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

[Roman Danyliw <[e-mail]>]

Hi Tom!

> -----Original Message-----
> From: tom petch <[e-mail]>
> Sent: Friday, October 30, 2020 7:14 AM
> To: Roman Danyliw <[e-mail]>; Rafa Marin-Lopez <[e-mail]>
> Cc: [e-mail]; Fernando Pereniguez-Garcia
> <[e-mail]>; Gabriel Lopez <[e-mail]>;
> [e-mail]; [e-mail]
> 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 <[e-mail]> On Behalf Of tom petch
> >> Sent: Thursday, October 29, 2020 12:38 PM
> >> To: Rafa Marin-Lopez <[e-mail]>
> >> Cc: [e-mail]; Fernando Pereniguez-Garcia
> >> <[e-mail]>; Gabriel Lopez <[e-mail]>;
> >> [e-mail]; [e-mail]
> >>
> >> 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 <[e-mail]>
> 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 <[e-mail]>
> >> 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,
> >>>>>                  [e-mail]. 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: [e-mail]
> >>>>>>>> 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"
> >>>>>>>> <[e-mail]>, "Rafael Lopez" <[e-mail]>,
> >>>>>>>> "Gabriel Lopez-Millan" <[e-mail]>, "Rafa Marin-Lopez"
> >>>>>>>> <[e-mail]>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 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: [phone] Fax: [phone] e-mail: [e-mail]
> >>>>>>> -------------------------------------------------------
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>> -------------------------------------------------------
> >>>>> Rafa Marin-Lopez, PhD
> >>>>> Dept. Information and Communications Engineering (DIIC) Faculty of
> >>>>> Computer Science-University of Murcia
> >>>>> 30100 Murcia - Spain
> >>>>> Telf: [phone] Fax: [phone] e-mail: [e-mail]
> >>>>> -------------------------------------------------------
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>> -------------------------------------------------------
> >>> Rafa Marin-Lopez, PhD
> >>> Dept. Information and Communications Engineering (DIIC) Faculty of
> >>> Computer Science-University of Murcia
> >>> 30100 Murcia - Spain
> >>> Telf: [phone] Fax: [phone] e-mail: [e-mail]
> >>> -------------------------------------------------------
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> last-call mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/last-call