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

Rafa Marin-Lopez <rafa@um.es> Tue, 22 September 2020 06:41 UTC

Return-Path: <rafa@um.es>
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 696713A141C; Mon, 21 Sep 2020 23:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=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=um.es
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 b_0YC27lJ_FJ; Mon, 21 Sep 2020 23:41:52 -0700 (PDT)
Received: from mx02.puc.rediris.es (outbound6sev.lav.puc.rediris.es [130.206.19.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EAC3A1087; Mon, 21 Sep 2020 23:41:52 -0700 (PDT)
Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by mx02.puc.rediris.es with ESMTP id 08M6fltK002619-08M6fltL002619; Tue, 22 Sep 2020 08:41:47 +0200
Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id E0C44202EC; Tue, 22 Sep 2020 08:41:47 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon44.um.es
Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oGEzeFLs4m8P; Tue, 22 Sep 2020 08:41:47 +0200 (CEST)
Received: from [192.168.1.36] (198.red-2-138-84.dynamicip.rima-tde.net [2.138.84.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id DCB53204CC; Tue, 22 Sep 2020 08:41:45 +0200 (CEST)
From: Rafa Marin-Lopez <rafa@um.es>
Message-Id: <F944D89A-BED3-4D6F-9A32-18E78E30ECCD@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C4ED188E-B826-4AFE-B15A-249883FEA04B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Tue, 22 Sep 2020 08:41:44 +0200
In-Reply-To: <159887332289.3841.15922213310506259874@ietfa.amsl.com>
Cc: Rafa Marin-Lopez <rafa@um.es>, gen-art@ietf.org, i2nsf@ietf.org, last-call@ietf.org, draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org
To: Mohit Sethi <mohit.m.sethi@ericsson.com>
References: <159887332289.3841.15922213310506259874@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-FEAS-SPF: spf-result=pass, ip=155.54.212.171, helo=xenon44.um.es, mailFrom=rafa@um.es
Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.171 as permitted sender) smtp.mailfrom=rafa@um.es
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=tTmkIPBPCXKq5ieoN4hw51jxnD+AEe+1AYu7JQ/YxgM=; b=6KvoAc5jcKlDs6pRGxN9PCqKQ855Dh/w/RxtUWnDZKAB7wA81iWE9+dWW3raoAaxmuWyq6fZRP8G uPZKwzYOUm+Ti/gqxqogOGQWl9hG/AXxroN52V3aom655qszt3VVmBihnFcpkgCfq6dPMWe+G7lk VL2gkLGT7C3oMNPkmeLNQ4qn4Ueb6VwZxCIBY6blb+Y/enL7HE62xywJ2mOn9yP1aScKceIA1jBX G5+SW/md53HVAQx5OifxCqoO6x9g3eYuJAPemcdb27ooLR5Uqzwf09jlXfOI9VbjqXXwFxeVLaM7 2Q0W+6GS8kqP20pQ7pPpFaLbjLZpjBRiFed3eQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/UvtUROq8ZfdBq4p8aMhPas4zE_4>
Subject: Re: [Gen-art] [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: Tue, 22 Sep 2020 06:41:56 -0000

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> 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>.
> 
> 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
> 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
-------------------------------------------------------