"trivial" changes to DNS (was: OpenNTPProject.org)

Thu Jan 16 19:35:00 UTC 2014

On Thu, Jan 16, 2014 at 10:48 AM, Christopher Morrow <
morrowc.lists at gmail.com> wrote:

> On Thu, Jan 16, 2014 at 11:39 AM, Andrew Sullivan <asullivan at 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