draft-ietf-i2nsf-nsf-facing-interface-dm-03.txt   draft-ietf-i2nsf-nsf-facing-interface-dm-04.txt 
I2NSF 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: September 12, 2019 J. Park Expires: September 25, 2019 J. Park
ETRI ETRI
S. Hares S. Hares
Q. Lin Q. Lin
Huawei Huawei
March 11, 2019 March 24, 2019
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-03 draft-ietf-i2nsf-nsf-facing-interface-dm-04
Abstract Abstract
This document defines a YANG data model for configuring security This document defines a YANG data model for configuring security
policy rules on network security functions. The YANG data model in policy rules on network security functions. The YANG data model in
this document is corresponding to the information model for Network this document is corresponding to 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). Security Functions (I2NSF).
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on September 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
4. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 4. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4
4.1. General I2NSF Security Policy Rule . . . . . . . . . . . 4 4.1. General I2NSF Security Policy Rule . . . . . . . . . . . 4
4.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Condtion Clause . . . . . . . . . . . . . . . . . . . . . 7 4.3. Condtion Clause . . . . . . . . . . . . . . . . . . . . . 7
4.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 13
5. YANG Data Module . . . . . . . . . . . . . . . . . . . . . . 13 5. YANG Data Module . . . . . . . . . . . . . . . . . . . . . . 14
5.1. I2NSF NSF-Facing Interface YANG Data Module . . . . . . . 13 5.1. I2NSF NSF-Facing Interface YANG Data Module . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88
7. Security Considerations . . . . . . . . . . . . . . . . . . . 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 88
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.1. Normative References . . . . . . . . . . . . . . . . . . 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 89
8.2. Informative References . . . . . . . . . . . . . . . . . 79 8.2. Informative References . . . . . . . . . . . . . . . . . 90
Appendix A. Configuration Examples . . . . . . . . . . . . . . . 81 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 91
A.1. Security Requirement 1: Block SNS Access during Business A.1. Security Requirement 1: Block SNS Access during Business
Hours . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Hours . . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.2. Security Requirement 2: Block Malicious VoIP/VoLTE A.2. Security Requirement 2: Block Malicious VoIP/VoLTE
Packets Coming to the Company . . . . . . . . . . . . . . 84 Packets Coming to the Company . . . . . . . . . . . . . . 94
A.3. Security Requirement 3: Mitigate HTTP and HTTPS Flood A.3. Security Requirement 3: Mitigate HTTP and HTTPS Flood
Attacks on a Company Web Server . . . . . . . . . . . . . 87 Attacks on a Company Web Server . . . . . . . . . . . . . 97
Appendix B. Changes from draft-ietf-i2nsf-nsf-facing-interface- Appendix B. Changes from draft-ietf-i2nsf-nsf-facing-interface-
dm-02 . . . . . . . . . . . . . . . . . . . . . . . 90 dm-03 . . . . . . . . . . . . . . . . . . . . . . . 100
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 91 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 100
Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 91 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 100
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101
1. Introduction 1. Introduction
This document defines a YANG [RFC6020][RFC7950] data model for This document defines a YANG [RFC6020][RFC7950] data model for
security policy rule configuration of network security devices. The security policy rule configuration of network security devices. The
YANG data model is corresponding to the information model YANG data model is corresponding to the information model
[i2nsf-nsf-cap-im] for Network Security Functions (NSF) facing [i2nsf-nsf-cap-im] for Network Security Functions (NSF) facing
interface in Interface to Network Security Functions (I2NSF). The interface in Interface to Network Security Functions (I2NSF). The
YANG data model in this document focuses on security policy YANG data model in this document focuses on security policy
configuration for generic network security functions. Note that configuration for generic network security functions. Note that
skipping to change at page 5, line 13 skipping to change at page 5, line 13
policy rule. policy rule.
module: ietf-i2nsf-policy-rule-for-nsf module: ietf-i2nsf-policy-rule-for-nsf
+--rw i2nsf-security-policy +--rw i2nsf-security-policy
+--rw system-policy* [system-policy-name] +--rw system-policy* [system-policy-name]
+--rw system-policy-name string +--rw system-policy-name string
+--rw priority-usage? identityref +--rw priority-usage? identityref
+--rw resolution-strategy? identityref +--rw resolution-strategy? identityref
+--rw default-action? identityref +--rw default-action? identityref
+--rw rules* [rule-name] +--rw rules* [rule-name]
+--rw rule-name string | +--rw rule-name string
+--rw rule-description? string | +--rw rule-description? string
+--rw rule-priority? uint8 | +--rw rule-priority? uint8
+--rw rule-enable? boolean | +--rw rule-enable? boolean
+--rw time-zone | +--rw rule-session-aging-time? uint16
| +--rw absolute-time-zone | +--rw rule-long-connection
| | +--rw start-time? start-time-type | | +--rw enable? boolean
| | +--rw end-time? end-time-type | | +--rw during? uint16
| +--rw periodic-time-zone | +--rw time-zone
| +--rw day | | +--rw absolute-time-zone
| | +--rw every-day? boolean | | | +--rw start-time? start-time-type
| | +--rw specific-day* day-type | | | +--rw end-time? end-time-type
| +--rw month | | +--rw periodic-time-zone
| +--rw every-month? boolean | | +--rw day
| +--rw specific-month* month-type | | | +--rw every-day? boolean
+--rw event-clause-container | | | +--rw specific-day* day-type
| ... | | +--rw month
+--rw condition-clause-container | | +--rw every-month? boolean
| ... | | +--rw specific-month* month-type
+--rw action-clause-container | +--rw event-clause-container
... | | ...
| +--rw condition-clause-container
| | ...
| +--rw action-clause-container
| ...
+--rw rule-group
+--rw groups* [group-name]
+--rw group-name string
+--rw rule-range
| +--rw start-rule? string
| +--rw end-rule? string
+--rw enable? boolean
Figure 1: YANG Tree Diagram for Network Security Policy Figure 1: YANG Tree Diagram for Network Security Policy
This YANG tree diagram shows general I2NSF security policy rule for This YANG tree diagram shows general I2NSF security policy rule for
generic network security functions. generic network security functions.
The system policy represents there could be multiple system policies The system policy represents there could be multiple system policies
in one NSF, and each system policy is used by one virtual instance of in one NSF, and each system policy is used by one virtual instance of
the NSF/device. The system policy includes system policy name, the NSF/device. The system policy includes system policy name,
priority usage, resolutation strategy, default action, and rules. priority usage, resolutation strategy, default action, and rules.
skipping to change at page 6, line 27 skipping to change at page 7, line 10
4.2. Event Clause 4.2. Event Clause
This section shows YANG tree diagram for an event clause of I2NSF This section shows YANG tree diagram for an event clause of I2NSF
security policy rule. security policy rule.
module: ietf-i2nsf-policy-rule-for-nsf module: ietf-i2nsf-policy-rule-for-nsf
+--rw i2nsf-security-policy +--rw i2nsf-security-policy
+--rw system-policy* [system-policy-name] +--rw system-policy* [system-policy-name]
... ...
+--rw rules* [rule-name] +--rw rules* [rule-name]
| ...
| +--rw event-clause-container
| | +--rw event-clause-description? string
| | +--rw event-clauses
| | +--rw system-event* identityref
| | +--rw system-alarm* identityref
| +--rw condition-clause-container
| | ...
| +--rw action-clause-container
| ...
+--rw rule-group
... ...
+--rw event-clause-container
| +--rw event-clause-description? string
| +--rw event-clauses
| +--rw system-event* identityref
| +--rw system-alarm* identityref
+--rw condition-clause-container
| ...
+--rw action-clause-container
...
Figure 2: YANG Tree Diagram for Network Security Policy Figure 2: YANG Tree Diagram for Network Security Policy
This YANG tree diagram shows an event clause of I2NSF security policy This YANG tree diagram shows an event clause of I2NSF security policy
rule for generic network security functions. An event clause is any rule for generic network security functions. An event clause is any
important occurrence in time of a change in the system being managed, important occurrence in time of a change in the system being managed,
and/or in the environment of the system being managed. An event and/or in the environment of the system being managed. An event
clause is used to trigger the evaluation of the condition clause of clause is used to trigger the evaluation of the condition clause of
the I2NSF Policy Rule. The event clause is defined as system event the I2NSF Policy Rule. The event clause is defined as system event
and system alarm. The event clause can be extended according to and system alarm. The event clause can be extended according to
skipping to change at page 11, line 40 skipping to change at page 12, line 23
| | +--rw pkt-sec-icmp-type* identityref | | +--rw pkt-sec-icmp-type* identityref
| +--rw packet-security-http-condition | +--rw packet-security-http-condition
| | +--rw pkt-sec-uri-content* string | | +--rw pkt-sec-uri-content* string
| | +--rw pkt-sec-url-content* string | | +--rw pkt-sec-url-content* string
| +--rw packet-security-voice-condition | +--rw packet-security-voice-condition
| | +--rw pkt-sec-src-voice-id* string | | +--rw pkt-sec-src-voice-id* string
| | +--rw pkt-sec-dest-voice-id* string | | +--rw pkt-sec-dest-voice-id* string
| | +--rw pkt-sec-user-agent* string | | +--rw pkt-sec-user-agent* string
| +--rw packet-security-ddos-condition | +--rw packet-security-ddos-condition
| +--rw pkt-sec-alert-rate? uint32 | +--rw pkt-sec-alert-rate? uint32
| | +--rw packet-payload-condition
| | | +--rw packet-payload-description? string
| | | +--rw pkt-payload-content* string
| | +--rw acl-number* uint32
| | +--rw application-condition
| | | +--rw application-description? string
| | | +--rw application-object* string
| | | +--rw application-group* string
| | | +--rw application-label* string
| | | +--rw category
| | | +--rw application-category*
[name application-subcategory]
| | | +--rw name string
| | | +--rw application-subcategory string
| | +--rw target-condition
| | | +--rw target-description? string
| | | +--rw device-sec-context-cond
| | | +--rw target-device* identityref
| | +--rw users-condition
| | | +--rw users-description? string
| | | +--rw user
| | | | +--rw (user-name)?
| | | | +--:(tenant)
| | | | | +--rw tenant uint8
| | | | +--:(vn-id)
| | | | +--rw vn-id uint8
| | | +--rw group
| | | | +--rw (group-name)?
| | | | +--:(tenant)
| | | | | +--rw tenant uint8
| | | | +--:(vn-id)
| | | | +--rw vn-id uint8
| | | +--rw security-grup string
| | +--rw url-category-condition
| | | +--rw url-category-description? string
| | | +--rw pre-defined-category* string
| | | +--rw user-defined-category* string
| | +--rw context-condition
| | | +--rw context-description? string
| | +--rw gen-context-condition
| | +--rw gen-context-description? string
| | +--rw geographic-location
| | +--rw src-geographic-location* uint32
| | +--rw dest-geographic-location* uint32
+--rw action-clause-container +--rw action-clause-container
... ...
Figure 3: YANG Tree Diagram for Network Security Policy Figure 3: YANG Tree Diagram for Network Security Policy
This YANG tree diagram shows an condition clause of I2NSF security This YANG tree diagram shows an condition clause of I2NSF security
policy rule for generic network security functions. A condition policy rule for generic network security functions. A condition
clause is defined as a set of attributes, features, and/or values clause is defined as a set of attributes, features, and/or values
that are to be compared with a set of known attributes, features, that are to be compared with a set of known attributes, features,
and/or values in order to determine whether or not the set of actions and/or values in order to determine whether or not the set of actions
skipping to change at page 13, line 16 skipping to change at page 14, line 44
according to specific vendor action features. The action clause is according to specific vendor action features. The action clause is
described in detail in [i2nsf-nsf-cap-im]. described in detail in [i2nsf-nsf-cap-im].
5. YANG Data Module 5. YANG Data Module
5.1. I2NSF NSF-Facing Interface YANG Data Module 5.1. I2NSF NSF-Facing Interface YANG Data Module
This section introduces an YANG data module for configuration of This section introduces an YANG data module for configuration of
security policy rules on network security functions. security policy rules on network security functions.
<CODE BEGINS> file "ietf-i2nsf-policy-rule-for-nsf@2019-03-11.yang" <CODE BEGINS> file "ietf-i2nsf-policy-rule-for-nsf@2019-03-24.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
iiprfn; iiprfn;
import ietf-inet-types{ import ietf-inet-types{
prefix inet; prefix inet;
skipping to change at page 14, line 26 skipping to change at page 16, line 5
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 8341; see This version of this YANG module is part of RFC 8341; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2019-03-11"{ revision "2019-03-24"{
description "Initial revision."; description "Initial revision.";
reference reference
"RFC XXXX: I2NSF Network Security Function-Facing Interface "RFC XXXX: I2NSF Network Security Function-Facing Interface
YANG Data Model"; YANG Data Model";
} }
/* /*
* Identities * Identities
*/ */
skipping to change at page 39, line 42 skipping to change at page 41, line 18
identity multiple-interfaces-satisfy-query { identity multiple-interfaces-satisfy-query {
base icmp-type; base icmp-type;
description description
"Identity for multiple interfaces satisfy query "Identity for multiple interfaces satisfy query
in extended echo reply types"; in extended echo reply types";
reference reference
"RFC 792: Internet Control Message Protocol "RFC 792: Internet Control Message Protocol
RFC 8335: PROBE: A Utility for Probing Interfaces"; RFC 8335: PROBE: A Utility for Probing Interfaces";
} }
identity target-device {
description
"Base identity for target devices";
reference
"draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities";
}
identity pc {
base target-device;
description
"Identity for pc";
}
identity mobile-phone {
base target-device;
description
"Identity for mobile-phone";
}
identity voip-volte-phone {
base target-device;
description
"Identity for voip-volte-phone";
}
identity tablet {
base target-device;
description
"Identity for tablet";
}
identity iot {
base target-device;
description
"Identity for IoT";
}
identity vehicle {
base target-device;
description
"Identity for vehicle";
}
identity content-security-control { identity content-security-control {
description description
"Base identity for content security control"; "Base identity for content security control";
reference reference
"RFC 8329: Framework for Interface to "RFC 8329: Framework for Interface to
Network Security Functions - Differences Network Security Functions - Differences
from ACL Data Models from ACL Data Models
draft-ietf-i2nsf-capability-04: Information Model draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities"; of NSFs Capabilities";
} }
skipping to change at page 56, line 8 skipping to change at page 58, line 31
numeric value which can range from 1 till 255."; numeric value which can range from 1 till 255.";
} }
leaf rule-enable { leaf rule-enable {
type boolean; type boolean;
description description
"True is enable. "True is enable.
False is not enbale."; False is not enbale.";
} }
leaf session-aging-time {
type uint16;
description
"This is session aging time.";
}
container long-connection {
description
"This is long-connection";
leaf enable {
type boolean;
description
"True is enable.
False is not enbale.";
}
leaf during {
type uint16;
description
"This is during time.";
}
}
container time-zone { container time-zone {
description description
"Time zone when the rules are applied"; "Time zone when the rules are applied";
container absolute-time-zone { container absolute-time-zone {
description description
"Rule execution according to absolute time"; "Rule execution according to absolute time";
leaf start-time { leaf start-time {
type start-time-type; type start-time-type;
default right-away; default right-away;
skipping to change at page 59, line 23 skipping to change at page 62, line 23
container packet-security-ipv4-condition { container packet-security-ipv4-condition {
description description
"The purpose of this container is to represent IPv4 "The purpose of this container is to represent IPv4
packet header information to determine if the set packet header information to determine if the set
of policy actions in this ECA policy rule should be of policy actions in this ECA policy rule should be
executed or not."; executed or not.";
reference reference
"RFC 791: Internet Protocol"; "RFC 791: Internet Protocol";
leaf ipv4-description {
type string;
description
"This is description for ipv4 condition.";
}
container pkt-sec-ipv4-header-length { container pkt-sec-ipv4-header-length {
choice match-type { choice match-type {
description description
"There are two types to configure a security "There are two types to configure a security
policy for IPv4 header length, such as exact match policy for IPv4 header length, such as exact match
and range match."; and range match.";
case exact-match { case exact-match {
leaf-list ipv4-header-length { leaf-list ipv4-header-length {
type uint8 { type uint8 {
range "5..15"; range "5..15";
skipping to change at page 65, line 5 skipping to change at page 68, line 10
container packet-security-ipv6-condition { container packet-security-ipv6-condition {
description description
"The purpose of this container is to represent "The purpose of this container is to represent
IPv6 packet header information to determine IPv6 packet header information to determine
if the set of policy actions in this ECA policy if the set of policy actions in this ECA policy
rule should be executed or not."; rule should be executed or not.";
reference reference
"RFC 2460: Internet Protocol, Version 6 (IPv6) "RFC 2460: Internet Protocol, Version 6 (IPv6)
Specification"; Specification";
leaf ipv6-description {
type string;
description
"This is description for ipv6 condition.";
}
leaf-list pkt-sec-ipv6-traffic-class { leaf-list pkt-sec-ipv6-traffic-class {
type identityref { type identityref {
base traffic-class; base traffic-class;
} }
description description
"The security policy rule according to "The security policy rule according to
IPv6 traffic class."; IPv6 traffic class.";
reference reference
"RFC 2460: Internet Protocol, Version 6 (IPv6) "RFC 2460: Internet Protocol, Version 6 (IPv6)
Specification - Traffic class"; Specification - Traffic class";
skipping to change at page 68, line 38 skipping to change at page 72, line 5
container packet-security-tcp-condition { container packet-security-tcp-condition {
description description
"The purpose of this container is to represent "The purpose of this container is to represent
TCP packet header information to determine TCP packet header information to determine
if the set of policy actions in this ECA policy if the set of policy actions in this ECA policy
rule should be executed or not."; rule should be executed or not.";
reference reference
"RFC 793: Transmission Control Protocol"; "RFC 793: Transmission Control Protocol";
leaf tcp-description {
type string;
description
"This is description for tcp condition.";
}
container pkt-sec-tcp-src-port-num { container pkt-sec-tcp-src-port-num {
uses pkt-sec-port-number; uses pkt-sec-port-number;
description description
"The security policy rule according to "The security policy rule according to
tcp source port number."; tcp source port number.";
reference reference
"RFC 793: Transmission Control Protocol "RFC 793: Transmission Control Protocol
- Port number"; - Port number";
} }
skipping to change at page 72, line 9 skipping to change at page 75, line 29
container packet-security-udp-condition { container packet-security-udp-condition {
description description
"The purpose of this container is to represent "The purpose of this container is to represent
UDP packet header information to determine UDP packet header information to determine
if the set of policy actions in this ECA policy if the set of policy actions in this ECA policy
rule should be executed or not."; rule should be executed or not.";
reference reference
"RFC 793: Transmission Control Protocol"; "RFC 793: Transmission Control Protocol";
leaf udp-description {
type string;
description
"This is description for udp condition.";
}
container pkt-sec-udp-src-port-num { container pkt-sec-udp-src-port-num {
uses pkt-sec-port-number; uses pkt-sec-port-number;
description description
"The security policy rule according to "The security policy rule according to
udp source port number."; udp source port number.";
reference reference
"RFC 793: Transmission Control Protocol "RFC 793: Transmission Control Protocol
- Port number"; - Port number";
} }
skipping to change at page 73, line 32 skipping to change at page 77, line 11
container packet-security-icmp-condition { container packet-security-icmp-condition {
description description
"The purpose of this container is to represent "The purpose of this container is to represent
ICMP packet header information to determine ICMP packet header information to determine
if the set of policy actions in this ECA policy if the set of policy actions in this ECA policy
rule should be executed or not."; rule should be executed or not.";
reference reference
"RFC 792: Internet Control Message Protocol "RFC 792: Internet Control Message Protocol
RFC 8335: PROBE: A Utility for Probing Interfaces"; RFC 8335: PROBE: A Utility for Probing Interfaces";
leaf icmp-description {
type string;
description
"This is description for icmp condition.";
}
leaf-list pkt-sec-icmp-type-and-code { leaf-list pkt-sec-icmp-type-and-code {
type identityref { type identityref {
base icmp-type; base icmp-type;
} }
description description
"The security policy rule according to "The security policy rule according to
ICMP parameters."; ICMP parameters.";
reference reference
"RFC 792: Internet Control Message Protocol "RFC 792: Internet Control Message Protocol
RFC 8335: PROBE: A Utility for Probing Interfaces"; RFC 8335: PROBE: A Utility for Probing Interfaces";
} }
} }
container packet-security-http-condition { container packet-security-http-condition {
description description
"Condition for http."; "Condition for http.";
leaf http-description {
type string;
description
"This is description for http condition.";
}
leaf-list pkt-sec-uri-content { leaf-list pkt-sec-uri-content {
type string; type string;
description description
"The security policy rule according to "The security policy rule according to
uri content."; uri content.";
} }
leaf-list pkt-sec-url-content { leaf-list pkt-sec-url-content {
type string; type string;
description description
skipping to change at page 74, line 32 skipping to change at page 78, line 23
security rules controlled by a centralized security rules controlled by a centralized
server for VoIP/VoLTE security service server for VoIP/VoLTE security service
(called VoIP IPS). The VoIP/VoLTE security (called VoIP IPS). The VoIP/VoLTE security
system controls each switch for the system controls each switch for the
VoIP/VoLTE call flow management by VoIP/VoLTE call flow management by
manipulating the rules that can be added, manipulating the rules that can be added,
deleted, or modified dynamically."; deleted, or modified dynamically.";
reference reference
"RFC 3261: SIP: Session Initiation Protocol"; "RFC 3261: SIP: Session Initiation Protocol";
leaf voice-description {
type string;
description
"This is description for voice condition.";
}
leaf-list pkt-sec-src-voice-id { leaf-list pkt-sec-src-voice-id {
type string; type string;
description description
"The security policy rule according to "The security policy rule according to
a source voice ID for VoIP and VoLTE."; a source voice ID for VoIP and VoLTE.";
} }
leaf-list pkt-sec-dest-voice-id { leaf-list pkt-sec-dest-voice-id {
type string; type string;
description description
skipping to change at page 75, line 4 skipping to change at page 78, line 49
"The security policy rule according to "The security policy rule according to
a destination voice ID for VoIP and VoLTE."; a destination voice ID for VoIP and VoLTE.";
} }
leaf-list pkt-sec-user-agent { leaf-list pkt-sec-user-agent {
type string; type string;
description description
"The security policy rule according to "The security policy rule according to
an user agent for VoIP and VoLTE."; an user agent for VoIP and VoLTE.";
} }
} }
container packet-security-ddos-condition { container packet-security-ddos-condition {
description description
"Condition for DDoS attack."; "Condition for DDoS attack.";
leaf ddos-description {
type string;
description
"This is description for ddos condition.";
}
leaf pkt-sec-alert-rate { leaf pkt-sec-alert-rate {
type uint32; type uint32;
description description
"The alert rate of flood detect for "The alert rate of flood detect for
same packets."; same packets.";
} }
} }
}
container packet-payload-condition {
description
"Condition for packet payload";
leaf packet-payload-description {
type string;
description
"This is description for payload condition.
Vendors can write instructions for payload condition
that vendor made";
}
leaf-list pkt-payload-content {
type string;
description
"The content keyword is very important in
signatures. Between the quotation marks you
can write on what you would like the
signature to match.";
}
}
leaf-list acl-number {
type uint32;
description
"This is acl-number.";
}
container application-condition {
description
"Condition for application";
leaf application-description {
type string;
description
"This is description for application condition.";
}
leaf-list application-object {
type string;
description
"This is application object.";
}
leaf-list application-group {
type string;
description
"This is application group.";
}
leaf-list application-label {
type string;
description
"This is application label.";
}
container category {
description
"This is application category";
list application-category {
key "name application-subcategory";
description
"This is application category list";
leaf name {
type string;
description
"This is name for application category.";
}
leaf application-subcategory {
type string;
description
"This is application subcategory.";
}
}
}
}
container target-condition {
description
"Condition for target";
leaf target-description {
type string;
description
"This is description for target condition.
Vendors can write instructions for target condition
that vendor made";
}
container device-sec-context-cond {
description
"The device attribute that can identify a device,
including the device type (i.e., router, switch,
pc, ios, or android) and the device's owner as
well.";
leaf-list target-device {
type identityref {
base target-device;
}
description
"Leaf list for target devices";
}
}
}
container users-condition {
description
"Condition for users";
leaf users-description {
type string;
description
"This is description for user condition.
Vendors can write instructions for user condition
that vendor made";
}
container user{
description
"The user (or user group) information with which
network flow is associated: The user has many
attributes such as name, id, password, type,
authentication mode and so on. Name/id is often
used in the security policy to identify the user.
Besides, NSF is aware of the IP address of the
user provided by a unified user management system
via network. Based on name-address association,
NSF is able to enforce the security functions
over the given user (or user group)";
choice user-name {
description
"The name of the user.
This must be unique.";
case tenant {
description
"Tenant information.";
leaf tenant {
type uint8;
mandatory true;
description
"User's tenant information.";
}
}
case vn-id {
description
"VN-ID information.";
leaf vn-id {
type uint8;
mandatory true;
description
"User's VN-ID information.";
}
}
}
}
container group {
description
"The user (or user group) information with which
network flow is associated: The user has many
attributes such as name, id, password, type,
authentication mode and so on. Name/id is often
used in the security policy to identify the user.
Besides, NSF is aware of the IP address of the
user provided by a unified user management system
via network. Based on name-address association,
NSF is able to enforce the security functions
over the given user (or user group)";
choice group-name {
description
"The name of the user.
This must be unique.";
case tenant {
description
"Tenant information.";
leaf tenant {
type uint8;
mandatory true;
description
"User's tenant information.";
}
}
case vn-id {
description
"VN-ID information.";
leaf vn-id {
type uint8;
mandatory true;
description
"User's VN-ID information.";
}
}
}
}
leaf security-grup {
type string;
mandatory true;
description
"security-grup.";
}
}
container url-category-condition {
description
"Condition for url category";
leaf url-category-description {
type string;
description
"This is description for url category condition.
Vendors can write instructions for context condition
that vendor made";
}
leaf-list pre-defined-category {
type string;
description
"This is pre-defined-category.";
}
leaf-list user-defined-category {
type string;
description
"This user-defined-category.";
}
}
container context-condition {
description
"Condition for context";
leaf context-description {
type string;
description
"This is description for context condition.
Vendors can write instructions for context condition
that vendor made";
}
}
container gen-context-condition {
description
"Condition for generic context";
leaf gen-context-description {
type string;
description
"This is description for generic context condition.
Vendors can write instructions for generic context
condition that vendor made";
}
container geographic-location {
description
"The location where network traffic is associated
with. The region can be the geographic location
such as country, province, and city,
as well as the logical network location such as
IP address, network section, and network domain.";
leaf-list src-geographic-location {
type uint32;
description
"This is mapped to ip address. We can acquire
source region through ip address stored in the
database.";
}
leaf-list dest-geographic-location {
type uint32;
description
"This is mapped to ip address. We can acquire
destination region through ip address stored
in the database.";
}
}
}
}
container action-clause-container { container action-clause-container {
description description
"An action is used to control and monitor aspects of "An action is used to control and monitor aspects of
flow-based NSFs when the event and condition clauses flow-based NSFs when the event and condition clauses
are satisfied. NSFs provide security functions by are satisfied. NSFs provide security functions by
executing various Actions. Examples of I2NSF Actions executing various Actions. Examples of I2NSF Actions
include providing intrusion detection and/or protection, include providing intrusion detection and/or protection,
web and flow filtering, and deep packet inspection web and flow filtering, and deep packet inspection
for packets and flows."; for packets and flows.";
reference reference
skipping to change at page 77, line 18 skipping to change at page 87, line 4
description description
"The Profile is divided into content security "The Profile is divided into content security
control and attack-mitigation-control. control and attack-mitigation-control.
Attack mitigation control: syn flood, udp flood, Attack mitigation control: syn flood, udp flood,
icmp flood, ip frag flood, ipv6 related, http flood, icmp flood, ip frag flood, ipv6 related, http flood,
https flood, dns flood, dns amp flood, ssl ddos, https flood, dns flood, dns amp flood, ssl ddos,
ip sweep, port scanning, ping of death, teardrop, ip sweep, port scanning, ping of death, teardrop,
oversized icmp, tracert."; oversized icmp, tracert.";
} }
} }
}
}
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";
}
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 5: YANG Data Module of I2NSF NSF-Facing-Interface Figure 5: YANG Data Module of I2NSF NSF-Facing-Interface
6. IANA Considerations 6. 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-policy-rule-for-nsf URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf
skipping to change at page 78, line 21 skipping to change at page 89, line 4
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the required transport secure transport is TLS is HTTPS, and the required transport secure transport is TLS
[RFC8446]. [RFC8446].
The NETCONF access control model [RFC8341] provides a means of The NETCONF access control model [RFC8341] provides a means of
restricting access to specific NETCONF or RESTCONF users to a restricting access to specific NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content. operations and content.
8. References 8. References
8.1. Normative 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,
DOI 10.17487/RFC2119, March 1997,
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the <https://www.rfc-editor.org/info/rfc2119>.
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, the Network Configuration Protocol (NETCONF)", RFC 6020,
January 2011, <https://www.rfc-editor.org/info/rfc6087>. DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[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>.
skipping to change at page 79, line 15 skipping to change at page 89, line 43
[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,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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, DOI 10.17487/RFC8329, February 2018,
<https://www.rfc-editor.org/info/rfc8329>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,
S., and N. Bahadur, "A YANG Data Model for Routing S., and N. Bahadur, "A YANG Data Model for the Routing
Information Base (RIB)", RFC RFC8431, September 2018. 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>.
8.2. Informative References 8.2. Informative References
[i2nsf-advanced-nsf-dm] [i2nsf-advanced-nsf-dm]
Pan, W. and L. Xia, "Configuration of Advanced Security Pan, W. and L. Xia, "Configuration of Advanced Security
Functions with I2NSF Security Controller", draft-dong- Functions with I2NSF Security Controller", draft-dong-
i2nsf-asf-config-01 (work in progress), October 2018. i2nsf-asf-config-01 (work in progress), October 2018.
[i2nsf-nsf-cap-dm] [i2nsf-nsf-cap-dm]
Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin, Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin,
"I2NSF Capability YANG Data Model", draft-ietf-i2nsf- "I2NSF Capability YANG Data Model", draft-ietf-i2nsf-
capability-data-model-02 (work in progress), November capability-data-model-03 (work in progress), March 2019.
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-04 (work in progress), October 2018. i2nsf-capability-04 (work in progress), October 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. Configuration Examples Appendix A. Configuration Examples
This section shows configuration examples of "ietf-i2nsf-policy-rule- This section shows configuration examples of "ietf-i2nsf-policy-rule-
for-nsf" module for security policy rules of network security for-nsf" module for security policy rules of network security
devices. For security requirements, we assume that the NSFs (i.e., devices. For security requirements, we assume that the NSFs (i.e.,
General firewall, Time based firewall, Web filter, VoIP/VoLTE filter General firewall, Time based firewall, URL filter, VoIP/VoLTE filter,
http and https flood mitigation ) described in Appendix A. and http and https flood mitigation ) described in Appendix A.
Configuration Examples of [i2nsf-nsf-cap-dm] are registered in I2NSF Configuration Examples of [i2nsf-nsf-cap-dm] are registered in I2NSF
framework. With the registed NSFs, we show configuration examples framework. With the registed NSFs, we show configuration examples
for security policy rules of network security functions according to for security policy rules of network security functions according to
the following three security requirements: (i) Block SNS access the following three security requirements: (i) Block SNS access
during business hours, (ii) Block malicious VoIP/VoLTE packets coming during business hours, (ii) Block malicious VoIP/VoLTE packets coming
to the company, and (iii) Mitigate http and https flood attacks on to the company, and (iii) Mitigate http and https flood attacks on
company web server. company web server.
A.1. Security Requirement 1: Block SNS Access during Business Hours A.1. Security Requirement 1: Block SNS Access during Business Hours
skipping to change at page 83, line 10 skipping to change at page 93, line 10
</i2nsf-security-policy> </i2nsf-security-policy>
Figure 6: Configuration XML for Time based Firewall to Block SNS Figure 6: Configuration XML for Time based Firewall to Block SNS
Access during Business Hours Access during Business Hours
<i2nsf-security-policy <i2nsf-security-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
<system-policy> <system-policy>
<system-policy-name>sns_access</system-policy-name> <system-policy-name>sns_access</system-policy-name>
<rules> <rules>
<rule-name>block_facebook_and_instgram</rule-name> <rule-name>block_sns_access_during_operation_time</rule-name>
<condition-clause-container> <condition-clause-container>
<packet-security-http-condition> <packet-security-http-condition>
<pkt-sec-url-content>facebook</pkt-sec-url-content> <pkt-sec-url-content>facebook</pkt-sec-url-content>
<pkt-sec-url-content>instagram</pkt-sec-url-content> <pkt-sec-url-content>instagram</pkt-sec-url-content>
</packet-security-http-condition> </packet-security-http-condition>
</condition-clause-container> </condition-clause-container>
<action-clause-container> <action-clause-container>
<packet-action> <packet-action>
<egress-action>drop</egress-action> <egress-action>drop</egress-action>
</packet-action> </packet-action>
skipping to change at page 85, line 10 skipping to change at page 95, line 10
to the Company to the Company
This section shows a configuration example for blocking malicious This section shows a configuration example for blocking malicious
VoIP/VoLTE packets coming to the company. VoIP/VoLTE packets coming to the company.
<i2nsf-security-policy <i2nsf-security-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
<system-policy> <system-policy>
<system-policy-name>voip_volte_inspection</system-policy-name> <system-policy-name>voip_volte_inspection</system-policy-name>
<rules> <rules>
<rule-name>block_malicious_voip_volte_packets</rule-name> <rule-name>block_malicious_voice_id</rule-name>
<condition-clause-container> <condition-clause-container>
<packet-security-ipv4-condition> <packet-security-ipv4-condition>
<pkt-sec-ipv4-dest> <pkt-sec-ipv4-dest>
<range-ipv4-address> <range-ipv4-address>
<start-ipv4-address>221.159.112.1</start-ipv4-address> <start-ipv4-address>221.159.112.1</start-ipv4-address>
<end-ipv4-address>221.159.112.90</end-ipv4-address> <end-ipv4-address>221.159.112.90</end-ipv4-address>
</range-ipv4-address> </range-ipv4-address>
</pkt-sec-ipv4-dest> </pkt-sec-ipv4-dest>
</packet-security-ipv4-condition> </packet-security-ipv4-condition>
<packet-security-tcp-condition> <packet-security-tcp-condition>
skipping to change at page 86, line 8 skipping to change at page 96, line 8
</rules> </rules>
</system-policy> </system-policy>
</i2nsf-security-policy> </i2nsf-security-policy>
Figure 8: Configuration XML for General Firewall to Block Malicious Figure 8: Configuration XML for General Firewall to Block Malicious
VoIP/VoLTE Packets Coming to the Company VoIP/VoLTE Packets Coming to the Company
<i2nsf-security-policy <i2nsf-security-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
<system-policy> <system-policy>
<system-policy-name>malicious_voice_id</system-policy-name> <system-policy-name>voip_volte_inspection</system-policy-name>
<rules> <rules>
<rule-name>block_malicious_voice_id</rule-name> <rule-name>block_malicious_voice_id</rule-name>
<condition-clause-container> <condition-clause-container>
<packet-security-voice-condition> <packet-security-voice-condition>
<pkt-sec-src-voice-id>11111@voip.black.com</pkt-sec-src-voice-id> <pkt-sec-src-voice-id>11111@voip.black.com</pkt-sec-src-voice-id>
<pkt-sec-src-voice-id>22222@voip.black.com</pkt-sec-src-voice-id> <pkt-sec-src-voice-id>22222@voip.black.com</pkt-sec-src-voice-id>
</packet-security-voice-condition> </packet-security-voice-condition>
</condition-clause-container> </condition-clause-container>
<action-clause-container> <action-clause-container>
<packet-action> <packet-action>
skipping to change at page 89, line 8 skipping to change at page 99, line 8
</rules> </rules>
</system-policy> </system-policy>
</i2nsf-security-policy> </i2nsf-security-policy>
Figure 10: Configuration XML for General Firewall to Mitigate HTTP Figure 10: Configuration XML for General Firewall to Mitigate HTTP
and HTTPS Flood Attacks on a Company Web Server and HTTPS Flood Attacks on a Company Web Server
<i2nsf-security-policy <i2nsf-security-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
<system-policy> <system-policy>
<system-policy-name>http_and_https_flood_attack_mitigation <system-policy-name>flood_attack_mitigation</system-policy-name>
</system-policy-name>
<rules> <rules>
<rule-name>100_per_second</rule-name> <rule-name>mitigate_http_and_https_flood_attack</rule-name>
<condition-clause-container> <condition-clause-container>
<packet-security-ddos-condition> <packet-security-ddos-condition>
<pkt-sec-alert-rate>100</pkt-sec-alert-rate> <pkt-sec-alert-rate>100</pkt-sec-alert-rate>
</packet-security-ddos-condition> </packet-security-ddos-condition>
</condition-clause-container> </condition-clause-container>
<action-clause-container> <action-clause-container>
<packet-action> <packet-action>
<ingress-action>drop</ingress-action> <ingress-action>drop</ingress-action>
</packet-action> </packet-action>
</action-clause-container> </action-clause-container>
skipping to change at page 90, line 26 skipping to change at page 100, line 23
http_and_https_flood_attack_mitigation. http_and_https_flood_attack_mitigation.
2. The name of the rule is 100_per_second. 2. The name of the rule is 100_per_second.
3. The rule controls the http and https packets according to the 3. The rule controls the http and https packets according to the
amount of incoming packets. amount of incoming packets.
4. If the incoming packets match the rules above, the packets are 4. If the incoming packets match the rules above, the packets are
blocked. blocked.
Appendix B. Changes from draft-ietf-i2nsf-nsf-facing-interface-dm-02 Appendix B. Changes from draft-ietf-i2nsf-nsf-facing-interface-dm-03
The following changes are made from draft-ietf-i2nsf-nsf-facing- The following changes are made from draft-ietf-i2nsf-nsf-facing-
interface-dm-03: interface-dm-04:
o We revised this YANG data module according to guidelines for
authors and reviewers of YANG data model documents [RFC6087].
o We changed the structure of the overall YANG data model.
o We added exact-range type as well as range-based type for the
range policy rules.
o We changed enumeration type to identity type for scalable
components.
o We added a description for the YANG tree diagram of the YANG data
module.
o We revised overall sentences of this YANG data model document. o We added fields for a rule (e.g., rule session aging time, rule
long connection, and rule group).
o We added configuration examples to make it easier for reviewers to o We added fields for a condition (e.g., payload, acl number,
understand. application, target, users, url category, context, and generic
context)
Appendix C. Acknowledgments Appendix C. Acknowledgments
This work was supported by Institute for Information & communications This work was supported by Institute for Information & communications
Technology Promotion (IITP) grant funded by the Korea government Technology Promotion (IITP) grant funded by the Korea government
(MSIP) (No.R-20160222-002755, Cloud based Security Intelligence (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence
Technology Development for the Customized Security Service Technology Development for the Customized Security Service
Provisioning). Provisioning).
Appendix D. Contributors Appendix D. Contributors
 End of changes. 46 change blocks. 
96 lines changed or deleted 569 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/