[e2e] 100% NAT - a DoS proof internet

[Dan Wing]

> Dan Wing wrote:
> >>>> 	- 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.
> 
> You seem to be under the impression that everything works if a server
> somewhere knows it's public address. I agree.
> 
> The question I asked is "what if it DOES NOT?"
> 
> > 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.
> 
> Even with NAT you need public IP addresses that are known and fixed -
> i.e., you need someone somewhere to run a server that isn't
> _arbitrarily_ NAT'd. Sure, a controlled, fixed NAT that you have the
> omniscient power to see the public IP address of works.
> 
> However, consider the following:
> 
> 	what if everything you want to talk with is NAT'd
> 
> 	what if everything you own is NAT'd
> 
> What if there is a public Internet, but you can't tell anyone there to
> help you?
> 
> _that_ is the problem.
>
> I.e., NAT-alleviation assumes someone somewhere has control over a
> machine who can help you. It's IMPOSSIBLE to bootstrap NAT-alleviation
> without that assistance.

I fail to understand the distinction between the problem you're
describing and the same problem without any NATs whatsoever.  For example
if I get a publicly routable IP address from my ISP and I want you to
send me some packets, I need to somehow tell you that IP address.  I 
might do that with DNS or via some other protocol (or SIP or Jabber).

A fully NATted universe doesn't work, I agree.  But it is possible for
two NATted devices to exchange UDP (and TCP) packets without relaying
those UDP (TCP) packets through some non-NATted device.

> WITH that assistance, you can get around things. However, in order to
> assume that anyone out there can help you, you MUST assume someone,
> somewhere who isn't under the influence of NATs.

Yes, of course.

> I.e., you can't find your way out of the rabbit hole with NATs alone.

Agreed.

> >>>> 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.
> 
> If I had control to integrate the STUN server into the NAT - which I
> typically don't control or sometimes even know is there - why would I
> bother?
> 
> The problem with NAT's isn't the NAT's you control; it's the NATs you
> don't. You can't run a STUN server behind those to any utility.
> 
> >>>> 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.
> 
> They're not solutions then.
> 
> > 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).
> 
> Again back to the same solution - the only way to make two NAT'd boxes
> talk to each other is with the assistance of another, non-NAT'd box.
>
> > 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.
> 
> That is the problem; you keep adding things I didn't assume, i.e, you
> define away the problem.
> 
> We agree that two NAT'd boxes can talk with the help of a 
> non-NAT'd box.
> That's easy.
> 
> Two NAT'd boxes alone cannot talk to each other.
> 
> (and I assume NATs aren't under your own control because they 
> that's the typical case).

At Starbucks or as a subscriber in S. Korea or China, I agree it's typical.

-d