Hi Tom! > -----Original Message----- > From: tom petch <daedulus@xxxxxxxxxxxxx> > Sent: Friday, October 30, 2020 7:14 AM > To: Roman Danyliw <rdd@xxxxxxxx>; Rafa Marin-Lopez <rafa@xxxxx> > Cc: i2nsf@xxxxxxxx; Fernando Pereniguez-Garcia > <fernando.pereniguez@xxxxxxxxxxx>; Gabriel Lopez <gabilm@xxxxx>; > ynir.ietf@xxxxxxxxx; last-call@xxxxxxxx > 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 <last-call-bounces@xxxxxxxx> On Behalf Of tom petch > >> Sent: Thursday, October 29, 2020 12:38 PM > >> To: Rafa Marin-Lopez <rafa@xxxxx> > >> Cc: i2nsf@xxxxxxxx; Fernando Pereniguez-Garcia > >> <fernando.pereniguez@xxxxxxxxxxx>; Gabriel Lopez <gabilm@xxxxx>; > >> ynir.ietf@xxxxxxxxx; last-call@xxxxxxxx > >> > >> 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 <daedulus@xxxxxxxxxxxxx> > 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 <daedulus@xxxxxxxxxxxxx> > >> 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, > >>>>> jsmith@xxxxxxxxxxx. 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: internet-drafts@xxxxxxxx > >>>>>>>> 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" > >>>>>>>> <fernando.pereniguez@xxxxxxxxxxx>, "Rafael Lopez" <rafa@xxxxx>, > >>>>>>>> "Gabriel Lopez-Millan" <gabilm@xxxxx>, "Rafa Marin-Lopez" > >>>>>>>> <rafa@xxxxx> > >>>>>>>> > >>>>>>>> > >>>>>>>> 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: rafa@xxxxx > >>>>>>> ------------------------------------------------------- > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> ------------------------------------------------------- > >>>>> 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: rafa@xxxxx > >>>>> ------------------------------------------------------- > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> ------------------------------------------------------- > >>> 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: rafa@xxxxx > >>> ------------------------------------------------------- > >>> > >>> > >>> > >>> > >>> > >> > >> -- > >> last-call mailing list > >> last-call@xxxxxxxx > >> https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
