I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors should treat these comments just like
any other last call comments.
Background: The document describes the issues with NAT-PT as defined in
RFC2766 and recommends reclassification of the RFC to historic status.
NAT-PT allows communication between IPv4-only nodes and IPv6-only nodes
via a set of network layer translation mechanisms (a combination of
address and protocol translations).
Review Summary: In general, I agree that while NATs have been a
necessary evil for IPv4, they should not be restricting IPv6 development
or applications. The document does a good job of describing the issues,
although, as I will indicate below, some of the issues described are
applicable to NATs in general and are not specific to NAT-PT alone. I
did not find any security issues with the document.
Details:
* Almost all the security issues pointed out in the document apply to
NATs in general and are not unique to NAT-PT. Having said that though, I
agree that those issues unnecessarily affect IPv6 if NAT-PT is used. For
instance:
- Section 1 points out the scalability concerns and single point of
failure introduced by NAT-PT, making it a nexus for attacks. While true,
this is true of NATs and more generally, true of any centralized entity
introduced by any protocol. IPsec gateways, Mobile IP Home Agents are
all examples of centralized entities through which a large volume of
traffic must pass. The major difference is that those are centralized
entities with which end nodes have a security association and are aware
that traffic is passing through those entities, while NATs are
essentially transparent and may be changing packets without
authorization. Hence, it is extremely difficult to detect a misbehaving
NAT than it is to detect some other misbehaving centralized entity.
- DoS threats relating to resource exhaustion are pointed out at a
couple of places in the document. The same comment as above applies
there as well.
* Section 2.1 talks about issues with NAT-PT in protocols embedding IP
addresses. The issue about address length differences and the
consequences is certainly valid. All the ALG related issues, though, are
applicable to any kind of NATs.
- This section states "Assuming that the NAT-PT contains a
co-located ALG for one of the relevant protocols, the ALG could replace
the embedded IP addresses and ports. However, this replacement can only
happen if no cryptographic integrity mechanism is used and the protocol
messages are sent in the clear (i.e., not encrypted)." Such an
operation, in theory, is also feasible when the IP addresses and ports
are considered mutable fields for security purposes. However, the stated
issues are valid for most known security protocols.
- This section calls out the need for UDP encapsulation of IPsec
traffic. Any protocol that does not run over a transport layer needs UDP
encapsulation for NAT traversal and this is not specific to NAT-PT.
We've done that with IPsec, MIP4, etc. and we've even run IKE over
different ports to avoid ALGs messing up the protocol.
Hope that helps.
Vidya
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf