--- 1/draft-ietf-i2nsf-applicability-05.txt 2018-10-22 04:14:31.621215654 -0700 +++ 2/draft-ietf-i2nsf-applicability-06.txt 2018-10-22 04:14:31.669216800 -0700 @@ -1,26 +1,26 @@ I2NSF Working Group J. Jeong Internet-Draft Sungkyunkwan University Intended status: Informational S. Hyun -Expires: March 15, 2019 Chosun University +Expires: April 25, 2019 Chosun University T. Ahn Korea Telecom S. Hares Huawei D. Lopez Telefonica I+D - September 11, 2018 + October 22, 2018 Applicability of Interfaces to Network Security Functions to Network- Based Security Services - draft-ietf-i2nsf-applicability-05 + draft-ietf-i2nsf-applicability-06 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 @@ -30,56 +30,56 @@ 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 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 March 15, 2019. + This Internet-Draft will expire on April 25, 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 4 4. Time-dependent Web Access Control Service . . . . . . . . . . 5 - 5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 6 - 6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 9 + 5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 7 + 6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 8 6.1. Firewall: Centralized Firewall System . . . . . . . . . . 11 6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System . . . . . . . . . . . . . . . . . . . . . . . . . 12 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-04 . . . 22 + Appendix A. Changes from draft-ietf-i2nsf-applicability-05 . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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 @@ -129,20 +129,39 @@ 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 that can establish and distribute access control policy rules into network resources for efficient DDoS-attack mitigation. + +------------+ + | I2NSF User | + +------------+ + ^ + | Consumer-Facing Interface + v + +-------------------+ Registration +-----------------------+ + |Security Controller|<-------------------->|Developer's Mgmt System| + +-------------------+ Interface +-----------------------+ + ^ + | NSF-Facing Interface + v + +----------------+ +---------------+ +-----------------------+ + | NSF-1 |-| NSF-2 |...| NSF-n | + | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)| + +----------------+ +---------------+ +-----------------------+ + + Figure 1: I2NSF Framework + 3. I2NSF Framework This section summarizes the I2NSF framework as defined in [RFC8329]. As shown in Figure 1, an I2NSF User can use security functions by delivering high-level security policies, which specify security requirements that the I2NSF user wants to enforce, to the Security Controller via the Consumer-Facing Interface [consumer-facing-inf-im][consumer-facing-inf-dm]. The Security Controller receives and analyzes the high-level security @@ -158,42 +177,24 @@ 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. 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. - +------------+ - | I2NSF User | - +------------+ - ^ - | Consumer-Facing Interface - v - +-------------------+ Registration +-----------------------+ - |Security Controller|<-------------------->|Developer's Mgmt System| - +-------------------+ Interface +-----------------------+ - ^ - | NSF-Facing Interface - v - +----------------+ +---------------+ +-----------------------+ - | NSF-1 |-| NSF-2 |...| NSF-n | - | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)| - +----------------+ +---------------+ +-----------------------+ - - Figure 1: I2NSF Framework - The NSF-Facing Interface between the Security Controller and NSFs can be implemented using NETCONF [RFC6241]. YANG data models describe low-level security policies for the sake of NSFs, which are translated from the high-level security policies by the Security Controller. The data model defined in [nsf-facing-inf-dm] can be 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 @@ -265,85 +266,87 @@ filter. SFC technology can be utilized to support such packet forwarding in the I2NSF framework [nsf-triggered-steering]. 4. The web filter checks the target URL field of the received packet, and realizes the packet is toward Example.com. The web filter then checks that the current time is in business hours. If so, the web filter drops the packet, and consequently the staff member's access to Example.com during business hours is blocked. -5. I2NSF Framework with SFC - - In the I2NSF architecture, an NSF can trigger an advanced security - action (e.g., DPI or DDoS attack mitigation) on a packet based on the - result of its own security inspection of the packet. For example, a - firewall triggers further inspection of a suspicious packet with DPI. - For this advanced security action to be fulfilled, the suspicious - packet should be forwarded from the current NSF to the successor NSF. - SFC [RFC7665] is a technology that enables this advanced security - action by steering a packet with multiple service functions (e.g., - NSFs), and this technology can be utilized by the I2NSF architecture - to support the advanced security action. - - SFC generally requires classifiers and service function forwarders - (SFFs); classifiers are responsible for determining which service - function path (SFP) (i.e., an ordered sequence of service functions) - a given packet should pass through, according to pre-configured - classification rules, and SFFs perform forwarding the given packet to - the next service function (e.g., NSF) on the SFP of the packet by - referring to their forwarding tables. In the I2NSF architecture with - SFC, the Security Controller can take responsibilities of generating - classification rules for classifiers and forwarding tables for SFFs. - By analyzing high-level security policies from I2NSF users, the - Security Controller can construct SFPs that are required to meet the - high-level security policies, generates classification rules of the - SFPs, and then configures classifiers with the classification rules - over NSF-Facing Interface so that relevant traffic packets can follow - the SFPs. Also, based on the global view of NSF instances available - in the system, the Security Controller constructs forwarding tables, - which are required for SFFs to forward a given packet to the next NSF - over the SFP, and configures SFFs with those forwarding tables over - NSF-Facing Interface. - +------------+ | I2NSF User | +------------+ ^ | Consumer-Facing Interface v +-------------------+ Registration +-----------------------+ |Security Controller|<-------------------->|Developer's Mgmt System| +-------------------+ Interface +-----------------------+ ^ ^ | | NSF-Facing Interface | |------------------------- | | | NSF-Facing Interface | - +-+-+-v-+-+-+-+-+-+ +------v-------+ + +-----v-----------+ +------v-------+ | +-----------+ | ------>| NSF-1 | | |Classifier | | | | (Firewall) | | +-----------+ | | +--------------+ | +-----+ |<-----| +--------------+ | | SFF | | |----->| NSF-2 | | +-----+ | | | (DPI) | - +-+-+-+-+-+-+-+-+-+ | +--------------+ + +-----------------+ | +--------------+ | . | . | . | +-----------------------+ ------>| NSF-n | |(DDoS-Attack Mitigator)| +-----------------------+ Figure 2: An I2NSF Framework with SFC +5. I2NSF Framework with SFC + + In the I2NSF architecture, an NSF can trigger an advanced security + action (e.g., DPI or DDoS attack mitigation) on a packet based on the + result of its own security inspection of the packet. For example, a + firewall triggers further inspection of a suspicious packet with DPI. + For this advanced security action to be fulfilled, the suspicious + packet should be forwarded from the current NSF to the successor NSF. + SFC [RFC7665] is a technology that enables this advanced security + action by steering a packet with multiple service functions (e.g., + NSFs), and this technology can be utilized by the I2NSF architecture + to support the advanced security action. + + Figure 2 shows an I2NSF framework with the support of SFC. As shown + in the figure, SFC generally requires classifiers and service + function forwarders (SFFs); classifiers are responsible for + determining which service function path (SFP) (i.e., an ordered + sequence of service functions) a given packet should pass through, + according to pre-configured classification rules, and SFFs perform + forwarding the given packet to the next service function (e.g., NSF) + on the SFP of the packet by referring to their forwarding tables. In + the I2NSF architecture with SFC, the Security Controller can take + responsibilities of generating classification rules for classifiers + and forwarding tables for SFFs. By analyzing high-level security + policies from I2NSF users, the Security Controller can construct SFPs + that are required to meet the high-level security policies, generates + classification rules of the SFPs, and then configures classifiers + with the classification rules over NSF-Facing Interface so that + relevant traffic packets can follow the SFPs. Also, based on the + global view of NSF instances available in the system, the Security + Controller constructs forwarding tables, which are required for SFFs + to forward a given packet to the next NSF over the SFP, and + configures SFFs with those forwarding tables over NSF-Facing + Interface. + 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. Based on the metadata information, the classifier searches an SFP which includes an NSF with the required security capability, changes the SFP-related information (e.g., service path identifier and service index [RFC8300]) of the packet with the new SFP that has been found, and then forwards the packet to the SFF. When receiving the packet, the SFF checks the SFP-related information such as the service path identifier and service index @@ -354,20 +357,55 @@ This section describes an I2NSF framework with SDN for I2NSF applicability and use cases, such as firewall, deep packet inspection, and DDoS-attack mitigation functions. SDN enables some packet filtering rules to be enforced in network forwarding elements (e.g., switch) by controlling their packet forwarding rules. By taking advantage of this capability of SDN, it is possible to optimize the process of security service enforcement in the I2NSF system. + +------------+ + | I2NSF User | + +------------+ + ^ + | Consumer-Facing Interface + v + +-------------------+ Registration +-----------------------+ + |Security Controller|<-------------------->|Developer's Mgmt System| + +-------------------+ Interface +-----------------------+ + ^ ^ + | | NSF-Facing Interface + | v + | +----------------+ +---------------+ +-----------------------+ + | | NSF-1 |-| NSF-2 |...| NSF-n | + | | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)| + | +----------------+ +---------------+ +-----------------------+ + | + | + | SDN Network + +--|----------------------------------------------------------------+ + | V NSF-Facing Interface | + | +----------------+ | + | | SDN Controller | | + | +----------------+ | + | ^ | + | | SDN Southbound Interface | + | v | + | +--------+ +------------+ +--------+ +--------+ | + | |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 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 @@ -393,59 +431,33 @@ elements and which should be enforced by NSFs. If some of the given rules requires security capabilities that can be provided by SDN forwarding elements, then the Security Controller instructs the SDN Controller via NSF-Facing Interface so that SDN forwarding elements can enforce those security policy rules with flow tables under the supervision of the SDN Controller. Or if some rules require security capabilities that cannot be provided by SDN forwarding elements but by NSFs, then the Security Controller instructs relevant NSFs to enforce those rules. - +------------+ - | I2NSF User | - +------------+ - ^ - | Consumer-Facing Interface - v - +-------------------+ Registration +-----------------------+ - |Security Controller|<-------------------->|Developer's Mgmt System| - +-------------------+ Interface +-----------------------+ - ^ ^ - | | NSF-Facing Interface - | v - | +----------------+ +---------------+ +-----------------------+ - | | NSF-1 |-| NSF-2 |...| NSF-n | - | | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)| - | +----------------+ +---------------+ +-----------------------+ - | ^ - | | - | v - | +--------+ - | | SFF | - | +--------+ - | ^ - | | - | V SDN Network - +--|----------------------------------------------------------------+ - | V NSF-Facing Interface | - | +----------------+ | - | | SDN Controller | | - | +----------------+ | - | ^ | - | | SDN Southbound Interface | - | v | - | +--------+ +--------+ +--------+ +--------+ | - | |Switch 1|-|Switch 2|-|Switch 3|......|Switch m| | - | +--------+ +--------+ +--------+ +--------+ | - +-------------------------------------------------------------------+ - - Figure 3: An I2NSF Framework with SDN Network + For the support of SFC in the I2NSF framework with SDN, as shown in + Figure 3, network forwarding elements (e.g., switch) can play the + role of either SFC Classifier or SFF, which are explained in + Section 5. Classifier and SFF have an NSF-Facing Interface with + Security Controller. This interface is used to update security + service function chaining information for traffic flows. For + example, when it needs to update an SFP for a traffic flow in an SDN + network, as shown in Figure 3, SFF (denoted as Switch-3) asks + Security Controller to update the SFP for the traffic flow (needing + another security service as an NSF) via NSF-Facing Interface. This + update lets Security Controller ask Classifier (denoted as Switch-2) + to update the mapping between the traffic flow and SFP in Classifier + via NSF-Facing Interface. 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] 6.1. Firewall: Centralized Firewall System A centralized network firewall can manage each network resource and apply common rules to individual network elements (e.g., switch). The centralized network firewall controls each forwarding element, @@ -536,24 +548,25 @@ 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 packet (e.g., SIP packet) of a suspicious pattern. 3. The Firewall triggers an appropriate security service function, such as VoIP IPS, for detailed security analysis of the - suspicious signal packet. That is, the firewall sends the packet - to the Service Function Forwarder (SFF) in the I2NSF framework - [nsf-triggered-steering], as shown in Figure 3. The SFF forwards - the suspicious signal packet to the VoIP IPS. + suspicious signal packet. In order for this triggering of VoIP + IPS to be served, the suspicious packet is sent to the Service + Function Forwarder (SFF) that is usually a switch in an SDN + network, as shown in Figure 3. The SFF forwards the suspicious + signal packet to the VoIP IPS. 4. The VoIP IPS analyzes the headers and contents of the signal packet, such as calling number and session description headers [RFC4566]. 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. @@ -691,47 +704,48 @@ 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)| | | | | | - | -----+---------- ----------------- | | ----+----- | | - | | NSF-Facing Interface | | | | | | - | ----+----- ----+----- ----+----- | | | VNFM(s)| | | - | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| +-(b)-+ | | | - | ----+----- ----+----- ----+----- | | ----+----- | | + | -----+---------- (a) ----------------- | | ----+----- | | + | | Security +-------+ Developer's | | | | | | | + | |Controller(EM)| |Mgmt System(EM)| +-(b)-+ VNFM(s)| | | + | -----+---------- ----------------- | | | | | | + | | NSF-Facing Interface | | ----+----- | | + | ----+----- ----+----- ----+----- | | | | | + | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | | | | + | ----+----- ----+----- ----+----- | | | | | | | | | | | | | | +------|-------------|-------------|--------+ | | | | | | | | | | | +------+-------------+-------------+--------+ | | | | | NFV Infrastructure (NFVI) | | | | | | ----------- ----------- ----------- | | | | | | | Virtual | | Virtual | | Virtual | | | | | | | | Compute | | Storage | | Network | | | | | | | ----------- ----------- ----------- | | ----+----- | | | +---------------------------------------+ | | | | | | | | Virtualization Layer | +-----+ VIM(s) +------+ | | +---------------------------------------+ | | | | | | +---------------------------------------+ | | ---------- | | | ----------- ----------- ----------- | | | | | | | Compute | | Storage | | Network | | | | | | | | Hardware| | Hardware| | Hardware| | | | | | | ----------- ----------- ----------- | | | | | | 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 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 @@ -949,34 +963,28 @@ (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. -Appendix A. Changes from draft-ietf-i2nsf-applicability-04 - - The following changes have been made from draft-ietf-i2nsf- - applicability-04: - - o A more precise description of the basic I2NSF flows is provided. +Appendix A. Changes from draft-ietf-i2nsf-applicability-05 - o The structure of the document makes each discussed use case be an - applicability statement according to the applied technology, such - as SFC, SDN, and NFV. + The following change has been made from draft-ietf-i2nsf- + applicability-05: - o In Section 6, Switch Controller is replaced by SDN Controller for - the terminology consistency in SDN standards. Switch is replaced - by forwarding element as a general term. + o In Figure 3, a separate box of SFF and the relevant interfaces + have been omitted to avoid misleading. Instead, SDN switches may + play the role of SFF and Classifier in an SDN network. Authors' Addresses Jaehoon Paul Jeong Department of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea