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
