|Main Archive Page > Month Archives > ipsec archives|
This took a bit longer than expected, but the IKEv1 transform IDs have now been allocated by IANA, and they're listed in errata for RFC 4543:
(Big thanks to Tero for his help with the details!)
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org] On Behalf
> Of Eronen Pasi (Nokia-NRC/Helsinki)
> Sent: 30 April, 2009 12:28
> To: email@example.com
> Subject: [IPsec] Transform IDs for AES-GMAC in IKEv1
> RFC 4543 specifies how to use AES-GMAC mode in AH and ESP and how to
> negotiate them in IKEv1 and IKEv2 (see Section 5, 1st paragraph).
> However, as Soo-Fei Chew pointed out, the IANA considerations text in
> the final document didn't actually ask IANA to assign the numbers for
> Here's my proposal for fixing the situation:
> (1) ask IANA to assign the four missing numbers (after IESG approval).
> (2) submit an RFC Editor errata, saying something like this:
> The following text should have been included in Section 9:
> For the negotiation of AES-GMAC in AH with IKEv1, the following
> values have been assigned in the IPsec AH Transform Identifiers
> registry (in isakmp-registry). Note that IKEv1 and IKEv2 use
> different transform identifiers.
> "TBD1" for AH_AES_128_GMAC
> "TBD2" for AH_AES_192_GMAC
> "TBD3" for AH_AES_256_GMAC
> For the negotiation of AES-GMAC in ESP with IKEv1, the following
> value has been assigned from the IPsec ESP Transform Identifiers
> registry (in isakmp-registry). Note that IKEv1 and IKEv2 use a
> different transform identifier.
> "TBD4" for ESP_NULL_AUTH_AES_GMAC
> (where we will in TBD1..4 after we know the numbers)
> (3) ask IANA to include a pointer to this errata in the isakmp-registry
> Does this sound like a reasonable plan?
> Best regards,
> IPsec mailing list