nanog mailing list archives
Re: "trivial" changes to DNS (was: OpenNTPProject.org)
From: Jimmy Hess <mysidia () gmail com>
Date: Thu, 16 Jan 2014 13:35:00 -0600
On Thu, Jan 16, 2014 at 10:48 AM, Christopher Morrow < morrowc.lists () gmail com> wrote:
On Thu, Jan 16, 2014 at 11:39 AM, Andrew Sullivan <asullivan () dyn com> wrote:On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote:
So... what other options are there to solve the larger problem of:
"Some service is running on a public host, and it can be used to attack a third party" where in all of these cases the third party is someone who's address has been spoofed in the src-address of a packet.
Standardizing some UDP service-neutral PRE-Authentication system comes to mind; operating at the host level, independent of the various services, requiring the client to perform at least as much work as the response packet. E.g. Fwknop Single-Packet Authentication/Port-Knocking Style "The application doesn't see any UDP packets from a source:port number pair, until a source address authenticity event occurs, for that source ip:port number pair." Say instead of "port knocking" though, the client is required to estimate the size of the response to its first round trip of UDP request messages. Then the client's UDP stack must construct and send a Hashcash proof of work, of sufficient difficulty based on the estimated query plus response size, up to the first full round trip; containing a message digest of the first UDP packet the client will send, before sending the packet, or it will be silently discarded. An out-of-band reply will come back to the claimed source, that the client souce IP:Port has to acknowledge within 5 packets. Once the out-of-band reply is acknowledged, the source is confirmed not to be spoofed. UDP response packets and new queries above the estimated initial reply size or after the 5th packet are delayed until definitive confirmation or silently dropped, instead of returned to the claimed source. -chris
--
-JH
Current thread:
- Re: "trivial" changes to DNS (was: OpenNTPProject.org), (continued)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Christopher Morrow (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Andrew Sullivan (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Christopher Morrow (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Andrew Sullivan (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Cb B (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Andrew Sullivan (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Cb B (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Bjoern A. Zeeb (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Saku Ytti (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Cb B (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Jimmy Hess (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Valdis . Kletnieks (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Mark Andrews (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Jimmy Hess (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Mark Andrews (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Cb B (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Mark Andrews (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Jared Mauch (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Andrew Sullivan (Jan 16)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Tony Finch (Jan 17)
- Re: "trivial" changes to DNS (was: OpenNTPProject.org) Jared Mauch (Jan 22)