Thanks -- I've asked the secretariat to start the IETF Last Call! Here are the first IETF Last Call comments (none of them major): - The text about 8-octet alignment probably needs some small clarifications. For IPv6, 8-octet alignment is not optional, so "SHOULD" is not really correct. And there's an exception: if you're doing UDP encapsulation, the 0x00000002 SPI/protocol identifier takes four octets, so the IPv6Padding field isn't included in that case.
- The bit numbers in Figure 4 aren't aligned. - [RFC3948] and [RFC5226] should be normative references, not informative. Best regards, Pasi > -----Original Message----- > From: ext gabriel montenegro [mailto:g_e_montene...@yahoo.com] > Sent: 14 October, 2009 00:07 > To: Yaron Sheffer; Tero Kivinen; Grewal, Ken > Cc: ipsec@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) > Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic- > visibility > > Just to make sure this does not fall through the cracks: we've > submitted rev 09 last week to address > the AD review comments per discussion on the mailing list and at the > virtual interim. > > > > ----- Original Message ---- > > From: Yaron Sheffer <yar...@checkpoint.com> > > To: Tero Kivinen <kivi...@iki.fi>; "Grewal, Ken" > <ken.gre...@intel.com> > > Cc: "ipsec@ietf.org" <ipsec@ietf.org>; "pasi.ero...@nokia.com" > <pasi.ero...@nokia.com> > > Sent: Mon, September 21, 2009 5:40:19 AM > > Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme- > traffic-visibility > > > > Hi Tero, > > > > Given that the existing ESP header is integrity-protected, I don't > see the > > downside to adding the same protection for the new header. On the > other hand, > > this would eliminate a whole class of vulnerabilities. We still have > a few > > reserved bits in the WESP header, and you don't want to find out > years down the > > road that they cannot be used because they're not protected in > transit. > > > > Thanks, > > Yaron > > > > > -----Original Message----- > > > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On > Behalf Of > > > Tero Kivinen > > > Sent: Monday, September 21, 2009 14:14 > > > To: Grewal, Ken > > > Cc: ipsec@ietf.org; pasi.ero...@nokia.com > > > Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme- > traffic- > > > visibility > > > > > > Grewal, Ken writes: > > > > >- A question: did the WG discuss the pros and cons of integrity > > > > >protecting the WESP header? (This does make WESP more complex to > > > > >implement, and currently the WESP header does not contain any > data > > > > >that would benefit from integrity protection in any way.) > > > > [Ken] This change was the result of a discussion on threats posed > by > > > > 'malware', which could modify the WESP headers to obfuscate the > > > > payload from inspection by intermediate nodes such as IDS/IPS > > > > systems. > > > > The issue (ticket #104) was raised and closed some time back > after > > > > lengthy discussions on the topic. > > > > http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104 > > > > > > As everything in the WESP header is something that can be verified > by > > > the recipient node why is the integrity protection needed? > > > > > > I think it would make implementation WESP much easier if it can be > > > done as post processing step after ESP has been applied, in a > similar > > > way UDP encapsulation can be done to the ESP packet. > > > -- > > > kivi...@iki.fi > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > Scanned by Check Point Total Security Gateway. > > > > Email secured by Check Point > > > > Email secured by Check Point > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
