Security Policy Translation in Interface to Network Security Functions
draft-yang-i2nsf-security-policy-translation-09

Document Type Active Internet-Draft (individual)
Authors Jaehoon (Paul) Jeong  , Patrick Lingga  , Jinhyuk Yang  , Chaehong Chung 
Last updated 2021-08-21
Stream (None)
Formats plain text html xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
I2NSF Working Group                                             J. Jeong
Internet-Draft                                                 P. Lingga
Intended status: Standards Track                                 J. Yang
Expires: 22 February 2022                                       C. Chung
                                                 Sungkyunkwan University
                                                          21 August 2021

 Security Policy Translation in Interface to Network Security Functions
            draft-yang-i2nsf-security-policy-translation-09

Abstract

   This document proposes a scheme of security policy translation (i.e.,
   Security Policy Translator) in Interface to Network Security
   Functions (I2NSF) Framework.  When I2NSF User delivers a high-level
   security policy for a security service, Security Policy Translator in
   Security Controller translates it into a low-level security policy
   for Network Security Functions (NSFs).  For this security policy
   translation, this document specifies the mapping between a high-level
   security policy based on the Consumer-Facing Interface YANG data
   model and a low-level security policy based on the NSF-Facing
   Interface YANG data model.  Also, it describes an architecture of a
   security policy translator along with an NSF database, and the
   process of security policy translation with the NSF database.

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 22 February 2022.

Copyright Notice

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

Jeong, et al.           Expires 22 February 2022                [Page 1]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Necessity for Security Policy Translator  . . . . . . . . . .   3
   4.  Design of Security Policy Translator  . . . . . . . . . . . .   4
     4.1.  Overall Structure of Security Policy Translator . . . . .   5
     4.2.  DFA-based Data Extractor  . . . . . . . . . . . . . . . .   6
       4.2.1.  Design of DFA-based Data Extractor  . . . . . . . . .   6
       4.2.2.  Example Scenario for Data Extractor . . . . . . . . .   7
     4.3.  Data Converter  . . . . . . . . . . . . . . . . . . . . .  10
       4.3.1.  Role of Data Converter  . . . . . . . . . . . . . . .  10
       4.3.2.  NSF Database  . . . . . . . . . . . . . . . . . . . .  10
       4.3.3.  Data Conversion in Data Converter . . . . . . . . . .  12
       4.3.4.  Data Model Mapper . . . . . . . . . . . . . . . . . .  13
       4.3.5.  Policy Provisioning . . . . . . . . . . . . . . . . .  18
     4.4.  CFG-based Policy Generator  . . . . . . . . . . . . . . .  20
       4.4.1.  Content Production  . . . . . . . . . . . . . . . . .  20
       4.4.2.  Structure Production  . . . . . . . . . . . . . . . .  21
       4.4.3.  Generator Construction  . . . . . . . . . . . . . . .  21
   5.  Implementation Considerations . . . . . . . . . . . . . . . .  25
     5.1.  Data Model Auto-adaptation  . . . . . . . . . . . . . . .  25
     5.2.  Data Conversion . . . . . . . . . . . . . . . . . . . . .  26
     5.3.  Policy Provisioning . . . . . . . . . . . . . . . . . . .  26
   6.  Features of Security Policy Translator Design . . . . . . . .  26
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  27
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  27
     10.2.  Informative References . . . . . . . . . . . . . . . . .  28
   Appendix A.  Changes from
           draft-yang-i2nsf-security-policy-translation-08 . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

Jeong, et al.           Expires 22 February 2022                [Page 2]
Internet-Draft      I2NSF Security Policy Translation        August 2021

1.  Introduction

   This document defines a scheme of a security policy translation in
   Interface to Network Security Functions (I2NSF) Framework [RFC8329].
   First of all, this document explains the necessity of a security
   policy translator (shortly called policy translator) in the I2NSF
   framework.

   The policy translator resides in Security Controller in the I2NSF
   framework and translates a high-level security policy to a low-level
   security policy for Network Security Functions (NSFs).  A high-level
   policy is specified by I2NSF User in the I2NSF framework and is
   delivered to Security Controller via Consumer-Facing Interface
   [I-D.ietf-i2nsf-consumer-facing-interface-dm].  It is translated into
   a low-level policy by Policy Translator in Security Controller and is
   delivered to NSFs to execute the rules corresponding to the low-level
   policy via NSF-Facing Interface
   [I-D.ietf-i2nsf-nsf-facing-interface-dm].

2.  Terminology

   This document uses the terminology specified in [RFC8329].

3.  Necessity for Security Policy Translator

   Security Controller acts as a coordinator between I2NSF User and
   NSFs.  Also, Security Controller has capability information of NSFs
   that are registered via Registration Interface
   [I-D.ietf-i2nsf-registration-interface-dm] by Developer's Management
   System [RFC8329].  As a coordinator, Security Controller needs to
   generate a low-level policy in the form of security rules intended by
   the high-level policy, which can be understood by the corresponding
   NSFs.

   A high-level security policy is specified by RESTCONF/YANG
   [RFC8040][RFC6020], and a low-level security policy is specified by
   NETCONF/YANG [RFC6241][RFC6020].  The translation from a high-level
   security policy to the corresponding low-level security policy will
   be able to rapidly elevate I2NSF in real-world deployment.  A rule in
   a high-level policy can include a broad target object, such as
   employees in a company for a security service (e.g., firewall and web
   filter).  Such employees may be from human resource (HR) department,
   software engineering department, and advertisement department.  A
   keyword of employee needs to be mapped to these employees from
   various departments.  This mapping needs to be handled by a security
   policy translator in a flexible way while understanding the intention
   of a policy specification.  Let us consider the following two
   policies:

Jeong, et al.           Expires 22 February 2022                [Page 3]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   *  Block my son's computers from malicious websites.

   *  Drop packets from the IP address 10.0.0.1 and 10.0.0.3 to harm.com
      and illegal.com

   The above two sentences are examples of policies for blocking
   malicious websites.  Both policies are for the same operation.
   However, NSF cannot understand the first policy, because the policy
   does not have any specified information for NSF.  To set up the
   policy at an NSF, the NSF MUST receive at least the source IP address
   and website address for an operation.  It means that the first
   sentence is NOT compatible for an NSF policy.  Conversely, when I2NSF
   Users request a security policy to the system, they never make a
   security policy like the second example.  For generating a security
   policy like the second sentence, the user MUST know that the NSF
   needs to receive the specified information, source IP address and
   website address.  It means that the user understands the NSF
   professionally, but there are not many professional users in a small
   size of company or at a residential area.  In conclusion, the I2NSF
   User prefers to issue a security policy in the first sentence, but an
   NSF will require the same policy as the second sentence with specific
   information.  Therefore, an advanced translation scheme of security
   policy is REQUIRED in I2NSF.

   This document proposes an approach using Automata theory [Automata]
   for the policy translation, such as Deterministic Finite Automaton
   (DFA) and Context Free Grammar (CFG).  Note that Automata theory is
   the foundation of programming language and compiler.  Thus, with this
   approach, I2NSF User can easily specify a high-level security policy
   that will be enforced into the corresponding NSFs with a compatibly
   low-level security policy with the help of Security Policy
   Translator.  Also, for easy management, a modularized translator
   structure is proposed.

