Re: [Gen-art] Gen-ART review of draft-ietf-behave-64-analysis-06

[Russ Housley <[e-mail]>]

David:

Has an errata been entered against RFC 3948?


On Feb 28, 2012, at 11:01 AM, <[e-mail]> <[e-mail]> wrote:

> 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art