Internet DRAFT - draft-yang-i2nsf-nfv-architecture

draft-yang-i2nsf-nfv-architecture







Network Working Group                                            H. Yang
Internet-Draft                                                        KT
Intended status: Informational                                    K. Sun
Expires: 21 November 2022                                         Y. Kim
                                                     Soongsil University
                                                                J. Jeong
                                                 Sungkyunkwan University
                                                             20 May 2022


                I2NSF on the NFV Reference Architecture
                  draft-yang-i2nsf-nfv-architecture-08

Abstract

   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.

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 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 21 November 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Yang, et al.            Expires 21 November 2022                [Page 1]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  I2NSF framework onto the NFV Reference Model  . . . . . . . .   3
     3.1.  Network Security Function . . . . . . . . . . . . . . . .   5
     3.2.  Security Controller . . . . . . . . . . . . . . . . . . .   5
     3.3.  Developer's Management System . . . . . . . . . . . . . .   5
     3.4.  I2NSF Interfaces  . . . . . . . . . . . . . . . . . . . .   5
       3.4.1.  Consumer-Facing Interface . . . . . . . . . . . . . .   6
       3.4.2.  NSF-Facing Interface  . . . . . . . . . . . . . . . .   6
       3.4.3.  Registration Interface  . . . . . . . . . . . . . . .   6
       3.4.4.  Interface for NSF Management  . . . . . . . . . . . .   7
   4.  Initial Configuration Procedure in NFV Architecture . . . . .   7
   5.  Multi-site Consideration  . . . . . . . . . . . . . . . . . .  10
   6.  Cloud Native NFV Architecture . . . . . . . . . . . . . . . .  11
     6.1.  The consideration of the Yang data model in the Container
           environment . . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Use Case of SFC-Enabled I2NSF Framework . . . . . . . . . . .  13
     7.1.  SFC Policy Manager  . . . . . . . . . . . . . . . . . . .  13
     7.2.  SFC Catalog Manager . . . . . . . . . . . . . . . . . . .  14
     7.3.  Developer's Management System in SFC-Enabled I2NSF
           Framework . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.4.  The consideration of SFC-enabled architecture in I2NSF
           Framework . . . . . . . . . . . . . . . . . . . . . . . .  15
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  15
   Appendix A.  Changes from draft-yang-i2nsf-nfv-architecture-05  .  17
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   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



Yang, et al.            Expires 21 November 2022                [Page 2]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


   Virtualization (NFV) environment since an NSF may be provided by
   virtualized infrastructure as a Virtual Network Function (VNF).
   Especially, the I2NSF applicability document [I2NSF-Applicability]
   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.

2.  Terminology

   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].  This
   document uses the terminology described in [RFC8329]
   [I2NSF-Terminology], [I2NSF-Applicability], [ETSI-GS-NFV-003],
   [Registration-Interface], [ETSI-GS-IFA-008], and
   [NSF-Triggered-Steering].

3.  I2NSF framework onto the NFV Reference Model

   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)
   [ETSI-GS-NFV-003].  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).










Yang, et al.            Expires 21 November 2022                [Page 3]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


   In [RFC8329], 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 Figure 1.

                                                  +--------------------+
   +-------------------------------------------+  |  ----------------  |
   |                 OSS/BSS                   |  |  | NFV          |  |
   +---------+---------------------------------+  |  | Orchestrator +-+|
             | (b)                                |  +--+-----------+ ||
   +---------|---------------------------------+  |     |             ||
   |  +------+------+      +-----------------+ |  |     |             ||
   |  |  Security   |      | Developer's Mgmt| |  |     |             ||
   |  | Controller  +--(a)-+    System(EM)   | |  |     |             ||
   |  +------+------+      +-----------------+ |  |  +--+---------+   ||
   |         | (c)                             |  |  |            |   ||
   |     +---+----+   +---+----+   +---+----+  +-(d)-+    VNFM    |   ||
   |     |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| | |  |                    |
   | | +---------+  +---------+  +---------+ | |  |   NFV Management   |
   | |          Hardware Resources           | |  |  and Orchestration |
   | +---------------------------------------+ |  |       (MANO)       |
   +-------------------------------------------+  +--------------------+
    (a) = Registration Interface, (b) = Consumer-Facing Interface
    (C) = NSF-Facing Interface, (d) = Ve-Vnfm Interface


        Figure 1: I2NSF Framework on NFV Reference Architecture




Yang, et al.            Expires 21 November 2022                [Page 4]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


