Paul Wouters writes: > > Recently we had a discussion about mapping IANA entries to a yang model, > and the question came up whether we sould add a deprecated marker to the > IKE/ESP registries for algorithms. > > I thought it was a good idea, but not everyone agreed. > > I just stumbled upon RFC 7696: Guidelines for Cryptographic Algorithm Agility > and Selecting Mandatory-to-Implement Algorithms > > > Section 2.1: Algorithm Identifiers > > In the IPsec protocol suite, the Internet Key Exchange Protocol > version 2 (IKEv2) [RFC7296] carries the algorithm identifiers for the > Authentication Header (AH) [RFC4302] and the Encapsulating Security > Payload (ESP) [RFC4303]. Such separation is a completely fine design > choice. [...] > > An IANA registry SHOULD be used for these algorithm or suite > identifiers. Once an algorithm identifier is added to the registry, > it should not be changed or removed. However, it is desirable to > mark a registry entry as deprecated when implementation is no longer > advisable. > > So there is even an RFC stating that we should really do this :) > > I guess the main question is, can we add these via a request to IANA > based on RFC 8221 and 8247, or do we need to write a short RFC with > requests to IANA?
Mostly you would need to convince me as an IANA expert to do that, and I do think it is wrong place to store that information and will make registry confusing and messy, so I do not want to do it. If (when?) you fail to do that then you would need to write draft and try to get WG consensus on that (and then David would take care of that draft). The problem is that to be really usuful we would need to include similar text we already have in RFC8247 for example, i.e., explain where ENCR_AES_CCM_8 is useful and why it is SHOULD for some environments, but not SHOULD for others etc. I still think adding notes (as I explained in my other email sent few minutes ago) is better option, and I plan to do that regardless... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
