I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd or
AD before posting a new version of the draft.
Document: draft-ietf-behave-64-analysis-06
Reviewer: David L. Black
Review Date: February 28, 2012
IETF LC End Date: February 20, 2012
IESG Telechat Date: March 1, 2012
Summary:
This draft is on the right track but has open issues, described in the review.
Comments:
This draft summarizes the improvements of stateful 64 techniques over the
now-historic
NAT-PT techniques for communication between IPv4 and IPv6 networks. The draft
does a
nice job of summarizing the current situation in a fashion that avoids the
reader
having to go through the plethora of details in the cited references. The
draft is
clearly written and reads well.
There is one open issue that's almost a nit - unfortunately, the IPsec
discussion in
item 6 of Section 3.2 is wrong, even though it was copied from RFC 4966 (FWIW,
it's
wrong there, also):
6. Unless UDP encapsulation is used for IPsec [RFC3948], traffic
using IPsec AH (Authentication Header), in transport and tunnel
mode, and IPsec ESP (Encapsulating Security Payload), in
transport mode, is unable to be carried through NAT-PT without
terminating the security associations on the NAT-PT, due to their
usage of cryptographic integrity protection (Section 4.5 of
[RFC4966]).
There are four problems with that explanation:
(1) AH cannot be UDP-encapsulated. RFC 3948 says:
Because the protection of the outer IP addresses in IPsec AH is
inherently incompatible with NAT, the IPsec AH was left out of the
scope of this protocol specification.
(2) The reasons for use of UDP encapsulation with ESP do not include ESP's
"usage of cryptographic integrity protection." because ESP's cryptographic
integrity protection does not include any IP header fields. The actual reasons
are considerably more subtle and involved (e.g., traffic selector issues and
NAT implementations that did not work correctly with IKE), see RFC 3715.
(3) Nit: The correct RFC 4966 reference is Section 2.1, not 4.5.
(4) A number of additional references are needed, starting with RFC 3715.
Here's an attempt to propose a text change:
OLD
6. Unless UDP encapsulation is used for IPsec [RFC3948], traffic
using IPsec AH (Authentication Header), in transport and tunnel
mode, and IPsec ESP (Encapsulating Security Payload), in
transport mode, is unable to be carried through NAT-PT without
terminating the security associations on the NAT-PT, due to their
usage of cryptographic integrity protection (Section 4.5 of
[RFC4966]).
NEW
6. IPsec traffic using AH (Authentication Header) [RFC4302] in
both transport and tunnel modes cannot be carried through NAT-PT
without terminating the security associations on the NAT-PT, due
to the inclusion of IP header fields in the scope of AH's cryptographic
integrity protection [RFC3715] (Section 2.1 of [RFC4966]). In
addition, IPsec traffic using ESP (Encapsulating Security Payload)
[RFC4303] in transport mode generally uses UDP encapsulation [RFC3948]
for NAT traversal (including NAT-PT traversal) in order to avoid the
problems described in [RFC3715] (Section 2.1 of [RFC 4966]).
END
The Security Area should review the above proposed text change.
idnits 2.12.13 noted that RFC 2766 was obsoleted by RFC 4966 - this is
fine, as RFC 2766 does need to be cited.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
