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

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

Hi Roman,
I will review your comments during the weekend and answer them early next
week.

Thanks.

Best Regards,
Paul

On Wed, Jun 5, 2019 at 7:35 AM Roman Danyliw <[e-mail]> wrote:

> Hello Paul!
>
> Thank you for the extensive changes you have made.  See follow-up
> questions below.  If you don't see a previous item listed, please consider
> it resolved.
>
> Since your comments were made with a word attachment (no problem!), I'm
> just responding to my own original thread.
>
> > From: I2nsf [mailto:[e-mail]] On Behalf Of Mr. Jaehoon
> Paul
> > Jeong
> > Sent: Thursday, May 02, 2019 5:13 AM
> > To: Roman Danyliw <[e-mail]>; Linda Dunbar
> > <[e-mail]>; Yoav Nir <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicability-09
> >
> > 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/bVTGfSXR70UcFkwfkV4FsNHg8
> > uo) with an AD review of draft-ietf-i2nsf-applicability-09.
>
> [snip]
>
> > (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.
>
> Per -11, I’d recommend making the text even more concise.
>
> OLD: In the I2NSF framework, each NSF initially registers the profile of
> its own capabilities into the Security    Controller (i.e., network
> operator management system [RFC8329]) in the I2NSF system via Registration
> Interface [registration-inf-dm] so that each   NSF can be selected and used
> to enforce a given security policy from I2NSF User (i.e., network security
> administrator).
>
> NEW:
> In the I2NSF framework, each NSF initially registers the profile of its
> own capabilities with the Security Controller (i.e., network operator
> management system [RFC8329]) of the I2NSF system via the Registration
> Interface [registration-inf-dm].  This registration enables an I2NSF User
> (i.e., network security administrator) to select and use the NSF to enforce
> a given security policy.
>
> > (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.
>
> I appreciate all of the new text in -11, but I don't think we need all of
> it.  My concern is that some of it will unnecessarily duplicates text
> already in Section 3 and [i2nsf-terminology].  The new text “(i.e., network
> operator management system [RFC8329]).” sufficiently defines the
> controller.  The new text “Security Controller is defined as …” isn’t
> needed.
>
> > (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/Xc92QkEPgRWC3FKuRvnaiNNFY2
> > o, I concur with ekr that the text needs to be clearer on what the DMS
> can do
> > to the I2NSF system.
>
> Despite the changes in -11, I still need help understanding the flow
> between the security controller and DMS.  Like ekr posed in the thread
> above, I’m trying to understand how the software is loaded into the
> production I2NSF system.
>
> As I understand it, we’re talking about a software update process
> facilitated through a NETCONF interface via the Internet.  Section 5 of
> draft-hyun-i2nsf-registration-interface-dm says:
>
>    1)  Security Controller first recognizes the set of capabilities
>        (i.e., NSF Profile) or the signature of a specific NSF required
>        or wasted in the current system.
>
>    2)  Developer's Management System (DMS) matches the recognized
>        information to an NSF based on the information model definition.
>
>    3)  Developer's Management System creates or eliminates NSFs matching
>        with the above information.
>
>    4)  Security Controller can then add/remove the corresponding NSF
>        instance to/from its list of available NSF instances in the
>        system.
>
> To test my understanding, the user interface sends a high-level action to
> the Security Controller (SC); the SC sends to the DMS what capabilities it
> wants; the DMS returns back what NSF (modules/packages/code) it has that
> meet these capabilities; the SC can then choose to download these NSF
> (modules/package/code) from the DMS and provision these newly downloaded
> NSF (modules/package/code) into the live system.  Is this correct?
>
> How is the new code transported from the DMS to the SC?  Is that in scope?
>
> > (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?
>
> See comment in #13 about consolidating all threat mitigation in the
> Security Considerations Section
>
> > (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.
>
> Per the following new text:
>
> However, the Security Controller can detect and prevent inside attacks by
> monitoring the activities of all the DMSs as well as the NSFs through the
> I2NSF NSF monitoring functionality [nsf-monitoring-dm]. Through the NSF
> monitoring, the Security Controller can monitor the activities and states
> of NSFs, and then can make a diagnosis to see whether the NSFs are working
> in normal conditions or in abnormal conditions including the insider
> threat. Note that the monitoring of the DMSs is out of scope for I2NSF.
>
> This still confusing to me.  The first sentence explicitly says that the
> Security Controller can monitoring the activities of all the DMSs, but the
> last sentence says monitoring the DMS is out of scope.
>
> As I understand it, the DMS is operated by a vendor outside of the
> deployed enclave of the I2NSF system.  Therefore, to me, this isn’t an
> insider threat but a supply chain attack.  Furthermore, “Note that an
> inside attacker at the DMS can seriously weaken the I2NSF system's
> security” is true.  However, it’s more than an inside attack.  An unwitting
> DMS vendor could be compromised and their infrastructure could be coerced
> into distributing modified NSF.
>
> I recommend moving all of this discussion about the insider threat/supply
> chain attacks and possible mitigation with monitoring into the Security
> Considerations.  Additionally, RFC8329 Section 4 doesn’t seem to:
>
> ** distinguish between a malicious and compromised provider – the
> mitigation would be different)
>
> ** a malicious/compromised DMS sending the wrong NSF (perhaps because the
> attacker can’t modify the code but can alter what gets sent)
>
> ** general caution of not bringing your network down through automated
> security action (using outside code) without prior testing
>
> > (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)?
>
> This comment resulted in a lot more text changes than anticipated.  I was
> intending to ask why certain interface mentioned the corresponding YANG
> modules (and other did not).  Given the new language, “The xxx interface
> _can_ be implemented as an _XML file_ ...”, a few additional questions:
>
> ** why the references to XML (in the new language)?
> ** why the use “can be implemented” (in the old and new language) because
> the alternative to the specified data model isn’t clear.
>
> Is it simpler to say, “The xxx interface _is_ implemented with the xxx
> interface YANG model [xxx-reference] using …{RESTCONF or NETCONF} which
> befits ...”?
>
> It looks like you some language has changed relative to RESTCONF vs.
> NETCONF.  This is the new summary:
> ** Consumer-Facing Interface = RESTCONF
> ** NSF-Facing interface = NETCONF
> ** Registration interface = NETCONF (was RESTCONF)
>
> I’d like to inquire about the consistency of this language with
> [draft-ietf-i2nsf-nsf-facing-interface-dm].  It’s Section 7 says that
> RESTCONF or NETCONF can both be used.
>
> > (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?
>
> Thanks for the changes from [draft-hyun-i2nsf-nsf-triggered-steering] to
> [RFC7665].  The followed edits more precisely use the reference (as having
> it after the “I2NSF architecture” made it read to me that this was the
> reference).
>
> Per Section 3,
> s/ Also, the I2NSF framework can enforce multiple chained NSFs for the
> low-level security policies by means of SFC techniques for the I2NSF
> architecture [RFC7665]./
> The I2NSF framework can chain multiple NSFs to implement low-level
> security policies with the SFC architecture [RFC7665]./
>
> Per Section 4,
> s/SFC technology can be utilized to support such packet forwarding in the
> I2NSF framework [RFC7665]/
> The SFC architecture [RFC7665] can be utilized to support such packet
> forwarding in the I2NSF framework/
>
> > (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?
>
> Thanks for the updated text.  I recommend being more precise with the
> following edit:
>
> OLD:
> To trigger an advanced security action in the I2NSF architecture, the
> current NSF appends metadata describing the security capability
> required for the advanced action to the suspicious packet to the
> network service header (NSH) of the packet [RFC8300].
>
> NEW:
> To trigger an advanced security action in the I2NSF architecture, the
> current NSF appends metadata describing the security capability
> required to the suspicious packet via a network service header (NSH)
> [RFC8300].
>
> > (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.
>
> All my questions are addressed with the new text.  Thanks.  I’d recommend
> looking at last few sentences of the new first and second paragraph of this
> section.  They appear to be saying a very similar thing.
>
> > (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.
>
> Thanks.  Check (20) because it appears this new language may introduce
> more duplicate 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.
>
> Thanks.  Check (20) because it appears this new language may introduce
> more duplicate text.  I think what you said for (21) obviates the need for
> this new language. It’s now clear what you mean (based on your language for
> (21)).
>
> > (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"?
>
> Editorial nit on the -11 edits.  s/ For the tasks for security enforcement
> (e.g., packet filtering)//
>
> > (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?
>
> Thanks for the additional language about being out of scope.  An editorial
> nit in this revised text:
>
> s/Note that the life-cycle management of VNFs are out of scope for I2NSF./
> Note that the life-cycle management of VNFs is out of scope for I2NSF./
>
> > If the Security Controller monitors/controls the VNFs, is it using [nsf-
> > monitoring-dm] and [nsf-facing-inf-dm]?
>
> Thanks for the additional references.  An editorial nit in the revised
> text:
>
> s/via NSF-Facing Interface along with NSF monitoring capability
> [nsf-facing-inf-dm][nsf-monitoring-dm]./
> via the NSF-Facing Interface along with the NSF monitoring capability
> [nsf-facing-inf-dm][nsf-monitoring-dm]./
>
> Regards,
> Roman
>
> > 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
>


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