I2NSF on the NFV Reference Architecture
KT KT Research Center 151Taebong-ro, Seocho-guSeoul06763Republic of Korea+82 10 9777 7439yangun@dcn.ssu.ac.kr Soongsil University 369, Sangdo-ro, Dongjak-guSeoul06978Republic of Korea+82 10 3643 5627gomjae@dcn.ssu.ac.kr
School of Electronic Engineering
Soongsil University369, Sangdo-ro, Dongjak-guSeoulSeoul06978Republic of Korea+82 10 2691 0904younghak@ssu.ac.kr
Department of Software
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4957+82 31 290 7996pauljeong@skku.eduhttp://iotlab.skku.edu/people-jaehoon-jeong.php
Internet-Draft
This document describes the integration of Interface to Network Security Functions
(I2NSF) Framework into the Network Functions Virtualization (NFV) Reference Model.
This document explains how the components and interfaces in the I2NSF Framework
can be placed in the NFV reference architecture, and also explains the procedures of
the lifecycle management of Network Security Functions (NSFs) according to
a user's security policy specification in the I2NSF framework on the NFV system.
The goal of Interface to Network Security Functions (I2NSF) is to define
a set of software interfaces and components for controlling and
monitoring aspects of physical and virtual Network Security Functions (NSFs),
with which a user can specify high-level security policy. To achieve this goal,
the I2NSF framework not only considers physical infrastructure, but also
considers a Network Functions Virtualization (NFV) environment since an NSF may
be provided by virtualized infrastructure as a Virtual Network Function (VNF).
Especially, the I2NSF applicability document
describes the applicability of I2NSF to network-based security services in an NFV environment.
Although it explains how I2NSF framework in an NFV environment for security services,
it does not explain the procedures of the lifecycle management of NSFs in detail.
Thus, this document explains such procedures in the I2NSF framework on the NSF system
along with the places of the components of the I2NSF framework in the NFV system.
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 .
This document uses the terminology described in , ,
, ,
, and .
The European Telecommunications Standards Institute (ETSI) defined
the components for the basic NFV architecture including the NFV
Infrastructure (NFVI), VNF Manager (VNFM), Virtualization
Infrastructure Manager (VIM), and NFV Orchestrator (NFVO) .
NFVI provides the virtual resources, such as a Virtual Machine (VM) and a Virtual
Network, which are used to create, update, and delete VNFs running applications.
VNFs are implemented through software virtualization techniques running over the NFVI.
Virtualized Infrastructure Manager (VIM) has a function for
controlling and managing the NFVI compute, storage and network
nodes, within one operator's infrastructure sub-domain. It also
collects and forwards performance measurement data and events.
VNFM manages the VNF lifecycle. When a VNF is created, the VNFM
manages the VNF instance in the lifecycle, and the VNFM performs
several actions such as software update/modification, monitoring data
collection (e.g., fault event in the VNF, and instance termination).
In , the I2NSF framework has four components
(i.e., I2NSF User, Security Controller, NSF, and Developer's Management System (DMS))
along with three main interfaces (i.e., Consumer-Facing Interface, NSF-Facing Interface,
and Registration Interface).
To adopt these components to the NFV reference architecture,
each component should be classified based on functionality. According
to component functionality, it would correspond to NFV reference
architecture components as .
A Network Security Function (NSF) is one of the security service functions.
In the ETSI reference architecture, a VNF is a network function which provides a specific service.
Therefore, an NSF corresponds to a VNF in the NFV reference architecture.
According to an I2NSF framework, Security Controller has a role to
translate an I2NSF User's high-level security policy into a low-level security policy
for an NSF. It also collects an NSF's capability information from DMS.
Based on the features of the I2NSF framework, Security Controller receives
a high-level security policy from an I2NSF user over Consumer-Facing Interface,
and after the security policy translation, it can forward the corresponding
low-level security policy to an appropriate NSF over NSF-Facing Interface.
In the NFV reference architecture, Element Management (EM) has a role to manage its
service function (e.g., firewall, Deep Packet Inspection, DDoS-attack mitigator) and
collaborate with the VNF Manager for the lifecycle management (e.g., the instantiation
and de-instantiation) of a VNF corresponding to the required security function.
This lifecycle management requires the exchange of information regarding the
NFVI resources associated with the VNF. EM performs typical management functionality
for its own VNFs.
This document proposes that Security Controller can be implemented as an EM
that can give a security policy to an NSF, and control the NSF.
Note that from the perspective of implementation, it can also be configured as
an independent component in the NFV system.
According to the definition of I2NSF Registration Interface, DMS
registers its NSF, which can be provided by a specific vendor, into Security Controller
along with the capability of the NSF.
In the NFV reference architecture, when a general VNFM creates and manages an NSF,
DMS can be used as an EM to manage the specific function of an NSF.
The Consumer-Facing Interface is an interface for communication
between I2NSF User and Security Controller. It is used to enable
different I2NSF Users in a given I2NSF system to define, manage, and
monitor security policies for specific flows within an administrative
domain.
In the NFV reference architecture, Operational Support Systems (OSS)
and Business Support Systems (BSS) are used to manipulate their applications
(e.g., security services) with their policies and rules. OSS and BSS support
a user-domain-specific system for users, such as security enforcement, billing,
order, and metering.
Although an interface is not defined between an I2NSF User and a VNF in the NFV
reference architecture, Consumer-Facing interface can be deployed for the interaction
between an I2NSF user and an VNF, as illustrated in .
The NSF-Facing Interface is an interface for communication between
Security Controller and NSF. It is used to specify and monitor flow-
based security policies enforced by one or more NSFs.
In the NFV reference architecture, Software Architecture (SWA)-4
Interface is defined. The interface SWA-4 is used by the EM to
communicate with a VNF. This management interface is used for the
runtime management of the VNF according to Fulfillment,
Assurance, Billing, and FCAPS (Fault, Configuration, Accounting,
Performance, Security) network management models and frameworks.
Therefore, NSF-Facing Interface corresponds to the SWA-4 interface.
Registration Interface is used to register an NSF from DMS System to Security Controller.
An NSF's capabilities can either be pre-configured or retrieved dynamically through
the I2NSF Registration Interface. Also, it is to search an appropriate NSF with the required
capability that can execute the requested security service.
In the NFV reference architecture, an interface is not defined between EM,
the registraion-interface can be deployed like a .
In this model, DMS needs to communicate with VNFM to create an NSF dynamically.
This interface is not defined in the I2NSF framework, since it is out of the scope of the I2NSF.
However, ETSI defined an interface "Ve-Vnfm" between EM and VNFM . Therefore, as an EM, DMS can use the interface "Ve-Vnfm" to communicate with VNFM.
The security service procedure in the proposed architecture is as
follows. When an I2NSF User requests a security service to Security
Controller with a high-level policy, Security Controller translates
the high-level policy into the corresponding low-level policy.
Then, it searches the NSF list with capabilities for the requested
security service according to the low-level policy. In this step,
there are two use cases.
As shown in ,
the first case is the case that when an NSF with the required capability is in active state.
The second case is the case that when an NSF with required capability is in inactive state.
When the NSF is in active state, Security Controller generates a low-level policy and
forwards it to the NSF to set the low-level policy up.
On the other hand, when the NSF is in inactive state, Security Controller sends
an NSF initiation request message to the DMS via Registration Interface and
DMS analyzes the message according to the vendor's configuration .
After that, DMS forwards the NSF initiation request message to VNFM via Ve-Vnfm Interface .
After the initiation of the NSF, VNFM sends back an NSF initiation response message
to Security Controller with an NSF's access information (e.g., IP address,
transport-layer protocol, port number, and the NSF's name).
With the received NSF access information, Security Controller generates a low-level policy
and forwards it to the NSF to set the security policy up.
However, when the NSF does not exist, The procedure is as follows.
As shown in ,
when an NSF does not exist, Security Controller sends a Capability Query message
to DMS to search for an NSF with the requested capability.
When DMS does not find such an NSF, the procedure is terminated after sending
Security Controller a failure notification message, which means that it does not
have any NSF with the requested capability.
On the other hand, When there exists an NSF corresponding to the requested
capability, DMS sends an NSF creation request message to the VNFM.
After the creation of the NSF as a VNF, it is registered into DMS. DMS
registers the NSF with capability and access information into Security Controller
via Registration Interface. The remaining procedure is the same as the previous case.
The previous section described how the I2NSF framework is plugged into
the NFV architecture in a single site. From the perspective of NFV, when
security functions are deployed, it might be deployed at a single site
or multiple sites.
Basically, the I2NSF framework only considers that a single DMS
could manage all its NSFs.
From the perspective of ETSI reference architecture, when NSFs are
deployed at a multi-site environment, a DMS could manage all of the NSFs in
such an environment in the same way of a single site.
Alternatively, multiple DMSs could manage the NSFs together.
The I2NSF framework only considers a single Security Controller that manages
all the NSFs in its management domain. This implies that one Security Controller
as an EM should be located at the domain.
However, from the perspective of ETSI reference architecture, an EM usually
is located at each site and controls a VNF which belongs to that site.
The I2NSF framework should consider the placement of Security Controller in
a multi-site environment, since there is a conflict between the I2NSF
framework and the ETSI NFV reference architecture regarding the placement of
Security Controller as an EM.
In the NFV reference architecture of the previous section, we only described architecture based on VM. However, in these days, cloud-native environment has been emerged that network function is decomposed to multiple micro-services and running on containers as VNF Components (VNFCs). In the perspective of cloud-native environment, the architecture should be modified based on standard document for Cloud Native architecture. ETSI defines NFV reference architecture in Cloud Native environment based on . In addition, standardization is in progress based on , and documents. In their documents, they defined Container Infrastructure Service Management (CISM) which is composed Managed Container Infrastructure Object (MCIO) and Virtual Resource (VR) management system. Depending on various deployment option for placing CISM and containerized infrastructure, defined 6 architectural options with mapping to the NFV-MANO components. In their scenario, the CISM can be embedded to VIM, deployed separately into VIM and VNFM, or running independently. Also, the CISM can be deployed into VM as VNF or individual component in NFV-MANO.
From this cloud-native perspective, NSF also can be considered to deploy as cloud-native functions. In this case, I2NSF framework can be provided Platfrom-as-a-Service (PaaS) model, which is agnostic to hosting environment, location of NSF and underlaying network topology. is shown an example of deploying I2NSF PaaS with additional interfaces for interworking with the CISM. In this scenario, the developer's management system can access the MCIO to register NSF's capability and description for configuring NSF object. The security controller has responsibility to modify runtime environment of specific NSF via the CISM by requesting from user, and also internal configuration of NSF container. The CISM recieves instantiation requests from VNFM via CISM-Vnfm interface then deploys NSF container via CISM-CIS interface. I2NSF consumer-facing interface can be supported with extension of interface between CISM and VNFM/NFV Orchestrator, which is defined in the as CISM northbound interface. As similar, NSF-facing interface can be mapped to CISM southbound interface that creates/modify/update containerized workloads. For registration interface, it is possible to provide API specified to container orchestrator, such as Kubernetes, between security controller and developer's managment system.
In a container environment, NSF computing resources and types of functions (ex, IDS/DPI, etc.) can be described in Helm and it is used in NSF's deployment. Based on this, basic components and network settings defined in I2NSF are possible.
Network settings enable communication among each component, but policies needed for NSF require separate settings using Yang data model. The I2NSF defined the Yang data model for communication between each component as follows.
NSF Monitoring Interface YANG Data Model
Network Security Function-Facing Interface YANG Data Model
Consumer-Facing Interface YANG Data Model
Capability YANG Data Model
The defined data model is referred for data transmission/reception after deployment, the actual data uses a protocol such as Netconf. In a container environment, the settings for Netconf can be included in a basic deployment file. The data model which is used for policy configurations mentioned above can be included in the existing Helm chart in XML format or configured in a separate file for setting.
A service service in the I2NSF applicability in >
requires a forwarding mechanism for cloud-based security services. Especially,
a Service Function Chaining (SFC)-enabled I2NSF Architecture in
shows a use case that uses SFC as a forwarding mechanism. In addition,
it specifies SFC components for I2NSF-based sercurity services (e.g., Classifier and
Service Function Forwarder (SFF)) and defines the required functionality of the components.
Therefore, the following subsections explain the details of each component and
consider how it corresponds to the NFV reference architecture.
SFC Policy Manager is a part of Security Controller. It is
responsible for interpreting a high-level security policy into a low-level security
policy, which is given by I2NSF User. It also handles the delivery of
the interpreted policy to SFC Classifier(s) for security function chaining.
Moreover, it also generates the information of the security function chaining for the
requested security service to SFF(s).
In the NFV reference architecture, Management and Orchestration (MANO) performs
similar functions as the SFC Policy Manager. More specifically, the NFV Orchestrator (NFVO)
performs on-boarding of a new Network Service (NS), VNF-FG (Forwarding Graph), and VNF Packages.
In addition, it manages NS lifecycle (including instantiation, scale-out/in,
performance measurement, event correlation, and termination).
Therefore, SFC Policy Manager corresponds to NFVO. In addition, if
SFC Policy Manager is a part of Security Controller, this function
should be separated from Security Controller, and then be placed in MANO.
SFC Catalog Manager is a part of Security Controller. It is
responsible for maintaining the information of every available SF
instance such as IP address, transport-layer protocol, port number,
service name, and load status. Moreover, it should respond to the
queries for available NSF instances from SFC Policy Manager in order to help
the generation of a forwarding table entry relevant to a given SFP. It also
requests DMS to dynamically instantiate additional SF instances in order to
avoid service congestion in an NSF or the elimination of an idle NSF
instance to avoid resource waste.
In the NFV reference architecture, SFC Catalog Manager corresponds to
an EM since the information related to VNF capability is managed by the EM.
Moreover, its functions are similar to Security Controller's as explained before.
In the SFC-enabled document, the functions of DMS are extended.
For the request message from SFC Catalog Manager,
DMS creates additional NSF instances for load balancing and eliminates
some of idle NSF instances.
As mentioned above, if DMS manages the NSF's lifecycle indirectly with VNFM,
it play a role of a VNFM. VNF lifecycle management includes
the instantiation, creation, provisioning, scaling, monitoring, and
termination of a VM as a VNF instance. Therefore, DMS corresponds to a
specific VNFM.
However, for the scaling performance at a network service level, the role
of DMS can be a part of MANO.
As mentioned above, when the I2NSF is provided in an NFV environment, various use cases can be provided through SFC technology.
As an NFV point of view, SFC can be provided in two ways. The first way is to configure the SFC between NSF through the individual SDN controller, and the second is to configure the SFC through the network management function in the cloud.
The way to provide traffic steering capabilities may vary depending on the cloud environment, but the Security Controller must request traffic steering to the SDN controller or network function management via VNFM (using Ve-Vnfm interface). Traffic steering can be provided through physical switches or Virtual Switch.
This document specifies the implementation of the I2NSF framework in the NFV system,
so the same security considerations for the I2NSF framework
can be applied to this document.
This document shares all the security issues of NFV that are
specified in the "Potential Areas of Concern" section of
.
Key words for use in RFCs to Indicate Requirement LevelsFramework for Interface to Network Security FunctionsApplicability of Interfaces to Network Security Functions to Network-Based Security ServicesService Function Chaining-Enabled I2NSF ArchitectureNetwork Functions Virtualization (NFV); Architectural FrameworkInterface to Network Security Functions (I2NSF) TerminologyI2NSF Registration Interface YANG Data ModelNetwork Functions Virtualisation (NFV);Management and Orchestration;Ve-Vnfm reference point - Interface andInformation Model SpecificationNetwork Functions Virtualisation (NFV); NFV Security; Problem StatementNetwork Functions Virtualisation (NFV) Release 3; Architecture; Report on the Enhancements of the NFV architecture towards "Cloud-native" and "PaaS"Network Functions Virtualisation (NFV) Release 4; Management and Orchestration; Requirements for service interfaces and object model for OS container management and orchestration specificationNetwork Functions Virtualisation (NFV) Release 3;Management and Orchestration;Functional requirements specification Network Functions Virtualisation (NFV) Release 4;Management and Orchestration;VNF Descriptor and Packaging Specification
The following changes have been made from draft-yang-i2nsf-nfv-architecture-05:
In this version, is added.
This work was supported in part by the Ministry of Science and ICT (MSIT)
under the ITRC (Information Technology Research Center) support program
(IITP-2019-2017-0-01633) supervised by the Institute for Information &
communications Technology Promotion (IITP).