[I2nsf] AD Review: draft-ietf-i2nsf-applicability-09

Roman Danyliw <rdd@cert.org> Wed, 17 April 2019 19:23 UTC

Return-Path: <rdd@cert.org>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2FB8012012A for <i2nsf@ietfa.amsl.com>; Wed, 17 Apr 2019 12:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id otIBoPoTuxpD for <i2nsf@ietfa.amsl.com>; Wed, 17 Apr 2019 12:23:31 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu []) (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 3A4BC12003E for <i2nsf@ietf.org>; Wed, 17 Apr 2019 12:23:31 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu []) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x3HJNTia003171 for <i2nsf@ietf.org>; Wed, 17 Apr 2019 15:23:29 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x3HJNTia003171
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1555529009; bh=FYv0B+zHI7zyy3YElRRpBP/0ttKdcJAw3LhO/bZkIZA=; h=From:To:Subject:Date:From; b=UdCjP/Qugzv2kL5bO1QSgH8nET0+ftkfPygpv7hv4bnq0P00ae/5Wsc7TdiSsG08J zl3ag0Ze4uC15dcf4NzP/heNlGLUAgrSZs+swL2Og0lpGdMgvesGZO0+10gWkwUYtA MlH6vocSndGDzgmgmVq+ZAapp6yDL0lBcV6eYljk=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu []) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x3HJNPR2008432 for <i2nsf@ietf.org>; Wed, 17 Apr 2019 15:23:25 -0400
Received: from MARATHON.ad.sei.cmu.edu ([]) by CASSINA.ad.sei.cmu.edu ([]) with mapi id 14.03.0439.000; Wed, 17 Apr 2019 15:23:24 -0400
From: Roman Danyliw <rdd@cert.org>
To: "i2nsf@ietf.org" <i2nsf@ietf.org>
Thread-Topic: AD Review: draft-ietf-i2nsf-applicability-09
Thread-Index: AdT1UCvGm5NYaV78So67XP7+f7eJBg==
Date: Wed, 17 Apr 2019 19:23:23 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B333BED6@marathon>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/adPSY8o8t1luOE8dNGfU78Oy3iY>
Subject: [I2nsf] AD Review: draft-ietf-i2nsf-applicability-09
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2019 19:23:34 -0000


I'm picking up where ekr left off (https://mailarchive.ietf.org/arch/msg/i2nsf/bVTGfSXR70UcFkwfkV4FsNHg8uo) with an AD review of draft-ietf-i2nsf-applicability-09.

(1) Section 1.  Please do not expand NSF again the second sentence.  The acronym NSF was defined in the first sentence.

(2) Global Typo - s/funcional/functional/

(3) Section 1.  I had difficulty understanding the sentence:

"Note that Network Security Function (NSF)  is defined as a
   funcional  block  for a security service within an I2NSF framework that
   has well-defined I2NSF NSF-facing interface and other external
   interfaces and well-defined functional behavior [NFV-Terminology]."

** I'm not clear on what a functional block is and [NFV-Terminology] doesn't define it (although it does define other things also using this terminology)

** Why is this NSF definition different than the one provided in RFC8329 - "Network Security Functions (NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions to which the packet is associated" or RFC8192, "An NSF is a function that is used to ensure integrity, confidentiality, or availability of network communication; to detect unwanted network activity; or to block, or at least mitigate, the effects of unwanted activity."

**Why use the [NVF-Terminology] citation?  It does not appear to have an entry for NSF in the terms/definitions.

(4) Section 1.  Per "The I2NSF framework allows ... by utilizing the capabilities of such products and the virtualization of security functions in the NFV platform", I don't understand what the second clause ("by utilizing ...") is adding.  It seems to simply restate  that the products have capabilities and will be virtualized (which is implicit in the NFV).

(5) Section 1.  Per "In the I2NSF framework, each NSF initially registers the profile of its own capabilities into the system in order for themselves to be available in the system", this sentence doesn't parse for me.

Do you mean, "In the I2NSF framework, each NSF initially registers a profile of its capabilities in the system"?  If so, I think clarity of what system (I think "I2NSF system") is being referenced is needed.

(6) Section 1.  Per "In addition, the Security Controller ...", this sentence introduces the concept of a Security Controller but doesn't define it.  Also, this seems like a level of detail not needed in the introduction.

(7) Section 2, 

This document uses the terminology described in [RFC7665], [RFC7149],
   [ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture],
   [ITU-T.X.1252], [ITU-T.X.800], [NFV-Terminology], [RFC8329],
   [i2nsf-terminology], [consumer-facing-inf-dm], [i2nsf-nsf-cap-im],
   [nsf-facing-inf-dm], [registration-inf-dm], and
   [nsf-triggered-steering ].  

This sentence has 15 references covering hundreds of pages as having the relevant terminology.  Are all of them needed?  That's seems like a lot background reading.

(8) Figure 1.  I found it confusing that this Figure 1 diagram didn't use the same names as Figure 1 of [RFC8329].  Specifically, why did the "Network Operator Management System" get renamed a "Security Controller"?

(9) Section 3.  Recommend the following editorial change since none of the third paragraph has anything to do with the NSF-Facing Interface:

OLD: Finally, the Security Controller sends the generated low-level security policies to the NSFs [i2nsf-nsf-cap-im][nsf-facing-inf-dm].

NEW: Finally, the Security Controller sends the generated low-level security policies to the NSFs [i2nsf-nsf-cap-im][nsf-facing-inf-dm] via the NSF Facing Interface.

DROP:  The Security Controller requests NSFs to perform low-level security services via the NSF-Facing Interface.  

