[e2e] 100% NAT - a DoS proof internet

[Dan Wing]

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

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

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

-d

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