[e2e] 100% NAT - a DoS proof internet

Joe Touch touch at ISI.EDU
Mon Feb 13 08:35:21 PST 2006


Hi, Jon,

Jon Crowcroft wrote:
> 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 -

So let's start. In the beginning, there is no DHT. Your host and mine
are behind NATs. Don't we FIRST need to join the DHT? How do we do that?

> 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

Allocating these addresses is what NAT's already do - some for a pool of
addresses, some for an address/port pair. All that does is allow your
host and my host to end up receiving incoming calls on those addresses.

We still need to find each others' addresses; you haven't told us how to
do that. The DHT by which we might find each other doesn't exist yet.

--

Finally, whatever ID you want to expose to the world (DHT node ID, DNS
name, etc.) just 'undoes' what the NAT did. Every reason you had for
NAT'ing the host is a reason to "NAT" those IDs at some point, where
you're back where you started.

Joe

> 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)
>  >>--------------enig8AEE14DC4866D756D31CF09B
>  >>Content-Type: text/plain; charset=ISO-8859-1
>  >>Content-Transfer-Encoding: quoted-printable
>  >>
>  >>Hi, Jon,
>  >>
>  >>Jon Crowcroft wrote:
>  >>> So there's three things here
>  >>>=20
>  >>> 1/ a mad idea for a DoS proof internet - This goes like this:
>  >>>=20
>  >>> 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)
>  >>>=20
>  >>> So how would you ever reach someone (like most NAT traversal stuff is
>  >>> tricky - viz skype - see also below:)
>  >>>=20
>  >>> Meanwhile, here is how: Distributed Hashed Time.
>  >>>=20
>  >>> 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).
>  >>>=20
>  >>> 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...
>  >>
>  >>Joe
>  >>
>  >>
>  >>--------------enig8AEE14DC4866D756D31CF09B
>  >>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
>  >>
>  >>iD8DBQFD8LE8E5f5cImnZrsRAlIaAJ9Dq0kBFWBmw5SzWpZBVSq6h94pMACg6EzY
>  >>VBmeL/dEBX6qvumw8swM4TQ=
>  >>=cuLP
>  >>-----END PGP SIGNATURE-----
>  >>
>  >>--------------enig8AEE14DC4866D756D31CF09B--
> 
>  cheers
> 
>    jon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060213/8bd9c69a/signature-0001.bin


More information about the end2end-interest mailing list