Subject: [IPsec] IANA IKEv2 parameters, encryption type=17

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Sep 2017 14:40:16 -0400

Why did we skip
    IKEv2_UNASSIGNED_17   = 17,

for IKEv2 Encryption Transforms?
  https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 Sep 2017 04:32:43 +0300

>   https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5

The original draft-ietf-ipsec-ciph-aes-gcm [1] had four differnet ICV
lengths: 4, 8, 12, and 16 octets, and they got numbers for all of them
[2]:

----------------------------------------------------------------------
   IANA has assigned four ESP Transform Identifiers for AES-GCM with
   an eight-byte explicit IV:

      <TBD1> for AES-GCM with a 4 octet ICV;
      <TBD2> for AES-GCM with an 8 octet ICV;
      <TBD3> for AES-GCM with a 12 octet ICV; and
      <TBD4> for AES-GCM with a 16 octet ICV.
----------------------------------------------------------------------

Then after the IESG approval the 4 octet ICV was removed from the RFC
4106 (most likely it was considered unsafe and too short), but IANA
had most likely already given out the numbers, thus the final numbers
for 8, 12, 16 octet versions came to be 18, 19, and 20, and the number
17 which was most likely allocated for the 4 octet ICV was marked as
reserved.

[1] https://tools.ietf.org/html/draft-ietf-ipsec-ciph-aes-gcm-00
[2] https://www.ietf.org/mail-archive/web/ipsec/current/msg01012.html
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Sep 2017 23:17:50 -0400 (EDT)

> lengths: 4, 8, 12, and 16 octets, and they got numbers for all of them

Ahh, so that's where it came from :)

> 17 which was most likely allocated for the 4 octet ICV was marked as

Except it is marked unassigned, not reserved. So one could use this
number in the future. I for sure have never seen it in the wild on
the wire or in source code. And if it is too weak, I guess we don't
mind breaking implementations who mistakenly still support it :)

Paul