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@xxxxxxxx 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf