[e2e] 100% NAT - a DoS proof internet

[Joe Touch]

Dan Wing wrote:
...
>>>> 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]

>From your description above:

	- each host learns its public IP address
		please describe how this happens if only
		the two hosts above participate - notably
		without using a service on a public IP host elsewhere

		STUN servers must reside on the public Internet
		to determine the public address of a NAT'd host

	- the hosts rendezvous
		that works only if both hosts know they want
		to talk with each other. when both are behind
		a NAT, that means a registry on a public server
		is required. ICE is one protocol for doing that,
		but it still requires a public server somewhere
		(i.e., the TURN server)

You're quoting are two protocols that solve the trivial case; the
problematic case is when you have NEITHER STUN or TURN servers on the
public Internet available.

Joe

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