< draft-yang-i2nsf-security-policy-translation-02.txt   draft-yang-i2nsf-security-policy-translation-03.txt >
I2NSF Working Group J. Yang I2NSF Working Group J. Yang
Internet-Draft J. Jeong Internet-Draft J. Jeong
Intended status: Standards Track J. Kim Intended status: Standards Track J. Kim
Expires: April 25, 2019 Sungkyunkwan University Expires: September 12, 2019 Sungkyunkwan University
October 22, 2018 March 11, 2019
Security Policy Translation in Interface to Network Security Functions Security Policy Translation in Interface to Network Security Functions
draft-yang-i2nsf-security-policy-translation-02 draft-yang-i2nsf-security-policy-translation-03
Abstract Abstract
This document proposes a scheme of security policy translation (i.e., This document proposes a scheme of security policy translation (i.e.,
Security Policy Translator) in Interface to Network Security Security Policy Translator) in Interface to Network Security
Functions (I2NSF) Framework. When I2NSF User delivers a high-level Functions (I2NSF) Framework. When I2NSF User delivers a high-level
security policy for a security service, Security Policy Translator in security policy for a security service, Security Policy Translator in
Security Controller translates it into a low-level security policy Security Controller translates it into a low-level security policy
for Network Security Functions (NSFs). for Network Security Functions (NSFs).
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Necessity for Policy Translator . . . . . . . . . . . . . . . 3 3. Necessity for Policy Translator . . . . . . . . . . . . . . . 3
4. Design of Policy Translator . . . . . . . . . . . . . . . . . 4 4. Design of Policy Translator . . . . . . . . . . . . . . . . . 4
4.1. Overall Structure of Policy Translator . . . . . . . . . 4 4.1. Overall Structure of Policy Translator . . . . . . . . . 4
4.2. DFA-based Data Extractor . . . . . . . . . . . . . . . . 6 4.2. DFA-based Data Extractor . . . . . . . . . . . . . . . . 6
4.2.1. Design of 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.2.2. Example Scenario for Data Extractor . . . . . . . . . 7
4.3. Data Converter . . . . . . . . . . . . . . . . . . . . . 9 4.3. Data Converter . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Role of Data Converter . . . . . . . . . . . . . . . 9 4.3.1. Role of Data Converter . . . . . . . . . . . . . . . 9
4.3.2. Data Conversion in Data Converter . . . . . . . . . . 10 4.3.2. NSF Database . . . . . . . . . . . . . . . . . . . . 10
4.3.3. Policy Provisioning . . . . . . . . . . . . . . . . . 11 4.3.3. Data Conversion in Data Converter . . . . . . . . . . 10
4.4. CFG-based Policy Generator . . . . . . . . . . . . . . . 12 4.3.4. Policy Provisioning . . . . . . . . . . . . . . . . . 12
4.4.1. Content Production . . . . . . . . . . . . . . . . . 12 4.4. CFG-based Policy Generator . . . . . . . . . . . . . . . 13
4.4.2. Structure Production . . . . . . . . . . . . . . . . 13 4.4.1. Content Production . . . . . . . . . . . . . . . . . 13
4.4.3. Generator Construction . . . . . . . . . . . . . . . 13 4.4.2. Structure Production . . . . . . . . . . . . . . . . 14
5. Features of Policy Translator Design . . . . . . . . . . . . 17 4.4.3. Generator Construction . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Implementation Considerations . . . . . . . . . . . . . . . . 18
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Data Model Auto-adaptation . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Data Conversion . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 5.3. Policy Provisioning . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 18 6. Features of Policy Translator Design . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Changes from draft-yang-i2nsf-security-policy- Appendix A. Changes from draft-yang-i2nsf-security-policy-
translation-01 . . . . . . . . . . . . . . . . . . . 20 translation-02 . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This document defines a scheme of a security policy translation in This document defines a scheme of a security policy translation in
Interface to Network Security Functions (I2NSF) Framework [RFC8329]. Interface to Network Security Functions (I2NSF) Framework [RFC8329].
First of all, this document explains the necessity of a security First of all, this document explains the necessity of a security
policy translator (shortly called policy translator) in the I2NSF policy translator (shortly called policy translator) in the I2NSF
framework. framework.
The policy translator resides in Security Controller in the I2NSF The policy translator resides in Security Controller in the I2NSF
framework and translates a high-level security policy to a low-level framework and translates a high-level security policy to a low-level
security policy for Network Security Functions (NSFs). A high-level security policy for Network Security Functions (NSFs). A high-level
policy is specified by I2NSF User in the I2NSF framework and is policy is specified by I2NSF User in the I2NSF framework and is
delivered to Security Controller via Consumer-Facing Interface delivered to Security Controller via Consumer-Facing Interface
[consumer-facing-inf]. It is translated into a low-level policy by [consumer-facing-inf-dm]. It is translated into a low-level policy
Policy Translator in Security Controller and is delivered to NSFs to by Policy Translator in Security Controller and is delivered to NSFs
execute the rules corresponding to the low-level policy via NSF- to execute the rules corresponding to the low-level policy via NSF-
Facing Interface [nsf-facing-inf]. Facing Interface [nsf-facing-inf-dm].
2. Terminology 2. Terminology
This document uses the terminology specified in [i2nsf-terminology] This document uses the terminology specified in [i2nsf-terminology]
[RFC8329]. [RFC8329].
3. Necessity for Policy Translator 3. Necessity for Policy Translator
Security Controller acts as a coordinator between I2NSF User and Security Controller acts as a coordinator between I2NSF User and
NSFs. Also, Security Controller has capability information of NSFs NSFs. Also, Security Controller has capability information of NSFs
that are registered via Registration Interface [registration-inf] by that are registered via Registration Interface [registration-inf-dm]
Developer's Management System [RFC8329]. As a coordinator, Security by Developer's Management System [RFC8329]. As a coordinator,
Controller needs to generate a low-level policy in the form of Security Controller needs to generate a low-level policy in the form
security rules intended by the high-level policy, which can be of security rules intended by the high-level policy, which can be
understood by the corresponding NSFs. understood by the corresponding NSFs.
A high-level security policy is specified by RESTCONF/YANG A high-level security policy is specified by RESTCONF/YANG
[RFC8040][RFC6020], and a low-level security policy is specified by [RFC8040][RFC6020], and a low-level security policy is specified by
NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level
security policy to the corresponding low-level security policy will security policy to the corresponding low-level security policy will
be able to rapidly elevate I2NSF in real-world deployment. A rule in 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 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 employees in a company for a security service (e.g., firewall and web
filter). Such employees may be from human resource (HR) department, filter). Such employees may be from human resource (HR) department,
skipping to change at page 3, line 46 skipping to change at page 3, line 51
o Drop packets from the IP address 10.0.0.1 and 10.0.0.3 to harm.com o Drop packets from the IP address 10.0.0.1 and 10.0.0.3 to harm.com
and illegal.com and illegal.com
The above two sentences are examples of policies for blocking The above two sentences are examples of policies for blocking
malicious websites. Both policies are for the same operation. malicious websites. Both policies are for the same operation.
However, NSF cannot understand the first policy, because the policy However, NSF cannot understand the first policy, because the policy
does not have any specified information for NSF. To set up the 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 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 and website address for an operation. It means that the first
sentence is NOT compatible for an NSF policy. Conversely, when I2NSF sentence is NOT compatible for an NSF policy. Conversely, when I2NSF
users request a security policy to the system, they never make a Users request a security policy to the system, they never make a
security policy like the second example. For generating a security security policy like the second example. For generating a security
policy like the second sentence, the user MUST know that the NSF policy like the second sentence, the user MUST know that the NSF
needs to receive the specified information, source IP address and needs to receive the specified information, source IP address and
website address. It means that the user understands the NSF website address. It means that the user understands the NSF
professionally, but there are not many professional users in a small professionally, but there are not many professional users in a small
size of company or at a residential area. In conclusion, the I2NSF 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 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 NSF will require the same policy as the second sentence with specific
information. Therefore, an advanced translation scheme of security information. Therefore, an advanced translation scheme of security
policy is REQUIRED in I2NSF. policy is REQUIRED in I2NSF.
This document proposes an approach using Automata theory [Automata] This document proposes an approach using Automata theory [Automata]
for the policy tranlation, such as Deterministic Finite Automaton for the policy tranlation, such as Deterministic Finite Automaton
(DFA) and Context-Free Grammar (CFG). Note that Automata theory is (DFA) and Context Free Grammar (CFG). Note that Automata theory is
the foundation of programming language and compiler. Thus, with this the foundation of programming language and compiler. Thus, with this
approach, I2NSF User can easily specify a high-level security policy approach, I2NSF User can easily specify a high-level security policy
that will be enforced into the corresponding NSFs with a compatibly that will be enforced into the corresponding NSFs with a compatibly
low-level security policy with the help of Policy Translator. Also, low-level security policy with the help of Policy Translator. Also,
for easy management, a modularized translator structure is proposed. for easy management, a modularized translator structure is proposed.
4. Design of Policy Translator 4. Design of Policy Translator
Common security policies are created by Extensible Markup Language Commonly used security policies are created as XML(Extensible Markup
(XML) [XML] files. A popular way to change the format of an XML file Language) [XML] files. A popular way to change the format of an XML
is to use an Extensible Stylesheet Language Transformation (XSLT) file is to use an XSLT (Extensible Stylesheet Language
[XSLT] document. XSLT is an XML-based language to transform an input Transformation) [XSLT] document. XSLT is an XML-based language to
XML file into another output XML file. However, the use of XSLT transform an input XML file into another output XML file. However,
makes it difficult to manage the policy translator and to handle the the use of XSLT makes it difficult to manage the policy translator
registration of new capabilities of NSFs. With the necessity for a and to handle the registration of new capabilities of NSFs. With the
policy translator, this document describes a policy translator based necessity for a policy translator, this document describes a policy
on Automata theory [Automata]. translator based on Automata theory.
4.1. Overall Structure of Policy Translator 4.1. Overall Structure of Policy Translator
High-Level Policy High-Level Policy
Security | Security |
Controller V Consumer-Facing Interface Controller V Consumer-Facing Interface
+------------------------+-------------------------+ +------------------------+-------------------------+
| Policy | | | Policy | |
| Translator | | | Translator | |
| +---------------------+----------------------+ | | +---------------------+----------------------+ |
| | | | | | | | | |
skipping to change at page 6, line 34 skipping to change at page 6, line 34
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| extractor 1 | | extractor 2 | ... | extractor m | | extractor 1 | | extractor 2 | ... | extractor m |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
data:1 data:2 data:m data:1 data:2 data:m
Figure 2: DFA Architecture of Data Extractor Figure 2: DFA Architecture of Data Extractor
Figure 2 shows a design for Data Extractor in the policy translator. Figure 2 shows a design for Data Extractor in the policy translator.
If a high-level policy contains data along the hierarchical structure If a high-level policy contains data along the hierarchical structure
of the standard Consumer-Facing Interface YANG data model of the standard Consumer-Facing Interface YANG data model
[consumer-facing-inf], data can be easily extracted using the state [consumer-facing-inf-dm], data can be easily extracted using the
transition machine, such as DFA. The extracted data can be processed state transition machine, such as DFA. The extracted data can be
and used by an NSF to understand it. Extractor can be constructed by processed and used by an NSF to understand it. Extractor can be
designing a DFA with the same hierarchical structure as a YANG data constructed by designing a DFA with the same hierarchical structure
model. as a YANG data model.
After constructing a DFA, Data Extractor can extract all of data in After constructing a DFA, Data Extractor can extract all of data in
the enterred high-level policy by using state transitions. Also, the the enterred high-level policy by using state transitions. Also, the
DFA can easily detect the grammar errors of the high-level policy. DFA can easily detect the grammar errors of the high-level policy.
The extracting algorithm of Data Extractor is as follows: The extracting algorithm of Data Extractor is as follows:
1. Start from the 'accepter' state. 1. Start from the 'accepter' state.
2. Read the next tag from the high-level policy. 2. Read the next tag from the high-level policy.
skipping to change at page 7, line 13 skipping to change at page 7, line 13
data, and then go back to step 2. data, and then go back to step 2.
5. If the current state is in 'middle', 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' 6. If there is no possible transition and arrived at 'accepter'
state, the policy has no grammar error. Otherwise, there is a state, the policy has no grammar error. Otherwise, there is a
grammar error, so stop the process with failure. grammar error, so stop the process with failure.
4.2.2. Example Scenario for Data Extractor 4.2.2. Example Scenario for Data Extractor
<I2NSF> <I2NSF>
<name>block_web</name> <name>block_web</name>
<cond> <cond>
<src>Son's_PC</src> <src>Son's_PC</src>
<dest>malicious</dest> <dest>malicious_websites</dest>
</cond> </cond>
<action>block<action> <action>block<action>
</I2NSF> </I2NSF>
Figure 3: The Example of High-level Policy Figure 3: The Example of High-level Policy
+----------+ +----------+
| accepter | | accepter |
+----------+ +----------+
| ^ | ^
<I2NSF>| |</I2NSF> <I2NSF>| |</I2NSF>
v | v |
+------------------------------------------------------+ +------------------------------------------------------+
skipping to change at page 7, line 46 skipping to change at page 7, line 46
+-------------+ +----------------------+ +-------------+ +-------------+ +----------------------+ +-------------+
| extractor 1 | | middle 2 | | extractor 4 | | extractor 1 | | middle 2 | | extractor 4 |
+-------------+ +----------------------+ +-------------+ +-------------+ +----------------------+ +-------------+
block_web | ^ | ^ block block_web | ^ | ^ block
<src>| |</src> <dest>| |</dest> <src>| |</src> <dest>| |</dest>
v | v | v | v |
+-------------+ +-------------+ +-------------+ +-------------+
| extractor 2 | | extractor 3 | | extractor 2 | | extractor 3 |
+-------------+ +-------------+ +-------------+ +-------------+
Son's_PC malicious Son's_PC malicious
_websites
Figure 4: The Example of Data Extractor Figure 4: The Example of Data Extractor
To explain the Data Extractor process by referring to an example To explain the Data Extractor process by referring to an example
scenario, assume that Security Controller received a high-level scenario, assume that Security Controller received a high-level
policy for a web-filtering as shown in Figure 3. Then we can 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 construct DFA-based Data Extractor by using the design as shown in
Figure 2. Figure 4 shows the architecture of Data Extractor that is Figure 2. Figure 4 shows the architecture of Data Extractor that is
based on the architection in Figure 2 along with the input high-level based on the architection in Figure 2 along with the input high-level
policy in Figure 3. Data Extractor can automatically extract all of policy in Figure 3. Data Extractor can automatically extract all of
skipping to change at page 8, line 40 skipping to change at page 8, line 41
8. The current state is an 'extractor' state. Extract the data of 8. The current state is an 'extractor' state. Extract the data of
'src' field called 'Son's_PC'. 'src' field called 'Son's_PC'.
9. Read the fourth closing tag called '</src>', and go back to the 9. Read the fourth closing tag called '</src>', and go back to the
'middle 2' state. 'middle 2' state.
10. Read the fifth opening tag called '<dest>', and transit to the 10. Read the fifth opening tag called '<dest>', and transit to the
'extractor 3' state. 'extractor 3' state.
11. The current state is an 'extractor' state. Extract the data of 11. The current state is an 'extractor' state. Extract the data of
'dest' field called 'malicious'. 'dest' field called 'malicious_websites'.
12. Read the fifth closing tag called '</dest>', and go back to the 12. Read the fifth closing tag called '</dest>', and go back to the
'middle 2' state. 'middle 2' state.
13. Read the third closing tag called '</cond>', and go back to the 13. Read the third closing tag called '</cond>', and go back to the
'middle 1' state. 'middle 1' state.
14. Read the sixth opening tag called '<action>', and transit to the 14. Read the sixth opening tag called '<action>', and transit to the
'extractor 4' state. 'extractor 4' state.
skipping to change at page 9, line 51 skipping to change at page 9, line 51
target NSFs with only the data (e.g., subject and object for a target NSFs with only the data (e.g., subject and object for a
security policy) of the high-level policy by comparing the extracted security policy) of the high-level policy by comparing the extracted
data with all capabilities of each NSF. This search process for data with all capabilities of each NSF. This search process for
appropriate NSFs is called by policy provisioning, and it eliminates appropriate NSFs is called by policy provisioning, and it eliminates
the need for I2NSF User to specify the target NSFs explicitly in a the need for I2NSF User to specify the target NSFs explicitly in a
high-level security policy. high-level security policy.
Data Converter selects target NSFs and converts the extracted data Data Converter selects target NSFs and converts the extracted data
into the capabilities of selected NSFs. If Security Controller uses into the capabilities of selected NSFs. If Security Controller uses
this data convertor, it can provide the policy provisioning function this data convertor, it can provide the policy provisioning function
to the I2NSF User automatically. Thus, the translator design to I2NSF User automatically. Thus, the translator design provides
provides big benefits to the I2NSF Framework. big benefits to the I2NSF Framework.
4.3.2. Data Conversion in Data Converter 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
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.
4.3.3. Data Conversion in Data Converter
High-level Low-level High-level Low-level
Policy Data Policy Data Policy Data Policy Data
+---------------+ +------------------------------+ +---------------+ +------------------------------+
| Rule Name | | Rule Name | | Rule Name | | Rule Name |
| +-----------+ | The Same value | +-------------------------+ | | +-----------+ | The Same value | +-------------------------+ |
| | block_web |-|------------------->|->| block_web | | | | block_web |-|------------------->|->| block_web | |
| +-----------+ | | +-------------------------+ | | +-----------+ | | +-------------------------+ |
| | | | | | | |
| Source | Conversion into | Source IPv4 | | Source | Conversion into | Source IPv4 |
| +-----------+ | User's IP address | +-------------------------+ | | +-----------+ | User's IP address | +-------------------------+ |
| | Son's_PC |-|------------------->|->| [10.0.0.1, 10.0.0.3] | | | | Son's_PC |-|------------------->|->| [10.0.0.1, 10.0.0.3] | |
| +-----------+ | | +-------------------------+ | | +-----------+ | | +-------------------------+ |
| | | | | | | |
| Destination | Conversion into | URL Category | | Destination | Conversion into | URL Category |
| +-----------+ | malicious websites | +-------------------------+ | | +-----------+ | malicious websites | +-------------------------+ |
| | malicious |-|------------------->|->| [harm.com, illegal.com] | | | | malicious |-|------------------->|->| [harm.com, | |
| | _websites | | | | illegal.com] | |
| +-----------+ | | +-------------------------+ | | +-----------+ | | +-------------------------+ |
| | | | | | | |
| Action | Conversion into | Log Action Drop Action | | Action | Conversion into | Log Action Drop Action |
| +-----------+ | NSF Capability | +----------+ +----------+ | | +-----------+ | NSF Capability | +----------+ +----------+ |
| | block |-|------------------->|->| True | | True | | | | block |-|------------------->|->| True | | True | |
| +-----------+ | | +----------+ +----------+ | | +-----------+ | | +----------+ +----------+ |
+---------------+ +------------------------------+ +---------------+ +------------------------------+
Figure 5: Example of Data Conversion Figure 5: Example of Data Conversion
skipping to change at page 11, line 5 skipping to change at page 12, line 5
o 'Source' field SHOULD be converted into a list of target IPv4 o 'Source' field SHOULD be converted into a list of target IPv4
addresses. addresses.
o 'Destination' field SHOULD be converted into a URL category list o 'Destination' field SHOULD be converted into a URL category list
of malicious websites. of malicious websites.
o 'Action' field SHOULD be converted into the corresponding o 'Action' field SHOULD be converted into the corresponding
action(s) in NSF capabilities. action(s) in NSF capabilities.
4.3.3. Policy Provisioning 4.3.4. Policy Provisioning
Log-keeper Low-level Web-filter Log-keeper Low-level Web-filter
NSF Policy Data NSF NSF Policy Data NSF
+-------------------+ +--------------------+ +-------------------+ +-------------------+ +--------------------+ +-------------------+
| Rule Name | | Rule Name | | Rule Name | | Rule Name | | Rule Name | | Rule Name |
| +--------------+ | | +--------------+ | | +--------------+ | | +--------------+ | | +--------------+ | | +--------------+ |
| | block_web |<-|<-|<-| block_web |->|->|->| block_web | | | | block_web |<-|<-|<-| block_web |->|->|->| block_web | |
| +--------------+ | | +--------------+ | | +--------------+ | | +--------------+ | | +--------------+ | | +--------------+ |
| | | | | | | | | | | |
| Source IPv4 | | Source IPv4 | | Source IPv4 | | Source IPv4 | | Source IPv4 | | Source IPv4 |
skipping to change at page 12, line 8 skipping to change at page 13, line 8
target NSFs are found by using other data which is not included in a 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 user's policy, it means that the user already knows the specific
knowledge of an NSF in the I2NSF Framework. Figure 6 shows an knowledge of an NSF in the I2NSF Framework. Figure 6 shows an
example of policy provisioning. In this example, log-keeper NSF and example of policy provisioning. In this example, log-keeper NSF and
web-filter NSF are selected for covering capabilities in the security web-filter NSF are selected for covering capabilities in the security
policy. All of capabilities can be covered by two selected NSFs. policy. All of capabilities can be covered by two selected NSFs.
4.4. CFG-based Policy Generator 4.4. CFG-based Policy Generator
Generator makes low-level security policies for each target NSF with Generator makes low-level security policies for each target NSF with
the extracted data. We constructed Generator by using a Context-Free the extracted data. We constructed Generator by using Context Free
Grammar called CFG. CFG is a set of production rules which can Grammar (CFG). CFG is a set of production rules which can describe
describe all possible strings in a given formal language(e.g., all possible strings in a given formal language(e.g., programming
programming language). The low-level policy also has its own language). The low-level policy also has its own language based on a
language based on a YANG data model of NSF-Facing Interface. Thus, YANG data model of NSF-Facing Interface. Thus, we can construct the
we can construct the productions based on the YANG data model. The productions based on the YANG data model. The productions that makes
productions that makes up the low-level security policy are up the low-level security policy are categorized into two types,
categorized into two types, 'Content Production' and 'Structure 'Content Production' and 'Structure Production'.
Production'.
4.4.1. Content Production 4.4.1. Content Production
Content Production is for injecting data into low-level policies to Content Production is for injecting data into low-level policies to
be generated. A security manager(i.e., a person (or software) to be generated. A security manager(i.e., a person (or software) to
make productions for security policies) can construct Content make productions for security policies) can construct Content
Productions in the form of an expression as the following Productions in the form of an expression as the following
productions: productions:
o [cont_prod] -> [cont_prod][cont_prod] (Where duplication is o [cont_prod] -> [cont_prod][cont_prod] (Where duplication is
skipping to change at page 13, line 4 skipping to change at page 13, line 51
policy. Last, the third production is for injecting data into a tag policy. Last, the third production is for injecting data into a tag
which is generated by the second production. If data is changed for which is generated by the second production. If data is changed for
an NSF, the security manager needs to change "only the third an NSF, the security manager needs to change "only the third
production" for data mapping in each NSF. production" for data mapping in each NSF.
For example, if the security manager wants to express a low-level For example, if the security manager wants to express a low-level
policy for source IP address, Content Production can be constructed policy for source IP address, Content Production can be constructed
in the following productions: in the following productions:
o [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication.) o [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication.)
o [cont_ipv4] -> <ipv4>[cont_ipv4_data]</ipv4>
o [cont_ipv4] -> <ipv4>[cont_ipv4_data]</ipv4>
o [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 o [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3
4.4.2. Structure Production 4.4.2. Structure Production
Structure Production is for grouping other tags into a hierarchy. Structure Production is for grouping other tags into a hierarchy.
The security manager can construct Structure Production in the form The security manager can construct Structure Production in the form
of an expression as the following production: of an expression as the following production:
o [struct_prod] -> <struct_tag>[prod_1]...[prod_n]</struct_tag> o [struct_prod] -> <struct_tag>[prod_1]...[prod_n]</struct_tag>
skipping to change at page 13, line 35 skipping to change at page 14, line 33
Structure Production. Structure Production.
o [struct_i2nsf] -> <I2NSF>[cont_name][struct_rules]</I2NSF> o [struct_i2nsf] -> <I2NSF>[cont_name][struct_rules]</I2NSF>
4.4.3. Generator Construction 4.4.3. Generator Construction
The security manager can build a generator by combining the two 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. productions which are described in Section 4.4.1 and Section 4.4.2.
Figure 7 shows the CFG-based Generator construction of the web-filter Figure 7 shows the CFG-based Generator construction of the web-filter
NSF. It is constructed based on the NSF-Facing Interface Data Model NSF. It is constructed based on the NSF-Facing Interface Data Model
in [nsf-facing-inf]. According to Figure 7, the security manager can in [nsf-facing-inf-dm]. According to Figure 7, the security manager
express productions for each clause as in following CFG: can express productions for each clause as in following CFG:
1. [cont_name] -> <rule-name>[cont_name_data]</rule-name> 1. [cont_name] -> <rule-name>[cont_name_data]</rule-name>
2. [cont_name_data] -> block_web 2. [cont_name_data] -> block_web
3. [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication) 3. [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication)
4. [cont_ipv4] -> <ipv4>[cont_ipv4_data]</ipv4> 4. [cont_ipv4] -> <ipv4>[cont_ipv4_data]</ipv4>
5. [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 5. [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3
6. [cont_url] -> [cont_url][cont_url] (Allow duplication) 6. [cont_url] -> [cont_url][cont_url] (Allow duplication)
7. [cont_url] -> <url>[cont_url_data]</url> 7. [cont_url] -> <url>[cont_url_data]</url>
8. [cont_url_data] -> harm.com | illegal.com
8. [cont_url_data] -> harm.com | illegal.com
9. [cont_action] -> <action>[cont_action_data]</action> 9. [cont_action] -> <action>[cont_action_data]</action>
10. [cont_action_data] -> drop 10. [cont_action_data] -> drop
11. [struct_packet] -> <packet>[cont_ipv4]</packet> 11. [struct_packet] -> <packet>[cont_ipv4]</packet>
12. [struct_payload] -> <payload>[cont_url]</payload> 12. [struct_payload] -> <payload>[cont_url]</payload>
13. [struct_cond] -> 13. [struct_cond] ->
<condition>[struct_packet][struct_payload]</condition> <condition>[struct_packet][struct_payload]</condition>
skipping to change at page 17, line 23 skipping to change at page 18, line 23
<url>harm.com</url> <url>harm.com</url>
<url>illegal.com</url> <url>illegal.com</url>
</payload> </payload>
</condition> </condition>
<action>drop</action> <action>drop</action>
</rules> </rules>
</I2NSF> </I2NSF>
Figure 8: Example of Low-Level Policy Figure 8: Example of Low-Level Policy
5. Features of Policy Translator Design 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 a 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.
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 performe 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 Policy Translator Design
First, by showing a visualized translator structure, the security First, by showing a visualized translator structure, the security
manager can handle various policy changes. Translator can be shown manager can handle various policy changes. Translator can be shown
by visualizing DFA and Context-Free Grammar so that the manager can by visualizing DFA and Context-free Grammar so that the manager can
easily understand the structure of Policy Translator. easily understand the structure of Policy Translator.
Second, if I2NSF User only keeps the hierarchy of the data model, Second, if I2NSF User only keeps the hierarchy of the data model,
I2NSF User can freely create high-level policies. In the case of 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 DFA, data extraction can be performed in the same way even if the
order of input is changed. The design of the policy translator is order of input is changed. The design of the policy translator is
more flexible than the existing method that works by keeping the tag more flexible than the existing method that works by keeping the tag
's position and order exactly. 's position and order exactly.
Third, the structure of Policy Translator can be updated even while Third, the structure of Policy Translator can be updated even while
Policy Translator is operating. Because Policy Translator is Policy Translator is operating. Because Policy Translator is
modularized, the translator can adapt to changes in the NSF modularized, the translator can adapt to changes in the NSF
capability while the I2NSF framework is running. The function of capability while the I2NSF framework is running. The function of
changing the translator's structure can be provided through changing the translator's structure can be provided through
Registration Interface. Registration Interface.
6. Security Considerations 7. Security Considerations
There is no security concern in a security policy translator proposed There is no security concern in the proposed security policy
in this document as long as the I2NSF interfaces (i.e., Consumer- translator as long as the I2NSF interfaces (i.e., Consumer-Facing
Facing Interface, NSF-Facing Interface, and Registration Interface) Interface, NSF-Facing Interface, and Registration Interface) are
are protected by secure communication channels. protected by secure communication channels.
7. Acknowledgments 8. Acknowledgments
This work was supported by Institute for Information & communications This work was supported by Institute for Information & communications
Technology Promotion (IITP) grant funded by the Korea MSIT (Ministry Technology Promotion (IITP) grant funded by the Korea MSIT (Ministry
of Science and ICT) (R-20160222-002755, Cloud based Security of Science and ICT) (R-20160222-002755, Cloud based Security
Intelligence Technology Development for the Customized Security Intelligence Technology Development for the Customized Security
Service Provisioning). Service Provisioning).
This work was supported in part by the MSIT under the ITRC This work was supported in part by the MSIT under the ITRC
(Information Technology Research Center) support program (IITP- (Information Technology Research Center) support program (IITP-
2018-2017-0-01633) supervised by the IITP. 2018-2017-0-01633) supervised by the IITP.
8. References 9. References
8.1. Normative References 9.1. Normative References
[Automata] [Automata]
Peter, L., "Formal Languages and Automata, 6th Edition", Peter, L., "Formal Languages and Automata, 6th Edition",
January 2016. January 2016.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
skipping to change at page 18, line 43 skipping to change at page 21, line 12
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, January 2017. Protocol", RFC 8040, January 2017.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, February 2018. Functions", RFC 8329, February 2018.
[XML] W3C, "On Views and XML (Extensible Markup Language)", June [XML] W3C, "On Views and XML (Extensible Markup Language)", June
1999. 1999.
8.2. Informative References 9.2. Informative References
[consumer-facing-inf] [consumer-facing-inf-dm]
Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares,
"I2NSF Consumer-Facing Interface YANG Data Model", draft- "I2NSF Consumer-Facing Interface YANG Data Model", draft-
ietf-i2nsf-consumer-facing-interface-dm-01 (work in ietf-i2nsf-consumer-facing-interface-dm-03 (work in
progress), July 2018. progress), March 2019.
[i2nsf-terminology] [i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF) Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-06 (work in Terminology", draft-ietf-i2nsf-terminology-07 (work in
progress), July 2018. progress), July 2019.
[nsf-facing-inf] [nsf-facing-inf-dm]
Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin,
"I2NSF Network Security Function-Facing Interface YANG "I2NSF Network Security Function-Facing Interface YANG
Data Model", draft-ietf-i2nsf-nsf-facing-interface-data- Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-03
model-01 (work in progress), July 2018. (work in progress), March 2019.
[registration-inf] [registration-inf-dm]
Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF
Registration Interface YANG Data Model", draft-ietf-i2nsf- Registration Interface YANG Data Model", draft-ietf-i2nsf-
registration-dm-00 (work in progress), October 2018. registration-interface-dm-02 (work in progress), March
2019.
[XSLT] W3C, "Extensible Stylesheet Language Transformations [XSLT] W3C, "Extensible Stylesheet Language Transformations
(XSLT) Version 1.0", November 1999. (XSLT) Version 1.0", November 1999.
Appendix A. Changes from draft-yang-i2nsf-security-policy- Appendix A. Changes from draft-yang-i2nsf-security-policy-
translation-01 translation-02
The following changes are made from draft-yang-i2nsf-security-policy- The following changes are made from draft-yang-i2nsf-security-policy-
translation-01: translation-02:
o In Section 3, an example is added to emphasis the necessity of a
security policy translator. Also, the citation for Automata
theory is added.
o In Section 3 and Section 4, some grammatical errors are corrected.
o In Figure 1, NSF DB component is added.
o In Section 4.2, an extraction scenario is added for clearer
explanation.
o In Section 4.3, an example of data conversion is added for clearer
explanation. Also, the detailed description and the schematic
diagram of policy provisioning is added.
o In Figure 5, the expression for each conversion is changed.
o In Section 4.4, an example of CFG is added for clearer
explanation. Also, the detailed description and the schematic
diagram of CFG-based Generator is added.
o Section 6 is added for describing "Security Considerations". o Section 4.3.2 is added for describing 'NSF Database'. This
section reinforces the ambiguous description of the NSF Database.
o The References section is divided into two subsections, such as, o Section 5 is added for describing 'Implementation Considerations'.
Normative References and Informative References. Also, the This section provides guidelines for a convenient implementation
references for Automata theory and XML (Extensible Markup Langage) of security policy translator.
are added to Normative References. In addition, the reference of
XSLT (Extensible Stylesheet Language Transformations) is added to
Informative References.
Authors' Addresses Authors' Addresses
Jinhyuk Yang Jinhyuk Yang
Department of Computer Engineering Department of Computer Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
 End of changes. 46 change blocks. 
122 lines changed or deleted 199 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/