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

[Tero Kivinen <[e-mail]>]

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/
-- 
[e-mail]