3.1.  Network Security Function

   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.

3.2.  Security Controller

   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.

3.3.  Developer's Management 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.

3.4.  I2NSF Interfaces








Yang, et al.            Expires 21 November 2022                [Page 5]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


3.4.1.  Consumer-Facing Interface

   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 Figure 1.

3.4.2.  NSF-Facing Interface

   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.

3.4.3.  Registration 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
   Figure 1.








Yang, et al.            Expires 21 November 2022                [Page 6]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


3.4.4.  Interface for NSF Management

   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 [ETSI-GS-IFA-008].
   Therefore, as an EM, DMS can use the interface "Ve-Vnfm" to
   communicate with VNFM.

4.  Initial Configuration Procedure in NFV Architecture

   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 Figure 2, 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 [Registration-Interface].
   After that, DMS forwards the NSF initiation request message to VNFM
   via Ve-Vnfm Interface [ETSI-GS-IFA-008].  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.















Yang, et al.            Expires 21 November 2022                [Page 7]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


   I2NSF           Security        Developer's          VNFM       NSF
   User            Controller      Mgmt System
      |               |                 |                 |         |
      |               |                 |                 |         |
      |--High-level-->|                 |                 |         |
      |policy Request |                 |                 |         |
      |               |                 |                 |         |
      |               |                 |                 |         |
      |               |                 |                 |         |
      |        Translation:             |                 |         |
      |      Data Conversion            |                 |         |
      |               |                 |                 |         |
      |               |                 |                 |         |
   case 1: NSFs available(activated) : Go to Policy Generation      |
      |               |                 |                 |         |
      |++case 2: NSFs available(de-activated)+++++++++++++|         |
      |               |                 |                 |         |
      |               |-NSF initiation->|                 |         |
      |               |  Request(Reg)   |-------NSF initiation----->|
      |               |                 |      Request(Ve-Vnfm)     |
      |               |                 |                 |        NSF
      |               |                 |                 |     Creation
      |               |                 |                 |         |
      |               |                 |<------NSF initiation------|
      |               |<-NSF initiation-|      Response(Ve-Vnfm)    |
      |               |   Response(Reg) |                 |         |
      |               |                 |                 |         |
      |++case 2: NSFs available(de-activated)+++++++++++++|         |
      |               |                 |                 |         |
      |        Translation:             |                 |         |
      |      Policy Generation          |                 |         |
      |               |                 |                 |         |
      |               |                 |                 |         |
      |               |---------Low-level policy Request----------->|
      |               |<--------Low-level policy Response-----------|
      |               |                 |                 |         |
      |               |                 |                 |         |
      |               |                 |                 |         |
      |               |                 |                 |         |
      |               |                 |                 |         |
      |               |                 |                 |         |
      |               |                 |                 |         |
      |               |                 |                 |         |



    Figure 2: Procedure of I2NSF Framework on NFV for the Case of
                           'NSF Available'



Yang, et al.            Expires 21 November 2022                [Page 8]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


   I2NSF           Security         Developer's          VNFM       NSF
   User            Controller       Mgmt System
      |               |                  |                 |         |
      |--High-level-->|                  |                 |         |
      |policy Request |                  |                 |         |
      |               |                  |                 |         |
      |          Translation:            |                 |         |
      |        Data Conversion           |                 |         |
      |               |                  |                 |         |
      |          Profile Entry           |                 |         |
      |           not matched            |                 |         |
      |               |                  |                 |         |
      |               |Capability Query->|                 |         |
      |               |                  |                 |         |
      |++case 1: Capability not Searched+++++++++++++++++++|         |
      |               |                  |                 |         |
      |               |<--No-NSF-found---|                 |         |
      |               |      Reply       |                 |         |
      |<--High-level--|                  |                 |         |
    policy Response(failure)             |                 |         |
      |               |                  |                 |         |
      |++case 1: Capability not Searched+++++++++++++++++++|         |
      |               |                  |                 |         |
      |    +case 2: Capability not Searched++++++++++++++++++++++    |
      |    |          |                  |                 |         |
      |    |          |--NSF Creation--->|                 |         |
      |    |          |   Request(Reg)   |-------NSF Creation------->|
      |    |          |                  |       Request(Ve-Vnfm)    |
      |    |          |                  |                 |       NSF
      |    |          |                  |                 |    Creation
      |    |          |                  |                 |         |
      |    |          |                  |<------NSF Creation--------|
      |    |          |<--NSF Creation---|      Response(Ve-Vnfm)    |
      |    |          |   Response(Reg)  |      (with NSF info)      |
      |    |          |                  |                 |         |
      |    |    Translation:             |                 |         |
      |    |  Policy Generation          |                 |         |
      |    |          |                  |                 |         |
      |    |          |----------Low-level policy Request----------->|
      |    |          |<---------Low-level policy Response-----------|
      |    |          |                  |                 |         |
      |<--High-level--|                  |                 |         |
    policy Response(Success)             |                 |         |
      |    |          |                  |                 |         |