4.  Design of Security Policy Translator

   Commonly used security policies are created as XML(Extensible Markup
   Language) [XML] files.  A popular way to change the format of an XML
   file is to use an XSLT (Extensible Stylesheet Language
   Transformation) [XSLT] document.  XSLT is an XML-based language to
   transform an input XML file into another output XML file.  However,
   the use of XSLT makes it difficult to manage the security policy
   translator and to handle the registration of new capabilities of
   NSFs.  With the necessity for a security policy translator, this
   document describes a security policy translator based on Automata
   theory.

Jeong, et al.           Expires 22 February 2022                [Page 4]
Internet-Draft      I2NSF Security Policy Translation        August 2021

4.1.  Overall Structure of Security Policy Translator

      +--------------------------------------------------+
      |                    I2NSF User                    |
      +------------------------+-------------------------+
                               | Consumer-Facing Interface
                               |
                   High-level Security Policy
                               |
      Security Controller      V
      +------------------------+--------------------------------+
      |  Security Policy       |                                |
      |  Translator            V                                |
      |  +---------------------+----------------------------++  |
      |  |                     |                             |  |
      |  |                     V                             |  |
      |  |             +-------+--------+       +----------+ |  |
      |  |             |   DFA-based    |       |Data Model| |  |
      |  |             | Data Extractor |       |  Mapper  | |  |
      |  |             +-------+--------+       +----------+ |  |
      |  | Extracted Data from |              Mapping |      |  |
      |  |   High-Level Policy V                Model V      |  |
      |  |               +-----+-----+           +--------+  |  |
      |  |               |    Data   |<--------->| NSF DB |  |  |
      |  |               | Converter |           +--------+  |  |
      |  |               +-----+-----+                       |  |
      |  |                     |  Required Data for          |  |
      |  |                     V  Target NSFs                |  |
      |  |            +--------+---------+                   |  |
      |  |            |    CFG-based     |                   |  |
      |  |            | Policy Generator |                   |  |
      |  |            +--------+---------+                   |  |
      |  |                     |                             |  |
      |  |                     V                             |  |
      |  +---------------------+-----------------------------+  |
      |                        |                                |
      |                        V                                |
      +------------------------+--------------------------------+
                               | NSF-Facing Interface
                               |
                    Low-level Security Policy
                               |
                               V
      +------------------------+-------------------------+
      |                      NSF(s)                      |
      +--------------------------------------------------+

         Figure 1: The Overall Design of Security Policy Translator

Jeong, et al.           Expires 22 February 2022                [Page 5]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   Figure 1 shows the overall design for Security Policy Translator in
   Security Controller.  There are four main components for Security
   Policy Translator: Data Extractor, Data Converter, Policy Generator,
   and Data Model Mapper.

   Extractor is a DFA-based module for extracting data from a high-level
   policy which I2NSF User delivered via Consumer-Facing Interface.
   Data Model Mapper creates a mapping model for mapping the elements
   between Consumer-Facing Interface and NSF-Facing Interface.  Data
   Converter converts the extracted data to the capabilities of target
   NSFs for a low-level policy.  It refers to an NSF Database (DB) in
   order to convert an abstract subject or object into the corresponding
   concrete subject or object (e.g., IP address and website URL).
   Policy Generator generates a low-level policy which will execute the
   NSF capabilities from Converter.

4.2.  DFA-based Data Extractor

4.2.1.  Design of DFA-based Data Extractor

                             +----------+
                             | accepter |
                             +----------+
                                  | ^
                           <tag 1>| |</tag 1>
                                  v |
        +------------------------------------------------------+
        |                      middle 1                        |
        +------------------------------------------------------+
            | ^                 | ^                      | ^
     <tag 2>| |</tag 2>  <tag 3>| |</tag 3>  ...  <tag n>| |</tag n>
            v |                 v |                      v |

            ...                 ...                      ...

      +-------------+      +-------------+          +-------------+
      | extractor 1 |      | extractor 2 |   ...    | extractor m |
      +-------------+      +-------------+          +-------------+
           data:1               data:2                   data:m

                Figure 2: DFA Architecture of Data Extractor

Jeong, et al.           Expires 22 February 2022                [Page 6]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   Figure 2 shows a design for Data Extractor in the security policy
   translator.  If a high-level policy contains data along the
   hierarchical structure of the standard Consumer-Facing Interface YANG
   data model [I-D.ietf-i2nsf-consumer-facing-interface-dm], data can be
   easily extracted using the state transition machine, such as DFA.
   The extracted data can be processed and used by an NSF to understand
   it.  Extractor can be constructed by designing a DFA with the same
   hierarchical structure as a YANG data model.

   After constructing a DFA, Data Extractor can extract all of data in
   the entered high-level policy by using state transitions.  Also, the
   DFA can easily detect the grammar errors of the high-level policy.
   The extracting algorithm of Data Extractor is as follows:

   1.  Start from the 'accepter' state.

   2.  Read the next tag from the high-level policy.

   3.  Transit to the corresponding state.

   4.  If the current state is in 'extractor', extract the corresponding
       data, and then go back to step 2.

   5.  If the current state is in 'middle', go back to step 2.

   6.  If there is no possible transition and arrived at 'accepter'
       state, the policy has no grammar error.  Otherwise, there is a
       grammar error, so stop the process with failure.

4.2.2.  Example Scenario for Data Extractor

                <I2NSF>
                  <name>block_web</name>
                  <cond>
                    <src>Son's_PC</src>
                    <dest>malicious_websites</dest>
                  </cond>
                  <action>block<action>
                </I2NSF>

                 Figure 3: The Example of High-level Policy

