Hello Mohamed,
> I adopted in my local copy the text you proposed to describe the IPsec issue.
> I can even shorten the
> text to something like "IPsec complications with NAT-PT (Section 2.1 of
> [RFC4966])" but I prefer your
> text because it provides more RFC pointers.
Thank you for picking up the text.
It would be helpful for the Security Area to double-check it - I've cc:'d Sean
Turner (SEC AD) in the hope that he or one of the IPsec experts in the Security
Directorate can quickly check this 1-paragraph proposed text change, as in
addition to this draft, I will need to file the result as errata against RFC
4966.
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
Thanks,
--David
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, February 29, 2012 4:37 AM
> To: Black, David; [email protected]; [email protected]; [email protected];
> [email protected]
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]
> Subject: RE: Gen-ART review of draft-ietf-behave-64-analysis-06
>
> Dear David,
>
> Thank you for the review.
>
> I adopted in my local copy the text you proposed to describe the IPsec issue.
> I can even shorten the
> text to something like "IPsec complications with NAT-PT (Section 2.1 of
> [RFC4966])" but I prefer your
> text because it provides more RFC pointers.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : [email protected] [mailto:[email protected]]
> > Envoyé : mardi 28 février 2012 17:01
> > À : [email protected]; [email protected]; BOUCADAIR Mohamed
> > OLNC/NAD/TIP; [email protected]; [email protected]
> > Cc : [email protected]; [email protected];
> > [email protected]; [email protected];
> > [email protected]
> > Objet : Gen-ART review of draft-ietf-behave-64-analysis-06
> >
> > 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