Yang, et al.            Expires 21 November 2022                [Page 9]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


  Figure 3: Procedure of I2NSF Framework on NFV for the Case of 'No
                            NSF Existing'

   However, when the NSF does not exist, The procedure is as follows.
   As shown in Figure 3, 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.

5.  Multi-site Consideration

   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.











Yang, et al.            Expires 21 November 2022               [Page 10]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


6.  Cloud Native NFV Architecture

   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 [ETSI-NFV-IFA29].
   In addition, standardization is in progress based on
   [ETSI-NFV-IFA40], [ETSI-NFV-IFA10] and [ETSI-NFV-IFA11] 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, [ETSI-NFV-IFA29] 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.  Figure 4 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 [ETSI-NFV-IFA29]
   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.








Yang, et al.            Expires 21 November 2022               [Page 11]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


                                                  +--------------------+
   +-------------------------------------------+  |  ---------------+  |
   |                 OSS/BSS                   |  |  | NFV          |  |
   +---------+---------------------------------+  |  | Orchestrator |  |
             | (b)                                |  +--+-----------+  |
   +---------|---------------------------------+  |     |              |
   |+--------+--------------------------------+|  |     |              |
   ||        |                  I2NSF PaaS    ||  |     |              |
   || +------+------+      +-----------------+||  |     |              |
   || |  Security   |      | Developer's Mgmt|||  |     |              |
   || | Controller  +--(a)-+      System     |||  |     |              |
   || +------+------+      +-----------------+||  |  +--+---------+    |
   ||        | (c)                            ||  |  |            |    |
   || +------+------------------------------+ |+-(d)-+    VNFM    +-+  |
   || |            Consumer-NSFs            | ||  |  |            | |  |
   || +-------------------------------------+ ||  |  +--+---------+ |  |
   || +-------|-------+     +--------|------+ ||  |     |           |  |
   || | NSF Instance  |     |  NSF Instance | ||  |     |           |  |
   || +---------------+     +---------------+ ||  |     |           |  |
   |+-----------------------------------------+|  |     |           |  |
   +-------------------------------------------+  |     |(e)        |  |
   +-------------------------------------------+  |     |           |  |
   | +----------+   +----------+  +----------+ |  |     |           |  |
   | | Container|   | Container|  | Container| |  |     |           |  |
   | +----------+   +----------+  +----------+ |  |  +--+---------+ |  |
   | +---------------------------------------+ +-(f)-+    CISM    | |  |
   | |   Conatiner Infra Service Instance    | |  |  +------------+ |  |
   | +---------------------------------------+ |  |                 |  |
   | +---------------------------------------+ |  |  +------------+ |  |
   | |          Hardware Resources           | +-----+     VIM    +-+  |
   | +---------------------------------------+ |  |  +------------+    |
   +-------------------------------------------+  +--------------------+
    (a) = Registration Interface, (b) = Consumer-Facing Interface,
    (C) = NSF-Facing Interface, (d) = Ve-Vnfm Interface,
    (e) = CISM-Vnfm Interface,  (f) = CISM-CIS Interface


              Figure 4: Deployment Scenario for I2NSF PaaS

6.1.  The consideration of the Yang data model in the Container
      environment

   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.





Yang, et al.            Expires 21 November 2022               [Page 12]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


   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.

7.  Use Case of SFC-Enabled I2NSF Framework

   A service service in the I2NSF applicability in
   [I2NSF-Applicability]> requires a forwarding mechanism for cloud-
   based security services.  Especially, a Service Function Chaining
   (SFC)-enabled I2NSF Architecture in [NSF-Triggered-Steering] 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.

7.1.  SFC Policy Manager

   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).









Yang, et al.            Expires 21 November 2022               [Page 13]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


   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.

7.2.  SFC Catalog Manager

   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.

7.3.  Developer's Management System in SFC-Enabled I2NSF Framework

   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.





Yang, et al.            Expires 21 November 2022               [Page 14]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


7.4.  The consideration of SFC-enabled architecture in I2NSF Framework

   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.

