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.
Configure a static NAT entry to map all packets from the public side to a single host on the private side. Show how that mapping provides any more security than what would exist by putting the public address on that host.
You snipped my comment, which said:
the standard usage of such devices is certainly that of a stateful firewall.
Configuring a static mapping to a particular "inside" host is not the standard usage in my experience. Obviously if you intentionally create a hole in your "security device", whether that be a NAT/NAPT or real firewall, that defeats some or even all of the protection offerred.
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. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking