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

From: gabriel montenegro <[email-masked]>
Date: Tue, 13 Oct 2009 14:07:04 -0700 (PDT)

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 <[email-masked]>
> To: Tero Kivinen <[email-masked]>; "Grewal, Ken" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Tero Kivinen
> > Sent: Monday, September 21, 2009 14:14
> > To: Grewal, Ken
> > Cc: [email-masked]; [email-masked]
> > 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.
> > --
> > [email-masked]
> > _______________________________________________
> > IPsec mailing list
> > [email-masked]
> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Wed, 14 Oct 2009 11:52:40 +0200

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

> From: ext gabriel montenegro [mailto:[email-masked]]
> Sent: 14 October, 2009 00:07
> To: Yaron Sheffer; Tero Kivinen; Grewal, Ken
> Cc: [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki)