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

From: Rafa Marin-Lopez <[email-masked]>
Date: Thu, 22 Oct 2020 19:39:02 +0200

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:
>   This document describes how to provide IPsec-based flow protection
>   (integrity and confidentiality) by means of an Interface to Network
>   Security Function (I2NSF) controller.  It considers two main well-
>   known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to-
>   host.  The service described in this document allows the
>   configuration and monitoring of IPsec Security Associations (SAs)
>   from a I2NSF Controller to one or several flow-based Network Security
>   Functions (NSFs) that rely on IPsec to protect data traffic.
> 
>   The document focuses on the I2NSF NSF-facing interface by providing
>   YANG data models for configuring the IPsec databases (SPD, SAD, PAD)
>   and IKEv2.  This allows IPsec SA establishment with minimal
>   intervention by the network administrator.  It does not define any
>   new protocol.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

-------------------------------------------------------
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: Roman Danyliw <[email-masked]>
Date: Fri, 30 Oct 2020 19:40:03 +0000

Hi Tom!

> -----Original Message-----
> From: tom petch <[email-masked]>
> Sent: Friday, October 30, 2020 7:14 AM
> To: Roman Danyliw <[email-masked]>; Rafa Marin-Lopez <[email-masked]>
> Cc: [email-masked]; Fernando Pereniguez-Garcia
> <[email-masked]>; Gabriel Lopez <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: Re: [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-
> flow-protection-11.txt
> 
> Roman  not this I-D but see below
> 
> On 29/10/2020 18:46, Roman Danyliw wrote:
> > Hi Tom!
> >
> >> -----Original Message-----
> >> From: last-call <[email-masked]> On Behalf Of tom petch
> >> Sent: Thursday, October 29, 2020 12:38 PM
> >> To: Rafa Marin-Lopez <[email-masked]>
> >> Cc: [email-masked]; Fernando Pereniguez-Garcia
> >> <[email-masked]>; Gabriel Lopez <[email-masked]>;
> >> [email-masked]; [email-masked]
> >>
> >> Top posting a new, related issue that may need Security AD or WG
> >> Chair to act on.
> >>
> >> It seems to me that the IANA entries for IKEv2 are incomplete.
> >> RFC8247 does a fine job of specifying algorithms and adding
> >> information such as status (MUST/SHOULD+), IoT, AEAD and so on,
> >> information which is not present on IANA.  The policy for, e.g.
> >> Transform Type 1, is expert review and entries have been added via
> >> draft-smyslov-esp-gont but the IANA entries lack this information
> >> and, looking at the I-D, I see no such information (nor is there any
> >> reason for it to be there).  Yet draft-ietf-i2nsf-sdn... needs this information
> as references in the YANG module show.
> >>
> >> It seems to me that this is a similar situation to that which the TLS
> >> WG found itself in and which led to a revision of the TLS IANA
> >> entries to provide what was needed via additional columns.
> >
> > Please help me understand.  In particular, I'm not following why this
> document should modify IKE IANA registries.  In my view, this document is
> provides a data model to encode an "IKEv2 configuration" of sorts.  Certainly,
> there are valid/invalid/incomplete/not recommended ways to provide a
> configuration with this data model if one relied solely on the pointers to the
> IANA registries from the YANG module definition.  However, as you noted,
> RFC8247 already provides guidance on specifying a configuration (albeit this
> guidance isn't fully encoded in the registries).  Furthermore, this document
> states:
> >
> > Section 8.1
> >     o  IKEv2 configurations should adhere to the recommendations in
> >        [RFC8247].
> >
> > so there is guidance on producing a configuration.  What is missing?
> >
> >> I think that the IANA pages for IKEv2 need revising so that that
> >> additional information that RFC8247 provides is required as
> >> additional columns in the IANA entries at least for Type 1, Type 2,
> >> Type 3, Type 4 and Authentication Method.
> >
> > While things could be clearer, I'm unsure of why _this YANG document_
> should do a registry reengineering.  Did you mean it should be done in general?
> 
> Not this I-D but another I-D from a WG with closer links to IKEv2; I don't know
> which WG that would be but a Security AD would:-)

Thanks for clarifying.  IPSECME (https://datatracker.ietf.org/wg/ipsecme/about/) (who has been cross-posted with this note)  is likely the best place to handle IPsec maintenance and the kind of registry modifications you describe below.

Regards,
Roman

> This I-D, as you quote, points to RFC8247 for guidance and that is fine.
>   But security moves on and new algorithms will be needed and this I-D also
> points to the IANA registry, which is Expert Review, where new entries have
> been added already; and for those the IANA Registry gives no guidance and the
> I-D that IANA references for the new entries - written by the Expert Reviewer! -
> also gives no guidance. Over time we are likely to accrue algorithms with no
> guidance unless and until an RFC8247-bis appears or we require IANA to have
> columns for guidance.
> Currently the new algorithms are GOST and so perhaps of limited interest but
> on the TLS list I am always seeing new algorithms appear and there the new
> IANA entry is required to give guidance.  My sense is that IKEv2 is a bit slower
> to take up new ones but, as with RFC8247, it does eventually.
> 
> I think that users need those extra columns that RFC8247 provides on the IANA
> website so that when new algorithms are added by Expert Review, then that
> guidance must be added as well.  This is what the TLS WG came round to and I
> think that IKEv2 needs to do the same.
> 
> Tom Petch
> 
> 
> > Regards,
> > Roman
> >
> >> Tom Petch
> >>
> >> 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
> >>>>
> >>>> 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:
> >>>>>>>
> >>>>>>>> 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
> >>>>>>>> has been successfully submitted by Rafa Marin-Lopez and posted
> >>>>>>>> to the IETF repository.
> >>>>>>>>
> >>>>>>>> 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 a I2NSF Controller to one or several flow-based
> >>>>>>>> Network
> >> Security
> >>>>>>>>     YANG data models for configuring the IPsec databases (SPD,
> >>>>>>>> SAD,
> >> PAD)
> >>>>>>>> Please note that it may take a couple of minutes from the time
> >>>>>>>> of submission until the htmlized version and diff are available
> >>>>>>>> at
> >> tools.ietf.org.
> >>>>>>>>
> >>>>>>>> The IETF Secretariat
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> Dept. Information and Communications Engineering (DIIC) Faculty
> >>>>>>> of Computer Science-University of Murcia
> >>>>>>> 30100 Murcia - Spain
> >>>>> Dept. Information and Communications Engineering (DIIC) Faculty of
> >>>>> Computer Science-University of Murcia
> >>>>> 30100 Murcia - Spain
> >>> Dept. Information and Communications Engineering (DIIC) Faculty of
> >>> Computer Science-University of Murcia
> >>> 30100 Murcia - Spain
> >> --
> >> last-call mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/last-call

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Oct 2020 16:20:55 -0400

I agree we should make our IANA entries clearer.

Begin forwarded message:

> From: Roman Danyliw <[email-masked]>
> Date: October 30, 2020 at 15:41:09 EDT
> To: tom petch <[email-masked]>
> Cc: [email-masked], [email-masked], Gabriel Lopez <[email-masked]>, [email-masked], Fernando Pereniguez-Garcia <[email-masked]>, [email-masked], Rafa Marin-Lopez <[email-masked]>
> Subject: Re: [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
> 
> Hi Tom!
>

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 31 Oct 2020 00:42:12 +0200

Roman Danyliw writes:
> > >> reason for it to be there).  Yet draft-ietf-i2nsf-sdn... needs
> > >> this information as references in the YANG module show. 

I am lost what information is missing from the IANA registry. The
registry do include numbers from draft-smyslov-esp-gost document. The
RFC8247 says:
----------------------------------------------------------------------
1.3.  Updating Algorithm Requirement Levels
...
    .... As a result, any algorithm listed at the IKEv2
   IANA registry not mentioned in this document MAY be implemented.
----------------------------------------------------------------------
I.e., all algorithms not listed there are MAY to implement.

But I do not see any reason why the yang module should provide any
other than pointer to the IANA registry, and the IANA registry already
has pointer to the RFC8247 to indicate the requirement levels for
algorithms. 

> > >> entries to provide what was needed via additional columns.

There was some requests to modify the IANA registry while we were
publishing RFC 8247 and the WG decided against it, and instead decided
to provide pointer to the RFC 8211 and RFC 8247 in the notes section.

The reason for that is that duplicating information always causes
problems, and because there is no (public) history of the IANA
registries, there is no way of finding out when and why specific
change to the registry was done unless there happens to be RFC that
actually did that change.

I myself as an IANA expert of those registries do think it is better
that working group will do RFC that will update the levels, and that
will leave audit trail and public working group mailing list
discussion about the changes. 

> > >> Type 3, Type 4 and Authentication Method.

I fail to see why does that information need to be in the IANA
registry? This is YANG model for IPsec, it should just refer to the
IANA registry about the mapping from algorithms to numbers and other
way around, but whether the algorithm is recommended or not, does not
belong to the YANG model, as that is not something that can be
modified by configuration or be part of running state.

This document seems to have wierd text in it:

      typedef encryption-algorithm-type {
        type uint16;
        description
          "The encryption algorithm is specified with a 16-bit
          number extracted from IANA Registry. The acceptable
          values MUST follow the requirement levels for
          encryption algorithms for ESP and IKEv2.";

I do not see what the last sentence of the text is trying to say? Does
it mean that this yang model cannot be shown of running configuration
where someone is using one the algorithms not considered safe anymore?
In ietf we usually just try to say what implementors are implementing,
we do not that often limit what adminstrators can configure. If the
implementation happens to implement one of those weak ciphers for
example for talking to one obsoleted old hardware that only supports
them, then I do not see why this yang model should forbid showing
running status of such configuration.

I think this document should just say that the algorithm numbers are
from the IANA registry, and nothing more. There might be informal
reference to the RFC 8221, and RFC 8247 but even that should not be
needed, as anybody implementing IKEv2 or ESP will already follow those
and only implement the algorithms from there that they seem proper. In
some cases that selection might include algorithms which are on SHOULD
NOT or even MUST NOT, if the backward compatibility to obsolete
hardware is more important than conformance.

> > This I-D, as you quote, points to RFC8247 for guidance and that is
> > fine. But security moves on and new algorithms will be needed and
> > this I-D also points to the IANA registry, which is Expert Review,
> > where new entries have been added already; and for those the IANA
> > Registry gives no guidance and the I-D that IANA references for
> > the new entries - written by the Expert Reviewer! - also gives no
> > guidance. Over time we are likely to accrue algorithms with no
> > guidance unless and until an RFC8247-bis appears or we require
> > IANA to have columns for guidance. Currently the new algorithms
> > are GOST and so perhaps of limited interest but on the TLS list I
> > am always seeing new algorithms appear and there the new IANA
> > entry is required to give guidance. My sense is that IKEv2 is a
> > bit slower to take up new ones but, as with RFC8247, it does
> > eventually.

The original cryptographic algorithm impelemtation requirements for
ESP and AH was published as RFC4305 in 2007. It was replaced with
RFC7321 in 2014, and that was replaced with RFC8221 in 2017. For IKEv2
we skipped the 2014 update, as that was not needed. We do have plans
to keep that draft up to date, and update it when there is need for
that, most likely in next 5 years or so, provided that implementation
status of some of new algorithms progresses favorably.

> > I think that users need those extra columns that RFC8247 provides
> > on the IANA website so that when new algorithms are added by
> > Expert Review, then that guidance must be added as well. This is
> > what the TLS WG came round to and I think that IKEv2 needs to do
> > the same.

I as an Expert does not want to decide whether the individual request
to add new 3rot13 cipher to the IANA registry should be MUST NOT,
SHOULD NOT, MAY or what. If the field is in the IANA registry then
whoever requests to add information to there can request whatever
value they want for that field too. Of course as an IANA expert I can
reject that by saying that 3rot13 is not MUST, but it is MUST NOT
algorithm, and then we can have discussion about that.

I rather have that discussion in the working group when we are
updating the requirements document next time. And as I said IANA
registries do not have any (public) history, or any way of finding out
why they got changed and who did the change. There has happened some
changes in the registry where I as an IANA Expert was not aware of at
all...

And if I need to find out when ENCR_MAGMA_MGM_KTREE was added or when
some of those earlier algorithms was renamed, I need to go to my
private mail archives. 
-- 
[email-masked]

---

From: Roman Danyliw <[email-masked]>
Date: Sat, 31 Oct 2020 01:12:29 +0000

Hi Tero!

> From: IPsec <[email-masked]> On Behalf Of Tero Kivinen
> Sent: Friday, October 30, 2020 6:42 PM
> To: Roman Danyliw <[email-masked]>
> Cc: Fernando Pereniguez-Garcia <[email-masked]>;
> [email-masked]; Gabriel Lopez <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; Rafa Marin-Lopez <[email-masked]>; tom petch
> <[email-masked]>
> Subject: Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-
> ipsec-flow-protection-11.txt
> 

> > > >> Transform Type 1, is expert review and entries have been added
> > > >> via draft-smyslov-esp-gont but the IANA entries lack this
> > > >> information and, looking at the I-D, I see no such information
> > > >> (nor is there any reason for it to be there).  Yet
> > > >> draft-ietf-i2nsf-sdn... needs this information as references in the YANG
> module show.
> 
> I am lost what information is missing from the IANA registry. 

Thanks for the analysis and feedback.

I think the deep threading may have confused who said what.  The above snip and all of the snips below are from Tom's assessment of the IANA registry situation (https://mailarchive.ietf.org/arch/msg/last-call/Cg66LRwtJjhJ5zNe8AEBWqKDll0/ and https://mailarchive.ietf.org/arch/msg/last-call/MMO9NsRif_x1WkGbJFlgKiLOGYQ/) 

My feedback in the earlier in the part of the thread (https://mailarchive.ietf.org/arch/msg/last-call/vSU21Yqbczthq9Uii0N0roHQI7c/) was that RFC8247 is cited by draft-ietf-i2nsf-sdn-ipsec-flow-protection to describe implementation requirements (as represented in the YANG module) and that no IANA changes should be needed.

In a follow-on messages (https://mailarchive.ietf.org/arch/msg/last-call/7eC7LH9_EWHxkA22YbST6Ghc4tc/) which added ipsec@ietf, I was noting that IPSecme is the WG with expertise and scope  that is best positioned to discuss management of the IKE registries

Regards,
Roman

> The registry do
> include numbers from draft-smyslov-esp-gost document. The
> RFC8247 says:
> 1.3.  Updating Algorithm Requirement Levels ...
> But I do not see any reason why the yang module should provide any other
> than pointer to the IANA registry, and the IANA registry already has pointer to
> the RFC8247 to indicate the requirement levels for algorithms.
> 
> > > >> It seems to me that this is a similar situation to that which the
> > > >> TLS WG found itself in and which led to a revision of the TLS
> > > >> IANA entries to provide what was needed via additional columns.
> 
> There was some requests to modify the IANA registry while we were publishing
> RFC 8247 and the WG decided against it, and instead decided to provide
> pointer to the RFC 8211 and RFC 8247 in the notes section.
> 
> The reason for that is that duplicating information always causes problems, and
> because there is no (public) history of the IANA registries, there is no way of
> finding out when and why specific change to the registry was done unless there
> happens to be RFC that actually did that change.
> 
> I myself as an IANA expert of those registries do think it is better that working
> group will do RFC that will update the levels, and that will leave audit trail and
> public working group mailing list discussion about the changes.
> 
> > > >> additional columns in the IANA entries at least for Type 1, Type
> > > >> 2, Type 3, Type 4 and Authentication Method.
> 
> I fail to see why does that information need to be in the IANA registry? This is
> YANG model for IPsec, it should just refer to the IANA registry about the
> mapping from algorithms to numbers and other way around, but whether the
> algorithm is recommended or not, does not belong to the YANG model, as that
> is not something that can be modified by configuration or be part of running
> state.
> 
> I do not see what the last sentence of the text is trying to say? Does it mean
> that this yang model cannot be shown of running configuration where someone
> is using one the algorithms not considered safe anymore?
> In ietf we usually just try to say what implementors are implementing, we do
> not that often limit what adminstrators can configure. If the implementation
> happens to implement one of those weak ciphers for example for talking to one
> obsoleted old hardware that only supports them, then I do not see why this
> yang model should forbid showing running status of such configuration.
> 
> I think this document should just say that the algorithm numbers are from the
> IANA registry, and nothing more. There might be informal reference to the RFC
> 8221, and RFC 8247 but even that should not be needed, as anybody
> implementing IKEv2 or ESP will already follow those and only implement the
> algorithms from there that they seem proper. In some cases that selection
> might include algorithms which are on SHOULD NOT or even MUST NOT, if the
> backward compatibility to obsolete hardware is more important than
> conformance.
> 
> > > Registry gives no guidance and the I-D that IANA references for the
> > > new entries - written by the Expert Reviewer! - also gives no
> > > guidance unless and until an RFC8247-bis appears or we require IANA
> > > to have columns for guidance. Currently the new algorithms are GOST
> > > and so perhaps of limited interest but on the TLS list I am always
> > > seeing new algorithms appear and there the new IANA entry is
> > > required to give guidance. My sense is that IKEv2 is a bit slower to
> > > take up new ones but, as with RFC8247, it does eventually.
> 
> The original cryptographic algorithm impelemtation requirements for ESP and
> AH was published as RFC4305 in 2007. It was replaced with
> RFC7321 in 2014, and that was replaced with RFC8221 in 2017. For IKEv2 we
> skipped the 2014 update, as that was not needed. We do have plans to keep
> that draft up to date, and update it when there is need for that, most likely in
> next 5 years or so, provided that implementation status of some of new
> algorithms progresses favorably.
> 
> > > I think that users need those extra columns that RFC8247 provides on
> > > the IANA website so that when new algorithms are added by Expert
> > > Review, then that guidance must be added as well. This is what the
> > > TLS WG came round to and I think that IKEv2 needs to do the same.
> 
> I as an Expert does not want to decide whether the individual request to add
> new 3rot13 cipher to the IANA registry should be MUST NOT, SHOULD NOT,
> MAY or what. If the field is in the IANA registry then whoever requests to add
> information to there can request whatever value they want for that field too.
> Of course as an IANA expert I can reject that by saying that 3rot13 is not MUST,
> but it is MUST NOT algorithm, and then we can have discussion about that.
> 
> I rather have that discussion in the working group when we are updating the
> requirements document next time. And as I said IANA registries do not have
> any (public) history, or any way of finding out why they got changed and who
> did the change. There has happened some changes in the registry where I as an
> IANA Expert was not aware of at all...
> 
> And if I need to find out when ENCR_MAGMA_MGM_KTREE was added or
> when some of those earlier algorithms was renamed, I need to go to my private
> mail archives.
> --
> [email-masked]
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: tom petch <[email-masked]>
Date: Sat, 31 Oct 2020 13:12:32 +0000

> I am lost what information is missing from the IANA registry.

Tero

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.

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.

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

The

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 31 Oct 2020 17:01:00 +0300

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.

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

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

Regards,
Valery Smyslov.

> > registry do include numbers from draft-smyslov-esp-gost document. The
TLS
> when
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf

---

From: Yoav Nir <[email-masked]>
Date: Sat, 31 Oct 2020 20:28:13 +0200

> On 31 Oct 2020, at 15:12, tom petch <[email-masked]> 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.

Yoav