In early 2009 there was discussion in the IPsec list that the RFC4543 was supposed to allocate numbers also for IKEv1, not only for IKEv2. There was some discussion on the list and then there was errata 1821 was submitted to the RFC4543 which said those numbers should also be allocated for the IKEv1 IANA registry. At that point we didn't really realize that ESPv2 which is implied by using IKEv1 does not support combined mode ciphers.
In the end of 2009 we started to discuss about the IPsec roadmap document, and then this item came out again. We had open ticket #111 (http://tools.ietf.org/wg/ipsecme/trac/ticket/111) about the issue and the final wording in the roadmap (now RFC6071) document was: ---------------------------------------------------------------------- 5.4. Combined Mode Algorithms IKEv1 and ESP-v2 use separate algorithms to provide encryption and integrity protection, and IKEv1 can negotiate different combinations of algorithms for different SAs. In ESP-v3, a new class of algorithms was introduced, in which a single algorithm can provide both encryption and integrity protection. [RFC5996] describes how IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to negotiate and use combined mode algorithms for its own traffic. When properly designed, these algorithms can provide increased efficiency in both implementation and execution. Although ESP-v2 did not originally include combined mode algorithms, some IKEv1 implementations have added the capability to negotiate combined mode algorithms for use in IPsec SAs; these implementations do not include the capability to use combined mode algorithms to protect IKE SAs. IANA numbers for combined mode algorithms have been added to the IKEv1 registry. 5.4.1. RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) (S, December 2005) ... Requirement levels for AES-CCM: IKEv1 - N/A IKEv2 - optional ESP-v2 - N/A ESP-v3 - optional [RFC4835] NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. 5.4.2. RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) (S, June 2005) ... Requirement levels for AES-GCM: IKEv1 - N/A IKEv2 - optional ESP-v2 - N/A ESP-v3 - optional [RFC4835] NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. 5.4.3. RFC 4543, The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH (S, May 2006) ... Requirement levels for AES-GMAC: IKEv1 - N/A IKEv2 - N/A IPsec-v2 - N/A IPsec-v3 - optional NOTE: The IPsec-v2 IANA registry includes values for AES-GMAC, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. ---------------------------------------------------------------------- Listing all those combined ciphers as N/A for IPsec-v2. As I think the RFC6071 do reflect the concensus of the IPsecME workgroup, and because of this I think we should fix the IANA allocations for the combined mode ciphers (this includes AES-CCM (RFC4835), AES-GCM (RFC4835) and AES-GMAC (RFC4543)) and change them to be RESERVED and add note that they are not really part of IKEv1 protocol. This whole issue comes mostly because there is no version number in the ESP, meaning only way to know whether ESPv2 or ESPv3 is used is by implying that from whether IKEv1 or IKEv2 was used (which do have version numbers). This affects following IANA entries in the isakmp-registry (http://www.iana.org/assignments/isakmp-registry): ---------------------------------------------------------------------- IPSEC ESP Transform Identifiers =============================== Transform ID Value Reference ------------ ----- --------- ESP_AES-CCM_8 14 [RFC4309] ESP_AES-CCM_12 15 [RFC4309] ESP_AES-CCM_16 16 [RFC4309] ESP_AES-GCM_8 18 [RFC4106] ESP_AES-GCM_12 19 [RFC4106] ESP_AES-GCM_16 20 [RFC4106] ESP_NULL_AUTH_AES-GMAC 23 [RFC4543][Errata1821] IPSEC AH Transform Identifiers ============================== Transform ID Value Reference ------------ ----- --------- AH_AES-128-GMAC 11 [RFC4543][Errata1821] AH_AES-192-GMAC 12 [RFC4543][Errata1821] AH_AES-256-GMAC 13 [RFC4543][Errata1821] IPSEC Security Association Attributes ===================================== Authentication Algorithm Name Value Reference ---- ----- --------- AES-128-GMAC 11 [RFC4543][Errata1821] AES-192-GMAC 12 [RFC4543][Errata1821] AES-256-GMAC 13 [RFC4543][Errata1821] ---------------------------------------------------------------------- I am not really sure what should be done for the AH transform identifiers, as I think the AH_AES-*-GMAC can actually be used without problems in the IPsec-v2 AH, but I am not sure. We have few options: 1) Leave things as they are as this is only for obsoleted protocol that nobody uses... Unfortunately there are still people using this obsoleted protocol and if the numbers are there in the IANA registry as they are now, some implementors might think they can actually implement and then they do end up mixed mode version of IPsec-v2 and IPsec-v3. 2) Change all those entries to be "RESERVED (was xxx)" and add note saying that they are not really a feature of IPsec-v2 and even when there is implementations using them that is not standard way to do it. If those algorithms is needed then ESPv3 (and IKEv2, and RFC4301 architecture) is needed. 3) Change ESP entries to "RESERVED (was xxx)" and add similar note than in 2, but leave AH entries intact. I think the option 2 is the best, i.e clearly mark them that you should not do this, but if you see these numbers you do know that it is some implementation using some wierd mixed IPsec-v2 / v3 feature set. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
