Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility

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_montenegro@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 <yaronf@checkpoint.com>
> > To: Tero Kivinen <kivinen@iki.fi>; "Grewal, Ken"
> <ken.grewal@intel.com>
> > Cc: "ipsec@ietf.org" <ipsec@ietf.org>; "Pasi.Eronen@nokia.com"
> <Pasi.Eronen@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-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On
> Behalf Of
> > > Tero Kivinen
> > > Sent: Monday, September 21, 2009 14:14
> > > To: Grewal, Ken
> > > Cc: ipsec@ietf.org; Pasi.Eronen@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.
> > > --
> > > kivinen@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