|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: IPv6 NAT
Thus spake "Tony Hain" <[email protected]> > 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
|