draft-ietf-i2nsf-capability-data-model-01.txt   draft-ietf-i2nsf-capability-data-model-02.txt 
Network Working Group S. Hares I2NSF Working Group S. Hares
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track J. Jeong Intended status: Standards Track J. Jeong
Expires: January 3, 2019 J. Kim Expires: May 8, 2019 J. Kim
Sungkyunkwan University Sungkyunkwan University
R. Moskowitz R. Moskowitz
HTT Consulting HTT Consulting
Q. Lin Q. Lin
Huawei Huawei
July 02, 2018 November 4, 2018
I2NSF Capability YANG Data Model I2NSF Capability YANG Data Model
draft-ietf-i2nsf-capability-data-model-01 draft-ietf-i2nsf-capability-data-model-02
Abstract Abstract
This document defines a YANG data model for capabilities that enable This document defines a YANG data model for capabilities that enable
an I2NSF user to control various Network Security Functions (NSFs) in a user to control various Network Security Functions (NSFs) in the
the framework for Interface to Network Security Functions (I2NSF). framework for Interface to Network Security Functions (I2NSF).
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 15 skipping to change at page 2, line 15
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. The Structure and Objective of NSF Capabilities . . . . . . . 6 5. The Structure and Objective of NSF Capabilities . . . . . . . 6
5.1. Generic Network Security Function Identification . . . . 6 5.1. Generic Network Security Function Identification . . . . 6
5.2. Event Capabilities . . . . . . . . . . . . . . . . . . . 6 5.2. Event Capabilities . . . . . . . . . . . . . . . . . . . 6
5.3. Condition Capabilities . . . . . . . . . . . . . . . . . 7 5.3. Condition Capabilities . . . . . . . . . . . . . . . . . 7
5.4. Action Capabilities . . . . . . . . . . . . . . . . . . . 7 5.4. Action Capabilities . . . . . . . . . . . . . . . . . . . 7
5.5. Resolution Strategy Capabilities . . . . . . . . . . . . 7 5.5. Resolution Strategy Capabilities . . . . . . . . . . . . 7
5.6. Default Action Capabilities . . . . . . . . . . . . . . . 7 5.6. Default Action Capabilities . . . . . . . . . . . . . . . 8
5.7. RPC for Acquiring Appropriate Network Security Function . 8 5.7. RPC for Acquiring Appropriate Network Security Function . 8
6. Data Model Structure . . . . . . . . . . . . . . . . . . . . 8 6. Data Model Structure . . . . . . . . . . . . . . . . . . . . 8
6.1. Network Security Function Identification . . . . . . . . 8 6.1. Network Security Function Identification . . . . . . . . 8
6.2. Capabilities of Generic Network Security Function . . . . 9 6.2. Capabilities of Generic Network Security Function . . . . 9
6.2.1. Event Capabilities . . . . . . . . . . . . . . . . . 9 6.2.1. Event Capabilities . . . . . . . . . . . . . . . . . 10
6.2.2. Condition Capabilities . . . . . . . . . . . . . . . 11 6.2.2. Condition Capabilities . . . . . . . . . . . . . . . 12
6.2.3. Action Capabilities . . . . . . . . . . . . . . . . . 14 6.2.3. Action Capabilities . . . . . . . . . . . . . . . . . 14
6.2.4. Resolution Strategy Capabilities . . . . . . . . . . 15 6.2.4. Resolution Strategy Capabilities . . . . . . . . . . 16
6.2.5. Content Security Capabilities . . . . . . . . . . . . 15 6.2.5. Capabilities of Advanced Network Security Function . 16
6.2.6. Attack Mitigation Capabilities . . . . . . . . . . . 16 6.2.6. Content Security Capabilities . . . . . . . . . . . . 17
6.2.7. RPC for Acquiring Appropriate Network Security 6.2.7. Attack Mitigation Capabilities . . . . . . . . . . . 18
Function . . . . . . . . . . . . . . . . . . . . . . 17 6.2.8. RPC for Acquiring Appropriate Network Security
7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 Function . . . . . . . . . . . . . . . . . . . . . . 19
7.1. I2NSF Capability YANG Data Module . . . . . . . . . . . . 18 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 7.1. I2NSF Capability YANG Data Module . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 9. Security Considerations . . . . . . . . . . . . . . . . . . . 57
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 10.1. Normative References . . . . . . . . . . . . . . . . . . 57
12.1. Normative References . . . . . . . . . . . . . . . . . . 53 10.2. Informative References . . . . . . . . . . . . . . . . . 57
12.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Example: Extended VoIP-VoLTE Security Function Appendix A. Example: Extended VoIP-VoLTE Security Function
Capabilities Module . . . . . . . . . . . . . . . . 55 Capabilities Module . . . . . . . . . . . . . . . . 59
Appendix B. Example: Configuration XML of Capability Module . . 56 Appendix B. Example: Configuration XML of Capability Module . . 60
B.1. Example: Configuration XML of Generic Network Security B.1. Example: Configuration XML of Generic Network Security
Function Capabilities . . . . . . . . . . . . . . . . . . 56 Function Capabilities . . . . . . . . . . . . . . . . . . 60
B.2. Example: Configuration XML of Extended VoIP/VoLTE B.2. Example: Configuration XML of Extended VoIP/VoLTE
Security Function Capabilities Module . . . . . . . . . . 58 Security Function Capabilities Module . . . . . . . . . . 62
Appendix C. Changes from draft-ietf-i2nsf-capability-data- Appendix C. Changes from draft-ietf-i2nsf-capability-data-
model-01 . . . . . . . . . . . . . . . . . . . . . . 59 model-01 . . . . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 64
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
As the industry becomes more sophisticated and network devices (e.g., As the industry becomes more sophisticated and network devices (e.g.,
Internet of Things, Self-driving vehicles, and VoIP/VoLTE Internet of Things, Self-driving vehicles, and VoIP/VoLTE
smartphones), service providers have a lot of problems mentioned in smartphones), service providers have a lot of problems mentioned in
[RFC8192]. To resolve these problems, [i2nsf-nsf-cap-im] specifies [RFC8192]. To resolve these problems, [i2nsf-nsf-cap-im] specifies
the information model of the capabilities of Network Security the information model of the capabilities of Network Security
Functions (NSFs). Functions (NSFs).
skipping to change at page 4, line 15 skipping to change at page 4, line 18
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-terminology][i2nsf-nsf-cap-im] [i2nsf-terminology][i2nsf-nsf-cap-im]
[i2rs-rib-data-model][supa-policy-info-model]. Especially, the [RFC8431][supa-policy-info-model]. Especially, the following terms
following terms are from [supa-policy-info-model]: 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 8, line 46 skipping to change at page 9, line 25
+--rw target-device +--rw target-device
| +--rw pc? boolean | +--rw pc? boolean
| +--rw mobile-phone? boolean | +--rw mobile-phone? boolean
| +--rw voip-volte-phone? boolean | +--rw voip-volte-phone? boolean
| +--rw tablet? boolean | +--rw tablet? boolean
| +--rw iot? boolean | +--rw iot? boolean
| +--rw vehicle? boolean | +--rw vehicle? boolean
+--rw generic-nsf-capabilities +--rw generic-nsf-capabilities
| +--rw net-sec-capabilities | +--rw net-sec-capabilities
| uses net-sec-caps | uses net-sec-caps
+--rw advanced-nsf-capabilities
| +--rw advaneced-sec-capabilities
| uses advaneced-sec-caps
+--rw complete-nsf-capabilities +--rw complete-nsf-capabilities
+--rw con-sec-control-capabilities +--rw con-sec-control-capabilities
| uses i2nsf-con-sec-control-caps | uses i2nsf-con-sec-control-caps
+--rw attack-mitigation-capabilities +--rw attack-mitigation-capabilities
uses i2nsf-attack-mitigation-control-caps uses i2nsf-attack-mitigation-control-caps
Figure 2: Data Model Structure for NSF-Identification Figure 2: Data Model Structure for NSF-Identification
This draft also utilizes the concepts originated in Basile, Lioy, This document also utilizes a formal model for policy reconciliation
Pitscheider, and Zhao[2015] concerning conflict resolution, use of proposed by Basile et al. [Policy-Reconciliation], which handles
external data, and target device. The authors are grateful to conflict resolution, the use of external data, and target device.
Cataldo for pointing out this excellent work.
The nsf-type object can be used for configuration about type of a The nsf-type object can be used for configuration about type of a
NSF. The types of NSF consists of Network Firewall, Web Application NSF. The types of NSF consists of Network Firewall, Web Application
Firewall, Anti-Virus, IDS, IPS, and DDoS Mitigator. The nsf-address Firewall, Anti-Virus, IDS, IPS, and DDoS Mitigator. The nsf-address
object can be used for configuration about location of a NSF. The object can be used for configuration about location of a NSF. The
target-device object can be used for configuration about target target-device object can be used for configuration about target
devices. We will add additional type of a NSF for more generic devices. We will add additional type of a NSF for more generic
network security functions. network security functions.
6.2. Capabilities of Generic Network Security Function 6.2. Capabilities of Generic Network Security Function
skipping to change at page 15, line 46 skipping to change at page 16, line 41
Figure 7: Data Model Structure for Resolution Strategy Capabilities Figure 7: Data Model Structure for Resolution Strategy Capabilities
of Network Security Function of Network Security Function
These objects are defined capabilities as first-matching-rule and These objects are defined capabilities as first-matching-rule and
last-matching-rule. These objects can be extended according to last-matching-rule. These objects can be extended according to
specific vendor resolution strategy features. We will add additional specific vendor resolution strategy features. We will add additional
resolution strategy objects for more generic network security resolution strategy objects for more generic network security
functions. functions.
6.2.5. Content Security Capabilities 6.2.5. Capabilities of Advanced Network Security Function
The data model for advanced NSF capabilities has the following
structure:
+--rw advanced-nsf-capabilities
| +--rw advanced-sec-capabilities
| +--rw antivirus
| | +--rw detect? boolean
| | +--rw exception-application? boolean
| | +--rw exception-signature? boolean
| | +--rw whitelists? boolean
| +--rw antiddos
| | +--rw syn-flood-action? boolean
| | +--rw udp-flood-action? boolean
| | +--rw http-flood-action? boolean
| | +--rw https-flood-action? boolean
| | +--rw dns-request-flood-action? boolean
| | +--rw dns-reply-flood-action? boolean
| | +--rw icmp-flood-action? boolean
| | +--rw sip-flood-action? boolean
| | +--rw detect-mode? boolean
| | +--rw baseline-learn? boolean
| +--rw ips
| +--rw signature-set? boolean
| +--rw exception-signature? boolean
...
Figure 8: Data Model Structure for Capabilities of Advanced Network
Security Function
These objects are defined capabilities of advanced network security
functions such as antivirus, antiddos, and ips. A detailed data
model for the configuration of the advanced network security
functions is described in [i2nsf-advanced-nsf-dm].
6.2.6. Content Security Capabilities
The data model for content security capabilities has the following The data model for content security capabilities has the following
structure: structure:
+--rw complete-nsf-capabilities +--rw complete-nsf-capabilities
+--rw con-sec-control-capabilities +--rw con-sec-control-capabilities
| +--rw anti-virus? boolean | +--rw anti-virus? boolean
| +--rw ips? boolean | +--rw ips? boolean
| +--rw ids? boolean | +--rw ids? boolean
| +--rw url-filter? boolean | +--rw url-filter? boolean
skipping to change at page 16, line 22 skipping to change at page 18, line 22
| +--rw mail-filter? boolean | +--rw mail-filter? boolean
| +--rw sql-filter? boolean | +--rw sql-filter? boolean
| +--rw file-blocking? boolean | +--rw file-blocking? boolean
| +--rw file-isolate? boolean | +--rw file-isolate? boolean
| +--rw pkt-capture? boolean | +--rw pkt-capture? boolean
| +--rw application-behavior? boolean | +--rw application-behavior? boolean
| +--rw voip-volte? boolean | +--rw voip-volte? boolean
+--rw attack-mitigation-capabilities +--rw attack-mitigation-capabilities
... ...
Figure 8: Data Model Structure for Content Security Capabilities of Figure 9: Data Model Structure for Content Security Capabilities of
Network Security Function Network Security Function
Content security is composed of a number of distinct security Content security is composed of a number of distinct security
Capabilities; each such Capability protects against a specific type Capabilities; each such Capability protects against a specific type
of threat in the application layer. Content security is a type of of threat in the application layer. Content security is a type of
Generic Network Security Function (GNSF), which summarizes a well- Generic Network Security Function (GNSF), which summarizes a well-
defined set of security Capabilities. defined set of security Capabilities.
6.2.6. Attack Mitigation Capabilities 6.2.7. Attack Mitigation Capabilities
The data model for attack mitigation capabilities has the following The data model for attack mitigation capabilities has the following
structure: structure:
+--rw complete-nsf-capabilities +--rw complete-nsf-capabilities
... ...
+--rw attack-mitigation-capabilities +--rw attack-mitigation-capabilities
+--rw (attack-mitigation-control-type)? +--rw (attack-mitigation-control-type)?
+--:(ddos-attack) +--:(ddos-attack)
| +--rw (ddos-attack-type)? | +--rw (ddos-attack-type)?
| +--:(network-layer-ddos-attack) | +--:(network-layer-ddos-attack)
| | +--rw network-layer-ddos-attack-types | | +--rw network-layer-ddos-attack-types
| | +--rw syn-flood-attack? boolean | | +--rw syn-flood-attack? boolean
| | +--rw udp-flood-attack? boolean | | +--rw udp-flood-attack? boolean
| | +--rw icmp-flood-attack? boolean | | +--rw icmp-flood-attack? boolean
| | +--rw ip-fragment-flood-attack? boolean | | +--rw ip-fragment-flood-attack? boolean
| | +--rw ipv6-related-attack? boolean | | +--rw ipv6-related-attack? boolean
| +--:(app-layer-ddos-attack) | +--:(app-layer-ddos-attack)
| +--rw app-layer-ddos-attack-types | +--rw app-layer-ddos-attack-types
| +--rw http-flood-attack? boolean | +--rw http-flood-attack? boolean
| +--rw https-flood-attack? boolean | +--rw https-flood-attack? boolean
| +--rw dns-flood-attack? boolean | +--rw dns-flood-attack? boolean
| +--rw dns-amp-flood-attack? boolean | +--rw dns-amp-flood-attack? boolean
| +--rw ssl-flood-attack? boolean | +--rw ssl-flood-attack? boolean
+--:(single-packet-attack) +--:(single-packet-attack)
+--rw (single-packet-attack-type)? +--rw (single-packet-attack-type)?
+--:(scan-and-sniff-attack) +--:(scan-and-sniff-attack)
| +--rw ip-sweep-attack? boolean | +--rw ip-sweep-attack? boolean
| +--rw port-scanning-attack? boolean | +--rw port-scanning-attack? boolean
+--:(malformed-packet-attack) +--:(malformed-packet-attack)
| +--rw ping-of-death-attack? boolean | +--rw ping-of-death-attack? boolean
| +--rw teardrop-attack? boolean | +--rw teardrop-attack? boolean
+--:(special-packet-attack) +--:(special-packet-attack)
+--rw oversized-icmp-attack? boolean +--rw oversized-icmp-attack? boolean
+--rw tracert-attack? boolean +--rw tracert-attack? boolean
Figure 9: Data Model Structure for Attack Mitigation Capabilities of Figure 10: Data Model Structure for Attack Mitigation Capabilities of
Network Security Function Network Security Function
Attack mitigation is composed of a number of GNSFs; each one protects Attack mitigation is composed of a number of GNSFs; each one protects
against a specific type of network attack. Attack Mitigation against a specific type of network attack. Attack Mitigation
security is a type of GNSF, which summarizes a well-defined set of security is a type of GNSF, which summarizes a well-defined set of
security Capabilities. security Capabilities.
6.2.7. RPC for Acquiring Appropriate Network Security Function 6.2.8. RPC for Acquiring Appropriate Network Security Function
The data model for RPC for Acquiring Appropriate Network Security The data model for RPC for Acquiring Appropriate Network Security
Function has the following structure: Function has the following structure:
rpcs: rpcs:
+---x call-appropriate-nsf +---x call-appropriate-nsf
+---w input +---w input
| +---w nsf-type nsf-type | +---w nsf-type nsf-type
| +---w target-device | +---w target-device
| +---w pc? boolean | +---w pc? boolean
skipping to change at page 18, line 24 skipping to change at page 20, line 24
| +---w iot? boolean | +---w iot? boolean
| +---w vehicle? boolean | +---w vehicle? boolean
+--ro output +--ro output
+--ro nsf-address +--ro nsf-address
+--ro (nsf-address-type)? +--ro (nsf-address-type)?
+--:(ipv4-address) +--:(ipv4-address)
| +--ro ipv4-address inet:ipv4-address | +--ro ipv4-address inet:ipv4-address
+--:(ipv6-address) +--:(ipv6-address)
+--ro ipv6-address inet:ipv6-address +--ro ipv6-address inet:ipv6-address
Figure 10: RPC for Acquiring Appropriate Network Security Function Figure 11: RPC for Acquiring Appropriate Network Security Function
This shows a RPC for acquiring an appropriate network security This shows a RPC for acquiring an appropriate network security
function according to type of NSF and/or target devices. If the SFF function according to type of NSF and/or target devices. If the SFF
[i2nsf-sfc]does not have the location information of network security [i2nsf-sfc]does not have the location information of network security
functions that it should send in own cache table, this can be used to functions that it should send in own cache table, this can be used to
acquire the information. These objects are defined as input data acquire the information. These objects are defined as input data
(i.e., NSF type and target devices) and output data (i.e., location (i.e., NSF type and target devices) and output data (i.e., location
information of NSF). information of NSF).
7. YANG Modules 7. YANG Modules
7.1. I2NSF Capability YANG Data Module 7.1. I2NSF Capability 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-capability@2018-07-02.yang" <CODE BEGINS> file "ietf-i2nsf-capability@2018-11-04.yang"
module ietf-i2nsf-capability { module ietf-i2nsf-capability {
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability";
prefix prefix
i2nsf-capability; i2nsf-capability;
import ietf-inet-types{ import ietf-inet-types{
prefix inet; prefix inet;
} }
skipping to change at page 19, line 31 skipping to change at page 21, line 31
Editor: Jaehoon Paul Jeong Editor: Jaehoon Paul Jeong
<mailto:pauljeong@skku.edu> <mailto:pauljeong@skku.edu>
Editor: Jinyong Tim Kim Editor: Jinyong Tim Kim
<mailto:timkim@skku.edu>"; <mailto:timkim@skku.edu>";
description description
"This module describes a capability model "This module describes a capability model
for I2NSF devices."; for I2NSF devices.";
revision "2018-07-02"{ revision "2018-11-04"{
description "The fifth revision"; description "The fifth revision";
reference reference
"draft-ietf-i2nsf-capability-00"; "draft-ietf-i2nsf-capability-04";
} }
grouping i2nsf-nsf-location { grouping i2nsf-nsf-location {
description description
"This provides a location for capabilities."; "This provides a location for capabilities.";
container nsf-address { container nsf-address {
description description
"This is location information for capabilities."; "This is location information for capabilities.";
choice nsf-address-type { choice nsf-address-type {
description description
skipping to change at page 46, line 45 skipping to change at page 48, line 45
leaf last-matching-rule { leaf last-matching-rule {
type boolean; type boolean;
description description
"If the resolution strategy is last matching rule"; "If the resolution strategy is last matching rule";
} }
} }
} }
} }
grouping i2nsf-advanced-sec-caps {
description
"i2nsf-advanced-sec-caps";
container advanced-sec-capabilities {
description
"net-sec-capabilities";
container antivirus {
description
"antivirus";
leaf detect {
type boolean;
description
"detect capability";
}
leaf exception-application {
type boolean;
description
"exception-application capability";
}
leaf exception-signature {
type boolean;
description
"exception-signature capability";
}
leaf whitelists {
type boolean;
description
"exception-signature capability";
}
}
container antiddos {
description
"antiddos";
leaf syn-flood-action {
type boolean;
description
"syn-flood-action capability";
}
leaf udp-flood-action {
type boolean;
description
"udp-flood-action capability";
}
leaf http-flood-action {
type boolean;
description
"http-flood-action capability";
}
leaf https-flood-action {
type boolean;
description
"https-flood-action capability";
}
leaf dns-request-flood-action {
type boolean;
description
"dns-request-flood-action capability";
}
leaf dns-reply-flood-action {
type boolean;
description
"dns-reply-flood-action capability";
}
leaf icmp-flood-action {
type boolean;
description
"icmp-flood-action capability";
}
leaf sip-flood-action {
type boolean;
description
"sip-flood-action capability";
}
leaf detect-mode {
type boolean;
description
"detect mode capability";
}
leaf baseline-learn {
type boolean;
description
"baseline-learn capability";
}
}
container ips {
description
"ips";
leaf signature-set {
type boolean;
description
"signature-set capability";
}
leaf exception-signature {
type boolean;
description
"exception-signature capability";
}
}
}
}
grouping i2nsf-con-sec-control-caps { grouping i2nsf-con-sec-control-caps {
description description
"i2nsf-con-sec-control-caps"; "i2nsf-con-sec-control-caps";
container con-sec-control-capabilities { container con-sec-control-capabilities {
description description
"content-security-control-capabilities"; "content-security-control-capabilities";
leaf anti-virus { leaf anti-virus {
type boolean; type boolean;
skipping to change at page 51, line 36 skipping to change at page 56, line 4
"nsf-name"; "nsf-name";
} }
uses capabilities-information; uses capabilities-information;
container generic-nsf-capabilities { container generic-nsf-capabilities {
description description
"generic-nsf-capabilities"; "generic-nsf-capabilities";
uses i2nsf-net-sec-caps; uses i2nsf-net-sec-caps;
} }
container advanced-nsf-capabilities {
description
"advanced-nsf-capabilities";
uses i2nsf-advanced-sec-caps;
}
container complete-nsf-capabilities { container complete-nsf-capabilities {
description description
"generic-nsf-capabilities"; "generic-nsf-capabilities";
uses i2nsf-con-sec-control-caps; uses i2nsf-con-sec-control-caps;
uses i2nsf-attack-mitigation-control-caps; uses i2nsf-attack-mitigation-control-caps;
} }
} }
skipping to change at page 52, line 25 skipping to change at page 56, line 43
uses i2nsf-it-resources; uses i2nsf-it-resources;
} }
output { output {
uses i2nsf-nsf-location; uses i2nsf-nsf-location;
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 11: YANG Data Module of I2NSF Capability Figure 12: YANG Data Module of I2NSF Capability
8. IANA Considerations 8. IANA Considerations
No IANA considerations exist for this document at this time. URL No IANA considerations exist for this document at this time. URL
will be added. will be added.
9. Security Considerations 9. Security Considerations
This document introduces no additional security threats and SHOULD This document introduces no additional security threats and SHOULD
follow the security requirements as stated in [RFC8329]. follow the security requirements as stated in [RFC8329].
10. Acknowledgments 10. References
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).
11. Contributors
I2NSF is a group effort. I2NSF has had a number of contributing
authors. 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 Jung-Soo Park (ETRI)
o Tae-Jin Ahn (Korea Telecom)
o Se-Hui Lee (Korea Telecom)
12. References
12.1. Normative References 10.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.
[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language",
RFC 7950, August 2016. RFC 7950, August 2016.
[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
and J. Jeong, "Interface to Network Security Functions and J. Jeong, "Interface to Network Security Functions
(I2NSF): Problem Statement and Use Cases", RFC 8192, July (I2NSF): Problem Statement and Use Cases", RFC 8192, July
2017. 2017.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, February 2018. Functions", RFC 8329, February 2018.
12.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.
10.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-01 (work in progress), April 2018. i2nsf-capability-04 (work in progress), October 2018.
[i2nsf-nsf-yang] [i2nsf-nsf-yang]
Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin,
"I2NSF Network Security Function-Facing Interface YANG "I2NSF Network Security Function-Facing Interface YANG
Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-00 Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-01
(work in progress), March 2018. (work in progress), July 2018.
[i2nsf-sfc] [i2nsf-sfc]
Hyun, S., Jeong, J., Park, J., and S. Hares, "Service Hyun, S., Jeong, J., Park, J., and S. Hares, "Service
Function Chaining-Enabled I2NSF Architecture", draft-hyun- Function Chaining-Enabled I2NSF Architecture", draft-hyun-
i2nsf-nsf-triggered-steering-05 (work in progress), March i2nsf-nsf-triggered-steering-06 (work in progress), July
2018. 2018.
[i2nsf-terminology] [i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF) Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-05 (work in Terminology", draft-ietf-i2nsf-terminology-06 (work in
progress), January 2018. progress), July 2018.
[i2rs-rib-data-model] [Policy-Reconciliation]
Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, Basile, C., Lioy, A., Pitscheider, C., and S. Zhao, "A
S., and N. Bahadur, "A YANG Data Model for Routing Formal Model of Policy Reconciliation",
Information Base (RIB)", draft-ietf-i2rs-rib-data-model-12 Euromicro Euromicro International Conference on Parallel,
(work in progress), April 2018. Distributed and Network-Based Processing (PDP), March
2015.
[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. Example: Extended VoIP-VoLTE Security Function Capabilities Appendix A. Example: Extended VoIP-VoLTE Security Function Capabilities
Module Module
skipping to change at page 56, line 16 skipping to change at page 60, line 16
leaf sip-header-user-agent { leaf sip-header-user-agent {
type boolean; type boolean;
description description
"SIP header user agent."; "SIP header user agent.";
} }
} }
} }
} }
Figure 12: Example: Extended VoIP-VoLTE Security Function Figure 13: Example: Extended VoIP-VoLTE Security Function
Capabilities Module Capabilities Module
Appendix B. Example: Configuration XML of Capability Module Appendix B. Example: Configuration XML of Capability Module
This section gives a xml examples for a configuration of Capability This section gives a xml examples for a configuration of Capability
module according to a requirement. module according to a requirement.
B.1. Example: Configuration XML of Generic Network Security Function B.1. Example: Configuration XML of Generic Network Security Function
Capabilities Capabilities
skipping to change at page 57, line 51 skipping to change at page 61, line 51
<alert>true</alert> <alert>true</alert>
</ingress-action-type> </ingress-action-type>
</action> </action>
</net-sec-control-capabilities> </net-sec-control-capabilities>
</generic-nsf-capabilities> </generic-nsf-capabilities>
</nsf> </nsf>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
Figure 13: Example: Configuration XML for Generic Network Security Figure 14: Example: Configuration XML for Generic Network Security
Function Capability Function Capability
B.2. Example: Configuration XML of Extended VoIP/VoLTE Security B.2. Example: Configuration XML of Extended VoIP/VoLTE Security
Function Capabilities Module Function Capabilities Module
This section gives a xml example for extended VoIP-VoLTE security This section gives a xml example for extended VoIP-VoLTE security
function capabilities (See Figure 12) configuration according to a function capabilities (See Figure 13) configuration according to a
requirement. requirement.
Requirement: Register VoIP/VoLTe security function according to Requirement: Register VoIP/VoLTe security function according to
requirements. requirements.
1. The location of the NSF is 221.159.112.151. 1. The location of the NSF is 221.159.112.151.
2. The NSF can obtain the best effect if the packet was generated by 2. The NSF can obtain the best effect if the packet was generated by
VoIP-VoLTE phone. VoIP-VoLTE phone.
skipping to change at page 59, line 38 skipping to change at page 63, line 38
<alert>true</alert> <alert>true</alert>
</ingress-action-type> </ingress-action-type>
</action> </action>
</net-sec-control-capabilities> </net-sec-control-capabilities>
</generic-nsf-capabilities> </generic-nsf-capabilities>
</nsf> </nsf>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
Figure 14: Example: Configuration XML for Extended VoIP/VoLTE Figure 15: Example: Configuration XML for Extended VoIP/VoLTE
Security Function Capabilities Security Function Capabilities
Appendix C. Changes from draft-ietf-i2nsf-capability-data-model-01 Appendix C. Changes from draft-ietf-i2nsf-capability-data-model-01
The following changes are made from draft-ietf-i2nsf-capability-data- The following changes are made from draft-ietf-i2nsf-capability-data-
model-00: model-01:
1. We have clarified and simplified capabilities. o We added capabilities of advanced network security functions such
as anti-virus, anti-ddos, and IPS.
2. We added additional condition capabilities for application and Appendix D. Acknowledgments
url.
3. We replaced unnecessary leaf-list component to leaf component. 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).
4. We replaced the list component to the container component for Appendix E. Contributors
net-sec-capabilities.
5. We modified the choice-case structure into a container structure This document is made by the group effort of I2NSF working group.
to allow for the selection of multiple catalogues for condition Many people actively contributed to this document. The following are
and action clauses. considered co-authors:
6. We added complete-nsf-capabilities such as content capabilities o Hyoungshick Kim (Sungkyunkwan University)
and attack mitigation capabilities.
o Daeyoung Hyun (Sungkyunkwan University)
o Dongjin Hong (Sungkyunkwan University)
o Liang Xia (Huawei)
o Jung-Soo Park (ETRI)
o Tae-Jin Ahn (Korea Telecom)
o Se-Hui Lee (Korea Telecom)
Authors' Addresses Authors' Addresses
Susan Hares Susan Hares
Huawei Huawei
7453 Hickory Hill 7453 Hickory Hill
Saline, MI 48176 Saline, MI 48176
USA USA
Phone: +1-734-604-0332 Phone: +1-734-604-0332
 End of changes. 50 change blocks. 
136 lines changed or deleted 286 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/