(10) Section 3.  Per the final sentence of paragraph 2, why is [i2nsf-nsf-cap-im] appropriate?  Doesn't the Security Controller use only the YANG module from [nsf-facing-inf-dm]?

(11) Section 3.  Per "Note that an inside attacker at the DMS can seriously weaken the I2NSF system ...", I concur with the assessment that a DMS can subvert the I2NSF system.  Three related points:

** The boundary/scope of an I2NSF system wasn't  clear to me.  It appears to me that an I2NSF system is security controller + NSFs.  There are several interfaces defined for the controller and NSFs.  Everything else (e.g., DMS, I2NSF user) is outside the scope of the I2NSF system, correct?  I draw attention to this distinction because identifying where this insider is located needs to be clearer.

** If the DMS can provide the software package for the NSF, I'm not sure how the insider threat is mitigated.  The attacker can already run a software load of her choice on your network (that you have permitted).

** Per https://mailarchive.ietf.org/arch/msg/i2nsf/Xc92QkEPgRWC3FKuRvnaiNNFY2o, I concur with ekr that the text needs to be clearer on what the DMS can do to the I2NSF system.

(12) Section 3, Per "On the other hand, an access to running (online) NSFs should be allowed only to the Security Controller, not the DMS.", this sentence isn't clear to me.

** It doesn't parse so I don't know who is supposed to get what access -- specifically, "an access to running NSFs"

** "running (online) NSFs" is proposing an operational construct which is also not clear to me.  It that the equivalent of saying in production?  If it means production, is there a distinction being made between interacting with the DMS during the time of provisioning and then after the fact?

(13) Section 3, Per "Also, the Security Controller can detect and prevent inside attacks by monitoring the activity of all the DMSs ... through the I2NSF NSF monitoring capability", is the monitoring interface also capable of observing the DMS?  I ask because the monitoring interface is described in RFC8329 as part of I2NSF NSF-Facing Interface (Section 3.2).  The Registration Interface description (Section 3.3 of RFC8329) makes no reference to any monitoring capability.

(14) Section 3, I'm not clear on what is MTI or the alternatives.  The text says "The Consumer-Facing Interface ... can be implemented ... by [consumer-facing-inf-dm]" and "the NSF facing interface ... can be implemented using NETCONF ... [with] ... the data model defined in [nsf-facing-inf-dm]".  Why can?  If not with those references then with what?

(15) Section 3.  What it intentional to say that the Consumer interface can be RESTCONF+YANG (with a reference); the NSF-Facing Interface is NETCONF (but YANG with no reference); and the registration interface is RESTCONF (no reference to YANG)?

(16) Section 4.  I found the term "an example XML code" vague given that this document is supposed to be an applicability statement highlighting I2NSF.  To what schema does this XML conform?  Is this a notional example or a complete instance?  On what interface would this have been sent?

(17) Section 4.  Grammatical Nit.

s/it is assumed that an NSF of firewall/
/it is assumed than a firewall NSF/

s/NSF of web filter/
/web filter NSF/

(18) Section 5.  What is the purpose of including this section if there is an entire draft (draft-hyun-i2nsf-nsf-triggered-steering) focused on the topic?

(19) Section 5, "To trigger an advanced security action in the I2NSF architecture, the current NSF appends a metadata describing the security capability required for the advanced action to the suspicious packet and sends the packet to the classifier."

** Editorial nit: s/NSF appends a metadata/NSF appends metadata/
** What is the reference for this meta-data format?

(20) Section 6.  What is the role of the DMS is this scenario?  Why does the controller need to rely on [NFV MANO] if all information about the capabilities is already provided by the DMS?  Since the SDN and other NSF operate using the same data model/interface, isn't the different between an SDN and NSF opaque to the controller?  I would have assumed that an SDN is simply a specific type of NSF with particular capabilities.

(21) Section 6.  "By taking advantage of this capability of SDN, it is possible to optimize the process of security service enforcement in the I2NSF system." The proposed optimization isn't evident from this text.

(22) Section 6.  "Especially, SDN forwarding elements enforce simple packet filtering rules that can be translated into their packet forwarding rules, whereas NSFs enforce NSF-related security rules requiring the security capabilities of the NSFs." 

** I found the use of the word "Especially" confusing
** I am not sure what distinction is being made between the SDN forwarding and NSF rules.

(23) Section 6, "For this purpose, the Security Controller instructs the SDN Controller via NSF-Facing Interface so that SDN forwarding elements can perform the required security services with flow tables under the supervision of the SDN Controller."

** I wasn't sure what the "for this purpose" was referencing, what "purpose"?

(24) Section 6.  Editorial Nit.

"The following subsections introduce three use cases for cloud-based security services: (i) firewall system, (ii) deep packet inspection system, and (iii) attack mitigation system.  [RFC8192]"

The following subsections introduce three use cases from [RFC8192] for cloud-based security services: (i) firewall system, (ii) deep packet inspection system, and (iii) attack mitigation system."

(25) Section 6.1 - 6.3.  It wasn't evident to me why these sections were in the document.  The described procedures and benefits didn't read as being I2NSF specific and appear to primarily describe what's happening in the SDN (and not using the defined I2NSF interfaces).

(26) Section 6.3, Typo. s/the the/the/

(27) Section 7.  "Those NSFs are created or removed by a virtual network functions manager (VNFM) in the NFV architecture that performs the life-cycle management of VNFs.  The Security Controller controls and monitors the configurations (e.g., function parameters and security policy rules) of VNFs."

Is the VNFM in scope for I2NSF?

If the Security Controller monitors/controls the VNFs, is it using [nsf-monitoring-dm] and [nsf-facing-inf-dm]?