[e2e] 100% NAT - a DoS proof internet
dwing at cisco.com
Mon Feb 20 22:01:52 PST 2006
> 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.
> >>>> 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
> 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.
More information about the end2end-interest