< draft-ietf-i2nsf-consumer-facing-interface-dm-03.txt   draft-ietf-i2nsf-consumer-facing-interface-dm-04.txt >
I2NSF 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: September 12, 2019 T. Ahn Expires: October 6, 2019 T. Ahn
Korea Telecom Korea Telecom
R. Kumar R. Kumar
Juniper Networks Juniper Networks
S. Hares S. Hares
Huawei Huawei
March 11, 2019 April 4, 2019
I2NSF Consumer-Facing Interface YANG Data Model I2NSF Consumer-Facing Interface YANG Data Model
draft-ietf-i2nsf-consumer-facing-interface-dm-03 draft-ietf-i2nsf-consumer-facing-interface-dm-04
Abstract Abstract
This document describes an information model and a YANG data model This document describes an information model and a YANG data model
for the Consumer-Facing Interface between an Interface to Network for the Consumer-Facing Interface between an Interface to Network
Security Functions (I2NSF) User and Security Controller in an I2NSF Security Functions (I2NSF) User and Security Controller in an I2NSF
system in a Network Functions Virtualization (NFV) environment. The system in a Network Functions Virtualization (NFV) environment. The
information model defines various managed objects and relationship information model defines various managed objects and relationship
among these objects needed to build the interface. The information among these objects needed to build the interface. The information
model is organized based on the "Event-condition-Event" (ECA) policy model is organized based on the "Event-condition-Event" (ECA) policy
model defined by a capability information model for Interface to model defined by a capability information model for Interface to
Network Security Functions (I2NSF)[draft-ietf-i2nsf-capability], and Network Security Functions (I2NSF)[i2nsf-capability-im], and the data
the data model is defined for enabling different users of a given model is defined for enabling different users of a given I2NSF system
I2NSF system to define, manage, and monitor security policies for to define, manage, and monitor security policies for specific flows
specific flows within an administrative domain. within an administrative domain.
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 September 12, 2019. This Internet-Draft will expire on October 6, 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 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Information Model for Policy . . . . . . . . . . . . . . . . 5 4. Information Model for Policy . . . . . . . . . . . . . . . . 5
4.1. Event Sub-Model . . . . . . . . . . . . . . . . . . . . . 6 4.1. Event Sub-model . . . . . . . . . . . . . . . . . . . . . 7
4.2. Condition Sub-Model . . . . . . . . . . . . . . . . . . . 7 4.2. Condition Sub-model . . . . . . . . . . . . . . . . . . . 7
4.3. Action Sub-Model . . . . . . . . . . . . . . . . . . . . 9 4.3. Action Sub-model . . . . . . . . . . . . . . . . . . . . 9
5. Information Model for Multi-Tenancy . . . . . . . . . . . . . 9 5. Information Model for Multi-Tenancy . . . . . . . . . . . . . 10
5.1. Policy-Domain . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Policy Domain . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Policy-Tenant . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Policy Tenant . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Policy-Role . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Policy Role . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Policy-User . . . . . . . . . . . . . . . . . . . . . . . 12 5.4. Policy User . . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Policy Management Authentication Method . . . . . . . . . 13 5.5. Policy Management Authentication Method . . . . . . . . . 13
6. Information Model for Policy Endpoint Groups . . . . . . . . 14 6. Information Model for Policy Endpoint Groups . . . . . . . . 14
6.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Device-Group . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Location-Group . . . . . . . . . . . . . . . . . . . . . 16 6.3. Location Group . . . . . . . . . . . . . . . . . . . . . 16
7. Information Model for Threat Prevention . . . . . . . . . . . 17 7. Information Model for Threat Prevention . . . . . . . . . . . 17
7.1. Threat-Feed . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Payload-content . . . . . . . . . . . . . . . . . . . . . 19 7.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 19
8. Role-Based Acess Control (RBAC) . . . . . . . . . . . . . . . 19 8. Role-based Acess Control (RBAC) . . . . . . . . . . . . . . . 19
9. YANG Data Model for Security Policies for Consumer-Facing 9. YANG Data Model for Security Policies for Consumer-Facing
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Example XML Output for Various Scenarios . . . . . . . . . . 37 10. Example XML Output for Various Scenarios . . . . . . . . . . 38
10.1. DB registration: Information of positions and devices 10.1. DB Registration: Information of Positions and Devices
(Endpoint group) . . . . . . . . . . . . . . . . . . . . 38 (Endpoint Group) . . . . . . . . . . . . . . . . . . . . 39
10.2. Scenario 1: Block SNS access during business hours . . . 38 10.2. Scenario 1: Block SNS Access during Business Hours . . . 39
10.3. Scenario 2: Block malicious VoIP/VoLTE packets coming to 10.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to
the company . . . . . . . . . . . . . . . . . . . . . . 40 a Company . . . . . . . . . . . . . . . . . . . . . . . 41
10.4. Scenario 3: Mitigate HTTP and HTTPS flood attacks on a 10.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a
company web Server . . . . . . . . . . . . . . . . . . . 41 Company Web Server . . . . . . . . . . . . . . . . . . . 42
11. Security Considerations . . . . . . . . . . . . . . . . . . . 43 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
13.1. Normative References . . . . . . . . . . . . . . . . . . 43 13.1. Normative References . . . . . . . . . . . . . . . . . . 44
13.2. Informative References . . . . . . . . . . . . . . . . . 43 13.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing- Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-
interface-dm-02 . . . . . . . . . . . . . . . . . . 46 interface-dm-03 . . . . . . . . . . . . . . . . . . 47
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 46 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 47
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 47 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
In I2NSF framework, each vendor can register their NSFs using the In an I2NSF framework, each vendor can register their NSFs using a
Vendor Management System (VMS). Assuming that vendors also provide Developer's Management System (DMS). Assuming that vendors also
the front-end web applications registered with the I2NSF provider, provide the front-end web applications registered with an I2NSF User,
the Consumer-Facing Interface is required because the web the Consumer-Facing Interface is required because the web
applications developed by each vendor need to have a standard applications developed by each vendor need to have a standard
interface specifying the data types used when I2NSF user and security interface specifying the data types used when the I2NSF User and
controller communicate using this interface. Therefore, this Security Controller communicate using this interface. Therefore,
document specifies the required information, their data types, and this document specifies the required information, their data types,
encoding schemes so that any data (security policy) transferred and encoding schemes so that high-level security policies (or
through the Consumer-Facing Interface can easily be translated by the configuration information for security policies) can be transferred
security controller into low-level security policies. The translated to the Security Controller through the Consumer-Facing Interface.
policies are delivered to Network Security Functions (NSFs) according These policies can easily be translated by the Security Controller
to their respective security capabilities for securiy enforcement. into low-level security policies. The Security Controller delivers
the translated policies to Network Security Functions (NSFs)
according to their respective security capabilities for the required
securiy enforcement.
The Consumer-Facing Interface would be built using a set of objects, The Consumer-Facing Interface would be built using a set of objects,
with each object capturing a unique set of information from Security with each object capturing a unique set of information from Security
Admin (i.e., I2NSF User [RFC8329]) needed to express a Security Administrator (i.e., I2NSF User [RFC8329]) needed to express a
Policy. An object may have relationship with various other objects Security Policy. An object may have relationship with various other
to express a complete set of requirement. An information model objects to express a complete set of requirement. An information
captures the managed objects and relationship among these objects. model captures the managed objects and relationship among these
The information model proposed in this document is structured in objects. The information model proposed in this document is
accordance with the "Event-Condition-Event" (ECA) policy model. structured in accordance with the "Event-Condition-Event" (ECA)
policy model.
An NSF Capability model is proposed in [draft-ietf-i2nsf-capability] An NSF Capability model is proposed in [i2nsf-capability-im] as the
as the basic model for both the NSF-Facing interface and Consumer- basic model for both the NSF-Facing interface and Consumer-Facing
Facing Interface security policy model of this document. Interface security policy model of this document.
[RFC3444] explains differences between an information and data model. [RFC3444] explains differences between an information and data model.
This document use the guidelines in [RFC3444] to define both the This document use the guidelines in [RFC3444] to define both the
information and data model for Consumer-Facing Interface. Figure 1 information and data model for Consumer-Facing Interface. Figure 1
shows a high-level abstraction of Consumer-Facing Interface. A data shows a high-level abstraction of Consumer-Facing Interface. A data
model, which represents an implementation of the information model in model, which represents an implementation of the information model in
a specific data representation language, is also defined in the later a specific data representation language, is also defined in this
sections of this document (see section 10). document.
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| Consumer-facing | | Consumer-facing | | Consumer-Facing | | Consumer-Facing |
| Interface +--->+ Interface | | Interface +--->+ Interface |
|Information Model| | Data Model | |Information Model| | Data Model |
+--------+--------+ +-----------------+ +--------+--------+ +-----------------+
^ ^
| |
+-------------+-------------+------------+ +-------------+-------------+------------+
| | | | | | | |
+----+----+ +-----+----+ +-----+----+ +----+----+ +----+----+ +-----+----+ +-----+----+ +----+----+
| Multi | | Policy | | Endpoint | | Threat | | Multi | | Policy | | Endpoint | | Threat |
| Tenancy | | | | groups | | feed | | Tenancy | | | | groups | | feed |
skipping to change at page 4, line 41 skipping to change at page 4, line 44
Figure 1: Diagram for High-level Abstraction of Consumer-Facing Figure 1: Diagram for High-level Abstraction of Consumer-Facing
Interface Interface
Data models are defined at a lower level of abstraction and provide Data models are defined at a lower level of abstraction and provide
many details. They provide details about the implementation of a many details. They provide details about the implementation of a
protocol's specification, e.g., rules that explain how to map managed protocol's specification, e.g., rules that explain how to map managed
objects onto lower-level protocol constructs. Since conceptual objects onto lower-level protocol constructs. Since conceptual
models can be implemented in different ways, multiple data models can models can be implemented in different ways, multiple data models can
be derived by a single information model. be derived by a single information model.
The efficient and flexible provisioning of network functions by NFV The efficient and flexible provisioning of network functions by a
leads to a rapid advance in the network industry. As practical Network Functions Virtualization (NFV) system leads to a rapid
applications, network security functions (NSFs), such as firewall, advance in the network industry. As practical applications, Network
intrusion detection system (IDS)/intrusion protection system (IPS), Security Functions (NSFs), such as firewall, Intrusion Detection
and attack mitigation, can also be provided as virtual network System (IDS)/Intrusion Prevention System (IPS), and attack
functions (VNF) in the NFV system. By the efficient virtual mitigation, can also be provided as Virtual Network Functions (VNF)
technology, these VNFs might be automatically provisioned and in the NFV system. By the efficient virtual technology, these VNFs
dynamically migrated based on real-time security requirements. This might be automatically provisioned and dynamically migrated based on
document presents a YANG data model to implement security functions real-time security requirements. This document presents a YANG data
based on NFV. model to implement security functions based on NFV.
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 RFC 2119 [RFC3444] document are to be interpreted as described in RFC 2119 [RFC3444]
RFC8174 [RFC8174]. RFC8174 [RFC8174].
3. Terminology 3. Terminology
This document uses the terminology described in This document uses the terminology described in
[i2nsf-terminology][client-facing-inf-im][client-facing-inf-req]. [i2nsf-terminology][client-facing-inf-req].
This document follows the guidelines of [RFC6087], uses the common This document follows the guidelines of [RFC6087], uses the common
YANG types defined in [RFC6991], and adopts the Network Management YANG types defined in [RFC6991], and adopts the Network Management
Datastore Architecture (NMDA). The meaning of the symbols in tree Datastore Architecture (NMDA). The meaning of the symbols in tree
diagrams is defined in [RFC8340]. diagrams is defined in [RFC8340].
4. Information Model for Policy 4. Information Model for Policy
A Policy object represents a mechanism to express a Security Policy A Policy object represents a mechanism to express a Security Policy
by Security Admin (i.e., I2NSF User) using Consumer-Facing Interface by Security Administrator (i.e., I2NSF User) using Consumer-Facing
toward Security Controller; the policy would be enforced on an NSF. Interface toward Security Controller; the policy would be enforced on
Figure 2 shows the XML instance of the Policy object. The Policy an NSF. Figure 2 shows the XML instance of the Policy object. The
object SHALL have following information: Policy object SHALL have following information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
Date: Date when this object was created or last modified. Date: Date when this object was created or last modified.
Rules: This field contains a list of rules. If the rule does not Rules: This field contains a list of rules. If the rule does not
have a user-defined precedence, then any conflict must be have a user-defined precedence, then any conflict must be
manually resolved. manually resolved.
+--rw policy +--rw policy
+--rw policy-name? string +--rw policy-name? string
+--rw rule* [rule-name] +--rw rule* [rule-name]
+--rw event | +--rw event
+--rw condition | +--rw condition
+--rw action | +--rw action
...
Figure 2: Policy YANG Data tree Figure 2: Policy YANG Data Tree
A policy is a container of Rules. In order to express a Rule, a Rule A policy is a container of Rules. In order to express a Rule, a Rule
must have complete information such as where and when a policy needs must have complete information such as where and when a policy needs
to be applied. This is done by defining a set of managed objects and to be applied. This is done by defining a set of managed objects and
relationship among them. A Policy Rule may be related segmentation, relationship among them. A Policy Rule may be related segmentation,
threat mitigation or telemetry data collection from an NSF in the threat mitigation or telemetry data collection from an NSF in the
network, which will be specified as the sub-model of the policy model network, which will be specified as the sub-model of the policy model
in the subsequent sections. Figure 3 shows the XML instance of the in the subsequent sections. Figure 3 shows the XML instance of the
Rule object. The rule object SHALL have the following information: Rule object. The rule object SHALL have the following information:
skipping to change at page 6, line 26 skipping to change at page 6, line 32
Condition: This field contains all the checking conditions to Condition: This field contains all the checking conditions to
apply to the objective traffic. See details in apply to the objective traffic. See details in
Section 4.2. Section 4.2.
Action: This field identifies the action taken when a rule is Action: This field identifies the action taken when a rule is
matched. There is always an implicit action to drop matched. There is always an implicit action to drop
traffic if no rule is matched for a traffic type. See traffic if no rule is matched for a traffic type. See
details in Section 4.3. details in Section 4.3.
IPsec: This field contains the information about IPsec type.
There are two types such as IPsec-IKE and IPsec-IKEless
[i2nsf-ipsec].
Owner: This field contains the onwer of the rule. For example, Owner: This field contains the onwer of the rule. For example,
the person who created it, and eligible for modifying it. the person who created it, and eligible for modifying it.
+--rw rule* [rule-name] +--rw rule* [rule-name]
+--rw rule-name string +--rw rule-name string
+--rw date? yang:date-and-time +--rw date? yang:date-and-time
+--rw event* [name] +--rw event* [name]
+--rw condition +--rw condition
+--rw action +--rw action
+--rw ipsec
+--rw owner? string +--rw owner? string
Figure 3: YANG Data tree for Rule Figure 3: YANG Data Tree for Rule
4.1. Event Sub-Model 4.1. Event Sub-model
The Event Object contains information related to scheduling a Rule. The Event Object contains information related to scheduling a Rule.
The Rule could be activated based on a time calendar or security The Rule could be activated based on a time calendar or security
event including threat level changes. Figure 4 shows the XML event including threat level changes. Figure 4 shows the XML
instance of the Event object. Event object SHALL have following instance of the Event object. Event object SHALL have following
information: information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
Date: This field indicates the date when this object was created Date: This field indicates the date when this object was created
skipping to change at page 7, line 25 skipping to change at page 7, line 38
+--rw date? yang:date-and-time +--rw date? yang:date-and-time
+--rw event-type enumeration +--rw event-type enumeration
+--rw time-information +--rw time-information
+--rw time +--rw time
| +--rw begin-time begin-time-type | +--rw begin-time begin-time-type
| +--rw end-time end-time-type | +--rw end-time end-time-type
+--rw recursive +--rw recursive
+--rw recur boolean +--rw recur boolean
+--rw recursive-type? enumeration +--rw recursive-type? enumeration
Figure 4: Event sub-model YANG data tree Figure 4: Event Sub-model YANG Data Tree
4.2. Condition Sub-Model 4.2. Condition Sub-model
This object represents Conditions that Security Admin wants to apply This object represents Conditions that Security Administrator wants
the checking on the traffic in order to determine whether the set of to apply the checking on the traffic in order to determine whether
actions in the Rule can be executed or not. The condition sub-model the set of actions in the Rule can be executed or not. The Condition
consists of 3 different types of three containers each representing Sub-model consists of 3 different types of three containers each
different cases, such as general firewall and ddos-mitigation cases, representing different cases, such as general firewall and DDoS-
and a case when the condition is based on the payload strings of mitigation cases, and a case when the condition is based on the
packets. Each containers have source-target and destination-target payload strings of packets. Each containers have source-target and
to represent the source and destination for each case. Figure 5 destination-target to represent the source and destination for each
shows the XML instance of the Condition object.The Condition submodel case. Figure 5 shows the XML instance of the Condition object. The
SHALL have following information: Condition Sub-model SHALL have following information:
Firewall-condition: This field represents the general firewall Firewall-condition: This field represents the general firewall
case, where a security admin can set up firewall conditions case, where a security admin can set up firewall conditions
using the information present in this field. The source using the information present in this field. The source
and destination is represented as source-target and and destination is represented as source-target and
destination-target, each referring to the IP-address-based destination-target, each referring to the IP-address-based
groups defined in the endpoint-group. groups defined in the endpoint-group.
DDoS-condition: This field represents the condition for DDoS DDoS-condition: This field represents the condition for DDoS
mitigation, where a security admin can set up DDoS mitigation, where a security admin can set up DDoS
skipping to change at page 9, line 15 skipping to change at page 9, line 26
| +--rw src-target* -> /policy | +--rw src-target* -> /policy
| /threat-prevention | /threat-prevention
| /threat-feed-list | /threat-feed-list
| /name | /name
+--rw destination-target +--rw destination-target
+--rw dest-target? -> /policy +--rw dest-target? -> /policy
/threat-prevention /threat-prevention
/threat-feed-list /threat-feed-list
/name /name
Figure 5: Condition sub-model YANG data tree Figure 5: Condition Sub-model YANG Data Tree
4.3. Action Sub-Model 4.3. Action Sub-model
This object represents actions that Security Admin wants to perform This object represents actions that Security Admin wants to perform
based on certain traffic class. Figure 6 shows the XML instance of based on certain traffic class. Figure 6 shows the XML instance of
the Action object. The Action object SHALL have following the Action object. The Action object SHALL have following
information: information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
Date: This field indicates the date when this object was created Date: This field indicates the date when this object was created
or last modified. or last modified.
Action: This field identifies the action when a rule is matched Action: This field identifies the action when a rule is matched
by an NSF. The action could be one of "PASS", "DROP", by an NSF. The action could be one of "PASS", "DROP",
"ALERT", "MIRROR", and "LOG". "ALERT", "MIRROR", and "LOG".
+--rw action +--rw action
+--rw name string +--rw name string
+--rw date yang:date-and-time +--rw date yang:date-and-time
+--rw action string +--rw action string
Figure 6: Action sub-model YANG data tree Figure 6: Action Sub-model YANG Data Tree
5. Information Model for Multi-Tenancy 5. Information Model for Multi-Tenancy
Multi-tenancy is an important aspect of any application that enables Multi-tenancy is an important aspect of any application that enables
multiple administrative domains in order to manage application multiple administrative domains in order to manage application
resources. An Enterprise organization may have multiple tenants or resources. An Enterprise organization may have multiple tenants or
departments such as Human Resources (HR), Finance, and Legal, with departments such as Human Resources (HR), Finance, and Legal, with
each tenant having a need to manage their own Security Policies. In each tenant having a need to manage their own Security Policies. In
a Service Provider, a tenant could represent a Customer that wants to a Service Provider, a tenant could represent a Customer that wants to
manage its own Security Policies. There are multiple managed objects manage its own Security Policies. There are multiple managed objects
that constitute multi-tenancy aspects as shown in Figure 7. This that constitute multi-tenancy aspects as shown in Figure 7. This
section lists these objects and any relationship among these objects. section lists these objects and the relationship among these objects.
Below diagram shows an example of multi-tenancy in an Enterprise Below diagram shows an example of multi-tenancy in an Enterprise
domain. domain.
+-------------------+ +-------------------+
(Multi-Tenancy) | Domain | (Multi-Tenancy) | Domain |
|(e.g., Enterprise) | |(e.g., Enterprise) |
+---------+---------+ +---------+---------+
^ ^
| |
+--------------------+--------------------+ +--------------------+--------------------+
skipping to change at page 10, line 32 skipping to change at page 10, line 43
| Sub-domain 1..n | | Sub-domain 1..n | | Sub-domain 1..n | | Sub-domain 1..n | | Sub-domain 1..n | | Sub-domain 1..n |
+--------+--------+ +--------+--------+ +--------+--------+ +--------+--------+ +--------+--------+ +--------+--------+
^ ^ ^ ^ ^ ^
| | | | | |
+--------+--------+ +--------+--------+ +--------+--------+ +--------+--------+ +--------+--------+ +--------+--------+
| Tenant 1..n | | Tenant 1..n | | Tenant 1..n | | Tenant 1..n | | Tenant 1..n | | Tenant 1..n |
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
Figure 7: Multi-tenancy Diagram Figure 7: Multi-tenancy Diagram
5.1. Policy-Domain 5.1. Policy Domain
This object defines a boundary for the purpose of policy management This object defines a boundary for the purpose of policy management
within a Security Controller. This may vary based on how the within a Security Controller. This may vary based on how the
Security Controller is deployed and hosted. For example, if an Security Controller is deployed and hosted. For example, if an
Enterprise hosts a Security Controller in their network; the domain Enterprise hosts a Security Controller in their network; the domain
in this case could just be the one that represents that Enterprise. in this case could just be the one that represents that Enterprise.
But if a Cloud Service Provider hosts managed services, then a domain But if a Cloud Service Provider hosts managed services, then a domain
could represent a single customer of that Provider. Figure 8 shows could represent a single customer of that Provider. Figure 8 shows
the XML instance of the Policy-domain object. Multi-tenancy model the XML instance of the Policy-Domain object. Multi-tenancy model
should be able to work in all such environments. The Policy-Domain should be able to work in all such environments. The Policy-Domain
object SHALL have following information: object SHALL have the following information:
Name: Name of the organization or customer representing this Name: Name of the organization or customer representing this
domain. domain.
Address: Address of the organization or customer. Address: Address of the organization or customer.
Contact: Contact information of the organization or customer. Contact: Contact information of the organization or customer.
Date: Date when this account was created or last modified. Date: Date when this account was created or last modified.
skipping to change at page 11, line 24 skipping to change at page 11, line 34
+--rw address? string +--rw address? string
+--rw contact? string +--rw contact? string
+--rw policy-tenant* [name] +--rw policy-tenant* [name]
+--rw authentication-method? -> /policy +--rw authentication-method? -> /policy
/multi-tenancy /multi-tenancy
/policy-mgnt-auth-method /policy-mgnt-auth-method
/name /name
... ...
... ...
Figure 8: Policy domain YANG data tree Figure 8: Policy Domain YANG Data Tree
5.2. Policy-Tenant 5.2. Policy Tenant
This object defines an entity within an organization. The entity This object defines an entity within an organization. The entity
could be a department or business unit within an Enterprise could be a department or business unit within an Enterprise
organization that would like to manage its own Policies due to organization that would like to manage its own Policies due to
regulatory compliance or business reasons. Figure 9 shows the XML regulatory compliance or business reasons. Figure 9 shows the XML
instance of the Policy-tenant object. The Policy-Tenant object SHALL instance of the Policy-Tenant object. The Policy-Tenant object SHALL
have following information: have the following information:
Name: Name of the Department or Division within an organization. Name: Name of the Department or Division within an organization.
Date: Date when this account was created or last modified. Date: Date when this account was created or last modified.
Domain: This field identifies the domain to which this tenant Domain: This field identifies the domain to which this tenant
belongs. This should be a reference to a Policy-Domain belongs. This should be a reference to a Policy-Domain
object. object.
+--rw policy-tenant* [name] +--rw policy-tenant* [name]
+--rw name string +--rw name string
+--rw date? yang:date-and-time +--rw date? yang:date-and-time
+--rw domain? -> /policy +--rw domain? -> /policy
/multi-tenancy /multi-tenancy
/policy-domain /policy-domain
/name /name
Figure 9: Policy tenant YANG data tree Figure 9: Policy Tenant YANG Data Tree
5.3. Policy-Role 5.3. Policy Role
This object defines a set of permissions assigned to a user in an This object defines a set of permissions assigned to a user in an
organization that wants to manage its own Security Policies. It organization that wants to manage its own Security Policies. It
provides a convenient way to assign policy users to a job function or provides a convenient way to assign policy users to a job function or
a set of permissions within the organization. Figure 10 shows the a set of permissions within the organization. Figure 10 shows the
XML instance of the Policy-role object. The Policy-Role object SHALL XML instance of the Policy-Role object. The Policy-Role object SHALL
have the following information: have the following information:
Name: This field identifies the name of the role. Name: This field identifies the name of the role.
Date: Date when this role was created or last modified. Date: Date when this role was created or last modified.
Access-Profile: This field identifies the access profile for the Access-Profile: This field identifies the access profile for the
role. The profile grants or denies the permissions to role. The profile grants or denies the permissions to
access Endpoint Groups for the purpose of policy management access Endpoint Groups for the purpose of policy management
or may restrict certain operations related to policy or may restrict certain operations related to policy
skipping to change at page 12, line 43 skipping to change at page 12, line 47
read-and-write, to choose from for each access-profile. read-and-write, to choose from for each access-profile.
+--rw policy-role +--rw policy-role
| +--rw name? string | +--rw name? string
| +--rw date? yang:date-and-time | +--rw date? yang:date-and-time
| +--rw access-profile* [name] | +--rw access-profile* [name]
| +--rw name string | +--rw name string
| +--rw date? yang:date-and-time | +--rw date? yang:date-and-time
| +--rw permission-type? identityref | +--rw permission-type? identityref
Figure 10: Policy role YANG data tree Figure 10: Policy Role YANG Data Tree
5.4. Policy-User 5.4. Policy User
This object represents a unique identity of a user within an This object represents a unique identity of a user within an
organization. The identity authenticates with Security Controller organization. The identity authenticates with Security Controller
using credentials such as a password or token in order to perform using credentials such as a password or token in order to perform
policy management. A user may be an individual, system, or policy management. A user may be an individual, system, or
application requiring access to Security Controller. Figure 11 shows application requiring access to Security Controller. Figure 11 shows
the XML instance of the Policy-user object. The Policy-User object the XML instance of the Policy-User object. The Policy-User object
SHALL have the following information: SHALL have the following information:
Name: Name of a user. Name: Name of a user.
Date: Date when this user was created or last modified. Date: Date when this user was created or last modified.
Password: User password for basic authentication. Password: User password for basic authentication.
Email: E-mail address of the user. Email: E-mail address of the user.
skipping to change at page 13, line 34 skipping to change at page 13, line 41
| +--rw date? yang:date-and-time | +--rw date? yang:date-and-time
| +--rw password? string | +--rw password? string
| +--rw email? string | +--rw email? string
| +--rw scope-type? identityref | +--rw scope-type? identityref
| +--rw role? -> /policy | +--rw role? -> /policy
/multi-tenancy /multi-tenancy
/policy-role /policy-role
/access-profile /access-profile
/name /name
Figure 11: Policy user YANG data tree Figure 11: Policy User YANG Data Tree
5.5. Policy Management Authentication Method 5.5. Policy Management Authentication Method
This object represents authentication schemes supported by Security This object represents authentication schemes supported by Security
Controller. Figure 12 shows the XML instance of the Policy Controller. Figure 12 shows the XML instance of the Policy
Management Authentication Method onject. This Policy-Management- Management Authentication Method onject. This Policy-Management-
Authentication-Method object SHALL have the following information: Authentication-Method object SHALL have the following information:
Name: This field identifies name of this object. Name: This field identifies name of this object.
skipping to change at page 14, line 15 skipping to change at page 14, line 21
Mutual-Authentication: This field indicates whether mutual Mutual-Authentication: This field indicates whether mutual
authentication is mandatory or not. authentication is mandatory or not.
Token-Server: This field stores the information about server that Token-Server: This field stores the information about server that
validates the token submitted as credentials. validates the token submitted as credentials.
Certificate-Server: This field stores the information about Certificate-Server: This field stores the information about
server that validates certificates submitted as server that validates certificates submitted as
credentials. credentials.
IPsec: This field contains the information about IPsec type.
There are two types; 1) IPsec-IKE and IPsec-IKEless.
Single Sign-on-Server: This field stores the information about Single Sign-on-Server: This field stores the information about
server that validates user credentials. server that validates user credentials.
+--rw policy-mgnt-auth-method* [name] +--rw policy-mgnt-auth-method* [name]
+--rw name string +--rw name string
+--rw date? yang:date-and-time +--rw date? yang:date-and-time
+--rw mutual-authentication? boolean +--rw mutual-authentication? boolean
+--rw password +--rw password
| +--rw password? password-type | +--rw password? password-type
+--rw token +--rw token
| +--rw token? string | +--rw token? string
| +--rw token-server? inet:ipv4-address | +--rw token-server? inet:ipv4-address
+--rw certificate +--rw certificate
| +--rw certificate? certificate-type | +--rw certificate? certificate-type
| +--rw certificate-server? inet:ipv4-address | +--rw certificate-server? inet:ipv4-address
+--rw ipsec* [ipsec-method]
| +--rw ipsec-method identityref
+--rw single-sign-on +--rw single-sign-on
+--rw credential? certificate-type +--rw credential? certificate-type
+--rw certificate-server? inet:ipv4-address +--rw certificate-server? inet:ipv4-address
Figure 12: Policy management authentication method YANG data tree Figure 12: Policy Management Authentication Method YANG Data Tree
6. Information Model for Policy Endpoint Groups 6. Information Model for Policy Endpoint Groups
The Policy Endpoint Group is a very important part of building User- The Policy Endpoint Group is a very important part of building User-
construct based policies. Security Admin would create and use these Construct based policies. A Security Administrator would create and
objects to represent a logical entity in their business environment, use these objects to represent a logical entity in their business
where a Security Policy is to be applied. There are multiple managed environment, where a Security Policy is to be applied. There are
objects that constitute a Policy Endpoint Group as shown in multiple managed objects that constitute a Policy's Endpoint Group as
Figure 13. Figure 14 shows the XML instance of the endpoint-group shown in Figure 13. Figure 14 shows the XML instance of the
object. shows the XML instance of the User-group object.. This Endpoint-Group object. This section lists these objects and
section lists these objects and relationship among them. relationship among them.
+-------------------+ +-------------------+
| Endpoint Group | | Endpoint Group |
+---------+---------+ +---------+---------+
^ ^
| |
+--------------+----------------+ +--------------+----------------+
1..n | 1..n | 1..n | 1..n | 1..n | 1..n |
+-----+----+ +------+-----+ +-------+------+ +-----+----+ +------+-----+ +-------+------+
|User-group| |Device-group| |Location-group| |User-group| |Device-group| |Location-group|
skipping to change at page 15, line 26 skipping to change at page 15, line 31
Figure 13: Endpoint Group Diagram Figure 13: Endpoint Group Diagram
+--rw endpoint-group +--rw endpoint-group
+--rw user-group* [name] +--rw user-group* [name]
| ... | ...
+--rw device-group* [name] +--rw device-group* [name]
| ... | ...
+--rw location-group* [name] +--rw location-group* [name]
... ...
Figure 14: Endpoint Group YANG data tree Figure 14: Endpoint Group YANG Data Tree
6.1. User Group 6.1. User Group
This object represents a User-group. Figure 15 shows the XML This object represents a User-Group. Figure 15 shows the XML
instance of the User-group object.The User-Group object SHALL have instance of the User-Group object. The User-Group object SHALL have
the following information: the following information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
Date: Date when this object was created or last modified. Date: Date when this object was created or last modified.
IP-Address: This field identifies the IP address of a user. IP-Address: This field identifies the IP address of a user.
Range-IP-Address: This field is a range of IP addresses of users. Range-IP-Address: This field is a range of IP addresses of users.
skipping to change at page 16, line 16 skipping to change at page 16, line 16
+--rw name string +--rw name string
+--rw date? yang:date-and-time +--rw date? yang:date-and-time
+--rw (match-type)? +--rw (match-type)?
+--:(exact-match) +--:(exact-match)
| +--rw ip-address* inet:ipv4-address | +--rw ip-address* inet:ipv4-address
+--:(range-match) +--:(range-match)
+--rw range-ip-address* [start-ip-address end-ip-address] +--rw range-ip-address* [start-ip-address end-ip-address]
+--rw start-ip-address inet:ipv4-address +--rw start-ip-address inet:ipv4-address
+--rw end-ip-address inet:ip-address +--rw end-ip-address inet:ip-address
Figure 15: User group YANG data tree Figure 15: User Group YANG Data Tree
6.2. Device-Group 6.2. Device Group
This object represents a Device-group. Figure 16 shows the XML This object represents a Device-Group. Figure 16 shows the XML
instance of the Device-group object.The Device-Group object SHALL instance of the Device-group object.The Device-Group object SHALL
have the following information: have the following information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
Date: Date when this object was created or last modified. Date: Date when this object was created or last modified.
IP-Address: This field identifies the IP address of a device. IP-Address: This field identifies the IP address of a device.
Range-IP-Address: This field is a range of IP addresses of Range-IP-Address: This field is a range of IP addresses of
skipping to change at page 16, line 44 skipping to change at page 16, line 44
+--rw name string +--rw name string
+--rw date? yang:date-and-time +--rw date? yang:date-and-time
+--rw (match-type)? +--rw (match-type)?
+--:(exact-match) +--:(exact-match)
| +--rw ip-address* inet:ipv4-address | +--rw ip-address* inet:ipv4-address
+--:(range-match) +--:(range-match)
+--rw range-ip-address* [start-ip-address end-ip-address] +--rw range-ip-address* [start-ip-address end-ip-address]
+--rw start-ip-address inet:ipv4-address +--rw start-ip-address inet:ipv4-address
+--rw end-ip-address inet:ip-address +--rw end-ip-address inet:ip-address
Figure 16: Device group YANG data tree Figure 16: Device Group YANG Data Tree
6.3. Location-Group 6.3. Location Group
This object represents a location group based on either tag or other This object represents a location group based on either tag or other
information. Figure 17 shows the XML instance of the Location-group information. Figure 17 shows the XML instance of the Location-Group
object. The Location-group object SHALL have the following object. The Location-Group object SHALL have the following
information: information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
Date: Date when this object was created or last modified. Date: Date when this object was created or last modified.
continent: to identify which continent the location group member continent: to identify which continent the location group member
is based at. is based at.
+--rw location-group* [name] +--rw location-group* [name]
+--rw name string +--rw name string
+--rw date? yang:date-and-time +--rw date? yang:date-and-time
+--rw continent? identityref +--rw continent? identityref
Figure 17: Location group YANG data tree Figure 17: Location Group YANG Data Tree
7. Information Model for Threat Prevention 7. Information Model for Threat Prevention
The threat prevention plays an important part in the overall security The threat prevention plays an important part in the overall security
posture by reducing the attack surfaces. This information could come posture by reducing the attack surfaces. This information could come
from various threat feeds (i.e., sources for obtaining the threat from various threat feeds (i.e., sources for obtaining the threat
information), such as EmergingThreats.com or AlienVault.com. There information), such as EmergingThreats.com or AlienVault.com. There
are multiple managed objects that constitute this category. This are multiple managed objects that constitute this category. This
section lists these objects and relationship among them. Figure 19 section lists these objects and relationship among them. Figure 19
shows the XML instance of a Threat-prevention object. shows the XML instance of a Threat-Prevention object.
+-------------------+ +-------------------+
| Threat Prevention | | Threat Prevention |
+---------+---------+ +---------+---------+
^ ^
| |
+---------+---------+ +---------+---------+
1..n | 1..n | 1..n | 1..n |
+------+------+ +--------+--------+ +------+------+ +--------+--------+
| Threat-feed | | payload-content | | Threat-feed | | payload-content |
+-------------+ +-----------------+ +-------------+ +-----------------+
Figure 18: Threat Prevention Diagram Figure 18: Threat Prevention Diagram
+--rw threat-prevention +--rw threat-prevention
| +--rw threat-feed-list* [name] | +--rw threat-feed-list* [name]
| ... | ...
| +--rw payload-content* [name] | +--rw payload-content* [name]
| ... | ...
Figure 19: Threat Prevention YANG data tree Figure 19: Threat Prevention YANG Data Tree
7.1. Threat-Feed 7.1. Threat Feed
This object represents a threat feed which provides signatures of This object represents a threat feed which provides signatures of
malicious activities. Figure 20 shows the XML instance of a Threat- malicious activities. Figure 20 shows the XML instance of a Threat-
feed-list. The Threat-Feed object SHALL have the following feed-list. The Threat-Feed object SHALL have the following
information: information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
Date: Date when this object was created or last modified. Date: Date when this object was created or last modified.
skipping to change at page 18, line 49 skipping to change at page 18, line 49
| | +--:(exact-match) | | +--:(exact-match)
| | | +--rw ip-address* inet:ipv4-address | | | +--rw ip-address* inet:ipv4-address
| | +--:(range-match) | | +--:(range-match)
| | +--rw range-ip-address* [start-ip-address end-ip-address] | | +--rw range-ip-address* [start-ip-address end-ip-address]
| | +--rw start-ip-address inet:ipv4-address | | +--rw start-ip-address inet:ipv4-address
| | +--rw end-ip-address inet:ip-address | | +--rw end-ip-address inet:ip-address
| +--rw threat-feed-description? string | +--rw threat-feed-description? string
+--rw threat-file-types* identityref +--rw threat-file-types* identityref
+--rw signatures* string +--rw signatures* string
Figure 20: Threat feed YANG data tree Figure 20: Threat Feed YANG Data Tree
7.2. Payload-content 7.2. Payload Content
This object represents a custom list created for the purpose of This object represents a custom list created for the purpose of
defining exception to threat feeds. Figure 21 shows the XML instance defining exception to threat feeds. Figure 21 shows the XML instance
of a Payload-content list. The Payload-content object SHALL have the of a Payload-content list. The Payload-Content object SHALL have the
following information: following information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
Date: Date when this object was created or last modified. Date: Date when this object was created or last modified.
List-Content: This field contains contents such as IP addresses List-Content: This field contains contents such as IP addresses
or URL names. or URL names.
+--rw payload-content* [name] +--rw payload-content* [name]
| +--rw name string | +--rw name string
| +--rw date? yang:date-and-time | +--rw date? yang:date-and-time
| +--rw content* string | +--rw content* string
Figure 21: Payload-content in YANG data tree Figure 21: Payload Content in YANG Data Tree
8. Role-Based Acess Control (RBAC) 8. Role-based Acess Control (RBAC)
Role-Based Access Control (RBAC) provides a powerful and centralized Role-Based Access Control (RBAC) provides a powerful and centralized
control within a network. It is a policy neutral access control control within a network. It is a policy neutral access control
mechanism defined around roles and privileges. The components of mechanism defined around roles and privileges. The components of
RBAC, such as role-permissions, user-role and role-role RBAC, such as role-permissions, user-role and role-role
relationships, make it simple to perform user assignments. relationships, make it simple to perform user assignments.
+--------------+ +--------------+
| | | |
| User 1 + (has many) | User 1 + (has many)
| |\ | |\
+--------------+ \ +---------------+ +-------------+ +--------------+ \ +---------------+ +-------------+
. \ | | (has many) | | . \ | | (has many) | |
. --->+ List of roles +----------->+ Permissions | . --->+ List of roles +----------->+ Permissions |
+--------------+ / | | | | +--------------+ / | | | |
| | / +---------------+ +-------------+ | | / +---------------+ +-------------+
| User n +/ | User n +/
| | (has many) | | (has many)
+--------------+ +--------------+
Figure 22: RBAC Diagram Figure 22: Role-based Acess Control Diagram
As shown in Figure 22, a role represents a collection of permissions As shown in Figure 22, a role represents a collection of permissions
(e.g., accessing a file server or other particular resources). A (e.g., accessing a file server or other particular resources). A
role may be assigned to one or multiple users. Both roles and role may be assigned to one or multiple users. Both roles and
permissions can be organized in a hirarchy. A role may consists of permissions can be organized in a hirarchy. A role may consists of
other roles and permissions. other roles and permissions.
Following are the steps required to build RBAC: Following are the steps required to build RBAC:
1. Defining roles and permissions. 1. Defining roles and permissions.
skipping to change at page 20, line 22 skipping to change at page 20, line 22
2. Establishing relations among roles and permissions. 2. Establishing relations among roles and permissions.
3. Defining users. 3. Defining users.
4. Associating rules with roles and permissions. 4. Associating rules with roles and permissions.
5. assigning roles to users. 5. assigning roles to users.
9. YANG Data Model for Security Policies for Consumer-Facing Interface 9. YANG Data Model for Security Policies for Consumer-Facing Interface
The main objective of this data model is to fully transform the The main objective of this data model is to provide both an
information model [client-facing-inf-im] into a YANG data model that information model and the corresponding YANG data model of I2NSF
can be used for delivering control and management messages via the Consumer-Facing Interface. This interface can be used to deliver
Consumer-Facing Interface between an I2NSF User and Security control and management messages between an I2NSF User and Security
Controller for the I2NSF User's high-level security policies. Controller for the I2NSF User's high-level security policies.
The semantics of the data model must be aligned with the information The semantics of the data model must be aligned with the information
model of the Consumer-Facing Interface. The transformation of the model of the Consumer-Facing Interface. The transformation of the
information model was performed so that this YANG data model can information model was performed so that this YANG data model can
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.
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.
<CODE BEGINS> file "ietf-cfi-policy.yang" <CODE BEGINS> file "ietf-cfi-policy.yang"
module ietf-i2nsf-cfi-policy { module ietf-i2nsf-cfi-policy {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy";
prefix prefix
cfi-policy; cfi-policy;
import ietf-yang-types{ import ietf-yang-types{
prefix yang; prefix yang;
reference reference
"Section 3 of RFC 6991"; "Section 3 of RFC 6991";
} }
skipping to change at page 21, line 47 skipping to change at page 21, line 47
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2019-03-11"{ revision "2019-04-04"{
description "latest revision"; description "latest revision";
reference reference
"draft-ietf-consumer-facing-interface-dm-02"; "draft-ietf-consumer-facing-interface-dm-03";
} }
identity permission-type { identity permission-type {
description description
"Base identity for the permission types."; "Base identity for the permission types.";
} }
identity read-only { identity read-only {
base permission-type; base permission-type;
description description
"Identity for read-only permission."; "Identity for read-only permission.";
skipping to change at page 24, line 4 skipping to change at page 24, line 4
identity trojan { identity trojan {
base malware-file-type; base malware-file-type;
description description
"Identity for Trojan infection event types."; "Identity for Trojan infection event types.";
} }
identity ransomeware { identity ransomeware {
base malware-file-type; base malware-file-type;
description description
"Identity for ransomeware infection event types."; "Identity for ransomeware infection event types.";
} }
identity ipsec-type {
description
"Base identity for the IPsec types.";
}
identity ike {
base ipsec-type;
description
"Identity for ipsec-ike";
}
identity ikeless {
base ipsec-type;
description
"Identity for ipsec-ikeless";
}
identity continent { identity continent {
description description
"Base Identity for continent types."; "Base Identity for continent types.";
} }
identity africa { identity africa {
base continent; base continent;
description description
"Identity for africa."; "Identity for africa.";
} }
skipping to change at page 25, line 21 skipping to change at page 25, line 38
among *nix systems. CER certificate extension, which is an among *nix systems. CER certificate extension, which is an
alternate form of .crt (Microsoft Convention) You can use MS to alternate form of .crt (Microsoft Convention) You can use MS to
convert .crt to .cer (.both DER encoded .cer, or base64[PEM] convert .crt to .cer (.both DER encoded .cer, or base64[PEM]
encoded .cer). The KEY extension is used both for public and encoded .cer). The KEY extension is used both for public and
private PKCS#8 keys. The keys may be encoded as binary DER or private PKCS#8 keys. The keys may be encoded as binary DER or
as ASCII PEM."; as ASCII PEM.";
} }
grouping meta { grouping meta {
description description
"The purpose of this grouping is to avoid repetition of same fields, such as 'name' and 'date'."; "The purpose of this grouping is to avoid repetition
of same fields, such as 'name' and 'date'.";
leaf name { leaf name {
type string; type string;
description "This is the name for an entity."; description "This is the name for an entity.";
} }
leaf date { leaf date {
type yang:date-and-time; type yang:date-and-time;
description "This is the date when the entity is created or modified."; description "This is the date when the entity is
created or modified.";
} }
} }
grouping ip-address { grouping ip-address {
description description
"There are two types to configure a security policy "There are two types to configure a security policy
for IPv4 address, such as exact match and range match."; for IPv4 address, such as exact match and range match.";
choice match-type { choice match-type {
description description
"User can choose between 'exact match' and 'range match'."; "User can choose between 'exact match' and 'range match'.";
skipping to change at page 27, line 34 skipping to change at page 28, line 4
} }
description description
"There can be a multiple number of security rules in "There can be a multiple number of security rules in
a policy object. This object is a policy instance to a policy object. This object is a policy instance to
have complete information such as where and when a have complete information such as where and when a
policy need to be applied."; policy need to be applied.";
list rule { list rule {
leaf rule-name { leaf rule-name {
type string; type string;
mandatory true;
description description
"This represents the name for rules."; "This represents the name for rules.";
} }
key "rule-name"; key "rule-name";
description description
"There can be a single or multiple number of rules."; "There can be a single or multiple number of rules.";
leaf date { leaf date {
type yang:date-and-time; type yang:date-and-time;
description description
"Date this object was created or last "Date this object was created or last
modified"; modified";
} }
list event { container event {
uses meta; description
key "name"; "This represents the event map group name.";
description
"This represents the event map group name.";
leaf security-event { leaf security-event {
type identityref { type identityref {
base security-event-type; base security-event-type;
} }
description description
"This contains the description of security events."; "This contains the description of security events.";
} }
leaf enforce-type { leaf enforce-type {
type enumeration{ type enumeration{
enum admin-enforced { enum admin-enforced {
skipping to change at page 32, line 8 skipping to change at page 32, line 25
condition destination."; condition destination.";
} }
} }
} }
} }
container action { container action {
description description
"This is the action container."; "This is the action container.";
leaf primary-action { leaf primary-action {
type string; type string;
mandatory true;
description description
"This field identifies the action when a rule "This field identifies the action when a rule
is matched by NSF. The action could be one of is matched by NSF. The action could be one of
'PERMIT', 'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS', 'PERMIT', 'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS',
'AUTHENTICATE-SESSION', 'IPS, 'APP-FIREWALL', etc."; 'AUTHENTICATE-SESSION', 'IPS, 'APP-FIREWALL', etc.";
} }
leaf secondary-action { leaf secondary-action {
type string; type string;
description description
"This field identifies additional actions if "This field identifies additional actions if
a rule is matched. This could be one of 'LOG', a rule is matched. This could be one of 'LOG',
'SYSLOG', 'SESSION-LOG', etc."; 'SYSLOG', 'SESSION-LOG', etc.";
} }
} }
container ipsec {
description
"This container represents the IPsec-IKE/IKEless cases.";
leaf ipsec-method {
type leafref {
path "/policy/multi-tenancy/policy-mgnt-auth-method/ipsec/ipsec-method";
}
description
"This represents the IPsec-method, which
is defined by policy-mgny-auth-method.";
}
}
leaf owner { leaf owner {
type string; type string;
description description
"This field defines the owner of this "This field defines the owner of this
policy. Only the owner is authorized to policy. Only the owner is authorized to
modify the contents of the policy."; modify the contents of the policy.";
} }
} }
container multi-tenancy { container multi-tenancy {
skipping to change at page 33, line 23 skipping to change at page 33, line 50
path "/policy/multi-tenancy/policy-domain/name"; path "/policy/multi-tenancy/policy-domain/name";
} }
description description
"This field identifies the domain to which this "This field identifies the domain to which this
tenant belongs. This should be reference to a tenant belongs. This should be reference to a
'Policy-Domain' object."; 'Policy-Domain' object.";
} }
} }
leaf authentication-method { leaf authentication-method {
type leafref { type leafref {
path "/policy/multi-tenancy/policy-mgnt-auth-method/name"; path "/policy/multi-tenancy/policy-mgnt-auth-method/ipsec/ipsec-method";
} }
description description
"Authentication method to be used for this domain. "Authentication method to be used for this domain.
It should be a reference to a 'policy-mgmt-auth-method' It should be a reference to a 'policy-mgmt-auth-method'
object."; object.";
} }
description description
"This represents the list of policy domains."; "This represents the list of policy domains.";
} }
container policy-role { container policy-role {
skipping to change at page 34, line 41 skipping to change at page 35, line 20
} }
leaf role { leaf role {
type leafref { type leafref {
path "/policy/multi-tenancy/policy-role/access-profile/name"; path "/policy/multi-tenancy/policy-role/access-profile/name";
} }
description description
"This represents the reference to the "This represents the reference to the
access-profiles."; access-profiles.";
} }
} }
list policy-mgnt-auth-method { container policy-mgnt-auth-method {
uses meta; description
key "name"; "This represents the list of authentication methods.";
leaf auth-method {
type string;
description
"This represents the authentication method name.";
}
leaf mutual-authentication { leaf mutual-authentication {
type boolean; type boolean;
description description
"To identify whether the authentication "To identify whether the authentication
is mutual."; is mutual.";
} }
container password { list password-based {
key "password";
leaf password { leaf password {
type string; type string;
description description
"This should be defined using the "This should be defined using the
regular expression."; regular expression.";
} }
description description
"This represents the password method."; "This represents the password-based method.";
} }
container token { list token-based {
key "token";
leaf token { leaf token {
type string; type string;
description description
"This should be defined according to "This should be defined according to
the token scheme."; the token scheme.";
} }
description
"This represents the token method.";
leaf token-server { leaf token-server {
type inet:ipv4-address; type inet:ipv4-address;
description description
"The token-server information if the "This represents the token-server
authentication method is token-based"; information if the authentication method
} is token-based.";
} }
container certificate {
description description
"This represents the certificate method."; "This represents the token-based method.";
}
list certificate-based {
key "certificate";
leaf certificate { leaf certificate {
type certificate-type; type certificate-type;
description description
"This represents the certificate-type."; "This represents the certificate-type.";
} }
leaf certificate-server { leaf certificate-server {
type inet:ipv4-address; type inet:ipv4-address;
description description
"The certificate-server information if "The certificate-server information if
the authentication method is the authentication method is
certificate-based"; certificate-based";
} }
description
"This describes the certificate-based authentication list.";
} }
container single-sign-on { list ipsec {
key "ipsec-method";
leaf ipsec-method {
type identityref {
base ipsec-type;
}
description
"This represents the IPsec-IKE or IPsec-IKEless cases.";
}
description description
"This represents the authentication method "This represents the list of IPsec-method.";
for single-sing-on."; }
list single-sign-on {
key "credential";
leaf credential { leaf credential {
type certificate-type; type certificate-type;
description description
"This represents the authentication "This represents the authentication
using user credentials."; using user credentials.";
} }
leaf certificate-server { leaf certificate-server {
type inet:ipv4-address; type inet:ipv4-address;
description description
"The certificate-server information if "The certificate-server information if
the authentication method is the authentication method is
certificate-based"; certificate-based";
} }
description
"This represents the authentication method
for single-sing-on.";
} }
description
"This represents the policy managegement method.";
} }
} }
container endpoint-group { container endpoint-group {
description description
"A logical entity in their business "A logical entity in their business
environment, where a security policy environment, where a security policy
is to be applied."; is to be applied.";
list user-group { list user-group {
uses user-group; uses user-group;
key "name"; key "name";
skipping to change at page 37, line 40 skipping to change at page 38, line 39
uses payload-string; uses payload-string;
key "name"; key "name";
description description
"This represents the payload-string group."; "This represents the payload-string group.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 23: YANG for policy-general Figure 23: YANG for Consumer-Facing Interface
10. Example XML Output for Various Scenarios 10. Example XML Output for Various Scenarios
This section describes the XML instances for different policies This section describes the XML instances for different policies
examples that are delivered through Consumer-Facing Interface. The examples that are delivered through Consumer-Facing Interface. The
considered use cases are: VoIP/VoLTE security service, DDoS-attack considered use cases are: VoIP/VoLTE security service, DDoS-attack
mitigation, time-based firewall as a web-filter. mitigation, time-based firewall as a web-filter.
10.1. DB registration: Information of positions and devices (Endpoint 10.1. DB Registration: Information of Positions and Devices (Endpoint
group) Group)
In order to create a rule of a security policy, it is essential to In order to create a rule of a security policy, it is essential to
first register data (those which are used to form such rule) to the first register data (those which are used to form such rule) to the
database. For example, The endpoint group consists of three database. For example, The endpoint group consists of three
different groups: user-group, device-group, and payload-group. Each different groups: user-group, device-group, and payload-group. Each
of these groups have separate group members with information other of these groups have separate group members with information other
than meta ("name" or "date"), such as ip-addresses or protocols used than meta ("name" or "date"), such as ip-addresses or protocols used
by devices. Figure 24 shows an example XML representation of the by devices. Figure 24 shows an example XML representation of the
registered information for the user-group and device-group. registered information for the user-group and device-group.
skipping to change at page 38, line 37 skipping to change at page 39, line 37
<name>webservers</name> <name>webservers</name>
<range-ip-address> <range-ip-address>
<start-ip-address>221.159.112.91</start-ip-address> <start-ip-address>221.159.112.91</start-ip-address>
<end-ip-address>221.159.112.97</end-ip-address> <end-ip-address>221.159.112.97</end-ip-address>
</range-ip-address> </range-ip-address>
<protocol>http</protocol> <protocol>http</protocol>
<protocol>https</protocol> <protocol>https</protocol>
</device-group> </device-group>
</ietf-i2nsf-cfi-policy:endpoint-group> </ietf-i2nsf-cfi-policy:endpoint-group>
Figure 24: Registering user-group and device-group information Figure 24: Registering User-group and Device-group Information
10.2. Scenario 1: Block SNS access during business hours 10.2. Scenario 1: Block SNS Access during Business Hours
The first example scenario is to "block SNS access during business The first example scenario is to "block SNS access during business
hours" using a time-based firewall policy. In this scenario, all hours" using a time-based firewall policy. In this scenario, all
users registered as "employee" in the user-group list are unable to users registered as "employee" in the user-group list are unable to
access Social Networking Services (SNS) during the office hours. The access Social Networking Services (SNS) during the office hours. The
XML instance is described below: XML instance is described below:
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
<ietf-i2nsf-cfi-policy:policy> <ietf-i2nsf-cfi-policy:policy>
<policy-name>security_policy_for_blocking_sns</policy-name> <policy-name>security_policy_for_blocking_sns</policy-name>
skipping to change at page 39, line 31 skipping to change at page 40, line 31
</firewall-condition> </firewall-condition>
<custom-condition> <custom-condition>
<destination-target> <destination-target>
<dest-target>sns-websites</dest-target> <dest-target>sns-websites</dest-target>
</destination-target> </destination-target>
</custom-condition> </custom-condition>
</condition> </condition>
<action> <action>
<primary-action>drop</primary-action> <primary-action>drop</primary-action>
</action> </action>
<ipsec>
<ipsec-method>ikeless</ipsec-method>
</ipsec>
</rule> </rule>
</ietf-i2nsf-cfi-policy:policy> </ietf-i2nsf-cfi-policy:policy>
Figure 25: An XML Example for Time-based Firewall Figure 25: An XML Example for Time-based Firewall
Time-based-condition Firewall Time-based-condition Firewall
1. The policy name is "security_policy_for_blocking_sns". 1. The policy name is "security_policy_for_blocking_sns".
2. The rule name is "block_access_to_sns_during_office_hours". 2. The rule name is "block_access_to_sns_during_office_hours".
3. The Source-target is "employees". 3. The Source-target is "employees".
4. The destination target is "sns-websites". "sns-websites" is the 4. The destination target is "sns-websites". "sns-websites" is the
key which represents the list containing the information, such as key which represents the list containing the information, such as
URL, about sns-websites. URL, about sns-websites.
5. The action required is to "drop" any attempt to connect to 5. The action required is to "drop" any attempt to connect to
websites related to Social networking. websites related to Social networking.
10.3. Scenario 2: Block malicious VoIP/VoLTE packets coming to the 6. The IPsec-method is set to "ikeless".
company
10.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a
Company
The second example scenario is to "block malicious VoIP/VoLTE packets The second example scenario is to "block malicious VoIP/VoLTE packets
coming to the company" using a VoIP policy. In this scenario, the coming to a company" using a VoIP policy. In this scenario, the
calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that
are classified as malicious are dropped. The IP addresses of the are classified as malicious are dropped. The IP addresses of the
employees and malicious VOIP IDs should be blocked are stored in the employees and malicious VOIP IDs should be blocked are stored in the
database or datastore of the enterprise. Here and the rest of the database or datastore of the enterprise. Here and the rest of the
cases assume that the security administrators or someone responsible cases assume that the security administrators or someone responsible
for the existing and newly generated policies, are not aware of which for the existing and newly generated policies, are not aware of which
and/or how many NSFs are needed to meet the security requirements. and/or how many NSFs are needed to meet the security requirements.
Figure 26 represents the XML document generated from YANG discussed Figure 26 represents the XML document generated from YANG discussed
in previous sections. Once a high-level seucurity policy is created in previous sections. Once a high-level seucurity policy is created
by a security admin, it is delivered by the Consumer-Facing by a security admin, it is delivered by the Consumer-Facing
skipping to change at page 40, line 43 skipping to change at page 41, line 45
</custom-condition> </custom-condition>
<firewall-condition> <firewall-condition>
<destination-target> <destination-target>
<dest-target>employees</dest-target> <dest-target>employees</dest-target>
</destination-target> </destination-target>
</firewall-condition> </firewall-condition>
</condition> </condition>
<action> <action>
<primary-action>drop</primary-action> <primary-action>drop</primary-action>
</action> </action>
<ipsec>
<ipsec-method>ikeless</ipsec-method>
</ipsec>
</rule> </rule>
</ietf-i2nsf-cfi-policy:policy> </ietf-i2nsf-cfi-policy:policy>
Figure 26: An XML Example for VoIP Security Service Figure 26: An XML Example for VoIP Security Service
Custom-condition Firewall Custom-condition Firewall
1. The policy name is 1. The policy name is
"security_policy_for_blocking_malicious_voip_packets". "security_policy_for_blocking_malicious_voip_packets".
skipping to change at page 41, line 20 skipping to change at page 42, line 25
admin can read every stored malicious VOIP IDs that are named as admin can read every stored malicious VOIP IDs that are named as
"malicious-id". "malicious-id".
4. The destination target is "employees". "employees" is the key 4. The destination target is "employees". "employees" is the key
which represents the list containing information about employees, which represents the list containing information about employees,
such as IP addresses. such as IP addresses.
5. The action required is "drop" when any incoming packets are from 5. The action required is "drop" when any incoming packets are from
"malicious-id". "malicious-id".
10.4. Scenario 3: Mitigate HTTP and HTTPS flood attacks on a company 6. The IPsec-method is set to "ikeless".
web Server
10.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company
Web Server
The third example scenario is to "Mitigate HTTP and HTTPS flood The third example scenario is to "Mitigate HTTP and HTTPS flood
attacks on a company web Server" using a DDoS-attack mitigation attacks on a company web server" using a DDoS-attack mitigation
policy. Here, the time information is not set because the service policy. Here, the time information is not set because the service
provided by the network should be maintained at all times. If the 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 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 admin can set the percentage of the packets to be dropped to safely
maintain the service. In this scenario, the source is set as "any" maintain the service. In this scenario, the source is set as "any"
to block any sources which send abnormal amount of packets. The to block any sources which send abnormal amount of packets. The
destination is set as "web_server01". Once the rule is set and destination is set as "web_server01". Once the rule is set and
delivered and enforced to the nsfs by the securiy controller, the delivered and enforced to the nsfs by the securiy controller, the
NSFs will monitor the incoming packet amounts and the destination to NSFs will monitor the incoming packet amounts and the destination to
act according to the rule set. The XML instance is described below: act according to the rule set. The XML instance is described below:
skipping to change at page 42, line 23 skipping to change at page 43, line 23
<dest-target>webservers</dest-target> <dest-target>webservers</dest-target>
</destination-target> </destination-target>
<rate-limit> <rate-limit>
<packet-per-second>100</packet-per-second> <packet-per-second>100</packet-per-second>
</rate-limit> </rate-limit>
</ddos-condition> </ddos-condition>
</condition> </condition>
<action> <action>
<primary-action>drop</primary-action> <primary-action>drop</primary-action>
</action> </action>
<ipsec>
<ipsec-method>ikeless</ipsec-method>
</ipsec>
</rule> </rule>
</ietf-i2nsf-cfi-policy:policy> </ietf-i2nsf-cfi-policy:policy>
Figure 27: An XML Example for DDoS-attack Mitigation Figure 27: An XML Example for DDoS-attack Mitigation
DDoS-condition Firewall DDoS-condition Firewall
1. The policy name is "security_policy_for_ddos_attacks". 1. The policy name is "security_policy_for_ddos_attacks".
2. The rule name is "100_packets_per_second". 2. The rule name is "100_packets_per_second".
skipping to change at page 43, line 5 skipping to change at page 43, line 52
second. In this case the rate limit is "100" packets per second. second. In this case the rate limit is "100" packets per second.
This amount depends on the packet receiving capacity of the This amount depends on the packet receiving capacity of the
server devices. server devices.
5. The Source-target is all sources which send abnormal amount of 5. The Source-target is all sources which send abnormal amount of
packets. packets.
6. The action required is to "drop" packet reception is more than 6. The action required is to "drop" packet reception is more than
100 packets per second. 100 packets per second.
7. The IPsec-method is set to "ikeless".
11. Security Considerations 11. Security Considerations
The data model for the I2NSF Consumer-Facing Interface is derived The data model for the I2NSF Consumer-Facing Interface is based on
from the I2NSF Consumer-Facing Interface Information Model the I2NSF framework [RFC8329], so the same security considerations
[client-facing-inf-im], so the same security considerations with the with the I2NSF framework should be included in this document. The
information model should be included in this document. The data data model needs a secure communication channel to protect the
model needs to support a mechanism to protect Consumer-Facing Consumer-Facing Interface between the I2NSF User and Security
Interface to Security Controller. Controller.
12. IANA Considerations 12. 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-cfi-policy URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
Registrant Contact: The I2NSF. Registrant Contact: The I2NSF.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
skipping to change at page 43, line 35 skipping to change at page 44, line 35
name: ietf-i2nsf-cfi-policy name: ietf-i2nsf-cfi-policy
namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
prefix: cfi-policy prefix: cfi-policy
reference: RFC 7950 reference: RFC 7950
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC3444] Pras, A., "On the Difference between Information Models [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
and Data Models", RFC 3444, January 2003. Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
13.2. Informative References <https://www.rfc-editor.org/info/rfc3444>.
[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.
[draft-ietf-i2nsf-capability]
Xia, L., Strassner, J., Huawei, Basile, C., PoliTo, Lopez,
D., and TID, "Information Model of NSFs Capabilities",
draft-ietf-i2nsf-capability-04 (work in progress), October
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-07
(work in progress), January 2019.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
January 2011, <https://www.rfc-editor.org/info/rfc6087>. January 2011, <https://www.rfc-editor.org/info/rfc6087>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
skipping to change at page 46, line 5 skipping to change at page 45, line 36
[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, DOI 10.17487/RFC8329, February 2018, Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
<https://www.rfc-editor.org/info/rfc8329>. <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>.
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- 13.2. Informative References
dm-02
The following changes have been made from draft-ietf-i2nsf-consumer-
facing-interface-dm-02:
o In this version of the WG draft, we merged the
[client-facing-inf-im] and draft-ietf-i2nsf-consumer-facing-
interface-dm-02 drafts. In sections 4 to 9, we describe the
information model for the security policies delivered through the
Consumer-Facing Interface. In sections 10 to 12, we provide and
discuss the YANG data model and example XML outputs of security
policies for various use cases.
o In Section 10, the following changes have been made: For "time- [client-facing-inf-req]
information" container in event sub-module list, the enforcement Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
type is defined into three different types (admin-enforced, time- S., and L. Xia, "Requirements for Client-Facing Interface
enforced, and event-enforced). Also, begin-time and end-time type to Security Controller", draft-ietf-i2nsf-client-facing-
has been defined seperately. The security policies can now be set interface-req-05 (work in progress), May 2018.
recursively (daily, weekly, and monthly).
o "policy-role" now has the access-profile container, and previlege [i2nsf-capability-im]
can be set separately per profile. Xia, L., Strassner, J., Basile, C., and D. Lopez,
"Information Model of NSFs Capabilities", draft-ietf-
i2nsf-capability-04 (work in progress), October 2018.
o "policy-user" information, such as email and password is newly [i2nsf-ipsec]
defined by regular expressions. Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-
Garcia, "Software-Defined Networking (SDN)-based IPsec
Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow-
protection-04 (work in progress), March 2019.
o "authentication-method" in "policy-mgnt-auth-method" has been [i2nsf-terminology]
modified. More specifically, the authentication-method type has Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
been changed from string to choice so that one can choose between Birkholz, "Interface to Network Security Functions (I2NSF)
password, token, and certificate. If not selected, password is Terminology", draft-ietf-i2nsf-terminology-07 (work in
used as a default. progress), January 2019.
o "Certificate-type" has been re-defined to include common Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface-
certificate extensions, such as ".CRT", "CER", and "KEY". dm-03
o Used groupings to represent the groups in the Endpoint groups. The following changes have been made from draft-ietf-i2nsf-consumer-
facing-interface-dm-03:
o Added examples for registering information (i.e., endpoint-groups, o This version added an I2NSF IPsec field for configuration and
threat-prevention, and multi-tenancy.) state data for IPsec management (i.e., IPsec method such as IKE
and IKEless [i2nsf-ipsec]) in the I2NSF framework.
Appendix B. Acknowledgments Appendix B. 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(MSIP) Technology Promotion(IITP) grant funded by the Korea government(MSIP)
(No.R-20160222-002755, Cloud based Security Intelligence Technology (No.R-20160222-002755, Cloud based Security Intelligence Technology
Development for the Customized Security Service Provisioning). Development for the Customized Security Service Provisioning).
Appendix C. Contributors Appendix C. Contributors
 End of changes. 119 change blocks. 
260 lines changed or deleted 305 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/