[e2e] 100% NAT - a DoS proof internet

[Joe Touch]

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).

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
>>
>>