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

From: Paul Wouters <[email-masked]>
Date: Mon, 2 Nov 2020 09:22:12 -0500 (EST)

On Sat, 31 Oct 2020, Yoav Nir wrote:

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

We do have a draft that is suggesting we add some tables :P

https://tools.ietf.org/html/draft-pwouters-ikev1-ipsec-graveyard

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 2 Nov 2020 20:34:18 +0200

tom petch writes:
> And RFC8247 specifies which algorithm are AEAD, the web page does not. 

Actually RFC8247 does not specify which algorithms are AEAD. It only
specifies that information for those algorithms it lists. For example
it does not mention ENCR_AES_CCM_16 at all, thus it does not list
whether it is AEAD algorithm or 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.

I can see some benefits for having the "AEAD?" column added to the
IANA registry, as there are differences how things are processed
depending whether the algorithm is AEAD or not. Currently the only way
to find whether the algorithm is AEAD is to read the RFC describing
the algorithm.

Also as that information is static, meaning it will not change over
time (compared to the recommendation levels which do change every time
we make new version of Algorithm Implementation Requirements and Usage
Guidance document), there is no problem for not having history
available, or having conflicting information in different places
(RFC vs IANA page).

On the other other hand we would problably need three values for that
column, one would be AEAD, another would non-AEAD and one would be
MAC-only.

The ENCR_NULL_AUTH_AES_GMAC, ENCR_KUZNYECHIK_MGM_MAC_KTREE and
ENCR_MAGMA_MGM_MAC_KTREE are not really an AEAD algorithms as they do
not encrypt anything but just put everything in the AAD of AEAD
structure. 

> 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 

TLS do have bit more entries in its registry, mostly because they
combine everything to one suite, meaning instead of adding separate
algorithms, they usually add multiple combinations of algorithms as
different suites, and when there started to be hundreds of those,
maintaining that list got bit annoying and especially to know which
one of them are something that implementations should implement.

I think our a la carte method is better as it limits the the number of
algorithms we are going to have, although the number of combinations
that can be negotiated is much higher...

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

I would always consider the published RFC as more authorative than
IANA pages, as IANA pages are updated by writing RFCs, and there have
been mistakes and there will be mistakes when extracting that data
from RFCs to IANA registry.

RFCs (or other published standard documents) do have some kind of
process to verify that the information is approved by the SDO, meaning
lots of people do check them. IANA registries are then extracted by
hand by people from those documents and only checked by handful of
people before published.

Usually IANA do want us to make an RFC to modify the registry, like we
did add RFC8247 where we renamed 6 old algorithms so that the naming
is more consistent (rename AES-GCM with a 8 octet ICV to
ENCR_AES_GCM_8 etc).

But not always. For example RFC4309 asks IANA to add "AES CCM with an
{8,12,16}-octet ICV" and what I think IANA did was to add
ENCR_AES-CCM_8 (underline, dash, underline), ENCR-AES-CCM_12 (dash,
dash, underline), ENCR-AES-CCM_16 (dash, dash, underline) to registry,
without consulting anybody, and which we then noticed 4 years later
[1].

I think we managed to fix that dash -> underline error, by just going
to the IANA desk in IETF and they did the change immediately, but for
the more substanial changes they wanted us to make an RFC that did
those changes. Thats why the RFC8247 has those quite unrelated
renaming things in it...

[1] https://mailarchive.ietf.org/arch/msg/ipsec/VmlenjxLKjWhldztreN5p9I3yP0/
-- 
[email-masked]

---

From: tom petch <[email-masked]>
Date: Tue, 3 Nov 2020 12:03:21 +0000

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Nov 2020 22:07:42 +0200

tom petch writes:
> that RFC is very clear - for up-to-date information go to IANA.

Not exactly. RFC7296 says:
----------------------------------------------------------------------
	.... Readers should refer to [IKEV2IANA] for the latest
   values.
----------------------------------------------------------------------
meaning it says that the tables in RFC7296 might not be complete, as
there are more values allocated by IANA than what is in there, and to
get complete list of values in each table, you need to go to the IANA
registry.

Then in section "3.3.4. Mandatory Transform IDs" it says:

----------------------------------------------------------------------
   The specification of suites that MUST and SHOULD be supported for
   interoperability has been removed from this document because they are
   likely to change more rapidly than this document evolves.  At the
   time of publication of this document, [RFC4307] specifies these
   suites, but note that it might be updated in the future, and other
   RFCs might specify different sets of suites.
----------------------------------------------------------------------

Which points us to RFC4307 which was obsoleted by the RFC 8247 which
is the latest version of that document.

So RFC7296 is quite clear that you go in different places to find the
list of numbers (IANA) and to find which algorithms are mandatory to
implement.

> The RFC that update RFC7296 do not appear to update that advice.

RFC 8247 was actually marked as Updating 7296, so anybody reading 7296
will find that version too, even without going through RFC4307. 

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

The IANA contains the tables that maps the numbers used in the IKEv2
to the names and references where they are specified. As others have
pointed out, some of those algorithms are not recommended all the
time, but only for specific use cases and or for specific key lengths,
like ENCR_AES_CBC, where RFC8247 has text like this:

   ENCR_AES_CBC is raised from SHOULD+ for 128-bit keys and MAY for
   256-bit keys in [RFC4307] to MUST. 192-bit keys remain at the MAY
   level.  ENCR_AES_CBC is the only shared mandatory-to-implement
   algorithm with RFC 4307 and as a result, it is necessary for
   interoperability with IKEv2 implementation compatible with RFC 4307.

or ENCR_AES_CCM_8:

   ENCR_AES_CCM_8 was not considered in RFC 4307.  This document
   considers it as SHOULD be implemented in order to be able to interact
   with IoT devices.  As this case is not a general use case for non-IoT
   VPNs, its status is expected to remain as SHOULD.  The 8-octet size
   of the ICV is expected to be sufficient for most use cases of IKEv2,
   as far less packets are exchanged in those cases, and IoT devices
   want to make packets as small as possible.  The SHOULD level is for
   128-bit keys, 256-bit keys remains at MAY level.

To explain this kind of things in the IANA registry would get quite a
lot of more columns....

> track the IETF WG that updates information on IKEv2 ie like me)?

It should use IANA registry for the mapping between numbers,
algorithms and references; and then for algoritm implementation
requirements and usage guidance it should point to RFC8247 for IKEv2,
and to RFC8221 for ESP.

> is that your best advice?

Yes.

> least qualify them with some statement that they need to check the RFC 

You always need to check the RFC of the current information if you are
planning to implement any of the algorithms. 
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 5 Nov 2020 18:33:19 +0300

Hi Tom,

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

> least qualify them with some statement that they need to check the RFC

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.

---

From: tom petch <[email-masked]>
Date: Sat, 7 Nov 2020 12:16:15 +0000

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

> .