On Thu, Dec 27, 2018 at 7:21 PM Mr. Jaehoon Paul Jeong < [email protected]> wrote:
> Eric, > Let me answer your further questions below. > > On Thu, Dec 27, 2018 at 11:59 PM Eric Rescorla <[email protected]> wrote: > >> >> >> On Wed, Dec 26, 2018 at 6:42 PM Mr. Jaehoon Paul Jeong < >> [email protected]> wrote: >> >>> Hi Eric, >>> Here are my answers inlines below. >>> >>> On Thu, Dec 27, 2018 at 3:44 AM Eric Rescorla <[email protected]> wrote: >>> >>>> Paul, >>>> >>>> Thanks for your new version. Some responses below. >>>> >>>> >>>> On Tue, Dec 25, 2018 at 6:42 AM Mr. Jaehoon Paul Jeong < >>>> [email protected]> wrote: >>>> >>>>> Hi Eric, Linda and Yoav, >>>>> I have reflected all the comments from Eric and submitted the revision >>>>> -08 as follows: >>>>> https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-08 >>>>> >>>>> The changes are described in Appendix A of -08 document as follows: >>>>> >>>>> ------------------------------------------------------------------------------------------------- >>>>> Appendix A. Changes from draft-ietf-i2nsf-applicability-07 >>>>> >>>>> The following changes have been made from >>>>> draft-ietf-i2nsf-applicability-07: >>>>> >>>>> o This version has reflected all the comments from Eric Rescorla >>>>> who >>>>> is a Security Area Director as follows. >>>>> >>>>> o In Section 1, Network Security Function (NFV) is defined in the >>>>> viewpoint of the I2NSF framework. >>>>> >>>>> o In Section 1, a user using the I2NSF User is clarified as a >>>>> system >>>>> administrator in the I2NSF framework. >>>>> >>>>> o In Section 1, as the applicability of the I2NSF framework, four >>>>> different scenarios are represented with a standard bulleted >>>>> list. >>>>> >>>>> o The standard document about ETSI-NFV is moved to Normative >>>>> References. >>>>> >>>>> o In Section 2, key terms (e.g., Network Function, Network Security >>>>> Function, Network Functions Virtualization, and Servive Function >>>>> Chaining) are internally defined along with the reference to open >>>>> specifications. >>>>> >>>>> o In Section 2, the definition of Firewall is corrected such that >>>>> some suspicious packets are inspected by the firewall rather than >>>>> every packet. >>>>> >>>>> o In Section 3, for a Developer's Management System, the problem of >>>>> an inside attacker is addressed, and a possible solution for the >>>>> inside attacks is suggested through I2NSF NSF monitoring >>>>> functionality. >>>>> >>>> >>>> I'm still pretty concerned about this. Standardizing a situation in >>>> which the >>>> developer of your firewall has real-time management-level access to >>>> that firewall seems extremely insecure, especially when that access is >>>> authenticated via conventional credentials that are online as part of >>>> the transaction (as opposed to software builds which can be signed >>>> offline). This doesn't seem like a best practice. Why is it necessary? >>>> >>> >>> >>>> => The developer of a firewall does not have real-time >>> management-level access >>> even though its management system works the control plane as part >>> of the I2NSF system. >>> The developer's management system provides the Security >>> Controller with >>> the interface (i.e., Registration Interface) that is used to >>> register the capability of >>> the developer's security network function (i.e., firewall), to >>> search an NSF for the required capability for a high-level security policy, >>> and to help the lifecycle management >>> of such an NSF for the Security Controller through an NFV >>> interface (i.e., Ve-Vnfm interface) with the NFV's MANO. >>> >> >> I don't understand the distinction you are drawing here. Under what >> conditions can the developer modify the behavior of the I2NSF system? Can >> it do so at any time and without explicit action by the admin. >> >> => The developer means a security solution vendor (e.g., McAfee and > Symantec) who provides the I2NSF system with security solutions, > such as firewall, web filter, DPI, IDS/IPS, and DDoS-attack > mitigator. Actually, the developer's management system > cannot modify the behavior of the I2NSF system in run-time as long > as the vendor doesn't have any backdoor to > their developer's management system. > This developer's management system facilitates the security service > government by the Security Controller > by providing the Security Controller with the Registration > Interface for the capability registration and > instantiation/de-instantiation > of the image of a security service function. > Thus, only the administrator can modify the behavior of the I2NSF > system. > > Maybe, > Diego Lopez can clarify my answer because he is the editor of RFC > 8329 (Framework for Interface to Network Security Functions): > https://tools.ietf.org/html/rfc832 > <https://tools.ietf.org/html/rfc8329> > Yeah, I'm not really following this. What functions can the Developer perform on the system. o In Section 4, an XML file for the RESTCONF/YANG for the time- >>>>> dependent web access control is pointed out with a reference to >>>>> the Consumer-Facing Interface's data model >>>>> [consumer-facing-inf-dm]. >>>>> >>>> >>>> I didn't follow this change. The example you give of a high level >>>> security >>>> policy is clearly freeform text and then you talk about XML. Is this >>>> just >>>> example a summary of the semantics of something which would actually be >>>> an >>>> XML file? Something else? >>>> >>> >>> => Even though the high-level security policy looks like a freeform >>> text, it is formatted >>> in an XML according to the high-level security policy YANG model >>> for the Consumer-Facing Interface. >>> Yes, it is just an example of a summary of the semantics for such >>> a high-level security policy, >>> which is represented as an XML file. >>> Here it an XML file for the web filter from the Consumer-Facing >>> Interface Data Model document >>> ( >>> https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-02 >>> ): >>> >>> You can see the XML file from >>> >>> https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-02#page-49 >>> >>> <?xml version="1.1" encoding="UTF-8"?> >>> <rpc message-id="4" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0"> >>> <edit-config> >>> <target> >>> <running/> >>> </target> >>> <config> >>> <i2nsf-cf-interface-wf-req nc:operation="create"> >>> <policy-wf> >>> <rule-wf> >>> <rule-wf-id>03</rule-wf-id> >>> <rule-wf-name>wf-policy-example</rule-wf-name> >>> <rule-wf-date>2018.10.26/14:03:17</rule-wf-date> >>> <event> >>> <event-id>04</event-id> >>> <event-name>wf</event-name> >>> <event-date>2018.10.26/14:03:17</event-date> >>> <event-type>wf</event-type> >>> <event-map-group>04</event-map-group> >>> <enable>True</enable> >>> </event> >>> <condition> >>> <condition-id>04</condition-id> >>> <source-ip>192.168.1.3</source-ip> >>> <destination-url>www.facebook.com</destination-url> >>> <time-information> >>> <begin-time>09:00</begin-time> >>> <end-time>18:00</end-time> >>> </time-information> >>> <match-direction>default</match-direction> >>> <exeption>00</exeption> >>> </condition> >>> <action> >>> <action-id>04</action-id> >>> <action-name>action-wf</action-name> >>> <action-date>2018.10.26/14:03:17</action-date> >>> <primary-action>REJECT</primary-action> >>> <secondary-action>LOG</secondary-action> >>> </action> >>> <precedence>none</precedence> >>> <owner> >>> <owner-id>03</owner-id> >>> <name>i2nsf-admin</name> >>> </owner> >>> </rule-wf> >>> </policy-wf> >>> </i2nsf-cf-interface-wf-req> >>> </config> >>> </edit-config> >>> </rpc> >>> => In the above, source ip is used for the employees. >>> Instead of the source ip, we can make and use "source group" for >>> employees that can be translated >>> into a set of IP addresses of the source group. >>> >> >> You need to make this clear, then. It would probably be easier to just >> show the XML and then provide the text summary. >> >> => Okay. I will include a simplified example XML code for web filter > and provide the text summary as below. > > This service scenario assumes that an enterprise network > administrator wants to control the staff members' access to a > particular Internet service (e.g., Example.com) during business > hours. The following is an example high-level security policy rule > for a web filter that the administrator requests: Block the staff > members' access to Example.com from 9 AM to 6 PM. > Here is an example XML code for this web filter: > <I2NSF> > <name>block_website</name> > <cond> > <src>Staff_Member's_PC</src> > <dest>Example.com</dest> > <time-span-start>9:00AM</time-span-start> > <time-span-end>-6:00PM</time-span-end> > </cond> > <action>block<action> > </I2NSF> > > The security policy name is "bloc_website" with the tag "name". > The filtering condition has the source group "Staff_Member's_PC" with > the tag "src", > the destination website "Example.com" with the tag "dest", > the filtering start time is the time "9:00AM" with the tag " > time-span-start", > and the filtering end time is the time "6:00PM" with the tag " > time-span-end". > The action is to "block" the packets satisfying the above condition, > that is, to drop those packets > LGTM. > >> >> o In Section 6, the definitions of an SDN forwarding element and an >>>>> NSF are clarified such that an SDN forwarding element is a switch >>>>> running as either a hardware middle box or a software virtual >>>>> switch, and an NSF is a virtual network function for a security >>>>> service. >>>>> >>>> >>>> This wasn't clear to me either. Based on this text it would seem that >>>> you could run an NSF on an SDN element, so it's not clear why they >>>> are disjoint sets. Can you give me more information here? >>>> >>> >>> => An SDN switch can run as a virtual network function like an NSF, but >>> the main functionality of the SDN switch is packet forwarding with a flow >>> table along with simple filtering rules. More complicated security services >>> can be done at dedicated NSFs. For example, there is the Open Virtual >>> Switch (OVS) project for such a software-based SDN switch: >>> https://www.openvswitch.org >>> >>> Thus, the SDN switches and NSFs are logically disjoint sets though all >>> of them can run physically as virtual network functions. >>> >> >> I'm sorry, this still isn't clear, at least to me. How can I look at a >> given software element and determine whether it's an NSF or a virtualized >> SDN switch? >> > > => The distinction is logically done such that the NFV system having the > I2NSF system categorizes some VNFs as NSFs for dedicated security services > and some VNFs as virtualized SDN switches for packet switching and > simple filtering rule enforcement. > > If there is an expert in the NFV, please let us know for further > clarification. > I'm not following this either, so that would definitely help. -Ekr > Thanks. > > Best Regards, > Paul > > >> >> -Ekr >> >>> >>> If you have further questions, please let me know. >>> >>> Thanks. >>> >>> Best Regards, >>> Paul >>> >>>> >>>> -Ekr >>>> >>>> >>>>> o In Section 6.3, a flow forwarding path management scheme in >>>>> [AVANT-GUARD] is described in a self-contained way as follows. >>>>> For DDoS-attack mitigation, the forwarding of traffic flows in >>>>> switches can be dynamically configured such that malicious >>>>> traffic >>>>> flows are handled by the paths separated from normal traffic >>>>> flows >>>>> in order to minimize the impact of those malicious traffic on the >>>>> the servers. This flow path separation can be done by a flow >>>>> forwarding path management scheme based on [AVANT-GUARD]. >>>>> >>>>> o Some typos are corrected such as "Interner -> Internet", >>>>> "Registation -> Registration", "The low-level security rules for >>>>> web filter checks -> The low-level security rules for web filter >>>>> check", "fltering -> filtering", "illegal packets -> malicious >>>>> packets", "manipulate rules -> configure rules", "managenent -> >>>>> management", and "DDoS-attack mitigation operations -> >>>>> DDoS-attack >>>>> mitigation". >>>>> >>>>> ------------------------------------------------------------------------------------------------- >>>>> >>>>> Thanks and Merry Christmas! >>>>> >>>>> Best Regards, >>>>> Paul >>>>> >>>>> On Fri, Dec 21, 2018 at 11:33 PM Eric Rescorla <[email protected]> wrote: >>>>> >>>>>> Rich version of this review at: >>>>>> https://mozphab-ietf.devsvcdev.mozaws.net/D3181 >>>>>> >>>>>> >>>>>> I found a number of typographical and grammar errors. Please give this >>>>>> document a thorough read. >>>>>> >>>>>> IMPORTANT >>>>>> S 1. >>>>>> > >>>>>> > Interface to Network Security Functions (I2NSF) defines a >>>>>> framework >>>>>> > and interfaces for interacting with Network Security Functions >>>>>> > (NSFs). The I2NSF framework allows heterogeneous NSFs >>>>>> developed by >>>>>> > different security solution vendors to be used in the Network >>>>>> > Functions Virtualization (NFV) environment [ETSI-NFV] by >>>>>> utilizing >>>>>> >>>>>> Much of this document cannot be understood without reading ETSI-NFV, >>>>>> so it has to be a normative reference. It also would be helpful to >>>>>> provide a link. >>>>>> >>>>>> >>>>>> S 2. >>>>>> > This document uses the terminology described in [RFC7149], >>>>>> > [ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture], >>>>>> > [ITU-T.X.1252], [ITU-T.X.800], [RFC8329], [i2nsf-terminology], >>>>>> > [consumer-facing-inf-im], [consumer-facing-inf-dm], >>>>>> > [i2nsf-nsf-cap-im], [nsf-facing-inf-dm], >>>>>> [registration-inf-dm], and >>>>>> > [nsf-triggered-steering]. In addition, the following terms are >>>>>> >>>>>> Every term in this document needs to be understandable without >>>>>> reference to closed specifications or internally defined. Please >>>>>> ensure that this is so, >>>>>> >>>>>> >>>>>> S 3. >>>>>> > used for the I2NSF NSF-Facing Interface. >>>>>> > >>>>>> > The Registration Interface between the Security Controller and >>>>>> the >>>>>> > Developer's Management System can be implemented by RESTCONF >>>>>> > [RFC8040]. The data model defined in [registration-inf-dm] >>>>>> can be >>>>>> > used for the I2NSF Registration Interface. >>>>>> >>>>>> What role does the Developer's Management System play in this? I think >>>>>> this refers to the text above starting with "The developers (or >>>>>> vendors)...". Is that correct? >>>>>> >>>>>> Assuming I am correct, this seems like a potentially serious security >>>>>> vulnerability in this design in that it potentially allows an inside >>>>>> attacker at the developer to seriously weaken a system's security. >>>>>> What protections exist to prevent this? >>>>>> >>>>>> >>>>>> S 4. >>>>>> > administrator wants to control the staff members' access to a >>>>>> > particular Interner service (e.g., Example.com) during business >>>>>> > hours. The following is an example high-level security policy >>>>>> rule >>>>>> > that the administrator requests: Block the staff members' >>>>>> access to >>>>>> > Example.com from 9 AM to 6 PM. The administrator sends this >>>>>> high- >>>>>> > level security policy to the Security Controller, then the >>>>>> Security >>>>>> >>>>>> The text above suggests that high-level policies are via >>>>>> RESTCONF/YANG, but this is clearly freeform text. >>>>>> COMMENTS >>>>>> S 1. >>>>>> > >>>>>> > 1. Introduction >>>>>> > >>>>>> > Interface to Network Security Functions (I2NSF) defines a >>>>>> framework >>>>>> > and interfaces for interacting with Network Security Functions >>>>>> > (NSFs). The I2NSF framework allows heterogeneous NSFs >>>>>> developed by >>>>>> >>>>>> Please define "Network Security Functions" here. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> S 1. >>>>>> > functions in the NFV platform. 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. >>>>>> In >>>>>> > addition, the Security Controller is validated by the I2NSF >>>>>> Client >>>>>> > (also called I2NSF User) that the user is employing, so that >>>>>> the user >>>>>> > can request security services through the Security Controller. >>>>>> >>>>>> In this case the user is the system administrator. >>>>>> >>>>>> >>>>>> S 1. >>>>>> > [RFC7149] to provide different security functionality such as >>>>>> > firewalls [opsawg-firewalls], Deep Packet Inspection (DPI), and >>>>>> > Distributed Denial of Service (DDoS) attack mitigation; (iv) >>>>>> the use >>>>>> > of NFV as supporting technology. The implementation of I2NSF >>>>>> in >>>>>> > these scenarios has allowed us to verify the applicability and >>>>>> > effectiveness of the I2NSF framework for a variety of use >>>>>> cases. >>>>>> >>>>>> This would be easier to read with a standard bulleted list. >>>>>> >>>>>> >>>>>> S 2. >>>>>> > network resources, which facilitates the design, delivery >>>>>> and >>>>>> > operation of network services in a dynamic and scalable >>>>>> manner >>>>>> > [ITU-T.Y.3300]. >>>>>> > >>>>>> > o Firewall: A service function at the junction of two network >>>>>> > segments that inspects every packet that attempts to cross >>>>>> the >>>>>> >>>>>> Nit: It might not inspect *every* packet. >>>>>> >>>>>> >>>>>> S 4. >>>>>> > >>>>>> > 4. Time-dependent Web Access Control Service >>>>>> > >>>>>> > This service scenario assumes that an enterprise network >>>>>> > administrator wants to control the staff members' access to a >>>>>> > particular Interner service (e.g., Example.com) during business >>>>>> >>>>>> Nit: "Internet" >>>>>> >>>>>> >>>>>> S 4. >>>>>> > inspection capability is required to check whether the target >>>>>> URL of >>>>>> > a received packet is in the Example.com domain or not. >>>>>> > >>>>>> > The Security Controller maintains the security capabilities of >>>>>> each >>>>>> > NSF running in the I2NSF system, which have been reported by >>>>>> the >>>>>> > Developer's Management System via the Registation interface. >>>>>> Based >>>>>> >>>>>> Nit: "Registration" >>>>>> >>>>>> >>>>>> S 4. >>>>>> > currently using the network. Based on the retrieved >>>>>> information, the >>>>>> > Security Controller generates low-level security rules to check >>>>>> > whether the source IP address of a received packet matches any >>>>>> one >>>>>> > being used by a staff member. In addition, the low-level >>>>>> security >>>>>> > rules should be able to determine that a received packet is of >>>>>> HTTP >>>>>> > protocol. The low-level security rules for web filter checks >>>>>> that >>>>>> >>>>>> Nit: "rules"... "checks" disagree. >>>>>> >>>>>> >>>>>> S 6. >>>>>> > translated into their packet forwarding rules, whereas NSFs >>>>>> enforce >>>>>> > NSF-related security rules requiring the security capabilities >>>>>> of the >>>>>> > NSFs. 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'm having some trouble understanding the difference here between NSFs >>>>>> and SDN elements. They both seem to be software controlled network >>>>>> elements. Is this just some continuum about CPU power? >>>>>> >>>>>> >>>>>> S 6. >>>>>> > can perform the required security services with flow tables >>>>>> under the >>>>>> > supervision of the SDN Controller. >>>>>> > >>>>>> > As an example, let us consider two different types of security >>>>>> rules: >>>>>> > >>>>>> > Rule A is a simple packet fltering rule that checks only the IP >>>>>> >>>>>> Nit: "filtering" >>>>>> >>>>>> >>>>>> S 6.2. >>>>>> > packets that have the same call-id. >>>>>> > >>>>>> > 6. The SDN Controller installs new rules (e.g., drop packets) >>>>>> into >>>>>> > underlying switches. >>>>>> > >>>>>> > 7. The illegal packets are dropped by these switches. >>>>>> >>>>>> "Illegal" is probably the wrong wrod here. >>>>>> >>>>>> >>>>>> S 6.3. >>>>>> > is helpful to determine security policies for such a >>>>>> network. >>>>>> > >>>>>> > 6.3. Attack Mitigation: Centralized DDoS-attack Mitigation System >>>>>> > >>>>>> > A centralized DDoS-attack mitigation can manage each network >>>>>> resource >>>>>> > and manipulate rules to each switch through a common server >>>>>> for DDoS- >>>>>> >>>>>> "manipulate rules to" is not grammatical. >>>>>> >>>>>> >>>>>> S 6.3. >>>>>> > >>>>>> > Servers are categorized into stateless servers (e.g., DNS >>>>>> servers) >>>>>> > and stateful servers (e.g., web servers). For DDoS-attack >>>>>> > mitigation, traffic flows in switches are dynamically >>>>>> configured by >>>>>> > traffic flow forwarding path management according to the >>>>>> category of >>>>>> > servers [AVANT-GUARD]. Such a managenent should consider the >>>>>> load >>>>>> >>>>>> 1. This seems hard to understand without this reference, which is not >>>>>> public. >>>>>> 2. "management" >>>>>> >>>>>> >>>>>> S 6.3. >>>>>> > mitigation, traffic flows in switches are dynamically >>>>>> configured by >>>>>> > traffic flow forwarding path management according to the >>>>>> category of >>>>>> > servers [AVANT-GUARD]. Such a managenent should consider the >>>>>> load >>>>>> > balance among the switches for the defense against DDoS >>>>>> attacks. >>>>>> > >>>>>> > The procedure of DDoS-attack mitigation operations in this >>>>>> system is >>>>>> >>>>>> "procedure of... operations" is ungrammatical >>>>>> >>>>>> >>>>> >>>>> -- >>>>> =========================== >>>>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>>>> Associate Professor >>>>> Department of Software >>>>> Sungkyunkwan University >>>>> Office: +82-31-299-4957 >>>>> Email: [email protected] >>>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>> <http://cpslab.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> >>> >> > > -- > =========================== > 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
