Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv

Thanks a lot Scott for the response. I am publishing the draft asap.
Yours,
Daniel

On Tue, Mar 27, 2018 at 2:04 PM, Scott Fluhrer (sfluhrer) <
sfluhrer@cisco.com> wrote:

>
>
> *From:* mglt.ietf@gmail.com <mglt.ietf@gmail.com> *On Behalf Of *Daniel
> Migault
> *Sent:* Tuesday, March 27, 2018 1:22 PM
> *To:* Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>
> *Cc:* IPsecme WG (ipsec@ietf.org) <ipsec@ietf.org>
> *Subject:* Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv
>
>
>
> Thank you Scott for your comments.
>
> I understand the first comment as a text clarification to comment on the
> mechanism provided by section 3.5 of RFC6407 and explicitely mention that
> is does not apply here. Does the replacement below addresses your concern ?
>
> OLD:
>    Section 3.5 of [RFC6407] explains how
>    repetition MAY BE prevented by using a prefix for each group member,
>    which could be prefixed to the Sequence Number.  Otherwise, Implicit
>    IV MUST NOT be used in multicast scenarios.
>
> NEW:
>    Section 3.5 of [RFC6407] provides a mechanism that MAY be used to
> prevent IV collisions when the same key is used by multiple users. The
> mechanism consists in partitioning the IV space between users by assigning
> the most significant byte to a user. When implicit IV transforms are used,
> such mechanism cannot be applied as the IV is not sent, but instead it is
> derived from the Sequence Number. A similar mechanism could be used by
> associating the most significant byte of the Sequence Number to a sender,
> while the 3 remaining bytes will be used to carry the counter value. Such
> mechanism prevents the use of Extended Sequence Number and limits the
> number of packet to be sent to 2** 24 =  16777216, that is 16 M.
>
> Unless some mechanism are provided to avoid collision between Sequence
> Number, ( and so IV ), Implicit IV MUST NOT be used.
>
>
>
> That works…
>
>
>
>
> Regarding the second comment, I guess the idea was to mention that a
> responser cannot select a IIV Transform unless being sent by the initiator.
> I propose the following text. Do it address your comment ?
>
> OLD:
>
>    The rules of SA payload processing ensure that the responder will
>    never send an SA payload containing the IIV indicator to an initiator
>    that does not support IIV.
>
>
> NEW:
>
>    The rules of SA payload processing ensure that the responder will
>    never send an SA payload containing the IIV transform to an initiator
>    that does not support IIV.
>
>
>
> I’m wondering whether this is necessary to state this.  For example, RFC
> 7634 (the ChaCha IPsec transform) does not have any similar language, even
> though (like this draft) they define a new transform id.
>
>
>
> However, I’m not demanding any change; the text just sounds redundant to
> me…
>
>
>
>
>
> The reason for not having AES_CTR was that the transform is on its way to
> be retired. I propose to remove AES-CTR, but if there is a need to provide
> AES-CTR with implicit IV we coudl also add additional code points.
>
> I am currently proposing the following text:
>
> OLD:
>    AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
>    implement the implicit IV described in this document.
>
> NEW:
>
>    AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
>    implement the implicit IV described in this document.
>
>
>
> Works for me.
>
>
>
>
>
> Yours,
>
> Daniel
>
> On Sun, Mar 25, 2018 at 2:10 PM, Scott Fluhrer (sfluhrer) <
> sfluhrer@cisco.com> wrote:
>
> -          Section 4: “Section 3.5 of [RFC6407] explains how repetition
> MAY BE prevented by using a prefix for each group member”
>
> Actually, RFC6407 just refers to RFC6054; that has the SID in the top 8
> bits of the 8 byte sequence number.  Used literally, this doesn’t work, as
> the top 8 bits of the 8 byte sequence number are never expressed in the
> packet in implicit-iv.  You could put them in the top 8 bits of the 4 byte
> sequence number (which means you can’t use ESN, but it didn’t work in the
> multisender case anyways), but that would mean that each sender would be
> limited to 16M packets. I believe that these details are distinct enough
> that (if this is considered a viable alternative) they should be explicitly
> listed (including the 16M packet restriction).  Alternatively, we can just
> forbid this transform in the multisender case.
>
>
>
> -          Section 6: “The rules of SA payload processing ensure that the
> responder will never send an SA payload containing the IIV indicator to an
> initiator that does not support IIV”
>
> I believe that this is stale text; the current draft doesn’t use an
> indicator; instead, it defines separate transforms IDs.
>
>
>
> -          Section 8 has “AES-CTR … [is] likely to implement the implicit
> IV described in this document”; however the transform ENCR_AES_CTR_IIV is
> not defined.  Is this intended?  Should we either remove the AES-CTR
> algorithm from the list of “likely to implement”, or should we actually
> define the transform id for it?
>
>
>
>
> _______________________________________________
> 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
>
>