draft-ietf-i2nsf-nsf-facing-interface-dm-01.txt   draft-ietf-i2nsf-nsf-facing-interface-dm-02.txt 
Network Working Group J. Kim I2NSF Working Group J. Kim
Internet-Draft J. Jeong Internet-Draft J. Jeong
Intended status: Standards Track Sungkyunkwan University Intended status: Standards Track Sungkyunkwan University
Expires: January 3, 2019 J. Park Expires: May 8, 2019 J. Park
ETRI ETRI
S. Hares S. Hares
Q. Lin Q. Lin
Huawei Huawei
July 02, 2018 November 4, 2018
I2NSF Network Security Function-Facing Interface YANG Data Model I2NSF Network Security Function-Facing Interface YANG Data Model
draft-ietf-i2nsf-nsf-facing-interface-dm-01 draft-ietf-i2nsf-nsf-facing-interface-dm-02
Abstract Abstract
This document defines a YANG data model corresponding to the This document defines a YANG data model corresponding to the
information model for Network Security Functions (NSF) facing information model for Network Security Functions (NSF)-Facing
interface in Interface to Network Security Functions (I2NSF). It Interface in Interface to Network Security Functions (I2NSF). It
describes a data model for the features provided by generic security describes a data model for the features provided by generic security
functions. This data model provides generic components whose vendors functions. This data model provides vendors with generic components
is well understood, so that the generic component can be used even if that they understand well, so these generic components can be used
it has some vendor specific functions. These generic functions even if they have some vendor specific functions. These generic
represent a point of interoperability, and can be provided by any functions represent a point of interoperability, and can be provided
product that offers the required Capabilities. Also, if vendors need by any product that offers the required capabilities. Also, if they
additional features for its network security function, they can add need additional features for their network security functions, the
the features by extending the YANG data model. vendors can easily add the features by extending the YANG data model
in this document.
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 January 3, 2019. This Internet-Draft will expire on May 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 38 skipping to change at page 2, line 38
4.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 4 4.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 4
4.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 5
5. Data Model Structure . . . . . . . . . . . . . . . . . . . . 5 5. Data Model Structure . . . . . . . . . . . . . . . . . . . . 5
5.1. I2NSF Security Policy Rule . . . . . . . . . . . . . . . 5 5.1. I2NSF Security Policy Rule . . . . . . . . . . . . . . . 5
5.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 8 5.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 8
5.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 10
6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. IETF NSF-Facing Interface YANG Data Module . . . . . . . 12 6.1. IETF NSF-Facing Interface YANG Data Module . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 47 8.1. Normative References . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.2. Informative References . . . . . . . . . . . . . . . . . 47
10.1. Normative References . . . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . . . 47
Appendix A. Changes from draft-ietf-i2nsf-nsf-facing-interface- Appendix A. Changes from draft-ietf-i2nsf-nsf-facing-interface-
dm-01 . . . . . . . . . . . . . . . . . . . . . . . 49 dm-01 . . . . . . . . . . . . . . . . . . . . . . . 48
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 48
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
This document defines a YANG [RFC6020] data model for the This document defines a YANG [RFC6020] data model for the
configuration of security services with the information model for configuration of security services with the information model for
Network Security Functions (NSF) facing interface in Interface to Network Security Functions (NSF) facing interface in Interface to
Network Security Functions (I2NSF). It provides a specific Network Security Functions (I2NSF). It provides a specific
information model and the corresponding data models for generic information model and the corresponding data models for generic
network security functions (i.e., network security functions), as network security functions (i.e., network security functions), as
defined in [i2nsf-nsf-cap-im]. With these data model, I2NSF defined in [i2nsf-nsf-cap-im]. With these data model, I2NSF
controller can control the capabilities of NSFs. controller can control the capabilities of NSFs.
The "Event-Condition-Action" (ECA) policy model is used as the basis The "Event-Condition-Action" (ECA) policy model is used as the basis
for the design of I2NSF Policy Rules. for the design of I2NSF Policy Rules.
The "ietf-i2nsf-nsf-facing-interface" YANG module defined in this The "ietf-i2nsf-nsf-facing-interface" YANG module defined in this
document provides the following features: document provides the following features:
o configuration of I2NSF security policy rule for generic network o Configuration of I2NSF security policy rule for generic network
security function policy security function policy;
o configuration of event clause for generic network security o Configuration of event clause for generic network security
function policy function policy;
o configuration of condition clause for generic network security o Configuration of condition clause for generic network security
function policy function policy;
o configuration of action clause for generic network security o Configuration of action clause for generic network security
function policy function policy.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
This document uses the terminology described in This document uses the terminology described in
[i2nsf-nsf-cap-im][i2rs-rib-data-model][supa-policy-info-model]. [i2nsf-nsf-cap-im][RFC8431][supa-policy-info-model]. Especially, the
Especially, the following terms are from [supa-policy-info-model]: following terms are from [supa-policy-info-model]:
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. 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.
3.1. Tree Diagrams 3.1. Tree Diagrams
A simplified graphical representation of the data model is used in A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams this document. The meaning of the symbols in these diagrams
[i2rs-rib-data-model] is as follows: [RFC8431] is as follows:
o Brackets "[" and "]" enclose list keys. o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration o Abbreviations before data node names: "rw" means configuration
(read-write) and "ro" state data (read-only). (read-write) and "ro" state data (read-only).
o Symbols after data node names: "?" means an optional node and "*" o Symbols after data node names: "?" means an optional node and "*"
denotes a "list" and "leaf-list". denotes a "list" and "leaf-list".
o Parentheses enclose choice and case nodes, and case nodes are also o Parentheses enclose choice and case nodes, and case nodes are also
skipping to change at page 5, line 24 skipping to change at page 5, line 24
An action is used to control and monitor aspects of flow-based NSFs An action is used to control and monitor aspects of flow-based NSFs
when the event and condition clauses are satisfied. NSFs provide when the event and condition clauses are satisfied. NSFs provide
security functions by executing various Actions. The object of an security functions by executing various Actions. The object of an
action clause is defined as ingress action, egress action, and apply action clause is defined as ingress action, egress action, and apply
profile action. The objects of action clauses can be extended profile action. The objects of action clauses can be extended
according to specific vendor action features. according to specific vendor action features.
5. Data Model Structure 5. Data Model Structure
This section shows a data model structure tree of generic network This section shows a data model structure tree of generic network
security functions that are defined in the [i2nsf-nsf-cap-im]. security functions that are defined in the [i2nsf-nsf-cap-im]. Note
that a detailed data model for the configuration of the advanced
network security functions is described in [i2nsf-advanced-nsf-dm].
The section discusses the following subjects:
o Consideration of ECA Policy Model by Aggregating the Event, o Consideration of ECA Policy Model by aggregating the Event,
Condition, and Action Clauses Objects. Condition, and Action Clause Objects;
o Consideration of Capability Algebra. o Consideration of Capability Algebra;
o Consideration of NSFs Capability Categories (i.e., Network o Consideration of NSFs Capability Categories (i.e., Network
Security, Content Security, and Attack Mitigation Capabilities). Security, Content Security, and Attack Mitigation Capabilities);
o Definitions for Network Security Event Class, Network Security o Definition for Network Security Event Class, Network Security
Condition Class, and Network Security Action Class. Condition Class, and Network Security Action Class.
5.1. I2NSF Security Policy Rule 5.1. I2NSF Security Policy Rule
The data model for the identification of network security policy has The data model for the identification of network security policy has
the following structure: the following structure:
module: ietf-i2nsf-policy-rule-for-nsf module: ietf-i2nsf-policy-rule-for-nsf
+--rw i2nsf-security-policy +--rw i2nsf-security-policy
| +--rw policy-name? string +--rw system-policy* [system-policy-name]
| +--rw rules* [rule-name] +--rw system-policy-name string
| | +--rw rule-name string +--rw priority-usage priority-usage-type
| | +--rw rule-description? string +--rw rules* [rule-name]
| | +--rw rule-priority? uint8 | +--rw rule-name string
| | +--rw enable? boolean | +--rw rule-description? string
| | +--rw session-aging-time? uint16 | +--rw rule-priority? uint8
| | +--rw long-connection | +--rw enable? boolean
| | | +--rw enable? boolean | +--rw session-aging-time? uint16
| | | +--rw during? uint16 | +--rw long-connection
| | +--rw policy-event-clause-agg-ptr* instance-identifier | | +--rw enable? boolean
| | +--rw policy-condition-clause-agg-ptr* instance-identifier | | +--rw during? uint16
| | +--rw policy-action-clause-agg-ptr* instance-identifier | +--rw time-zone
| | +--rw time-zone | | +--rw absolute-time-zone
| | +--rw absolute-time-zone | | | +--rw time
| | | +--rw time | | | | +--rw start-time? yang:date-and-time
| | | | +--rw start-time? yang:date-and-time | | | | +--rw end-time? yang:date-and-time
| | | | +--rw end-time? yang:date-and-time | | | +--rw date
| | | +--rw date | | | +--rw absolute-date? yang:date-and-time
| | | +--rw absolute-date? yang:date-and-time | | +--rw periodic-time-zone
| | +--rw periodic-time-zone | | +--rw day
| | +--rw day | | | +--rw sunday? boolean
| | | +--rw sunday? boolean | | | +--rw monday? boolean
| | | +--rw monday? boolean | | | +--rw tuesday? boolean
| | | +--rw tuesday? boolean | | | +--rw wednesday? boolean
| | | +--rw wednesday? boolean | | | +--rw thursday? boolean
| | | +--rw thursday? boolean | | | +--rw friday? boolean
| | | +--rw friday? boolean | | | +--rw saturday? boolean
| | | +--rw saturday? boolean | | +--rw month
| | +--rw month | | +--rw january? boolean
| | +--rw january? boolean | | +--rw february? boolean
| | +--rw february? boolean | | +--rw march? boolean
| | +--rw march? boolean | | +--rw april? boolean
| | +--rw april? boolean | | +--rw may? boolean
| | +--rw may? boolean | | +--rw june? boolean
| | +--rw june? boolean | | +--rw july? boolean
| | +--rw july? boolean | | +--rw august? boolean
| | +--rw august? boolean | | +--rw september? boolean
| | +--rw september? boolean | | +--rw october? boolean
| | +--rw october? boolean | | +--rw november? boolean
| | +--rw november? boolean | | +--rw december? boolean
| | +--rw december? boolean | +--rw event-clause-container
| +--rw resolution-strategy | | ...
| | +--rw (resolution-strategy-type)? | +--rw condition-clause-container
| | +--:(fmr) | | ...
| | | +--rw first-matching-rule? boolean | +--rw action-clause-container
| | +--:(lmr) | ...
| | +--rw last-matching-rule? boolean +--rw resolution-strategy
| +--rw default-action | +--rw (resolution-strategy-type)?
| | +--rw default-action-type? boolean | +--:(fmr)
| +--rw rule-group | | +--rw first-matching-rule? boolean
| +--rw groups* [group-name] | +--:(lmr)
| +--rw group-name string | +--rw last-matching-rule? boolean
| +--rw rule-range +--rw default-action
| | +--rw start-rule? string | +--rw default-action-type? boolean
| | +--rw end-rule? string +--rw rule-group
| +--rw enable? boolean +--rw groups* [group-name]
| +--rw description? string +--rw group-name string
+--rw event-clause-container +--rw rule-range
| ... | +--rw start-rule? string
+--rw condition-clause-container | +--rw end-rule? string
| ... +--rw enable? boolean
+--rw action-clause-container +--rw description? string
...
Figure 1: Data Model Structure for Network Security Policy Figure 1: Data Model Structure for Network Security Policy
Identification Identification
5.2. Event Clause 5.2. Event Clause
The data model for event rule has the following structure: The data model for event rule has the following structure:
module: ietf-i2nsf-policy-rule-for-nsf module: ietf-i2nsf-policy-rule-for-nsf
+--rw i2nsf-security-policy* [policy-name] +--rw i2nsf-security-policy
| ... +--rw system-policy* [system-policy-name]
| +--rw eca-policy-rules* [rule-id] ...
| ... | +--rw event-clause-container
| +--rw resolution-strategy | | +--rw event-clause-list* [eca-object-id]
| ... | | +--rw entity-class? identityref
| +--rw default-action | | +--rw eca-object-id string
| ... | | +--rw description? string
+--rw event-clause-container | | +--rw sec-event-content string
| +--rw event-clause-list* [eca-object-id] | | +--rw sec-event-format sec-event-format
| +--rw entity-class? identityref | | +--rw sec-event-type string
| +--rw eca-object-id string | +--rw condition-clause-container
| +--rw description? string | | ...
| +--rw sec-event-content string | +--rw action-clause-container
| +--rw sec-event-format sec-event-format | ...
| +--rw sec-event-type string +--rw resolution-strategy
+--rw condition-clause-container | ...
| ... +--rw default-action
+--rw action-clause-container | ...
... +--rw rule-group
...
Figure 2: Data Model Structure for Event Rule Figure 2: Data Model Structure for Event Rule
These objects are defined as user security event, device security These objects are defined as user security event, device security
event, system security event, and time security event. These objects event, system security event, and time security event. These objects
can be extended according to specific vendor event features. We will can be extended according to specific vendor event features. We will
add additional event objects for more generic network security add additional event objects for more generic network security
functions. functions.
5.3. Condition Clause 5.3. Condition Clause
The data model for condition rule has the following structure: The data model for condition rule has the following structure:
module: ietf-i2nsf-policy-rule-for-nsf module: ietf-i2nsf-policy-rule-for-nsf
+--rw i2nsf-security-policy* [policy-name] +--rw i2nsf-security-policy
| ... +--rw system-policy* [system-policy-name]
| +--rw eca-policy-rules* [rule-id] ...
| ... | +--rw event-clause-container
| +--rw resolution-strategy | | ...
| ... | +--rw condition-clause-container
| +--rw default-action | | +--rw condition-clause-list* [eca-object-id]
| ... | | +--rw entity-class? identityref
+--rw event-clause-container | | +--rw eca-object-id string
| ... | | +--rw packet-security-condition
+--rw condition-clause-container | | | +--rw packet-description? string
| +--rw condition-clause-list* [eca-object-id] | | | +--rw packet-security-mac-condition
| +--rw entity-class? identityref | | | | +--rw pkt-sec-cond-mac-dest* yang:phys-address
| +--rw eca-object-id string | | | | +--rw pkt-sec-cond-mac-src* yang:phys-address
| +--rw packet-security-condition | | | | +--rw pkt-sec-cond-mac-8021q* string
| | +--rw packet-description? string | | | | +--rw pkt-sec-cond-mac-ether-type* string
| | +--rw packet-security-mac-condition | | | | +--rw pkt-sec-cond-mac-tci* string
| | | +--rw pkt-sec-cond-mac-dest* yang:phys-address | | | +--rw packet-security-ipv4-condition
| | | +--rw pkt-sec-cond-mac-src* yang:phys-address | | | | +--rw pkt-sec-cond-ipv4-header-length* uint8
| | | +--rw pkt-sec-cond-mac-8021q* string | | | | +--rw pkt-sec-cond-ipv4-tos* uint8
| | | +--rw pkt-sec-cond-mac-ether-type* string | | | | +--rw pkt-sec-cond-ipv4-total-length* uint16
| | | +--rw pkt-sec-cond-mac-tci* string | | | | +--rw pkt-sec-cond-ipv4-id* uint8
| | +--rw packet-security-ipv4-condition | | | | +--rw pkt-sec-cond-ipv4-fragment* uint8
| | | +--rw pkt-sec-cond-ipv4-header-length* uint8 | | | | +--rw pkt-sec-cond-ipv4-fragment-offset* uint16
| | | +--rw pkt-sec-cond-ipv4-tos* uint8 | | | | +--rw pkt-sec-cond-ipv4-ttl* uint8
| | | +--rw pkt-sec-cond-ipv4-total-length* uint16 | | | | +--rw pkt-sec-cond-ipv4-protocol* uint8
| | | +--rw pkt-sec-cond-ipv4-id* uint8 | | | | +--rw pkt-sec-cond-ipv4-src* inet:ipv4-address
| | | +--rw pkt-sec-cond-ipv4-fragment* uint8 | | | | +--rw pkt-sec-cond-ipv4-dest* inet:ipv4-address
| | | +--rw pkt-sec-cond-ipv4-fragment-offset* uint16 | | | | +--rw pkt-sec-cond-ipv4-ipopts? string
| | | +--rw pkt-sec-cond-ipv4-ttl* uint8 | | | | +--rw pkt-sec-cond-ipv4-sameip? boolean
| | | +--rw pkt-sec-cond-ipv4-protocol* uint8 | | | | +--rw pkt-sec-cond-ipv4-geoip* string
| | | +--rw pkt-sec-cond-ipv4-src* inet:ipv4-address | | | +--rw packet-security-ipv6-condition
| | | +--rw pkt-sec-cond-ipv4-dest* inet:ipv4-address | | | | +--rw pkt-sec-cond-ipv6-dscp* string
| | | +--rw pkt-sec-cond-ipv4-ipopts? string | | | | +--rw pkt-sec-cond-ipv6-ecn* string
| | | +--rw pkt-sec-cond-ipv4-sameip? boolean | | | | +--rw pkt-sec-cond-ipv6-traffic-class* uint8
| | | +--rw pkt-sec-cond-ipv4-geoip* string | | | | +--rw pkt-sec-cond-ipv6-flow-label* uint32
| | +--rw packet-security-ipv6-condition | | | | +--rw pkt-sec-cond-ipv6-payload-length* uint16
| | | +--rw pkt-sec-cond-ipv6-dscp* string | | | | +--rw pkt-sec-cond-ipv6-next-header* uint8
| | | +--rw pkt-sec-cond-ipv6-ecn* string | | | | +--rw pkt-sec-cond-ipv6-hop-limit* uint8
| | | +--rw pkt-sec-cond-ipv6-traffic-class* uint8 | | | | +--rw pkt-sec-cond-ipv6-src* inet:ipv6-address
| | | +--rw pkt-sec-cond-ipv6-flow-label* uint32 | | | | +--rw pkt-sec-cond-ipv6-dest* inet:ipv6-address
| | | +--rw pkt-sec-cond-ipv6-payload-length* uint16 | | | +--rw packet-security-tcp-condition
| | | +--rw pkt-sec-cond-ipv6-next-header* uint8 | | | | +--rw pkt-sec-cond-tcp-src-port* inet:port-number
| | | +--rw pkt-sec-cond-ipv6-hop-limit* uint8 | | | | +--rw pkt-sec-cond-tcp-dest-port* inet:port-number
| | | +--rw pkt-sec-cond-ipv6-src* inet:ipv6-address | | | | +--rw pkt-sec-cond-tcp-seq-num* uint32
| | | +--rw pkt-sec-cond-ipv6-dest* inet:ipv6-address | | | | +--rw pkt-sec-cond-tcp-ack-num* uint32
| | +--rw packet-security-tcp-condition | | | | +--rw pkt-sec-cond-tcp-window-size* uint16
| | | +--rw pkt-sec-cond-tcp-src-port* inet:port-number | | | | +--rw pkt-sec-cond-tcp-flags* uint8
| | | +--rw pkt-sec-cond-tcp-dest-port* inet:port-number | | | +--rw packet-security-udp-condition
| | | +--rw pkt-sec-cond-tcp-seq-num* uint32 | | | | +--rw pkt-sec-cond-udp-src-port* inet:port-number
| | | +--rw pkt-sec-cond-tcp-ack-num* uint32 | | | | +--rw pkt-sec-cond-udp-dest-port* inet:port-number
| | | +--rw pkt-sec-cond-tcp-window-size* uint16 | | | | +--rw pkt-sec-cond-udp-length* string
| | | +--rw pkt-sec-cond-tcp-flags* uint8 | | | +--rw packet-security-icmp-condition
| | +--rw packet-security-udp-condition | | | +--rw pkt-sec-cond-icmp-type* uint8
| | | +--rw pkt-sec-cond-udp-src-port* inet:port-number | | | +--rw pkt-sec-cond-icmp-code* uint8
| | | +--rw pkt-sec-cond-udp-dest-port* inet:port-number | | | +--rw pkt-sec-cond-icmp-seg-num* uint32
| | | +--rw pkt-sec-cond-udp-length* string | | +--rw packet-payload-condition
| | +--rw packet-security-icmp-condition | | | +--rw packet-payload-description? string
| | +--rw pkt-sec-cond-icmp-type* uint8 | | | +--rw pkt-payload-content* string
| | +--rw pkt-sec-cond-icmp-code* uint8 | | +--rw acl-number? uint32
| | +--rw pkt-sec-cond-icmp-seg-num* uint32 | | +--rw application-condition
| +--rw packet-payload-condition | | | +--rw application-description? string
| | +--rw packet-payload-description? string | | | +--rw application-object* string
| | +--rw pkt-payload-content* string | | | +--rw application-group* string
| +--rw acl-number? uint32 | | | +--rw application-label* string
| +--rw application-condition | | | +--rw category
| | +--rw application-description? string | | | +--rw application-category*
| | +--rw application-object* string | | | [name application-subcategory]
| | +--rw application-group* string | | | +--rw name string
| | +--rw application-label* string | | | +--rw application-subcategory string
| | +--rw category | | +--rw target-condition
| | +--rw application-category* [name application-subcategory] | | | +--rw target-description? string
| | +--rw name string | | | +--rw device-sec-context-cond
| | +--rw application-subcategory string | | | +--rw pc? boolean
| +--rw target-condition | | | +--rw mobile-phone? boolean
| | +--rw target-description? string | | | +--rw voip-volte-phone? boolean
| | +--rw device-sec-context-cond | | | +--rw tablet? boolean
| | +--rw pc? boolean | | | +--rw iot? boolean
| | +--rw mobile-phone? boolean | | | +--rw vehicle? boolean
| | +--rw voip-volte-phone? boolean | | +--rw users-condition
| | +--rw tablet? boolean | | | +--rw users-description? string
| | +--rw iot? boolean | | | +--rw user
| | +--rw vehicle? boolean | | | | +--rw (user-name)?
| +--rw users-condition | | | | +--:(tenant)
| | +--rw users-description? string | | | | | +--rw tenant uint8
| | +--rw user | | | | +--:(vn-id)
| | | +--rw (user-name)? | | | | +--rw vn-id uint8
| | | +--:(tenant) | | | +--rw group
| | | | +--rw tenant uint8 | | | | +--rw (group-name)?
| | | +--:(vn-id) | | | | +--:(tenant)
| | | +--rw vn-id uint8 | | | | | +--rw tenant uint8
| | +--rw group | | | | +--:(vn-id)
| | | +--rw (group-name)? | | | | +--rw vn-id uint8
| | | +--:(tenant) | | | +--rw security-grup string
| | | | +--rw tenant uint8 | | +--rw url-category-condition
| | | +--:(vn-id) | | | +--rw url-category-description? string
| | | +--rw vn-id uint8 | | | +--rw pre-defined-category* string
| | +--rw security-grup string | | | +--rw user-defined-category* string
| +--rw url-category-condition | | +--rw context-condition
| | +--rw pre-defined-category* string | | | +--rw context-description? string
| | +--rw user-defined-category* string | | +--rw gen-context-condition
| +--rw context-condition | | +--rw gen-context-description? string
| | +--rw context-description? string | | +--rw geographic-location
| +--rw gen-context-condition | | +--rw src-geographic-location* uint32
| +--rw gen-context-description? string | | +--rw dest-geographic-location* uint32
| +--rw geographic-location | +--rw action-clause-container
| +--rw src-geographic-location* uint32 | ...
| +--rw dest-geographic-location* uint32 +--rw resolution-strategy
+--rw action-clause-container | ...
... +--rw default-action
| ...
+--rw rule-group
...
Figure 3: Data Model Structure for Condition Rule Figure 3: Data Model Structure for Condition Rule
These objects are defined as packet security condition, packet These objects are defined as packet security condition, packet
payload security condition, target security condition, user security payload security condition, target security condition, user security
condition, context condition, and generic context condition. These condition, context condition, and generic context condition. These
objects can be extended according to specific vendor condition objects can be extended according to specific vendor condition
features. We will add additional condition objects for more generic features. We will add additional condition objects for more generic
network security functions. network security functions.
5.4. Action Clause 5.4. Action Clause
The data model for action rule has the following structure: The data model for action rule has the following structure:
module: ietf-i2nsf-policy-rule-for-nsf module: ietf-i2nsf-policy-rule-for-nsf
+--rw i2nsf-security-policy* [policy-name] +--rw i2nsf-security-policy
| ... +--rw system-policy* [system-policy-name]
| +--rw eca-policy-rules* [rule-id] ...
| ... | +--rw event-clause-container
| +--rw resolution-strategy | | ...
| ... | +--rw condition-clause-container
| +--rw default-action | | ...
| ... | +--rw action-clause-container
+--rw event-clause-container | +--rw action-clause-list* [eca-object-id]
| ... | +--rw entity-class? identityref
+--rw condition-clause-container | +--rw eca-object-id string
| ... | +--rw rule-log? boolean
+--rw action-clause-container | +--rw session-log? boolean
+--rw action-clause-list* [eca-object-id] | +--rw ingress-action
+--rw entity-class? identityref | | +--rw ingress-description? string
+--rw eca-object-id string | | +--rw ingress-action-type? ingress-action
+--rw rule-log? boolean | +--rw egress-action
+--rw session-log? boolean | | +--rw egress-description? string
+--rw ingress-action | | +--rw egress-action-type? egress-action
| +--rw ingress-description? string | +--rw apply-profile
| +--rw ingress-action-type? ingress-action | +--rw profile-description? string
+--rw egress-action | +--rw content-security-control
| +--rw egress-description? string | | +--rw content-security-control-types
| +--rw egress-action-type? egress-action | | +--rw antivirus? string
+--rw apply-profile | | +--rw ips? string
+--rw profile-description? string | | +--rw ids? string
+--rw content-security-control | | +--rw url-filtering? string
| +--rw content-security-control-types | | +--rw data-filtering? string
| +--rw antivirus? string | | +--rw mail-filtering? string
| +--rw ips? string | | +--rw file-blocking? string
| +--rw ids? string | | +--rw file-isolate? string
| +--rw url-filtering? string | | +--rw pkt-capture? string
| +--rw data-filtering? string | | +--rw application-control? string
| +--rw mail-filtering? string | | +--rw voip-volte? string
| +--rw file-blocking? string | +--rw attack-mitigation-control
| +--rw file-isolate? string | +--rw ddos-attack
| +--rw pkt-capture? string | | +--rw ddos-attack-type
| +--rw application-control? string | | +--rw network-layer-ddos-attack
| +--rw voip-volte? string | | | +--rw network-layer-ddos-attack-type
+--rw attack-mitigation-control | | | +--rw syn-flood? string
+--rw ddos-attack | | | +--rw udp-flood? string
| +--rw ddos-attack-type | | | +--rw icmp-flood? string
| +--rw network-layer-ddos-attack | | | +--rw ip-frag-flood? string
| | +--rw network-layer-ddos-attack-type | | | +--rw ipv6-related? string
| | +--rw syn-flood? string | | +--rw app-layer-ddos-attack
| | +--rw udp-flood? string | | +--rw app-ddos-attack-types
| | +--rw icmp-flood? string | | +--rw http-flood? string
| | +--rw ip-frag-flood? string | | +--rw https-flood? string
| | +--rw ipv6-related? string | | +--rw dns-flood? string
| +--rw app-layer-ddos-attack | | +--rw dns-amp-flood? string
| +--rw app-ddos-attack-types | | +--rw ssl-ddos? string
| +--rw http-flood? string | +--rw single-packet-attack
| +--rw https-flood? string | +--rw single-packet-attack-type
| +--rw dns-flood? string | +--rw scan-and-sniff-attack
| +--rw dns-amp-flood? string | | +--rw scan-and-sniff-attack-types
| +--rw ssl-ddos? string | | +--rw ip-sweep? string
+--rw single-packet-attack | | +--rw port-scanning? string
+--rw single-packet-attack-type | +--rw malformed-packet-attack
+--rw scan-and-sniff-attack | | +--rw malformed-packet-attack-types
| +--rw scan-and-sniff-attack-types | | +--rw ping-of-death? string
| +--rw ip-sweep? string | | +--rw teardrop? string
| +--rw port-scanning? string | +--rw special-packet-attack
+--rw malformed-packet-attack | +--rw special-packet-attack-types
| +--rw malformed-packet-attack-types | +--rw oversized-icmp? string
| +--rw ping-of-death? string | +--rw tracert? string
| +--rw teardrop? string +--rw resolution-strategy
+--rw special-packet-attack | ...
+--rw special-packet-attack-types +--rw default-action
+--rw oversized-icmp? string | ...
+--rw tracert? string +--rw rule-group
...
Figure 4: Data Model Structure for Action Rule Figure 4: Data Model Structure for Action Rule
These objects are defined as ingress action, egress action, and apply These objects are defined as ingress action, egress action, and apply
profile action. These objects can be extended according to specific profile action. These objects can be extended according to specific
vendor action feature. We will add additional action objects for vendor action feature. We will add additional action objects for
more generic network security functions. more generic network security functions.
6. YANG Module 6. YANG Module
6.1. IETF NSF-Facing Interface YANG Data Module 6.1. IETF NSF-Facing Interface YANG Data Module
This section introduces a YANG module for the information model of This section introduces a YANG module for the information model of
network security functions, as defined in the [i2nsf-nsf-cap-im]. network security functions, as defined in the [i2nsf-nsf-cap-im].
<CODE BEGINS> file "ietf-i2nsf-policy-rule-for-nsf@2018-07-02.yang" <CODE BEGINS> file "ietf-i2nsf-policy-rule-for-nsf@2018-11-04.yang"
module ietf-i2nsf-policy-rule-for-nsf { module ietf-i2nsf-policy-rule-for-nsf {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"; "urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf";
prefix prefix
policy-rule-for-nsf; policy-rule-for-nsf;
import ietf-inet-types{ import ietf-inet-types{
prefix inet; prefix inet;
skipping to change at page 13, line 21 skipping to change at page 13, line 28
Editor: Jaehoon Paul Jeong Editor: Jaehoon Paul Jeong
<mailto:pauljeong@skku.edu> <mailto:pauljeong@skku.edu>
Editor: Susan Hares Editor: Susan Hares
<mailto:shares@ndzh.com>"; <mailto:shares@ndzh.com>";
description description
"This module defines a YANG data module for network security "This module defines a YANG data module for network security
functions."; functions.";
revision "2018-07-02"{ revision "2018-11-04"{
description "The fourth revision"; description "The fourth revision";
reference reference
"draft-ietf-i2nsf-capability-00"; "draft-ietf-i2nsf-capability-04";
} }
typedef sec-event-format { typedef sec-event-format {
type enumeration { type enumeration {
enum unknown { enum unknown {
description description
"If SecEventFormat is unknown"; "If SecEventFormat is unknown";
} }
enum guid { enum guid {
description description
skipping to change at page 14, line 16 skipping to change at page 14, line 22
enum fqpn { enum fqpn {
description description
"If SecEventFormat is FQPN "If SecEventFormat is FQPN
(Fully Qualified Path Name)"; (Fully Qualified Path Name)";
} }
} }
description description
"This is used for SecEventFormat."; "This is used for SecEventFormat.";
} }
typedef priority-usage-type {
type enumeration {
enum priority-by-order {
description
"If priority type is order";
}
enum priority-by-number {
description
"If priority type is number";
}
}
description
"This is used for priority type.";
}
typedef ingress-action { typedef ingress-action {
type enumeration { type enumeration {
enum pass { enum pass {
description description
"If ingress action is pass"; "If ingress action is pass";
} }
enum drop { enum drop {
description description
"If ingress action is drop"; "If ingress action is drop";
} }
skipping to change at page 17, line 31 skipping to change at page 18, line 4
this user. The content and format are specified in this user. The content and format are specified in
the SecEventContent and SecEventFormat class the SecEventContent and SecEventFormat class
attributes, respectively. An example of the attributes, respectively. An example of the
SecEventContent attribute is string hrAdmin, SecEventContent attribute is string hrAdmin,
with the SecEventFormat attribute set to 1 (GUID) with the SecEventFormat attribute set to 1 (GUID)
and the SecEventType attribute set to 5 and the SecEventType attribute set to 5
(new logon)."; (new logon).";
} }
} }
container i2nsf-security-policy { container i2nsf-security-policy {
description description
"policy is a container "policy is a container
including a set of security rules according to certain logic, including a set of security rules according to certain logic,
i.e., their similarity or mutual relations, etc. The network i.e., their similarity or mutual relations, etc. The network
security policy is able to apply over both the unidirectional security policy is able to apply over both the unidirectional
and bidirectional traffic across the NSF."; and bidirectional traffic across the NSF.";
leaf policy-name { list system-policy {
key "system-policy-name";
description
"The system-policy represents there could be multiple system
policies in one NSF, and each system policy is used by
one virtual instance of the NSF/device.";
leaf system-policy-name {
type string; type string;
mandatory true;
description description
"The name of the policy. "The name of the policy.
This must be unique."; This must be unique.";
} }
leaf priority-usage {
type priority-usage-type;
mandatory true;
description
"This is priority type.";
}
list rules { list rules {
key "rule-name"; key "rule-name";
description description
"This is a rule for network security functions."; "This is a rule for network security functions.";
leaf rule-name { leaf rule-name {
type string; type string;
mandatory true; mandatory true;
description description
"The id of the rule. "The id of the rule.
skipping to change at page 19, line 9 skipping to change at page 19, line 46
False is not enbale."; False is not enbale.";
} }
leaf during { leaf during {
type uint16; type uint16;
description description
"This is during time."; "This is during time.";
} }
} }
leaf-list policy-event-clause-agg-ptr {
type instance-identifier;
must 'derived-from-or-self (/event-clause-container/
event-clause-list/entity-class, "ECA-EVENT-TYPE")';
description
"TBD";
}
leaf-list policy-condition-clause-agg-ptr {
type instance-identifier;
must 'derived-from-or-self (/condition-clause-container/
condition-clause-list/entity-class, "ECA-CONDITION-TYPE")';
description
"TBD";
}
leaf-list policy-action-clause-agg-ptr {
type instance-identifier;
must 'derived-from-or-self (/action-clause-container/
action-clause-list/entity-class, "ECA-ACTION-TYPE")';
description
"TBD";
}
container time-zone { container time-zone {
description description
"This can be used to apply rules according to time-zone"; "This can be used to apply rules according to time-zone";
container absolute-time-zone { container absolute-time-zone {
description description
"This can be used to apply rules according to "This can be used to apply rules according to
absolute-time"; absolute-time";
container time { container time {
description description
"This can be used to apply rules according to time"; "This can be used to apply rules according to time";
skipping to change at page 22, line 30 skipping to change at page 22, line 44
"This is november for periodic month"; "This is november for periodic month";
} }
leaf december { leaf december {
type boolean; type boolean;
description description
"This is december for periodic month"; "This is december for periodic month";
} }
} }
} }
} }
}
container resolution-strategy {
description
"The resolution strategies can be used to
specify how to resolve conflicts that occur between
the actions of the same or different policy rules that
are matched and contained in this particular NSF";
choice resolution-strategy-type {
description
"Vendors can use YANG data model to configure rules";
case fmr {
leaf first-matching-rule {
type boolean;
description
"If the resolution strategy is first matching rule";
}
}
case lmr {
leaf last-matching-rule {
type boolean;
description
"If the resolution strategy is last matching rule";
}
}
}
}
container default-action {
description
"This default action can be used to specify a predefined
action when no other alternative action was matched
by the currently executing I2NSF Policy Rule. An analogy
is the use of a default statement in a C switch statement.";
leaf default-action-type {
type boolean;
description
"True is permit
False is deny.";
}
}
container rule-group {
description
"This is rule group";
list groups {
key "group-name";
description
"This is a group for rules";
leaf group-name {
type string;
description
"This is a group for rules";
}
container rule-range {
description
"This is a rule range.";
leaf start-rule {
type string;
description
"This is a start rule";
}
leaf end-rule {
type string;
description
"This is a end rule";
}
}
leaf enable {
type boolean;
description
"This is enable
False is not enable.";
}
leaf description {
type string;
description
"This is a desription for rule-group";
}
}
}
}
container event-clause-container { container event-clause-container {
description "TBD"; description "TBD";
list event-clause-list { list event-clause-list {
key eca-object-id; key eca-object-id;
uses i2nsf-eca-object-type { uses i2nsf-eca-object-type {
refine entity-class { refine entity-class {
default ECA-EVENT-TYPE; default ECA-EVENT-TYPE;
} }
} }
description description
" This is abstract. An event is defined as any important " This is abstract. An event is defined as any important
occurrence in time of a change in the system being occurrence in time of a change in the system being
managed, and/or in the environment of the system being managed, and/or in the environment of the system being
managed. When used in the context of policy rules for managed. When used in the context of policy rules for
a flow-based NSF, it is used to determine whether the a flow-based NSF, it is used to determine whether the
Condition clause of the Policy Rule can be evaluated Condition clause of the Policy Rule can be evaluated
skipping to change at page 46, line 34 skipping to change at page 45, line 4
type string; type string;
description description
"Additional Inspection of "Additional Inspection of
Tracrt Attack."; Tracrt Attack.";
} }
} }
} }
} }
} }
} }
} }
} }
} }
}
<CODE ENDS> }
container resolution-strategy {
description
"The resolution strategies can be used to
specify how to resolve conflicts that occur between
the actions of the same or different policy rules that
are matched and contained in this particular NSF";
Figure 5: YANG Data Module of I2NSF NSF-Facing-Interface choice resolution-strategy-type {
description
"Vendors can use YANG data model to configure rules";
7. Security Considerations case fmr {
leaf first-matching-rule {
type boolean;
description
"If the resolution strategy is first matching rule";
}
}
case lmr {
leaf last-matching-rule {
type boolean;
description
"If the resolution strategy is last matching rule";
}
}
This document introduces no additional security threats and SHOULD }
follow the security requirements as stated in [RFC8329]. }
8. Acknowledgments container default-action {
description
"This default action can be used to specify a predefined
action when no other alternative action was matched
by the currently executing I2NSF Policy Rule. An analogy
is the use of a default statement in a C switch statement.";
This work was supported by Institute for Information & communications leaf default-action-type {
Technology Promotion (IITP) grant funded by the Korea government type boolean;
(MSIP) (No.R-20160222-002755, Cloud based Security Intelligence description
Technology Development for the Customized Security Service "True is permit
Provisioning). False is deny.";
}
9. Contributors }
I2NSF is a group effort. I2NSF has had a number of contributing container rule-group {
authors. The following are considered co-authors: description
"This is rule group";
o Hyoungshick Kim (Sungkyunkwan University) list groups {
key "group-name";
description
"This is a group for rules";
o Daeyoung Hyun (Sungkyunkwan University) leaf group-name {
type string;
description
"This is a group for rules";
}
o Dongjin Hong (Sungkyunkwan University) container rule-range {
description
"This is a rule range.";
o Liang Xia (Huawei) leaf start-rule {
type string;
description
"This is a start rule";
}
leaf end-rule {
type string;
description
"This is a end rule";
}
}
leaf enable {
type boolean;
description
"This is enable
False is not enable.";
}
leaf description {
type string;
description
"This is a desription for rule-group";
}
}
}
}
}
}
o Tae-Jin Ahn (Korea Telecom) <CODE ENDS>
o Se-Hui Lee (Korea Telecom) Figure 5: YANG Data Module of I2NSF NSF-Facing-Interface
10. References 7. Security Considerations
10.1. Normative References This document introduces no additional security threats and SHOULD
follow the security requirements as stated in [RFC8329].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, February 2018. Functions", RFC 8329, February 2018.
10.2. Informative References [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,
S., and N. Bahadur, "A YANG Data Model for Routing
Information Base (RIB)", RFC RFC8431, September 2018.
8.2. Informative References
[i2nsf-advanced-nsf-dm]
Pan, W. and L. Xia, "Configuration of Advanced Security
Functions with I2NSF Security Controller", draft-dong-
i2nsf-asf-config-01 (work in progress), October 2018.
[i2nsf-nsf-cap-im] [i2nsf-nsf-cap-im]
Xia, L., Strassner, J., Basile, C., and D. Lopez, Xia, L., Strassner, J., Basile, C., and D. Lopez,
"Information Model of NSFs Capabilities", draft-ietf- "Information Model of NSFs Capabilities", draft-ietf-
i2nsf-capability-00 (work in progress), September 2017. i2nsf-capability-04 (work in progress), October 2018.
[i2rs-rib-data-model]
Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,
S., and N. Bahadur, "A YANG Data Model for Routing
Information Base (RIB)", draft-ietf-i2rs-rib-data-model-10
(work in progress), February 2018.
[supa-policy-info-model] [supa-policy-info-model]
Strassner, J., Halpern, J., and S. Meer, "Generic Policy Strassner, J., Halpern, J., and S. Meer, "Generic Policy
Information Model for Simplified Use of Policy Information Model for Simplified Use of Policy
Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
model-03 (work in progress), May 2017. model-03 (work in progress), May 2017.
Appendix A. Changes from draft-ietf-i2nsf-nsf-facing-interface-dm-01 Appendix A. Changes from draft-ietf-i2nsf-nsf-facing-interface-dm-01
The following changes are made from draft-ietf-i2nsf-nsf-facing- The following changes are made from draft-ietf-i2nsf-nsf-facing-
interface-dm-00: interface-dm-01:
1. We added rule enable, session aging time, and long connection o We added system policy which represents there could be multiple
attributes. system policies in one NSF, and each system policy is used by one
virtual instance of the NSF/device. This is a very general
feature for all the NSFs/devices.
2. We added a rule group attribute. o We changed policy name to system policy name for system policy.
3. We added additional conditions such as application and url. o We deleted policy-event-clause-agg-ptr, policy-condition-clause-
agg-ptr, and policy-action-clause-agg-ptr.
4. We replaced manual to description to clarify the meaning. o We added priority-usage which represents priority of policies by
order or number.
Appendix B. Acknowledgments
This work was supported by Institute for Information & communications
Technology Promotion (IITP) grant funded by the Korea government
(MSIP) (No.R-20160222-002755, Cloud based Security Intelligence
Technology Development for the Customized Security Service
Provisioning).
Appendix C. Contributors
This document is made by the group effort of I2NSF working group.
Many people actively contributed to this document. The following are
considered co-authors:
o Hyoungshick Kim (Sungkyunkwan University)
o Daeyoung Hyun (Sungkyunkwan University)
o Dongjin Hong (Sungkyunkwan University)
o Liang Xia (Huawei)
o Tae-Jin Ahn (Korea Telecom)
o Se-Hui Lee (Korea Telecom)
Authors' Addresses Authors' Addresses
Jinyong Tim Kim Jinyong Tim Kim
Department of Computer Engineering Department of Computer Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
 End of changes. 60 change blocks. 
456 lines changed or deleted 483 lines changed or added

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