Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt

Hi Tero!

> -----Original Message-----
> From: IPsec <[email protected]> On Behalf Of Tero Kivinen
> Sent: Friday, October 30, 2020 6:42 PM
> To: Roman Danyliw <[email protected]>
> Cc: Fernando Pereniguez-Garcia <[email protected]>;
> [email protected]; Gabriel Lopez <[email protected]>; [email protected];
> [email protected]; [email protected]; Rafa Marin-Lopez <[email protected]>; tom petch
> <daedulus-6b45v/[email protected]>
> 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.
> --
> [email protected]
> 
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec