Looks good!  Thank you.

BR,
Emre

On Mon, Aug 17, 2009 at 3:55 AM, <pasi.ero...@nokia.com> wrote:

> The original text in RFC 4306 was slightly confusing, but I think we
> should leave room for ROHCoIPsec here. Perhaps adding something like
> this after the bulleted list?
>
>   If the Child SA negotiation includes some future IPsec protocol(s)
>   in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then
>   (1) all keys for SAs carrying data from the initiator to the
>   responder are taken before SAs going in the reverse direction, and
>   (2) keying material for the IPsec protocols are taken in the order
>    in which the protocol headers will appear in the encapsulated
>    packet.
>
> Best regards,
> Pasi
> (not wearing any hats)
>
> > -----Original Message-----
> > From: Emre Ertekin
> > Sent: 15 August, 2009 00:54
> > To: ipsec@ietf.org
> > Subject: [IPsec] Comment/Request on IKEv2bis Draft
>
> > Hi All,
> >
> > One comment/request on the IKEv2bis draft.
> >
> >
> > One of the differences between RFC 4306 and the IKEv2bis draft is in
> > Section 2.17, Generating Key Material for Child SAs.  Appendix E.2
> > of the IKEv2bis draft indicates the following:
> >
> >   In Section 2.17, removed "If multiple IPsec protocols are
> >   negotiated, keying material is taken in the order in which the
> >   protocol headers will appear in the encapsulated packet" because
> >   multiple IPsec protocols cannot be negotiated at one time.
> >
> > Is it possible to leave the quoted text in the spec?  I agree that
> > multiple IPsec protocols cannot be negotiated at one time; however,
> > the text is useful for ROHCoIPsec implementers, where multiple keys
> > may need to be generated for a ROHC-enabled Child SA.
> >
> > For example, if a ROHC-enabled Child-SA with ROHC_INTEG
> > [draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated,
> > first the IPsec encryption/authentication keying material will be
> > taken, then an additional key will be taken for the algorithm used
> > to verify the proper decompression of packet headers.
> >
> > BR,
> > Emre
>
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to