Hi Linda and Paul! I’ve seen the updates to my comments. My apologizes for the delay in reviewing and commenting on them. Please expect feedback early next week.
Roman From: Linda Dunbar [mailto:dunbar...@gmail.com] Sent: Thursday, May 30, 2019 6:45 PM To: Roman Danyliw <r...@cert.org> Cc: i2nsf@ietf.org Subject: Editors have addressed all your comments to draft-ietf-i2nsf-applicability-09 , can you move it forward to IESG? Roman, The editors have all your comments to draft-ietf-i2nsf-applicability-09, they have uploaded the revised version (draft-ietf-i2nsf-applicability-11). the attached documents highlight their changes to address your comments. can you move it forward to IESG? Thank you very much Linda Dunbar From: Mr. Jaehoon Paul Jeong <jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>> Sent: Sunday, May 26, 2019 8:00 PM To: Roman Danyliw <r...@cert.org<mailto:r...@cert.org>> Cc: Yoav Nir <ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>>; Jaehoon (Paul) Jeong <paulje...@skku.edu<mailto:paulje...@skku.edu>>; draft-ietf-i2nsf-applicabil...@ietf.org<mailto:draft-ietf-i2nsf-applicabil...@ietf.org>; linda.dun...@huawei.com<mailto:linda.dun...@huawei.com> Subject: Re: your comments to draft-ietf-i2nsf-applicability-09 have all been addressed, can you move it forward to IESG? Hi Roman, Could you review my revision and share your review with us in the i2nsf mailing list? As you may know, the progress of our I2NSF Applicability draft is so delayed after the WGLC. I hope we can make a fast progress Thanks. Best Regards, Paul 2019년 5월 17일 (금) 오전 12:23, Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>님이 작성: Roman, Thank you very much for the comments to draft-ietf-i2nsf-applicability-09. The draft authors have addressed them in the draft-ietf-i2nsf-applicability-11. Please see the attached letter on their changes to each of your comment. Can you move the draft forward to IESG? Thank you very much. Linda & Yoav From: Mr. Jaehoon Paul Jeong [mailto:jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>] Sent: Thursday, May 02, 2019 4:13 AM To: Roman Danyliw <r...@cert.org<mailto:r...@cert.org>>; Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>; Yoav Nir <ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>> Cc: i2nsf@ietf.org<mailto:i2nsf@ietf.org>; skku_secu-brain_...@googlegroups.com<mailto: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<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-i2nsf-applicability-10&data=02%7C01%7Cldunbar%40futurewei.com%7C176e649a0712434048a708d6e23ec320%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636945156539390558&sdata=fNWPkqJu6vWczL25A34FIRZ9bn%2FZX%2Ba6jqNU2GvsxVk%3D&reserved=0> 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<mailto:r...@cert.org>> wrote: Hi! I'm picking up where ekr left off (https://mailarchive.ietf.org/arch/msg/i2nsf/bVTGfSXR70UcFkwfkV4FsNHg8uo<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fi2nsf%2FbVTGfSXR70UcFkwfkV4FsNHg8uo&data=02%7C01%7Cldunbar%40futurewei.com%7C176e649a0712434048a708d6e23ec320%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636945156539400552&sdata=lfeRnF5W3n%2BKZiE5Qg%2BUVbcKwDPNsZsLykcdWGQ5sSk%3D&reserved=0>) 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<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fi2nsf%2FXc92QkEPgRWC3FKuRvnaiNNFY2o&data=02%7C01%7Cldunbar%40futurewei.com%7C176e649a0712434048a708d6e23ec320%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636945156539400552&sdata=RuQAtjrDt%2BsS1ICnjJh1itqbMRAAPpL0ftoibjBJJVw%3D&reserved=0>, 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 I2nsf@ietf.org<mailto:I2nsf@ietf.org> https://www.ietf.org/mailman/listinfo/i2nsf<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi2nsf&data=02%7C01%7Cldunbar%40futurewei.com%7C176e649a0712434048a708d6e23ec320%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636945156539410549&sdata=Yv40HJnxj9LEt0Z3p2DgPe2njwxGYA0clXSeVOV0rP0%3D&reserved=0> -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>, paulje...@skku.edu<mailto:paulje...@skku.edu> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcpslab.skku.edu%2Fpeople-jaehoon-jeong.php&data=02%7C01%7Cldunbar%40futurewei.com%7C176e649a0712434048a708d6e23ec320%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636945156539410549&sdata=BXO3w6E%2FSKZ13p5ohj%2FpboZK8wse0xZlIOxO38MSYF8%3D&reserved=0>
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
