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 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> ). 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> ). > > 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
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
