Sorry, I made a typo (see below):
> 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]
[I-D.ietf-ipsecme-rfc4307bis] of course.
> (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:
So, the correct text is:
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-rfc7321bis]. 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":
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
