Network Working Group S. Hyun Internet-Draft J. Jeong Intended status: Standards Track S. Woo Expires: September 14, 2017 Y. Yeo Sungkyunkwan University J. Park ETRI March 13, 2017 Registration Interface Information Model for Interface to Network Security Functions draft-hyun-i2nsf-registration-interface-im-01 Abstract This document describes an information model for Interface to Network Security Functions (I2NSF) Registration Interface between Security Controller and Developer's Management System. The information model is required for Network Security Function (NSF) instance registration and the dynamic life cycle management of NSF instances. This document explains the procedures over I2NSF registration interface for these functionalities. It also describes the detailed information which should be exchanged via I2NSF registration interface. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 14, 2017. Hyun, et al. Expires September 14, 2017 [Page 1] Internet-Draft Registration Interface Information Model March 2017 Copyright Notice Copyright (c) 2017 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 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 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Life-Cycle Managment Mechanism . . . . . . . . . . . . . . 6 5.2. Registration Mechanism . . . . . . . . . . . . . . . . . . 6 5.3. NSF Access Information . . . . . . . . . . . . . . . . . . 7 5.4. NSF Profile (Capabilities of an NSF instance) . . . . . . 7 5.4.1. Packet Content-Matching Capability . . . . . . . . . . 8 5.4.2. Content-Matching Capability . . . . . . . . . . . . . 8 5.4.3. Context-Matching Capability . . . . . . . . . . . . . 8 5.4.4. Attack-Mitigation Capability . . . . . . . . . . . . . 9 5.4.5. Action Capability . . . . . . . . . . . . . . . . . . 9 5.4.6. Performance Capability . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Changes from draft-hyun-i2nsf-registration-interface-im-00 . . . . 11 Hyun, et al. Expires September 14, 2017 [Page 2] Internet-Draft Registration Interface Information Model March 2017 1. Introduction A number of virtual network security function instances typically exist in Interface to Network Security Functions (I2NSF) framework [i2nsf-framework]. In this environment, it is important to dynamically manage a Network Security Function (NSF) instance pool for efficient resource utilization. For instance, if a certain NSF instance is receiving an excessive amount of traffic beyond its capacity, an additional instance for the same security function should be created. If an NSF instance is idle for a period of time, it would be better to destroy it to avoid resource waste. In addition, the existing information model for NSF-facing interface requires an NSF to trigger another type of NSF for further inspection [capability-im]. In this case, if there is no available instance for the latter NSF, a new NSF should be instantiated. Similarly, in order to enforce a security policy from the client, all the required NSF instances should be created. This document describes the procedures which should be performed on the registration interface between security controller and developer's management system to dynamically manage a pool of NSF instances. It further describes the detailed information which should be exchanged between security controller and developer's management system. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology This document uses the terminology described in [i2nsf-terminology][capability-im][i2nsf-framework] [nsf-triggered-steering]. o Network Security Function (NSF): A function that is responsible for specific treatment of received packets. A Network Security Function can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). Sample Network Security Service Functions are as follows: Firewall, Intrusion Prevention/ Detection System (IPS/IDS), Deep Packet Inspection (DPI), Application Visibility and Control (AVC), network virus and malware scanning, sandbox, Data Loss Prevention (DLP), Distributed Denial of Service (DDoS) mitigation and TLS proxy [nsf-triggered-steering]. Hyun, et al. Expires September 14, 2017 [Page 3] Internet-Draft Registration Interface Information Model March 2017 o Advanced Inspection/Action: As like the I2NSF information model for NSF-facing interface [capability-im], Advanced Inspection/ Action means that a security function calls another security function for further inspection based on its own inspection result [nsf-triggered-steering]. o Network Security Function Profile (NSF Profile): NSF Profile specifies the security and performance capability of an NSF instance. Each NSF instance has its own NSF Profile which describes the type of security service it can provide and its resource capacity. [nsf-triggered-steering]. 4. Objectives o Efficient network resource utilization through dynamic instantiation of NSFs and load balancing: In I2NSF framework, it is sometimes possible that a specific NSF experiences heavy traffic loads. For example, under DDoS attacks, a huge volume of traffic would be delivered to DoS attack mitigator function to cope with the attacks. In this case, we should allocate a large portion of resources to that DoS attack mitigator function by creating a sufficient number of DoS mitigator instances. In addition, after the attack is terminated, we should eliminate some of the instances no longer used. In this way, we can achieve efficient resource utilization. For this purpose, it is essential to define an information model of registration interface for dynamic instantiation/elimination of NSF instances. o Creating an NSF instance to serve another NSF's inspection request: In I2NSF framework, an NSF can trigger another type of NSF(s) for more advanced security inspection of the traffic. In this case, the next NSF is determined by the current NSF's inspection result and client's policy. However, if there is no available NSF instance to serve the former NSF's request, we should create an NSF instance by requesting Developer's Management System (DMS) through registration interface. o Creating NSF instances required to enforce security policy rules from Client: In I2NSF framework, users decide which security service is necessary in the system. If there is no NSF instances to enforce the client's security policy, then we should also create the required instances by requesting DMS via registration interface. o Registering NSF instances from Developer's Management System: Depending on system's security requirements, it may require some NSFs by default. In this case, DMS creates these default NSF instances without the need of receiving requests from Security Hyun, et al. Expires September 14, 2017 [Page 4] Internet-Draft Registration Interface Information Model March 2017 Controller. After creating them, DMS notifies Security Controller of those NSF instances via registration interface. 5. Information Model The I2NSF registration interface was only used for registering new NSF instances to Security Controller. In this document, however, we extend its utilization to support dynamic NSF life cycle management and describe the information that should be exchanged via the registration interface for the functionality . Moreover, we also define the information model of NSF Profile because, for registration interface, NSF Profile (i.e., capabilities of an NSF) needs to be clarified so that the components of I2NSF framework can exchange the set of capabilities in a standardized manner. This is typically done through the following process:: 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. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Interface Information Design | | | | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | | |Life-Cycle Management| | Registration | | | | Sub-Model | | Sub-Model | | | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The Registration Interface Information Model Design As illustrated in Figure 1, the information model for Registration Interface consists of two sub-models: life-cycle management, registration sub-models. The life-cycle management functionality and the registration functionality use NSF Profile to achieve their goals. In this context, NSF Profile is the capability objects that Hyun, et al. Expires September 14, 2017 [Page 5] Internet-Draft Registration Interface Information Model March 2017 describe and/or prescribe inspection capability an NSF instance can provide. 5.1. Life-Cycle Managment Mechanism For the life-cycle management of NSFs, Security Controller in I2NSF framework requires two types of requests: Instance Creation and Elimination Request Messages. Security Controller sends the request messages to DMS when required. Once receiving the request, DMS conducts creating/eliminating the corresponding NSF instance and responds Security Controller with the results. There are several cases requiring creation of a new NSF instance which provides specific security inspection functionalities and elimination of an existing NSF which is unused for a period of time. For example, 1) When an NSF triggers an advanced inspection of the suspicious traffic via another type of NSF whose instance is currently unavailable in the system. 2) When an NSF instance undergoes an excessive amount of traffic +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ |Instance Creation| | Instance Elimination | | Request Message | | Request Message | +-+-+-+-^-+-+-+-+-+ +-+-+-+-+-+^+-+-+-+-+-+-+ | | | | | | | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | NSF Profile | | NSF Access | +-+-+-+-+-+-+-+-+ | Information | +-+-+-+-+-+-+-+-+ Figure 2: Life-Cycle Management Sub-Model Overview 5.2. Registration Mechanism In order to register a new NSF instance, DMS should generate a Registration Message to Security Controller. A Registration Message consists of an NSF Profile and an NSF Access Information. The former describes the inspection capability of the new NSF instance and the latter is for enabling network access to the new instance from other components. After this registration process, as explained in [capability-im], the I2NSF capability interface can conduct controlling and monitoring the new registered NSF instance. Hyun, et al. Expires September 14, 2017 [Page 6] Internet-Draft Registration Interface Information Model March 2017 +-+-+-+-+-+-+-+-+ | Registration | | Message | +-+-+-+-^-+-+-+-+ | +-----------------------------+ | | | | +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | NSF Profile | | NSF Access | | | | Information | +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Figure 3: Registration Mechanism Sub-Model Overview 5.3. NSF Access Information NSF Access Information contains the followings that are required to communicate with an NSF: IPv4 address, IPv6 address, port number, and supported transport protocol(s) (e.g., Virtual Extensible LAN (VXLAN) [RFC 7348], Generic Protocol Extension for VXLAN (VXLAN-GPE) [nvo3-vxlan-gpe], Generic Route Encapsulation (GRE), Ethernet etc.). In this document, NSF Access Information is used to identify a specific NSF instance (i.e. NSF Access Information is the signature(unique identifier) of an NSF instance in the overall system). 5.4. NSF Profile (Capabilities of an NSF instance) NSF Profile basically refers the inspection capabilities of an NSF instance. As illustrated in Figure 4, it can be split into five capabilities (Content-Matching, Context-Matching, Attack-Mitigation, Action, Performance Capabilities). We share the security capabilities which are defined in Section 3 (Overall Analysis of Security Capability) in [capability-im] for the first five capabilities and append one additional capability. Hyun, et al. Expires September 14, 2017 [Page 7] Internet-Draft Registration Interface Information Model March 2017 +-+-+-+-+-+-+-+-+ | Capability | | Objects | +-+-+-+-^-+-+-+-+ | +--------------------+--------------------+-----------+ | | | | | | | | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | |Content-Matching | |Content-Matching | |Context-Matching | | | (Packet) | | Capability | | Capability | | | Capability | | | | | | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | | +--------------------+--------------------+-----------+ | | | | | | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |Attack Mitigation| | Action | | Performance | | Capability | | Capability | | Capability | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ Figure 4: NSF Profile Overview 5.4.1. Packet Content-Matching Capability Refer to the kind of information or attributes acquired directly from the packet headers or payloads that can be used in the security policy. It can be any fields or attributes in the packet L2/L3/L4 header, or special segment of bytes in the packet payload. [capability-im] 5.4.2. Content-Matching Capability Content security is another category of security capabilities applied to application layer. Through detecting the contents carried over the traffic in application layer, these capabilities can realize various security functions, such as defending against intrusion, inspecting virus, filtering malicious URL or junk email, blocking illegal web access or malicious data retrieval. [capability-im] 5.4.3. Context-Matching Capability This capability refers to the content information for the received packets. It can be User, Schedule, Region, Target, State and Direction information. [capability-im] Hyun, et al. Expires September 14, 2017 [Page 8] Internet-Draft Registration Interface Information Model March 2017 5.4.4. Attack-Mitigation Capability This category of security capabilities is used to detect and mitigate various types of network attacks. Today's common network attacks can be classified into the following sets, and each set further consists of a number of specific attacks: [capability-im] o DDoS attacks: * Network layer DDoS attacks: Examples include SYN flood, UDP flood, ICMP flood, IP fragment flood, IPv6 Routing header attack, and IPv6 duplicate address detection attack; * Application layer DDoS attacks: Examples include http flood, https flood, cache-bypass http floods, WordPress XML RPC floods, ssl DDoS. o Single-packet attack: * Scanning and sniffing attacks: IP sweep, port scanning, etc * Malformed packet attacks: Ping of Death, Teardrop, etc * Special packet attacks: Oversized ICMP, Tracert, IP timestamp option packets, etc 5.4.5. Action Capability NSFs provide security functions by executing various Actions, which at least includes: [capability-im] o Ingress actions, such as pass, drop, mirroring, etc; o Egress actions, such as invoke signaling, tunnel encapsulation, packet forwarding and/or transformation; o Applying a specific Functional Profile or signature (NSF Profile) - The functional profile or signature file defines the security capabilities for content security control and/or attack mitigation control. One goal of I2NSF is to standardize the form and functional interface of those security capabilities while supporting vendor-specific implementations of each. 5.4.6. Performance Capability This information basically represents the processing capability of an NSF, i.e., the amount of traffic it can process for a unit time period. This information can be used to determine whether the NSF is Hyun, et al. Expires September 14, 2017 [Page 9] Internet-Draft Registration Interface Information Model March 2017 in congestion by comparing this with the workload that the NSF currently undergoes. Moreover, this information can specify an available amount of each type of resources such as processing power and memory which are available on the NSF. 6. Security Considerations The information model of the registration interface is based on the I2NSF framework without any architectural changes. Thus, this document shares the security considerations of the I2NSF framwork that are specified in [i2nsf-framework] for the purpose of achieving secure communication between components in the proposed architecture. 7. Acknowledgements This work was supported by Institute for Information & communications Technology Promotion(IITP) grant funded by the Korea government(MSIP) (No.R-20160222-002755, Cloud based Security Intelligence Technology Development for the Customized Security Service Provisioning). 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [capability-im] Xia, L., Strassner, J., Basile, C., and D. Lopez, "Information Model of NSFs Capabilities", draft-xibassnez-i2nsf-capability-01 (work in progress), March 2017. [i2nsf-framework] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", draft-ietf-i2nsf-framework-04 (work in progress), October 2016. [i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Birkholz, "Interface to Network Security Functions (I2NSF) Terminology", draft-ietf-i2nsf-terminology-03 (work in progress), March 2017. Hyun, et al. Expires September 14, 2017 [Page 10] Internet-Draft Registration Interface Information Model March 2017 [nsf-triggered-steering] Hyun, S., Jeong, J., Woo, S., Yeo, Y., and J. Park, "NSF-Triggered Traffic Steering", draft-hyun-i2nsf-nsf-triggered-steering-02 (work in progress), March 2017. [nvo3-vxlan-gpe] Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-03 (work in progress), October 2016. Appendix A. Changes from draft-hyun-i2nsf-registration-interface-im-00 The following changes are made from draft-hyun-i2nsf-registration-interface-im-00: o Miscellaneous expressions in the whole descriptions are corrected. o The description of NSF Access Information and Performance Capability is specified in more detail than the previous version. Authors' Addresses Sangwon Hyun Department of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 290 7222 Fax: +82 31 299 6673 EMail: swhyun77@skku.edu URI: http://imtl.skku.ac.kr/ Jaehoon Paul Jeong Department of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Fax: +82 31 290 7996 EMail: pauljeong@skku.edu URI: http://iotlab.skku.edu/people-jaehoon-jeong.php Hyun, et al. Expires September 14, 2017 [Page 11] Internet-Draft Registration Interface Information Model March 2017 SangUk Woo Department of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 290 7222 Fax: +82 31 299 6673 EMail: suwoo@imtl.skku.ac.kr, URI: http://imtl.skku.ac.kr/index.php?mid=member_student YunSuk Yeo Department of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 290 7222 Fax: +82 31 299 6673 EMail: yunsuk@imtl.skku.ac.kr, URI: http://imtl.skku.ac.kr/index.php?mid=member_student Jung-Soo Park Electronics and Telecommunications Research Institute 218 Gajeong-Ro, Yuseong-Gu Daejeon 305-700 Republic of Korea Phone: +82 42 860 6514 EMail: pjs@etri.re.kr Hyun, et al. Expires September 14, 2017 [Page 12]