Jeong, et al.           Expires 22 February 2022                [Page 7]
Internet-Draft      I2NSF Security Policy Translation        August 2021

                                +----------+
                                | accepter |
                                +----------+
                                     | ^
                              <I2NSF>| |</I2NSF>
                                     v |
           +------------------------------------------------------+
           |                      middle 1                        |
           +------------------------------------------------------+
               | ^                   | ^                    | ^
         <name>| |</name>      <cond>| |</cond>     <action>| |</action>
               v |                   v |                    v |
         +-------------+   +----------------------+    +-------------+
         | extractor 1 |   |       middle 2       |    | extractor 4 |
         +-------------+   +----------------------+    +-------------+
            block_web        | ^              | ^           block
                        <src>| |</src>  <dest>| |</dest>
                             v |              v |
                       +-------------+  +-------------+
                       | extractor 2 |  | extractor 3 |
                       +-------------+  +-------------+
                           Son's_PC        malicious
                                           _websites

                  Figure 4: The Example of Data Extractor

   To explain the Data Extractor process by referring to an example
   scenario, assume that Security Controller received a high-level
   policy for a web-filtering as shown in Figure 3.  Then we can
   construct DFA-based Data Extractor by using the design as shown in
   Figure 2.  Figure 4 shows the architecture of Data Extractor that is
   based on the architecture in Figure 2 along with the input high-level
   policy in Figure 3.  Data Extractor can automatically extract all of
   data in the high-level policy according to the following process:

   1.   Start from the 'accepter' state.

   2.   Read the first opening tag called '<I2NSF>', and transit to the
        'middle 1' state.

   3.   Read the second opening tag called '<name>', and transit to the
        'extractor 1' state.

   4.   The current state is an 'extractor' state.  Extract the data of
        'name' field called 'block_web'.

   5.   Read the second closing tag called '</name>', and go back to the
        'middle 1' state.

Jeong, et al.           Expires 22 February 2022                [Page 8]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   6.   Read the third opening tag called '<cond>', and transit to the
        'middle 2' state.

   7.   Read the fourth opening tag called '<src>', and transit to the
        'extractor 2' state.

   8.   The current state is an 'extractor' state.  Extract the data of
        'src' field called 'Son's_PC'.

   9.   Read the fourth closing tag called '</src>', and go back to the
        'middle 2' state.

   10.  Read the fifth opening tag called '<dest>', and transit to the
        'extractor 3' state.

   11.  The current state is an 'extractor' state.  Extract the data of
        'dest' field called 'malicious_websites'.

   12.  Read the fifth closing tag called '</dest>', and go back to the
        'middle 2' state.

   13.  Read the third closing tag called '</cond>', and go back to the
        'middle 1' state.

   14.  Read the sixth opening tag called '<action>', and transit to the
        'extractor 4' state.

   15.  The current state is an 'extractor' state.  Extract the data of
        'action' field called 'block'.

   16.  Read the sixth closing tag called '</action>', and go back to
        the 'middle 1' state.

   17.  Read the first closing tag called '</I2NSF>', and go back to the
        'accepter' state.

   18.  There is no further possible transition, and the state is
        finally on 'accepter' state.  There is no grammar error in
        Figure 3 so the scanning for data extraction is finished.

   The above process is constructed by an extracting algorithm.  After
   finishing all the steps of the above process, Data Extractor can
   extract all of data in Figure 3, 'block_web', 'Son's_PC',
   'malicious', and 'block'.

   Since the translator is modularized into a DFA structure, a visual
   understanding is feasible.  Also, the performance of Data Extractor
   is excellent compared to one-to-one searching of data for a

Jeong, et al.           Expires 22 February 2022                [Page 9]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   particular field.  In addition, the management is efficient because
   the DFA completely follows the hierarchy of Consumer-Facing
   Interface.  If I2NSF User wants to modify the data model of a high-
   level policy, it only needs to change the connection of the relevant
   DFA node.

4.3.  Data Converter

4.3.1.  Role of Data Converter

   Every NSF has its own unique capabilities.  The capabilities of an
   NSF are registered into Security Controller by a Developer's
   Management System, which manages the NSF, via Registration Interface.
   Therefore, Security Controller already has all information about the
   capabilities of NSFs.  This means that Security Controller can find
   target NSFs with only the data (e.g., subject and object for a
   security policy) of the high-level policy by comparing the extracted
   data with all capabilities of each NSF.  This search process for
   appropriate NSFs is called by policy provisioning, and it eliminates
   the need for I2NSF User to specify the target NSFs explicitly in a
   high-level security policy.

   Data Converter selects target NSFs and converts the extracted data
   into the capabilities of selected NSFs.  If Security Controller uses
   this data convertor, it can provide the policy provisioning function
   to I2NSF User automatically.  Thus, the translator design provides
   big benefits to the I2NSF Framework.

4.3.2.  NSF Database

   The NSF Database contains all the information needed to convert high-
   level policy data to low-level policy data.  The contents of NSF
   Database are classified as the following two: "endpoint information"
   and "NSF capability information".

   The first is "endpoint information".  Endpoint information is
   necessary to convert an abstract high-level policy data such as
   Son's_PC, malicious to a specific low-level policy data such as
   10.0.0.1, illegal.com.  In the high-level policy, the range of
   endpoints for applying security policy MUST be provided abstractly.
   Thus, endpoint information is needed to specify the abstracted high-
   level policy data.  Endpoint information is provided by I2NSF User as
   the high-level policy through Consumer-Facing Interface, and Security
   Controller builds NSF Database based on received information.

   The second is "NSF capability information".  Since capability is
   information that allows NSF to know what features it can support, NSF
   capability information is used in policy provisioning process to

Jeong, et al.           Expires 22 February 2022               [Page 10]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   search the appropriate NSFs through the security policy.  NSF
   capability information is provided by Developer's Management System
   (DMS) through Registration Interface, and Security Controller builds
   NSF Database based on received information.  In addition, if the NSF
   sends monitoring information such as initiating information to
   Security Controller through NSF-Facing Interface, Security Controller
   can modify NSF Database accordingly.

     NSF Capability Information                   Endpoint Information
     +-------------------+   has        convert   +------------------+
     |        NSF        +||---+        +-------||+     Endpoint     |
     +-------------------+     |        |         +------------------+
     | *nsf_id   (INT)   |     |        |         | *end_id (INT)    |
     | nsf_name  (STRING)|     |        |         | keyword (STRING) |
     | inbound   (INT)   |     |        |         +------------------+
     | outbound  (INT)   |     |        |
     | bandwidth (INT)   |     |        |
     | activated (BOOL)  |     |        |
     +-------------------+     |        |
               +---------------+        |        +---------------------+
              /|\                       +------||+ Mapping Information |
     +--------------------+   has       |        +---------------------+
     |     Capability     +||---+       |        | *element_id (INT)   |
     +--------------------+     |       |        | element_name(STR)   |
     | *capa_id   (INT)   |     |       |        | element_map (STR)   |
     | capa_name  (STRING)|     |       |        +---------------------+
     | capa_index (INT)   |     |       |
     +--------------------+     |       |
                               /|\     /|\
                        +-----------------------+
                        |         Field         |
                        +-----------------------+
                        | *field_id   (INT)     |
                        | field_name  (STRING)  |
                        | field_index (INT)     |
                        | mapped_data (STRING)  |
                        +-----------------------+

           Figure 5: Entity-Relationship Diagram of NSF Database

   Figure 5 shows an Entity-Relationship Diagram (ERD) of NSF Database
   designed to include both endpoint information received from I2NSF
   User and NSF capability information received from DMS.  By designing
   the NSF database based on the ERD, all the information necessary for
   security policy translation can be stored, and the network system
   administrator can manage the NSF database efficiently.

Jeong, et al.           Expires 22 February 2022               [Page 11]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   ERD was expressed by using Crow's Foot notation.  Crow's Foot
   notation represents a relationship between entities as a line and
   represents the cardinality of the relationship as a symbol at both
   ends of the line.  Attributes prefixed with * are key values of each
   entity.  A link with two vertical lines represents one-to-one
   mapping, and a bird-shaped link represents one-to-many mapping.  An
   NSF entity stores the NSF name (nsf_name), NSF specification
   (inbound, outbound, bandwidth), and NSF activation (activated).  A
   Capability entity stores the capability name (capa_name) and the
   index of the capability field in a Registration Interface Data Model
   (capa_index).  An Endpoint entity stores the keyword of abstract data
   conversion from I2NSF User (keyword).  A Field entity stores the
   field name (field_name), the index of the field index in an NSF-
   Facing Interface Data Model, and converted data by referring to the
   Endpoint entity and a 'convert' relationship.

4.3.3.  Data Conversion in Data Converter

      High-level                           Low-level
      Policy Data                          Policy Data
   +---------------+                    +------------------------------+
   |   Rule Name   |                    |  Rule Name                   |
   | +-----------+ | The Same value     |  +-------------------------+ |
   | | block_web |-|------------------->|->|        block_web        | |
   | +-----------+ |                    |  +-------------------------+ |
   |               |                    |                              |
   |    Source     | Conversion into    |  Source IPv4                 |
   | +-----------+ | User's IP address  |  +-------------------------+ |
   | | Son's_PC  |-|------------------->|->|   [10.0.0.1, 10.0.0.3]  | |
   | +-----------+ |                    |  +-------------------------+ |
   |               |                    |                              |
   |  Destination  | Conversion into    |  URL Category                |
   | +-----------+ | malicious websites |  +-------------------------+ |
   | | malicious |-|------------------->|->|       [harm.com,        | |
   | | _websites | |                    |  |       illegal.com]      | |
   | +-----------+ |                    |  +-------------------------+ |
   |               |                    |                              |
   |    Action     | Conversion into    |  Log Action     Drop Action  |
   | +-----------+ | NSF Capability     |  +----------+   +----------+ |
   | |   block   |-|------------------->|->|   True   |   |   True   | |
   | +-----------+ |                    |  +----------+   +----------+ |
   +---------------+                    +------------------------------+

                    Figure 6: Example of Data Conversion

   Figure 6 shows an example for describing a data conversion in Data
   Converter.  High-level policy data MUST be converted into low-level
   policy data which are compatible with NSFs.  If a system

Jeong, et al.           Expires 22 February 2022               [Page 12]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   administrator attaches a database to Data Converter, it can convert
   contents by referring to the database with SQL queries.  Data
   conversion in Figure 6 is based on the following list:

   *  'Rule Name' field does NOT need the conversion.

   *  'Source' field SHOULD be converted into a list of target IPv4
      addresses.

   *  'Destination' field SHOULD be converted into a URL category list
      of malicious websites.

   *  'Action' field SHOULD be converted into the corresponding
      action(s) in NSF capabilities.

4.3.4.  Data Model Mapper

   When translating a policy, the mapping between each element of the
   data models are necessary to properly convert the data.  The Data
   Model Mapper create a mapping model between the elements in Consumer-
   Facing Interface Data Model and NSF-Facing Interface Data Model.
   Each element in the Consumer-Facing Interface Policy Data Model has
   at least one or more corresponding element in NSF-Facing Interface
   Data Model.

   Figure 7 shows a mapping list of data fields between Consumer-Facing
   Interface Data Model and NSF-Facing Interface Data Model.  Figure 7
   describes the process of passing the data value to the appropriate
   data field of the Data Model in detail after the data conversion.

   #policy name mapping
   /consumer-facing/i2nsf-cfi-policy/policy-name
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /system-policy-name

   #rule name mapping
   /consumer-facing/i2nsf-cfi-policy/rules/rule-name
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/rule-name

   #start time mapping
   /consumer-facing/i2nsf-cfi-policy/
   /rules/event/time/start-date-time
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/event/time/start-date-time

   #end time mapping
   /consumer-facing/i2nsf-cfi-policy/

Jeong, et al.           Expires 22 February 2022               [Page 13]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   /rules/event/time/end-date-time
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/event/time/end-date-time

   /consumer-facing/i2nsf-cfi-policy/
   /rules/event/time/period/day
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/event/time/period/day

   /consumer-facing/i2nsf-cfi-policy/
   /rules/event/time/period/date
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/event/time/period/date

   /consumer-facing/i2nsf-cfi-policy/
   /rules/event/time/period/month
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/event/time/period/month

   /consumer-facing/i2nsf-cfi-policy/
   /rules/event/time/frequency
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/event/time/frequency

   #firewall-condition source target reference and mapping
   /consumer-facing/i2nsf-cfi-policy/rules/condition
   /firewall-condition/source
       -> reference: /consumer-facing/policy
                     /endpoint-group/user-group/name
       -> reference: /consumer-facing/policy
                     /endpoint-group/device-group/name
           -> extract: /consumer-facing/policy
                       /endpoint-group/user-group/ip-address
               -> mapping: /nsf-facing/i2nsf-security-policy
                           /rules/condition/ipv4
                           /source-address
               -> mapping: /nsf-facing/i2nsf-security-policy
                           /rules/condition/ipv6
                           /source-address

   #firewall-condition destination target reference and mapping
   /consumer-facing/i2nsf-cfi-policy/rule/condition
   /firewall-condition/destination
       -> reference: /consumer-facing/policy
                     /endpoint-group/user-group/name
       -> reference: /consumer-facing/policy
                     /endpoint-group/device-group/name
           -> extract: /consumer-facing/policy

