[e2e] 100% NAT - a DoS proof internet

Joe Touch touch at ISI.EDU
Wed Feb 22 11:35:10 PST 2006

Hash: SHA1

Saikat Guha wrote:
> On Wed, 2006-02-22 at 09:13 -0800, Joe Touch wrote:
>>Fair enough.  The DNS is optional in the Internet.
>>In the Internet, if I am behind a NAT and want to reach you, I need to
>>know your public IP address and the port that you will listen on.
>>You do NOT need to know _I_ will contact you, you do not need to know my
>>IP address, and you do not need to know my source port; you can accept
>>'any incoming'.
> You implicitly make the assumption that I am willing to accept your (and
> indiscriminately everyone else's) packets. Anyone behind a firewall,
> either by choice or not, would likely agree that this classic assumption
> is no longer substantiated in general.
> If the packet is from a known worm-infected address, I don't want it. My
> ISP doesn't want me to receive it lest I wreak havoc on their network.
> Most likely, your ISP won't want you to send it in the first place.

That's what firewalls are for. NATs don't block infected sources; they
block only sources you didn't expect packets from.

>>NATs don't work that way - my knowing your contact info isn't enough;
>>you need to know I'm coming. Destination address and port are
>>insufficient to demultiplex incoming calls; you NEED source address and
>>port, and you NEED a DNS-like structure to accomplish that.
> The "NEED" for source address and port based demultiplex is due more to
> security concerns than NATs. Before I let you in, I want to know who you
> are, what you are trying to send me and why, and I might as well
> negotiate how and at what address we can exchange packets.

You do that inside the packet exchange - e.g., using SSL or IPsec E2E.
Just blocking on the source IP address and port that you didn't expect
isn't security - it's service blocking.

> The mechanistic requirements of the NAT'ed Internet conveniently
> coincide with the present security requirements. One may very well
> leverage the other imho.

NATs coincide with the model that consumers are clients and commercial
entities are servers. When that's not the case (VoIP, software
maintenance via web service portals, etc.), NATs do not coincide.

Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


More information about the end2end-interest mailing list