Re: IPv6 NAT

["Stephen Sprunk" <stephen () sprunk org>]

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