draft-ietf-i2nsf-registration-interface-dm-08.txt   draft-ietf-i2nsf-registration-interface-dm-09.txt 
I2NSF Working Group S. Hyun I2NSF Working Group S. Hyun, Ed.
Internet-Draft Myongji University Internet-Draft Myongji University
Intended status: Standards Track J. Jeong Intended status: Standards Track J. Jeong, Ed.
Expires: October 1, 2020 T. Roh Expires: March 2, 2021 T. Roh
S. Wi S. Wi
Sungkyunkwan University Sungkyunkwan University
J. Park J. Park
ETRI ETRI
March 30, 2020 August 29, 2020
I2NSF Registration Interface YANG Data Model I2NSF Registration Interface YANG Data Model
draft-ietf-i2nsf-registration-interface-dm-08 draft-ietf-i2nsf-registration-interface-dm-09
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 with 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.
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 October 1, 2020. This Internet-Draft will expire on March 2, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . 12 6.1.4. NSF Access Information . . . . . . . . . . . . . . . 12
6.2. YANG Data Modules . . . . . . . . . . . . . . . . . . . . 12 6.2. YANG Data Modules . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. XML Example of Registration Interface Data Model . . 22 Appendix A. XML Examples of I2NSF Registration Interface Data
A.1. Example 1: Registration for Capabilities of General Model . . . . . . . . . . . . . . . . . . . . . . . 22
A.1. Example 1: Registration for the Capabilities of a General
Firewall . . . . . . . . . . . . . . . . . . . . . . . . 22 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 22
A.2. Example 2: Registration for Capabilities of Time based A.2. Example 2: Registration for the Capabilities of a Time-
Firewall . . . . . . . . . . . . . . . . . . . . . . . . 23 based Firewall . . . . . . . . . . . . . . . . . . . . . 25
A.3. Example 3: Registration for Capabilities of Web Filter . 25 A.3. Example 3: Registration for the Capabilities of a Web
A.4. Example 4: Registration for Capabilities of VoIP/VoLTE Filter . . . . . . . . . . . . . . . . . . . . . . . . . 29
Filter . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.4. Example 4: Registration for the Capabilities of a
A.5. Example 5: Registration for Capabilities of HTTP and VoIP/VoLTE Filter . . . . . . . . . . . . . . . . . . . . 32
HTTPS Flood Mitigation . . . . . . . . . . . . . . . . . 28 A.5. Example 5: Registration for the Capabilities of an HTTP
A.6. Example 6: Query for Capabilities of Time based Firewall 30 and HTTPS Flood Mitigator . . . . . . . . . . . . . . . . 35
Appendix B. NSF Lifecycle Management in NFV Environments . . . . 32 A.6. Example 6: Query for the Capabilities of a Time-based
Appendix C. Changes from draft-ietf-i2nsf-registration- Firewall . . . . . . . . . . . . . . . . . . . . . . . . 38
interface-dm-07 . . . . . . . . . . . . . . . . . . 32 Appendix B. NSF Lifecycle Management in NFV Environments . . . . 41
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 32 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 41
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 33 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
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 with 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
required to serve some security service request(s) from an I2NSF required to serve some security service request(s) from an I2NSF
user, the security controller should be able to request the DMS for user, the security controller should be able to request the DMS for
NSFs that have the required security 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 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] [RFC8174] when, and only when, they appear in all capitals, [RFC2119] when, and only when, they appear in all capitals, as shown
as shown here. here.
3. Terminology 3. Terminology
This document uses the following terms defined in This document uses the following terms defined in [RFC8329] and
[i2nsf-terminology], [capability-dm], [RFC8329], [I-D.ietf-i2nsf-capability-data-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 a specific treatment of received packets. A Network Security for a 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.
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.
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]
o YANG: This document follows the guidelines of [RFC8407], 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
skipping to change at page 5, line 34 skipping to change at page 5, line 34
| +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |
| | NSF Capability | | NSF Capability | | | | NSF Capability | | NSF Capability | |
| | Registration | | Query | | | | Registration | | Query | |
| +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: I2NSF Registration Interface Information Model Figure 1: I2NSF Registration Interface Information Model
5.1. NSF Capability Registration 5.1. NSF Capability Registration
This submodel is used by DMS to register an NSF to Security This submodel is used by DMS to register an NSF with Security
Controller. Figure 2 shows how this submodel is constructed. The Controller. Figure 2 shows how this submodel is constructed. The
most important part in Figure 2 is the NSF capability, and this most important part in Figure 2 is the NSF capability, and this
specifies the set of capabilities that the NSF to be registered can specifies the set of capabilities that the NSF to be registered can
offer. The NSF Name contains a unique name of this NSF with the offer. The NSF Name contains a unique name of this NSF with the
specified set of capabilities. When registering the NSF, DMS specified set of capabilities. When registering the NSF, DMS
additionally includes the network access information of the NSF which additionally includes the network access information of the NSF which
is required to enable network communications with the NSF. is required to enable network communications with the NSF.
The following will further explain the NSF capability information and The following will further explain the NSF capability information and
the NSF access information in more detail. the NSF access information in more detail.
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
| NSF Capability | | NSF Capability |
| Registration | | Registration |
+-+-+-+-^-+-+-+-+-+ +-+-+-+-+^+-+-+-+-+
| |
+---------------------+--------------------+ +---------------------+--------------------+
| | | | | |
| | | | | |
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
| NSF | | NSF Capability| | NSF Access | | NSF | | NSF Capability| | NSF Access |
| 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 defined an NSF. Following the information model of NSF capabilities defined
in [capability-dm], we share the same I2NSF security capabilities: in [I-D.ietf-i2nsf-capability-data-model], we share the same I2NSF
Time Capabilities, Event Capabilities, Condition Capabilities, Action security capabilities: Time Capabilities, Event Capabilities,
Capabilities, Resolution Strategy Capabilities, Default Action Condition Capabilities, Action Capabilities, Resolution Strategy
Capabilities, and IPsec Method [i2nsf-ipsec]. Also, NSF Capability Capabilities, Default Action Capabilities, and IPsec Method
[I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. Also, NSF Capability
Information additionally contains the performance capabilities of an Information additionally contains the performance capabilities of an
NSF as shown in Figure 3. NSF as shown in Figure 3.
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
| NSF Capability | | NSF Capability |
| Information | | Information |
+-+-+-+-^-+-+-+-+-+ +-+-+-+-^-+-+-+-+-+
| |
| |
+----------------------+----------------------+ +----------------------+----------------------+
| | | |
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| I2NSF | | Performance | | I2NSF | | Performance |
| Capabilities | | Capabilities | | Capabilities | | Capabilities |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| |
+--+-----------------+------------------+-----------------+-------+ +------+--------------+-----------------+-----------------+-------+
| | | | | | | | | |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ |
| Time | | Event | | Condition | | Action | | | Time | | Event | | Condition | | Action | |
| Capabilities| | Capabilities| | Capabilities| | Capabilities| | | Capabilities| | Capabilities| | Capabilities| | Capabilities| |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ |
| |
+----------------------+--------------------+-------+ +---------------------+---------------------+-------+
| | | | | |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+
| Resolution | | Default | | IPsec | | Resolution | | Default | | IPsec |
| Strategy | | Action | | Method | | Strategy | | Action | | Method |
| Capabilities| | Capabilities| +-+-+-+-+-+-+ | 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.
Assuming that the current workload status of each NSF is being Assuming that the current workload status of each NSF is being
collected through NSF monitoring [i2nsf-monitoring], this capability collected through NSF monitoring
[I-D.ietf-i2nsf-nsf-monitoring-data-model], this capability
information of the NSF can be used to determine whether the NSF is in information of the NSF can be used to determine whether the NSF is in
congestion by comparing it with the current workload of the NSF. congestion by comparing it with the current workload of the NSF.
Moreover, this information can specify an available amount of each Moreover, this information can specify an available amount of each
type of resource, such as processing power which are available on the type of resource, such as processing power which are available on the
NSF. (The registration interface can control the usages and NSF. (The registration interface can control the usages and
limitations of the created instance and make the appropriate request limitations of the created instance and make the appropriate request
according to the status.) As illustrated in Figure 4, this according to the status.) As illustrated in Figure 4, this
information consists of two items: Processing and Bandwidth. information consists of two items: Processing and Bandwidth.
Processing information describes the NSF's available processing Processing information describes the NSF's available processing
power. Bandwidth describes the information about available network power. Bandwidth describes the information about available network
skipping to change at page 8, line 26 skipping to change at page 8, line 26
| Processing | | Bandwidth | | Processing | | Bandwidth |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
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) [RFC7348], Generic Protocol Extension for VXLAN (VXLAN-GPE)
[nvo3-vxlan-gpe], Generic Route Encapsulation (GRE), Ethernet etc.). [I-D.ietf-nvo3-vxlan-gpe], Generic Route Encapsulation (GRE),
In this document, NSF Access Information is used to identify a Ethernet etc.). In this document, NSF Access Information is used to
specific NSF instance (i.e. NSF Access Information is the identify a 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 11, line 7 skipping to change at page 11, line 4
+--rw port +--rw port
Figure 7: YANG Tree of NSF Capability Query Module Figure 7: YANG Tree of NSF Capability Query Module
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 [I-D.ietf-i2nsf-capability-data-model].
6.1.3. NSF Capability Information 6.1.3. NSF Capability Information
This section expands the nsf-capability-info in Figure 6 and This section expands the nsf-capability-info in Figure 6 and
Figure 7. Figure 7.
NSF Capability Information NSF Capability Information
+--rw nsf-capability-info +--rw nsf-capability-info
+--rw security-capability +--rw security-capability
| uses ietf-i2nsf-capability | uses ietf-i2nsf-capability
+--rw performance-capability +--rw performance-capability
| uses nsf-performance-capability | uses 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 performance-capability is used to specify in [I-D.ietf-i2nsf-capability-data-model]. The performance-
the performance capability of an NSF. capability is used to 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 nsf-performance-capability in Figure 8. This section expands the nsf-performance-capability in Figure 8.
NSF Performance Capability NSF Performance Capability
+--rw nsf-performance-capability +--rw nsf-performance-capability
+--rw processing +--rw processing
| +--rw processing-average uint16 | +--rw processing-average uint16
| +--rw processing-peak uint16 | +--rw processing-peak uint16
skipping to change at page 12, line 18 skipping to change at page 12, line 18
NSF Access Information NSF Access Information
+--rw nsf-access-info +--rw nsf-access-info
+--rw capability-name string +--rw capability-name string
+--rw ip inet:ip-address +--rw ip inet:ip-address
+--rw port inet:port-number +--rw port 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. The field of
ip can have either an IPv4 address or an IPv6 address.
6.2. YANG Data Modules 6.2. YANG Data Modules
This section provides YANG modules of the data model for the This section provides a YANG module 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@2020-03-30.yang" This YANG module imports from [RFC6991], and makes a reference to
[I-D.ietf-i2nsf-capability-data-model].
<CODE BEGINS> file "ietf-i2nsf-reg-interface@2020-08-29.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"; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface";
prefix nsfreg; prefix nsfreg;
// RFC Ed.: replace occurences of XXXX with actual RFC number and // RFC Ed.: replace occurences of XXXX with actual RFC number and
// remove this note // remove this note
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference "RFC 6991"; reference "RFC 6991";
} }
import ietf-i2nsf-capability { import ietf-i2nsf-capability {
prefix capa; prefix cap;
// RFC Ed.: replace YYYY with actual RFC number of // RFC Ed.: replace YYYY with actual RFC number of
// draft-ietf-i2nsf-capability-data-model and remove this note. // draft-ietf-i2nsf-capability-data-model and remove this note.
reference "RFC YYYY: I2NSF Capability YANG Data Model"; reference "RFC YYYY: I2NSF Capability YANG Data Model";
} }
organization organization
"IETF I2NSF (Interface to Network Security Functions) "IETF I2NSF (Interface to Network Security Functions)
Working Group"; Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/i2nsf> "WG Web: <http://tools.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org> WG List: <mailto:i2nsf@ietf.org>
Editor: Sangwon Hyun Editor: Sangwon Hyun
<mailto:shyun@mju.ac.kr> <mailto:shyun@mju.ac.kr>
skipping to change at page 13, line 11 skipping to change at page 13, line 14
organization organization
"IETF I2NSF (Interface to Network Security Functions) "IETF I2NSF (Interface to Network Security Functions)
Working Group"; Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/i2nsf> "WG Web: <http://tools.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org> WG List: <mailto:i2nsf@ietf.org>
Editor: Sangwon Hyun Editor: Sangwon Hyun
<mailto:shyun@mju.ac.kr> <mailto:shyun@mju.ac.kr>
Editor: Jaehoon Paul Jeong Editor: Jaehoon Paul Jeong
<mailto:pauljeong@skku.edu> <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>";
description description
"This module defines a YANG data model for I2NSF "This module defines a YANG data model for I2NSF
registration interface. Registration Interface.
Copyright (c) 2020 IETF Trust and the persons Copyright (c) 2020 IETF Trust and the persons
identified as authors of the code. All rights reserved. identified as authors of the code. All rights reserved.
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.";
// RFC Ed.: replace XXXX with actual RFC number and remove // RFC Ed.: replace XXXX with actual RFC number and remove
// this note // this note
revision "2020-03-30" { revision "2020-08-29" {
description "Initial revision"; description "Initial revision";
reference reference
"RFC XXXX: I2NSF Registration Interface YANG Data Model"; "RFC XXXX: I2NSF Registration Interface YANG Data Model";
// RFC Ed.: replace XXXX with actual RFC number and remove // RFC Ed.: replace XXXX with actual RFC number and remove
// this note // this note
} }
grouping nsf-performance-capability { grouping nsf-performance-capability {
description description
"Description of the performance capabilities of an NSF"; "Description of the performance capabilities of an NSF";
skipping to change at page 15, line 18 skipping to change at page 15, line 17
} }
} }
} }
grouping nsf-capability-info { grouping nsf-capability-info {
description description
"Capability description of an NSF"; "Capability description of an NSF";
container security-capability { container security-capability {
description description
"Description of the security capabilities of an NSF"; "Description of the security capabilities of an NSF";
uses capa:nsf-capabilities; uses cap:nsf-capabilities;
// RFC Ed.: replace YYYY with actual RFC number of // RFC Ed.: replace YYYY with actual RFC number of
// draft-ietf-i2nsf-capability-data-model and remove this note. // draft-ietf-i2nsf-capability-data-model and remove this note.
reference "RFC YYYY: I2NSF Capability YANG Data Model"; reference "RFC YYYY: I2NSF Capability YANG Data Model";
} }
container performance-capability { container performance-capability {
description description
"Description of the performance capabilities of an NSF"; "Description of the performance capabilities of an NSF";
uses nsf-performance-capability; uses nsf-performance-capability;
} }
} }
skipping to change at page 15, line 41 skipping to change at page 15, line 40
description description
"Information required to access an NSF"; "Information required to access an NSF";
leaf capability-name { leaf capability-name {
type string; type string;
description description
"Unique name of this NSF's capability"; "Unique name of this NSF's capability";
} }
leaf ip { leaf ip {
type inet:ip-address; type inet:ip-address;
description description
"IPv4/IPv6 address of this NSF"; "Either an IPv4 address or an IPv6 address of this NSF";
} }
leaf port { leaf port {
type inet:port-number; type inet:port-number;
description description
"Port available on this NSF"; "Port available on this NSF";
} }
} }
container nsf-registrations { container nsf-registrations {
description description
skipping to change at page 16, line 37 skipping to change at page 16, line 36
} }
rpc nsf-capability-query { rpc nsf-capability-query {
description description
"Description of the capabilities that the "Description of the capabilities that the
Security Controller requests to the DMS"; Security Controller requests to the DMS";
input { input {
container query-nsf-capability { container query-nsf-capability {
description description
"Description of the capabilities to request"; "Description of the capabilities to request";
uses capa:nsf-capabilities; uses cap:nsf-capabilities;
// RFC Ed.: replace YYYY with actual RFC number of // RFC Ed.: replace YYYY with actual RFC number of
// draft-ietf-i2nsf-capability-data-model and remove this note. // draft-ietf-i2nsf-capability-data-model and remove this note.
reference "RFC YYYY: I2NSF Capability YANG Data Model"; reference "RFC YYYY: I2NSF Capability YANG Data Model";
} }
} }
output { output {
container nsf-access-info { container nsf-access-info {
description description
"Network access information of an NSF "Network access information of an NSF
with the requested capabilities"; with the requested capabilities";
skipping to change at page 17, line 16 skipping to change at page 17, line 14
<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][RFC8525]:
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: nsfreg Prefix: nsfreg
Reference: RFC XXXX Reference: RFC XXXX
// RFC Ed.: replace XXXX with actual RFC number and remove // RFC Ed.: replace XXXX with actual RFC number and remove
// this note // this note
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].
skipping to change at page 18, line 10 skipping to change at page 18, line 6
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
o nsf-registrations: The attacker may exploit this to register a o nsf-registrations: The attacker may exploit this to register a
compromised or malicious NSF instead of a legitimate NSF to the compromised or malicious NSF instead of a legitimate NSF with the
Security Controller. Security Controller.
o nsf-performance-capability: The attacker may provide incorrect o nsf-performance-capability: The attacker may provide incorrect
information of the performance capability of any target NSF by information of the performance capability of any target NSF by
illegally modifying this. illegally modifying this.
o nsf-capability-info: The attacker may provide incorrect o nsf-capability-info: The attacker may provide incorrect
information of the security capability of any target NSF by information of the security capability of any target NSF by
illegally modifying this. illegally modifying this.
skipping to change at page 19, line 13 skipping to change at page 19, line 9
its sensitivity/vulnerability: its sensitivity/vulnerability:
o nsf-capability-query: The attacker may exploit this RPC operation o nsf-capability-query: The attacker may exploit this RPC operation
to deteriorate the availability of the DMS and/or gather the to deteriorate the availability of the DMS and/or gather the
information of some interested NSFs from the DMS. information of some interested NSFs from the DMS.
9. References 9. References
9.1. Normative References 9.1. Normative References
[capability-dm] [I-D.ietf-i2nsf-capability-data-model]
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), July 2019. capability-data-model-08 (work in progress), August 2020.
[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,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849,
DOI 10.17487/RFC3849, July 2004,
<https://www.rfc-editor.org/info/rfc3849>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737,
DOI 10.17487/RFC5737, January 2010,
<https://www.rfc-editor.org/info/rfc5737>.
[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, DOI 10.17487/RFC6087, Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
January 2011, <https://www.rfc-editor.org/info/rfc6087>. January 2011, <https://www.rfc-editor.org/info/rfc6087>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
skipping to change at page 20, line 28 skipping to change at page 20, line 43
[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 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", BCP 216, RFC 8407, Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018, DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>. <https://www.rfc-editor.org/info/rfc8407>.
[RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,
S., and N. Bahadur, "A YANG Data Model for the Routing
Information Base (RIB)", RFC 8431, DOI 10.17487/RFC8431,
September 2018, <https://www.rfc-editor.org/info/rfc8431>.
[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 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", RFC 8525,
DOI 10.17487/RFC8525, March 2019,
<https://www.rfc-editor.org/info/rfc8525>.
[i2nsf-ipsec] 9.2. Informative References
Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-
Garcia, "Software-Defined Networking (SDN)-based IPsec
Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow-
protection-07 (work in progress), August 2019.
[i2nsf-monitoring] [I-D.ietf-i2nsf-nsf-monitoring-data-model]
Jeong, J., Chung, C., Hares, S., Xia, L., and H. Birkholz, Jeong, J., Chung, C., Hares, S., Xia, L., and H. Birkholz,
"I2NSF NSF Monitoring YANG Data Model", draft-ietf-i2nsf- "I2NSF NSF Monitoring YANG Data Model", draft-ietf-i2nsf-
nsf-monitoring-data-model-02 (work in progress), November nsf-monitoring-data-model-03 (work in progress), May 2020.
2019.
[i2nsf-terminology] [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia,
Birkholz, "Interface to Network Security Functions (I2NSF) "Software-Defined Networking (SDN)-based IPsec Flow
Terminology", draft-ietf-i2nsf-terminology-08 (work in Protection", draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
progress), July 2019. (work in progress), June 2020.
[I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN (VXLAN-GPE)", draft-ietf-nvo3-vxlan-
gpe-10 (work in progress), July 2020.
[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.
[nvo3-vxlan-gpe] Appendix A. XML Examples of I2NSF Registration Interface Data Model
Maino, Ed., F., Kreeger, Ed., L., and U. Elzur, Ed.,
"Generic Protocol Extension for VXLAN", draft-ietf-nvo3-
vxlan-gpe-09 (work in progress), December 2019.
[RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,
S., and N. Bahadur, "A YANG Data Model for Routing
Information Base (RIB)", RFC 8431, September 2018.
[supa-policy-data-model]
Halpern, J., Strassner, J., and S. van der Meer, "Generic
Policy Data Model for Simplified Use of Policy
Abstractions (SUPA)", draft-ietf-supa-generic-policy-data-
model-04 (work in progress), June 2017.
[supa-policy-info-model]
Strassner, J., Halpern, J., and S. van der Meer, "Generic
Policy Information Model for Simplified Use of Policy
Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
model-03 (work in progress), May 2017.
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 under the assumption of registering several Interface data model under the assumption of registering several
types of NSFs and querying NSF capability. types of NSFs and querying NSF capability.
A.1. Example 1: Registration for Capabilities of General Firewall A.1. Example 1: Registration for the Capabilities of a General Firewall
This section shows an XML example for registering the capabilities of This section shows an XML example for registering the capabilities of
general firewall. a general firewall in either IPv4 networks [RFC5737] or IPv6 networks
[RFC3849].
<nsf-registrations <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:cap="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-information> <nsf-information>
<capability-name>general_firewall_capability</capability-name> <capability-name>general_firewall_capability</capability-name>
<nsf-capability-info> <nsf-capability-info>
<security-capability> <security-capability>
<condition-capabilities> <condition-capabilities>
<generic-nsf-capabilities> <generic-nsf-capabilities>
<ipv4-capa>capa:ipv4-protocol</ipv4-capa> <ipv4-capability>cap:ipv4-protocol</ipv4-capability>
<ipv4-capa>capa:exact-ipv4-address</ipv4-capa> <ipv4-capability>cap:exact-ipv4-address</ipv4-capability>
<ipv4-capa>capa:range-ipv4-address</ipv4-capa> <ipv4-capability>cap:range-ipv4-address</ipv4-capability>
<tcp-capa>capa:exact-tcp-port-num</tcp-capa> <tcp-capability>cap:exact-tcp-port-num</tcp-capability>
<tcp-capa>capa:range-tcp-port-num</tcp-capa> <tcp-capability>cap:range-tcp-port-num</tcp-capability>
</generic-nsf-capabilities> </generic-nsf-capabilities>
</condition-capabilities> </condition-capabilities>
<action-capabilities> <action-capabilities>
<ingress-action-capa>capa:pass</ingress-action-capa> <ingress-action-capability>cap:pass</ingress-action-capability>
<ingress-action-capa>capa:drop</ingress-action-capa> <ingress-action-capability>cap:drop</ingress-action-capability>
<ingress-action-capa>capa:alert</ingress-action-capa> <ingress-action-capability>cap:alert</ingress-action-capability>
<egress-action-capa>capa:pass</egress-action-capa> <egress-action-capability>cap:pass</egress-action-capability>
<egress-action-capa>capa:drop</egress-action-capa> <egress-action-capability>cap:drop</egress-action-capability>
<egress-action-capa>capa:alert</egress-action-capa> <egress-action-capability>cap:alert</egress-action-capability>
</action-capabilities> </action-capabilities>
<ipsec-method>capa:ikeless</ipsec-method> <ipsec-method>cap:ikeless</ipsec-method>
</security-capability> </security-capability>
<performance-capability> <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>
</performance-capability> </performance-capability>
</nsf-capability-info> </nsf-capability-info>
<nsf-access-info> <nsf-access-info>
<capability-name>general_firewall</capability-name> <capability-name>general_firewall</capability-name>
<ip>2001:DB8:8:4::2</ip> <ip>192.0.2.11</ip>
<port>3000</port> <port>3000</port>
</nsf-access-info> </nsf-access-info>
</nsf-information> </nsf-information>
</nsf-registrations> </nsf-registrations>
Figure 12: Configuration XML for Registration of General Firewall Figure 12: Configuration XML for Registration of a General Firewall
in an IPv4 Network
Figure 12 shows the configuration XML for registering the general Figure 12 shows the configuration XML for registering a general
firewall and its capabilities as follows. firewall in an IPv4 network [RFC5737] 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 a protocol, an exact IPv4 address, and a
address for IPv4 packets. range of IPv4 addresses for IPv4 packets.
3. The NSF can inspect exact port number and range port number for 3. The NSF can inspect an exact port number and a range of port
tcp packets. numbers for 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 [i2nsf-ipsec]. Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
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 2001:DB8:8:4::2. 7. The IPv4 address of the NSF is 192.0.2.11.
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 <nsf-registrations
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
xmlns:cap="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-information>
<capability-name>general_firewall_capability</capability-name>
<nsf-capability-info>
<security-capability>
<condition-capabilities>
<generic-nsf-capabilities>
<ipv6-capability>cap:ipv6-protocol</ipv6-capability>
<ipv6-capability>cap:exact-ipv6-address</ipv6-capability>
<ipv6-capability>cap:range-ipv6-address</ipv6-capability>
<tcp-capability>cap:exact-tcp-port-num</tcp-capability>
<tcp-capability>cap:range-tcp-port-num</tcp-capability>
</generic-nsf-capabilities>
</condition-capabilities>
<action-capabilities>
<ingress-action-capability>cap:pass</ingress-action-capability>
<ingress-action-capability>cap:drop</ingress-action-capability>
<ingress-action-capability>cap:alert</ingress-action-capability>
<egress-action-capability>cap:pass</egress-action-capability>
<egress-action-capability>cap:drop</egress-action-capability>
<egress-action-capability>cap:alert</egress-action-capability>
</action-capabilities>
<ipsec-method>cap:ikeless</ipsec-method>
</security-capability>
<performance-capability>
<processing>
<processing-average>1000</processing-average>
<processing-peak>5000</processing-peak>
</processing>
<bandwidth>
<outbound>
<outbound-average>1000</outbound-average>
<outbound-peak>5000</outbound-peak>
</outbound>
<inbound>
<inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak>
</inbound>
</bandwidth>
</performance-capability>
</nsf-capability-info>
<nsf-access-info>
<capability-name>general_firewall</capability-name>
<ip>2001:DB8:0:1::11</ip>
<port>3000</port>
</nsf-access-info>
</nsf-information>
</nsf-registrations>
Figure 13: Configuration XML for Registration of a General Firewall
in an IPv6 Network
In addition, Figure 13 shows the configuration XML for registering a
general firewall in an IPv6 network [RFC3849] and its capabilities as
follows.
1. The instance name of the NSF is general_firewall.
2. The NSF can inspect a protocol, an exact IPv6 address, and a
range of IPv6 addresses for IPv6 packets.
3. The NSF can inspect an exact port number and a range of port
numbers for TCP packets.
4. The NSF can determine whether the packets are allowed to pass,
drop, or alert.
5. The NSF can support IPsec not through IKEv2, but through a
Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
6. The NSF can have processing power and bandwidth.
7. The IPv6 address of the NSF is 2001:DB8:0:1::11.
8. The port of the NSF is 3000.
A.2. Example 2: Registration for the Capabilities of a 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. a time-based firewall in either IPv4 networks [RFC5737] or IPv6
networks [RFC3849].
<nsf-registrations <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:cap="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-information> <nsf-information>
<capability-name>time_based_firewall_capability</capability-name> <capability-name>time_based_firewall_capability</capability-name>
<nsf-capability-info> <nsf-capability-info>
<security-capability> <security-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>
<condition-capabilities> <condition-capabilities>
<generic-nsf-capabilities> <generic-nsf-capabilities>
<ipv4-capa>capa:ipv4-protocol</ipv4-capa> <ipv4-capability>cap:ipv4-protocol</ipv4-capability>
<ipv4-capa>capa:exact-ipv4-address</ipv4-capa> <ipv4-capability>cap:exact-ipv4-address</ipv4-capability>
<ipv4-capa>capa:range-ipv4-address</ipv4-capa> <ipv4-capability>cap:range-ipv4-address</ipv4-capability>
</generic-nsf-capabilities> <tcp-capability>cap:exact-tcp-port-num</tcp-capability>
</condition-capabilities> <tcp-capability>cap:range-tcp-port-num</tcp-capability>
<action-capabilities> </generic-nsf-capabilities>
<ingress-action-capa>capa:pass</ingress-action-capa>
<ingress-action-capa>capa:drop</ingress-action-capa>
<ingress-action-capa>capa:alert</ingress-action-capa>
<egress-action-capa>capa:pass</egress-action-capa>
<egress-action-capa>capa:drop</egress-action-capa>
<egress-action-capa>capa:alert</egress-action-capa>
</action-capabilities>
<ipsec-method>capa:ike</ipsec-method>
</security-capability>
<performance-capability>
<processing>
<processing-average>1000</processing-average>
<processing-peak>5000</processing-peak>
</processing>
<bandwidth>
<outbound>
<outbound-average>1000</outbound-average>
<outbound-peak>5000</outbound-peak>
</outbound>
<inbound>
<inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak>
</inbound>
</bandwidth>
</performance-capability>
</nsf-capability-info>
<nsf-access-info>
<capability-name>time_based_firewall</capability-name>
<ip>2001:DB8:8:4::3</ip>
<port>3000</port>
</nsf-access-info>
</nsf-information>
</nsf-registrations>
Figure 13: Configuration XML for Registration of Time based Firewall </condition-capabilities>
<action-capabilities>
<ingress-action-capability>cap:pass</ingress-action-capability>
<ingress-action-capability>cap:drop</ingress-action-capability>
<ingress-action-capability>cap:alert</ingress-action-capability>
<egress-action-capability>cap:pass</egress-action-capability>
<egress-action-capability>cap:drop</egress-action-capability>
<egress-action-capability>cap:alert</egress-action-capability>
</action-capabilities>
<ipsec-method>cap:ike</ipsec-method>
</security-capability>
<performance-capability>
<processing>
<processing-average>1000</processing-average>
<processing-peak>5000</processing-peak>
</processing>
<bandwidth>
<outbound>
<outbound-average>1000</outbound-average>
<outbound-peak>5000</outbound-peak>
</outbound>
<inbound>
<inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak>
</inbound>
</bandwidth>
</performance-capability>
</nsf-capability-info>
<nsf-access-info>
<capability-name>time_based_firewall</capability-name>
<ip>192.0.2.11</ip>
<port>3000</port>
</nsf-access-info>
</nsf-information>
</nsf-registrations>
Figure 13 shows the configuration XML for registering the time-based Figure 14: Configuration XML for Registration of a Time-based
firewall and its capabilities as follows. Firewall in an IPv4 Network
Figure 14 shows the configuration XML for registering a time-based
firewall in an IPv4 network [RFC5737] 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 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 a protocol, an exact IPv4 address, and a
address for IPv4 packets. range of IPv4 addresses 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 [i2nsf-ipsec]. 5. The NSF can support IPsec through IKEv2
[I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
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 2001:DB8:8:4::3. 7. The IPv4 address of the NSF is 192.0.2.11.
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 <nsf-registrations
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
xmlns:cap="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-information>
<capability-name>time_based_firewall_capability</capability-name>
<nsf-capability-info>
<security-capability>
<time-capabilities>absolute-time</time-capabilities>
<time-capabilities>periodic-time</time-capabilities>
<condition-capabilities>
<generic-nsf-capabilities>
<ipv6-capability>cap:ipv6-protocol</ipv6-capability>
<ipv6-capability>cap:exact-ipv6-address</ipv6-capability>
<ipv6-capability>cap:range-ipv6-address</ipv6-capability>
<tcp-capability>cap:exact-tcp-port-num</tcp-capability>
<tcp-capability>cap:range-tcp-port-num</tcp-capability>
</generic-nsf-capabilities>
</condition-capabilities>
<action-capabilities>
<ingress-action-capability>cap:pass</ingress-action-capability>
<ingress-action-capability>cap:drop</ingress-action-capability>
<ingress-action-capability>cap:alert</ingress-action-capability>
<egress-action-capability>cap:pass</egress-action-capability>
<egress-action-capability>cap:drop</egress-action-capability>
<egress-action-capability>cap:alert</egress-action-capability>
</action-capabilities>
<ipsec-method>cap:ike</ipsec-method>
</security-capability>
<performance-capability>
<processing>
<processing-average>1000</processing-average>
<processing-peak>5000</processing-peak>
</processing>
<bandwidth>
<outbound>
<outbound-average>1000</outbound-average>
<outbound-peak>5000</outbound-peak>
</outbound>
<inbound>
<inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak>
</inbound>
</bandwidth>
</performance-capability>
</nsf-capability-info>
<nsf-access-info>
<capability-name>time_based_firewall</capability-name>
<ip>2001:DB8:0:1::11</ip>
<port>3000</port>
</nsf-access-info>
</nsf-information>
</nsf-registrations>
Figure 15: Configuration XML for Registration of a Time-based
Firewall in an IPv6 Network
In addition, Figure 15 shows the configuration XML for registering a
time-based firewall in an IPv6 network [RFC3849] and its capabilities
as follows.
1. The instance name of the NSF is time_based_firewall.
2. The NSF can enforce the security policy rule according to
absolute time and periodic time.
3. The NSF can inspect a protocol, an exact IPv6 address, and a
range of IPv6 addresses for IPv6 packets.
4. The NSF can determine whether the packets are allowed to pass,
drop, or alert.
5. The NSF can support IPsec through IKEv2
[I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
6. The NSF can have processing power and bandwidth.
7. The IPv6 address of the NSF is 2001:DB8:0:1::11.
8. The port of the NSF is 3000.
A.3. Example 3: Registration for the Capabilities of a 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. a web filter in either IPv4 networks [RFC5737] or IPv6 networks
[RFC3849].
<nsf-registrations <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:cap="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-information> <nsf-information>
<capability-name>web_filter</capability-name> <capability-name>web_filter</capability-name>
<nsf-capability-info> <nsf-capability-info>
<security-capability> <security-capability>
<condition-capabilities> <condition-capabilities>
<advanced-nsf-capabilities> <advanced-nsf-capabilities>
<url-capa>capa:user-defined</url-capa> <url-capability>cap:user-defined</url-capability>
</advanced-nsf-capabilities> </advanced-nsf-capabilities>
</condition-capabilities> </condition-capabilities>
<action-capabilities> <action-capabilities>
<ingress-action-capa>capa:pass</ingress-action-capa> <ingress-action-capability>cap:pass</ingress-action-capability>
<ingress-action-capa>capa:drop</ingress-action-capa> <ingress-action-capability>cap:drop</ingress-action-capability>
<ingress-action-capa>capa:alert</ingress-action-capa> <ingress-action-capability>cap:alert</ingress-action-capability>
<egress-action-capa>capa:pass</egress-action-capa> <egress-action-capability>cap:pass</egress-action-capability>
<egress-action-capa>capa:drop</egress-action-capa> <egress-action-capability>cap:drop</egress-action-capability>
<egress-action-capa>capa:alert</egress-action-capa> <egress-action-capability>cap:alert</egress-action-capability>
</action-capabilities>
<ipsec-method>cap:ikeless</ipsec-method>
</security-capability>
<performance-capability>
<processing>
<processing-average>1000</processing-average>
<processing-peak>5000</processing-peak>
</processing>
<bandwidth>
<outbound>
<outbound-average>1000</outbound-average>
<outbound-peak>5000</outbound-peak>
</outbound>
<inbound>
<inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak>
</inbound>
</bandwidth>
</performance-capability>
</nsf-capability-info>
<nsf-access-info>
<capability-name>web_filter</capability-name>
<ip>192.0.2.11</ip>
<port>3000</port>
</nsf-access-info>
</nsf-information>
</nsf-registrations>
</action-capabilities> Figure 16: Configuration XML for Registration of a Web Filter in an
<ipsec-method>capa:ikeless</ipsec-method> IPv4 Network
</security-capability>
<performance-capability>
<processing>
<processing-average>1000</processing-average>
<processing-peak>5000</processing-peak>
</processing>
<bandwidth>
<outbound>
<outbound-average>1000</outbound-average>
<outbound-peak>5000</outbound-peak>
</outbound>
<inbound>
<inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak>
</inbound>
</bandwidth>
</performance-capability>
</nsf-capability-info>
<nsf-access-info>
<capability-name>web_filter</capability-name>
<ip>2001:DB8:8:4::4</ip>
<port>3000</port>
</nsf-access-info>
</nsf-information>
</nsf-registrations>
Figure 14: Configuration XML for Registration of Web Filter Figure 16 shows the configuration XML for registering a web filter in
an IPv4 network [RFC5737] and its capabilities are as follows.
Figure 14 shows the configuration XML for registering the web filter, 1. The instance name of the NSF is web_filter.
and its capabilities are as follows.
2. The NSF can inspect URL for HTTP and HTTPS packets.
3. The NSF can determine whether the packets are allowed to pass,
drop, or alert.
4. The NSF can support IPsec not through IKEv2, but through a
Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
5. The NSF can have processing power and bandwidth.
6. The IPv4 address of the NSF is 192.0.2.11.
7. The port of the NSF is 3000.
<nsf-registrations
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
xmlns:cap="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-information>
<capability-name>web_filter</capability-name>
<nsf-capability-info>
<security-capability>
<condition-capabilities>
<advanced-nsf-capabilities>
<url-capability>cap:user-defined</url-capability>
</advanced-nsf-capabilities>
</condition-capabilities>
<action-capabilities>
<ingress-action-capability>cap:pass</ingress-action-capability>
<ingress-action-capability>cap:drop</ingress-action-capability>
<ingress-action-capability>cap:alert</ingress-action-capability>
<egress-action-capability>cap:pass</egress-action-capability>
<egress-action-capability>cap:drop</egress-action-capability>
<egress-action-capability>cap:alert</egress-action-capability>
</action-capabilities>
<ipsec-method>cap:ikeless</ipsec-method>
</security-capability>
<performance-capability>
<processing>
<processing-average>1000</processing-average>
<processing-peak>5000</processing-peak>
</processing>
<bandwidth>
<outbound>
<outbound-average>1000</outbound-average>
<outbound-peak>5000</outbound-peak>
</outbound>
<inbound>
<inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak>
</inbound>
</bandwidth>
</performance-capability>
</nsf-capability-info>
<nsf-access-info>
<capability-name>web_filter</capability-name>
<ip>2001:DB8:0:1::11</ip>
<port>3000</port>
</nsf-access-info>
</nsf-information>
</nsf-registrations>
Figure 17: Configuration XML for Registration of a Web Filter in an
IPv6 Network
In addition, Figure 17 shows the configuration XML for registering a
web filter in an IPv6 network [RFC3849] 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 [i2nsf-ipsec]. Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
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 2001:DB8:8:4::4. 6. The IPv6 address of the NSF is 2001:DB8:0:1::11.
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 the Capabilities of a 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. a VoIP/VoLTE filter in either IPv4 networks [RFC5737] or IPv6
networks [RFC3849].
<nsf-registrations <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:cap="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-information> <nsf-information>
<capability-name>voip_volte_filter</capability-name> <capability-name>voip_volte_filter</capability-name>
<nsf-capability-info> <nsf-capability-info>
<security-capability> <security-capability>
<condition-capabilities> <condition-capabilities>
<advanced-nsf-capabilities> <advanced-nsf-capabilities>
<voip-volte-capa>capa:voice-id</voip-volte-capa> <voip-volte-capability>cap:voice-id</voip-volte-capability>
</advanced-nsf-capabilities> </advanced-nsf-capabilities>
</condition-capabilities> </condition-capabilities>
<action-capabilities> <action-capabilities>
<ingress-action-capa>capa:pass</ingress-action-capa> <ingress-action-capability>cap:pass</ingress-action-capability>
<ingress-action-capa>capa:drop</ingress-action-capa> <ingress-action-capability>cap:drop</ingress-action-capability>
<ingress-action-capa>capa:alert</ingress-action-capa> <ingress-action-capability>cap:alert</ingress-action-capability>
<egress-action-capa>capa:pass</egress-action-capa> <egress-action-capability>cap:pass</egress-action-capability>
<egress-action-capa>capa:drop</egress-action-capa> <egress-action-capability>cap:drop</egress-action-capability>
<egress-action-capa>capa:alert</egress-action-capa> <egress-action-capability>cap:alert</egress-action-capability>
</action-capabilities> </action-capabilities>
<ipsec-method>capa:ikeless</ipsec-method> <ipsec-method>cap:ikeless</ipsec-method>
</security-capability> </security-capability>
<performance-capability> <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>
</performance-capability> </performance-capability>
</nsf-capability-info> </nsf-capability-info>
<nsf-access-info> <nsf-access-info>
<capability-name>voip_volte_filter</capability-name> <capability-name>voip_volte_filter</capability-name>
<ip>2001:DB8:8:4::5</ip> <ip>192.0.2.11</ip>
<port>3000</port> <port>3000</port>
</nsf-access-info> </nsf-access-info>
</nsf-information> </nsf-information>
</nsf-registrations> </nsf-registrations>
Figure 15: Configuration XML for Registration of VoIP/VoLTE Filter Figure 18: Configuration XML for Registration of a VoIP/VoLTE Filter
in an IPv4 Network
Figure 15 shows the configuration XML for registering VoIP/VoLTE Figure 18 shows the configuration XML for registering a VoIP/VoLTE
filter, and its capabilities are as follows. filter in an IPv4 network [RFC5737] 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 a 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 [i2nsf-ipsec]. Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
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 2001:DB8:8:4::5. 6. The IPv4 address of the NSF is 192.0.2.11.
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 <nsf-registrations
Mitigation xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
xmlns:cap="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-information>
<capability-name>voip_volte_filter</capability-name>
<nsf-capability-info>
<security-capability>
<condition-capabilities>
<advanced-nsf-capabilities>
<voip-volte-capability>cap:voice-id</voip-volte-capability>
</advanced-nsf-capabilities>
</condition-capabilities>
<action-capabilities>
<ingress-action-capability>cap:pass</ingress-action-capability>
<ingress-action-capability>cap:drop</ingress-action-capability>
<ingress-action-capability>cap:alert</ingress-action-capability>
<egress-action-capability>cap:pass</egress-action-capability>
<egress-action-capability>cap:drop</egress-action-capability>
<egress-action-capability>cap:alert</egress-action-capability>
</action-capabilities>
<ipsec-method>cap:ikeless</ipsec-method>
</security-capability>
<performance-capability>
<processing>
<processing-average>1000</processing-average>
<processing-peak>5000</processing-peak>
</processing>
<bandwidth>
<outbound>
<outbound-average>1000</outbound-average>
<outbound-peak>5000</outbound-peak>
</outbound>
<inbound>
<inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak>
</inbound>
</bandwidth>
</performance-capability>
</nsf-capability-info>
<nsf-access-info>
<capability-name>voip_volte_filter</capability-name>
<ip>2001:DB8:0:1::11</ip>
<port>3000</port>
</nsf-access-info>
</nsf-information>
</nsf-registrations>
Figure 19: Configuration XML for Registration of a VoIP/VoLTE Filter
in an IPv6 Network
Figure 19 shows the configuration XML for registering a VoIP/VoLTE
filter in an IPv6 network [RFC3849] and its capabilities are as
follows.
1. The instance name of the NSF is voip_volte_filter.
2. The NSF can inspect a voice id for VoIP/VoLTE packets.
3. The NSF can determine whether the packets are allowed to pass,
drop, or alert.
4. The NSF can support IPsec not through IKEv2, but through a
Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
5. The NSF can have processing power and bandwidth.
6. The IPv6 address of the NSF is 2001:DB8:0:1::11.
7. The port of the NSF is 3000.
A.5. Example 5: Registration for the Capabilities of an HTTP and HTTPS
Flood Mitigator
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. an HTTP and HTTPS flood mitigator in either IPv4 networks [RFC5737]
or IPv6 networks [RFC3849].
<nsf-registrations <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:cap="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-information> <nsf-information>
<capability-name> <capability-name>
http_and_https_flood_mitigation http_and_https_flood_mitigator
</capability-name> </capability-name>
<nsf-capability-info> <nsf-capability-info>
<security-capability> <security-capability>
<condition-capabilities> <condition-capabilities>
<advanced-nsf-capabilities> <advanced-nsf-capabilities>
<antiddos-capa>capa:http-flood-action</antiddos-capa> <anti-ddos-capability>
<antiddos-capa>capa:https-flood-action</antiddos-capa> cap:http-flood-action
</advanced-nsf-capabilities> </anti-ddos-capability>
<anti-ddos-capability>
cap:https-flood-action
</anti-ddos-capability>
</advanced-nsf-capabilities>
</condition-capabilities>
<action-capabilities>
<ingress-action-capability>cap:pass</ingress-action-capability>
<ingress-action-capability>cap:drop</ingress-action-capability>
<ingress-action-capability>cap:alert</ingress-action-capability>
<egress-action-capability>cap:pass</egress-action-capability>
<egress-action-capability>cap:drop</egress-action-capability>
<egress-action-capability>cap:alert</egress-action-capability>
</action-capabilities>
<ipsec-method>cap:ike</ipsec-method>
</security-capability>
<performance-capability>
<processing>
<processing-average>1000</processing-average>
<processing-peak>5000</processing-peak>
</processing>
<bandwidth>
<outbound>
<outbound-average>1000</outbound-average>
<outbound-peak>5000</outbound-peak>
</outbound>
<inbound>
<inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak>
</inbound>
</bandwidth>
</performance-capability>
</nsf-capability-info>
<nsf-access-info>
<capability-name>
http_and_https_flood_mitigation
</capability-name>
<ip>192.0.2.11</ip>
<port>3000</port>
</nsf-access-info>
</nsf-information>
</nsf-registrations>
</condition-capabilities> Figure 20: Configuration XML for Registration of an HTTP and HTTPS
<action-capabilities> Flood Mitigator in an IPv4 Network
<ingress-action-capa>capa:pass</ingress-action-capa>
<ingress-action-capa>capa:drop</ingress-action-capa>
<ingress-action-capa>capa:alert</ingress-action-capa>
<egress-action-capa>capa:pass</egress-action-capa>
<egress-action-capa>capa:drop</egress-action-capa>
<egress-action-capa>capa:alert</egress-action-capa>
</action-capabilities>
<ipsec-method>capa:ike</ipsec-method>
</security-capability>
<performance-capability>
<processing>
<processing-average>1000</processing-average>
<processing-peak>5000</processing-peak>
</processing>
<bandwidth>
<outbound>
<outbound-average>1000</outbound-average>
<outbound-peak>5000</outbound-peak>
</outbound>
<inbound>
<inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak>
</inbound>
</bandwidth>
</performance-capability>
</nsf-capability-info>
<nsf-access-info>
<capability-name>
http_and_https_flood_mitigation
</capability-name>
<ip>2001:DB8:8:4::6</ip>
<port>3000</port>
</nsf-access-info>
</nsf-information>
</nsf-registrations>
Figure 16: Configuration XML for Registration of of HTTP and HTTPS Figure 20 shows the configuration XML for registering an HTTP and
Flood Mitigation HTTPS flood mitigator in an IPv4 network [RFC5737] and its
capabilities are as follows.
Figure 16 shows the configuration XML for registering the http and 1. The instance name of the NSF is http_and_https_flood_mitigator.
https flood mitigator, and its capabilities are as follows.
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
packets.
2. The NSF can control the amount of packets for http and https 3. The NSF can determine whether the packets are allowed to pass,
drop, or alert.
4. The NSF can support IPsec through IKEv2
[I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
5. The NSF can have processing power and bandwidth.
6. The IPv4 address of the NSF is 192.0.2.11.
7. The port of the NSF is 3000.
<nsf-registrations
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
xmlns:cap="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-information>
<capability-name>
http_and_https_flood_mitigator
</capability-name>
<nsf-capability-info>
<security-capability>
<condition-capabilities>
<advanced-nsf-capabilities>
<anti-ddos-capability>
cap:http-flood-action
</anti-ddos-capability>
<anti-ddos-capability>
cap:https-flood-action
</anti-ddos-capability>
</advanced-nsf-capabilities>
</condition-capabilities>
<action-capabilities>
<ingress-action-capability>cap:pass</ingress-action-capability>
<ingress-action-capability>cap:drop</ingress-action-capability>
<ingress-action-capability>cap:alert</ingress-action-capability>
<egress-action-capability>cap:pass</egress-action-capability>
<egress-action-capability>cap:drop</egress-action-capability>
<egress-action-capability>cap:alert</egress-action-capability>
</action-capabilities>
<ipsec-method>cap:ike</ipsec-method>
</security-capability>
<performance-capability>
<processing>
<processing-average>1000</processing-average>
<processing-peak>5000</processing-peak>
</processing>
<bandwidth>
<outbound>
<outbound-average>1000</outbound-average>
<outbound-peak>5000</outbound-peak>
</outbound>
<inbound>
<inbound-average>1000</inbound-average>
<inbound-peak>5000</inbound-peak>
</inbound>
</bandwidth>
</performance-capability>
</nsf-capability-info>
<nsf-access-info>
<capability-name>
http_and_https_flood_mitigation
</capability-name>
<ip>2001:DB8:0:1::11</ip>
<port>3000</port>
</nsf-access-info>
</nsf-information>
</nsf-registrations>
Figure 21: Configuration XML for Registration of an HTTP and HTTPS
Flood Mitigator in an IPv6 Network
In addition, Figure 21 shows the configuration XML for registering an
HTTP and HTTPS flood mitigator in an IPv6 network [RFC3849] and its
capabilities are as follows.
1. The instance name of the NSF is http_and_https_flood_mitigator.
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 [i2nsf-ipsec]. 4. The NSF can support IPsec through IKEv2
[I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
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 2001:DB8:8:4::6. 6. The IPv6 address of the NSF is 2001:DB8:0:1::11.
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 the Capabilities of a 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 a
time-based firewall. time-based firewall in either IPv4 networks [RFC5737] or IPv6
networks [RFC3849].
<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">
<nsf-capability-query <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:cap="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-capability>cap:ipv4-protocol</ipv4-capability>
<ipv4-capa>capa:exact-ipv4-address</ipv4-capa> <ipv4-capability>cap:exact-ipv4-address</ipv4-capability>
<ipv4-capa>capa:range-ipv4-address</ipv4-capa> <ipv4-capability>cap:range-ipv4-address</ipv4-capability>
</generic-nsf-capabilities> </generic-nsf-capabilities>
</condition-capabilities> </condition-capabilities>
<action-capabilities> <action-capabilities>
<ingress-action-capa>capa:pass</ingress-action-capa> <ingress-action-capability>cap:pass</ingress-action-capability>
<ingress-action-capa>capa:drop</ingress-action-capa> <ingress-action-capability>cap:drop</ingress-action-capability>
<ingress-action-capa>capa:alert</ingress-action-capa> <ingress-action-capability>cap:alert</ingress-action-capability>
<egress-action-capa>capa:pass</egress-action-capa> <egress-action-capability>cap:pass</egress-action-capability>
<egress-action-capa>capa:drop</egress-action-capa> <egress-action-capability>cap:drop</egress-action-capability>
<egress-action-capa>capa:alert</egress-action-capa> <egress-action-capability>cap:alert</egress-action-capability>
</action-capabilities> </action-capabilities>
<ipsec-method>capa:ikeless</ipsec-method> <ipsec-method>cap:ikeless</ipsec-method>
</query-i2nsf-capability-info> </query-i2nsf-capability-info>
</nsf-capability-query> </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">
<capability-name>time-based-firewall</capability-name> <capability-name>time-based-firewall</capability-name>
<ip>2001:DB8:8:4::7</ip> <ip>192.0.2.11</ip>
<port>8080</port> <port>3000</port>
</nsf-access-info> </nsf-access-info>
</rpc-reply> </rpc-reply>
Figure 17: Configuration XML for Query of Time-based Firewall Figure 22: Configuration XML for Query of a Time-based Firewall in an
IPv4 Network
Figure 17 shows the XML configuration for querying the capabilities Figure 22 shows the XML configuration for querying the capabilities
of the time-based firewall. of a time-based firewall in an IPv4 network [RFC5737]. The access
information of the announced time-based firewall has the IPv4 address
of 192.0.2.11 and the port number of 3000.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<nsf-capability-query
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
xmlns:cap="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<query-i2nsf-capability-info>
<time-capabilities>absolute-time</time-capabilities>
<time-capabilities>periodic-time</time-capabilities>
<condition-capabilities>
<generic-nsf-capabilities>
<ipv6-capability>cap:ipv6-protocol</ipv6-capability>
<ipv6-capability>cap:exact-ipv6-address</ipv6-capability>
<ipv6-capability>cap:range-ipv6-address</ipv6-capability>
</generic-nsf-capabilities>
</condition-capabilities>
<action-capabilities>
<ingress-action-capability>cap:pass</ingress-action-capability>
<ingress-action-capability>cap:drop</ingress-action-capability>
<ingress-action-capability>cap:alert</ingress-action-capability>
<egress-action-capability>cap:pass</egress-action-capability>
<egress-action-capability>cap:drop</egress-action-capability>
<egress-action-capability>cap:alert</egress-action-capability>
</action-capabilities>
<ipsec-method>cap:ikeless</ipsec-method>
</query-i2nsf-capability-info>
</nsf-capability-query>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<nsf-access-info
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface">
<capability-name>time-based-firewall</capability-name>
<ip>2001:DB8:0:1::11</ip>
<port>3000</port>
</nsf-access-info>
</rpc-reply>
Figure 23: Configuration XML for Query of a Time-based Firewall in an
IPv6 Network
In addition, Figure 23 shows the XML configuration for querying the
capabilities of a time-based firewall in an IPv6 network [RFC3849].
The access information of the announced time-based firewall has the
IPv6 address of 2001:DB8:0:1::11 and the port number of 3000.
Appendix B. NSF Lifecycle Management in NFV Environments Appendix B. NSF Lifecycle Management 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-07 Appendix C. Acknowledgments
The following changes have been made from draft-ietf-i2nsf-
registration-interface-dm-07:
o This version is revised according to the comments from Reshad
Rahman who reviewed this document as a YANG doctor.
o draft-ietf-i2nsf-capability-data-model is cited as a normative
reference according to the guideline at
https://tools.ietf.org/html/rfc8407#section-3.9
o For the references to draft-ietf-i2nsf-capability-data-model in
the YANG model, they are qualified with a note to the editor that
the draft will become an RFC, so the actual RFC number of the
draft needs to be used.
o The editor's notes are put to request to replace XXXX with the
actual RFC number of this document (i.e., draft-ietf-i2nsf-
registration-interface-dm) when the document is published.
o Leaf nodes (i.e., processing-average and processing-peak) under
container processing have unit GHz explicitly with units "GHz".
Appendix D. Acknowledgments
This work was supported by Institute of Information & Communications This work was supported by Institute of Information & Communications
Technology Planning & Evaluation (IITP) grant funded by the Korea Technology Planning & Evaluation (IITP) grant funded by the Korea
MSIT (Ministry of Science and ICT) (No. 2016-0-00078, Cloud Based MSIT (Ministry of Science and ICT) (No. 2016-0-00078, Cloud Based
Security Intelligence Technology Development for the Customized Security Intelligence Technology Development for the Customized
Security Service Provisioning). Security Service Provisioning).
Appendix E. Contributors Appendix D. 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, such as Reshad
considered co-authors: Rahman. The authors sincerely appreciate their contributions.
o Jinyong Tim Kim (Sungkyunkwan University) The following are co-authors of this document:
o Chaehong Chung (Sungkyunkwan University) Jinyong Tim Kim
Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
o Susan Hares (Huawei) EMail: timkim@skku.edu
o Diego R. Lopez (Telefonica) Chaehong Chung
Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
EMail: darkhong@skku.edu
Susan Hares
Huawei
7453 Hickory Hill
Saline, MI 48176
USA
EMail: shares@ndzh.com
Diego R. Lopez
Telefonica I+D
Jose Manuel Lara, 9
Seville, 41013
Spain
EMail: diego.r.lopez@telefonica.com
Authors' Addresses Authors' Addresses
Sangwon Hyun Sangwon Hyun (editor)
Department of Computer Engineering Department of Computer Engineering
Myongji University Myongji University
116 Myongji-ro, Cheoin-gu 116 Myongji-ro, Cheoin-gu
Yongin, Gyeonggi-do 17058 Yongin, Gyeonggi-do 17058
Republic of Korea Republic of Korea
EMail: shyun@mju.ac.kr EMail: shyun@mju.ac.kr
Jaehoon Paul Jeong Jaehoon Paul Jeong (editor)
Department of Computer Science and Engineering 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
 End of changes. 110 change blocks. 
494 lines changed or deleted 952 lines changed or added

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