Subject: [IPsec] WGLC on draft-mglt-ipsecme-implicit-iv-04

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 26 Oct 2017 19:47:33 +0000

All,

This message starts a Working Group Last Call (WGLC) for draft-mglt-ipsecme-implicit-iv-04.

The version to be reviewed can be found here: https://www.ietf.org/id/draft-mglt-ipsecme-implicit-iv-04.txt.

Please send your comments, questions, and edit proposals to the WG mail list until November 9th, 2017.  If you believe that the document is ready to be submitted to the IESG for consideration as a Standards Track RFC please send a short message stating this.

Best Regards,
Dave and Tero

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 27 Oct 2017 18:30:37 +0300

Waltermire, David A. (Fed) writes:
> The version to be reviewed can be found here:
> https://www.ietf.org/id/draft-mglt-ipsecme-implicit-iv-04.txt. 
> 
> Please send your comments, questions, and edit proposals to the WG
> mail list until November 9th, 2017.  If you believe that the
> document is ready to be submitted to the IESG for consideration as a
> Standards Track RFC please send a short message stating this. 

<chair hat off>
<iana expert hat on>

In section 8, fix the spelling of the ENCR_AES-CCM_8_IIV and similar
so that they do not use "-", but only "_" (or otherwise be ready to
face the wrath of the angry implementor in next IETF). I.e.

   -  ENCR_AES_CCM_8_IIV

   -  ENCR_AES_GCM_16_IIV

   -  ENCR_CHACHA20_POLY1305_IIV
-- 
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Fri, 27 Oct 2017 12:36:41 -0400

Hi Tero,

Thanks for the review, It should be easy to fix.
Yours,
Daniel

On Fri, Oct 27, 2017 at 11:30 AM, Tero Kivinen <[email-masked]> wrote:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 30 Oct 2017 15:19:27 +0300

Hi,

> Please send your comments, questions, and edit proposals to the WG mail list until November 9th, 2017.  If
> you believe that the document is ready to be submitted to the IESG for consideration as a Standards Track
> RFC please send a short message stating this.
> 
> Best Regards,
> Dave and Tero

I found document almost ready. There are a couple of issues that should be addressed:

1. Abstract

	IPsec ESP sends an initialization vector (IV) or nonce in each packet, adding 8 or 16 octets.

   This assertion needs some clarification. The size of IV is generally variable, 8 or 16 octets
    are relevant only for the currently defined transforms. I suggest to rephrase this sentence:

	IPsec ESP sends an initialization vector (IV) or nonce in each packet. The size of IV 
	depends on the applied transform, being usually 8 or 16 octets for the transforms
	defined by the time this document is written.

(or something like that)

2. IANA Considerations

	AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
	implement the implicit IV described in this document.  This section
	limits assignment of new code points to the recommended suites
	provided in [I-D.ietf-ipsecme-rfc4307bis] and
	[I-D.ietf-ipsecme-rfc7321bis], thus the new Transform Type 1 -
	Encryption Algorithm Transform IDs are as defined below:

    The newly defined IIV transforms are not applicable for IKEv2 (because there is no unique per message field;
    Message ID do can repeat, e.g. in case RFC6311 or RFC7383 is used). So, [I-D.ietf-ipsecme-rfc7321bis]
    (now RFC8247) must not be referenced here. Moreover, I'd like to express this prohibition 
    more explicitly in IANA registry, instructing IANA to put "Not allowed" in the column "IKEv2 Reference"
    for these transforms:
    
	AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
	implement the implicit IV described in this document.  This section
	limits assignment of new code points to the recommended suites
	provided in [I-D.ietf-ipsecme-rfc4307bis]. Note, that using implicit IV for these
	algorithms is defined for ESP only and is not allowed for protecting
	IKEv2 messages.

	IANA is requested to add the following transforms to the Transform Type 1 -
	Encryption Algorithm Transform IDs registry for IKEv2, setting "ESP Reference"
	to this document and marking "IKEv2 Reference" as "Not allowed":

3. Please, update references: 
	[I-D.ietf-ipsecme-rfc7321bis] is now RFC8221
	[I-D.yeung-g-ikev2] is now draft-yeung-g-ikev2-12

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 30 Oct 2017 15:28:43 +0300

>     Message ID do can repeat, e.g. in case RFC6311 or RFC7383 is used). So, [I-D.ietf-ipsecme-rfc7321bis]

[I-D.ietf-ipsecme-rfc4307bis] of course.

>     more explicitly in IANA registry, instructing IANA to put "Not allowed" in the column "IKEv2 Reference"

So, the correct text is:
 
	provided in [I-D.ietf-ipsecme-rfc7321bis]. Note, that using implicit IV for these

Regards,
Valery.