--On Friday, October 31, 2003 7:35 AM -0600 Stephen Sprunk <stephen@sprunk.org> wrote:
Thus spake "Tony Hain" <alh-ietf@tndh.net>
Kuhtz, Christian wrote:
All hairsplitting aside, given that the term NAT these days is mostly used in a PAT (particularly in a customer connecting to the I) context, what isn't secure about?
mangling the header doesn't provide any security, and if you believe it does, do the following exercise:
Mangling the header does not, but the stateful inspection and blocking used by a dynamic NAT/NAPT certainly does.
The point is that the stateful inspection/blocking can be achieved without NAT/PAT/NAPT.
A stateful filter that is automatically populated by traffic originated from the private side is what is providing 'security'. That function existed in routers long before NAT was specified by the IETF (see RFC1044 for vendor).
True. But consumers can't buy a RFC1044 device off the shelf today; what they can buy are generic NAT/NAPT devices which provide a minimal firewalling function _iff_ the user doesn't intentionally create holes. While it'd be nice if these devices didn't _require_ NAT/NAPT for their minimal operating mode, that's the configuration that is most likely to work in the setting it's intended for.
I'm not sure about RFC1044, but, it's relatively easy to buy lots of devices that will do stateful inspection without NAT off the shelf. Any version of *NIX with iptables or ipchains, some Cisco routers, Various Checkpoint software products, Cyberguard firewalls, Nokia, Sonic, Netscreen, NetGuard, and others all support Stateful inspection with or without NAT/PAT/NAPT. There is NO security benefit to NAT/PAT/NAPT. There is a security benefit to stateful inspection. NAT is harmful to many protocols. Stateful inspection is not. Owen -- If it wasn't signed, it probably didn't come from me.