[e2e] 100% NAT - a DoS proof internet

[Dan Wing]

> Dan Wing wrote:
> > (behind on my email - sorry for the delay.) 
> > 
> >> -----Original Message-----
> >> From: end2end-interest-bounces at postel.org 
> >> [mailto:end2end-interest-bounces at postel.org] On Behalf Of Joe Touch
> >> Sent: Monday, February 13, 2006 8:18 AM
> >> To: Jon Crowcroft
> >> Cc: end2end-interest at postel.org
> >> Subject: Re: [e2e] 100% NAT - a DoS proof internet
> >>> 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
> > 
> > You can communicate with a host behind a NAT if that host tries to
> > communicate with you first.  This is how ICE (draft-ietf-mmusic-ice)
> > functions.  ICE's basic operation in this regard is this:
> > 
> >   1. Each host learns its public IP address (ICE describes 
> >   using STUN,
> >      RFC3489, for this; however you could use any other 
> >   technique you
> >      might prefer such as Bonjour, UPnP, or whatever),
> 
> You can't learn your public IP address without (a) or (b) above.
>
> >   2. They exchange their public IP addresses with each other using a
> >      rendezvous protocol (ICE expects "SDP" is the rendezvous
> >      protocol; SDP is used by SIP which solves your (b)), and then
> 
> I don't need to 'solve' (b); it's trivial to design a protocol to do
> this. The point I'm making is that (a) or (b) is required. 
> This repeats that point.
> 
> In the absence of both (a) and (b), how is it solvable? (_that_ is the
> real question).

I must be misunderstanding.  ICE (draft-ietf-mmusic-ice) describes
how a bi-directional UDP stream can be established between two 
hosts behind their own NATs, like this:

   [host]--[NAT]-----[Internet]-----[NAT]--[host]

-d

> Joe
> 
> >   3.  The hosts begin sending UDP packets to each other's public
> >       IP address.  The NAT binding is opened when the first
> >       inside->outside packet is seen by the NAT, which causes a
> >       subsequent outside->inside packet to be NATted to the
> >       proper host.
> > 
> > 
> > There is a similar technique that works with TCP when both hosts are
> > behind unmodified, unconfigured NATs.  If I recall correctly the NAT
> > technique does rely on the nearly ubiquitious (but TCP violating)
> > "stealth" NAT behavior (that is, the NAT has to simply drop 
> unexpected
> > TCP SYNs rather than respond with an ICMP error or a TCP 
> RST).  For an
> > example of specifics please see draft-hoffman-behave-tcp-03.txt.  
> > 
> > -d
> > 
> >> 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
> >>
> >>