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

On 05/11/2020 15:33, Valery Smyslov wrote:
> 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...


Valery

Thank you for your thoughts on this.  As you will know, the IESG are now 
commenting on this I-D and my experience is that, once that has started, 
then that takes over the discussion so having got the topic aired, 
albeit not necessarily to a conclusion incorporated in the I-D, I will 
leave it up to the IESG to decide what should or should not be included 
in the YANG module.  I will keep the outcome of this discussion in my 
mind as and when the topic comes up again.  As you may gather, I follow 
the TLS WG and so am familiar with the approach that it has taken 
(likewise that of SSH) but do not track the work on IKEv2 - I did not 
even know which WG was responsible for it:-(

Tom Petch

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