[e2e] 100% NAT - a DoS proof internet

[Joe Touch]

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.

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.

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

Joe