Hi Scott, Peter, This text was kept simple deliberately, so we would not need to cover every single case of different algorithm permutations. The intention was as Peter indicates below "... "augmented" meant that the bytes would be logically prepended to the existing ESP data before the ICV was calculated...".
This is the same intention for AEAD algorithms, where the WESP header would be prepended to the ESP header and part of the AAD. If you think it adds additional clarity by explicitly specifying these 'rules', then we could certainly elaborate on the section as you describe below. And I agree that the '"four" should be changed' comment, which was an oversight due to last minute addition for IPv6 padding requirements. Thanks, - Ken >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf >Of McCann Peter-A001034 >Sent: Wednesday, December 16, 2009 10:45 AM >To: Scott C Moonen >Cc: [email protected]; [email protected]; [email protected]; draft- >[email protected] >Subject: Re: [IPsec] WESP and combined-mode algorithms > >Hi, Scott, > >Your comments make sense; I had assumed that "augmented" meant >that the bytes would be logically prepended to the existing ESP >data before the ICV was calculated, and that this notion was >well-defined wrt existing ESP ICV methods. I am not as familiar >with the combined mode AAD and how that works, so I'd defer to >your and the authors' judgement on whether additional specification >is needed. > >I do agree that the "four" should be changed. We should also keep >in mind the UDP encapsulation described in section 2.1, which adds >a header of 16 bytes, so we could say, "four, eight, or sixteen". > >-Pete > >Scott C Moonen wrote: >> Peter, your comment below made me go back and re-read the draft. >> Section 2.2 of this draft makes this statement: >> >> In the diagrams below, "WESP ICV" refers to the ICV computation as >> modified by this specification. Namely, the ESP ICV computation is >> augmented to include the four octets that constitute the WESP >> header. Otherwise, the ICV computation is as specified by ESP >> [RFC4303]. >> >> In general I wonder if this paragraph should be beefed up a bit. >> Tables 1 and 2 of RFC 4303 go into specific detail as to the order in >> which things are included in the ICV calculation, and simply saying >> "augmented" leaves some ambiguity as to where the WESP data appears. >> This paragraph should also probably say "four or eight" instead of >> "four". Finally, I wonder if the document should go into even more >> detail on how the WESP header is authenticated for combined-mode >> algorithms. Typically those algorithms have "additional >> authentication data", and I wonder if we should document specifically >> how the WESP header appears in the AAD for currently specified >> algorithms, and also document the expectation that future >> combined-mode RFCs should explicitly mention how a WESP header would >> appear in their AAD. >> >> >> Scott Moonen ([email protected]) >> z/OS Communications Server TCP/IP Development >> http://www.linkedin.com/in/smoonen >> <http://www.linkedin.com/in/smoonen> >> >> >> >> From: "McCann Peter-A001034" <[email protected]> >> To: <[email protected]>, >> <[email protected]> >> Cc: [email protected] >> Date: 12/16/2009 12:20 PM >> Subject: Re: [IPsec] Gen-ART telechat review of >> draft-ietf-ipsecme-traffic-visibility-11 >> >> ________________________________ >> >> >> >> >> 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 >> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> >> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html >> <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-ipsecme-traffic-visibility-11 >> Reviewer: Pete McCann >> Review Date: 16 Dec 2009 >> IESG Telechat date: 17 Dec 2009 >> >> Summary: Ready >> >> Major issues: none >> Minor issues: none >> Nits/editorial comments: none >> >> This version addresses my previous comment adequately. >> >> -Pete >> >> >> >> McCann Peter-A001034 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 >>> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> >>> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html >>> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> > ). >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. >>> >>> Document: draft-ietf-ipsecme-traffic-visibility-09 >>> Reviewer: Pete McCann >>> Review Date: 2009-10-29 >>> IETF LC End Date: 2009-10-28 >>> IESG Telechat date: unknown >>> >>> Summary: One minor issue to discuss >>> >>> Major issues: none >>> >>> Minor issues: >>> >>> Section 2: >>> As can be seen, the WESP format extends the standard ESP header >>> by the first 4 octets for IPv4 and by 8 octets for IPv6. The >>> WESP header is integrity protected, along with all the fields >>> specified for ESP in RFC 4303. >>> Normally ESP wouldn't need to process encapsulation headers that >>> appear prior to the SPI. Won't this require modification of the ESP >>> implementation, possibly breaking its modularity? Would it be >>> problematic for certain algorithms to include this data? It might be >>> good to state that. >>> >>> Nits/editorial comments: none >> >> _______________________________________________ >> IPsec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec >> <https://www.ietf.org/mailman/listinfo/ipsec> > >_______________________________________________ >IPsec mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
