[e2e] 100% NAT - a DoS proof internet
touch at ISI.EDU
Mon Feb 20 17:11:04 PST 2006
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:
>> 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:
> 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.
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.
More information about the end2end-interest