[e2e] 100% NAT - a DoS proof internet

Jon Crowcroft Jon.Crowcroft at cl.cam.ac.uk
Tue Feb 14 01:28:25 PST 2006

um, i think you need to re-read about DHTs and consistent hashes

what yo uare talking about is  the peer-to-peer routing part of some
structured DHTs - this is thigns like the finger table in chord, or
the prefix routing in pastry - i didnt say I was using any of that - i
am _just_ using a DHT to do the time slot allocation in a way that is
decentralised and agreed but not known except by agreement (made
externally to this mechanism - as must _any_ security scheme have)
between sender and recipient.

yes, there are attacks on the external mechanism (and there are
attacks on the routing) but saying there are attacks on X so your
mechanism to defend on attacks on Y is pointless, is completely bogus

In missive <43F0B13C.8080801 at isi.edu>, Joe Touch typed:

 >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
 >>Content-Type: text/plain; charset=ISO-8859-1
 >>Content-Transfer-Encoding: quoted-printable
 >>Hi, Jon,
 >>Jon Crowcroft wrote:
 >>> So there's three things here
 >>> 1/ a mad idea for a DoS proof internet - This goes like this:
 >>> What if 100% of hosts were behing a NAT (a bit like mark handley and
 >>> adam greenhalgh's idea on a dos proof internet in fdna a while back,=20
 >>> but taken to extreme, or also like default off paper in hotnets)
 >>> So how would you ever reach someone (like most NAT traversal stuff is
 >>> tricky - viz skype - see also below:)
 >>> Meanwhile, here is how: Distributed Hashed Time.
 >>> So we all know about DHTs - they hash an object to a node id, then use
 >>> some p2p route to get to the node id (e.g. MIT's chord finger table
 >>> etc etc).
 >>> So if we want to talk to a set of known people, we hash their
 >>> identifier (name) to TIME. We then send to each other at that agreed
 >>> time - no-one else can send to us or from us to them, and the hash key
 >>> can be a shared secret....
 >>How do you "send to each other"?
 >>You need to talk to a host behind a NAT. You need to reach the service
 >>on that host that runs this DHTime protocol. You can have more than one
 >>host behind the NAT. A NAT basically makes everything behind it look
 >>like one host.
 >>There are two options:
 >>	a. the host behind the NAT tries to reach the other host first
 >>		this works only if the 'other host' is NOT behind
 >>		a NAT, so we're out of luck
 >>	b. you 'register' your host somewhere as owning a unique
 >>	way to demultiplex packets to it
 >>A DHT does both of these - (a) to reach a node somewhere else that is
 >>NOT NAT'd first, then (b) to register in that infrastructure so other
 >>nodes can find it using its node ID.
 >>Two killer questions:
 >>	1. if everything is NAT'd, how do you perform step (a)?
 >>		i.e., where is the first place you register?
 >>	2. (b) assumes hosts have unique node-IDs, but you
 >>	went through a lot of trouble to remove that property (NATs)
 >>		for every reason you had a NAT in the base net,
 >>		why is it now acceptable to not NAT the node-IDs?
 >>		- if you NAT node IDs, you're back where you started
 >>		- if you're OK with not NAT'ing node IDs, why did you
 >>		NAT the base net?
 >>			i.e., non-NAT'd node IDs now become susceptible
 >>			to every message on the DHT
 >>> there you go...the details should be simple (apart from how you
 >>> provide sufficiently accurate synchronized time without a globally
 >>> reachable adddress betweewn the NTP servers, which, I admit, is
 >>> probably a mite tricky - i guess you need to have them agree a set of
 >>> rough times or something:)
 >>Time, IMO, is the least of your concerns...
 >>Content-Type: application/pgp-signature; name="signature.asc"
 >>Content-Description: OpenPGP digital signature
 >>Content-Disposition: attachment; filename="signature.asc"
 >>Version: GnuPG v1.4.1 (MingW32)
 >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 >>-----END PGP SIGNATURE-----



More information about the end2end-interest mailing list