tom petch writes: > The problem I see is where to direct readers of the i2nsf-sdn to for > more information, about which algorithms are recommended, or not, and, a > secondary consideration, whether they are AEAD or not, since the latter > affects the YANG module. The I-D has lots of references to RFC7296 and > that RFC is very clear - for up-to-date information go to IANA. Not exactly. RFC7296 says: ---------------------------------------------------------------------- .... Readers should refer to [IKEV2IANA] for the latest values. ---------------------------------------------------------------------- meaning it says that the tables in RFC7296 might not be complete, as there are more values allocated by IANA than what is in there, and to get complete list of values in each table, you need to go to the IANA registry. Then in section "3.3.4. Mandatory Transform IDs" it says: ---------------------------------------------------------------------- The specification of suites that MUST and SHOULD be supported for interoperability has been removed from this document because they are likely to change more rapidly than this document evolves. At the time of publication of this document, [RFC4307] specifies these suites, but note that it might be updated in the future, and other RFCs might specify different sets of suites. ---------------------------------------------------------------------- Which points us to RFC4307 which was obsoleted by the RFC 8247 which is the latest version of that document. So RFC7296 is quite clear that you go in different places to find the list of numbers (IANA) and to find which algorithms are mandatory to implement. > The RFC that update RFC7296 do not appear to update that advice. RFC 8247 was actually marked as Updating 7296, so anybody reading 7296 will find that version too, even without going through RFC4307. > And the i2nsf I-D also contains references to IANA often alongside a > reference to an RFC. You seem to be saying that IANA is only a good > reference if it points to an RFC that says so which may not match > the expectations of users (particularly those who are familiar with > the approach of the TLS WG). If they are pointed to IANA they may > well expect IANA to be the best source of information but you seem > to be saying that the WG decided not to support that, rather > expecting people to read the RFC. If IANA said 'use this to find the > RFC but do not otherwise trust this information' that would be fine, > well in a manner of speaking:-) The IANA contains the tables that maps the numbers used in the IKEv2 to the names and references where they are specified. As others have pointed out, some of those algorithms are not recommended all the time, but only for specific use cases and or for specific key lengths, like ENCR_AES_CBC, where RFC8247 has text like this: ENCR_AES_CBC is raised from SHOULD+ for 128-bit keys and MAY for 256-bit keys in [RFC4307] to MUST. 192-bit keys remain at the MAY level. ENCR_AES_CBC is the only shared mandatory-to-implement algorithm with RFC 4307 and as a result, it is necessary for interoperability with IKEv2 implementation compatible with RFC 4307. or ENCR_AES_CCM_8: ENCR_AES_CCM_8 was not considered in RFC 4307. This document considers it as SHOULD be implemented in order to be able to interact with IoT devices. As this case is not a general use case for non-IoT VPNs, its status is expected to remain as SHOULD. The 8-octet size of the ICV is expected to be sufficient for most use cases of IKEv2, as far less packets are exchanged in those cases, and IoT devices want to make packets as small as possible. The SHOULD level is for 128-bit keys, 256-bit keys remains at MAY level. To explain this kind of things in the IANA registry would get quite a lot of more columns.... > So, question. What references should draft i2nsf-sdn point readers to > for up-to-date information on algorithms (assuming that they do not > track the IETF WG that updates information on IKEv2 ie like me)? It should use IANA registry for the mapping between numbers, algorithms and references; and then for algoritm implementation requirements and usage guidance it should point to RFC8247 for IKEv2, and to RFC8221 for ESP. > Currently that is both a reference to the IANA registry and to an RFC; > is that your best advice? Yes. > Were I an author of this I-D, as opposed to a reader thereof, then based > on what you say I would remove references to the IANA website or at > least qualify them with some statement that they need to check the RFC > for current information! You always need to check the RFC of the current information if you are planning to implement any of the algorithms. -- kivinen@xxxxxx -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
