Hi Tero! > -----Original Message----- > From: IPsec <ipsec-bounces@xxxxxxxx> On Behalf Of Tero Kivinen > Sent: Friday, October 30, 2020 6:42 PM > To: Roman Danyliw <rdd@xxxxxxxx> > Cc: Fernando Pereniguez-Garcia <fernando.pereniguez@xxxxxxxxxxx>; > i2nsf@xxxxxxxx; Gabriel Lopez <gabilm@xxxxx>; ynir.ietf@xxxxxxxxx; > ipsec@xxxxxxxx; last-call@xxxxxxxx; Rafa Marin-Lopez <rafa@xxxxx>; tom petch > <daedulus@xxxxxxxxxxxxx> > Subject: Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn- > ipsec-flow-protection-11.txt > > Roman Danyliw writes: > > > >> It seems to me that the IANA entries for IKEv2 are incomplete. > > > >> RFC8247 does a fine job of specifying algorithms and adding > > > >> information such as status (MUST/SHOULD+), IoT, AEAD and so on, > > > >> information which is not present on IANA. The policy for, e.g. > > > >> Transform Type 1, is expert review and entries have been added > > > >> via draft-smyslov-esp-gont but the IANA entries lack this > > > >> information and, looking at the I-D, I see no such information > > > >> (nor is there any reason for it to be there). Yet > > > >> draft-ietf-i2nsf-sdn... needs this information as references in the YANG > module show. > > I am lost what information is missing from the IANA registry. Thanks for the analysis and feedback. I think the deep threading may have confused who said what. The above snip and all of the snips below are from Tom's assessment of the IANA registry situation (https://mailarchive.ietf.org/arch/msg/last-call/Cg66LRwtJjhJ5zNe8AEBWqKDll0/ and https://mailarchive.ietf.org/arch/msg/last-call/MMO9NsRif_x1WkGbJFlgKiLOGYQ/) My feedback in the earlier in the part of the thread (https://mailarchive.ietf.org/arch/msg/last-call/vSU21Yqbczthq9Uii0N0roHQI7c/) was that RFC8247 is cited by draft-ietf-i2nsf-sdn-ipsec-flow-protection to describe implementation requirements (as represented in the YANG module) and that no IANA changes should be needed. In a follow-on messages (https://mailarchive.ietf.org/arch/msg/last-call/7eC7LH9_EWHxkA22YbST6Ghc4tc/) which added ipsec@ietf, I was noting that IPSecme is the WG with expertise and scope that is best positioned to discuss management of the IKE registries Regards, Roman > The registry do > include numbers from draft-smyslov-esp-gost document. The > RFC8247 says: > ---------------------------------------------------------------------- > 1.3. Updating Algorithm Requirement Levels ... > .... As a result, any algorithm listed at the IKEv2 > IANA registry not mentioned in this document MAY be implemented. > ---------------------------------------------------------------------- > I.e., all algorithms not listed there are MAY to implement. > > But I do not see any reason why the yang module should provide any other > than pointer to the IANA registry, and the IANA registry already has pointer to > the RFC8247 to indicate the requirement levels for algorithms. > > > > >> It seems to me that this is a similar situation to that which the > > > >> TLS WG found itself in and which led to a revision of the TLS > > > >> IANA entries to provide what was needed via additional columns. > > There was some requests to modify the IANA registry while we were publishing > RFC 8247 and the WG decided against it, and instead decided to provide > pointer to the RFC 8211 and RFC 8247 in the notes section. > > The reason for that is that duplicating information always causes problems, and > because there is no (public) history of the IANA registries, there is no way of > finding out when and why specific change to the registry was done unless there > happens to be RFC that actually did that change. > > I myself as an IANA expert of those registries do think it is better that working > group will do RFC that will update the levels, and that will leave audit trail and > public working group mailing list discussion about the changes. > > > > >> I think that the IANA pages for IKEv2 need revising so that that > > > >> additional information that RFC8247 provides is required as > > > >> additional columns in the IANA entries at least for Type 1, Type > > > >> 2, Type 3, Type 4 and Authentication Method. > > I fail to see why does that information need to be in the IANA registry? This is > YANG model for IPsec, it should just refer to the IANA registry about the > mapping from algorithms to numbers and other way around, but whether the > algorithm is recommended or not, does not belong to the YANG model, as that > is not something that can be modified by configuration or be part of running > state. > > This document seems to have wierd text in it: > > typedef encryption-algorithm-type { > type uint16; > description > "The encryption algorithm is specified with a 16-bit > number extracted from IANA Registry. The acceptable > values MUST follow the requirement levels for > encryption algorithms for ESP and IKEv2."; > > I do not see what the last sentence of the text is trying to say? Does it mean > that this yang model cannot be shown of running configuration where someone > is using one the algorithms not considered safe anymore? > In ietf we usually just try to say what implementors are implementing, we do > not that often limit what adminstrators can configure. If the implementation > happens to implement one of those weak ciphers for example for talking to one > obsoleted old hardware that only supports them, then I do not see why this > yang model should forbid showing running status of such configuration. > > I think this document should just say that the algorithm numbers are from the > IANA registry, and nothing more. There might be informal reference to the RFC > 8221, and RFC 8247 but even that should not be needed, as anybody > implementing IKEv2 or ESP will already follow those and only implement the > algorithms from there that they seem proper. In some cases that selection > might include algorithms which are on SHOULD NOT or even MUST NOT, if the > backward compatibility to obsolete hardware is more important than > conformance. > > > > This I-D, as you quote, points to RFC8247 for guidance and that is > > > fine. But security moves on and new algorithms will be needed and > > > this I-D also points to the IANA registry, which is Expert Review, > > > where new entries have been added already; and for those the IANA > > > Registry gives no guidance and the I-D that IANA references for the > > > new entries - written by the Expert Reviewer! - also gives no > > > guidance. Over time we are likely to accrue algorithms with no > > > guidance unless and until an RFC8247-bis appears or we require IANA > > > to have columns for guidance. Currently the new algorithms are GOST > > > and so perhaps of limited interest but on the TLS list I am always > > > seeing new algorithms appear and there the new IANA entry is > > > required to give guidance. My sense is that IKEv2 is a bit slower to > > > take up new ones but, as with RFC8247, it does eventually. > > The original cryptographic algorithm impelemtation requirements for ESP and > AH was published as RFC4305 in 2007. It was replaced with > RFC7321 in 2014, and that was replaced with RFC8221 in 2017. For IKEv2 we > skipped the 2014 update, as that was not needed. We do have plans to keep > that draft up to date, and update it when there is need for that, most likely in > next 5 years or so, provided that implementation status of some of new > algorithms progresses favorably. > > > > I think that users need those extra columns that RFC8247 provides on > > > the IANA website so that when new algorithms are added by Expert > > > Review, then that guidance must be added as well. This is what the > > > TLS WG came round to and I think that IKEv2 needs to do the same. > > I as an Expert does not want to decide whether the individual request to add > new 3rot13 cipher to the IANA registry should be MUST NOT, SHOULD NOT, > MAY or what. If the field is in the IANA registry then whoever requests to add > information to there can request whatever value they want for that field too. > Of course as an IANA expert I can reject that by saying that 3rot13 is not MUST, > but it is MUST NOT algorithm, and then we can have discussion about that. > > I rather have that discussion in the working group when we are updating the > requirements document next time. And as I said IANA registries do not have > any (public) history, or any way of finding out why they got changed and who > did the change. There has happened some changes in the registry where I as an > IANA Expert was not aware of at all... > > And if I need to find out when ENCR_MAGMA_MGM_KTREE was added or > when some of those earlier algorithms was renamed, I need to go to my private > mail archives. > -- > kivinen@xxxxxx > > _______________________________________________ > IPsec mailing list > IPsec@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ipsec -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
