Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
> On 31 Oct 2020, at 15:12, tom petch wrote: > > On 30/10/2020 22:42, Tero Kivinen wrote: >> 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. > > > Tero > > Thanks for getting back to me. What is missing from the IANA registry is the > guidance as to the status of the algorithm, how highly it is recommended or > not. This I-D tells people to go to RFC8247 and the IANA Registry for > advice; RFC8247 gives that advice; the IANA web page does not. It’s possible to add a column in the IANA registry, but it is not possible to capture the information from 8247 in such a table. RFC 8247 has “MAY” and “SHOULD+” labels, but it also has comments and a bunch of explanation, such as that some algorithm is a SHOULD for IoT, but not otherwise. I think it’s better to point people at the RFC where the information is, rather than post very partial information in an IANA table. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [I2nsf] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
Hi Tom, we discussed with the chairs the usefulness of adding "Recommended/Not recommended" column (as TLS WG did) into the IKEv2 algorithm registries back in 2018 in Bangkok and I was one who of those who initially suggested this. However, Tero made a very good point that IANA doesn't have any public history. So, in the ipsecme WG another approach was taken - we have RFCs that say which algorithms are recommended/not recommended for ESP and for IKEv2 and these RFCs are updated periodically. > Thanks for getting back to me. What is missing from the IANA registry > is the guidance as to the status of the algorithm, how highly it is > recommended or not. This I-D tells people to go to RFC8247 and the IANA > Registry for advice; RFC8247 gives that advice; the IANA web page does not. As Tero said, the IANA web page references current RFCs (8221 & 8247 at the moment) that list recommended algorithms. Just one more level of indirection. All algorithms that are not listed in these RFC are treated as "not recommended" by default, including newly added algorithms. > And RFC8247 specifies which algorithm are AEAD, the web page does not. > The YANG module behaves differently depending on whether or not the > algorithm is AEAD; YANG implementors need to know, having this > information on the web page would make it easier for YANG implementors. Is is a problem to open corresponding RFC or I-D? Or do you want to say that YANG implementers don't need any other information about algorithms except whether it's AEAD and whether it's recommended? Regards, Valery Smyslov. > And RFC8247 specifies IoT, which I do not think is yet a consideration here. > > As I said, we are currently ok but as new algorithms get added, by > Expert Review, then that information is needed and may not be available > as there is no requirement for the Expert Reviewer to make it available. > > As I said to Roman, the TLS WG found that they needed to add extra > columns to their web pages of algorithms. Different columns (e.g. DTLS > not AEAD) but I think that the situation is otherwise identical so I am > anticipating that in a year or two you will see what I mean:-). In > passing, the TLS WG determine by consensus what the status is for a new > algorithm but the Expert Reviewer makes it available via the web site > whether or not it is in an RFC. > > I take your point about duplicating data - no relational databases here! > - but the answer is to specify which is authoritative and for me that > should be the IANA pages as it is for many assignments in the context of > YANG and before that SMI going back decades. > > Tom Petch > > > 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
Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
On 30/10/2020 22:42, Tero Kivinen wrote:
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.
Tero
Thanks for getting back to me. What is missing from the IANA registry
is the guidance as to the status of the algorithm, how highly it is
recommended or not. This I-D tells people to go to RFC8247 and the IANA
Registry for advice; RFC8247 gives that advice; the IANA web page does not.
And RFC8247 specifies which algorithm are AEAD, the web page does not.
The YANG module behaves differently depending on whether or not the
algorithm is AEAD; YANG implementors need to know, having this
information on the web page would make it easier for YANG implementors.
And RFC8247 specifies IoT, which I do not think is yet a consideration here.
As I said, we are currently ok but as new algorithms get added, by
Expert Review, then that information is needed and may not be available
as there is no requirement for the Expert Reviewer to make it available.
As I said to Roman, the TLS WG found that they needed to add extra
columns to their web pages of algorithms. Different columns (e.g. DTLS
not AEAD) but I think that the situation is otherwise identical so I am
anticipating that in a year or two you will see what I mean:-). In
passing, the TLS WG determine by consensus what the status is for a new
algorithm but the Expert Reviewer makes it available via the web site
whether or not it is in an RFC.
I take your point about duplicating data - no relational databases here!
- but the answer is to specify which is authoritative and for me that
should be the IANA pages as it is for many assignments in the context of
YANG and before that SMI going back decades.
Tom Petch
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