Jeong, et al.           Expires 22 February 2022               [Page 14]
Internet-Draft      I2NSF Security Policy Translation        August 2021

                       /endpoint-group/user-group/ip-address
               -> mapping: /nsf-facing/i2nsf-security-policy
                           /rules/condition/ipv4
                           /destination-address
               -> mapping: /nsf-facing/i2nsf-security-policy
                           /rules/condition/ipv6
                           /destination-address

   #ddos-condition threshold mapping
   /consumer-facing/i2nsf-cfi-policy/rules/condition
   /ddos-condition/packet-rate-threshold
       -> mapping: /nsf-facing/i2nsf-security-policy/rules/condition
                   /ddos/alert-packet-rate

   /consumer-facing/i2nsf-cfi-policy/rules/condition
   /ddos-condition/packet-byte-threshold
       -> mapping: /nsf-facing/i2nsf-security-policy/rules/condition
                   /ddos/alert-byte-rate

   /consumer-facing/i2nsf-cfi-policy/rules/condition
   /ddos-condition/flow-rate-threshold
       -> mapping: /nsf-facing/i2nsf-security-policy/rules/condition
                   /ddos/alert-flow-rate

   #payload-condition mapping
   /consumer-facing/i2nsf-cfi-policy/rules/condition
   /payload/content
       -> reference: /consumer-facing/policy
                     /threat-prevention/payload-content/name
           -> extract: /consumer-facing/policy
                       /threat-prevention/payload-content/content
               -> mapping: /nsf-facing/i2nsf-security-policy
                           /rules/condition/payload
                           /payload-content

   #voice-condition mapping
   /consumer-facing/i2nsf-cfi-policy/rules/condition
   /voice/source-id
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/condition/voice
                   /source-voice-id

   /consumer-facing/i2nsf-cfi-policy/rules/condition
   /voice/destination-id
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/condition/voice
                   /destination-voice-id

Jeong, et al.           Expires 22 February 2022               [Page 15]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   /consumer-facing/i2nsf-cfi-policy/rules/condition
   /voice/user-agent
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/condition/voice
                   /user-agent

   #payload-condition mapping
   /consumer-facing/i2nsf-cfi-policy/rules/condition
   /url
       -> reference: /consumer-facing/policy
                     /url-group/name
           -> extract: /consumer-facing/policy
                       /threat-prevention/payload-content/pre-defined
               -> mapping: /nsf-facing/i2nsf-security-policy
                           /rules/condition/url
                           /pre-defined-category
           -> extract: /consumer-facing/policy
                       /threat-prevention/payload-content/user-defined
               -> mapping: /nsf-facing/i2nsf-security-policy
                           /rules/condition/url
                           /user-defined-category

   #rule action name mapping
   /consumer-facing/i2nsf-cfi-policy/rules/action/name
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/action-clause-container
                   /packet-action/ingress-action
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/action-clause-container
                   /packet-action/egress-action
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/action-clause-container
                   /packet-action/log-action
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/action-clause-container
                   /advanced-action/content-security-control
       -> mapping: /nsf-facing/i2nsf-security-policy
                   /rules/action-clause-container
                   /advanced-action/attack-mitigation-control

             Figure 7: Mapping Information for Data Conversion

   The mapping list shown in the Figure 7 shows all mapped components.
   This data list should be saved into the NSF Database to provide the
   mapping information for converting the data.  It is important to
   produce the list automatically as the Consumer-Facing Interface and
   NSF-Facing Interface can be extended anytime by vendors according to

Jeong, et al.           Expires 22 February 2022               [Page 16]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   the provided NSF.  The Data Model Mapper in Security Policy
   Translator should be used to produce the mapping model information
   automatically.

       Consumer-Facing Interface          NSF-Facing Interface
            YANG Data Model                  YANG Data Model
                   |                               |
                   V                               V
         +---------+-------------------------------+------+
         |         |       Data Model Mapper       |      |
         |         |                               |      |
         |         |  +-------------------------+  |      |
         |         +->| Convert as a Tree Graph |<-+      |
         |            +------------+------------+         |
         |                         |                      |
         |                         v                      |
         |          +----------------------------+        |
         |          | Calculate each element     |        |
         |          | Tree Edit Distance         |        |
         |          | between the CFI and NFI    |        |
         |          +--------------+-------------+        |
         |                         |                      |
         |                         v                      |
         |            +-------------------------+         |
         |            |  Get the elements with  |         |
         |            |  smallest distance as   |         |
         |            |  the candidates         |         |
         |            +-------------------------+         |
         |                         |                      |
         +-------------------------+----------------------+
                                   |
                                   V
                     Data Model Mapping Information

   Note
   CFI: Consumer-Facing Interface
   NFI: NSF-Facing Interface

                        Figure 8: Data Model Mapping

   Figure 8 shows the mapping for I2NSF Security Policy Translator.  The
   mapper uses the Consumer-Facing Interface and NSF-Facing Interface
   YANG Data Model as inputs.  The process the Data Model and converts
   it into a Tree Graph.  Tree Graph is used to proces the Data Model as
   a Tree instead of individual elements.  Then the Data Model Mapper
   calculates the Tree Edit Distance between each element in Consumer-

Jeong, et al.           Expires 22 February 2022               [Page 17]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   Facing Interface and each element in NSF-Facing Interface.  The Tree
   Edit Distance can be calculated with an algorithm, e.g., Zhang-Shasha
   algorithm [Zhang-Shasha], with the calculation should start from the
   root of the tree.

   The Zhang-Shasha calculates the distance by three operations:

   *  Insert: Inserting a node or element

   *  Delete: Deleting a node or element

   *  Change: Change the label of a node or element to another

   The insert and delete operations are a simple of adding/deleting a
   node or element with the length of the label of the node.  The change
   operation must be calculated between the label of the element to
   produce the distance.  There are methods to calculate this, such as
   Levenshtein Distance, Cosine Similarity, or Sequence Matching.  For
   this data model mapper, cosine similarity should be the best choice
   as it measures the similarity between words.  The data models have
   similarity between words and it can helps in calculating as minimum
   distance as possible.

   When the minimum distance is obtained, the NSF-Facing Interface
   element is saved as the candidates for mapping the Consumer-Facing
   Interface element.  This information should be saved to the NSF
   Database for the Data Converter.

   Do note that the proper mapping can be achieved because the
   similarity between the Consumer-Facing Interface and NSF-Facing
   Interface.  An extension created for the Consumer-Facing Interface
   and NSF-Facing Interface should keep the close similarity
   relationship between the data models to be able to produce the
   mapping model information automatically.

4.3.5.  Policy Provisioning

