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

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Sun, 25 Mar 2018 18:10:34 +0000

-          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?

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Sun, 25 Mar 2018 19:01:27 +0000

Rereading this, I have to do one correction:

From: IPsec <[email-masked]> On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Sunday, March 25, 2018 2:11 PM
To: IPsecme WG ([email-masked]) <[email-masked]>
Subject: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv

-          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.
I meant "the top 8 bits of the 8 byte explicit IV"...

Sorry about that...

---

From: Daniel Migault <[email-masked]>
Date: Tue, 27 Mar 2018 13:22:08 -0400

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.

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.

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.

Yours,
Daniel

On Sun, Mar 25, 2018 at 2:10 PM, Scott Fluhrer (sfluhrer) <
[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 27 Mar 2018 18:04:43 +0000

From: [email-masked] <[email-masked]> On Behalf Of Daniel Migault
Sent: Tuesday, March 27, 2018 1:22 PM
To: Scott Fluhrer (sfluhrer) <[email-masked]>
Cc: IPsecme WG ([email-masked]) <[email-masked]>
Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv

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:

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:

NEW:

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.

OLD:

NEW:

Works for me.

Yours,
Daniel
On Sun, Mar 25, 2018 at 2:10 PM, Scott Fluhrer (sfluhrer) <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Daniel Migault <[email-masked]>
Date: Tue, 27 Mar 2018 14:10:27 -0400

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) <
[email-masked]> wrote:

>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Daniel
> Migault
> *Sent:* Tuesday, March 27, 2018 1:22 PM
> *To:* Scott Fluhrer (sfluhrer) <[email-masked]>
> *Cc:* IPsecme WG ([email-masked]) <[email-masked]>
> *Subject:* Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv
>
>
>
> 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.
>
>
>