Re: [I2nsf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

[Alissa Cooper <[e-mail]>]

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=[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 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
>>> [e-mail] <mailto:[e-mail]>
>>> 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: [phone] Fax: [phone] e-mail: [e-mail] <mailto:[e-mail]>
>> -------------------------------------------------------
>> 
>> 
>> 
>> 
>> 
>> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art