--- 1/draft-ietf-i2nsf-applicability-07.txt 2018-12-25 07:13:37.773310666 -0800 +++ 2/draft-ietf-i2nsf-applicability-08.txt 2018-12-25 07:13:37.829312004 -0800 @@ -1,134 +1,175 @@ I2NSF Working Group J. Jeong Internet-Draft Sungkyunkwan University Intended status: Informational S. Hyun -Expires: April 25, 2019 Chosun University +Expires: June 28, 2019 Chosun University T. Ahn Korea Telecom S. Hares Huawei D. Lopez Telefonica I+D - October 22, 2018 + December 25, 2018 Applicability of Interfaces to Network Security Functions to Network- Based Security Services - draft-ietf-i2nsf-applicability-07 + draft-ietf-i2nsf-applicability-08 Abstract This document describes the applicability of Interface to Network Security Functions (I2NSF) to network-based security services in Network Functions Virtualization (NFV) environments, such as firewall, deep packet inspection, or attack mitigation engines. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. + Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 25, 2019. + This Internet-Draft will expire on June 28, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of + (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Time-dependent Web Access Control Service . . . . . . . . . . 5 - 5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . . 7 - 6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . . 8 - 6.1. Firewall: Centralized Firewall System . . . . . . . . . . 10 - 6.2. Deep Packet Inspection: Centralized VoIP/VoLTE - Security System . . . . . . . . . . . . . . . . . . . . . 12 + 3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Time-dependent Web Access Control Service . . . . . . . . . . 6 + 5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 8 + 6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 9 + 6.1. Firewall: Centralized Firewall System . . . . . . . . . . 12 + 6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security + System . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Attack Mitigation: Centralized DDoS-attack Mitigation - System . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . . 16 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 11. Informative References . . . . . . . . . . . . . . . . . . . . 19 - Appendix A. Changes from draft-ietf-i2nsf-applicability-06 . . . 21 + System . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 18 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 + 11.2. Informative References . . . . . . . . . . . . . . . . . 21 + Appendix A. Changes from draft-ietf-i2nsf-applicability-07 . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 - different security solution vendors to be used in the Network - Functions Virtualization (NFV) environment [ETSI-NFV] by utilizing - the capabilities of such products and the virtualization of security + (NSFs). 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]. + + 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 the + capabilities of such products and the virtualization of security 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. + addition, the Security Controller is validated by the I2NSF User + (also called I2NSF Client) that a system administrator (as a user) is + employing, so that the system administrator can request security + services through the Security Controller. This document illustrates the applicability of the I2NSF framework - with four different scenarios: (i) the enforcement of time-dependent - web access control; (ii) the application of I2NSF to a Service - Function Chaining (SFC) environment [RFC7665]; (iii) the integration - of the I2NSF framework with Software-Defined Networking (SDN) - [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. + with four different scenarios: + + 1. The enforcement of time-dependent web access control. + + 2. The application of I2NSF to a Service Function Chaining (SFC) + environment [RFC7665]. + + 3. The integration of the I2NSF framework with Software-Defined + Networking (SDN) [RFC7149] to provide different security + functionality such as firewalls [opsawg-firewalls], Deep Packet + Inspection (DPI), and Distributed Denial of Service (DDoS) attack + mitigation. + + 4. The use of Network Functions Virtualization (NFV) [ETSI-NFV] as a + 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. 2. Terminology - This document uses the terminology described in [RFC7149], + 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], [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 - defined below: + [ITU-T.X.1252], [ITU-T.X.800], [NFV-Terminology], [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 defined below: o Software-Defined Networking (SDN): A set of techniques that enables to directly program, orchestrate, control, and manage network resources, which facilitates the design, delivery and operation of network services in a dynamic and scalable manner [ITU-T.Y.3300]. + o Network Function: A funcional block within a network + infrastructure that has well-defined external interfaces and well- + defined functional behavior [NFV-Terminology]. + + o Network Security Function (NSF): A funcional block within a + security service within a network infrastructure that has well- + defined external interfaces and well-defined functional + behavior[NFV-Terminology]. + + o Network Functions Virtualization (NFV): A principle of separating + network functions (or network security functions) from the + hardware they run on by using virtual hardware abstraction + [NFV-Terminology]. + + o Service Function Chaining (SFC): The execution of an ordered set + of abstract service functions (i.e., network functions) according + to ordering constraints that must be applied to packets, frames, + and flows selected as a result of classification. The implied + order may not be a linear progression as the architecture allows + for SFCs that copy to more than one branch, and also allows for + cases where there is flexibility in the order in which service + functions need to be applied [RFC7665]. + o Firewall: A service function at the junction of two network - segments that inspects every packet that attempts to cross the - boundary. It also rejects any packet that does not satisfy - certain criteria for, for example, disallowed port numbers or IP - addresses. + segments that inspects some suspicious packets that attempt to + cross the boundary. It also rejects any packet that does not + satisfy certain criteria for, for example, disallowed port numbers + or IP addresses. o Centralized Firewall System: A centralized firewall that can establish and distribute policy rules into network resources for efficient firewall management. o Centralized VoIP Security System: A centralized security system that handles the security functions required for VoIP and VoLTE services. o Centralized DDoS-attack Mitigation System: A centralized mitigator @@ -167,24 +208,30 @@ policies from an I2NSF User, and identifies what types of security capabilities are required to meet these high-level security policies. The Security Controller then identifies NSFs that have the required security capabilities, and generates low-level security policies for each of the NSFs so that the high-level security policies are eventually enforced by those NSFs [policy-translation]. Finally, the Security Controller sends the generated low-level security policies to the NSFs [i2nsf-nsf-cap-im][nsf-facing-inf-dm]. The Security Controller requests NSFs to perform low-level security - services via the NSF-Facing Interface. The developers (or vendors) - inform the Security Controller of the capabilities of the NSFs - through the I2NSF Registration Interface [registration-inf-dm] for - registering (or deregistering) the corresponding NSFs. + services via the NSF-Facing Interface. As shown in Figure 1, with a + Developer's Management System, developers (or vendors) inform the + Security Controller of the capabilities of the NSFs through the I2NSF + Registration Interface [registration-inf-dm] for registering (or + deregistering) the corresponding NSFs. Note that an inside attacker + at the Development Management System can seriously weaken the I2NSF + system's security. For the detection and prevention of inside + attacks, the Security Controller needs to monitor the activity of all + the Development Management Systems as well as the NSFs through the + I2NSF NSF monitoring functionality [nsf-monitoring-dm]. The Consumer-Facing Interface between an I2NSF User and the Security Controller can be implemented using, for example, RESTCONF [RFC8040]. Data models specified by YANG [RFC6020] describe high-level security policies to be specified by an I2NSF User. The data model defined in [consumer-facing-inf-dm] can be used for the I2NSF Consumer-Facing Interface. The NSF-Facing Interface between the Security Controller and NSFs can be implemented using NETCONF [RFC6241]. YANG data models describe @@ -202,55 +249,60 @@ low-level security policies by means of SFC techniques for the I2NSF architecture described in [nsf-triggered-steering]. The following sections describe different security service scenarios illustrating the applicability of the I2NSF framework. 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 + particular Internet 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 + level security policy to the Security Controller. Refer to an XML + file for the high-level security policy of a time-based web-filter in + [consumer-facing-inf-dm], whose data model is defined by YANG, and + which is delivered over RESTCONF. + + After receiving the high-level security policy, the Security Controller identifies required security capabilities, e.g., IP address and port number inspection capabilities and URL inspection capability. In this scenario, it is assumed that the IP address and port number inspection capabilities are required to check whether a received packet is an HTTP packet from a staff member. The URL 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 + Developer's Management System via the Registration interface. Based on this information, the Security Controller identifies NSFs that can perform the IP address and port number inspection and URL inspection [policy-translation]. In this scenario, it is assumed that an NSF of firewall has the IP address and port number inspection capabilities and an NSF of web filter has URL inspection capability. The Security Controller generates low-level security rules for the NSFs to perform IP address and port number inspection, URL inspection, and time checking. Specifically, the Security Controller may interoperate with an access control server in the enterprise network in order to retrieve the information (e.g., IP address in use, company identifier (ID), and role) of each employee that is 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 - the target URL field of a received packet is equal to Example.com. + protocol. The low-level security rules for web filter check that the + target URL field of a received packet is equal to Example.com. Finally, the Security Controller sends the low-level security rules of the IP address and port number inspection to the NSF of firewall and the low-level rules for URL inspection to the NSF of web filter. The following describes how the time-dependent web access control service is enforced by the NSFs of firewall and web filter. 1. A staff member tries to access Example.com during business hours, e.g., 10 AM. @@ -393,32 +446,33 @@ | |Switch-1|-| Switch-2 |-|Switch-3|.......|Switch-m| | | | | |(Classifier)| | (SFF) | | | | | +--------+ +------------+ +--------+ +--------+ | +-------------------------------------------------------------------+ Figure 3: An I2NSF Framework with SDN Network Figure 3 shows an I2NSF framework [RFC8329] with SDN networks to support network-based security services. In this system, the enforcement of security policy rules is divided into the SDN - forwarding elements (e.g., switch) and NSFs. Especially, SDN + forwarding elements (e.g., switch running as either a hardware middle + box or a software virtual switch) and NSFs (e.g., firewall running in + a form of a virtual network function [ETSI-NFV]). 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. 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. 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 + Rule A is a simple packet filtering rule that checks only the IP address and port number of a given packet, whereas rule B is a time- consuming packet inspection rule for analyzing whether an attached file being transmitted over a flow of packets contains malware. Rule A can be translated into packet forwarding rules of SDN forwarding elements and thus be enforced by these elements. In contrast, rule B cannot be enforced by forwarding elements, but it has to be enforced by NSFs with anti-malware capability. Specifically, a flow of packets is forwarded to and reassembled by an NSF to reconstruct the attached file stored in the flow of packets. The NSF then analyzes the file to check the existence of malware. If the file contains @@ -528,26 +581,26 @@ A centralized VoIP/VoLTE security system can monitor each VoIP/VoLTE flow and manage VoIP/VoLTE security rules, according to the configuration of a VoIP/VoLTE security service called VoIP Intrusion Prevention System (IPS). This centralized VoIP/VoLTE security system controls each switch for the VoIP/VoLTE call flow management by manipulating the rules that can be added, deleted or modified dynamically. The centralized VoIP/VoLTE security system can cooperate with a network firewall to realize VoIP/VoLTE security service. - Specifically, a network firewall performs basic security checks of an - unknown flow's packet observed by a switch. If the network firewall - detects that the packet is an unknown VoIP call flow's packet that - exhibits some suspicious patterns, then it triggers the VoIP/VoLTE - security system for more specialized security analysis of the - suspicious VoIP call packet. + Specifically, a network firewall performs the basic security check of + an unknown flow's packet observed by a switch. If the network + firewall detects that the packet is an unknown VoIP call flow's + packet that exhibits some suspicious patterns, then it triggers the + VoIP/VoLTE security system for more specialized security analysis of + the suspicious VoIP call packet. The procedure of VoIP/VoLTE security operations in this system is as follows: 1. A switch forwards an unknown flow's packet to the SDN Controller, and the SDN Controller further forwards the unknown flow's packet to the Firewall for basic security inspection. 2. The Firewall analyzes the header fields of the packet, and figures out that this is an unknown VoIP call flow's signal @@ -567,21 +620,21 @@ 5. If, for example, the VoIP IPS regards the packet as a spoofed packet by hackers or a scanning packet searching for VoIP/VoLTE devices, it drops the packet. In addition, the VoIP IPS requests the SDN Controller to block that packet and the subsequent 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. + 7. The malicious packets are dropped by these switches. Existing SDN protocols can be used through standard interfaces between the VoIP IPS application and switches [RFC7149][ITU-T.Y.3300] [ONF-OpenFlow][ONF-SDN-Architecture]. Legacy hardware based VoIP IPS has some challenges, such as provisioning time, the granularity of security, expensive cost, and the establishment of policy. The I2NSF framework can resolve the challenges through the above centralized VoIP/VoLTE security system based on SDN as follows: @@ -606,34 +659,36 @@ o The establishment of policy: Policy should be established for each network resource. However, it is difficult to describe what flows are permitted or denied for VoIP IPS within a specific organization network under management. Thus, a centralized view 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- - attack mitigation (called DDoS-attack Mitigator). The centralized - DDoS-attack mitigation system defends servers against DDoS attacks - outside the private network, that is, from public networks. + and configure rules to each switch for DDoS-attack mitigation (called + DDoS-attack Mitigator) on a common server. The centralized DDoS- + attack mitigation system defends servers against DDoS attacks outside + the private network, that is, from public networks. 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 - balance among the switches for the defense against DDoS attacks. + 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]. This management 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 - as follows: + The procedure of DDoS-attack mitigation in this system is as follows: 1. A Switch periodically reports an inter-arrival pattern of a flow's packets to one of the SDN Controllers. 2. The SDN Controller forwards the flow's inter-arrival pattern to an appropriate security service application, such as DDoS-attack Mitigator. 3. The DDoS-attack Mitigator analyzes the reported pattern for the flow. @@ -670,48 +725,43 @@ o Performance: The performance of DDoS-attack mitigators is often slower than the link speed of network interfaces. The checking of DDoS attacks may reduce the performance of the network interfaces. DDoS-attack mitigators can be adaptively deployed among network switches, depending on network conditions in the framework. o The management of network resources: Since there may be hundreds of network resources in an administered network, the dynamic management of network resources for performance (e.g., load balancing) is a challenge for DDoS-attack mitigation. In the - framework, as dynamic network resource management, traffic flow - forwarding path management can handle the load balancing of - network switches [AVANT-GUARD]. With this management, the current - and near-future workload can be spread among the network switches - for DDoS-attack mitigation. In addition, DDoS-attack mitigation - rules can be dynamically added for new DDoS attacks. + framework, for dynamic network resource management, a flow + forwarding path management scheme can handle the load balancing of + network switches [AVANT-GUARD]. With this management scheme, the + current and near-future workload can be spread among the network + switches for DDoS-attack mitigation. In addition, DDoS-attack + mitigation rules can be dynamically added for new DDoS attacks. o The establishment of policy: Policy should be established for each network resource. However, it is difficult to describe what flows are permitted or denied for new DDoS-attacks (e.g., DNS reflection attack) within a specific organization network under management. Thus, a centralized view is helpful to determine security policies for such a network. So far this section has described the procedure and impact of the three use cases for network-based security services using the I2NSF framework with SDN networks. To support these use cases in the proposed data-driven security service framework, YANG data models described in [consumer-facing-inf-dm], [nsf-facing-inf-dm], and [registration-inf-dm] can be used as Consumer-Facing Interface, NSF- Facing Interface, and Registration Interface, respectively, along with RESTCONF [RFC8040] and NETCONF [RFC6241]. -7. I2NSF Framework with NFV - - This section discusses the implementation of the I2NSF framework - using Network Functions Virtualization (NFV). - +--------------------+ +-------------------------------------------+ | ---------------- | | I2NSF User (OSS/BSS) | | | NFV | | +------+------------------------------------+ | | Orchestrator +-+ | | Consumer-Facing Interface | -----+---------- | | +------|------------------------------------+ | | | | | -----+---------- (a) ----------------- | | ----+----- | | | | Security +-------+ Developer's | | | | | | | | |Controller(EM)| |Mgmt System(EM)| +-(b)-+ VNFM(s)| | | | -----+---------- ----------------- | | | | | | @@ -739,20 +789,25 @@ | | Hardware Resources | | | NFV Management | | +---------------------------------------+ | | and Orchestration | | | | (MANO) | +-------------------------------------------+ +--------------------+ (a) = Registration Interface (b) = Ve-Vnfm Interface Figure 4: I2NSF Framework Implementation with respect to the NFV Reference Architectural Framework +7. I2NSF Framework with NFV + + This section discusses the implementation of the I2NSF framework + using Network Functions Virtualization (NFV). + NFV is a promising technology for improving the elasticity and efficiency of network resource utilization. In NFV environments, NSFs can be deployed in the forms of software-based virtual instances rather than physical appliances. Virtualizing NSFs makes it possible to rapidly and flexibly respond to the amount of service requests by dynamically increasing or decreasing the number of NSF instances. Moreover, NFV technology facilitates flexibly including or excluding NSFs from multiple security solution vendors according to the changes on security requirements. In order to take advantages of the NFV technology, the I2NSF framework can be implemented on top of an NFV @@ -847,154 +903,229 @@ o Hyunsik Yang (Soongsil University) o Younghan Kim (Soongsil University) o Jung-Soo Park (ETRI) o Se-Hui Lee (Korea Telecom) o Mohamed Boucadair (Orange) -11. Informative References +11. References - [RFC8329] Lopez, D., Lopez, E., Dunbar, L., - Strassner, J., and R. Kumar, "Framework for - Interface to Network Security Functions", - RFC 8329, February 2018. +11.1. Normative References - [RFC6020] Bjorklund, M., "YANG - A Data Modeling - Language for the Network Configuration - Protocol (NETCONF)", RFC 6020, + [ETSI-NFV] + ETSI GS NFV 002 V1.1.1, "Network Functions Virtualisation + (NFV); Architectural Framework", Available: + https://www.etsi.org/deliver/etsi_gs/ + nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf, October + 2013. + + [ITU-T.Y.3300] + Recommendation ITU-T Y.3300, "Framework of Software- + Defined Networking", Available: https://www.itu.int/rec/T- + REC-Y.3300-201406-I, June 2014. + + [NFV-Terminology] + ETSI GS NFV 003 V1.2.1, "Network Functions Virtualisation + (NFV); Terminology for Main Concepts in NFV", Available: + https://www.etsi.org/deliver/etsi_gs/ + NFV/001_099/003/01.02.01_60/gs_nfv003v010201p.pdf, + December 2014. + + [ONF-OpenFlow] + ONF, "OpenFlow Switch Specification (Version 1.4.0)", + Available: https://www.opennetworking.org/wp- + content/uploads/2014/10/openflow-spec-v1.4.0.pdf, October + 2013. + + [ONF-SDN-Architecture] + ONF TR-521, "SDN Architecture (Issue 1.1)", Available: + https://www.opennetworking.org/wp- + content/uploads/2014/10/TR- + 521_SDN_Architecture_issue_1.1.pdf, June 2016. + + [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the + Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. - [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., - and A. Bierman, "Network Configuration - Protocol (NETCONF)", RFC 6241, June 2011. + [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. + Bierman, "Network Configuration Protocol (NETCONF)", + RFC 6241, June 2011. - [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, - "RESTCONF Protocol", RFC 8040, - January 2017. + [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined + Networking: A Perspective from within a Service Provider + Environment", RFC 7149, March 2014. - [consumer-facing-inf-im] Kumar, R., Lohiya, A., Qi, D., Bitar, N., - Palislamovic, S., Xia, L., and J. Jeong, - "Information Model for Consumer-Facing - Interface to Security Controller", draft- - kumar-i2nsf-client-facing-interface-im-07 - (work in progress), July 2018. + [RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining + (SFC) Architecture", RFC 7665, October 2015. - [consumer-facing-inf-dm] Jeong, J., Kim, E., Ahn, T., Kumar, R., and - S. Hares, "I2NSF Consumer-Facing Interface - YANG Data Model", draft-ietf-i2nsf- - consumer-facing-interface-dm-01 (work in - progress), July 2018. + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, January 2017. - [i2nsf-nsf-cap-im] Xia, L., Strassner, J., Basile, C., and D. - Lopez, "Information Model of NSFs - Capabilities", - draft-ietf-i2nsf-capability-02 (work in + [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., + and J. Jeong, "Interface to Network Security Functions + (I2NSF): Problem Statement and Use Cases", RFC 8192, July + 2017. + + [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service + Header (NSH)", RFC 8300, January 2018. + + [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. + Kumar, "Framework for Interface to Network Security + Functions", RFC 8329, February 2018. + +11.2. Informative References + + [AVANT-GUARD] + Shin, S., Yegneswaran, V., Porras, P., and G. Gu, "AVANT- + GUARD: Scalable and Vigilant Switch Flow Management in + Software-Defined Networks", ACM CCS, November 2013. + + [consumer-facing-inf-dm] + Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, + "I2NSF Consumer-Facing Interface YANG Data Model", draft- + ietf-i2nsf-consumer-facing-interface-dm-02 (work in + progress), November 2018. + + [consumer-facing-inf-im] + Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, + S., Xia, L., and J. Jeong, "Information Model for + Consumer-Facing Interface to Security Controller", draft- + kumar-i2nsf-client-facing-interface-im-07 (work in progress), July 2018. - [policy-translation] Yang, J., Jeong, J., and J. Kim, "Security - Policy Translation in Interface to Network - Security Functions", draft-yang-i2nsf- - security-policy-translation-01 (work in + [i2nsf-nfv-architecture] + Yang, H., Kim, Y., Jeong, J., and J. Kim, "I2NSF on the + NFV Reference Architecture", draft-yang-i2nsf-nfv- + architecture-04 (work in progress), November 2018. + + [i2nsf-nsf-cap-im] + Xia, L., Strassner, J., Basile, C., and D. Lopez, + "Information Model of NSFs Capabilities", draft-ietf- + i2nsf-capability-04 (work in progress), October 2018. + + [i2nsf-terminology] + Hares, S., Strassner, J., Lopez, D., Xia, L., and H. + Birkholz, "Interface to Network Security Functions (I2NSF) + Terminology", draft-ietf-i2nsf-terminology-06 (work in progress), July 2018. - [nsf-facing-inf-dm] Kim, J., Jeong, J., Park, J., Hares, S., - and Q. Lin, "I2NSF Network Security - Function-Facing Interface YANG Data Model", - draft-ietf-i2nsf-nsf-facing-interface-data- - model-01 (work in progress), July 2018. + [ITU-T.X.1252] + Recommendation ITU-T X.1252, "Baseline Identity Management + Terms and Definitions", April 2010. - [registration-inf-dm] Hyun, S., Jeong, J., Roh, T., Wi, S., and - J. Park, "I2NSF Registration Interface YANG - Data Model", - draft-hyun-i2nsf-registration-dm-06 (work - in progress), July 2018. + [ITU-T.X.800] + Recommendation ITU-T X.800, "Security Architecture for + Open Systems Interconnection for CCITT Applications", + March 1991. - [nsf-triggered-steering] Hyun, S., Jeong, J., Park, J., and S. - Hares, "Service Function Chaining-Enabled - I2NSF Architecture", - draft-hyun-i2nsf-nsf-triggered-steering-06 - (work in progress), July 2018. + [nsf-facing-inf-dm] + Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, + "I2NSF Network Security Function-Facing Interface YANG + Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-02 + (work in progress), November 2018. - [i2nsf-nfv-architecture] Yang, H. and Y. Kim, "I2NSF on the NFV - Reference Architecture", - draft-yang-i2nsf-nfv-architecture-02 (work - in progress), June 2018. + [nsf-monitoring-dm] + Jeong, J., Kim, J., Hong, D., Hares, S., Xia, L., and H. + Birkholz, "A YANG Data Model for Monitoring I2NSF Network + Security Functions", draft-hong-i2nsf-nsf-monitoring-data- + model-06 (work in progress), November 2018. - [RFC7149] Boucadair, M. and C. Jacquenet, "Software- - Defined Networking: A Perspective from - within a Service Provider Environment", - RFC 7149, March 2014. + [nsf-triggered-steering] + Hyun, S., Jeong, J., Park, J., and S. Hares, "Service + Function Chaining-Enabled I2NSF Architecture", draft-hyun- + i2nsf-nsf-triggered-steering-06 (work in progress), July + 2018. - [ITU-T.Y.3300] Recommendation ITU-T Y.3300, "Framework of - Software-Defined Networking", June 2014. + [opsawg-firewalls] + Baker, F. and P. Hoffman, "On Firewalls in Internet + Security", draft-ietf-opsawg-firewalls-01 (work in + progress), October 2012. - [ONF-OpenFlow] ONF, "OpenFlow Switch Specification - (Version 1.4.0)", October 2013. + [policy-translation] + Yang, J., Jeong, J., and J. Kim, "Security Policy + Translation in Interface to Network Security Functions", + draft-yang-i2nsf-security-policy-translation-02 (work in + progress), October 2018. - [ONF-SDN-Architecture] ONF, "SDN Architecture", June 2014. + [registration-inf-dm] + Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF + Registration Interface YANG Data Model", draft-ietf-i2nsf- + registration-interface-dm-01 (work in progress), November + 2018. - [ITU-T.X.1252] Recommendation ITU-T X.1252, "Baseline - Identity Management Terms and Definitions", - April 2010. + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. - [ITU-T.X.800] Recommendation ITU-T X.800, "Security - Architecture for Open Systems - Interconnection for CCITT Applications", - March 1991. +Appendix A. Changes from draft-ietf-i2nsf-applicability-07 - [AVANT-GUARD] Shin, S., Yegneswaran, V., Porras, P., and - G. Gu, "AVANT-GUARD: Scalable and Vigilant - Switch Flow Management in Software-Defined - Networks", ACM CCS, November 2013. + The following changes have been made from draft-ietf-i2nsf- + applicability-07: - [ETSI-NFV] ETSI GS NFV 002 V1.1.1, "Network Functions - Virtualization (NFV); Architectural - Framework", October 2013. + o This version has reflected all the comments from Eric Rescorla who + is a Security Area Director as follows. - [RFC4566] Handley, M., Jacobson, V., and C. Perkins, - "SDP: Session Description Protocol", - RFC 4566, July 2006. + o In Section 1, Network Security Function (NFV) is defined in the + viewpoint of the I2NSF framework. - [i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, - L., and H. Birkholz, "Interface to Network - Security Functions (I2NSF) Terminology", - draft-ietf-i2nsf-terminology-06 (work in - progress), July 2018. + o In Section 1, a user using the I2NSF User is clarified as a system + administrator in the I2NSF framework. - [opsawg-firewalls] Baker, F. and P. Hoffman, "On Firewalls in - Internet Security", - draft-ietf-opsawg-firewalls-01 (work in - progress), October 2012. + o In Section 1, as the applicability of the I2NSF framework, four + different scenarios are represented with a standard bulleted list. - [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, - C., Kumar, R., and J. Jeong, "Interface to - Network Security Functions (I2NSF): Problem - Statement and Use Cases", RFC 8192, - July 2017. + o The standard document about ETSI-NFV is moved to Normative + References. - [RFC7665] Halpern, J. and C. Pignataro, "Service - Function Chaining (SFC) Architecture", - RFC 7665, October 2015. + 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. - [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, - "Network Service Header (NSH)", RFC 8300, - January 2018. + o In Section 2, the definition of Firewall is corrected such that + some suspicious packets are inspected by the firewall rather than + every packet. -Appendix A. Changes from draft-ietf-i2nsf-applicability-06 + 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. - The following change has been made from - draft-ietf-i2nsf-applicability-06: + 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]. - o Add the acknowledgment to the EU H2020 project SHIELD. + 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. + + 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". Authors' Addresses Jaehoon Paul Jeong Department of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea @@ -1014,27 +1145,27 @@ EMail: shyun@chosun.ac.kr Tae-Jin Ahn Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon 305-811 Republic of Korea Phone: +82 42 870 8409 EMail: taejin.ahn@kt.com - Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA Phone: +1-734-604-0332 EMail: shares@ndzh.com + Diego R. Lopez Telefonica I+D Jose Manuel Lara, 9 - Seville, 41013 + Seville 41013 Spain Phone: +34 682 051 091 EMail: diego.r.lopez@telefonica.com