IPv6 NAT
Stephen Sprunk
stephen at sprunk.org
Fri Oct 31 13:35:11 UTC 2003
Thus spake "Tony Hain" <alh-ietf at 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
More information about the NANOG
mailing list