[e2e] 100% NAT - a DoS proof internet

[Dan Wing]

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

If you don't want a rendezvous protocol a host could indicate
its publicly-accessible IP address and UDP port via SRV DNS
records.

DNS is, of course, a public server with a registry.  But 
even with NAT you need DNS, so I'm failing to grasp the 
nuance of your argument that requiring a registry dooms
the original poster's proposal.

> >> 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 do need a way to learn your public IP address and UDP port.
STUN is but one way to accomplish that.  Bonjour and UPnP are two
other ways, and Bonjour and UPnP do not require a STUN server on
the Internet.  

Integrating a STUN server into the NAT itself is a way to avoid
a STUN server on the Internet, too.

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

UPnP and Bonjour only work if you own and control the NAT, I agree.

STUN will tell you your public IP address, even if the NAT is owned by
and controlled by your evil ISP that has put you behind a huge NAT.  
But in order to do that I agree you would need to talk with a STUN
server on the Internet (such as stun-server.org).


Sorry for jumping into the thread -- I thought the problem you
had raised is that two hosts, both behind their own NATs, could
not communicate with each other.  It seems I misunderstood.

-d