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. 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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
