Mohit, thanks for your review. Rafa, thanks for your responses. I entered a No Objection ballot.
Alissa > On Oct 6, 2020, at 7:57 AM, Mohit Sethi M > <mohit.m.sethi=40ericsson....@dmarc.ietf.org> wrote: > > Hi Rafa, > > Thanks for addressing my comments. Your changes and updates look good. > > --Mohit > > On 9/22/20 9:41 AM, Rafa Marin-Lopez wrote: >> Dear Mohit: >> >> Thank you very much for your review. We really appreciate it. Please see our >> comments inline: >> >>> El 31 ago 2020, a las 13:28, Mohit Sethi via Datatracker <nore...@ietf.org >>> <mailto:nore...@ietf.org>> escribió: >>> >>> Reviewer: Mohit Sethi >>> Review result: On the Right Track >>> >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>> >>> For more information, please see the FAQ at >>> >>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq >>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>. >>> >>> Document: draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 >>> Reviewer: Mohit Sethi >>> Review Date: 2020-08-31 >>> IETF LC End Date: 2020-09-04 >>> IESG Telechat date: Not scheduled for a telechat >>> >>> Summary: This document describes how IPsec SAs can be setup from a >>> centralized >>> I2NSF controller. The document is "On the Right Track". >>> >>> Major issues: >>> - The document should highlight in the abstract and elsewhere that it does >>> not >>> define a protocol between the I2NSF controller and the NSF. It only >>> specifies >>> the YANG model. Several appendices refer to notification messages. Where are >>> they defined/specified? >> >> [Authors] Regarding the abstract, we have applied your suggestions. We can >> also include a few words to highlight the aspect you mention: we do not >> define any new protocol but a YANG model. >> >>> 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. >>> Therefore, it does not not define any new protocol. This >>> allows IPsec SA establishment with minimal intervention by the network >>> administrator. >> >> >> >> With respect to notifications, they are defined in NETCONF itself but we had >> to define through the YANG model the information (notification data) that >> will be sent: >> >> For example: >> >> notifications: >> +---n sadb-acquire >> | +--ro ipsec-policy-name string >> | +--ro traffic-selector >> | +--ro local-subnet inet:ip-prefix >> | +--ro remote-subnet inet:ip-prefix >> | +--ro inner-protocol? ipsec-inner-protocol >> | +--ro local-ports* [start end] >> | | +--ro start inet:port-number >> | | +--ro end inet:port-number >> | +--ro remote-ports* [start end] >> | +--ro start inet:port-number >> | +--ro end inet:port-number >> +---n sadb-expire >> | +--ro ipsec-sa-name string >> | +--ro soft-lifetime-expire? boolean >> | +--ro lifetime-current >> | +--ro time? uint32 >> | +--ro bytes? uint32 >> | +--ro packets? uint32 >> | +--ro idle? uint32 >> +---n sadb-seq-overflow >> | +--ro ipsec-sa-name string >> +---n sadb-bad-spi >> +--ro spi uint32 >> >> Therefore We define YANG notifications for the ikeless case making use of >> the notification message defined by NETCONF. >> >>> >>> - For the IKE case, a lot would depend on the cryptographic suites >>> implemented >>> in the NSF. For example, what if the I2NSF issues certificates for curves >>> not >>> implemented. The document should maybe mention that the I2NSF is aware of >>> the >>> NSF and its IKEv2 implementation/version details based on which it issues >>> the >>> credentials. This relates to the text: "and applying other IKEv2 >>> configuration >>> parameters (e.g. cryptographic algorithms for establishing an IKEv2 SA)". >>> You >>> can't configure what is not implemented? >> >> We think this is discussed in Section 5.4 NSF registration and discovery. We >> acknowledged that I2NSF must discover NSF features. However this is a >> previous step to what we define in this I-D. Once the NSF is operative and >> I2NSF controller has knowledge of the NSF and their features, the I2NSF >> controller can configure properly. >> >> Should we extend the section 5.4 somehow? Any suggestion? >> >> >>> >>> - Does the specification allow NSF's to derive many CHILD SAs? >> >> If you are referring to IKE case, the IKE implementation in the NSF may >> derive several child SAs based on a particular policy. However, under I2NSF >> controller standpoint. >> >> In the IKE-less case, the I2NSF controller can apply multiple IPsec SAs in >> the NSF. >> >> Beyond these comments all the minor issues below has been already fixed in >> the v09 we are preparing. >> >> Best regards and thank you so much again! >> >> >>> >>> Minor issues: >>> - The document has several grammatical errors. I have fixed many of them in >>> my >>> review below but surely not all. I hope that chairs/ADs could do another >>> pass >>> before sending this to the RFC editor. >>> >>> Nits/editorial comments: >>> - The document uses terms such as NSF ships/implements IKEv2. Use consistent >>> terminology. >>> >>> - Abstract: There were too many issues with the abstract to individually >>> point >>> out. Here is an edited version for you to consider: >>> >>> 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. >>> >>> - The SDN controller manages and configures the distributed network >>> resources >>> and provides an abstracted view of the network resources to the SDN >>> applications. -> Incorrect usage of "the" in several places. Consider >>> changing >>> to: "SDN controllers configure and manage distributed network resources and >>> provide an abstracted view of the network resources to SDN applications" >>> >>> - The SDN application can customize and automate the operations (including >>> management) of the abstracted network resources in a programmable manner via >>> this interface [RFC7149] [ITU-T.Y.3300] [ONF-SDN-Architecture] >>> [ONF-OpenFlow]. >>> -> Remove article from the beginning of the sentence "SDN applications can >>> customize and automate the operations (including management) of the >>> abstracted >>> network resources in a programmable manner via this interface [RFC7149] >>> [ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow]." >>> >>> - Several sentences are way too long. Here is an edited version of the 2nd >>> paragraph that you could consider: Several network scenarios now demand a >>> centralized way of managing different security aspects. For example, >>> Software-Defined WANs (SD-WANs). SD-WANs are an SDN extension providing a >>> software abstraction to create secure network overlays over traditional WAN >>> and >>> branch networks. SD-WANs utilize IPsec [RFC4301] as an underlying security >>> protocol. The goal of SD-WANs is to provide flexible and automated >>> deployment >>> from a centralized point to enable on-demand network security services such >>> as >>> IPsec Security Association (IPsec SA) management. >>> >>> Additionally, Section 4.3.3 in [RFC8192] describes another example use case >>> for >>> Cloud Data Center Scenario titled "Client-Specific Security Policy in Cloud >>> VPNs". The use case in RFC 8192 states that "dynamic key management is >>> critical >>> for securing the VPN and the distribution of policies". These VPNs can be >>> established using IPsec. The management of IPsec SAs in data centers using >>> a >>> centralized entity is a scenario where the current specification maybe >>> applicable. >>> >>> - This text is repeated twice: "In the IKE case, IKEv2 already provides a >>> mechanism to detect whether ..." >>> >>> - "view is built either requesting information to the NSFs under its >>> control, >>> or because these NSFs inform the I2NSF Controller." -> "view is built >>> either by >>> requesting information from the NSFs under its control, or by information >>> pushed from the NSFs to the I2NSF Controller" >>> >>> - "Combined algorithms has been removed" -> have been >>> >>> - "admit the configurations of these values." -> "accept configuration of >>> these >>> values" >>> >>> - "Beside, IaaS services providing virtualization environments are >>> deployments >>> solutions based on IPsec to provide" -> "Besides, IaaS services providing >>> virtualization environments are deployments that often rely on IPsec to >>> provide" >>> >>> - "Despite this procedure may increase the latency to complete the process, >>> no >>> traffic is sent over the network until the IPsec SAs are completely >>> operative." >>> -> "Even though this procedure may increase" >>> >>> - "If some of the operations described above fails" -> "If some of the >>> operations described above fail" >>> >>> - "In such as reactive mode, upon reception of the sadb-acquire >>> notification, >>> the I2NSF Controller installs the new IPsec SAs in NSF A and B (following" >>> -> "" >>> >>> - "If this is not critic then it is an" -> this is not critical >>> >>> >>> _______________________________________________ >>> I2nsf mailing list >>> i2...@ietf.org <mailto:i2...@ietf.org> >>> https://www.ietf.org/mailman/listinfo/i2nsf >>> <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: r...@um.es <mailto:r...@um.es> >> ------------------------------------------------------- >> >> >> >> >> >> > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
