draft-ietf-i2nsf-consumer-facing-interface-dm-01.txt   draft-ietf-i2nsf-consumer-facing-interface-dm-02.txt 
Network Working Group J. Jeong I2NSF Working Group J. Jeong
Internet-Draft E. Kim Internet-Draft E. Kim
Intended status: Standards Track Sungkyunkwan University Intended status: Standards Track Sungkyunkwan University
Expires: January 3, 2019 T. Ahn Expires: May 8, 2019 T. Ahn
Korea Telecom Korea Telecom
R. Kumar R. Kumar
Juniper Networks Juniper Networks
S. Hares S. Hares
Huawei Huawei
July 2, 2018 November 4, 2018
I2NSF Consumer-Facing Interface YANG Data Model I2NSF Consumer-Facing Interface YANG Data Model
draft-ietf-i2nsf-consumer-facing-interface-dm-01 draft-ietf-i2nsf-consumer-facing-interface-dm-02
Abstract Abstract
This document describes a YANG data model for the Consumer-Facing This document describes a YANG data model for the Consumer-Facing
Interface between an Interface to Network Security Functions (I2NSF) Interface between an Interface to Network Security Functions (I2NSF)
User and Security Controller in an I2NSF system in a Network User and Security Controller in an I2NSF system in a Network
Functions Virtualization (NFV) environment. The data model is Functions Virtualization (NFV) environment. The data model is
required for enabling different users of a given I2NSF system to required for enabling different users of a given I2NSF system to
define, manage, and monitor security policies for specific flows define, manage, and monitor security policies for specific flows
within an administrative domain. within an administrative domain.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Data Modeling for Security Policies for Consumer-Facing 4. Data Modeling for Security Policies for Consumer-Facing
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. YANG Data Model for Security Policies for Consumer-Facing 4.1. YANG Data Model for Security Policies for Consumer-Facing
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Interface . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 5. Use Case: Policy Instance Example for VoIP/VoLTE Security
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1. Policy Instance YANG Example for VoIP/VoLTE Security
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 Services . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Normative References . . . . . . . . . . . . . . . . . . 37 6. Example XML Output for Various Use Cases . . . . . . . . . . 45
9.2. Informative References . . . . . . . . . . . . . . . . . 37 6.1. Case 1: VoIP Security Service . . . . . . . . . . . . . . 45
6.2. Case 2: DDoS-Attack Mitigation . . . . . . . . . . . . . 47
6.3. Case 3: Time-Based Firewall . . . . . . . . . . . . . . . 48
6.4. Case 4: Time-Based Web-Filter . . . . . . . . . . . . . . 49
6.5. Case 5: Threat-Feed Configuration . . . . . . . . . . . . 50
7. Security Considerations . . . . . . . . . . . . . . . . . . . 51
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.1. Normative References . . . . . . . . . . . . . . . . . . 51
8.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing- Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-
interface-dm-00 . . . . . . . . . . . . . . . . . . 39 interface-dm-01 . . . . . . . . . . . . . . . . . . 53
Appendix B. Use Case: Policy Instance Example for VoIP/VoLTE Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 53
Security Services . . . . . . . . . . . . . . . . . 39 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 53
Appendix C. Policy Instance YANG Example for VoIP/VoLTE Security Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
Services . . . . . . . . . . . . . . . . . . . . . . 41
Appendix D. Example XML output for VoIP service . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This document provides a YANG [RFC6020] data model that defines the This document provides a YANG [RFC6020] data model that defines the
required data for the Consumer-Facing Interface between an Interface required data for the Consumer-Facing Interface between an Interface
to Network Security Functions (I2NSF) User and Security Controller in to Network Security Functions (I2NSF) User and Security Controller in
an I2NSF system [i2nsf-framework] in a Network Functions an I2NSF system [i2nsf-framework] in a Network Functions
Virtualization (NFV) environment. The data model is required for Virtualization (NFV) environment. The data model is required for
enabling different users of a given I2NSF system to define, manage enabling different users of a given I2NSF system to define, manage
and monitor security policies for specific flows within an and monitor security policies for specific flows within an
skipping to change at page 4, line 7 skipping to change at page 4, line 12
facilitate the efficient delivery of the control or management facilitate the efficient delivery of the control or management
messages. messages.
This data model is designed to support the I2NSF framework that can This data model is designed to support the I2NSF framework that can
be extended according to the security needs. In other words, the be extended according to the security needs. In other words, the
model design is independent of the content and meaning of specific model design is independent of the content and meaning of specific
policies as well as the implementation approach. This document policies as well as the implementation approach. This document
suggests a VoIP/VoLTE security service as a use case for policy rule suggests a VoIP/VoLTE security service as a use case for policy rule
generation. generation.
+-----------------+ +-----------------+
| | | |
| Consumer Facing +------>+ Consumer Facing |
| Interface | | Interface |
|Information Model| | Data Model |
+--------+--------+ +-----------------+
^
|
|
+-------------+-------------+
| |
| Policy-general |
| |
+-------------+-------------+
^
|
+------------+-------------+------------+--------------+
| | | | |
+-----+----+ +----+-----+ +----+----+ +----+----+ +------+-----+
| | | | | | | | | |
| Multi | | Endpoint | | Policy | | Threat | | Telemetry |
| tenancy | | groups | | | | feed | | data |
+----------+ +----------+ +----+----+ +---------+ +------------+
^
|
|
+------+------+
| |
| Rule |
| |
+------+------+
^
|
+----------------+----------------+
| | |
+------+------+ +------+------+ +------+------+
| | | | | |
| Event | | Condition | | Action |
| | | | | |
+-------------+ +-------------+ +-------------+
Figure 1: High-level-abstraction for Consumer Facing Interface
Multi-tenancy in this document enables multiple administrative Multi-tenancy in this document enables multiple administrative
domains in order to manage application resources. An Enterprise domains in order to manage application resources. An Enterprise
organization may have multiple tenants or departments such as HR, organization may have multiple tenants or departments such as human
finance, and legal. Thus, we need an object which defines a set of resources (HR), finance, and legal departments. Thus, we need an
permissions assigned to a user in an organization that wants to object which defines a set of permissions assigned to a user in an
manage its own Security Policies. You can think of it as a way to organization that wants to manage its own Security Policies. You can
assign policy users to a job function or a set of permissions within think of it as a way to assign policy users to a job function or a
the organization. The policy-role object SHALL have Name, Date and set of permissions within the organization. The policy-role object
access-profile to grant or deny permissions for the perpose of SHALL have Name, Date and access-profile to grant or deny permissions
security policy management. for the perpose of security policy management.
module: policy-general module: policy-general
+--rw policy +--rw policy
| +--rw rule* [rule-id] | +--rw rule* [rule-id]
| +--rw rule-id uint16 | +--rw rule-id uint16
| +--rw name? string | +--rw name? string
| +--rw date? yang:date-and-time | +--rw date? yang:date-and-time
| +--rw case? string | +--rw case? string
| +--rw event* [event-id] | +--rw event* [event-id]
| | +--rw event-id string | | +--rw event-id string
skipping to change at page 8, line 39 skipping to change at page 7, line 48
| +--rw qos-marking? uint16 | +--rw qos-marking? uint16
+--rw telemetry-destination* [telemetry-destination-id] +--rw telemetry-destination* [telemetry-destination-id]
+--rw telemetry-destination-id uint16 +--rw telemetry-destination-id uint16
+--rw name? string +--rw name? string
+--rw date? yang:date-and-time +--rw date? yang:date-and-time
+--rw collector-source? inet:ipv4-address +--rw collector-source? inet:ipv4-address
+--rw collector-credentials? string +--rw collector-credentials? string
+--rw data-encoding? string +--rw data-encoding? string
+--rw data-transport? enumeration +--rw data-transport? enumeration
Figure 2: Generic Data Model for Security Policies for cf Interface Figure 1: Generic Data Model for Security Policies for cf Interface
5. YANG Data Model for Security Policies for Consumer-Facing Interface 4.1. YANG Data Model for Security Policies for Consumer-Facing
Interface
This section describes a YANG data model for Consumer-Facing This section describes a YANG data model for Consumer-Facing
Interface, based on the information model of Consumer-Facing Interface, based on the information model of Consumer-Facing
Interface to security controller [client-facing-inf-im]. Interface to security controller [client-facing-inf-im].
<CODE BEGINS> file "policy-general.yang" <CODE BEGINS> file "policy-general.yang"
module ietf-policy-general { module ietf-policy-general {
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-policy-general"; "urn:ietf:params:xml:ns:yang:ietf-policy-general";
prefix prefix
skipping to change at page 9, line 37 skipping to change at page 8, line 48
WG Chair: Linda Dunbar WG Chair: Linda Dunbar
<mailto:Linda.duhbar@huawei.com> <mailto:Linda.duhbar@huawei.com>
Editor: Jaehoon Paul Jeong Editor: Jaehoon Paul Jeong
<mailto:pauljeong@skku.edu>"; <mailto:pauljeong@skku.edu>";
description description
"This module defines a YANG data module for consumer-facing "This module defines a YANG data module for consumer-facing
interface to security controller."; interface to security controller.";
revision "2018-07-02"{ revision "2018-11-04"{
description "fourth revision"; description "fourth revision";
reference reference
"draft-kumar-i2nsf-client-facing-interface-im-04"; "draft-kumar-i2nsf-client-facing-interface-im-04";
} }
//Groupings //Groupings
container policy { container policy {
description description
"This object is a policy instance to have "This object is a policy instance to have
complete information such as where and when complete information such as where and when
a policy need to be applied."; a policy need to be applied.";
list rule { list rule {
key "rule-id"; key "rule-id";
leaf rule-id { leaf rule-id {
skipping to change at page 17, line 24 skipping to change at page 15, line 47
"This represents the policy-user-id."; "This represents the policy-user-id.";
} }
description description
"This represents the list of policy users."; "This represents the list of policy users.";
leaf name { leaf name {
type string; type string;
mandatory true; mandatory true;
description description
"The name of a user."; "The name of a user.";
} }
leaf date { leaf date {
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
description description
"Date this user was created or last modified"; "Date this user was created or last modified";
}
}
leaf password { leaf password {
type string; type string;
mandatory true; mandatory true;
description description
"User password for basic authentication"; "User password for basic authentication";
} }
leaf email { leaf email {
type string; type string;
mandatory true; mandatory true;
description description
"The email account of a user"; "The email account of a user";
} }
leaf scope-type { leaf scope-type {
type string; type string;
description description
"identifies whether a user has domain-wide "identifies whether a user has domain-wide
or tenant-wide privileges"; or tenant-wide privileges";
} }
leaf scope-reference { leaf scope-reference {
type string; type string;
description description
"This references policy-domain or policy-tenant "This references policy-domain or policy-tenant
skipping to change at page 37, line 4 skipping to change at page 33, line 38
} }
description description
"This field contains streaming telemetry data "This field contains streaming telemetry data
protocols. This could be gRPC, protocol protocols. This could be gRPC, protocol
buffer over UDP, etc."; buffer over UDP, etc.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 3: YANG for policy-general
6. Security Considerations
The data model for the I2NSF Consumer-Facing Interface is derived
from the I2NSF Consumer-Facing Interface Information Model
[client-facing-inf-im], so the same security considerations with the
information model should be included in this document. The data
model needs to support a mechanism to protect Consumer-Facing
Interface to Security Controller.
7. Acknowledgments
This work was supported by Institute for Information & communications
Technology Promotion(IITP) grant funded by the Korea government(MSIP)
(No.R-20160222-002755, Cloud based Security Intelligence Technology
Development for the Customized Security Service Provisioning).
This document has greatly benefited from inputs by Hyoungshick Kim, Figure 2: YANG for policy-general
Mahdi F. Dachmehchi, Seungjin Lee, Jinyong Tim Kim, and Daeyoung
Hyun.
8. Contributors
I2NSF is a group effort. The following people actively contributed
to the consumer facing interface data model, and are considered co-
authors: o Hyoungshick Kim (Sungkyunkwan University) o Seungjin Lee
(Sungkyunkwan University)
9. References
9.1. Normative References
[RFC3444] Pras, A., "On the Difference between Information Models
and Data Models", RFC 3444, January 2003.
9.2. Informative References
[client-facing-inf-im]
Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
S., and L. Xia, "Information model for Client-Facing
Interface to Security Controller", draft-kumar-i2nsf-
client-facing-interface-im-04 (work in progress), July
2017.
[client-facing-inf-req]
Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
S., and L. Xia, "Requirements for Client-Facing Interface
to Security Controller", draft-ietf-i2nsf-client-facing-
interface-req-03 (work in progress), July 2017.
[i2nsf-framework]
Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security
Functions", draft-ietf-i2nsf-framework-08 (work in
progress), October 2017.
[i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Birkholz, H., and L.
Xia, "Information model for Client-Facing Interface to
Security Controller", draft-ietf-i2nsf-terminology-04
(work in progress), July 2017.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface-
dm-00
The following changes have been made from draft-jeong-i2nsf-consumer-
facing-interface-dm-05:
o In Section 3, the high-level abstraction of the consumer facing
interface has been added.
o The overall organization of the YANG data model and its data types
have also been reviewed and corrected, and produced the
corresponding data tree as shown in the Section 5.
o Overall editorial errors have been corrected.
Appendix B. Use Case: Policy Instance Example for VoIP/VoLTE Security 5. Use Case: Policy Instance Example for VoIP/VoLTE Security Services
Services
A common scenario for VoIP/VoLTE policy enforcement could be that a A common scenario for VoIP/VoLTE policy enforcement could be that a
malicious call is made to a benign user of any telecommunication malicious call is made to a benign user of any telecommunication
company. For example, imagine a case wherea company "A" employs a company. For example, imagine a case wherea company "A" employs a
hacker with a malicious attempt to hack a user's phone with malware. hacker with a malicious attempt to hack a user's phone with malware.
The company "A" is located in a country, such as Africa, and uses the The company "A" is located in a country, such as Africa, and uses the
user's hacked phone to call the company. The hacked user is unaware user's hacked phone to call the company. The hacked user is unaware
of the company "A" so complains about the international call that was of the company "A" so complains about the international call that was
made to the company "B", which is the user's telecommunications made to the company "B", which is the user's telecommunications
company. The company "A" charges the company "B" for the company. The company "A" charges the company "B" for the
skipping to change at page 41, line 9 skipping to change at page 35, line 30
| +--rw signature-server? inet:ipv4-address | +--rw signature-server? inet:ipv4-address
| +--rw file-types? string | +--rw file-types? string
| +--rw malware-signatures? string | +--rw malware-signatures? string
+--rw event-map-group* [event-map-group-id] +--rw event-map-group* [event-map-group-id]
+--rw event-map-group-id uint16 +--rw event-map-group-id uint16
+--rw name? string +--rw name? string
+--rw date? yang:date-and-time +--rw date? yang:date-and-time
+--rw security-events? string +--rw security-events? string
+--rw threat-map? string +--rw threat-map? string
Figure 4: Policy Instance Example for VoIP/VoLTE Security Services Figure 3: Policy Instance Example for VoIP/VoLTE Security Services
Appendix C. Policy Instance YANG Example for VoIP/VoLTE Security 5.1. Policy Instance YANG Example for VoIP/VoLTE Security Services
Services
The following YANG data model is a policy instance for VoIP/VoLTE The following YANG data model is a policy instance for VoIP/VoLTE
security services. The policy-calendar can act as a scheduler to set security services. The policy-calendar can act as a scheduler to set
the start time and end time to block malicious calls which use the start time and end time to block malicious calls which use
suspicious IDs, or calls from other countries. suspicious IDs, or calls from other countries.
<CODE BEGINS> file "ietf-i2nsf-cf-interface-voip.yang" <CODE BEGINS> file "ietf-i2nsf-cf-interface-voip.yang"
module ietf-policy-voip { module ietf-policy-voip {
namespace namespace
skipping to change at page 42, line 9 skipping to change at page 36, line 28
WG Chair: Linda Dunbar WG Chair: Linda Dunbar
<mailto:Linda.duhbar@huawei.com> <mailto:Linda.duhbar@huawei.com>
Editor: Jaehoon Paul Jeong Editor: Jaehoon Paul Jeong
<mailto:pauljeong@skku.edu>"; <mailto:pauljeong@skku.edu>";
description description
"This module defines a YANG data module for consumer-facing "This module defines a YANG data module for consumer-facing
interface to security controller."; interface to security controller.";
revision "2018-07-02"{ revision "2018-11-04"{
description "sixth revision"; description "sixth revision";
reference reference
"draft-kumar-i2nsf-client-facing-interface-im-04"; "draft-kumar-i2nsf-client-facing-interface-im-07";
} }
container policy-voip { container policy-voip {
description description
"This object is a policy instance to have "This object is a policy instance to have
complete information such as where and when complete information such as where and when
a policy need to be applied."; a policy need to be applied.";
list rule-voip { list rule-voip {
key "rule-voip-id"; key "rule-voip-id";
leaf rule-voip-id { leaf rule-voip-id {
type uint16; type uint16;
mandatory true; mandatory true;
skipping to change at page 51, line 16 skipping to change at page 45, line 30
} }
leaf threat-map { leaf threat-map {
type string; type string;
description description
"This contains a list of threat levels."; "This contains a list of threat levels.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 5: Policy Instance YANG Example for VoIP Security Services Figure 4: Policy Instance YANG Example for VoIP Security Services
Appendix D. Example XML output for VoIP service 6. Example XML Output for Various Use Cases
In this section, we present an XML example for VoIP service. Here, In this section, we present an XML example for various use cases.
we are going to drop calls commin from a country with an Ip from Here, we show the policy examples that can be delivered through
South Africa that is classified as malicious. consumer-facing interface. For now, the considered use cases are:
VoIP security service, DDoS-attack mitigation, time-based firewall,
and web-filter.
6.1. Case 1: VoIP Security Service
The first example is a VoIP policy. Here, we are going to drop calls
commin from a country with an Ip from South Africa that is classified
as malicious. The below figure shows the XML document generated by
using the YANG data tree as shown in the previous section.
<?xml version="1.1" encoding="UTF-8"?> <?xml version="1.1" encoding="UTF-8"?>
<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0"> <rpc message-id="1" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0">
<edit-config> <edit-config>
<target> <target>
<running/> <running/>
</target> </target>
<config> <config>
<i2nsf-cf-interface-voip-req nc:operation="create"> <i2nsf-cf-interface-voip-req nc:operation="create">
<policy-voip> <policy-voip>
<rule-voip> <rule-voip>
<rule-voip-id>01</rule-voip-id> <rule-voip-id>01</rule-voip-id>
<rule-voip-name>voip-policy-example</rule-voip-name> <rule-voip-name>voip-policy-example</rule-voip-name>
<rule-voip-date>2017.10.25/20:30:32</rule-voip-date> <rule-voip-date>2017.10.25/20:30:32</rule-voip-date>
<event> <event>
<event-id>01</event-id> <event-id>01</event-id>
<event-name>voip_call</event-name> <event-name>voip_call</event-name>
<event-date>2017.10.25/20:30:32</event-date> <event-date>2017.10.25/20:30:32</event-date>
<event-type>malicious</event-type> <event-type>malicious</event-type>
<time-information>
<begin-time>22:00</begin-time>
<end-time>08:00</end-time>
</time-information>
<event-map-group>19</event-map-group> <event-map-group>19</event-map-group>
<enable>True</enable> <enable>True</enable>
</event> </event>
<condition> <condition>
<condition-id>01</condition-id> <condition-id>01</condition-id>
<source-caller>105.176.0.0</source-caller> <source-caller>105.176.0.0</source-caller>
<destination-callee>192.168.171.35</destination-callee> <destination-callee>192.168.171.35</destination-callee>
<time-information>
<begin-time>22:00</begin-time>
<end-time>08:00</end-time>
</time-information>
<match-direction>default</match-direction> <match-direction>default</match-direction>
<exeption>00</exeption> <exeption>00</exeption>
</condition> </condition>
<action> <action>
<action-id>01</action-id> <action-id>01</action-id>
<action-name>action-voip</action-name> <action-name>action-voip</action-name>
<action-date>2017.10.25/20:30:32</action-date> <action-date>2017.10.25/20:30:32</action-date>
<primary-action>DENY</primary-action> <primary-action>DENY</primary-action>
<secondary-action>LOG</secondary-action> <secondary-action>LOG</secondary-action>
</action> </action>
skipping to change at page 52, line 31 skipping to change at page 47, line 4
<owner> <owner>
<owner-id>01</owner-id> <owner-id>01</owner-id>
<name>i2nsf-admin</name> <name>i2nsf-admin</name>
</owner> </owner>
</rule-voip> </rule-voip>
</policy-voip> </policy-voip>
</i2nsf-cf-interface-voip-req> </i2nsf-cf-interface-voip-req>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
Figure 5: An XML Example for VoIP Security Service
Figure 6: An XML example for VoIP service 6.2. Case 2: DDoS-Attack Mitigation
Authors' Addresses The second example is a DDoS-attack mitigation policy. Here, the
time information is not set because the service provided by the
network should be maintained at all times. If the packets sent by
any sources are more than the set threshold, then the admin can set
the percentage of the packets to be dropped to safely maintain the
service.
<?xml version="1.1" encoding="UTF-8"?>
<rpc message-id="2" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<i2nsf-cf-interface-ddos-req nc:operation="create">
<policy-ddos>
<rule-ddos>
<rule-ddos-id>03</rule-ddos-id>
<rule-ddos-name>ddos-policy-example</rule-ddos-name>
<rule-ddos-date>2018.10.25/11:25:32</rule-ddos-date>
<event>
<event-id>03</event-id>
<event-name>ddos</event-name>
<event-date>2018.10.25/11:25:32</event-date>
<event-type>ddos</event-type>
<event-map-group>03</event-map-group>
<enable>True</enable>
</event>
<condition>
<condition-id>03</condition-id>
<source-ip>Any</source-ip>
<destination-ip>192.168.173.37</destination-ip>
<threshold>30</threshold>
<time-information>
<begin-time>--:--</begin-time>
<end-time>--:--</end-time>
</time-information>
<match-direction>default</match-direction>
<exeption>00</exeption>
</condition>
<action>
<action-id>03</action-id>
<action-name>action-ddos</action-name>
<action-date>2018.10.25/11:25:32</action-date>
<primary-action>REJECT</primary-action>
<secondary-action>LOG</secondary-action>
</action>
<precedence>none</precedence>
<owner>
<owner-id>03</owner-id>
<name>i2nsf-admin</name>
</owner>
</rule-ddos>
</policy-ddos>
</i2nsf-cf-interface-ddos-req>
</config>
</edit-config>
</rpc>
Figure 6: An XML Example for DDoS-attack Mitigation
6.3. Case 3: Time-Based Firewall
The third example is a time-based firewall policy. Consider a Smart
Factory which operates from 9 am to 7 pm during the working days.
During these hours, only the admin responsible for operating the
factory is allow to access a control system. The below figure show
that any access during outside the operating hours is rejected.
<?xml version="1.1" encoding="UTF-8"?>
<rpc message-id="3" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<i2nsf-cf-interface-fw-req nc:operation="create">
<policy-fw>
<rule-fw>
<rule-fw-id>01</rule-fw-id>
<rule-fw-name>fw-policy-example</rule-fw-name>
<rule-fw-date>2018.10.25/11:19:05</rule-fw-date>
<event>
<event-id>01</event-id>
<event-name>invalid_access</event-name>
<event-date>2018.10.25/11:19:05</event-date>
<event-type>invalid</event-type>
<event-map-group>02</event-map-group>
<enable>True</enable>
</event>
<condition>
<condition-id>02</condition-id>
<source-ip>115.176.0.1</source-ip>
<destination-ip>192.168.173.41</destination-ip>
<time-information>
<begin-time>09:00</begin-time>
<end-time>17:00</end-time>
</time-information>
<match-direction>default</match-direction>
<exeption>00</exeption>
</condition>
<action>
<action-id>02</action-id>
<action-name>action-fw</action-name>
<action-date>2018.10.25/11:19:05</action-date>
<primary-action>PASS</primary-action>
<secondary-action>LOG</secondary-action>
</action>
<precedence>none</precedence>
<owner>
<owner-id>02</owner-id>
<name>i2nsf-admin</name>
</owner>
</rule-fw>
</policy-fw>
</i2nsf-cf-interface-fw-req>
</config>
</edit-config>
</rpc>
Figure 7: An XML Example for Time-based Firewall
6.4. Case 4: Time-Based Web-Filter
The last example is a time-based web-filter policy. Let us suppose
that a owner of an enterprise wants to forbid access to a specific
set of websites, such as Facebook, Youtube, Instagram, etc. The
below figure shows an example policy an admin of a sector or
department can deploy.
<?xml version="1.1" encoding="UTF-8"?>
<rpc message-id="4" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<i2nsf-cf-interface-wf-req nc:operation="create">
<policy-wf>
<rule-wf>
<rule-wf-id>03</rule-wf-id>
<rule-wf-name>wf-policy-example</rule-wf-name>
<rule-wf-date>2018.10.26/14:03:17</rule-wf-date>
<event>
<event-id>04</event-id>
<event-name>wf</event-name>
<event-date>2018.10.26/14:03:17</event-date>
<event-type>wf</event-type>
<event-map-group>04</event-map-group>
<enable>True</enable>
</event>
<condition>
<condition-id>04</condition-id>
<source-ip>192.168.1.3</source-ip>
<destination-url>www.facebook.com</destination-url>
<time-information>
<begin-time>09:00</begin-time>
<end-time>18:00</end-time>
</time-information>
<match-direction>default</match-direction>
<exeption>00</exeption>
</condition>
<action>
<action-id>04</action-id>
<action-name>action-wf</action-name>
<action-date>2018.10.26/14:03:17</action-date>
<primary-action>REJECT</primary-action>
<secondary-action>LOG</secondary-action>
</action>
<precedence>none</precedence>
<owner>
<owner-id>03</owner-id>
<name>i2nsf-admin</name>
</owner>
</rule-wf>
</policy-wf>
</i2nsf-cf-interface-wf-req>
</config>
</edit-config>
</rpc>
Figure 8: An XML Example for Time-based Web-filter
6.5. Case 5: Threat-Feed Configuration
The threat-feed container described above can convey various sources
containing information concerning security threats. One good example
can be STIX. STIX (Structured Threat Information Expression) is a
language and serialization format used to exchange cyber threat
intelligence (CTI). It is a lanauge to describe threat information
in a standardized format to enable exchanging and sharing them. The
blow figure show the necessary configuration, which can be generated
and delivered by consumer-facing interface.
...
...
<configuration-tf>
<threat-feed>
<threat-feed-id>02</threat-feed-id>
<threat-feed-name>stix</threat-feed-name>
<threat-feed-date>2018.10.25/11:25:32</threat-feed-date>
<threat-feed-type>ip-address</threat-feed-type>
<feed-server>105.134.171.24</feed-server>
<feed-priority>ip-address</feed-priority>
</threat-feed>
</configuration-tf>
...
...
Figure 9: An XML Example for Threat-feed Configuration
Usually, STIX can be obtained from a TAXII server which contains a
collection of cyber threat information formatted in STIX. Here, the
"feed-server" leaf contains the ip-address of the TAXII server, so
that recent threat related information can be collected when the
configuration is set.
7. Security Considerations
The data model for the I2NSF Consumer-Facing Interface is derived
from the I2NSF Consumer-Facing Interface Information Model
[client-facing-inf-im], so the same security considerations with the
information model should be included in this document. The data
model needs to support a mechanism to protect Consumer-Facing
Interface to Security Controller.
8. References
8.1. Normative References
[RFC3444] Pras, A., "On the Difference between Information Models
and Data Models", RFC 3444, January 2003.
8.2. Informative References
[client-facing-inf-im]
Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
S., and L. Xia, "Information model for Client-Facing
Interface to Security Controller", draft-kumar-i2nsf-
client-facing-interface-im-07 (work in progress), July
2018.
[client-facing-inf-req]
Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
S., and L. Xia, "Requirements for Client-Facing Interface
to Security Controller", draft-ietf-i2nsf-client-facing-
interface-req-05 (work in progress), May 2018.
[i2nsf-framework]
Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, February 2018.
[i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Birkholz, H., and L.
Xia, "Information model for Client-Facing Interface to
Security Controller", draft-ietf-i2nsf-terminology-06
(work in progress), July 2018.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface-
dm-01
The following changes have been made from draft-ietf-i2nsf-consumer-
facing-interface-dm-01:
o In Section 6, four additional XML output examples (VoIP, DDoS-
attack, Time-based Firewall and Web-filter) for security policies
are added. Also, an example XML output for Threat-feed
configuration is added using STIX and TAXII as a threat-feed
example.
o The overall organization of the YANG data model and its data types
have also been reviewed and corrected, and produced the
corresponding data tree as shown in the Sections 4 and 5.
o Overall editorial errors have been corrected.
Appendix B. Acknowledgments
This work was supported by Institute for Information & communications
Technology Promotion(IITP) grant funded by the Korea government(MSIP)
(No.R-20160222-002755, Cloud based Security Intelligence Technology
Development for the Customized Security Service Provisioning).
Appendix C. Contributors
This document is made by the group effort of I2NSF working group.
Many people actively contributed to this document, such as Mahdi F.
Dachmehchi and Daeyoung Hyun. The following are considered co-
authors:
o Hyoungshick Kim (Sungkyunkwan University)
o Seungjin Lee (Sungkyunkwan University)
o Jinyong Tim Kim (Sungkyunkwan University)
Authors' Addresses
Jaehoon Paul Jeong Jaehoon Paul Jeong
Department of Software Department of Software
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 31 299 4957 Phone: +82 31 299 4957
Fax: +82 31 290 7996 Fax: +82 31 290 7996
EMail: pauljeong@skku.edu EMail: pauljeong@skku.edu
 End of changes. 36 change blocks. 
179 lines changed or deleted 365 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/