Transport Directorate review of draft-mrw-nat66-09.txt
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they
receive. Please always CC tsv-dir(_at_)ietf(_dot_)org if you reply to or forward
this review.
I found no major issues with the document, and the document is nearly
ready for publication. Below are two points you might want to
consider addressing before publishing.
Overall, personally, I am glad to see this draft go forward to publication.
I think it is valuable, the more so because of the careful review and iteration
of the algorithms that took place on the nat66 mailing list.
1) The Introduction contains a factual error:
It is transport-agnostic with respect to transports that don't
checksum the IP header, such as SCTP or DCCP, and to transports
that use the TCP/UDP pseudo-header and checksum [RFC1071].
DCCP is not like SCTP in regard to checksum of the pseudo-header,
per RFC 4340 Section 9.1:
DCCP uses the TCP/IP checksum algorithm. The Checksum field in the
DCCP generic header (see Section 5.1) equals the 16-bit one's
complement of the one's complement sum of all 16-bit words in the
DCCP header, DCCP options, a pseudoheader taken from the network-
layer header, and, depending on the value of the Checksum Coverage
field, some or all of the application data...
The pseudoheader is calculated as for TCP.
2) There are a few impacts (or potential complications) end-to-end.
As the Transport Directorate reviewer, I thought I should review carefully
how NPTv6 impacts our many transport protocols. I found that that most
of the transports fit into one of the two categories mentioned in the
Introduction. Either (I) they don't checksum the IP header so don't care
if it changes or (II) they use the RFC 1071 checksum and therefore the
algorithm's "adjustment" works for them.
OK:
udp (II)
dccp (II)
udp-lite (II)
partial checksum DCCP (II)
dccp-udpencap (II)
sctp (I)
alc with tesla (I)
norm with tesla (I)
However, I'd like to mention two cases that are not addressed by I or II:
2a). RFC 5925- TCP Authentication Option - this is broken because IP addresses
are used in computing a MAC. Work has begun in draft-touch-ao-nat to allow
the zeroing out of the addresses but this discussion has not been completed.
Suggestion: mention the RFC 5925 problem briefly in this draft.
2b). RFC 5996 -IKEv2bis - NAT traversal - I think there may be residual issues
for NPTv6 with IPsec. Fred wrote (not unreasonably) on the mailing list that:
ESP (Encryption or the ESP-NULL integrity check) works through this.
AH doesn't. (2010-12-10)
But as I read RFC 5996, NPTv6 should trigger NAT Detection even though it
does not need to NAT traversal solutions defined. In the case of transport
mode, NAT Detection results in checksum fixup. It seems like this implies
only redundant action (as per RFC 3948 3.1.2) but it would be a good idea for
someone with expertise to look at whether there is a conflict.
Also, RFC 5996 calls out that:
if a NAT is detected, both devices MUST use UDP encapsulation for ESP.
and RFC 3948 2.1 says:
the IPv4 UDP Checksum SHOULD be transmitted as a zero value
which brings conflict with IPv6's prohibition of UDP checksum zero.
On UDP, the authors might want to take note of this sentence from
draft-ietf-6man-udpzero-02, section 1.3.4:
If NAT is defined for IPv6, it should take UDP zero checksum into
consideration.
NPTv6 seems like it is also a novel test of the adress-agility of the
SA management in IKEv2bis.
Suggestion: mention that it would be valuable to test interactions of
NPTv6 with various aspects of current-day IKEv2/IPsec NAT traversal.
Thanks!
Allison
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf