draft-ietf-i2nsf-registration-interface-dm-04.txt   draft-ietf-i2nsf-registration-interface-dm-05.txt 
I2NSF Working Group S. Hyun I2NSF Working Group S. Hyun
Internet-Draft Chosun University Internet-Draft Chosun University
Intended status: Standards Track J. Jeong Intended status: Standards Track J. Jeong
Expires: December 14, 2019 T. Roh Expires: January 25, 2020 T. Roh
S. Wi S. Wi
Sungkyunkwan University Sungkyunkwan University
J. Park J. Park
ETRI ETRI
June 12, 2019 July 24, 2019
I2NSF Registration Interface YANG Data Model I2NSF Registration Interface YANG Data Model
draft-ietf-i2nsf-registration-interface-dm-04 draft-ietf-i2nsf-registration-interface-dm-05
Abstract Abstract
This document defines an information model and a YANG data model for This document defines an information model and a YANG data model for
Registration Interface between Security Controller and Developer's Registration Interface between Security Controller and Developer's
Management System (DMS) in the Interface to Network Security Management System (DMS) in the Interface to Network Security
Functions (I2NSF) framework to register Network Security Functions Functions (I2NSF) framework to register Network Security Functions
(NSF) of the DMS into the Security Controller. The objective of (NSF) of the DMS into the Security Controller. The objective of
these information and data models is to support NSF capability these information and data models is to support NSF capability
registration and query via I2NSF Registration Interface. registration and query via I2NSF Registration Interface.
Editorial Note (To be removed by RFC Editor)
Please update these statements within the document with the RFC
number to be assigned to this document:
"This version of this YANG module is part of RFC XXXX;"
"RFC XXXX: I2NSF Registration Interface YANG Data Model"
"reference: RFC XXXX"
Please update the "revision" date of the YANG module.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 14, 2019. This Internet-Draft will expire on January 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 33 skipping to change at page 2, line 18
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Information Model . . . . . . . . . . . . . . . . . . . . . . 5 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 4
5.1. NSF Capability Registration . . . . . . . . . . . . . . . 5 5.1. NSF Capability Registration . . . . . . . . . . . . . . . 5
5.1.1. NSF Capability Information . . . . . . . . . . . . . 6 5.1.1. NSF Capability Information . . . . . . . . . . . . . 6
5.1.2. NSF Access Information . . . . . . . . . . . . . . . 8 5.1.2. NSF Access Information . . . . . . . . . . . . . . . 8
5.2. NSF Capability Query . . . . . . . . . . . . . . . . . . 8 5.2. NSF Capability Query . . . . . . . . . . . . . . . . . . 8
6. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 8 6.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 8
6.1.1. Definition of Symbols in Tree Diagrams . . . . . . . 9 6.1.1. Definition of Symbols in Tree Diagrams . . . . . . . 9
6.1.2. I2NSF Registration Interface . . . . . . . . . . . . 9 6.1.2. I2NSF Registration Interface . . . . . . . . . . . . 9
6.1.3. NSF Capability Information . . . . . . . . . . . . . 11 6.1.3. NSF Capability Information . . . . . . . . . . . . . 11
6.1.4. NSF Access Information . . . . . . . . . . . . . . . 11 6.1.4. NSF Access Information . . . . . . . . . . . . . . . 12
6.2. YANG Data Modules . . . . . . . . . . . . . . . . . . . . 12 6.2. YANG Data Modules . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. XML Example of Registration Interface Data Model . . 20 Appendix A. XML Example of Registration Interface Data Model . . 22
A.1. Example 1: Registration for Capabilities of General A.1. Example 1: Registration for Capabilities of General
Firewall . . . . . . . . . . . . . . . . . . . . . . . . 20 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 22
A.2. Example 2: Registration for Capabilities of Time based A.2. Example 2: Registration for Capabilities of Time based
Firewall . . . . . . . . . . . . . . . . . . . . . . . . 21 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 23
A.3. Example 3: Registration for Capabilities of Web Filter . 23 A.3. Example 3: Registration for Capabilities of Web Filter . 25
A.4. Example 4: Registration for Capabilities of VoIP/VoLTE A.4. Example 4: Registration for Capabilities of VoIP/VoLTE
Filter . . . . . . . . . . . . . . . . . . . . . . . . . 25 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.5. Example 5: Registration for Capabilities of HTTP and A.5. Example 5: Registration for Capabilities of HTTP and
HTTPS Flood Mitigation . . . . . . . . . . . . . . . . . 26 HTTPS Flood Mitigation . . . . . . . . . . . . . . . . . 28
A.6. Example 6: Query for Capabilities of Time based Firewall 28 A.6. Example 6: Query for Capabilities of Time based Firewall 30
Appendix B. NSF Lifecycle Managmenet in NFV Environments . . . . 30 Appendix B. NSF Lifecycle Managmenet in NFV Environments . . . . 32
Appendix C. Changes from draft-ietf-i2nsf-registration- Appendix C. Changes from draft-ietf-i2nsf-registration-
interface-dm-03 . . . . . . . . . . . . . . . . . . 30 interface-dm-04 . . . . . . . . . . . . . . . . . . 32
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 30 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 32
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 30 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
A number of Network Security Functions (NSF) may exist in the A number of Network Security Functions (NSF) may exist in the
Interface to Network Security Functions (I2NSF) framework [RFC8329]. Interface to Network Security Functions (I2NSF) framework [RFC8329].
Since each of these NSFs likely has different security capabilities Since each of these NSFs likely has different security capabilities
from each other, it is important to register the security from each other, it is important to register the security
capabilities of the NSF into the security controller. In addition, capabilities of the NSF into the security controller. In addition,
it is required to search NSFs of some required security capabilities it is required to search NSFs of some required security capabilities
on demand. As an example, if additional security capabilities are on demand. As an example, if additional security capabilities are
skipping to change at page 3, line 45 skipping to change at page 3, line 30
Interface [RFC8329] between the security controller and the Interface [RFC8329] between the security controller and the
developer's management system (DMS) to support NSF capability developer's management system (DMS) to support NSF capability
registration and query via the registration interface. It also registration and query via the registration interface. It also
describes the operations which should be performed by the security describes the operations which should be performed by the security
controller and the DMS via the Registration Interface using the controller and the DMS via the Registration Interface using the
defined model. defined model.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] [RFC8174] when, and only when, they appear in all capitals,
as shown here.
3. Terminology 3. Terminology
This document uses the following terms defined in This document uses the following terms defined in
[i2nsf-terminology], [capability-dm], [RFC8329], [i2nsf-terminology], [capability-dm], [RFC8329],
[supa-policy-data-model], and [supa-policy-info-model] [supa-policy-data-model], and [supa-policy-info-model]
o Network Security Function (NSF): A function that is responsible o Network Security Function (NSF): A function that is responsible
for specific treatment of received packets. A Network Security for specific treatment of received packets. A Network Security
Function can act at various layers of a protocol stack (e.g., at Function can act at various layers of a protocol stack (e.g., at
the network layer or other OSI layers). Sample Network Security the network layer or other OSI layers). Sample Network Security
Service Functions are as follows: Firewall, Intrusion Prevention/ Service Functions are as follows: Firewall, Intrusion Prevention/
Detection System (IPS/IDS), Deep Packet Inspection (DPI), Detection System (IPS/IDS), Deep Packet Inspection (DPI),
Application Visibility and Control (AVC), network virus and Application Visibility and Control (AVC), network virus and
malware scanning, sandbox, Data Loss Prevention (DLP), Distributed malware scanning, sandbox, Data Loss Prevention (DLP), Distributed
Denial of Service (DDoS) mitigation and TLS proxy. Denial of Service (DDoS) mitigation and TLS proxy.
skipping to change at page 4, line 25 skipping to change at page 4, line 13
interest to an environment in a form that is dependent on data interest to an environment in a form that is dependent on data
repository, data definition language, query language, repository, data definition language, query language,
implementation language, and protocol. [supa-policy-info-model] implementation language, and protocol. [supa-policy-info-model]
o Information Model: An information model is a representation of o Information Model: An information model is a representation of
concepts of interest to an environment in a form that is concepts of interest to an environment in a form that is
independent of data repository, data definition language, query independent of data repository, data definition language, query
language, implementation language, and protocol. language, implementation language, and protocol.
[supa-policy-info-model] [supa-policy-info-model]
o YANG: This document follows the guidelines of [RFC6087], uses the o YANG: This document follows the guidelines of [RFC8407], uses the
common YANG types defined in [RFC6991], and adopts the Network common YANG types defined in [RFC6991], and adopts the Network
Management Datastore Architecture (NMDA). The meaning of the Management Datastore Architecture (NMDA). The meaning of the
symbols in tree diagrams is defined in [RFC8340]. symbols in tree diagrams is defined in [RFC8340].
4. Objectives 4. Objectives
o Registering NSFs to I2NSF framework: Developer's Management System o Registering NSFs to I2NSF framework: Developer's Management System
(DMS) in I2NSF framework is typically run by an NSF vendor, and (DMS) in I2NSF framework is typically run by an NSF vendor, and
uses Registration Interface to provide NSFs developed by the NSF uses Registration Interface to provide NSFs developed by the NSF
vendor to Security Controller. DMS registers NSFs and their vendor to Security Controller. DMS registers NSFs and their
capabilities to I2NSF framework through Registration Interface. capabilities to I2NSF framework through Registration Interface.
For the registered NSFs, Security Controller maintains a catalog For the registered NSFs, Security Controller maintains a catalog
of the capabilities of those NSFs. of the capabilities of those NSFs.
o Updating the capabilities of registered NSFs: After an NSF is o Updating the capabilities of registered NSFs: After an NSF is
registered into Security Controller, some modifications on the registered into Security Controller, some modifications on the
capability of the NSF may be required later. In this case, DMS capability of the NSF may be required later. In this case, DMS
uses Registration Interface to update the capability of the NSF, uses Registration Interface to update the capability of the NSF,
and this update should be reflected on the catalog of NSFs. and this update should be reflected on the catalog of NSFs.
o Querying DMS about some required capabilities: Security Controller o Querying DMS about some required capabilities: In cases that some
may need some additional capabilities to serve the security security capabilities are required to serve the security service
service request from an I2NSF user, but none of the registered request from an I2NSF user, Security Controller searches through
NSFs has the required capabilities. In this case, Security the registered NSFs to find ones that can provide the required
Controller may query DMS about NSF(s) that can provide the capabilities. But Security Controller might fail to find any NSFs
required capabilities via Registration Interface. having the required capabilities among the registered NSFs. In
this case, Security Controller need to request DMS for additional
NSF(s) that can provide the required security capabilities via
Registration Interface.
5. Information Model 5. Information Model
The I2NSF registration interface is used by Security Controller and The I2NSF registration interface is used by Security Controller and
Developer's Management System (DMS) in I2NSF framework. The Developer's Management System (DMS) in I2NSF framework. The
following summarizes the operations done through the registration following summarizes the operations done through the registration
interface: interface:
1) DMS registers NSFs and their capabilities to Security Controller 1) DMS registers NSFs and their capabilities to Security Controller
via the registration interface. DMS also uses the registration via the registration interface. DMS also uses the registration
skipping to change at page 6, line 28 skipping to change at page 6, line 28
Figure 2: NSF Capability Registration Sub-Model Figure 2: NSF Capability Registration Sub-Model
5.1.1. NSF Capability Information 5.1.1. NSF Capability Information
NSF Capability Information basically describes the security NSF Capability Information basically describes the security
capabilities of an NSF. In Figure 3, we show capability objects of capabilities of an NSF. In Figure 3, we show capability objects of
an NSF. Following the information model of NSF capabilities defiend an NSF. Following the information model of NSF capabilities defiend
in [capability-dm], we share the same I2NSF security capabilities: in [capability-dm], we share the same I2NSF security capabilities:
Time Capabilities, Event Capabilities, Condition Capabilities, Action Time Capabilities, Event Capabilities, Condition Capabilities, Action
Capabilities, Resolution Strategy Capabilities, Default Action Capabilities, Resolution Strategy Capabilities, Default Action
Capabilities, and IPsec Method. Also, NSF Capability Information Capabilities, and IPsec Method [i2nsf-ipsec]. Also, NSF Capability
additionally contains the performance capabilities of an NSF as shown Information additionally contains the performance capabilities of an
in Figure 3. NSF as shown in Figure 3.
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
| NSF Capability | | NSF Capability |
| Information | | Information |
+-+-+-+-^-+-+-+-+-+ +-+-+-+-^-+-+-+-+-+
| |
| |
+----------------------+----------------------+ +----------------------+----------------------+
| | | |
| | | |
skipping to change at page 8, line 25 skipping to change at page 8, line 25
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
Figure 4: Performance Capability Overview Figure 4: Performance Capability Overview
5.1.2. NSF Access Information 5.1.2. NSF Access Information
NSF Access Information contains the followings that are required to NSF Access Information contains the followings that are required to
communicate with an NSF: IPv4 address, IPv6 address, port number, and communicate with an NSF: IPv4 address, IPv6 address, port number, and
supported transport protocol(s) (e.g., Virtual Extensible LAN (VXLAN) supported transport protocol(s) (e.g., Virtual Extensible LAN (VXLAN)
[RFC 7348], Generic Protocol Extension for VXLAN (VXLAN-GPE) [RFC 7348], Generic Protocol Extension for VXLAN (VXLAN-GPE)
[draft-ietf-nvo3-vxlan-gpe], Generic Route Encapsulation (GRE), [nvo3-vxlan-gpe], Generic Route Encapsulation (GRE), Ethernet etc.).
Ethernet etc.). In this document, NSF Access Information is used to In this document, NSF Access Information is used to identify a
identify a specific NSF instance (i.e. NSF Access Information is the specific NSF instance (i.e. NSF Access Information is the
signature(unique identifier) of an NSF instance in the overall signature(unique identifier) of an NSF instance in the overall
system). system).
5.2. NSF Capability Query 5.2. NSF Capability Query
Security Controller may require some additional capabilities to serve Security Controller may require some additional capabilities to serve
the security service request from an I2NSF user, but none of the the security service request from an I2NSF user, but none of the
registered NSFs has the required capabilities. In this case, registered NSFs has the required capabilities. In this case,
Security Controller makes a description of the required capabilities Security Controller makes a description of the required capabilities
by using the NSF capability information sub-model in Section 5.1.1, by using the NSF capability information sub-model in Section 5.1.1,
skipping to change at page 9, line 35 skipping to change at page 9, line 35
6.1.2. I2NSF Registration Interface 6.1.2. I2NSF Registration Interface
module : ietf-i2nsf-reg-interface module : ietf-i2nsf-reg-interface
+--rw nsf-capability-registration +--rw nsf-capability-registration
| uses i2nsf-nsf-registrations | uses i2nsf-nsf-registrations
rpcs : rpcs :
+---x nsf-capability-query +---x nsf-capability-query
| uses i2nsf-nsf-capability-query | uses i2nsf-nsf-capability-query
Figure 5: YANG tree of I2NSF Registration Interface Figure 5: YANG Tree of I2NSF Registration Interface
The I2NSF registration interface is used for the following purposes. The I2NSF registration interface is used for the following purposes.
Developer's Management System (DMS) registers NSFs and their Developer's Management System (DMS) registers NSFs and their
capabilities into Security Controller via the registration interface. capabilities into Security Controller via the registration interface.
In case that Security Controller fails to find any NSF among the In case that Security Controller fails to find any NSF among the
registered NSFs which can provide some required capabilities, registered NSFs which can provide some required capabilities,
Security Controller uses the registration interface to query DMS Security Controller uses the registration interface to query DMS
about NSF(s) having the required capabilities. The following about NSF(s) having the required capabilities. The following
sections describe the YANG data models to support these operations. sections describe the YANG data models to support these operations.
6.1.2.1. NSF Capability Registration 6.1.2.1. NSF Capability Registration
This section expands the i2nsf-nsf-registrations in Figure 5. This section expands the i2nsf-nsf-registrations in Figure 5.
NSF Capability Registration NSF Capability Registration
+--rw i2nsf-nsf-registrations +--rw i2nsf-nsf-registrations
+--rw i2nsf-nsf-capability-registration* [nsf-name] +--rw i2nsf-nsf-capability-registration* [nsf-name]
+--rw nsf-name string +--rw nsf-name string
+--rw nsf-capability-info +--rw nsf-capability-info
| uses i2nsf-nsf-capability-info | uses i2nsf-nsf-capability-info
+--rw i2nsf-capability
| uses ietf-i2nsf-capability
+--rw nsf-performance-capability
| uses i2nsf-nsf-performance-capability
+--rw nsf-access-info +--rw nsf-access-info
| uses i2nsf-nsf-access-info | uses i2nsf-nsf-access-info
+--rw nsf-instance-name
+--rw i2nsf-nsf-address nsf-address
+--rw nsf-port-number
Figure 6: YANG tree of NSF Capability Registration Figure 6: YANG Tree of NSF Capability Registration
When registering an NSF to Security Controller, DMS uses this module When registering an NSF to Security Controller, DMS uses this module
to describe what capabilities the NSF can offer. DMS includes the to describe what capabilities the NSF can offer. DMS includes the
network access information of the NSF which is required to make a network access information of the NSF which is required to make a
network connection with the NSF as well as the capability description network connection with the NSF as well as the capability description
of the NSF. of the NSF.
6.1.2.2. NSF Capability Query 6.1.2.2. NSF Capability Query
This section expands the i2nsf-nsf-capability-query in Figure 5. This section expands the i2nsf-nsf-capability-query in Figure 5.
NSF Capability Query NSF Capability Query
+---x i2nsf-nsf-capability-query +---x i2nsf-nsf-capability-query
+---w input +---w input
| +---w query-i2nsf-capability-info | +---w query-i2nsf-capability-info
| | uses ietf-i2nsf-capability | | uses ietf-i2nsf-capability
+--ro output +--ro output
+--ro nsf-access-info +--ro nsf-access-info
| uses i2nsf-nsf-access-info | uses i2nsf-nsf-access-info
+--rw nsf-instance-name
+--rw i2nsf-nsf-address nsf-address
+--rw nsf-port-number
Figure 7: YANG tree of NSF Capability Query Figure 7: YANG Tree of NSF Capability Query
Security Controller may require some additional capabilities to Security Controller may require some additional capabilities to
provide the security service requested by an I2NSF user, but none of provide the security service requested by an I2NSF user, but none of
the registered NSFs has the required capabilities. In this case, the registered NSFs has the required capabilities. In this case,
Security Controller makes a description of the required capabilities Security Controller makes a description of the required capabilities
using this module and then queries DMS about which NSF(s) can provide using this module and then queries DMS about which NSF(s) can provide
these capabilities. Use NETCONF RPCs to send a NSF capability query. these capabilities. Use NETCONF RPCs to send a NSF capability query.
Input data is query-i2nsf-capability-info and output data is nsf- Input data is query-i2nsf-capability-info and output data is nsf-
access-info. In Figure 7, the ietf-i2nsf-capability refers to the access-info. In Figure 7, the ietf-i2nsf-capability refers to the
module defined in [capability-dm]. module defined in [capability-dm].
skipping to change at page 11, line 17 skipping to change at page 11, line 23
This section expands the i2nsf-nsf-capability-info in Figure 6 and This section expands the i2nsf-nsf-capability-info in Figure 6 and
Figure 7. Figure 7.
NSF Capability Information NSF Capability Information
+--rw i2nsf-nsf-capability-info +--rw i2nsf-nsf-capability-info
+--rw i2nsf-capability +--rw i2nsf-capability
| uses ietf-i2nsf-capability | uses ietf-i2nsf-capability
+--rw nsf-performance-capability +--rw nsf-performance-capability
| uses i2nsf-nsf-performance-capability | uses i2nsf-nsf-performance-capability
Figure 8: YANG tree of I2NSF NSF Capability Information Figure 8: YANG Tree of I2NSF NSF Capability Information
In Figure 8, the ietf-i2nsf-capability refers to the module defined In Figure 8, the ietf-i2nsf-capability refers to the module defined
in [capability-dm]. The i2nsf-nsf-performance-capability is used to in [capability-dm]. The i2nsf-nsf-performance-capability is used to
specify the performance capability of an NSF. specify the performance capability of an NSF.
6.1.3.1. NSF Performance Capability 6.1.3.1. NSF Performance Capability
This section expands the i2nsf-nsf-performance-capability in This section expands the i2nsf-nsf-performance-capability in
Figure 8. Figure 8.
skipping to change at page 11, line 41 skipping to change at page 11, line 47
| +--rw processing-average uint16 | +--rw processing-average uint16
| +--rw processing-peak uint16 | +--rw processing-peak uint16
+--rw bandwidth +--rw bandwidth
| +--rw outbound | +--rw outbound
| | +--rw outbound-average uint16 | | +--rw outbound-average uint16
| | +--rw outbound-peak uint16 | | +--rw outbound-peak uint16
| +--rw inbound | +--rw inbound
| | +--rw inbound-average uint16 | | +--rw inbound-average uint16
| | +--rw inbound-peak uint16 | | +--rw inbound-peak uint16
Figure 9: YANG tree of I2NSF NSF Performance Capability Figure 9: YANG Tree of I2NSF NSF Performance Capability
This module is used to specify the performance capabilities of an NSF This module is used to specify the performance capabilities of an NSF
when registering or initiating the NSF. when registering or initiating the NSF.
6.1.4. NSF Access Information 6.1.4. NSF Access Information
This section expands the i2nsf-nsf-access-info in Figure 6. This section expands the i2nsf-nsf-access-info in Figure 6.
NSF Access Information NSF Access Information
+--rw i2nsf-nsf-access-info +--rw i2nsf-nsf-access-info
+--rw nsf-instance-name string +--rw nsf-instance-name string
+--rw nsf-address inet:ipv4-address +--rw i2nsf-nsf-address nsf-address
+--rw nsf-port-number inet:port-number +--rw nsf-port-number inet:port-number
Figure 10: YANG tree of I2NSF NSF Access Informantion Figure 10: YANG Tree of I2NSF NSF Access Informantion
This module contains the network access information of an NSF that is This module contains the network access information of an NSF that is
required to enable network communications with the NSF. required to enable network communications with the NSF.
6.2. YANG Data Modules 6.2. YANG Data Modules
This section provides YANG modules of the data model for the This section provides YANG modules of the data model for the
registration interface between Security Controller and Developer's registration interface between Security Controller and Developer's
Management System, as defined in Section 5. Management System, as defined in Section 5.
<CODE BEGINS> file "ietf-i2nsf-reg-interface@2019-06-12.yang" <CODE BEGINS> file "ietf-i2nsf-reg-interface@2019-07-24.yang"
module ietf-i2nsf-reg-interface{ module ietf-i2nsf-reg-interface {
yang-version 1.1; yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface";
prefix "iiregi";
import ietf-inet-types{ namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface";
prefix inet;
reference "RFC 6991";
}
import ietf-i2nsf-capability{
prefix capa;
reference "draft-ietf-i2nsf-capability
-data-model-04";
}
organization
"IETF I2NSF (Interface to Network Security Functions)
Working Group";
contact prefix nsfreg;
"WG Web: <http://tools.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org> import ietf-inet-types {
prefix inet;
reference "RFC 6991";
}
import ietf-i2nsf-capability {
prefix capa;
reference "draft-ietf-i2nsf-capability-data-model-05";
}
WG Chair: Linda Dunbar organization
<mailto:Linda.duhbar@huawei.com> "IETF I2NSF (Interface to Network Security
Functions) Working Group";
Editor: Sangwon Hyun contact
<mailto:swhyun77@skku.edu> "WG Web: <http://tools.ietf.org/wg/i2nsf>
Editor: Jaehoon Paul Jeong WG List: <mailto:i2nsf@ietf.org>
<mailto:pauljeong@skku.edu> WG Chair: Linda Dunbar
<mailto:Linda.duhbar@huawei.com>
Editor: Taekyun Roh Editor: Sangwon Hyun
<mailto:tkroh0198@skku.edu> <mailto:shyun@chosun.ac.kr>
Editor: Jaehoon Paul Jeong
<mailto:pauljeong@skku.edu>
Editor: Taekyun Roh
<mailto:tkroh0198@skku.edu>
Editor: Sarang Wi
<mailto:dnl9795@skku.edu>
Editor: Jung-Soo Park
<mailto:pjs@etri.re.kr>";
Editor: Sarang Wi description
<mailto:dnl9795@skku.edu> "This module defines a YANG data model for
I2NSF registration interface.
Editor: Jung-Soo Park Copyright (c) <2019> IETF Trust and the persons
<mailto:pjs@etri.re.kr>"; identified as authors of the code. All rights reserved.
description Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
"It defines a YANG data model for Registration Interface. This version of this YANG module is part of
Copyright (c) 2018 IETF Trust and the persons identified as draft-ietf-i2nsf-registration-interface-dm-05; see
authors of the code. All rights reserved. the draft itself for full legal notices.";
Redistribution and use in source and binary forms, with or revision 2019-07-24 {
without modification, is permitted pursuant to, and subject description "The fifth revision";
to the license terms contained in, the Simplified BSD License reference
set forth in Section 4.c of the IETF Trust's Legal Provisions "draft-ietf-i2nsf-registration-interface-dm-05";
Relating to IETF Documents }
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see typedef nsf-address {
the RFC itself for full legal notices."; type union {
type inet:ipv4-address;
type inet:ipv6-address;
}
description
"IPv4/IPv6 address of this NSF";
revision 2019-06-12 { }
description "The third revision";
reference rpc i2nsf-nsf-capability-query {
"RFC XXXX: I2NSF Registration Interface YANG Data Model"; description
"Description of the capabilities that the
Security Controller requests to the DMS";
input {
container query-i2nsf-capability-info {
description
"Description of the capabilities to request";
uses "capa:nsf-capabilities";
reference
"draft-ietf-i2nsf-capability-data-model-05";
}
}
output {
container nsf-access-info {
description
"Network access information of an NSF
with the requested capabilities";
uses i2nsf-nsf-access-info;
} }
rpc i2nsf-nsf-capability-query { }
description }
"Capability information that the container i2nsf-nsf-registrations {
Security Controller description
sends to the DMS"; "Information of an NSF that DMS registers
input{ to Security Controller";
container query-i2nsf-capability-info { list i2nsf-nsf-capability-registration {
description key "nsf-name";
"i2nsf capability information"; description
uses "capa:nsf-capabilities"; "Required information for registration";
reference leaf nsf-name {
"draft-ietf-i2nsf-capability type string;
-data-model-04"; mandatory true;
} description
"Unique name of this registered NSF";
}
container nsf-capability-info {
description
"Capability description of this NSF";
uses i2nsf-nsf-capability-info;
}
container nsf-access-info {
description
"Network access information of this NSF";
uses i2nsf-nsf-access-info;
}
} }
output{ }
container nsf-access-info {
description
"nsf access information";
uses i2nsf-nsf-access-info;
} grouping i2nsf-nsf-performance-capability {
} description
"Description of the performance capailities
of an NSF";
container processing {
description
"Processing power of an NSF in the unit of GHz (gigahertz)";
leaf processing-average {
type uint16;
description
"Average processing power";
}
leaf processing-peak {
type uint16;
description
"Peak processing power";
}
}
container bandwidth {
description
"Network bandwidth available on an NSF
in the unit of Gbps (gigabits per second)";
container outbound {
description
"Outbound network bandwidth";
leaf outbound-average {
type uint16;
description
"Average outbound bandwidth";
} }
container i2nsf-nsf-registrations{ leaf outbound-peak {
type uint16;
description
"Peak outbound bandwidth";
}
}
container inbound {
description description
"i2nsf-nsf-registrations"; "Inbound network bandwidth";
list i2nsf-nsf-capability-registration { leaf inbound-average {
key "nsf-name"; type uint16;
description description
"Requeired information for registration"; "Average inbound bandwidth";
leaf nsf-name {
type string;
mandatory true;
description
"nsf-name";
}
container nsf-capability-info {
description
"nsf-capability-information";
uses i2nsf-nsf-capability-info;
}
container nsf-access-info {
description
"nsf-access-info";
uses i2nsf-nsf-access-info;
}
}
} }
leaf inbound-peak {
grouping i2nsf-nsf-performance-capability { type uint16;
description description
"NSF performance capailities"; "Peak inbound bandwidth";
container processing{
description
"processing info";
leaf processing-average{
type uint16;
description
"processing-average";
}
leaf processing-peak{
type uint16;
description
"processing peak";
}
}
container bandwidth{
description
"bandwidth info";
container outbound{
description
"outbound";
leaf outbound-average{
type uint16;
description
"outbound-average";
}
leaf outbound-peak{
type uint16;
description
"outbound-peak";
}
}
container inbound{
description
"inbound";
leaf inbound-average{
type uint16;
description
"inbound-average";
}
leaf inbound-peak{
type uint16;
description
"inbound-peak";
}
}
} }
}
} }
grouping i2nsf-nsf-capability-info { }
grouping i2nsf-nsf-capability-info {
description
"Capability description of an NSF";
container i2nsf-capability {
description description
"Detail information of an NSF"; "Description of the security capabilities of an NSF";
container i2nsf-capability { uses "capa:nsf-capabilities";
description reference "draft-ietf-i2nsf-capability-data-model-05";
"ietf i2nsf capability information"; }
uses "capa:nsf-capabilities"; container nsf-performance-capability {
reference "draft-ietf-i2nsf-capability description
-data-model-04"; "Description of the performance capabilities of an NSF";
uses i2nsf-nsf-performance-capability;
} }
container nsf-performance-capability {
description
"performance capability";
uses i2nsf-nsf-performance-capability;
}
} }
grouping i2nsf-nsf-access-info { grouping i2nsf-nsf-access-info {
description
"Information required to access an NSF";
leaf nsf-instance-name {
type string;
description description
"NSF access information"; "Unique name of this NSF instance";
leaf nsf-instance-name { }
type string; leaf i2nsf-nsf-address {
description type nsf-address;
"nsf-instance-name"; description
} "IPv4/IPv6 address of this NSF";
leaf nsf-address { }
type inet:ipv4-address; leaf nsf-port {
mandatory true; type inet:port-number;
description description
"nsf-address"; "Port available on this NSF";
} }
leaf nsf-port-address { }
type inet:port-number; }
description
"nsf-port-address"; <CODE ENDS>
}
}
}
<CODE ENDS>
Figure 11: Registration Interface YANG Data Model Figure 11: Registration Interface YANG Data Model
7. IANA Considerations 7. IANA Considerations
This document requests IANA to register the following URI in the This document requests IANA to register the following URI in the
"IETF XML Registry" [RFC3688]: "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in This document requests IANA to register the following YANG module in
the "YANG Module Names" registry [RFC7950]. the "YANG Module Names" registry [RFC7950].
Name: ietf-i2nsf-reg-interface Name: ietf-i2nsf-reg-interface
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface
Prefix: iiregi Prefix: nsfreg
Reference: RFC XXXX Reference: RFC XXXX
8. Security Considerations 8. Security Considerations
The YANG module specified in this document defines a data schema The YANG module specified in this document defines a data schema
designed to be accessed through network management protocols such as designed to be accessed through network management protocols such as
NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is
the secure transport layer, and the required secure transport is the secure transport layer, and the required secure transport is
Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS,
and the required secure transport is TLS [RFC8446]. and the required secure transport is TLS [RFC8446].
The NETCONF access control model [RFC8341] provides a means of The NETCONF access control model [RFC8341] provides a means of
restricting access to specific NETCONF or RESTCONF users to a restricting access to specific NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content. operations and content.
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
o i2nsf-nsf-registrations: The attacker may exploit this to register
a compromised or malicious NSF instead of a legitimate NSF to the
Security Controller.
o i2nsf-nsf-performance-capability: The attacker may provide
incorrect information of the performance capability of any target
NSF by illegally modifying this.
o i2nsf-nsf-capability-info: The attacker may provide incorrect
information of the security capability of any target NSF by
illegally modifying this.
o i2nsf-nsf-access-info: The attacker may provide incorrect network
access information of any target NSF by illegally modifying this.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
o i2nsf-nsf-registrations: The attacker may try to gather some
sensitive information of a registered NSF by sniffing this.
o i2nsf-nsf-performance-capability: The attacker may gather the
performance capability information of any target NSF and misuse
the information for subsequent attacks.
o i2nsf-nsf-capability-info: The attacker may gather the security
capability information of any target NSF and misuse the
information for subsequent attacks.
o i2nsf-nsf-access-info: The attacker may gather the network access
information of any target NSF and misuse the information for
subsequent attacks.
The RPC operation in this YANG module may be considered sensitive or
vulnerable in some network environments. It is thus important to
control access to this operation. The following is the operation and
its sensitivity/vulnerability:
o i2nsf-nsf-capability-query: The attacker may exploit this RPC
operation to deteriorate the availability of the DMS and/or gather
the information of some interested NSFs from the DMS.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
skipping to change at page 18, line 17 skipping to change at page 19, line 43
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
9.2. Informative References 9.2. Informative References
[capability-dm] [capability-dm]
Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin, Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin,
"I2NSF Capability YANG Data Model", draft-ietf-i2nsf- "I2NSF Capability YANG Data Model", draft-ietf-i2nsf-
capability-data-model-05 (work in progress), June 2019. capability-data-model-05 (work in progress), July 2019.
[draft-ietf-nvo3-vxlan-gpe] [i2nsf-ipsec]
Maino, Ed., F., Kreeger, Ed., L., and U. Elzur, Ed., Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-
"Generic Protocol Extension for VXLAN", draft-ietf-nvo3- Garcia, "Software-Defined Networking (SDN)-based IPsec
vxlan-gpe-06 (work in progress), April 2018. Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow-
protection-05 (work in progress), July 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-07 (work in Terminology", draft-ietf-i2nsf-terminology-08 (work in
progress), January 2019. progress), July 2019.
[nfv-framework] [nfv-framework]
"Network Functions Virtualisation (NFV); Architectureal "Network Functions Virtualisation (NFV); Architectureal
Framework", ETSI GS NFV 002 ETSI GS NFV 002 V1.1.1, Framework", ETSI GS NFV 002 ETSI GS NFV 002 V1.1.1,
October 2013. October 2013.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. [nvo3-vxlan-gpe]
Kumar, "Framework for Interface to Network Security Maino, Ed., F., Kreeger, Ed., L., and U. Elzur, Ed.,
Functions", RFC 8329, February 2018. "Generic Protocol Extension for VXLAN", draft-ietf-nvo3-
vxlan-gpe-06 (work in progress), April 2018.
[RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,
S., and N. Bahadur, "A YANG Data Model for Routing S., and N. Bahadur, "A YANG Data Model for Routing
Information Base (RIB)", RFC 8431, September 2018. Information Base (RIB)", RFC 8431, September 2018.
[supa-policy-data-model] [supa-policy-data-model]
Halpern, J., Strassner, J., and S. van der Meer, "Generic Halpern, J., Strassner, J., and S. van der Meer, "Generic
Policy Data Model for Simplified Use of Policy Policy Data Model for Simplified Use of Policy
Abstractions (SUPA)", draft-ietf-supa-generic-policy-data- Abstractions (SUPA)", draft-ietf-supa-generic-policy-data-
model-04 (work in progress), June 2017. model-04 (work in progress), June 2017.
skipping to change at page 21, line 12 skipping to change at page 23, line 12
</outbound> </outbound>
<inbound> <inbound>
<inbound-average>1000</inbound-average> <inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak> <inbound-peak>5000</inbound-peak>
</inbound> </inbound>
</bandwidth> </bandwidth>
</nsf-performance-capability> </nsf-performance-capability>
</nsf-capability-info> </nsf-capability-info>
<nsf-access-info> <nsf-access-info>
<nsf-instance-name>general_firewall</nsf-instance-name> <nsf-instance-name>general_firewall</nsf-instance-name>
<nsf-address>221.159.112.100</nsf-address> <i2nsf-nsf-address>2001:DB8:8:4::2</i2nsf-nsf-address>
<nsf-port-address>3000</nsf-port-address> <nsf-port-address>3000</nsf-port-address>
</nsf-access-info> </nsf-access-info>
</i2nsf-nsf-capability-registration> </i2nsf-nsf-capability-registration>
</i2nsf-nsf-registrations> </i2nsf-nsf-registrations>
Figure 12: Configuration XML for Registration of General Firewall Figure 12: Configuration XML for Registration of General Firewall
Figure 12 shows the configuration XML for registering the general Figure 12 shows the configuration XML for registering the general
firewall and its capabilities as follows. firewall and its capabilities as follows.
skipping to change at page 21, line 35 skipping to change at page 23, line 35
2. The NSF can inspect protocol, exact IPv4 address, and range IPv4 2. The NSF can inspect protocol, exact IPv4 address, and range IPv4
address for IPv4 packets. address for IPv4 packets.
3. The NSF can inspect exact port number and range port number for 3. The NSF can inspect exact port number and range port number for
tcp packets. tcp packets.
4. The NSF can determine whether the packets are allowed to pass, 4. The NSF can determine whether the packets are allowed to pass,
drop, or alert. drop, or alert.
5. The NSF can support IPsec not through IKEv2, but through a 5. The NSF can support IPsec not through IKEv2, but through a
Security Controller. Security Controller [i2nsf-ipsec].
6. The NSF can have processing power and bandwidth. 6. The NSF can have processing power and bandwidth.
7. The location of the NSF is 221.159.112.100. 7. The location of the NSF is 2001:DB8:8:4::2.
8. The port of the NSF is 3000. 8. The port of the NSF is 3000.
A.2. Example 2: Registration for Capabilities of Time based Firewall A.2. Example 2: Registration for Capabilities of Time based Firewall
This section shows an XML example for registering the capabilities of This section shows an XML example for registering the capabilities of
time-based firewall. time-based firewall.
<i2nsf-nsf-registrations <i2nsf-nsf-registrations
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface" xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
skipping to change at page 22, line 46 skipping to change at page 24, line 46
</outbound> </outbound>
<inbound> <inbound>
<inbound-average>1000</inbound-average> <inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak> <inbound-peak>5000</inbound-peak>
</inbound> </inbound>
</bandwidth> </bandwidth>
</nsf-performance-capability> </nsf-performance-capability>
</nsf-capability-info> </nsf-capability-info>
<nsf-access-info> <nsf-access-info>
<nsf-instance-name>time_based_firewall</nsf-instance-name> <nsf-instance-name>time_based_firewall</nsf-instance-name>
<nsf-address>221.159.112.110</nsf-address> <i2nsf-nsf-address>2001:DB8:8:4::3</i2nsf-nsf-address>
<nsf-port-address>3000</nsf-port-address> <nsf-port-address>3000</nsf-port-address>
</nsf-access-info> </nsf-access-info>
</i2nsf-nsf-capability-registration> </i2nsf-nsf-capability-registration>
</i2nsf-nsf-registrations> </i2nsf-nsf-registrations>
Figure 13: Configuration XML for Registration of Time based Firewall Figure 13: Configuration XML for Registration of Time based Firewall
Figure 13 shows the configuration XML for registering the time-based Figure 13 shows the configuration XML for registering the time-based
firewall and its capabilities as follows. firewall and its capabilities as follows.
skipping to change at page 23, line 21 skipping to change at page 25, line 21
2. The NSF can enforce the security policy rule according to 2. The NSF can enforce the security policy rule according to
absolute time and periodic time. absolute time and periodic time.
3. The NSF can inspect protocol, exact IPv4 address, and range IPv4 3. The NSF can inspect protocol, exact IPv4 address, and range IPv4
address for IPv4 packets. address for IPv4 packets.
4. The NSF can determine whether the packets are allowed to pass, 4. The NSF can determine whether the packets are allowed to pass,
drop, or alert. drop, or alert.
5. The NSF can support IPsec through IKEv2. 5. The NSF can support IPsec through IKEv2 [i2nsf-ipsec].
6. The NSF can have processing power and bandwidth. 6. The NSF can have processing power and bandwidth.
7. The location of the NSF is 221.159.112.110. 7. The location of the NSF is 2001:DB8:8:4::3.
8. The port of the NSF is 3000. 8. The port of the NSF is 3000.
A.3. Example 3: Registration for Capabilities of Web Filter A.3. Example 3: Registration for Capabilities of Web Filter
This section shows an XML example for registering the capabilities of This section shows an XML example for registering the capabilities of
web filter. web filter.
<i2nsf-nsf-registrations <i2nsf-nsf-registrations
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface" xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
skipping to change at page 24, line 27 skipping to change at page 26, line 27
</outbound> </outbound>
<inbound> <inbound>
<inbound-average>1000</inbound-average> <inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak> <inbound-peak>5000</inbound-peak>
</inbound> </inbound>
</bandwidth> </bandwidth>
</nsf-performance-capability> </nsf-performance-capability>
</nsf-capability-info> </nsf-capability-info>
<nsf-access-info> <nsf-access-info>
<nsf-instance-name>web_filter</nsf-instance-name> <nsf-instance-name>web_filter</nsf-instance-name>
<nsf-address>221.159.112.120</nsf-address> <i2nsf-nsf-address>2001:DB8:8:4::4</i2nsf-nsf-address>
<nsf-port-address>3000</nsf-port-address> <nsf-port-address>3000</nsf-port-address>
</nsf-access-info> </nsf-access-info>
</i2nsf-nsf-capability-registration> </i2nsf-nsf-capability-registration>
</i2nsf-nsf-registrations> </i2nsf-nsf-registrations>
Figure 14: Configuration XML for Registration of Web Filter Figure 14: Configuration XML for Registration of Web Filter
Figure 14 shows the configuration XML for registering the web filter, Figure 14 shows the configuration XML for registering the web filter,
and its capabilities are as follows. and its capabilities are as follows.
1. The instance name of the NSF is web_filter. 1. The instance name of the NSF is web_filter.
2. The NSF can inspect url for http and https packets. 2. The NSF can inspect url for http and https packets.
3. The NSF can determine whether the packets are allowed to pass, 3. The NSF can determine whether the packets are allowed to pass,
drop, or alert. drop, or alert.
4. The NSF can support IPsec not through IKEv2, but through a 4. The NSF can support IPsec not through IKEv2, but through a
Security Controller. Security Controller [i2nsf-ipsec].
5. The NSF can have processing power and bandwidth. 5. The NSF can have processing power and bandwidth.
6. The location of the NSF is 221.159.112.120. 6. The location of the NSF is 2001:DB8:8:4::4.
7. The port of the NSF is 3000. 7. The port of the NSF is 3000.
A.4. Example 4: Registration for Capabilities of VoIP/VoLTE Filter A.4. Example 4: Registration for Capabilities of VoIP/VoLTE Filter
This section shows an XML example for registering the capabilities of This section shows an XML example for registering the capabilities of
VoIP/VoLTE filter. VoIP/VoLTE filter.
<i2nsf-nsf-registrations <i2nsf-nsf-registrations
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface" xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"> xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<i2nsf-nsf-capability-registration> <i2nsf-nsf-capability-registration>
<nsf-name>voip_volte_filter_capability</nsf-name> <nsf-name>voip_volte_filter_capability</nsf-name>
<nsf-capability-info> <nsf-capability-info>
<i2nsf-capability> <i2nsf-capability>
<condition-capabilities> <condition-capabilities>
<advanced-nsf-capabilities> <advanced-nsf-capabilities>
<voip-volte-capa>capa:voice-id</voip-volte-capa> <voip-volte-capa>capa:voice-id</voip-volte-capa>
</advanced-nsf-capabilities> </advanced-nsf-capabilities>
</condition-capabilities> </condition-capabilities>
<action-capabilities> <action-capabilities>
<ingress-action-capa>capa:pass</ingress-action-capa> <ingress-action-capa>capa:pass</ingress-action-capa>
<ingress-action-capa>capa:drop</ingress-action-capa> <ingress-action-capa>capa:drop</ingress-action-capa>
<ingress-action-capa>capa:alert</ingress-action-capa> <ingress-action-capa>capa:alert</ingress-action-capa>
<egress-action-capa>capa:pass</egress-action-capa> <egress-action-capa>capa:pass</egress-action-capa>
<egress-action-capa>capa:drop</egress-action-capa> <egress-action-capa>capa:drop</egress-action-capa>
<egress-action-capa>capa:alert</egress-action-capa> <egress-action-capa>capa:alert</egress-action-capa>
</action-capabilities> </action-capabilities>
<ipsec-method>capa:ikeless</ipsec-method> <ipsec-method>capa:ikeless</ipsec-method>
</i2nsf-capability> </i2nsf-capability>
<nsf-performance-capability> <nsf-performance-capability>
<processing> <processing>
<processing-average>1000</processing-average> <processing-average>1000</processing-average>
<processing-peak>5000</processing-peak> <processing-peak>5000</processing-peak>
</processing> </processing>
<bandwidth> <bandwidth>
<outbound> <outbound>
<outbound-average>1000</outbound-average> <outbound-average>1000</outbound-average>
<outbound-peak>5000</outbound-peak> <outbound-peak>5000</outbound-peak>
</outbound> </outbound>
<inbound> <inbound>
<inbound-average>1000</inbound-average> <inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak> <inbound-peak>5000</inbound-peak>
</inbound> </inbound>
</bandwidth> </bandwidth>
</nsf-performance-capability> </nsf-performance-capability>
</nsf-capability-info> </nsf-capability-info>
<nsf-access-info> <nsf-access-info>
<nsf-instance-name>voip_volte_filter</nsf-instance-name> <nsf-instance-name>voip_volte_filter</nsf-instance-name>
<nsf-address>221.159.112.130</nsf-address> <i2nsf-nsf-address>2001:DB8:8:4::5</i2nsf-nsf-address>
<nsf-port-address>3000</nsf-port-address> <nsf-port-address>3000</nsf-port-address>
</nsf-access-info> </nsf-access-info>
</i2nsf-nsf-capability-registration> </i2nsf-nsf-capability-registration>
</i2nsf-nsf-registrations> </i2nsf-nsf-registrations>
Figure 15: Configuration XML for Registration of VoIP/VoLTE Filter Figure 15: Configuration XML for Registration of VoIP/VoLTE Filter
Figure 15 shows the configuration XML for registering VoIP/VoLTE Figure 15 shows the configuration XML for registering VoIP/VoLTE
filter, and its capabilities are as follows. filter, and its capabilities are as follows.
1. The instance name of the NSF is voip_volte_filter. 1. The instance name of the NSF is voip_volte_filter.
2. The NSF can inspect voice id for VoIP/VoLTE packets. 2. The NSF can inspect voice id for VoIP/VoLTE packets.
3. The NSF can determine whether the packets are allowed to pass, 3. The NSF can determine whether the packets are allowed to pass,
drop, or alert. drop, or alert.
4. The NSF can support IPsec not through IKEv2, but through a 4. The NSF can support IPsec not through IKEv2, but through a
Security Controller. Security Controller [i2nsf-ipsec].
5. The NSF can have processing power and bandwidth. 5. The NSF can have processing power and bandwidth.
6. The location of the NSF is 221.159.112.130. 6. The location of the NSF is 2001:DB8:8:4::5.
7. The port of the NSF is 3000. 7. The port of the NSF is 3000.
A.5. Example 5: Registration for Capabilities of HTTP and HTTPS Flood A.5. Example 5: Registration for Capabilities of HTTP and HTTPS Flood
Mitigation Mitigation
This section shows an XML example for registering the capabilities of This section shows an XML example for registering the capabilities of
http and https flood mitigation. http and https flood mitigation.
<i2nsf-nsf-registrations <i2nsf-nsf-registrations
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface" xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"> xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<i2nsf-nsf-capability-registration> <i2nsf-nsf-capability-registration>
<nsf-name> <nsf-name>
http_and_h ttps_flood_mitigation_capability http_and_h ttps_flood_mitigation_capability
</nsf-name> </nsf-name>
<nsf-capability-info> <nsf-capability-info>
<i2nsf-capability> <i2nsf-capability>
<condition-capabilities> <condition-capabilities>
<advanced-nsf-capabilities> <advanced-nsf-capabilities>
<antiddos-capa>capa:http-flood-action</antiddos-capa> <antiddos-capa>capa:http-flood-action</antiddos-capa>
<antiddos-capa>capa:https-flood-action</antiddos-capa> <antiddos-capa>capa:https-flood-action</antiddos-capa>
</advanced-nsf-capabilities> </advanced-nsf-capabilities>
</condition-capabilities> </condition-capabilities>
<action-capabilities> <action-capabilities>
<ingress-action-capa>capa:pass</ingress-action-capa> <ingress-action-capa>capa:pass</ingress-action-capa>
<ingress-action-capa>capa:drop</ingress-action-capa> <ingress-action-capa>capa:drop</ingress-action-capa>
<ingress-action-capa>capa:alert</ingress-action-capa> <ingress-action-capa>capa:alert</ingress-action-capa>
<egress-action-capa>capa:pass</egress-action-capa> <egress-action-capa>capa:pass</egress-action-capa>
<egress-action-capa>capa:drop</egress-action-capa> <egress-action-capa>capa:drop</egress-action-capa>
<egress-action-capa>capa:alert</egress-action-capa> <egress-action-capa>capa:alert</egress-action-capa>
skipping to change at page 27, line 37 skipping to change at page 29, line 37
<inbound-average>1000</inbound-average> <inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak> <inbound-peak>5000</inbound-peak>
</inbound> </inbound>
</bandwidth> </bandwidth>
</nsf-performance-capability> </nsf-performance-capability>
</nsf-capability-info> </nsf-capability-info>
<nsf-access-info> <nsf-access-info>
<nsf-instance-name> <nsf-instance-name>
http_and_https_flood_mitigation http_and_https_flood_mitigation
</nsf-instance-name> </nsf-instance-name>
<nsf-address>221.159.112.140</nsf-address> <i2nsf-nsf-address>2001:DB8:8:4::6</i2nsf-nsf-address>
<nsf-port-address>3000</nsf-port-address> <nsf-port-address>3000</nsf-port-address>
</nsf-access-info> </nsf-access-info>
</i2nsf-nsf-capability-registration> </i2nsf-nsf-capability-registration>
</i2nsf-nsf-registrations> </i2nsf-nsf-registrations>
Figure 16: Configuration XML for Registration of of HTTP and HTTPS Figure 16: Configuration XML for Registration of of HTTP and HTTPS
Flood Mitigation Flood Mitigation
Figure 16 shows the configuration XML for registering the http and Figure 16 shows the configuration XML for registering the http and
https flood mitigator, and its capabilities are as follows. https flood mitigator, and its capabilities are as follows.
1. The instance name of the NSF is http_and_https_flood_mitigation. 1. The instance name of the NSF is http_and_https_flood_mitigation.
2. The NSF can control the amount of packets for http and https 2. The NSF can control the amount of packets for http and https
packets. packets.
3. The NSF can determine whether the packets are allowed to pass, 3. The NSF can determine whether the packets are allowed to pass,
drop, or alert. drop, or alert.
4. The NSF can support IPsec through IKEv2. 4. The NSF can support IPsec through IKEv2 [i2nsf-ipsec].
5. The NSF can have processing power and bandwidth. 5. The NSF can have processing power and bandwidth.
6. The location of the NSF is 221.159.112.140. 6. The location of the NSF is 2001:DB8:8:4::6.
7. The port of the NSF is 3000. 7. The port of the NSF is 3000.
A.6. Example 6: Query for Capabilities of Time based Firewall A.6. Example 6: Query for Capabilities of Time based Firewall
This section shows an XML example for querying the capabilities of This section shows an XML example for querying the capabilities of
time-based firewall. time-based firewall.
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<i2nsf-nsf-capability-query <i2nsf-nsf-capability-query
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface" xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"> xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<query-i2nsf-capability-info> <query-i2nsf-capability-info>
<time-capabilities>absolute-time</time-capabilities> <time-capabilities>absolute-time</time-capabilities>
<time-capabilities>periodic-time</time-capabilities> <time-capabilities>periodic-time</time-capabilities>
<condition-capabilities> <condition-capabilities>
<generic-nsf-capabilities> <generic-nsf-capabilities>
<ipv4-capa>capa:ipv4-protocol</ipv4-capa> <ipv4-capa>capa:ipv4-protocol</ipv4-capa>
<ipv4-capa>capa:exact-ipv4-address</ipv4-capa> <ipv4-capa>capa:exact-ipv4-address</ipv4-capa>
<ipv4-capa>capa:range-ipv4-address</ipv4-capa> <ipv4-capa>capa:range-ipv4-address</ipv4-capa>
</generic-nsf-capabilities> </generic-nsf-capabilities>
</condition-capabilities> </condition-capabilities>
<action-capabilities> <action-capabilities>
<ingress-action-capa>capa:pass</ingress-action-capa> <ingress-action-capa>capa:pass</ingress-action-capa>
<ingress-action-capa>capa:drop</ingress-action-capa> <ingress-action-capa>capa:drop</ingress-action-capa>
<ingress-action-capa>capa:alert</ingress-action-capa> <ingress-action-capa>capa:alert</ingress-action-capa>
<egress-action-capa>capa:pass</egress-action-capa> <egress-action-capa>capa:pass</egress-action-capa>
<egress-action-capa>capa:drop</egress-action-capa> <egress-action-capa>capa:drop</egress-action-capa>
<egress-action-capa>capa:alert</egress-action-capa> <egress-action-capa>capa:alert</egress-action-capa>
</action-capabilities> </action-capabilities>
<ipsec-method>capa:ikeless</ipsec-method> <ipsec-method>capa:ikeless</ipsec-method>
</query-i2nsf-capability-info> </query-i2nsf-capability-info>
</i2nsf-nsf-capability-query> </i2nsf-nsf-capability-query>
</rpc> </rpc>
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<nsf-access-info <nsf-access-info
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface">
<nsf-instance-name>time-based-firewall</nsf-instance-name> <nsf-instance-name>time-based-firewall</nsf-instance-name>
<nsf-address>221.159.223.250</nsf-address> <i2nsf-nsf-address>2001:DB8:8:4::7</i2nsf-nsf-address>
<nsf-port-address>8080</nsf-port-address> <nsf-port-address>8080</nsf-port-address>
</nsf-access-info> </nsf-access-info>
</rpc-reply> </rpc-reply>
Figure 17: Configuration XML for Query of Time-based Firewall Figure 17: Configuration XML for Query of Time-based Firewall
Figure 17 shows the XML configuration for querying the capabilities Figure 17 shows the XML configuration for querying the capabilities
of the time-based firewall. of the time-based firewall.
Appendix B. NSF Lifecycle Managmenet in NFV Environments Appendix B. NSF Lifecycle Managmenet in NFV Environments
Network Functions Virtualization (NFV) can be used to implement I2NSF Network Functions Virtualization (NFV) can be used to implement I2NSF
framework. In NFV environments, NSFs are deployed as virtual network framework. In NFV environments, NSFs are deployed as virtual network
skipping to change at page 30, line 21 skipping to change at page 32, line 21
with the VNF Manager (VNFM) via the Ve-Vnfm interface with the VNF Manager (VNFM) via the Ve-Vnfm interface
[nfv-framework]. Security Controller can use this interface for the [nfv-framework]. Security Controller can use this interface for the
purpose of the lifecycle management of NSFs. If some NSFs need to be purpose of the lifecycle management of NSFs. If some NSFs need to be
instantiated to enforce security policies in the I2NSF framework, instantiated to enforce security policies in the I2NSF framework,
Security Controller could request the VNFM to instantiate them Security Controller could request the VNFM to instantiate them
through the Ve-Vnfm interface. Or if an NSF, running as a VNF, is through the Ve-Vnfm interface. Or if an NSF, running as a VNF, is
not used by any traffic flows for a time period, Security Controller not used by any traffic flows for a time period, Security Controller
may request deinstantiating it through the interface for efficient may request deinstantiating it through the interface for efficient
resource utilization. resource utilization.
Appendix C. Changes from draft-ietf-i2nsf-registration-interface-dm-03 Appendix C. Changes from draft-ietf-i2nsf-registration-interface-dm-04
The following changes have been made from draft-ietf-i2nsf- The following changes have been made from draft-ietf-i2nsf-
registration-interface-dm-03: registration-interface-dm-04:
o In Section 5.1.1, Figure 3 and sentences are revised to be o This version is revised according to the comments from Reshad
synchronized with the I2NSF Capability YANG Data Model, including Rahman who reviewed this document as a YANG doctor.
IPsec method support.
Appendix D. Acknowledgments Appendix D. Acknowledgments
This work was supported by Institute for Information & communications This work was supported by Institute of Information & Communications
Technology Promotion (IITP) grant funded by the Korea government Technology Planning & Evaluation (IITP) grant funded by the Korea
(MSIP)(No. R-20160222-002755, Cloud based Security Intelligence MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based
Technology Development for the Customized Security Service Security Intelligence Technology Development for the Customized
Provisioning). Security Service Provisioning).
Appendix E. Contributors Appendix E. Contributors
This document is made by the group effort of I2NSF working group. This document is made by the group effort of I2NSF working group.
Many people actively contributed to this document. The following are Many people actively contributed to this document. The following are
considered co-authors: considered co-authors:
o Jinyong Tim Kim (Sungkyunkwan University) o Jinyong Tim Kim (Sungkyunkwan University)
o Chaehong Chung (Sungkyunkwan University) o Chaehong Chung (Sungkyunkwan University)
 End of changes. 88 change blocks. 
358 lines changed or deleted 438 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/