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

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

Hi Roman,
I have addressed all of your comments again and submitted version -12:
https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-12

I attach my revision letter.

Could you confirm that my addressing is good enough to move this draft
forward to the IESG submission?

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>