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

[Valery Smyslov <[e-mail]>]

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?
> 
> Valery
> 
> 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.  The RFC
> that update RFC7296 do not appear to update that advice.  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:-)
> 
> 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)?
> Currently that is both a reference to the IANA registry and to an RFC;
> is that your best advice?

I believe a reference to IANA suffices. Note, that IANA algorithms registries have 
notes referencing RFCs with up-to-date information about algorithms status.
E.g. for encryption algorithms the following note appears in the registry:

    Note
	To find out requirement levels for encryption algorithms for
	ESP, see [RFC8221]. For IKEv2, see [RFC8247].

> 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!

IANA website has already contained this statement and references the most recent 
RFCs for IKEv2 and for ESP containing algorithms requirement levels.

> What would you advise?

As I've already said, I believe sole reference to IANA webpage is enough 
for careful reader, because IANA has notes mentioned above with 
references to up-to-date RFCs describing current algorithms status.
However, I think that referencing both RFCs and IANA in the I-D won't hurt anyway.

Whether algorithms are AEAD or not is different thing. Currently this information
is missing on the IANA webpage, so one must look into the each algorithm
specification to learn it...

Regards,
Valery.

> Tom Petch
> 
> >
> > 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
> >>