[e2e] 100% NAT - a DoS proof internet

[Joe Touch]

Hi, Dan,

Dan Wing wrote:
>>> 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
> 
> Both Bonjour and UPnP provide existing mechanisms to learn your
> public IP address.  Depending on how they're implemented, they 
> can even work in a nested NAT scenario like:
> 
>   [host]--[NAT]--[NAT]-----[Internet]
> 
> NSIS provides another technique to learn your public IP address.
> 
>> 		STUN servers must reside on the public Internet
>> 		to determine the public address of a NAT'd host
> 
> Yes, a STUN server on the Internet is the technique described
> by ICE.  STUN is the only existing IETF protocol to learn
> your public IP address.  NSIS isn't yet ready and Bonjour's
> NAT-PMP and UPnP aren't IETF protocols.
> 
> A STUN server could be integrated with your NAT device, of 
> course, and provide the same information as a public STUN 
> server.  This could also be implemented to work in a nested 
> NAT scenario like I diagrammed above, as well.
> 
>> 	- 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.
> 
> Publicly-accessible server.  The server could, itself, be behind
> a NAT, so long as it had some way of learning its public IP address
> and publishing its public IP address and port.

How?

That's the trick with ALL of these. Short of having a cooperating system
in the public Internet or the equivalent (i.e., a friendly net manager,
or omniscient deity), how?

>> ICE is one protocol for doing that,
>> 		but it still requires a public server somewhere
>> 		(i.e., the TURN server)
> 
> ICE does not require a TURN server.  
> 
> A TURN server's only function is to relay UDP media, and is 
> only necessary if the NAT implementation creates a new UDP 
> binding when the host communicates to a new remote host (such
> behavior is called 'symmetric NAT' in RFC3489.  The behavior
> makes it impossible to rendezvous on the UDP port you learned
> via STUN.  Bonjour- and UPnP-learned addresses wouldn't suffer
> from this problem.)

Fine, but you still need the STUN server in the first place.

>> 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.
> 
> TURN isn't needed unless the NAT's implementation is defective.
> 
> If you don't want to hit a public STUN server such as stun-server.org,
> you would have to use UPnP, Bonjour, or buy a NAT with a STUN server
> built in.

How would any of that help if all of those systems  UPnP, Bonjour, or a
NAT w/STUN inside) are behind NATs?

The problem is that you cannot control whether you're stuffed behind a
NAT - short of out-of-band agreement from your ISP. Once you are, none
of these systems work.

Joe