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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Roman, Linda, and Yoav,
I have reflected Roman's questions and comments
in I2NSF Applicability Draft (version 10).
Here is the link of the revised draft:
https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-10

I send you my revision letter that describes my answers and reflection in
the text.

If you have questions and comments, please let me know.

Thanks.

Best Regards,
Paul


On Wed, Apr 17, 2019 at 9:23 PM Roman Danyliw <[e-mail]> wrote:

> Hi!
>
> 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.
>
> OLD:
> "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]"
>
> NEW:
> 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]?
>
> Roman
>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>


-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>