8.  Security Considerations

   This document specifies the implementation of the I2NSF framework in
   the NFV system, so the same security considerations for the I2NSF
   framework [RFC8329] 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
   [ETSI-GS-NFV-SEC-001].

9.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8329]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
              Kumar, "Framework for Interface to Network Security
              Functions", RFC 8329, February 2018,
              <https://www.rfc-editor.org/rfc/rfc8329>.

   [I2NSF-Applicability]
              Jeong, J., Hyun, S., Ahn, T., Hares, S., and D. Lopez,
              "Applicability of Interfaces to Network Security Functions
              to Network-Based Security Services", Work in Progress,
              Internet-Draft, draft-ietf-i2nsf-applicability-13, June
              2019, <https://datatracker.ietf.org/doc/html/draft-ietf-
              i2nsf-applicability-13>.

   [NSF-Triggered-Steering]
              Hyun, S., Jeong, J., Park, J., and S. Hares, "Service
              Function Chaining-Enabled I2NSF Architecture", Work in



Yang, et al.            Expires 21 November 2022               [Page 15]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


              Progress, Internet-Draft, draft-hyun-i2nsf-nsf-triggered-
              steering-06, July 2018,
              <https://datatracker.ietf.org/doc/html/draft-hyun-i2nsf-
              nsf-triggered-steering-06>.

   [ETSI-GS-NFV-003]
              "Network Functions Virtualization (NFV); Architectural
              Framework", October 2013.

   [I2NSF-Terminology]
              Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
              Birkholz, "Interface to Network Security Functions (I2NSF)
              Terminology", Work in Progress, Internet-Draft, draft-
              ietf-i2nsf-terminology-06, July 2018,
              <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-
              terminology-06>.

   [Registration-Interface]
              Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF
              Registration Interface YANG Data Model", Work in Progress,
              Internet-Draft, draft-ietf-i2nsf-registration-interface-
              dm-01, November 2018,
              <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-
              registration-interface-dm-01>.

   [ETSI-GS-IFA-008]
              "Network Functions Virtualisation (NFV);Management and
              Orchestration;Ve-Vnfm reference point - Interface
              andInformation Model Specification", October 2016.

   [ETSI-GS-NFV-SEC-001]
              "Network Functions Virtualisation (NFV); NFV Security;
              Problem Statement", October 2014.

   [ETSI-NFV-IFA29]
              "Network Functions Virtualisation (NFV) Release 3;
              Architecture; Report on the Enhancements of the NFV
              architecture towards "Cloud-native" and "PaaS"", November
              2019.

   [ETSI-NFV-IFA40]
              "Network Functions Virtualisation (NFV) Release 4;
              Management and Orchestration; Requirements for service
              interfaces and object model for OS container management
              and orchestration specification", March 2020.






Yang, et al.            Expires 21 November 2022               [Page 16]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


   [ETSI-NFV-IFA10]
              "Network Functions Virtualisation (NFV) Release
              3;Management and Orchestration;Functional requirements
              specification", April 2019.

   [ETSI-NFV-IFA11]
              "Network Functions Virtualisation (NFV) Release
              4;Management and Orchestration;VNF Descriptor and
              Packaging Specification", September 2020.

Appendix A.  Changes from draft-yang-i2nsf-nfv-architecture-05

   The following changes have been made from draft-yang-i2nsf-nfv-
   architecture-05:

   *  In this version, Section 6 is added.

Appendix B.  Acknowledgements

   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).

Authors' Addresses

   Hyunsik Yang
   KT
   KT Research Center 151
   Taebong-ro, Seocho-gu
   Seoul
   06763
   Republic of Korea
   Phone: +82 10 9777 7439
   Email: yangun@dcn.ssu.ac.kr


   Kyoungjae Sun
   Soongsil University
   369, Sangdo-ro, Dongjak-gu
   Seoul
   06978
   Republic of Korea
   Phone: +82 10 3643 5627
   Email: gomjae@dcn.ssu.ac.kr






Yang, et al.            Expires 21 November 2022               [Page 17]

Internet-Draft   I2NSF on the NFV Reference Architecture        May 2022


   Younghan Kim
   School of Electronic Engineering
   Soongsil University
   369, Sangdo-ro, Dongjak-gu
   Seoul
   Seoul
   06978
   Republic of Korea
   Phone: +82 10 2691 0904
   Email: younghak@ssu.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
   Email: pauljeong@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php




























Yang, et al.            Expires 21 November 2022               [Page 18]