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 <[email protected]> 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:[email protected]] On Behalf Of Mr. Jaehoon > Paul > > Jeong > > Sent: Thursday, May 02, 2019 5:13 AM > > To: Roman Danyliw <[email protected]>; Linda Dunbar > > <[email protected]>; Yoav Nir <[email protected]> > > Cc: [email protected]; [email protected] > > 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 <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/i2nsf > > > > > > > > -- > > =========================== > > Mr. Jaehoon (Paul) Jeong, Ph.D. > > Associate Professor > > Department of Software > > Sungkyunkwan University > > Office: +82-31-299-4957 > > Email: [email protected], [email protected] Personal Homepage: > > http://iotlab.skku.edu/people-jaehoon-jeong.php > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: [email protected], [email protected] Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
