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:i2nsf-boun...@ietf.org] On Behalf Of Mr. Jaehoon Paul > Jeong > Sent: Thursday, May 02, 2019 5:13 AM > To: Roman Danyliw <r...@cert.org>; Linda Dunbar > <linda.dun...@huawei.com>; Yoav Nir <ynir.i...@gmail.com> > Cc: i2nsf@ietf.org; skku_secu-brain_...@googlegroups.com > 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 <r...@cert.org> 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 > I2nsf@ietf.org > 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: jaehoon.p...@gmail.com, paulje...@skku.edu Personal Homepage: > http://iotlab.skku.edu/people-jaehoon-jeong.php _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
