--- 1/draft-ietf-i2nsf-applicability-03.txt 2018-07-17 13:14:09.046298536 -0700 +++ 2/draft-ietf-i2nsf-applicability-04.txt 2018-07-17 13:14:09.098299802 -0700 @@ -1,26 +1,26 @@ I2NSF Working Group J. Jeong Internet-Draft Sungkyunkwan University Intended status: Informational S. Hyun -Expires: January 3, 2019 Chosun University +Expires: January 18, 2019 Chosun University T. Ahn Korea Telecom S. Hares Huawei D. Lopez Telefonica I+D - July 2, 2018 + July 17, 2018 Applicability of Interfaces to Network Security Functions to Network- Based Security Services - draft-ietf-i2nsf-applicability-03 + draft-ietf-i2nsf-applicability-04 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,21 +30,21 @@ 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 January 3, 2019. + This Internet-Draft will expire on January 18, 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 @@ -61,26 +61,26 @@ 3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Time-dependent Web Access Control Service . . . . . . . . 5 4. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 7 5. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 9 5.1. Firewall: Centralized Firewall System . . . . . . . . . . 11 5.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Attack Mitigation: Centralized DDoS-attack Mitigation System . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 16 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 - 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 - 10. Informative References . . . . . . . . . . . . . . . . . . . 19 - Appendix A. Changes from draft-ietf-i2nsf-applicability-02 . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 + 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 + 10. Informative References . . . . . . . . . . . . . . . . . . . 20 + Appendix A. Changes from draft-ietf-i2nsf-applicability-03 . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Interface to Network Security Functions (I2NSF) defined 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 NFV environment 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 @@ -194,26 +194,26 @@ ^ | 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 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 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 Mgmt System can be implemented by RESTCONF [RFC8040]. The data model defined in [registration-inf-dm] can be used for the I2NSF Registration Interface. Also, the I2NSF framework can enforce multiple chained NSFs for the low-level security policies by means of service function chaining (SFC) techniques for the I2NSF architecture described in [nsf-triggered-steering]. @@ -302,45 +302,47 @@ 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 + SFC, the Security Controller can take responsibilities of generating classification rules for classifiers and forwarding tables for SFFs. - In particular, 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 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 can construct forwarding tables - required for SFFs to forward a given packet to the next NSF over the - SFP. + 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-------+ | +-----------+ | ------>| NSF-1 | | |Classifier | | | | (Firewall) | | +-----------+ | | +--------------+ | +-----+ |<-----| +--------------+ | | SFF | | |----->| NSF-2 | | +-----+ | | | (DPI) | +-+-+-+-+-+-+-+-+-+ | +--------------+ | . | . @@ -704,47 +706,48 @@ 6. I2NSF Framework with NFV This section discusses the implementation of the I2NSF framework with Network Functions Virtualization (called NFV). +--------------------+ +-------------------------------------------+ | ---------------- | | I2NSF User (OSS/BSS) | | | NFV | | +------+------------------------------------+ | | Orchestrator +-+ | - | Consumer-Facing Interface | ---+------------ | | + | Consumer-Facing Interface | -----+---------- | | +------|------------------------------------+ | | | | - | ----+-------------------------------- | | | | | - | | Security Controller(EM) | | | | | | - | ----+-------------+-------------+---- | | ---+---------- | | - | | NSF-Facing Interface | |(a)-| Developer's| | | - | ----+---- ----+---- ----+---- | | Mgmt System| | | - | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| |(b)-| (VNFM) | | | - | ----+---- ----+---- ----+---- | | ---+---------- | | + | -----+---------- (a) ----------------- | | | | | + | | Security |-------| Developer's | | | | | | + | |Controller(EM)| |Mgmt System(EM)| | | | | | + | -----+---------- ----------------- | | ----+----- | | + | | NSF-Facing Interface | | | | | | + | ----+----- ----+----- ----+----- | | | VNFM(s)| | | + | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| +-(b)-+ | | | + | ----+----- ----+----- ----+----- | | ----+----- | | | | | | | | | | | +------|-------------|-------------|--------+ | | | | | | | | | | | +------+-------------+-------------+--------+ | | | | | NFV Infrastructure (NFVI) | | | | | | ----------- ----------- ----------- | | | | | | | Virtual | | Virtual | | Virtual | | | | | | | | Compute | | Storage | | Network | | | | | | - | ----------- ----------- ----------- | | ---+------ | | + | ----------- ----------- ----------- | | ----+----- | | | +---------------------------------------+ | | | | | | - | | Virtualization Layer | |--|-| VIM(s) +-------- | + | | Virtualization Layer | +-----+ VIM(s) +------+ | | +---------------------------------------+ | | | | | | +---------------------------------------+ | | ---------- | | | ----------- ----------- ----------- | | | | | | | Compute | | Storage | | Network | | | | | - | | | hardware| | hardware| | hardware| | | | | + | | | Hardware| | Hardware| | Hardware| | | | | | | ----------- ----------- ----------- | | | | - | | Hardware resources | | | NFV Management | + | | Hardware Resources | | | NFV Management | | +---------------------------------------+ | | and Orchestration | +-------------------------------------------+ +--------------------+ (a) = Registration Interface (b) = Ve-Vnfm Interface Figure 4: I2NSF Framework Implementation in NFV Reference Architectural Framework NFV is a promising technology for improving the elasticity and efficiency of network resource utilization. In NFV environments, @@ -755,70 +758,72 @@ 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 infrastructure as show in Figure 4. Figure 4 shows an I2NSF framework implementation based on the NFV reference architecture that the European Telecommunications Standards Institute (ETSI) defines [ETSI-NFV]. The NSFs are deployed as virtual network functions (VNFs) in Figure 4. The Developer's - Management System in the I2NSF framework is responsible for creating - or removing NSF instances, and can be implemented as the virtual - network functions manager (VNFM) in the NFV architecture that - performs the life-cycle management of VNFs. The Security Controller - can be implemented as the Element Management (EM) in the NFV - architecture that controls and monitors the configurations (e.g., - function parameters and security policy rules) of VNFs. Finally, the - I2NSF User can be implemented as OSS/BSS (Operational Support - Systems/Business Support Systems) in the NFV architecture that - provides interfaces for users in the NFV system. + Management System (DMS) in the I2NSF framework is responsible for + registering capability information of NSFs into the Security + Controller. Those NSFs are created or removed by a virtual network + functions manager (VNFM) in the NFV architecture that performs the + life-cycle management of VNFs. The Security Controller controls and + monitors the configurations (e.g., function parameters and security + policy rules) of VNFs. Both the DMS and Security Controller can be + implemented as the Element Managements (EMs) in the NFV architecture. + Finally, the I2NSF User can be implemented as OSS/BSS (Operational + Support Systems/Business Support Systems) in the NFV architecture + that provides interfaces for users in the NFV system. The operation procedure in the I2NSF framework based on the NFV architecture is as follows: - 1. The Developer's Mgmt System (DMS) has a set of virtual machine - (VM) images of NSFs, and each VM image can be used to create an - NSF instance that provides a set of security capabilities. The - DMS initially registers a mapping table of the ID of each VM - image and the set of capabilities that can be provided by an NSF - instance created from the VM image into the Security Controller. + 1. The VNFM has a set of virtual machine (VM) images of NSFs, and + each VM image can be used to create an NSF instance that provides + a set of security capabilities. The DMS initially registers a + mapping table of the ID of each VM image and the set of + capabilities that can be provided by an NSF instance created from + the VM image into the Security Controller. 2. If the Security Controller does not have any instantiated NSF that has the set of capabilities required to meet the security requirements from users, it searches the mapping table (registered by the DMS) for the VM image ID corresponding to the required set of capabilities. 3. The Security Controller requests the DMS to instantiate an NSF - with the VM image ID. + with the VM image ID via VNFM. - 4. When receiving the instantiation request, the DMS first asks the + 4. When receiving the instantiation request, the VNFM first asks the NFV orchestrator for the permission required to create the NSF instance, requests the VIM to allocate resources for the NSF instance, and finally creates the NSF instance based on the allocated resources. - 5. Once the NSF instance has been created, the DMS performs the - initial configurations of the NSF instance and then notifies the - Security Controller of the NSF instance. + 5. Once the NSF instance has been created by the VNFM, the DMS + performs the initial configurations of the NSF instance and then + notifies the Security Controller of the NSF instance. 6. After being notified of the created NSF instance, the Security Controller delivers low-level security policy rules to the NSF instance for policy enforcement. The I2NSF framework can be implemented based on the NFV architecture. Note that the registration of the capabilities of NSFs is performed through the Registration Interface and the life-cycle management for - NSFs (VNFs) is performed through the Ve-Vnfm interface, as shown in - Figure 4. More details about the I2NSF framework based on the NFV - reference architecture are described in [i2nsf-nfv-architecture]. + NSFs (VNFs) is performed through the Ve-Vnfm interface between the + DMS and VNFM, as shown in Figure 4. More details about the I2NSF + framework based on the NFV reference architecture are described in + [i2nsf-nfv-architecture]. 7. Security Considerations The I2NSF framework with SDN networks in this document is derived from the I2NSF framework [RFC8329], so the security considerations of the I2NSF framework should be included in this document. Therefore, proper secure communication channels should be used the delivery of control or management messages among the components in the proposed framework. @@ -861,42 +866,42 @@ [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. [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-06 (work in + kumar-i2nsf-client-facing-interface-im-07 (work in progress), July 2018. [ETSI-NFV] ETSI GS NFV 002 V1.1.1, "Network Functions Virtualization (NFV); Architectural Framework", October 2013. [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. [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 progress), July 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-05 (work in - progress), January 2018. + Terminology", draft-ietf-i2nsf-terminology-06 (work in + progress), July 2018. [ITU-T.X.1252] Recommendation ITU-T X.1252, "Baseline Identity Management Terms and Definitions", April 2010. [ITU-T.X.800] Recommendation ITU-T X.800, "Security Architecture for Open Systems Interconnection for CCITT Applications", March 1991. @@ -924,26 +929,26 @@ ONF, "SDN Architecture", June 2014. [opsawg-firewalls] Baker, F. and P. Hoffman, "On Firewalls in Internet Security", draft-ietf-opsawg-firewalls-01 (work in progress), October 2012. [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-04 (work in progress), July 2018. + registration-dm-05 (work in progress), July 2018. [registration-inf-im] Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF Registration Interface Information Model", draft-hyun- - i2nsf-registration-interface-im-05 (work in progress), + i2nsf-registration-interface-im-06 (work in progress), July 2018. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [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. @@ -965,30 +970,31 @@ (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-02 +Appendix A. Changes from draft-ietf-i2nsf-applicability-03 The following changes have been made from draft-ietf-i2nsf- - applicability-02: + applicability-03: - o In Section 4, it is explained how the I2NSF framework and SFC can - be combined to support chaining NSFs. + o In Section 4, NSF-Facing Interface is used between Security + Controller and Classifier (or SFF) in order to configure + Classifier (or SFF) for SFC-based NSF chaining. - o In Section 6, it is explained how the I2NSF framework can be - implemented based on the NFV reference architecture. + o In Section 6, Developer's Management System is implemented as EM + rather than VNFM in the NFV reference architecture. Authors' Addresses Jaehoon Paul Jeong Department of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea