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

Mohit Sethi via Datatracker <noreply@ietf.org> Mon, 31 August 2020 11:28 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E40763A1290; Mon, 31 Aug 2020 04:28:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Mohit Sethi via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: last-call@ietf.org, draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org, i2nsf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.15.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159887332289.3841.15922213310506259874@ietfa.amsl.com>
Reply-To: Mohit Sethi <mohit.m.sethi@ericsson.com>
Date: Mon, 31 Aug 2020 04:28:42 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/qghXXTZ9xrgisVWtf_XwwaDkFSo>
Subject: [Gen-art] 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
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: Mon, 31 Aug 2020 11:28:43 -0000

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?

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

- Does the specification allow NSF's to derive many CHILD SAs?

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