[e2e] 100% NAT - a DoS proof internet

Joe Touch touch at ISI.EDU
Wed Feb 22 07:39:14 PST 2006

Saikat Guha wrote:
> On Mon, 2006-02-20 at 22:36 -0800, Joe Touch wrote:
>> Without NATs, you need:
>> 	my IP address
>> 	the port I run the service on
> Indeed. As you suggest, lets assume there is a service that allows you
> somehow publish your IP address and port, which may be assigned
> dynamically by DHCP.

If you had a place to publish them, that place would need to accept
incoming requests - i.e., to respond to queries from others about your

Let's say that place is behind a NAT. Then *it* needs to similarly
publish its address and port.

And so on...

i.e., besides begging the question of how you can find out your public
address/port without cooperation from your NAT or a server on a public
port, even if you had cooperation from your NAT you still need to
deposit this info somewhere public.

NATs *rely* on the fact that some places aren't NAT'd. I.e., they are
Nietzschian - NATs are for the 'special'; the commoners need to be on
the public NAT, exposed in infrastructure and open to incoming services.

>                           +------ request ------+
>                           V                     |
> [You] -- publish --> [Service] -- response --> [Me]
>> With NATs, I need to know YOU are calling be somehow, so that I can do
>> something to trigger the NAT upstream from me
> Also true. Simply change the service above to notify you when someone
> wants to contact you.

Er - how does that service know that? The service needs to be on the
public net to accept the call that indicates someone called it to call you.

>                           +------ request ------+
>                           V                     |
> [You] -- publish --> [Service] -- response --> [Me]
>   A                       |
>   +----- notify  ---------+
>> The only way to do that is via a server on the public Internet (short of
>> a telephone, which can cheat in any coordination system).
> The service doesn't have to be "on" the public internet, but rather
> accessible from the public Internet. In particular, the service can
> run behind a NAT that the service provider controls. The service
> provider configures the NAT to forward inbound queries to the correct
> private address.

The server needs to be "on the public Internet". It needs to lack the
intended protections of NATs. It needs to have a public address open to
incoming connections, and that information needs to be advertised.
Whether it's tunneled behind a NAT that isn't hiding it is irrelevant.

>> I.e., a NAT'd Internet is an incomplete architecture; it cannot usefully
>> exist without non-NAT'd servers.
> Certainly, this service above would have to be part of the architecture
> to complete it. Just as DNS is now a part of the IP architecture.

The DNS is part of the IP architecture. The service above must be
OUTSIDE the NAT architecture.


More information about the end2end-interest mailing list