Hi,
> 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
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.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
