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

From: tom petch <[email-masked]>
Date: Mon, 2 Nov 2020 12:06:57 +0000

Rafa

As you may know, the submission window closes in the week before the 
IETF meeting which is perhaps why over 150 new I-D have just appeared:-( 
which may or may not affect your plans. I expect to look some more this 
week but the country is going into lockdown for four weeks, some are 
saying for six months, so I need to work out what I have to get done 
before all the places I need to go shut:-(  Some things pre-empt IETF work!

On the formatting, my hope was that the paragraphs of text as in YANG 
description would spread out to occupy fewer lines, so fixing the 
indentation is an improvement but not quite all I had hoped for - it 
certainly makes it easier to read.  I would not reissue a new version 
just for this

And inline twice

On 30/10/2020 17:43, Rafa Marin-Lopez wrote:
> Hi Tom:
>
> Thank you very much again. See our comments inline:
>
>> El 29 oct 2020, a las 18:06, tom petch <[email-masked]> escribió:
>>
>> Back to routine comments on this I-D; I don't think that any of my earlier ones are unresolved.
>>
>> On 29/10/2020 11:23, Rafa Marin-Lopez wrote:
>>> Hi Tom:
>>>
>>>> El 28 oct 2020, a las 19:02, tom petch <[email-masked]> escribió:
>>>>
>>>> On 28/10/2020 10:42, Rafa Marin-Lopez wrote:
>>>>> Hi Tom:
>>>>>
>>>>> Thank you very much for your insight. It is very helpful. Please see our comments/questions inline.
>>>>>
>>>>>> El 27 oct 2020, a las 13:42, tom petch <[email-masked]> escribió:
>>>>>>
>>>>>> I think that the IESG will find a number of problems with this I-D.
>>>>>>
>>>>>> YANG module references RFC822 which is several years out of date
>>
>> Rafa
>>
>> Several YANG leaf are in seconds, eight I think, but none use the YANG
>> units seconds;
>> statement.  I suggest adding it.
>
> Added. They are seven.

I still see eight - the one that lacks units is
leaf established

>> typedef ipsec-spd-action
>> capitalises the actions as does RFC4301 but later uses of this have lower case actions; probably ok as it is
>
> Ok.
>>
>> protocol number appears in several places but technically, IPv6, which we must all love and promote, has 'next header' instead.  Probably worth a mention at least once in the YANG module
>
> We have included this note:
>
> NOTE: In case of IPv6, the protocol in the IP packet payload is
> specified in the Next Header field of the IPv6
> packet.";
>>
>> On the start >= end, I was looking at nat-yang and it has
>> must ". >= ../start-port-number"
>> which is the sort of YANG constraint I had in mind
>
> Done.
>
> must '. >= ../start’
>
>> leaf dscp-mapping
>> I do not understand, a hex string of indeterminate length for DSCP values (plural).  I expect DSCP to be six bit and values to be a leaf-list
>
> Right. Since we have inet:dscp type , we have used that one in a leaf-list as you recommend.
>
> leaf-list dscp-mapping {
>         type inet:dscp;
>         default 0;
>         description
>           "DSCP values allowed for packets carried over
>           this IPsec SA.";
>         reference
>           "Section 4.4.2.1. in RFC 4301.";
>       }
>
>>
>> leaf ecn
>> /Annex C/Appendix C/
>
> Fixed.
>>
>> I see that RFC8247 gives AEAD status which is a good reference to have except that as my other post today says there is no requirement for any future additions to the IANA data to include this information; IANA for IKEv2 needs updating iun a separate I-D!
>>
>> leaf mask
>> hex-string with no length specified
>
> Since this masked is after all 32-bits mask we have used uint32 instead.
>>
>> leaf ds-algorithm
>> default 1
>> which I think is RSA; worth stating as it might raise some AD eyebrows
>
> Clarified in the description.
>>
>> pfs-groups
>> /it is required perfect forward secrecy/perfect forward secrecy is required/
>
> Fixed.
>
>> and a reference to Transform Type 4?
>
> As we mention earlier, this pfs-groups used the type pfs-group, which includes the reference to Transform Type 4.
>>
>> leaf ext-seq-num
>> /FALSE/false/ or /False/?
>>
>> leaf encryption-algorithm (twice, in separate containers)
>
> Mmmmm… we only see in one place.

I see it a second time for
leaf integrity-algorithm

Tom Petch

>> /the integrity leaf/ the integrity-algorithm leaf/
>
> Fixed.
>>
>> I have yet to look at the text or the examples, probably next week.
>
> Thank you very much. We are going to post -12 with all these comments and the previous ones so far. If there are pending comments we can prepare -13 right away.
>
> Best Regards.
>>
>> Tom Petch
>>
>>>> On boiler plate, I mean the reference to RFC2119 which now must use the language from RFC8174 in the body of the I-D; sorry for the confusion.
>>>
>>> Ah ok. I guess you are referring to change that paragraph with this:
>>>
>>>
>>> The key words "MUST", "MUST NOT", "REQUIRED",
>>> "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
>>> "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>> "OPTIONAL" in this document are to be interpreted
>>> as described in BCP 14 RFC2119 RFC8174 when,
>>> and only when, they appear in all capitals,
>>> as shown here.
>>>
>>>>
>>>> On XXXX, you have XXXX standing in for more than one RFC-to-be which confuses.  The convention is to use XXXX for this I-D and then AAAA BBBB etc for any others such as the netconf I-D in this instance.
>>>
>>> Ah ok. In any case, we have now only XXXX for our RFC-to-be so problem fixed.
>>>>
>>>> Two big issues, for me (perhaps not for others).  The convention with YANG is for each successive line to be indented two characters, you have four, which creates a lot of white space and pushes the text to the right hand margin.  I think that two characters is the default when you use pyang to format a YANG module.
>>>
>>> We can try to reduce it to two characters.
>>>
>>>>
>>>> And references.  I have had to work harder than I want to to make sense of the IANA references.  I think you should have five separate references in the I-D for IANA for
>>>> Transform Type 1
>>>> Transform Type 3
>>>> Transform Type 4
>>>> Authentication Method
>>>> Protocol Numbers
>>>> and each reference in the I-D should have a URL pointing to the specific section of IANA web site.
>>>
>>> Ok, good. This follows what we thought.
>>>
>>>> In the YANG, it is harder to know what to do.  Those first three references are in the third tier i.e.
>>>> Group - Internet Key Exchange V2 (IKEv2) Parameters
>>>> Registry  -Transform Attribute Types
>>>> and then Type 1, 3, 4 as the third tier as I am calling it
>>>> and I think that every reference in the YANG should give me all three tiers after IANA in that order perhaps
>>>> IANA; IKEv2 Parameters; Transform Atribute Types; Transform Type 1
>>>
>>> Great. We also considered this as a possible solution after sending our e-mail. Let’s do it.
>>>
>>>> If the syntax needs tweeking, then the RFC Editor will do a good job of that but at present the references are inconsistent in which elements are specified in what order and that is something the RFC Editor probably cannot cope with.
>>>> Authentication Method is a registry so that just needs Group name and Registry name after IANA.
>>>
>>> Ok, good.
>>>>
>>>> Some minor glitches.
>>>> I-D appears twice in the body of the I-D - perhaps document or memo.
>>>
>>> Ok.
>>>
>>>> objetives/objectives/
>>>
>>> Fixed.
>>>> end port number perhaps /must/MUST/
>>>
>>>> and YANG is very good at including such checks with a must ....
>>>> 'If AEAD is used .. where? this occurs in several places and I think that you need to specify the leaf where AEAD will be specified or implied.
>>>
>>> Ok we have changed it to:
>>>
>>> If Authenticated Encryption with Associated Data (AEAD) is used (leaf esp-algorithms/encryption/algorithm-type)
>>> this flag MUST be false."
>>>
>>>> And is it possible to make that a YANG 'must' statement - looking at the IKEv2 registries it is not obvious which are AEAD so that might be more complexity than it is worth.
>>>> 'only available on linux kernels' Um implementation detail, you may get asked to remove that altogether or at least to a Informative Appendix - I would leave it in for now.
>>>
>>> Ok.
>>>
>>>> 'import ietf-i2nsf-ikec' the reference needs to be to a RFC and if it is not yet an RFC then RFC XXXX <title> in both Appendix B and C
>>>
>>> Yes, we have changed that to:
>>>
>>> RFC XXXX: Software-Defined Networking
>>>                 (SDN)-based IPsec Flow Protection.
>>>
>>>> leaf-list pfs-groups could do with a reference - Transform Type 4?
>>>
>>> The leaf list is referring to type pfs-group and we have now
>>>
>>> typedef pfs-group {
>>>              type uint16;
>>>              description
>>>                  "DH groups for IKE and IPsec SA rekey.";
>>>              reference
>>>                  "IANA; Internet Key Exchange V2 (IKEv2) Parameters;
>>> 				Transform Atribute Types; Transform Type 4 -
>>>                  Diffie-Hellman Group Transform IDs.
>>> 				Section 3.3.2 in RFC 7296.";
>>>          }
>>>
>>>
>>>> I am still working my way through the YANG so may have some more comments tomorrow.
>>>
>>> Ok, do not worry we will work in -12 with these comments so far to have a quick response. We can prepare a another version later with the rest of them.
>>>
>>> Thank you very much for your effort.
>>>>
>>>> Tom Petch
>>>>
>>>>> We have realized that we missed to change this, even though we discussed it. We will change it right away in the following way (bold):
>>>>>
>>>>> case rfc822-address-string {
>>>>>       leaf rfc822-address-string {
>>>>>            type string;
>>>>>            description
>>>>>                "Specifies the identity as a
>>>>>                 fully-qualified RFC5322 email
>>>>>                 address string. An example is,
>>>>>                 [email-masked]. The string
>>>>>                 MUST NOT contain any
>>>>>                 terminators e.g., NULL, CR,
>>>>>                 etc.).";
>>>>>             reference
>>>>>                    "RFC 5322.";
>>>>>       }
>>>>> }
>>>>>
>>>>> Btw, we already used in the past “case rfc822-address-string” and “leaf rfc822-address-string” since this is coming from IKEv2 standard. Do you think we should change that name as well?
>>>>>> YANG module references IANA Protocol Numbers which is not in the I-D references
>>>>>
>>>>> We have included the following reference:
>>>>>
>>>>> [IANA-Protocols-Number]
>>>>>                Internet Assigned Numbers Authority (IANA), "Protocol
>>>>>                Numbers", January 2020.
>>>>>
>>>>>
>>>>>>
>>>>>> s.2 boiler plate is out of date
>>>>>
>>>>> What we see is the I-D has the second choice stated in https://www.ietf.org/standards/ids/guidelines/
>>>>>
>>>>> This Internet-Draft is submitted in full conformance with the
>>>>>     provisions of BCP 78 and BCP 79.
>>>>>
>>>>>     Internet-Drafts are working documents of the Internet Engineering
>>>>>     Task Force (IETF).  Note that other groups may also distribute
>>>>>     working documents as Internet-Drafts.  The list of current Internet-
>>>>>     Drafts is at https://datatracker.ietf.org/drafts/current/.
>>>>>
>>>>>     Internet-Drafts are draft documents valid for a maximum of six months
>>>>>     and may be updated, replaced, or obsoleted by other documents at any
>>>>>     time.  It is inappropriate to use Internet-Drafts as reference
>>>>>     material or to cite them other than as "work in progress."
>>>>>
>>>>> Could you refer what is out of date?
>>>>>
>>>>>>
>>>>>> XXXX is standing in for more than one RFC
>>>>>
>>>>> Yes, XXXX has been used because we do not know the future number assigned to our I-D.
>>>>>
>>>>> Also we realized we also included this to refer to crypto-types I-D but this has been solved now in a new version -12 that we are preparing to include your comments. We noticed we can replace the type of rw cert-data?, ca-data*, crl-data? for binary without any problem.
>>>>>
>>>>> |           |     +--rw cert-data?        binary
>>>>> |           +--rw private-key?            binary
>>>>> |           +--rw ca-data*                binary
>>>>> |           +--rw crl-data?               binary
>>>>>
>>>>>>
>>>>>> but the show stopper that makes a proper review of this too costly is the references.  Those to IANA of which there are several I want to pursue.  The I-D reference is to IKEv2 parameters. Sadly, this is a three tier structure and noone agrees on what to call the third tier so I will call it tier3 here.  Top level is Group, as per RFC8126, second level is Registry.  The I-D reference is to the Group only which is fine if the actual reference then specifies the Registry and Tier3 but they never do, usually just Tier3 e.g. Transform Type 3 which makes for a lot of work for the reader, too much for this one.  You have to go hunting in all the second level Registry until you can find a match for the Tier3 identifier. And there are no URL.  If you want an example that I find easy to use, go look at RFC8407 (as usual).
>>>>>
>>>>> You’re right. Could you point the exact part at RFC 8407 with that example? We would really appreciate it.
>>>>>
>>>>> On the other hand, would it be enough to include the URL for Transform Type 3 https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-7 ?
>>>>>
>>>>> (Same for Transform Type 1, Transform Type 4)
>>>>>
>>>>>>
>>>>>> The reference for import of i2nsf-ikec gives a YANG module name; this needs to be the name of the RFC to be
>>>>>
>>>>> Fixed.
>>>>>
>>>>> import ietf-i2nsf-ikec {
>>>>>              prefix nsfikec;
>>>>>              reference
>>>>>                  "RFC XXXX: Software-Defined Networking
>>>>>                 (SDN)-based IPsec Flow Protection.";
>>>>> }
>>>>>
>>>>> We still use XXXX because we do not know the number assigned to the RFC to be.
>>>>>
>>>>>>
>>>>>> The example IPv6 address in the YANG module has :0:0: which is usually just ::
>>>>>
>>>>> Fixed.
>>>>>
>>>>> If you have any further comments, please let us know so we can include them in -12
>>>>>
>>>>> Best Regards.
>>>>>>
>>>>>> And I have some way to go still.
>>>>>>
>>>>>> Tom Petch
>>>>>>
>>>>>> On 22/10/2020 18:39, Rafa Marin-Lopez wrote:
>>>>>>> Dear all:
>>>>>>>
>>>>>>> After receiving a suggestion to make things clearer in the feature ikeless-notification description, we have just uploaded a new version -11 with a minor change to add the following text:
>>>>>>>
>>>>>>> feature ikeless-notification {
>>>>>>>              description
>>>>>>>                  "This feature indicates that the server supports
>>>>>>>                  generating notifications in the ikeless module.
>>>>>>>
>>>>>>>                  To ensure broader applicability of this module,
>>>>>>>                  the notifications are marked as a feature.
>>>>>>>                  For the implementation of ikeless case,
>>>>>>>                  the NSF is expected to implement this
>>>>>>>                  feature.";
>>>>>>>          }
>>>>>>>
>>>>>>> Best Regards.
>>>>>>>
>>>>>>>> Inicio del mensaje reenviado:
>>>>>>>>
>>>>>>>> De: [email-masked]
>>>>>>>> Asunto: New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
>>>>>>>> Fecha: 22 de octubre de 2020, 15:32:50 CEST
>>>>>>>> Para: "Fernando Pereniguez-Garcia" <[email-masked]>, "Rafael Lopez" <[email-masked]>, "Gabriel Lopez-Millan" <[email-masked]>, "Rafa Marin-Lopez" <[email-masked]>
>>>>>>>>
>>>>>>>>
>>>>>>>> A new version of I-D, draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
>>>>>>>> has been successfully submitted by Rafa Marin-Lopez and posted to the
>>>>>>>> IETF repository.
>>>>>>>>
>>>>>>>> Name:		draft-ietf-i2nsf-sdn-ipsec-flow-protection
>>>>>>>> Revision:	11
>>>>>>>> Title:		Software-Defined Networking (SDN)-based IPsec Flow Protection
>>>>>>>> Document date:	2020-10-22
>>>>>>>> Group:		i2nsf
>>>>>>>> Pages:		92
>>>>>>>> URL:            https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
>>>>>>>> Status:         https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
>>>>>>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection
>>>>>>>> Htmlized:       https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-11
>>>>>>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-11
>>>>>>>>
>>>>>>>> Abstract:

---

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

---

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: tom petch <[email-masked]>
Date: Wed, 4 Nov 2020 10:42:07 +0000

Rafa

Another separate thought.  The references you have for algorithms are to 
both IANA and RFC.  It seems to me that the IANA pages will be more 
up-to-date and can be updated by Expert Review which may take place 
before there is an RFC available while the RFC provide more detail that 
a user might want.  I am uncertain which is best so I raised this on the 
ipsecme WG list, which is responsible for IKEv2 maintenance, and I got 
the following.  The question is mine, the response from Tero Kivinen.

============================================================

 > is that your best advice?

Yes.
=============================================================

So do as you are currently doing and I shall stop thinking about it.

Tom Petch

> Hi Tom:

<snip>

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Wed, 4 Nov 2020 11:54:45 +0100

Hi Tom:

> El 4 nov 2020, a las 11:42, tom petch <[email-masked]> escribió:
> 
> Rafa
> 
> Another separate thought.  The references you have for algorithms are to both IANA and RFC.  It seems to me that the IANA pages will be more up-to-date and can be updated by Expert Review which may take place before there is an RFC available while the RFC provide more detail that a user might want.  I am uncertain which is best so I raised this on the ipsecme WG list, which is responsible for IKEv2 maintenance, and I got the following.  The question is mine, the response from Tero Kivinen.
> 

Yes, we are following this conversation as well. 

> So do as you are currently doing and I shall stop thinking about it.

Thank you very much for all your effort with this.

Best Regards.

> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [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: Fri, 6 Nov 2020 12:37:47 +0000

Rafa

My attempt to read the text keeps running into a brick wall (lockdown:-( 
but I have a few new comments.  I said sometime ago that the IESG would 
likely find plenty to say and I see that Benjamin has lived up to my 
expectations.  I wish I could be as productive as him:-(

For completeness, I include what I have found so far but suspect that 
they will all be overtaken by IESG comments.

RFC2247 I don't find good for DN; I find RFC4519 better but suspect that 
X.520 would be better still but do not have a copy of that to hand; this 
is the sort of thing I expect the IESG to have definite views on

given that the model has a boolean for fragmentation should is also have 
a leaf or some such for PMTU? Doing the former requires the latter or is 
that latter expected to be elsewhere in a different YANG model?

Abstract; PAD, SPD, SAD need expanding or else leaving out if the 
reference to IPsec databases is adequate for the Abstract.

I know you added the comment about no protocol (the comment surprised 
me:-) but I think the YANG modules matter more so I would say
'It defines three YANG modules but no new protocol.'

1
/Inspired in the SDN/Inspired by the SDN/
3
/state date/state data/

4.1
'a YANG data model  .. MUST be defined'
it would be good to reference where they are, ie the Appendices

4.2
ditto

[which is as far as I got reading but ..]

8
/should adhere/SHOULD adhere/  ??

Tom Petch

On 02/11/2020 12:06, tom petch wrote:
>>> protocol number appears in several places but technically, IPv6,
>>> which we must all love and promote, has 'next header' instead.
>>> Probably worth a mention at least once in the YANG module
>>
>>> I do not understand, a hex string of indeterminate length for DSCP
>>> values (plural).  I expect DSCP to be six bit and values to be a
>>> leaf-list
>>
>>> I see that RFC8247 gives AEAD status which is a good reference to
>>> have except that as my other post today says there is no requirement
>>> for any future additions to the IANA data to include this
>>> information; IANA for IKEv2 needs updating iun a separate I-D!
>>>
>>> leaf mask
>> As we mention earlier, this pfs-groups used the type pfs-group, which
>> includes the reference to Transform Type 4.
>>>
>>> leaf ext-seq-num
>> Thank you very much. We are going to post -12 with all these comments
>> and the previous ones so far. If there are pending comments we can
>> prepare -13 right away.
>>
>> Best Regards.
>>>
>>> Tom Petch
>>>
>>>>> On boiler plate, I mean the reference to RFC2119 which now must use
>>>>> the language from RFC8174 in the body of the I-D; sorry for the
>>>>> confusion.
>>>>
>>>>> On XXXX, you have XXXX standing in for more than one RFC-to-be
>>>>> which confuses.  The convention is to use XXXX for this I-D and
>>>>> then AAAA BBBB etc for any others such as the netconf I-D in this
>>>>> instance.
>>>>
>>>>> Two big issues, for me (perhaps not for others).  The convention
>>>>> with YANG is for each successive line to be indented two
>>>>> characters, you have four, which creates a lot of white space and
>>>>> pushes the text to the right hand margin.  I think that two
>>>>> characters is the default when you use pyang to format a YANG module.
>>>>
>>>>> And references.  I have had to work harder than I want to to make
>>>>> sense of the IANA references.  I think you should have five
>>>>> separate references in the I-D for IANA for
>>>>> Transform Type 1
>>>>> Transform Type 3
>>>>> Transform Type 4
>>>>> Authentication Method
>>>>> Protocol Numbers
>>>>> and I think that every reference in the YANG should give me all
>>>>> three tiers after IANA in that order perhaps
>>>>> If the syntax needs tweeking, then the RFC Editor will do a good
>>>>> job of that but at present the references are inconsistent in which
>>>>> elements are specified in what order and that is something the RFC
>>>>> Editor probably cannot cope with.
>>>>> 'If AEAD is used .. where? this occurs in several places and I
>>>>> think that you need to specify the leaf where AEAD will be
>>>>> specified or implied.
>>>>
>>>> If Authenticated Encryption with Associated Data (AEAD) is used
>>>> (leaf esp-algorithms/encryption/algorithm-type)
>>>>> And is it possible to make that a YANG 'must' statement - looking
>>>>> at the IKEv2 registries it is not obvious which are AEAD so that
>>>>> might be more complexity than it is worth.
>>>>> 'only available on linux kernels' Um implementation detail, you may
>>>>> get asked to remove that altogether or at least to a Informative
>>>>> Appendix - I would leave it in for now.
>>>>
>>>> Ok.
>>>>
>>>>> 'import ietf-i2nsf-ikec' the reference needs to be to a RFC and if
>>>>> it is not yet an RFC then RFC XXXX <title> in both Appendix B and C
>>>>
>>>> Ok, do not worry we will work in -12 with these comments so far to
>>>> have a quick response. We can prepare a another version later with
>>>> the rest of them.
>>>>
>>>>>> We have realized that we missed to change this, even though we
>>>>>> discussed it. We will change it right away in the following way
>>>>>> (bold):
>>>>>>
>>>>>> Btw, we already used in the past “case rfc822-address-string” and
>>>>>> “leaf rfc822-address-string” since this is coming from IKEv2
>>>>>> standard. Do you think we should change that name as well?
>>>>>> What we see is the I-D has the second choice stated in
>>>>>> https://www.ietf.org/standards/ids/guidelines/
>>>>>>
>>>>>> Also we realized we also included this to refer to crypto-types
>>>>>> I-D but this has been solved now in a new version -12 that we are
>>>>>> preparing to include your comments. We noticed we can replace the
>>>>>> type of rw cert-data?, ca-data*, crl-data? for binary without any
>>>>>> problem.
>>>>>>
>>>>>>> but the show stopper that makes a proper review of this too
>>>>>>> costly is the references.  Those to IANA of which there are
>>>>>>> several I want to pursue.  The I-D reference is to IKEv2
>>>>>>> parameters. Sadly, this is a three tier structure and noone
>>>>>>> agrees on what to call the third tier so I will call it tier3
>>>>>>> here.  Top level is Group, as per RFC8126, second level is
>>>>>>> Registry.  The I-D reference is to the Group only which is fine
>>>>>>> if the actual reference then specifies the Registry and Tier3 but
>>>>>>> they never do, usually just Tier3 e.g. Transform Type 3 which
>>>>>>> makes for a lot of work for the reader, too much for this one.
>>>>>>> You have to go hunting in all the second level Registry until you
>>>>>>> can find a match for the Tier3 identifier. And there are no URL.
>>>>>>> If you want an example that I find easy to use, go look at
>>>>>>> RFC8407 (as usual).
>>>>>>
>>>>>> On the other hand, would it be enough to include the URL for
>>>>>> Transform Type 3
>>>>>> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-7
>>>>>> ?
>>>>>>
>>>>>>> The reference for import of i2nsf-ikec gives a YANG module name;
>>>>>>> this needs to be the name of the RFC to be
>>>>>>
>>>>>> Fixed.
>>>>>>
>>>>>> import ietf-i2nsf-ikec {
>>>>>>              prefix nsfikec;
>>>>>>              reference
>>>>>>>> After receiving a suggestion to make things clearer in the
>>>>>>>> feature ikeless-notification description, we have just uploaded
>>>>>>>> a new version -11 with a minor change to add the following text:
>>>>>>>>
>>>>>>>>> Asunto: New Version Notification for
>>>>>>>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
>>>>>>>>> Para: "Fernando Pereniguez-Garcia"
>>>>>>>>> <[email-masked]>, "Rafael Lopez" <[email-masked]>,
>>>>>>>>> "Gabriel Lopez-Millan" <[email-masked]>, "Rafa Marin-Lopez"
>>>>>>>>> <[email-masked]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A new version of I-D,
>>>>>>>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
>>>>>>>>> URL:
>>>>>>>>> https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
>>>>>>>>>
>>>>>>>>> Status:
>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
>>>>>>>>>
>>>>>>>>> Htmlized:
>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection
>>>>>>>>>
>>>>>>>>> Htmlized:
>>>>>>>>> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-11
>>>>>>>>>
>>>>>>>>> Diff:
>>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-11
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Abstract:

---

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

> .

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 10 Nov 2020 21:36:18 -0800

Hi Tom, Rafa,

> is the sort of thing I expect the IESG to have definite views on

I agree that 2247 is not very good for DN (but I missed that in my own
review; thank you for noticing it!).
I think that the best reference might differ if we want the conventional
string encoding of the DN vs the actual ASN.1 structure, but I think I
would have to consult with some other experts to be certain of the right
reference, in either case.

-Ben

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Wed, 11 Nov 2020 19:45:42 +0100

Hi Benjamin (and Tom)

Thanks for this discussion. We can wait for the proper reference.

We would like to mention we are also working in your review, and preparing the e-mail with our response.  In this sense, thank you so much for your very detailed review. It is really valuable.

Best Regards.

> El 11 nov 2020, a las 6:36, Benjamin Kaduk <[email-masked]> escribió:
> 
> Hi Tom, Rafa,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>