Hi Tony,
On Jan 23, 2009, at 5:26 PM, Tony Hain wrote:
Any and all discussions in the IETF related to nat MUST NOT imply
any kind
of security. The fact that product marketing departments do that is
absolutely out of scope, as the IETF needs to stay focused on the
technical
reality that mangling the header does not have any security impact
(try to
take a static 1:1 address mapping and show how that node is any more
secure
than it would be without the nat). To that end, bullet 2) creates an
invalid
set of goals for this proposed bof.
"Simple Security" is one of the primary reasons cited for using NAT,
and the IPv4 NAT property of blocking inbound connections is an
important part of some security solutions. While I agree that NAT is
not the only, and probably not the best, way to achieve this
functionality, it is a feature of NATs that is widely used, and relied
upon, in IPv4.
If we go with a one-to-one, two-way algorithmic mapping, our NAT
solution will not have this property. IMO, we need to make it clear
that our solution does not have this property, and also make it clear
how this property can be obtained. Our v6ops documents already
recommend the use of a firewall for IPv6 networks. There also seems
to be some consensus view that a similar type of functionality can be
obtained using a "stateful firewall", but (as far as I know) we have
not actually specified how to build/configure a firewall to block
inbound connections while allowing outbound ones, and I think we
should do that.
When we do go through the exercise of defining this solution, it will
be interesting to see how it compares to IPv4 NAT in terms of its
architectural impact on the network.
Margaret
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
