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

[tom petch <[e-mail]>]

On 31/10/2020 14:01, 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?

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!

What would you advise?

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