Jeong, et al.           Expires 22 February 2022               [Page 18]
Internet-Draft      I2NSF Security Policy Translation        August 2021

         Log-keeper              Low-level              Web-filter
            NSF                 Policy Data                NSF
   +-------------------+  +--------------------+  +-------------------+
   |    Rule Name      |  |     Rule Name      |  |     Rule Name     |
   | +--------------+  |  |  +--------------+  |  |  +--------------+ |
   | |  block_web   |<-|<-|<-|   block_web  |->|->|->|   block_web  | |
   | +--------------+  |  |  +--------------+  |  |  +--------------+ |
   |                   |  |                    |  |                   |
   |   Source IPv4     |  |    Source IPv4     |  |    Source IPv4    |
   | +--------------+  |  |  +--------------+  |  |  +--------------+ |
   | |  [10.0.0.1,  |<-|<-|<-|  [10.0.0.1,  |->|->|->|  [10.0.0.1,  | |
   | |   10.0.0.3]  |  |  |  |   10.0.0.3]  |  |  |  |   10.0.0.3]  | |
   | +--------------+  |  |  +--------------+  |  |  +--------------+ |
   |                   |  |                    |  |                   |
   |                   |  |    URL Category    |  |    URL Category   |
   |                   |  |  +--------------+  |  |  +--------------+ |
   |                   |  |  |  [harm.com,  |->|->|->|  [harm.com,  | |
   |                   |  |  | illegal.com] |  |  |  | illegal.com] | |
   |                   |  |  +--------------+  |  |  +--------------+ |
   |                   |  |                    |  |                   |
   |    Log Action     |  |     Log Action     |  |                   |
   | +--------------+  |  |  +--------------+  |  |                   |
   | |     True     |<-|<-|<-|     True     |  |  |                   |
   | +--------------+  |  |  +--------------+  |  |                   |
   +-------------------+  |                    |  |                   |
                          |     Drop Action    |  |     Drop Action   |
                          |  +--------------+  |  |  +--------------+ |
                          |  |     True     |->|->|->|     True     | |
                          |  +--------------+  |  |  +--------------+ |
                          +--------------------+  +-------------------+

                  Figure 9: Example of Policy Provisioning

   Generator searches for proper NSFs which can cover all of
   capabilities in the high-level policy.  Generator searches for target
   NSFs by comparing only NSF capabilities which is registered by Vendor
   Management System.  This process is called by "policy provisioning"
   because Generator finds proper NSFs by using only the policy.  If
   target NSFs are found by using other data which is not included in a
   user's policy, it means that the user already knows the specific
   knowledge of an NSF in the I2NSF Framework.  Figure 9 shows an
   example of policy provisioning.  In this example, log-keeper NSF and
   web-filter NSF are selected for covering capabilities in the security
   policy.  All of capabilities can be covered by two selected NSFs.

Jeong, et al.           Expires 22 February 2022               [Page 19]
Internet-Draft      I2NSF Security Policy Translation        August 2021

4.4.  CFG-based Policy Generator

   Generator makes low-level security policies for each target NSF with
   the extracted data.  We constructed Generator by using Context Free
   Grammar (CFG).  CFG is a set of production rules which can describe
   all possible strings in a given formal language(e.g., programming
   language).  The low-level policy also has its own language based on a
   YANG data model of NSF-Facing Interface.  Thus, we can construct the
   productions based on the YANG data model.  The productions that makes
   up the low-level security policy are categorized into two types,
   'Content Production' and 'Structure Production'.

4.4.1.  Content Production

   Content Production is for injecting data into low-level policies to
   be generated.  A security manager(i.e., a person (or software) to
   make productions for security policies) can construct Content
   Productions in the form of an expression as the following
   productions:

   *  [cont_prod] -> [cont_prod][cont_prod] (Where duplication is
      allowed.)

   *  [cont_prod] -> <cont_tag>[cont_data]</cont_tag>

   *  [cont_data] -> data_1 | data_2 | ... | data_n

   Square brackets mean non-terminal state.  If there are no non-
   terminal states, it means that the string is completely generated.
   When the duplication of content tag is allowed, the security manager
   adds the first production for a rule.  If there is no need to allow
   duplication, the first production can be skipped because it is an
   optional production.

   The second production is the main production for Content Production
   because it generates the tag which contains data for low-level
   policy.  Last, the third production is for injecting data into a tag
   which is generated by the second production.  If data is changed for
   an NSF, the security manager needs to change "only the third
   production" for data mapping in each NSF.

   For example, if the security manager wants to express a low-level
   policy for source IP address, Content Production can be constructed
   in the following productions:

   *  [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication.)

