[e2e] 100% NAT - a DoS proof internet
Jon.Crowcroft at cl.cam.ac.uk
Mon Feb 13 08:25:44 PST 2006
there's no central anything - there is a pool of unallocated globally
reachable addresses and a set of points (where, as yet, you can't
ingress/egress) around the edge of the net -
behind these points, one can cause a globally reachable address to be
allocated for an egress w.r.t. an ingress for unidirectional
communication at some time - so the other end can then try sending to
it (only at that time) - this usefully has the side effect of
allocating another globally reachable pinhole at the source so the
sink (but noone else) could optionally answer
thing of the time being a capability and this being a
very virtual circuit.
its not like IP, jim, at all.
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
>>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"
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.4.1 (MingW32)
>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>-----END PGP SIGNATURE-----
More information about the end2end-interest