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

Alissa Cooper <alissa@cooperw.in> Thu, 05 November 2020 01:53 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248103A1200; Wed, 4 Nov 2020 17:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Fp3n/cT+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GjoMiF6l
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3FnBU6bYHAB; Wed, 4 Nov 2020 17:53:07 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644233A122A; Wed, 4 Nov 2020 17:53:07 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9CA6E5C0138; Wed, 4 Nov 2020 20:53:06 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 04 Nov 2020 20:53:06 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=/j5ZqzxbbSxd7JSyFKYvk5m m1KBYE+J/a/Bz0fkhZoY=; b=Fp3n/cT+j4gGYUwt89urVGrOrWr6bjoxVpv9zV8 3U1hDeTzO1pUqfAyaMlFFi6qAxerQtElJUJyo7rIzVxHE1Xh/XWwSGbyxiAwWrYM 7MsKamLNogNkUjy2Lmg3EvzGMCtbvSmTLP1MyJZctmFniPGySmpuOAhpJ1SerUrv pifeZwsRoKkoD7LgmW5Cu16pxCBFcNEtUYo8X65eNQnfJxhZ2BKQhj8IS/1WS3Uc YnHEoOGM3owc7o5MyccaSCRdCpJoi8eg+n6ikA4xsMkYVJ6qJHW7KAAozvjfl0SP r7pVXUGlDPLOkonwMitJNmQ9O2YQjrEjbLt7KIxK29qnN0Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=/j5Zqz xbbSxd7JSyFKYvk5mm1KBYE+J/a/Bz0fkhZoY=; b=GjoMiF6lfBlkLTnLt9Ctt+ 5HdDU9boPvh32KSg+R32hdyWe7Q6jq+Z4sF6xLhcojkLVR5XHgo2ncN3lylLkvXd eUeLiqduSgj7Fkd9ooL7NL4dNefDx99lWOaDtbzkZ35c+TXlmsQH1VCcw4ZJ8uQN jkqvmk0oV9wOPNpA4ypNnpXxkDrxtgQ61znJjBur/pG5GpgktmAqhb/yXrOWN79Q dSxt4CkTHEOnBfQsl+YA5oih8o/2d8wQ6KQi3ocpfBDCAoSV/gsz0Y2Nnq389mVr +KXxOFIi9GeOmKAhBBDkudDnQng8A1GCblq+yZCVrMK7lP31M5D5MeB3Sps/4ZBw ==
X-ME-Sender: <xms:AVujXy8-meeamsRQ3jeunc0t0Y4SRHUcqBRQnUCfiaZlVADVQGuqgw> <xme:AVujXyvQZ6fpPz6cKhNQ7EYm4-gVMSg5GfPhvz5VqD3uJyKjhAW4YS0RyXR28HiZE PuTU3oF2K-xac5Dfw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtiedggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuggftrfgrth htvghrnhepgeegffefuddvffeflefgheektdeigfehffdtteetieeffefhfedugeduuedv vefhnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrd ejkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr lhhishhsrgestghoohhpvghrfidrihhn
X-ME-Proxy: <xmx:AVujX4CcPrXt24UadFBxCJ-Z3mhq4N_EYtf4apv-n_asv8lBanl4zw> <xmx:AVujX6cOJ_f7qEH0UFqLjfZJgCvYY3ak8pBLo1HB5EtFm1tYRV83Bg> <xmx:AVujX3MLA-Nmd-YpkkJ-pEakPVnpPFcOV8g_Nz9RJ7If1fBmEqiuvg> <xmx:AlujX8pjJqQxcgfOlKuxOceidBzV1YuugfCVmoyvN6szaI5QjZRogA>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.78]) by mail.messagingengine.com (Postfix) with ESMTPA id 5C0B532801F2; Wed, 4 Nov 2020 20:53:05 -0500 (EST)
From: Alissa Cooper <alissa@cooperw.in>
Message-Id: <24F0B132-1C89-415E-95B0-0A9D80D2C4AF@cooperw.in>
Content-Type: multipart/alternative; boundary="Apple-Mail=_21F25525-7123-41A7-A123-078EB63C73F4"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 4 Nov 2020 20:53:05 -0500
In-Reply-To: <486e2620-192a-e0c7-21c1-480cc1d5f69a@ericsson.com>
Cc: Rafa Marin-Lopez <rafa@um.es>, Mohit Sethi M <mohit.m.sethi@ericsson.com>, "i2nsf@ietf.org" <i2nsf@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" <draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org>
To: Mohit Sethi M <mohit.m.sethi=40ericsson.com@dmarc.ietf.org>
References: <159887332289.3841.15922213310506259874@ietfa.amsl.com> <F944D89A-BED3-4D6F-9A32-18E78E30ECCD@um.es> <486e2620-192a-e0c7-21c1-480cc1d5f69a@ericsson.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/bdCTtSqq4wHR2gAbm2Cu7hy0uoY>
Subject: Re: [Gen-art] [Last-Call] [I2nsf] Genart last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2020 01:53:10 -0000

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.com@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 <noreply@ietf.org <mailto:noreply@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
>>> I2nsf@ietf.org <mailto:I2nsf@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: rafa@um.es <mailto:rafa@um.es>
>> -------------------------------------------------------
>> 
>> 
>> 
>> 
>> 
>> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art