Jeong, et al.           Expires 22 February 2022               [Page 20]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   *  [cont_ipv4] -> <ipv4>[cont_ipv4_data]</ipv4>

   *  [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3

4.4.2.  Structure Production

   Structure Production is for grouping other tags into a hierarchy.
   The security manager can construct Structure Production in the form
   of an expression as the following production:

   *  [struct_prod] -> <struct_tag>[prod_1]...[prod_n]</struct_tag>

   Structure Production can be expressed as a single production.  The
   above production means to group other tags by the name of a tag which
   is called by 'struct_tag'. [prod_x] is a state for generating a tag
   which wants to be grouped by Structure Production. [prod_x] can be
   both Content Production and Structure Production.  For example, if
   the security manager wants to express the low-level policy for the
   I2NSF tag, which is grouping 'name' and 'rules', Structure Production
   can be constructed as the following production where [cont_name] is
   the state for Content Production and [struct_rule] is the state for
   Structure Production.

   *  [struct_i2nsf] -> <I2NSF>[cont_name][struct_rules]</I2NSF>

4.4.3.  Generator Construction

   The security manager can build a generator by combining the two
   productions which are described in Section 4.4.1 and Section 4.4.2.
   Figure 10 shows the CFG-based Generator construction of the web-
   filter NSF.  It is constructed based on the NSF-Facing Interface Data
   Model in [I-D.ietf-i2nsf-nsf-facing-interface-dm].  According to
   Figure 10, the security manager can express productions for each
   clause as in following CFG:

   1.   [cont_name] -> <rule-name>[cont_name_data]</rule-name>

   2.   [cont_name_data] -> block_web

   3.   [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication)

   4.   [cont_ipv4] -> <ipv4>[cont_ipv4_data]</ipv4>

   5.   [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3

   6.   [cont_url] -> [cont_url][cont_url] (Allow duplication)

   7.   [cont_url] -> <url>[cont_url_data]</url>

Jeong, et al.           Expires 22 February 2022               [Page 21]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   8.   [cont_url_data] -> harm.com | illegal.com

   9.   [cont_action] -> <action>[cont_action_data]</action>

   10.  [cont_action_data] -> drop

   11.  [struct_packet] -> <packet>[cont_ipv4]</packet>

   12.  [struct_payload] -> <payload>[cont_url]</payload>

   13.  [struct_cond] ->
        <condition>[struct_packet][struct_payload]</condition>

   14.  [struct_rules] -> <rules>[struct_cond][cont_action]</rules>

   15.  [struct_i2nsf] -> <I2NSF>[cont_name][struct_rules]</I2NSF>

   Then, Generator generates a low-level policy by using the above CFG.
   The low-level policy is generated by the following process:

   1.   Start: [struct_i2nsf]

   2.   Production 15: <I2NSF>[cont_name][struct_rules]</I2NSF>

   3.   Production 1: <I2NSF><rule-name>[cont_name_data]</rule-
        name>[struct_rules]</I2NSF>

   4.   Production 2: <I2NSF><rule-name>block_web</rule-
        name>[struct_rules]</I2NSF>

   5.   Production 14: <I2NSF><rule-name>block_web</rule-
        name><rules>[struct_cond][cont_action]</rules></I2NSF>

   6.   Production 13: <I2NSF><rule-name>block_web</rule-name><rules><co
        ndition>[struct_packet][struct_payload]</condition>[cont_action]
        </rules></I2NSF>

   7.   Production 11: <I2NSF><rule-name>block_web</rule-name><rules><co
        ndition><packet>[cont_ipv4]</packet>[struct_payload]</condition>
        [cont_action]</rules></I2NSF>

   8.   Production 3: <I2NSF><rule-name>block_web</rule-name><rules><con
        dition><packet>[cont_ipv4][cont_ipv4]</packet>[struct_payload]</
        condition>[cont_action]</rules></I2NSF>

Jeong, et al.           Expires 22 February 2022               [Page 22]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   9.   Production 4: <I2NSF><rule-name>block_web</rule-name><rules><con
        dition><packet><ipv4>[cont_ipv4_data]</ipv4><ipv4>[cont_ipv4_dat
        a]</ipv4></packet>[struct_payload]</condition>[cont_action]</rul
        es></I2NSF>

   10.  Production 5: <I2NSF><rule-name>block_web</rule-name><rules><con
        dition><packet><ipv4>10.0.0.1</ipv4><ipv4>10.0.0.3</ipv4></packe
        t>[struct_payload]</condition>[cont_action]</rules></I2NSF>

   11.  Production 12: <I2NSF><rule-name>block_web</rule-name><rules><co
        ndition><packet><ipv4>10.0.0.1</ipv4><ipv4>10.0.0.3</ipv4></pack
        et><payload>[cont_url]</payload></condition>[cont_action]</rules
        ></I2NSF>

   12.  Production 6: <I2NSF><rule-name>block_web</rule-name><rules><con
        dition><packet><ipv4>10.0.0.1</ipv4><ipv4>10.0.0.3</ipv4></packe
        t><payload>[cont_url][cont_url]</payload></condition>[cont_actio
        n]</rules></I2NSF>

   13.  Production 7: <I2NSF><rule-name>block_web</rule-name><rules><con
        dition><packet><ipv4>10.0.0.1</ipv4><ipv4>10.0.0.3</ipv4></packe
        t><payload><url>[cont_url_data]</url><url>[cont_url_data]</url><
        /payload></condition>[cont_action]</rules></I2NSF>

   14.  Production 8: <I2NSF><rule-name>block_web</rule-name><rules><con
        dition><packet><ipv4>10.0.0.1</ipv4><ipv4>10.0.0.3</ipv4></packe
        t><payload><url>harm.com</url><url>illegal.com</url></payload></
        condition>[cont_action]</rules></I2NSF>

   15.  Production 9: <I2NSF><rule-name>block_web</rule-name><rules><con
        dition><packet><ipv4>10.0.0.1</ipv4><ipv4>10.0.0.3</ipv4></packe
        t><payload><url>harm.com</url><url>illegal.com</url></payload></
        condition><action>[cont_action_data]</action></rules></I2NSF>

   16.  Production 10: <I2NSF><rule-name>block_web</rule-name><rules><co
        ndition><packet><ipv4>10.0.0.1</ipv4><ipv4>10.0.0.3</ipv4></pack
        et><payload><url>harm.com</url><url>illegal.com</url></payload><
        /condition><action>drop</action></rules></I2NSF>

   The last production has no non-terminal state, and the low-level
   policy is completely generated.  Figure 11 shows the generated low-
   level policy where tab characters and newline characters are added.

Jeong, et al.           Expires 22 February 2022               [Page 23]
Internet-Draft      I2NSF Security Policy Translation        August 2021

               +-----------------------------------------------------+
               | +----------+ +----------+ +----------+ +----------+ |
       Content | |   Rule   | |  Source  | |   URL    | |   Drop   | |
    Production | |   Name   | |   IPv4   | | Category | |  Action  | |
               | +-----+----+ +-----+----+ +----+-----+ +----+-----+ |
               |       |            |           |            |       |
               +--------------------+-----------+--------------------+
                       |            |           |            |
                       V            V           V            V
               +-------+------------+-----------+------------+-------+
               |       |            |           |            |       |
               |       |            V           V            |       |
               |       |      +----------+ +----------+      |       |
               |       |      |  Packet  | |  Payload |      |       |
               |       |      |  Clause  | |  Clause  |      |       |
               |       |      +-----+----+ +----+-----+      |       |
               |       |            |           |            |       |
               |       |            V           V            |       |
               |       |          +---------------+          |       |
               |       |          |   Condition   |          |       |
     Structure |       |          |    Clause     |          |       |
    Production |       |          +-------+-------+          |       |
               |       |                  |                  |       |
               |       |                  V                  V       |
               |       |                +----------------------+     |
               |       |                |     Rule Clause      |     |
               |       |                +-----------+----------+     |
               |       |                            |                |
               |       V                            V                |
               |     +-----------------------------------------+     |
               |     |               I2NSF Clause              |     |
               |     +--------------------+--------------------+     |
               |                          |                          |
               +--------------------------+--------------------------+
                                          |
                                          V
                                   Low-Level Policy

            Figure 10: Generator Construction for Web-Filter NSF

Jeong, et al.           Expires 22 February 2022               [Page 24]
Internet-Draft      I2NSF Security Policy Translation        August 2021

                 <I2NSF>
                     <rule-name>block_web</rule-name>
                     <rules>
                         <condition>
                             <packet>
                                 <ipv4>10.0.0.1</ipv4>
                                 <ipv4>10.0.0.3</ipv4>
                             </packet>
                             <payload>
                                 <url>harm.com</url>
                                 <url>illegal.com</url>
                             </payload>
                         </condition>
                         <action>drop</action>
                     </rules>
                 </I2NSF>

                   Figure 11: Example of Low-Level Policy

5.  Implementation Considerations

   The implementation considerations in this document include the
   following three: "data model auto-adaptation", "data conversion", and
   "policy provisioning".

5.1.  Data Model Auto-adaptation

   Security Controller which acts as the intermediary MUST process the
   data according to the data model of the connected interfaces.
   However, the data model can be changed flexibly depending on the
   situation, and Security Controller may adapt to the change.
   Therefore, Security Controller can be implemented for convenience so
   that the security policy translator can easily adapt to the change of
   the data model.

   The translator constructs and uses the DFA to adapt to Consumer-
   Facing Interface Data Model.  In addition, the CFG is constructed and
   used to adapt to NSF-Facing Interface Data Model.  Both the DFA and
   the CFG follow the same tree structure of YANG Data Model.

   The DFA starts at the node and expands operations by changing the
   state according to the input.  Based on the YANG Data Model, a
   container node is defined as a middle state and a leaf node is
   defined as an extractor node.  After that, if the nodes are connected
   in the same way as the hierarchical structure of the data model,
   Security Controller can automatically construct the DFA.  The DFA can
   be conveniently built by investigating the link structure using the
   stack, starting with the root node.

Jeong, et al.           Expires 22 February 2022               [Page 25]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   The CFG starts at the leaf nodes and is grouped into clauses until
   all the nodes are merged into one node.  A leaf node is defined as
   the content production, and a container node is defined as the
   structure production.  After that, if the nodes are connected in the
   same way as the hierarchy of the data model, Security Controller can
   automatically construct the CFG.  The CFG can be conveniently
   constructed by investigating the link structure using the priority
   queue data, starting with the leaf nodes.

5.2.  Data Conversion

   Security Controller requires the ability to materialize the abstract
   data in the high-level security policy and forward it to NSFs.
   Security Controller can receive endpoint information as keywords
   through the high-level security policy.  At this time, if the
   endpoint information corresponding to the keyword is mapped and the
   query is transmitted to the NSF Database, the NSF Database can be
   conveniently registered with necessary information for data
   conversion.  When a policy tries to establish a policy through the
   keyword, Security Controller searches the details corresponding to
   the keyword registered in the NSF Database and converts the keywords
   into the appropriate and specified data.

5.3.  Policy Provisioning

   This document stated that policy provisioning function is necessary
   to enable users without expert security knowledge to create policies.
   Policy provisioning is determined by the capability of the NSF.  If
   the NSF has information about the capability in the policy, the
   probability of selection increases.

   Most importantly, selected NSFs may be able to perform all
   capabilities in the security policy.  This document recommends a
   study of policy provisioning algorithms that are highly efficient and
   can satisfy all capabilities in the security policy.

6.  Features of Security Policy Translator Design

   First, by showing a visualized translator structure, the security
   manager can handle various policy changes.  Translator can be shown
   by visualizing DFA and Context-free Grammar so that the manager can
   easily understand the structure of Security Policy Translator.

Jeong, et al.           Expires 22 February 2022               [Page 26]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   Second, if I2NSF User only keeps the hierarchy of the data model,
   I2NSF User can freely create high-level policies.  In the case of
   DFA, data extraction can be performed in the same way even if the
   order of input is changed.  The design of the security policy
   translator is more flexible than the existing method that works by
   keeping the tag 's position and order exactly.

   Third, the structure of Security Policy Translator can be updated
   even while Security Policy Translator is operating.  Because Security
   Policy Translator is modularized, the translator can adapt to changes
   in the NSF capability while the I2NSF framework is running.  The
   function of changing the translator's structure can be provided
   through Registration Interface.

7.  Security Considerations

   There is no security concern in the proposed security policy
   translator as long as the I2NSF interfaces (i.e., Consumer-Facing
   Interface, NSF-Facing Interface, and Registration Interface) are
   protected by secure communication channels.

8.  IANA Considerations

   This document does not require any IANA actions.

9.  Acknowledgments

   This work was supported by Institute of Information & Communications
   Technology Planning & Evaluation (IITP) grant funded by the Ministry
   of Science and ICT (MSIT), Korea, (R-20160222-002755, Cloud based
   Security Intelligence Technology Development for the Customized
   Security Service Provisioning).  This work was supported in part by
   the IITP (2020-0-00395, Standard Development of Blockchain based
   Network Management Automation Technology).  This work was supported
   in part by the MSIT under the Information Technology Research Center
   (ITRC) support program (IITP-2021-2017-0-01633) supervised by the
   IITP.

10.  References

10.1.  Normative References

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

Jeong, et al.           Expires 22 February 2022               [Page 27]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

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

10.2.  Informative References

   [I-D.ietf-i2nsf-consumer-facing-interface-dm]
              Jeong, J. (., Chung, C., Ahn, T., Kumar, R., and S. Hares,
              "I2NSF Consumer-Facing Interface YANG Data Model", Work in
              Progress, Internet-Draft, draft-ietf-i2nsf-consumer-
              facing-interface-dm-13, 8 March 2021,
              <https://www.ietf.org/archive/id/draft-ietf-i2nsf-
              consumer-facing-interface-dm-13.txt>.

   [I-D.ietf-i2nsf-nsf-facing-interface-dm]
              Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin,
              "I2NSF Network Security Function-Facing Interface YANG
              Data Model", Work in Progress, Internet-Draft, draft-ietf-
              i2nsf-nsf-facing-interface-dm-12, 8 March 2021,
              <https://www.ietf.org/archive/id/draft-ietf-i2nsf-nsf-
              facing-interface-dm-12.txt>.

   [I-D.ietf-i2nsf-registration-interface-dm]
              Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Park,
              "I2NSF Registration Interface YANG Data Model", Work in
              Progress, Internet-Draft, draft-ietf-i2nsf-registration-
              interface-dm-10, 21 February 2021,
              <https://www.ietf.org/archive/id/draft-ietf-i2nsf-
              registration-interface-dm-10.txt>.

   [Automata] Peter, L., "Formal Languages and Automata, 6th Edition",
              January 2016.

Jeong, et al.           Expires 22 February 2022               [Page 28]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   [Zhang-Shasha]
              Zhang, K. and D. Shasha, "Simple Fast Algorithms for the
              Editing Distance Between Trees and Related Problems", SIAM
              J. Comput. https://www.researchgate.net/publication/220618
              233_Simple_Fast_Algorithms_for_the_Editing_Distance_Betwee
              n_Trees_and_Related_Problems, 1989.

   [XML]      W3C, "On Views and XML (Extensible Markup Language)", June
              1999.

   [XSLT]     W3C, "Extensible Stylesheet Language Transformations
              (XSLT) Version 1.0", November 1999.

Appendix A.  Changes from draft-yang-i2nsf-security-policy-
             translation-08

   The following changes are made from draft-yang-i2nsf-security-policy-
   translation-08:

   *  The version adds a Data Model Mapper section as Section 5.  In
      this section, the implementation considerations include the
      following three: "data model auto-adaptation", "data conversion",
      and "policy provisioning".

   *  This version describes the mapping with the updated data models of
      Consumer-Facing Interface and NSF-Facing Interface.

Authors' Addresses

   Jaehoon (Paul) Jeong
   Department of Computer Science and Engineering
   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

   Patrick Lingga
   Department of Electronic, Electrical and Computer Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon

Jeong, et al.           Expires 22 February 2022               [Page 29]
Internet-Draft      I2NSF Security Policy Translation        August 2021

   Gyeonggi-Do
   16419
   Republic of Korea

   Phone: +82 31 299 4957
   Email: patricklink@skku.edu

   Jinhyuk Yang
   Department of Electronic, Electrical and Computer Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea

   Phone: +82 10 8520 8039
   Email: jin.hyuk@skku.edu

   Chaehong Chung
   Department of Electronic, Electrical and Computer Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea

   Phone: +82 31 299 4957
   Email: darkhong@skku.edu

Jeong, et al.           Expires 22 February 2022               [Page 30]