draft-ietf-i2nsf-registration-interface-dm-03.txt   draft-ietf-i2nsf-registration-interface-dm-04.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: September 29, 2019 T. Roh Expires: December 14, 2019 T. Roh
S. Wi S. Wi
Sungkyunkwan University Sungkyunkwan University
J. Park J. Park
ETRI ETRI
March 28, 2019 June 12, 2019
I2NSF Registration Interface YANG Data Model I2NSF Registration Interface YANG Data Model
draft-ietf-i2nsf-registration-interface-dm-03 draft-ietf-i2nsf-registration-interface-dm-04
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
Interface to Network Security Functions (I2NSF) Registration Registration Interface between Security Controller and Developer's
Interface between Security Controller and Developer's Management Management System (DMS) in the Interface to Network Security
System (DMS). The objective of these information and data models is Functions (I2NSF) framework to register Network Security Functions
to support NSF capability registration and query via I2NSF (NSF) of the DMS into the Security Controller. The objective of
Registration Interface. these information and data models is to support NSF capability
registration and query via I2NSF Registration Interface.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Please update these statements within the document with the RFC Please update these statements within the document with the RFC
number to be assigned to this document: number to be assigned to this document:
"This version of this YANG module is part of RFC XXXX;" "This version of this YANG module is part of RFC XXXX;"
"RFC XXXX: I2NSF Registration Interface YANG Data Model" "RFC XXXX: I2NSF Registration Interface YANG Data Model"
skipping to change at page 2, line 7 skipping to change at page 2, line 10
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 September 29, 2019. This Internet-Draft will expire on December 14, 2019.
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 46 skipping to change at page 2, line 49
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 . . . . . . . . . . . . . . . 11
6.2. YANG Data Modules . . . . . . . . . . . . . . . . . . . . 12 6.2. YANG Data Modules . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. XML Example of Registration Interface Data Model . . 19 Appendix A. XML Example of Registration Interface Data Model . . 20
A.1. Example 1: Registration for Capabilities of General A.1. Example 1: Registration for Capabilities of General
Firewall . . . . . . . . . . . . . . . . . . . . . . . . 19
A.2. Example 2: Registration for Capabilities of Time based
Firewall . . . . . . . . . . . . . . . . . . . . . . . . 20 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 20
A.3. Example 3: Registration for Capabilities of Web Filter . 22 A.2. Example 2: Registration for Capabilities of Time based
Firewall . . . . . . . . . . . . . . . . . . . . . . . . 21
A.3. Example 3: Registration for Capabilities of Web Filter . 23
A.4. Example 4: Registration for Capabilities of VoIP/VoLTE A.4. Example 4: Registration for Capabilities of VoIP/VoLTE
Filter . . . . . . . . . . . . . . . . . . . . . . . . . 24 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.5. Example 5: Registration for Capabilities of HTTP and A.5. Example 5: Registration for Capabilities of HTTP and
HTTPS Flood Mitigation . . . . . . . . . . . . . . . . . 25 HTTPS Flood Mitigation . . . . . . . . . . . . . . . . . 26
A.6. Example 6: Query for Capabilities of Time based Firewall 27 A.6. Example 6: Query for Capabilities of Time based Firewall 28
Appendix B. NSF Lifecycle Managmenet in NFV Environments . . . . 29 Appendix B. NSF Lifecycle Managmenet in NFV Environments . . . . 30
Appendix C. Changes from draft-ietf-i2nsf-registration- Appendix C. Changes from draft-ietf-i2nsf-registration-
interface-dm-02 . . . . . . . . . . . . . . . . . . 29 interface-dm-03 . . . . . . . . . . . . . . . . . . 30
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 29 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 30
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 29 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
A number of network security functions may exist in Interface to A number of Network Security Functions (NSF) may exist in the
Network Security Functions (I2NSF) framework [RFC8329]. Since these Interface to Network Security Functions (I2NSF) framework [RFC8329].
NSFs likely have different security capabilities, it is important to Since each of these NSFs likely has different security capabilities
register the security capabilities of each NSF into the security from each other, it is important to register the security
controller. In addition, it is required to search NSFs of some capabilities of the NSF into the security controller. In addition,
required security capabilities on demand. As an example, if it is required to search NSFs of some required security capabilities
additional security capabilities are required to serve some security on demand. As an example, if additional security capabilities are
service request(s) from an I2NSF user, the security controller should required to serve some security service request(s) from an I2NSF
be able to request the DMS for NSFs that have the required security user, the security controller should be able to request the DMS for
capabilities. NSFs that have the required security capabilities.
This document describes an information model (see Section 5) and a This document describes an information model (see Section 5) and a
YANG [RFC7950] data model (see Section 6) for the I2NSF Registration YANG [RFC7950] data model (see Section 6) for the I2NSF Registration
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 and NSF initiation request via the registration and query via the registration interface. It also
registration interface. It also describes the operations which describes the operations which should be performed by the security
should be performed by the security controller and the DMS via the controller and the DMS via the Registration Interface using 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
This document uses the following terms defined in This document uses the following terms defined in
[i2nsf-terminology], [capability-im], [RFC8329], [i2nsf-terminology], [capability-dm], [RFC8329],
[nsf-triggered-steering], [supa-policy-data-model], and [supa-policy-data-model], and [supa-policy-info-model]
[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.
[nsf-triggered-steering]
o Data Model: A data model is a representation of concepts of o Data Model: A data model is a representation of concepts of
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.
skipping to change at page 5, line 25 skipping to change at page 5, line 23
via the registration interface. DMS also uses the registration via the registration interface. DMS also uses the registration
interface to update the capabilities of the NSFs registered interface to update the capabilities of the NSFs registered
previously. previously.
2) In case that Security Controller fails to find any registered NSF 2) In case that Security Controller fails to find any registered NSF
that can provide some required capabilities, Security Controller that can provide some required capabilities, Security Controller
queries DMS about NSF(s) having the required capabilities via the queries DMS about NSF(s) having the required capabilities via the
registration interface. registration interface.
Figure 1 shows the information model of the I2NSF registration Figure 1 shows the information model of the I2NSF registration
interface, which consists of three submodels: NSF capability interface, which consists of two submodels: NSF capability
registration, and NSF capability query. Each submodel is used for registration and NSF capability query. Each submodel is used for the
the operations listed above. The remainder of this section will operations listed above. The remainder of this section will provide
provide more in-depth explanations of each submodel. in-depth explanations of each submodel.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I2NSF Registration Interface Information Model | | I2NSF Registration Interface Information Model |
| | | |
| +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |
| | NSF Capability | | NSF Capability | | | | NSF Capability | | NSF Capability | |
| | Registration | | Query | | | | Registration | | Query | |
| +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 28 skipping to change at page 6, line 25
| Name | | Information | | Information | | Name | | Information | | Information |
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
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-im], we share the same security capabilities: Network in [capability-dm], we share the same I2NSF security capabilities:
Security Capabilities, Content Security Capabilities, and Attack Time Capabilities, Event Capabilities, Condition Capabilities, Action
Mitigation Capabilities. Also, NSF Capability Information Capabilities, Resolution Strategy Capabilities, Default Action
Capabilities, and IPsec Method. Also, NSF Capability Information
additionally contains the performance capabilities of an NSF as shown additionally contains the performance capabilities of an NSF as shown
in Figure 3. in Figure 3.
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
| NSF Capability | | NSF Capability |
| Information | | Information |
+-+-+-+-^-+-+-+-+-+ +-+-+-+-^-+-+-+-+-+
| |
| |
+---------------+-------+--------------+ +----------------------+----------------------+
| | | | |
| | | | |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Network Security | |Content Security | | | I2NSF | | Performance |
| Capabilities | | Capabilities | | | Capabilities | | Capabilities |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| |
+-----------------------+--------------+ +--+-----------------+------------------+-----------------+-------+
| | | | | | |
| | +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | Time | | Event | | Condition | | Action | |
| Performance | |Attack Mitigation| | Capabilities| | Capabilities| | Capabilities| | Capabilities| |
| Capabilities | | Capabilities | +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |
+----------------------+--------------------+-------+
| | |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+
| Resolution | | Default | | IPsec |
| Strategy | | Action | | Method |
| Capabilities| | Capabilities| +-+-+-+-+-+-+
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
Figure 3: NSF Capability Information Figure 3: NSF Capability Information
5.1.1.1. Performance Capabilities 5.1.1.1. Performance Capabilities
This information represents the processing capability of an NSF. This information represents the processing capability of an NSF.
This information can be used to determine whether the NSF is in This information can be used to determine whether the NSF is in
congestion by comparing this with the workload that the NSF currently congestion by comparing this with the workload that the NSF currently
undergoes. Moreover, this information can specify an available undergoes. Moreover, this information can specify an available
amount of each type of resources such as processing power which are amount of each type of resources such as processing power which are
skipping to change at page 8, line 45 skipping to change at page 8, line 45
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,
and sends DMS a query about which NSF(s) can provide these and sends DMS a query about which NSF(s) can provide these
capabilities. capabilities.
6. Data Model 6. Data Model
6.1. YANG Tree Diagram 6.1. YANG Tree Diagram
This section provides an overview of the YANG Tree diagram of the This section provides the YANG Tree diagram of the I2NSF registration
I2NSF registration interface. interface.
6.1.1. Definition of Symbols in Tree Diagrams 6.1.1. Definition of Symbols in Tree Diagrams
A simplified graphical representation of the data model is used in A simplified graphical representation of the data model is used in
this section. The meaning of the symbols used in the following this section. The meaning of the symbols used in the following
diagrams [RFC8431] is as follows: diagrams [RFC8431] is as follows:
Brackets "[" and "]" enclose list keys. Brackets "[" and "]" enclose list keys.
Abbreviations before data node names: "rw" means configuration Abbreviations before data node names: "rw" means configuration
skipping to change at page 10, line 45 skipping to change at page 10, line 45
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 [i2nsf-capability-dm]. module defined in [capability-dm].
6.1.3. NSF Capability Information 6.1.3. NSF Capability Information
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 [i2nsf-capability-dm]. The i2nsf-nsf-performance-capability is in [capability-dm]. The i2nsf-nsf-performance-capability is used to
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.
NSF Performance Capability NSF Performance Capability
+--rw i2nsf-nsf-performance-capability +--rw i2nsf-nsf-performance-capability
+--rw processing +--rw processing
| +--rw processing-average uint16 | +--rw processing-average uint16
skipping to change at page 12, line 18 skipping to change at page 12, line 18
+--rw nsf-address inet:ipv4-address +--rw nsf-address inet:ipv4-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 introduces a YANG data module for the information model This section provides YANG modules of the data model for the
of the required data for the registration interface between Security registration interface between Security Controller and Developer's
Controller and Developer's Management System, as defined in Management System, as defined in Section 5.
Section 5.
<CODE BEGINS> file "ietf-i2nsf-reg-interface@2019-03-28.yang" <CODE BEGINS> file "ietf-i2nsf-reg-interface@2019-06-12.yang"
module ietf-i2nsf-reg-interface{ module ietf-i2nsf-reg-interface{
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"; "urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface";
prefix "iiregi"; prefix "iiregi";
import ietf-inet-types{ import ietf-inet-types{
prefix inet; prefix inet;
reference "RFC 6991"; reference "RFC 6991";
skipping to change at page 13, line 34 skipping to change at page 13, line 32
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2019-03-28 { revision 2019-06-12 {
description "The third revision"; description "The third revision";
reference reference
"RFC XXXX: I2NSF Registration Interface YANG Data Model"; "RFC XXXX: I2NSF Registration Interface YANG Data Model";
} }
rpc i2nsf-nsf-capability-query { rpc i2nsf-nsf-capability-query {
description description
"Capability information that the "Capability information that the
Security Controller Security Controller
sends to the DMS"; sends to the DMS";
input{ input{
skipping to change at page 17, line 12 skipping to change at page 17, line 12
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: iiregi
Reference: RFC XXXX Reference: RFC XXXX
8. Security Considerations 8. Security Considerations
This document introduces no additional security threats and SHOULD The YANG module specified in this document defines a data schema
follow the security requirements as stated in [RFC8329]. designed to be accessed through network management protocols such as
NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is
the secure transport layer, and the required secure transport is
Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS,
and the required secure transport is TLS [RFC8446].
The NETCONF access control model [RFC8341] provides a means of
restricting access to specific NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs toIndicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2004. DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", RFC 6087, January 2011. Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
January 2011, <https://www.rfc-editor.org/info/rfc6087>.
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
July 2013. and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
RFC 7950, August 2016. Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC8340] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 8340, March 2018. RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
9.2. Informative References 9.2. Informative References
[capability-im] [capability-dm]
Xia, L., Strassner, J., Basile, C., and D. Lopez, Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin,
"Information Model of NSFs Capabilities", draft-i2nsf- "I2NSF Capability YANG Data Model", draft-ietf-i2nsf-
capability-04 (work in progress), October 2018. capability-data-model-05 (work in progress), June 2019.
[draft-ietf-nvo3-vxlan-gpe] [draft-ietf-nvo3-vxlan-gpe]
Maino, Ed., F., Kreeger, Ed., L., and U. Elzur, Ed., Maino, Ed., F., Kreeger, Ed., L., and U. Elzur, Ed.,
"Generic Protocol Extension for VXLAN", draft-ietf-nvo3- "Generic Protocol Extension for VXLAN", draft-ietf-nvo3-
vxlan-gpe-06 (work in progress), April 2018. vxlan-gpe-06 (work in progress), April 2018.
[i2nsf-capability-dm]
Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin,
"I2NSF Capability YANG Data Model", draft-ietf-i2nsf-
capability-data-model-02 (work in progress), November
2018.
[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-07 (work in
progress), January 2019. progress), January 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.
[nsf-triggered-steering]
Hyun, S., Jeong, J., Park, J., and S. Hares, "Service
Function Chaining-Enabled I2NSF Architecture", draft-hyun-
i2nsf-nsf-triggered-steering-06 (work in progress), July
2018.
[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.
[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
skipping to change at page 19, line 8 skipping to change at page 20, line 8
[supa-policy-info-model] [supa-policy-info-model]
Strassner, J., Halpern, J., and S. van der Meer, "Generic Strassner, J., Halpern, J., and S. van der Meer, "Generic
Policy Information Model for Simplified Use of Policy Policy Information Model for Simplified Use of Policy
Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
model-03 (work in progress), May 2017. model-03 (work in progress), May 2017.
Appendix A. XML Example of Registration Interface Data Model Appendix A. XML Example of Registration Interface Data Model
This section describes XML examples of the I2NSF Registration This section describes XML examples of the I2NSF Registration
Interface data model in five NSF Registration examples and one NSF Interface data model under the assumption of registering several
Capability Query example. types of NSFs and querying NSF capability.
A.1. Example 1: Registration for Capabilities of General Firewall A.1. Example 1: Registration for Capabilities of General Firewall
This section shows a configuration example for capabilities This section shows an XML example for registering the capabilities of
registration of general firewall. general 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"
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>general_firewall_capability</nsf-name> <nsf-name>general_firewall_capability</nsf-name>
<nsf-capability-info> <nsf-capability-info>
<i2nsf-capability> <i2nsf-capability>
<condition-capabilities> <condition-capabilities>
<generic-nsf-capabilities> <generic-nsf-capabilities>
skipping to change at page 19, line 40 skipping to change at page 20, line 40
</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>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>
skipping to change at page 20, line 20 skipping to change at page 21, line 20
<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> <nsf-address>221.159.112.100</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 registration of general Figure 12 shows the configuration XML for registering the general
firewall and its capabilities are as follows. firewall and its capabilities as follows.
1. The instance name of the NSF is general_firewall. 1. The instance name of the NSF is general_firewall.
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 control 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.
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 221.159.112.100.
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 a configuration example for capabilities This section shows an XML example for registering the capabilities of
registration 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"
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>time_based_firewall_capability</nsf-name> <nsf-name>time_based_firewall_capability</nsf-name>
<nsf-capability-info> <nsf-capability-info>
<i2nsf-capability> <i2nsf-capability>
<time-capabilities>absolute-time</time-capabilities> <time-capabilities>absolute-time</time-capabilities>
<time-capabilities>periodic-time</time-capabilities> <time-capabilities>periodic-time</time-capabilities>
skipping to change at page 21, line 25 skipping to change at page 22, line 25
</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>ike</ipsec-method> <ipsec-method>capa:ike</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>
skipping to change at page 22, line 7 skipping to change at page 23, line 7
<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> <nsf-address>221.159.112.110</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 registration of time based Figure 13 shows the configuration XML for registering the time-based
firewall and its capabilities are as follows. firewall and its capabilities as follows.
1. The instance name of the NSF is time_based_firewall. 1. The instance name of the NSF is time_based_firewall.
2. The NSF can execute 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 control 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.
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 221.159.112.110.
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 a configuration example for capabilities This section shows an XML example for registering the capabilities of
registration 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"
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>web_filter_capability</nsf-name> <nsf-name>web_filter_capability</nsf-name>
<nsf-capability-info> <nsf-capability-info>
<i2nsf-capability> <i2nsf-capability>
<condition-capabilities> <condition-capabilities>
<advanced-nsf-capabilities> <advanced-nsf-capabilities>
skipping to change at page 23, line 6 skipping to change at page 24, line 6
</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>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>
skipping to change at page 23, line 35 skipping to change at page 24, line 35
<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> <nsf-address>221.159.112.120</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 registration of 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 control 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.
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 221.159.112.120.
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 a configuration example for capabilities This section shows an XML example for registering the capabilities of
registration 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>
skipping to change at page 24, line 32 skipping to change at page 25, line 32
</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>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>
skipping to change at page 25, line 12 skipping to change at page 26, line 12
<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> <nsf-address>221.159.112.130</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 registration of 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 control 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.
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 221.159.112.130.
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 a configuration example for capabilities This section shows an XML example for registering the capabilities of
registration 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>
skipping to change at page 26, line 14 skipping to change at page 27, line 14
</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>ike</ipsec-method> <ipsec-method>capa:ike</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>
skipping to change at page 26, line 46 skipping to change at page 27, line 46
</nsf-instance-name> </nsf-instance-name>
<nsf-address>221.159.112.140</nsf-address> <nsf-address>221.159.112.140</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 registration of VoIP/VoLTE Figure 16 shows the configuration XML for registering the http and
filter 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 control 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.
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 221.159.112.140.
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 a configuration example for capabilities query 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>
skipping to change at page 28, line 28 skipping to change at page 29, line 28
</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>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> <nsf-address>221.159.223.250</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 configuration of input data and output data XML Figure 17 shows the XML configuration for querying the capabilities
for nsf capability query of 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
functions (VNFs). Security Controller can be implemented as an functions (VNFs). Security Controller can be implemented as an
Element Management (EM) of the NFV architecture, and is connected Element Management (EM) of the NFV architecture, and is connected
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-02 Appendix C. Changes from draft-ietf-i2nsf-registration-interface-dm-03
The following changes have been made from draft-ietf-i2nsf- The following changes have been made from draft-ietf-i2nsf-
registration-interface-dm-02: registration-interface-dm-03:
o Appendix A. added an IPsec field in the XML examples of the o In Section 5.1.1, Figure 3 and sentences are revised to be
registration interface data model for five NSF Registration synchronized with the I2NSF Capability YANG Data Model, including
examples and one NSF Capability Query example. IPsec method support.
Appendix D. Acknowledgments Appendix D. 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 government(MSIP) Technology Promotion (IITP) grant funded by the Korea government
(No.R-20160222-002755, Cloud based Security Intelligence Technology (MSIP)(No. R-20160222-002755, Cloud based Security Intelligence
Development for the Customized Security Service Provisioning). Technology Development for the Customized 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 Susan Hares (Huawei) o Susan Hares (Huawei)
o Diego R. Lopez (Telefonica) o Diego R. Lopez (Telefonica)
o Chung, Chaehong (Sungkyunkwan University)
Authors' Addresses Authors' Addresses
Sangwon Hyun Sangwon Hyun
Department of Computer Engineering Department of Computer Engineering
Chosun University Chosun University
309, Pilmun-daero, Dong-gu 309, Pilmun-daero, Dong-gu
Gwangju, Jeollanam-do 61452 Gwangju, Jeollanam-do 61452
Republic of Korea Republic of Korea
EMail: shyun@chosun.ac.kr EMail: shyun@chosun.ac.kr
Jaehoon Paul Jeong Jaehoon Paul Jeong
Department of Software Department of Computer Science and 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
Phone: +82 31 299 4957 Phone: +82 31 299 4957
Fax: +82 31 290 7996 Fax: +82 31 290 7996
EMail: pauljeong@skku.edu EMail: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Taekyun Roh Taekyun Roh
Electrical Computer Engineering Department of Electronic, Electrical and 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
Phone: +82 31 290 7222 Phone: +82 31 290 7222
Fax: +82 31 299 6673 Fax: +82 31 299 6673
EMail: tkroh0198@skku.edu EMail: tkroh0198@skku.edu
Sarang Wi Sarang Wi
Electrical Computer Engineering Department of Electronic, Electrical and 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
Phone: +82 31 290 7222 Phone: +82 31 290 7222
Fax: +82 31 299 6673 Fax: +82 31 299 6673
EMail: dnl9795@skku.edu EMail: dnl9795@skku.edu
Jung-Soo Park Jung-Soo Park
Electronics and Telecommunications Research Institute Electronics and Telecommunications Research Institute
 End of changes. 69 change blocks. 
159 lines changed or deleted 192 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/