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

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

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

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.

> Currently that is both a reference to the IANA registry and to an RFC; 
> is that your best advice?

Yes.

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

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