draft-ietf-i2nsf-consumer-facing-interface-dm-06.txt   draft-ietf-i2nsf-consumer-facing-interface-dm-07.txt 
I2NSF Working Group J. Jeong I2NSF Working Group J. Jeong
Internet-Draft E. Kim Internet-Draft C. Chung
Intended status: Standards Track Sungkyunkwan University Intended status: Standards Track Sungkyunkwan University
Expires: January 25, 2020 T. Ahn Expires: May 7, 2020 T. Ahn
Korea Telecom Korea Telecom
R. Kumar R. Kumar
Juniper Networks Juniper Networks
S. Hares S. Hares
Huawei Huawei
July 24, 2019 November 4, 2019
I2NSF Consumer-Facing Interface YANG Data Model I2NSF Consumer-Facing Interface YANG Data Model
draft-ietf-i2nsf-consumer-facing-interface-dm-06 draft-ietf-i2nsf-consumer-facing-interface-dm-07
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 types of managed objects and the information model defines various types of managed objects and the
relationship among them needed to build the interface. The relationship among them needed to build the interface. The
information model is organized based on the "Event-Condition-Action" information model is organized based on the "Event-Condition-Action"
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 25, 2020. This Internet-Draft will expire on May 7, 2020.
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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . . 7 4.1. Event Sub-model . . . . . . . . . . . . . . . . . . . . . 7
4.2. Condition Sub-model . . . . . . . . . . . . . . . . . . . 8 4.2. Condition Sub-model . . . . . . . . . . . . . . . . . . . 8
4.3. Action Sub-model . . . . . . . . . . . . . . . . . . . . 9 4.3. Action Sub-model . . . . . . . . . . . . . . . . . . . . 9
5. Information Model for Multi-Tenancy . . . . . . . . . . . . . 10 5. Information Model for Policy Endpoint Groups . . . . . . . . 10
5.1. Policy Domain . . . . . . . . . . . . . . . . . . . . . . 10 5.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Policy Tenant . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Policy Role . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Location Group . . . . . . . . . . . . . . . . . . . . . 12
5.4. Policy User . . . . . . . . . . . . . . . . . . . . . . . 12 6. Information Model for Threat Prevention . . . . . . . . . . . 13
5.5. Policy Management Authentication Method . . . . . . . . . 13 6.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 13
6. Information Model for Policy Endpoint Groups . . . . . . . . 14 6.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 14
6.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 15 7. Network Configuration Access Control Model (NACM) . . . . . . 15
6.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 16 8. YANG Data Model of Consumer-Facing Interface . . . . . . . . 15
6.3. Location Group . . . . . . . . . . . . . . . . . . . . . 16 9. XML Configuration Examples of High-Level Security Policy
7. Information Model for Threat Prevention . . . . . . . . . . . 17 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Database Registration: Information of Positions and
7.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 18 Devices (Endpoint Group) . . . . . . . . . . . . . 36
8. Role-based Acess Control (RBAC) . . . . . . . . . . . . . . . 19 9.2. Scenario 1: Block SNS Access during Business Hours . . . 37
9. YANG Data Model for Security Policies for Consumer-Facing 9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20 a Company . . . . . . . . . . . . . . . . . . . . . . . . 39
10. Example XML Output for Various Scenarios . . . . . . . . . . 49 9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a
10.1. DB Registration: Information of Positions and Devices Company Web Server . . . . . . . . . . . . . . . . . . . 40
(Endpoint Group) . . . . . . . . . . . . . . . . . . . . 49 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42
10.2. Scenario 1: Block SNS Access during Business Hours . . . 50 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
10.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
a Company . . . . . . . . . . . . . . . . . . . . . . . 52 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42
10.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
Company Web Server . . . . . . . . . . . . . . . . . . . 53 14.1. Normative References . . . . . . . . . . . . . . . . . . 44
14.2. Informative References . . . . . . . . . . . . . . . . . 45
11. Security Considerations . . . . . . . . . . . . . . . . . . . 55
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
13.1. Normative References . . . . . . . . . . . . . . . . . . 55
13.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing- Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-
interface-dm-05 . . . . . . . . . . . . . . . . . . 58 interface-dm-06 . . . . . . . . . . . . . . . . . . 47
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
1. Introduction 1. Introduction
In a framework of Interface to Network Security Functions (I2NSF), In a framework of Interface to Network Security Functions (I2NSF),
each vendor can register their NSFs using a Developer's Management each vendor can register their NSFs using a Developer's Management
System (DMS). Assuming that vendors also provide the front-end web System (DMS). Assuming that vendors also provide the front-end web
applications registered with an I2NSF User, the Consumer-Facing applications registered with an I2NSF User, the Consumer-Facing
Interface is required because the web applications developed by each Interface is required because the web applications developed by each
vendor need to have a standard interface specifying the data types vendor need to have a standard interface specifying the data types
used when the I2NSF User and Security Controller communicate using used when the I2NSF User and Security Controller communicate using
skipping to change at page 4, line 15 skipping to change at page 4, line 12
a specific data representation language, is also defined in this a specific data representation language, is also defined in this
document. 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 | | Policy | | Endpoint | | Threat |
| Tenancy | | | | groups | | feed | | | | groups | | feed |
+---------+ +-----+----+ +----------+ +---------+ +-----+----+ +----------+ +---------+
^ ^
| |
+------+------+ +------+------+
| Rule | | Rule |
+------+------+ +------+------+
^ ^
| |
+----------------+----------------+ +----------------+----------------+
| | | | | |
+------+------+ +------+------+ +------+------+ +------+------+ +------+------+ +------+------+
skipping to change at page 5, line 17 skipping to change at page 5, line 14
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]
[i2nsf-terminology][client-facing-inf-req]. [client-facing-inf-req].
This document follows the guidelines of [RFC8407], uses the common This document follows the guidelines of [RFC8407], 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 Administrator (i.e., I2NSF User) using Consumer-Facing by Security Administrator (i.e., I2NSF User) using Consumer-Facing
Interface toward Security Controller; the policy would be enforced on Interface toward Security Controller; the policy would be enforced on
an NSF. Figure 2 shows the YANG tree of the Policy object. The an NSF. Figure 2 shows the YANG tree of the Policy object. The
Policy object SHALL have the following information: Policy object SHALL 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.
Rules: This field contains a list of rules. These rules are Rule: This field contains a list of rules. These rules are
defined for 1) communication between two Endpoint Groups, defined for 1) communication between two Endpoint Groups,
2) for preventing communication with externally or 2) for preventing communication with externally or
internally identified threats, and 3) for implementing internally identified threats, and 3) for implementing
business requirement such as controlling access to internal business requirement such as controlling access to internal
or external resources for meeting regulatory compliance or or external resources for meeting regulatory compliance or
business objectives. An organization may restrict certain business objectives. An organization may restrict certain
communication between a set of user and applications for communication between a set of user and applications for
example. The threats may be from threat feeds obtained example. The threats may be from threat feeds obtained
from external sources or dynamically identified by using from external sources or dynamically identified by using
specialty devices in the network. Rule conflict analysis specialty devices in the network. Rule conflict analysis
should be triggered by the monitoring service to perform an should be triggered by the monitoring service to perform an
exhaustive detection of anomalies among the configuration exhaustive detection of anomalies among the configuration
rules installed into the security functions. rules installed into the security functions.
+--rw i2nsf-cfi-policy* [policy-name] +--rw i2nsf-cfi-policy* [policy-name]
+--rw policy-name string +--rw policy-name string
+--rw rule* [rule-name] | +--rw rule* [rule-name]
+--rw multi-tenancy
+--rw endpoint-group +--rw endpoint-group
+--rw threat-prevention +--rw threat-prevention
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 Rule. 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 YANG tree of the Rule in the subsequent sections. Figure 3 shows the YANG data tree of the
object. The rule object SHALL have the following information: Rule object. The rule object SHALL have the following information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
Event: This field includes the information to determine whether Event: This field includes the information to determine whether
the Rule Condition can be evaluated or not. See details in the Rule Condition can be evaluated or not. See details in
Section 3.1. Section 4.1.
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.
skipping to change at page 7, line 13 skipping to change at page 7, line 13
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 event +--rw event
+--rw (condition)? +--rw (condition)?
+--rw action +--rw action
+--rw ipsec-method +--rw ipsec-method
+--rw owner identityref +--rw owner identityref
Figure 3: YANG Data Tree for Rule Figure 3: Rule YANG Data Tree
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 set time or security event. The Rule could be activated based on a set time or security event.
Figure 4 shows the YANG tree of the Event object. Event object SHALL Figure 4 shows the YANG tree of the Event object. Event object SHALL
have following information: have following information:
Security-event: This field identifies for which security event Security-event: This field identifies for which security event
the policy is enforced. The examples of security events the policy is enforced. The examples of security events
skipping to change at page 7, line 39 skipping to change at page 7, line 39
Admin: This represents the enforcement type based on admin's Admin: This represents the enforcement type based on admin's
decision. decision.
Time: This represents the security rule is enforced based on Time: This represents the security rule is enforced based on
begin-time and end-time information. begin-time and end-time information.
Frequency: This represents how frequent the rule should be Frequency: This represents how frequent the rule should be
enforced. There are four options: "only-once", "daily", enforced. There are four options: "only-once", "daily",
"weekly" and "monthly". "weekly" and "monthly".
+--rw event +--rw event
+--rw security-event identityref +--rw security-event identityref
+--rw (enforce-type)? +--rw (enforce-type)?
| +--:(admin) | +--:(admin)
| | +--rw admin? identityref | | +--rw admin? identityref
| +--:(time) | +--:(time)
| +--rw time-information | +--rw time-information
| +--rw begin-time? yang:date-and-time | +--rw begin-time? yang:date-and-time
| +--rw end-time? yang:date-and-time | +--rw end-time? yang:date-and-time
+--rw frequency? enumeration +--rw frequency? 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 Administrator wants This object represents Conditions that Security Administrator wants
to apply the checking on the traffic in order to determine whether to apply the checking on the traffic in order to determine whether
the set of actions in the Rule can be executed or not. The Condition the set of actions in the Rule can be executed or not. The Condition
Sub-model consists of three different types of containers each Sub-model consists of three different types of containers each
representing different cases, such as general firewall and DDoS- representing different cases, such as general firewall and DDoS-
skipping to change at page 8, line 25 skipping to change at page 8, line 25
case. Figure 5 shows the YANG tree of the Condition object. The case. Figure 5 shows the YANG tree of the Condition object. The
Condition Sub-model SHALL have following information: Condition Sub-model SHALL have following information:
Case (Firewall-condition): This field represents the general Case (Firewall-condition): This field represents the general
firewall case, where a security admin can set up firewall firewall case, where a security admin can set up firewall
conditions using the information present in this field. conditions using the information present in this field.
The source and destination is represented as firewall- The source and destination is represented as firewall-
source and firewall-destination, each referring to the IP- source and firewall-destination, each referring to the IP-
address-based groups defined in the endpoint-group. address-based groups defined in the endpoint-group.
DDoS-condition: This field represents the condition for DDoS Case (DDoS-condition): This field represents the condition for
mitigation, where a security admin can set up DDoS DDoS mitigation, where a security admin can set up DDoS
mitigation conditions using the information present in this mitigation conditions using the information present in this
field. The source and destination is represented as ddos- field. The source and destination is represented as ddos-
source and ddos-destination, each referring to the device- source and ddos-destination, each referring to the device-
groups defined and registered in the endpoint-group. groups defined and registered in the endpoint-group.
Custom-condition: This field contains the payload string Case (Custom-condition): This field contains the payload string
information. This information is useful when security rule information. This information is useful when security rule
condition is based on the string contents of incoming or condition is based on the string contents of incoming or
outgoing packets. The source and destination is outgoing packets. The source and destination is
represented as custon-source and custom-destination, each represented as custom-source and custom-destination, each
referring to the payload-groups defined and registered in referring to the payload-groups defined and registered in
the endpoint-group. the endpoint-group.
Threat-feed-condition: This field contains the information Case (Threat-feed-condition): This field contains the information
obtained from threat-feeds (e.g., Palo-Alto, or RSA- obtained from threat-feeds (e.g., Palo-Alto, or RSA-
netwitness). This information is useful when security rule netwitness). This information is useful when security rule
condition is based on the existing threat reports gathered condition is based on the existing threat reports gathered
by other sources. The source and destination is by other sources. The source and destination is
represented as threat-feed-source and threat-feed- represented as threat-feed-source and threat-feed-
destination. For clarity, threat-feed-source/destination destination. For clarity, threat-feed-source/destination
represent the source/destination of a target security represent the source/destination of a target security
threat, not the information source/destination of a threat- threat, not the information source/destination of a threat-
feed. feed.
+--rw (condition)? +--rw (condition)?
+--:(firewall-condition) +--:(firewall-condition)
| +--rw firewall-source | +--rw firewall-source
| | +--rw src-target -> /../../user-group/name | | +--rw src-target -> /../../nacm:group/nacm:user-name
| +--rw firewall-destination | +--rw firewall-destination
| +--rw dest-target* -> /../../user-group/name | +--rw dest-target* -> /../../nacm:group/nacm:user-name
+--:(ddos-condition) +--:(ddos-condition)
| +--rw ddos-source | +--rw ddos-source
| | +--rw src-target* -> /../../device-group/name | | +--rw src-target* -> /../../device-group/name
| +--rw ddos-destination | +--rw ddos-destination
| | +--rw dest-target* -> /../../device-group/name | | +--rw dest-target* -> /../../device-group/name
| +--rw rate-limit | +--rw rate-limit
| +--rw packet-per-second? uint16 | +--rw packet-per-second? uint16
+--:(custom-condition) +--:(custom-condition)
| +--rw custon-source | +--rw custon-source
| | +--rw src-target* -> /../../payload-content/name | | +--rw src-target* -> /../../payload-content/name
| +--rw custom-destination | +--rw custom-destination
| +--rw dest-target -> /../../payload-content/name | +--rw dest-target -> /../../payload-content/name
+--:(threat-feed-condition) +--:(threat-feed-condition)
+--rw threat-feed-source +--rw threat-feed-source
| +--rw src-target* -> /../../threat-feed-list/feed-name | +--rw src-target* -> /../../threat-feed-list/feed-name
+--rw threat-feed-destination +--rw threat-feed-destination
+--rw dest-target -> /../../threat-feed-list/feed-name +--rw dest-target -> /../../threat-feed-list/feed-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 YANG tree of the based on certain traffic class. Figure 6 shows the YANG tree of the
Action object. The Action object SHALL have following information: Action object. The Action object SHALL have following information:
Primary-action: This field identifies the action when a rule is Primary-action: This field identifies the action when a rule is
matched by an NSF. The action could be one of "PASS", matched by an NSF. The action could be one of "PASS",
"DROP", "ALERT", "RATE-LIMIT", and "MIRROR". "DROP", "ALERT", "RATE-LIMIT", and "MIRROR".
Secondary-action: This field identifies the action when a rule is Secondary-action: This field identifies the action when a rule is
matched by an NSF. The action could be one of "log", matched by an NSF. The action could be one of "log",
"syslog", "session-log". "syslog", "session-log".
+--rw action +--rw action
+--rw primary-action identityref +--rw primary-action identityref
+--rw secondary-action? identityref +--rw secondary-action? identityref
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 Policy Endpoint Groups
Multi-tenancy is an important aspect of any application that enables
multiple administrative domains in order to manage application
resources. An Enterprise organization may have multiple tenants or
departments such as Human Resources (HR), Finance, and Legal, with
each tenant having a need to manage their own Security Policies. In
a Service Provider, a tenant could represent a Customer that wants to
manage its own Security Policies. There are multiple managed objects
that constitute multi-tenancy aspects as shown in Figure 7. This
section lists these objects and the relationship among these objects.
Below diagram shows an example of multi-tenancy in an Enterprise
domain.
+-------------------+
(Multi-Tenancy) | Domain |
|(e.g., Enterprise) |
+---------+---------+
^
|
+--------------------+--------------------+
| | |
+--------+-------+ +---------+--------+ +--------+--------+
| Department 1 | | Department 2 | | Department n |
+--------+-------+ +---------+--------+ +--------+--------+
^ ^ ^
| | |
+--------+--------+ +-----------------+ +--------+--------+
| Sub-domain 1..n | | Sub-domain 1..n | | Sub-domain 1..n |
+--------+--------+ +--------+--------+ +--------+--------+
^ ^ ^
| | |
+--------+--------+ +--------+--------+ +--------+--------+
| Tenant 1..n | | Tenant 1..n | | Tenant 1..n |
+-----------------+ +-----------------+ +-----------------+
Figure 7: Multi-tenancy Diagram
5.1. Policy Domain
This object defines a boundary for the purpose of policy management
within a Security Controller. This may vary based on how the
Security Controller is deployed and hosted. For example, if an
Enterprise hosts a Security Controller in their network; the domain
in this case could just be the one that represents that Enterprise.
But if a Cloud Service Provider hosts managed services, then a domain
could represent a single customer of that Provider. Figure 8 shows
the YANG tree of the Policy-Domain object. Multi-tenancy model
should be able to work in all such environments. The Policy-Domain
object SHALL have the following information:
Domain-name: Name of the domain of an organization or enterprise.
Address: Address information of the organization or enterprise.
Contact: Contact information of the organization or enterprise.
+--rw policy-domain* [domain-name]
+--rw domain-name identityref
+--rw address? string
+--rw contact? string
Figure 8: Policy Domain YANG Data Tree
5.2. Policy Tenant
This object defines an entity within an organization. The entity
could be a department or business unit within an Enterprise
organization that would like to manage its own Policies due to
regulatory compliance or business reasons. Figure 9 shows the YANG
tree of the Policy-Tenant object. The Policy-Tenant object SHALL
have the following information:
Tenant-type: This field represents the type of tenant within a
domain. In an enterprise, the examples of tenants could be
the departments or divisions, such as HR department and
Finance department.
+--rw policy-tenant* [tenant-name]
+--rw tenant-type identityref
Figure 9: Policy Tenant YANG Data Tree
5.3. Policy Role
This object defines a set of permissions assigned to a user in an
organization that wants to manage its own Security Policies. It
provides a convenient way to assign policy users to a job function or
a set of permissions within the organization. Figure 10 shows the
YANG tree of the Policy-Role object. The Policy-Role object SHALL
have the following information:
Role-type: "This represent the roles within the tenants, in order
to distinguish who may or may not have access to policies.
The role types include "user", "group", "other", and "all".
"user" "represents an individual where as group represents
a group of users. "All" means both the individual and the
group members, whereas "other" denotes anyone who is not a
specific individual or a member of a specific group.
+--rw policy-role* [role-name]
+--rw role-type identityref
Figure 10: Policy Role YANG Data Tree
5.4. Policy User
This object represents a unique identity of a user within an
organization. The identity authenticates with Security Controller
using credentials such as a password or token in order to perform
policy management. A user may be an individual, system, or
application requiring access to Security Controller. Figure 11 shows
the YANG tree of the Policy-User object. The Policy-User object
SHALL have the following information:
Name: Name of a user.
Password: User password for basic authentication. The crypto-
hash mechanism for this entry is ianach:crypt-hash.
Email: E-mail address of the user.
Access-profile: This represents the access profile for the user.
The access-profile is based on the permission-type and the
scope type defined. The permission-types include "no-
permission", read", "write", "execute", "read-and-write",
"read-and-execute", and "write-and-execute"
Scope-Type: This field identifies whether the user has domain-
wide or tenant-wide privileges.
+--rw policy-user* [name]
+--rw name string
+--rw password? ianach:crypt-hash
+--rw email? string
+--rw access-profile* [permission-type scope-type]
+--rw permission-type identityref
+--rw scope-type identityref
Figure 11: Policy User YANG Data Tree
5.5. Policy Management Authentication Method
This object represents authentication schemes supported by Security
Controller. Figure 12 shows the YANG tree of the Policy Management
Authentication Method onject. This Policy-Management-Authentication-
Method object SHALL have the following information:
Policy-mgmt-auth-method-instance: This field represent the
authentication instances. Each instance is based on either
client authentication, server authentication or both
(mutual) authentication.
Policy-mgmt-auth-method: This represents the choices of
authentication methods. Each instance of authentication
consists of authentication methods chosen by an entity,
such as a security admin. There are "Password-based",
"token-based". "certificate-based", and "IPsec"
authentication methods.
Password-list: This list contains the passwords that are
encrypted using crypto-has algorithm (ianach:crypt-hash).
Token-list: This list contains the information such as the access
tokens and a token server.
Cert-server-list: This list contains the certification server
information such as server address (IPv4 and IPv6) and
certificate types.
IPsec: This list has IPsec method types based on the identities
defined. There are two types such as IPsec-IKE and IPsec-
IKEless.
+--rw policy-mgmt-auth-method-instance* [auth-instance-type]
+--rw auth-instance-type identityref
+--rw (policy-mgmt-auth-method)?
+--:(password-based)
| +--rw password-list* [password]
| +--rw password ianach:crypt-hash
+--:(token-based)
| +--rw token-list* [token]
| +--rw token string
| +--rw token-server? inet:ipv4-address
+--:(certificate-based)
| +--rw cert-server-list* [cert-server-name]
| +--rw cert-server-name string
| +--rw cert-server-ipv4? inet:ipv4-address
| +--rw cert-server-ipv6? inet:ipv6-address
| +--rw certificate* [cert-type]
| +--rw cert-type identityref
+--:(ipsec)
+--rw ipsec-method* [method]
+--rw method identityref
Figure 12: Policy Management Authentication Method YANG Data Tree
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. A Security Administrator would create and Construct based policies. A Security Administrator would create and
use these objects to represent a logical entity in their business use these objects to represent a logical entity in their business
environment, where a Security Policy is to be applied. There are environment, where a Security Policy is to be applied. There are
multiple managed objects that constitute a Policy's Endpoint Group as multiple managed objects that constitute a Policy's Endpoint Group as
shown in Figure 13. Figure 14 shows the YANG tree of the Endpoint- shown in Figure 7. Figure 8 shows the YANG tree of the Endpoint-
Group object. This section lists these objects and relationship Group object. This section lists these objects and relationship
among them. 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|
+----------+ +------------+ +--------------+ +----------+ +------------+ +--------------+
Figure 13: Endpoint Group Diagram Figure 7: 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 8: Endpoint Group YANG Data Tree
6.1. User Group 5.1. User Group
This object represents a User-Group. Figure 15 shows the YANG tree This object represents a User-Group. Figure 9 shows the YANG tree of
of the User-Group object. The User-Group object SHALL have the the User-Group object. The User-Group 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.
IP-address: This represents the IPv4 address of a user in the IP-address: This represents the IPv4 address of a user in the
user group. user group.
range-ipv4-address: This represents the IPv4 address of a user in range-ipv4-address: This represents the IPv4 address of a user in
the user gorup. the user gorup.
range-ipv6-address: This represents the IPv6 address of a user in range-ipv6-address: This represents the IPv6 address of a user in
the user gorup. the user gorup.
+--rw user-group* [name] +--rw user-group* [name]
+--rw name string +--rw name -> /../../nacm:group/nacm:user-name
+--rw (match-type)? +--rw (match-type)?
+--:(exact-match-ipv4) +--:(exact-match-ipv4)
| +--rw ip-address* inet:ipv4-address | +--rw ip-address* inet:ipv4-address
+--:(exact-match-ipv6) +--:(exact-match-ipv6)
| +--rw ip-address* inet:ipv4-address | +--rw ip-address* inet:ipv4-address
+--:(range-match-ipv4) +--:(range-match-ipv4)
| +--rw range-ipv4-address* [start-ipv4-address end-ipv4-address] | +--rw range-ipv4-address*
| +--rw start-ipv4-address inet:ipv4-address [start-ipv4-address end-ipv4-address]
| +--rw end-ipv4-address inet:ipv4-address | +--rw start-ipv4-address inet:ipv4-address
+--:(range-match-ipv6) | +--rw end-ipv4-address inet:ipv4-address
+--rw range-ipv6-address* [start-ipv6-vaddress end-ipv6-address] +--:(range-match-ipv6)
+--rw start-ipv6-address inet:ipv6-address +--rw range-ipv6-address*
+--rw end-ipv6-address inet:ipv6-address [start-ipv6-vaddress end-ipv6-address]
+--rw start-ipv6-address inet:ipv6-address
+--rw end-ipv6-address inet:ipv6-address
Figure 15: User Group YANG Data Tree Figure 9: User Group YANG Data Tree
6.2. Device Group 5.2. Device Group
This object represents a Device-Group. Figure 16 shows the YANG tree This object represents a Device-Group. Figure 10 shows the YANG tree
of the Device-group object.The Device-Group object SHALL have the of the Device-group object. The Device-Group 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.
IP-address: This represents the IPv4 address of a device in the IP-address: This represents the IPv4 address of a device in the
device group. device group.
range-ipv4-address: This represents the IPv4 address of a device range-ipv4-address: This represents the IPv4 address of a device
in the device gorup. in the device gorup.
range-ipv6-address: This represents the IPv6 address of a device range-ipv6-address: This represents the IPv6 address of a device
in the device gorup. in the device gorup.
Protorol: This represents the communication protocols used by the Protocol: This represents the communication protocols used by the
devices. The protocols are "SSH", "FTP", "SMTP", "HTTP", devices. The protocols are "SSH", "FTP", "SMTP", "HTTP",
"HTTPS", and etc. "HTTPS", and etc.
+--rw device-group* [name] +--rw device-group* [name]
+--rw name string +--rw name string
+--rw (match-type)? +--rw (match-type)?
+--:(exact-match-ipv4) | +--:(exact-match-ipv4)
| +--rw ip-address* inet:ipv4-address | | +--rw ip-address* inet:ipv4-address
+--:(exact-match-ipv6) | +--:(exact-match-ipv6)
| +--rw ip-address* inet:ipv4-address | | +--rw ip-address* inet:ipv4-address
+--:(range-match-ipv4) | +--:(range-match-ipv4)
| +--rw range-ipv4-address* [start-ipv4-address end-ipv4-address] | | +--rw range-ipv4-address*
| +--rw start-ipv4-address inet:ipv4-address [start-ipv4-address end-ipv4-address]
| +--rw end-ipv4-address inet:ipv4-address | | +--rw start-ipv4-address inet:ipv4-address
+--:(range-match-ipv6) | | +--rw end-ipv4-address inet:ipv4-address
+--rw range-ipv6-address* [start-ipv6-vaddress end-ipv6-address] | +--:(range-match-ipv6)
+--rw start-ipv6-address inet:ipv6-address | +--rw range-ipv6-address*
+--rw end-ipv6-address inet:ipv6-address [start-ipv6-vaddress end-ipv6-address]
| +--rw start-ipv6-address inet:ipv6-address
| +--rw end-ipv6-address inet:ipv6-address
+--rw protocol identityref
Figure 16: Device Group YANG Data Tree Figure 10: Device Group YANG Data Tree
6.3. Location Group 5.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 YANG tree of the Location-Group information. Figure 11 shows the YANG tree 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.
geo-ip-ipv4: This field represents the IPv4 Geo-ip of a location. geo-ip-ipv4: This field represents the IPv4 Geo-ip of a location.
geo-ip-ipv6: This field represents the IPv6 Geo-ip of a location. geo-ip-ipv6: This field represents the IPv6 Geo-ip of a location.
continent: This field represents the continent where the location continent: This field represents the continent where the location
group member is at. group member is at.
+--rw location-group* [name] +--rw location-group* [name]
+--rw name string +--rw name string
+--rw geo-ip-ipv4 inet:ipv4-address +--rw geo-ip-ipv4 inet:ipv4-address
+--rw geo-ip-ipv6 inet:ipv6-address +--rw geo-ip-ipv6 inet:ipv6-address
+--rw continent? identityref +--rw continent? identityref
Figure 17: Location Group YANG Data Tree Figure 11: Location Group YANG Data Tree
7. Information Model for Threat Prevention 6. 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). There are multiple managed objects that constitute
are multiple managed objects that constitute this category. This this category. This section lists these objects and relationship
section lists these objects and relationship among them. Figure 19 among them. Figure 13 shows the YANG tree of a Threat-Prevention
shows the YANG tree of a Threat-Prevention object. 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 12: 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 13: Threat Prevention YANG Data Tree
7.1. Threat Feed 6.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 YANG tree of a Threat- malicious activities. Figure 14 shows the YANG tree 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:
Feed-name: This field identifies the name of this object. Feed-name: This field identifies the name of this object.
Feed-Server-ipv4: This represents the IPv4 server address of the Feed-Server-ipv4: This represents the IPv4 server address of the
feed provider, it may be external or local servers. feed provider, it may be external or local servers.
Feed-Server-ipv6: This represents the IPv6 server address of the Feed-Server-ipv6: This represents the IPv6 server address of the
feed provider, it may be external or local servers. feed provider, it may be external or local servers.
skipping to change at page 18, line 33 skipping to change at page 14, line 18
types used (e.g., executable malware). types used (e.g., executable malware).
Threat-file-types: This field identifies the information about Threat-file-types: This field identifies the information about
the file types identified and reported by the threat-feed. the file types identified and reported by the threat-feed.
signatures: This field contains the signatures of malicious signatures: This field contains the signatures of malicious
programs or activities provided by the threat-feed. The programs or activities provided by the threat-feed. The
examples of signature types are "YARA", "SURICATA", and examples of signature types are "YARA", "SURICATA", and
"SNORT". "SNORT".
+--rw threat-prevention +--rw threat-prevention
+--rw threat-feed-list* [feed-name] +--rw threat-feed-list* [feed-name]
+--rw feed-name identityref +--rw feed-name identityref
+--rw feed-server-ipv4? inet:ipv4-address +--rw feed-server-ipv4? inet:ipv4-address
+--rw feed-server-ipv6? inet:ipv6-address +--rw feed-server-ipv6? inet:ipv6-address
+--rw feed-description? string +--rw feed-description? string
+--rw threat-file-types* identityref +--rw threat-file-types* identityref
+--rw signatures* identityref +--rw signatures* identityref
Figure 20: Threat Feed YANG Data Tree Figure 14: Threat Feed YANG Data Tree
7.2. Payload Content 6.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 YANG tree of defining exception to threat feeds. Figure 15 shows the YANG tree of
a Payload-content list. The Payload-Content object SHALL have the a Payload-content list. The Payload-Content object SHALL have the
following information: following information:
Name: This field identifies the name of this object. For Name: This field identifies the name of this object. For
example, the name "backdoor" indicates the payload content example, the name "backdoor" indicates the payload content
is related to backdoor attack. is related to backdoor attack.
payload-description: This represents the description of how the payload-description: This represents the description of how the
payload content is related to a security attack. payload content is related to a security attack.
Content: This contains the payload contents, which are involed in Content: This contains the payload contents, which are involed in
a security attack, as strings. a security attack, as strings.
+--rw payload-content* [name] +--rw payload-content* [name]
+--rw name string +--rw name string
+--rw payload-description string +--rw payload-description string
+--rw content* string +--rw content* string
Figure 21: Payload Content in YANG Data Tree
8. Role-based Acess Control (RBAC)
Role-Based Access Control (RBAC) provides a powerful and centralized
control within a network. It is a policy neutral access control
mechanism defined around roles and privileges. The components of
RBAC, such as role-permissions, user-role and role-role
relationships, make it simple to perform user assignments.
+--------------+ Figure 15: Payload Content in YANG Data Tree
| |
| User 1 + (has many)
| |\
+--------------+ \ +---------------+ +-------------+
. \ | | (has many) | |
. --->+ List of roles +----------->+ Permissions |
+--------------+ / | | | |
| | / +---------------+ +-------------+
| User n +/
| | (has many)
+--------------+
Figure 22: Role-based Acess Control Diagram 7. Network Configuration Access Control Model (NACM)
As shown in Figure 22, a role represents a collection of permissions Network Configuration Access Control Model (NACM) provides a high-
(e.g., accessing a file server or other particular resources). A level overview of the access control with the following features
role may be assigned to one or multiple users. Both roles and [RFC8341]:
permissions can be organized in a hirarchy. A role may consists of
other roles and permissions.
Following are the steps required to build RBAC: o Independent control of action, data, and notification access is
provided.
1. Defining roles and permissions. o A simple and familiar set of datastore permissions is used.
2. Establishing relations among roles and permissions. o Support for YANG security tagging allows default security modes to
automatically exclude sensitive data.
3. Defining users. o Separate default access modes for read, write, and execute
permissions are provided.
4. Associating rules with roles and permissions. o Access control rules are applied to configurable groups of users.
5. assigning roles to users. The data model for the I2NSF Consumer-Facing Interface provides NACM
mechanisms and concepts to user-group and owners permissions. The
NACM with the above features can be used to set up all the management
access controls in the I2NSF high-level authorization view, and it
may have a high impact on the optimization and performance.
9. YANG Data Model for Security Policies for Consumer-Facing Interface 8. YANG Data Model of Consumer-Facing Interface
The main objective of this data model is to provide both an The main objective of this data model is to provide both an
information model and the corresponding YANG data model of I2NSF information model and the corresponding YANG data model of I2NSF
Consumer-Facing Interface. This interface can be used to deliver Consumer-Facing Interface. This interface can be used to deliver
control and management messages 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
skipping to change at page 20, line 42 skipping to change at page 16, line 16
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. Interface to Security Controller.
<CODE BEGINS> file "ietf-cfi-policy.yang" <CODE BEGINS> file "ietf-i2nsf-cfi-policy@2019-11-04.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";
} }
import ietf-inet-types{ import ietf-inet-types{
prefix inet; prefix inet;
reference reference
"Section 4 of RFC 6991"; "Section 4 of RFC 6991";
} }
import iana-crypt-hash { import ietf-netconf-acm {
prefix ianach; prefix nacm;
} }
organization organization
"IETF I2NSF (Interface to Network Security Functions) "IETF I2NSF (Interface to Network Security Functions)
Working Group"; Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/i2nsf> "WG Web: <http://tools.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org> WG List: <mailto:i2nsf@ietf.org>
WG Chair: Adrian Farrel
<mailto:Adrain@olddog.co.uk>
WG Chair: Linda Dunbar WG Chair: Linda Dunbar
<mailto:Linda.duhbar@huawei.com> <mailto:Linda.duhbar@huawei.com>
WG Chair: Yoav Nir
<mailto:ynir.ietf@gmail.com>
Editor: Jaehoon Paul Jeong Editor: Jaehoon Paul Jeong
<mailto:pauljeong@skku.edu>"; <mailto:pauljeong@skku.edu>
Editor: Chaehong Chung
<mailto:darkhong@skku.edu>";
description description
"This module is a YANG module for Consumer-Facing Interface. "This module is a YANG module for Consumer-Facing Interface.
Copyright (c) 2018 IETF Trust and the persons identified as Copyright (c) 2018 IETF Trust and the persons identified as
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-07-21"{ revision "2019-11-04"{
description "latest revision"; description "The latest revision";
reference reference
"draft-ietf-consumer-facing-interface-dm-03"; "draft-ietf-consumer-facing-interface-dm-07";
}
identity permission-type {
description
"Base identity for the permission types.";
}
identity no-permission {
base permission-type;
description
"Identity for no-permission.";
}
identity read {
base permission-type;
description
"Identity for read permission.";
}
identity write {
base permission-type;
description
"Identity for write permission.";
}
identity execute {
base permission-type;
description
"Identity for execute permission.";
}
identity write-and-execute {
base permission-type;
description
"Identity for write & execute permission.";
}
identity read-and-execute {
base permission-type;
description
"Identity for read & execute permission.";
}
identity read-and-write {
base permission-type;
description
"Identity for read & write permission.";
}
identity scope-type {
description
"Base Identity for scope-type.";
}
identity tenant-wide {
base scope-type;
description
"Base Identity for tenant-wide scope type.";
}
identity domain-wide {
base scope-type;
description
"Base Identity for domain-wide scope type.";
} }
identity malware-file-type { identity malware-file-type {
description description
"Base identity for malware file types."; "Base identity for malware file types.";
} }
identity executable-file { identity executable-file {
base malware-file-type; base malware-file-type;
description description
"Identity for executable file types."; "Identity for executable file types.";
skipping to change at page 25, line 32 skipping to change at page 20, line 4
identity south-america { identity south-america {
base continent; base continent;
description description
"Identity for south-america."; "Identity for south-america.";
} }
identity oceania { identity oceania {
base continent; base continent;
description description
"Identity for Oceania"; "Identity for Oceania";
} }
identity certificate-type {
description
"Base Identity for certificate-type.
CRT certificate extension, which is used for certificates.
The certificates may be encoded as binary DER or as ASCII PEM.
The CER and CRT extensions are nearly synonymous. Most common
among *nix systems. CER certificate extension, which is an
alternate form of .crt (Microsoft Convention) You can use MS to
convert .crt to .cer (.both DER encoded .cer, or base64[PEM]
encoded .cer). The KEY extension is used both for public and
private PKCS#8 keys. The keys may be encoded as binary DER or
as ASCII PEM.";
}
identity cer {
base certificate-type;
description
"Identity for '.cer' certificates.";
}
identity crt {
base certificate-type;
description
"Identity for '.crt' certificates.";
}
identity key {
base certificate-type;
description
"Identity for '.key' certificates.";
}
identity enforce-type { identity enforce-type {
description description
"This identity represents the event of "This identity represents the event of
policy enforcement trigger type."; policy enforcement trigger type.";
} }
identity admin { identity admin {
base enforce-type; base enforce-type;
description description
"The identity for policy enforcement by admin."; "The identity for policy enforcement by admin.";
} }
skipping to change at page 28, line 37 skipping to change at page 22, line 26
base secondary-action; base secondary-action;
description description
"The identity for system logging."; "The identity for system logging.";
} }
identity session-log { identity session-log {
base secondary-action; base secondary-action;
description description
"The identity for session logging."; "The identity for session logging.";
} }
identity role-type {
description
"This is the base identity for the roles.";
}
identity user {
base role-type;
description
"This represents the identity of the user role.";
}
identity group {
base role-type;
description
"This represents the identity of any member of the
security policy's defined group.";
}
identity other {
base role-type;
description
"This represents the identity of anyone else.";
}
identity all {
base role-type;
description
"This represents the identity of everyone
(i.e., user, group, and other).";
}
identity owner { identity owner {
description description
"This is the base identity for the owner"; "This is the base identity for the owner";
} }
identity dept-head { identity dept-head {
base owner; base owner;
description description
"This represents the identity of the head of department."; "This represents the identity of the head of department.";
} }
identity manager { identity manager {
skipping to change at page 29, line 46 skipping to change at page 23, line 8
base owner; base owner;
description description
"This represents the identity of the head of security."; "This represents the identity of the head of security.";
} }
identity sec-admin { identity sec-admin {
base owner; base owner;
description description
"This represents the identity of security admin."; "This represents the identity of security admin.";
} }
identity tenant-type {
description
"This is the base identity for the tenants
to represent the ownership of the security policies.";
}
identity human-resources {
base tenant-type;
description
"This represents the identity of the human resources
department or division.";
}
identity marketing {
base tenant-type;
description
"This represents the identity of the marketing
department or division.";
}
identity customer-service {
base tenant-type;
description
"This represents the identity of customer service
department or division.";
}
identity research {
base tenant-type;
description
"This represents the identity of research
department or division.";
}
identity finance {
base tenant-type;
description
"This represents the identity of finance
department or division.";
}
identity domain {
description
"This represents the base identity of different domains.";
}
identity enterprise {
base domain;
description
"This represents the identity of an enterprise domain.";
}
identity signature-type { identity signature-type {
description description
"This represents the base identity for signature types."; "This represents the base identity for signature types.";
} }
identity signature-yara { identity signature-yara {
base signature-type; base signature-type;
description description
"This represents the YARA signatures."; "This represents the YARA signatures.";
} }
identity signature-snort { identity signature-snort {
base signature-type; base signature-type;
description description
"This represents the SNORT signatures."; "This represents the SNORT signatures.";
} }
identity signature-suricata { identity signature-suricata {
base signature-type; base signature-type;
description description
"This represents the SURICATA signatures."; "This represents the SURICATA signatures.";
skipping to change at page 31, line 41 skipping to change at page 24, line 4
identity fireeye { identity fireeye {
base threat-feed-type; base threat-feed-type;
description description
"This represents FireEye threat-feed."; "This represents FireEye threat-feed.";
} }
identity alienvault { identity alienvault {
base threat-feed-type; base threat-feed-type;
description description
"This represents Alienvault threat-feed."; "This represents Alienvault threat-feed.";
} }
identity auth-type {
description
"The base identity for authentication type.";
}
identity auth-type-server {
base auth-type;
description
"This represents the server authentication.";
}
identity auth-type-client {
base auth-type;
description
"This represents the client authentication.";
}
identity auth-type-mutual {
base auth-type;
description
"This represents the both server and client
authentication.";
}
identity auth-method-type {
description
"Base idendity for authentication-methods";
}
identity password-based {
base auth-method-type;
description
"This is the identity for the password-based authetication type.";
}
identity token-based {
base auth-method-type;
description
"This is the identity for the token-based authetication type.";
}
identity certificate-based {
base auth-method-type;
description
"This is the identity for the certificate-based authetication type.";
}
/* /*
* Groupings * Groupings
*/ */
grouping ipv4-list { grouping ipv4-list {
description description
"Grouping for ipv4 based ip-addresses."; "Grouping for ipv4 based ip-addresses.";
leaf-list ipv4 { leaf-list ipv4 {
type inet:ipv4-address; type inet:ipv4-address;
skipping to change at page 33, line 29 skipping to change at page 24, line 48
grouping ipv6 { grouping ipv6 {
description description
"Grouping for ipv6 based ip-address."; "Grouping for ipv6 based ip-address.";
leaf ipv6 { leaf ipv6 {
type inet:ipv6-address; type inet:ipv6-address;
description description
"This is the entry for the ipv6 ip-address."; "This is the entry for the ipv6 ip-address.";
} }
} }
grouping ip-address-info { grouping ip-address-info {
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 {
description
"User can choose between 'exact match' and 'range match'.";
case exact-match-ipv4 {
uses ipv4;
description
"Exact ip-address match for ipv4 type addresses";
}
case exact-match-ipv6 {
uses ipv6;
description
"Exact ip-address match for ipv6 type addresses";
}
case range-match-ipv4 {
list range-ipv4-address {
key "start-ipv4-address end-ipv4-address";
leaf start-ipv4-address {
type inet:ipv4-address;
description
"Start IPv4 address for a range match.";
}
leaf end-ipv4-address {
type inet:ipv4-address;
description
"End IPv4 address for a range match.";
}
description
"Range match for an IP-address.";
}
}
case range-match-ipv6 {
list range-ipv6-address {
key "start-ipv6-address end-ipv6-address";
leaf start-ipv6-address {
type inet:ipv6-address;
description
"Start IPv6 address for a range match.";
}
leaf end-ipv6-address {
type inet:ipv6-address;
description
"End IPv6 address for a range match.";
}
description
"Range match for an IP-address.";
}
}
}
}
grouping password-based-method { choice match-type {
list password-list {
key "auth-method";
leaf auth-method {
type identityref {
base auth-method-type;
}
description
"This represents the authentication method is password-based.";
}
leaf password {
type ianach:crypt-hash;
description
"The password for this entry.";
}
description
"This represents the list of
encrypted passwords.";
}
}
grouping certificate-based-method {
list cert-server-list {
key "auth-method";
description description
"This describes the certificate-based authentication list."; "User can choose between 'exact match' and 'range match'.";
case exact-match-ipv4 {
leaf auth-mthod { uses ipv4;
type identityref {
base auth-method-type;
}
description
"This represents the authentication method is
certificate based method.";
}
leaf cert-server-name {
type string;
description
"This field represents the name of the certificate-
server name.";
}
leaf cert-server-ipv4 {
type inet:ipv4-address;
description description
"This represents ipv4 address of a "Exact ip-address match for ipv4 type addresses";
certificate server.";
} }
leaf cert-server-ipv6 { case exact-match-ipv6 {
type inet:ipv6-address; uses ipv6;
description description
"This represents the ipv6 address of a "Exact ip-address match for ipv6 type addresses";
certificate server.";
} }
list certificate { case range-match-ipv4 {
key "cert-type"; list range-ipv4-address {
description key "start-ipv4-address end-ipv4-address";
"This represents the certificate-types."; leaf start-ipv4-address {
type inet:ipv4-address;
leaf cert-type { description
type identityref { "Start IPv4 address for a range match.";
base certificate-type; }
leaf end-ipv4-address {
type inet:ipv4-address;
description
"End IPv4 address for a range match.";
} }
description description
"This represents a certificate type."; "Range match for an IP-address.";
} }
} }
} case range-match-ipv6 {
} list range-ipv6-address {
key "start-ipv6-address end-ipv6-address";
grouping token-based-method { leaf start-ipv6-address {
list token-list { type inet:ipv6-address;
key "auth-method"; description
description "Start IPv6 address for a range match.";
"This represents the list of tokens."; }
leaf end-ipv6-address {
leaf auth-method { type inet:ipv6-address;
type identityref { description
base auth-method-type; "End IPv6 address for a range match.";
}
description
"Range match for an IP-address.";
} }
description
"This represents the authentication type is
token-based method.";
}
leaf token {
type string;
description
"This object contains a string of a token.";
}
leaf token-server {
type inet:ipv4-address;
description
"This represents the token-server information.";
} }
} }
} }
grouping ipsec-based-method { grouping ipsec-based-method {
description
"This represents the ipsec-based method.";
list ipsec-method { list ipsec-method {
key "method"; key "method";
description description
"This represents the list of IPsec method types."; "This represents the list of IPsec method types.";
leaf method { leaf method {
type identityref { type identityref {
base i2nsf-ipsec; base i2nsf-ipsec;
} }
description description
"This represents IPsec IKE and IPsec IKEless cases."; "This represents IPsec IKE and IPsec IKEless cases.";
} }
} }
} }
grouping user-group { grouping user-group {
description description
"The grouping for user-group entities, and "The grouping for user-group entities, and
contains information such as name & ip-address."; contains information such as name & ip-address.";
leaf name { leaf-list name {
type string; type leafref {
path /nacm:nacm/nacm:groups/nacm:group/nacm:user-name;
}
description description
"This represents the name of a user."; "This represents the name of a user.";
} }
uses ip-address-info; uses ip-address-info;
} }
grouping device-group { grouping device-group {
description description
"This group represents device group information "This group represents device group information
such as ip-address protocol."; such as ip-address protocol.";
leaf name { leaf name {
type string; type string;
description description
"This represents the name of a device."; "This represents the name of a device.";
} }
uses ip-address-info; uses ip-address-info;
leaf-list protocol { leaf-list protocol {
type identityref { type identityref {
base protocol-type; base protocol-type;
} }
description description
"This represents the communication protocols of devices."; "This represents the communication protocols of devices.";
} }
} }
grouping location-group { grouping location-group {
description description
"This group represents location-group information "This group represents location-group information
such as geo-ip and continent."; such as geo-ip and continent.";
leaf name { leaf name {
type string; type string;
description description
"This represents the name of a location."; "This represents the name of a location.";
} }
leaf geo-ip-ipv4 { leaf geo-ip-ipv4 {
type inet:ipv4-address; type inet:ipv4-address;
description description
"This represents the IPv4 geo-ip of a location."; "This represents the IPv4 geo-ip of a location.";
} }
skipping to change at page 39, line 4 skipping to change at page 28, line 28
} }
grouping payload-string { grouping payload-string {
description description
"The grouping for payload-string content. "The grouping for payload-string content.
It contains information such as name and string content."; It contains information such as name and string content.";
leaf payload-description { leaf payload-description {
type string; type string;
description description
"This represents the description of a payload."; "This represents the description of a payload.";
} }
leaf-list content { leaf-list content {
type string; type string;
description description
"This represents the payload string content."; "This represents the payload string content.";
} }
} }
grouping owners-ref {
description
"This grouping is for owners reference using Network configuration Access Control Model (NACM).";
leaf-list owners {
type leafref {
path /nacm:nacm/nacm:groups/nacm:group/nacm:name;
}
description
"This leaf-list names the owner groups of the
list instace it sits on. Only the owners and
super users are authorized to modify the contents.";
}
}
list i2nsf-cfi-policy { list i2nsf-cfi-policy {
key "policy-name"; key "policy-name";
description
"This is the security policy list. Each policy in the list
contains a list of security rules, and is a policy instance
to have complete information such as where and when a
policy needs to be applied.";
leaf policy-name {
type string;
mandatory true;
description description
"This is the security policy list. Each policy in the list "The name which identifies the policy.";
contains a list of security rules, and is a policy instance }
to have complete information such as where and when a uses owners-ref;
policy needs to be applied.";
leaf policy-name { container rule{
type string; description
mandatory true; "This container is for rules.";
description nacm:default-deny-write;
"The name which identifies the policy.";
}
list rule { list rule {
leaf rule-name { leaf rule-name {
type string; type string;
mandatory true; mandatory true;
description description
"This represents the name for rules."; "This represents the name for the rule.";
} }
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.";
uses owners-ref;
container event { container event {
description description
"This represents the event (e.g., a security event, which a security rule is made for."; "This represents the event (e.g., a security event,
which a security rule is made for.)";
leaf security-event { leaf security-event {
type identityref { type identityref {
base security-event-type; base security-event-type;
} }
mandatory true; mandatory true;
description description
"This contains the description of security events."; "This contains the description of security events.";
} }
choice enforce-type { choice enforce-type {
description description
"There are three different enforcement types; "There are three different enforcement types; admin, and time.";
admin, and time.";
case enforce-admin { case enforce-admin {
leaf admin { leaf admin {
type identityref { type identityref {
base enforce-type; base enforce-type;
} }
description description
"This represents the enforcement type based on admin's decision."; "This represents the enforcement type based on admin's
decision.";
} }
} }
case time { case time {
container time-information { container time-information {
description description
"The begin-time and end-time information "The begin-time and end-time information
when the security rule should be applied."; when the security rule should be applied.";
leaf enforce-time { leaf enforce-time {
type identityref { type identityref {
base enforce-type; base enforce-type;
} }
description description
"The enforcement type is time-enforced."; "The enforcement type is time-enforced.";
} }
leaf begin-time { leaf begin-time {
type yang:date-and-time; type yang:date-and-time;
description description
"This is start time for time zone"; "This is start time for time zone";
} }
leaf end-time { leaf end-time {
type yang:date-and-time; type yang:date-and-time;
description description
"This is end time for time zone"; "This is end time for time zone";
} }
} }
} }
} }
leaf frequency { leaf frequency {
type enumeration { type enumeration {
enum only-once { enum only-once {
description description
"This represents the rule is enforced only once."; "This represents the rule is enforced only once.";
} }
skipping to change at page 41, line 11 skipping to change at page 31, line 10
"This represents the rule is enforced on a weekly basis."; "This represents the rule is enforced on a weekly basis.";
} }
enum monthly { enum monthly {
description description
"This represents the rule is enforced on a monthly basis."; "This represents the rule is enforced on a monthly basis.";
} }
} }
default only-once; default only-once;
description description
"This represents how frequent the rule should be enforced."; "This represents how frequent the rule should be enforced.";
}
} }
} container condition {
container condition {
choice condition {
description description
"The conditions for general security policies."; "The conditions for general security policies.";
case firewall-condition { choice condition {
description
"This choice condition is for general firewall.";
case firewall-condition {
description
"The general firewall condition.";
container firewall-source {
description description
"The general firewall condition."; "This represents the source.";
container firewall-source { leaf src-target {
description type leafref {
"This represents the source."; path /nacm:nacm/nacm:groups/nacm:group/nacm:user-name;
leaf src-target {
type leafref {
path "/i2nsf-cfi-policy/endpoint-group/user-group/name";
}
mandatory true;
description
"This describes the paths to
the source reference.";
} }
} mandatory true;
container firewall-destination {
description description
"This represents the destination."; "This describes the paths to
leaf-list dest-target { the source reference.";
type leafref { }
path "/i2nsf-cfi-policy/endpoint-group/user-group/name";
}
description
"This describes the paths to the
destination target reference.";
}
}
} }
case ddos-condition { container firewall-destination {
description description
"The condition for DDoS mitigation."; "This represents the destination.";
container ddos-source { leaf-list dest-target {
description type leafref {
"This represents the source."; path /nacm:nacm/nacm:groups/nacm:group/nacm:user-name;
leaf-list src-target {
type leafref {
path "/i2nsf-cfi-policy/endpoint-group/device-group/name";
}
description
"This describes the path to the
source target references.";
} }
description
"This describes the paths to the
destination target reference.";
} }
container ddos-destination { }
description }
"This represents the target."; case ddos-condition {
leaf-list dest-target { description
type leafref { "The condition for DDoS mitigation.";
path "/i2nsf-cfi-policy/endpoint-group/device-group/name"; container ddos-source {
} description
description "This represents the source.";
"This describes the path to the leaf-list src-target {
destination target references."; type leafref {
path "/i2nsf-cfi-policy/endpoint-group/device-group/name";
} }
description
"This describes the path to the
source target references.";
} }
container rate-limit { }
description "This describes the rate-limit."; container ddos-destination {
leaf packet-per-second { description
type uint16; "This represents the target.";
description leaf-list dest-target {
"The rate-limit limits the amount of incoming packets."; type leafref {
path "/i2nsf-cfi-policy/endpoint-group/device-group/name";
} }
description
"This describes the path to the
destination target references.";
} }
} }
case custom-condition { container rate-limit {
description description "This describes the rate-limit.";
"The condition based on packet contents."; leaf packet-per-second {
container custon-source { type uint16;
description description
"This represents the source."; "The rate-limit limits the amount of incoming packets.";
leaf-list src-target { }
type leafref { }
path "/i2nsf-cfi-policy/threat-prevention/payload-content/name"; }
} case custom-condition {
description description
"Describes the payload string "The condition based on packet contents.";
content condition source."; container custon-source {
description
"This represents the source.";
leaf-list src-target {
type leafref {
path "/i2nsf-cfi-policy/threat-prevention/payload-content/name";
} }
description
"Describes the payload string
content condition source.";
} }
container custom-destination { }
description container custom-destination {
"This represents the destination."; description
"This represents the destination.";
leaf dest-target { leaf dest-target {
type leafref { type leafref {
path "/i2nsf-cfi-policy/threat-prevention/payload-content/name"; path "/i2nsf-cfi-policy/threat-prevention/payload-content/name";
}
mandatory true;
description
"Describes the payload string
content condition destination.";
} }
mandatory true;
description
"Describes the payload string
content condition destination.";
} }
} }
case threat-feed-condition { }
case threat-feed-condition {
description
"The condition based on the threat-feed information.";
container threat-feed-source {
description description
"The condition based on the threat-feed information."; "This represents the source.";
container threat-feed-source { leaf-list src-target {
description type leafref {
"This represents the source."; path "/i2nsf-cfi-policy/threat-prevention/threat-feed-list/feed-name";
leaf-list src-target {
type leafref {
path "/i2nsf-cfi-policy/threat-prevention/threat-feed-list/feed-name";
}
description "Describes the threat-feed
condition source.";
} }
description "Describes the threat-feed
condition source.";
} }
container threat-feed-destination { }
description container threat-feed-destination {
"This represents the destination."; description
leaf dest-target { "This represents the destination.";
type leafref { leaf dest-target {
path "/i2nsf-cfi-policy/threat-prevention/threat-feed-list/feed-name"; type leafref {
} path "/i2nsf-cfi-policy/threat-prevention/threat-feed-list/feed-name";
mandatory true;
description "Describes the threat-feed
condition destination.";
} }
mandatory true;
description "Describes the threat-feed
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 identityref { type identityref {
base primary-action; base primary-action;
} }
mandatory true; mandatory true;
description description
"This represent the primary actions (e.g., PASS, DROP, "This represent the primary actions (e.g., PASS, DROP,
ALERT, and MIRROR) to be applied a condition."; ALERT, and MIRROR) to be applied a condition.";
} }
leaf secondary-action { leaf secondary-action {
type identityref { type identityref {
base secondary-action; base secondary-action;
} }
description description
"This represents the secondary actions (e.g., log "This represents the secondary actions (e.g., log
and syslog) to be applied if needed."; and syslog) to be applied if needed.";
}
} }
} container ipsec-method {
container ipsec-method {
description description
"This container represents the IPsec IKE and IKEless cases."; "This container represents the IPsec IKE and IKEless cases.";
leaf method { leaf method {
type leafref { type identityref {
path "/i2nsf-cfi-policy/multi-tenancy/policy-mgmt-auth-method-instance/ipsec-method/method"; base i2nsf-ipsec;
} }
description description
"This references the IPsec method types, "This references the IPsec method types,
which includes IPsec IKE and IPsec IKEless cases."; which includes IPsec IKE and IPsec IKEless cases.";
}
} }
} leaf owner {
leaf owner { type identityref {
type identityref {
base owner; base owner;
} }
mandatory true; mandatory true;
description description
"This field defines the owner of this "This field defines the owner of this
rule. Only the owner is authorized to rule. Only the owner is authorized to
modify the contents of the rule."; modify the contents of the rule.";
}
} }
} }
container endpoint-group {
container multi-tenancy {
description description
"The multi-tenant environment information "A logical entity in their business
in which the policy is applied. The Rules environment, where a security policy
in the Policy can refer to sub-objects is to be applied.";
(e.g., domain, tenant, role, and user) of it."; uses user-group;
list device-group {
list policy-domain { key "name";
key "domain-name"; uses device-group;
description
"This represents the device group.";
}
list location-group{
key "name";
uses location-group;
description description
"This represents the list of policy domains."; "This represents the location group.";
leaf domain-name {
type identityref {
base domain;
}
description
"This represents the name of a domain.";
}
leaf address {
type string;
description
"The address details of the organization
or customer.";
}
leaf contact {
type string;
description
"contact information of the organization
or customer.";
} }
list policy-tenant { }
key "tenant-type";
description
"This field identifies the domain to which this
tenant belongs. This should be reference to a
'Policy-Domain' object.";
leaf tenant-type{
type identityref {
base tenant-type;
}
description
"The name of the tenant, such as HR or Finance department.";
}
list policy-role {
key "role-type";
description
"This represent the roles within the tenants,
in order to distinguish who may or may not
have access to policies.";
leaf role-type { container threat-prevention {
type identityref { description
base role-type; "this describes the list of threat-prevention.";
}
description
"This represents the name of the role";
}
list policy-user {
key "name";
description
"This represents the list of policy users.";
leaf name { list threat-feed-list {
type string; key "feed-name";
description
"This represents the name of the user";
}
leaf password {
type ianach:crypt-hash;
description
"User password for basic authentication";
}
leaf email {
type string;
description
"The email account of a user";
}
list access-profile {
key "permission-type scope-type";
description
"This field identifies the access profile for the
role. The profile grants or denies access to policy
objects.";
leaf permission-type {
type identityref {
base permission-type;
}
description
"This represents the permission types, such as
read, write, execute, read-and-write, and etc.";
}
leaf scope-type {
type identityref {
base scope-type;
}
description
"identifies whether a user has domain-wide
or tenant-wide privileges";
}
}
}
}
}
}
list policy-mgmt-auth-method-instance {
key "auth-instance-type";
description description
"This represents the list of instances for "This represents the threat feed list.";
policy management authentication methods."; uses threat-feed-info;
leaf auth-instance-type { leaf-list threat-file-types {
type identityref { type identityref {
base auth-type; base malware-file-type;
} }
default executable-file;
description description
"This identifies whether the authentication type "This contains a list of file types needed to
is server authentication, client authentication, be scanned for the virus.";
or both.";
} }
choice policy-mgmt-auth-method { leaf-list signatures {
type identityref {
base signature-type;
}
default signature-suricata;
description description
"This represents the choices for which "This contains a list of signatures or hash
authentication method is used."; of the threats.";
case password-based {
uses password-based-method;
}
case token-based {
description
"This represents the token-based method.";
uses token-based-method;
}
case certificate-based {
description
"This represents the certificate-based-method.";
uses certificate-based-method;
}
case ipsec {
description
"This repreents authentication method based on IPSEC.";
uses ipsec-based-method;
} }
} }
} list payload-content {
} key "name";
container endpoint-group { leaf name {
description type string;
"A logical entity in their business
environment, where a security policy
is to be applied.";
list user-group {
key "name";
uses user-group;
description
"This represents the user group.";
}
list device-group {
key "name";
uses device-group;
description
"This represents the device group.";
}
list location-group{
key "name";
uses location-group;
description
"This represents the location group.";
}
}
container threat-prevention {
description
"this describes the list of threat-prevention.";
list threat-feed-list {
key "feed-name";
description description
"This represents the threat feed list."; "This represents the name of payload-content.
uses threat-feed-info; It should give an idea of why specific payload
content is marked as threat. For example, the name
leaf-list threat-file-types { 'backdoor' indicates the payload content is related
type identityref { to backdoor attack.";
base malware-file-type;
}
default executable-file;
description
"This contains a list of file types needed to
be scanned for the virus.";
}
leaf-list signatures {
type identityref {
base signature-type;
}
default signature-suricata;
description
"This contains a list of signatures or hash
of the threats.";
} }
} description
list payload-content { "This represents the payload-string group.";
key "name"; uses payload-string;
leaf name {
type string;
decription
"This represents the name of payload-content".
It should give an idea of why specific payload
content is marked as threat. For example, the name
"backdoor" indicates the payload content is related
to backdoor attack.";
}
description
"This represents the payload-string group.";
uses payload-string;
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 23: YANG for Consumer-Facing Interface Figure 16: YANG for Consumer-Facing Interface
10. Example XML Output for Various Scenarios 9. XML Configuration Examples of High-Level Security Policy Rules
This section describes the XML instances for different policies This section shows XML configuration examples of high-level security
examples that are delivered through Consumer-Facing Interface. The policy rules that are delivered from the I2NSF User to the Security
considered use cases are: VoIP/VoLTE security service, DDoS-attack Controller over the Consumer-Facing Interface. The considered use
mitigation, time-based firewall as a web-filter. cases are: Database registration, time-based firewall for web
filtering, VoIP/VoLTE security service, and DDoS-attack mitigation.
10.1. DB Registration: Information of Positions and Devices (Endpoint 9.1. Database Registration: Information of Positions and Devices
Group) (Endpoint Group)
If new endpoints are introduced to the network, it is necessary to If new endpoints are introduced to the network, it is necessary to
first register their data to the database. For example, if new first register their data to the database. For example, if new
members are newly introduced in either of three different groups members are newly introduced in either of three different groups
(i.e., user-group, device-group, and payload-group), each of them (i.e., user-group, device-group, and payload-group), each of them
should be registered with information such as ip-addresses or should be registered with information such as ip-addresses or
protocols used by devices. Figure 24 shows an example XML protocols used by devices. Figure 17 shows an example XML
representation of the registered information for the user-group and representation of the registered information for the user-group and
device-group. device-group.
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
<endpoint-group xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"> <endpoint-group xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
<user-group> <user-group>
<name>employees</name> <name>employees</name>
<range-ip-address> <range-ip-address>
<start-ip-address>221.159.112.1</start-ip-address> <start-ip-address>221.159.112.1</start-ip-address>
<end-ip-address>221.159.112.90</end-ip-address> <end-ip-address>221.159.112.90</end-ip-address>
</range-ip-address> </range-ip-address>
</user-group> </user-group>
<device-group> <device-group>
<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>
</endpoint-group xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"> </endpoint-group xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
Figure 24: Registering User-group and Device-group Information Figure 17: Registering User-group and Device-group Information
10.2. Scenario 1: Block SNS Access during Business Hours 9.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 office
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 "employees" 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" ?>
<policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"> <policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
<policy-name>security_policy_for_blocking_sns</policy-name> <policy-name>security_policy_for_blocking_sns</policy-name>
<rule> <rule>
<rule-name>block_access_to_sns_during_office_hours</rule-name> <rule-name>block_access_to_sns_during_office_hours</rule-name>
<event> <event>
<time-information> <time-information>
skipping to change at page 51, line 37 skipping to change at page 38, line 37
</condition> </condition>
<action> <action>
<primary-action>drop</primary-action> <primary-action>drop</primary-action>
</action> </action>
<ipsec-method> <ipsec-method>
<method>ipsec-ike</method> <method>ipsec-ike</method>
</ipsec-method> </ipsec-method>
</rule> </rule>
</policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"> </policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
Figure 25: An XML Example for Time-based Firewall Figure 18: 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.
6. The IPsec method type used for nsf traffic steering is set to 6. The IPsec method type used for nsf traffic steering is set to
"ipsec-ike". "ipsec-ike".
10.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a 9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a Company
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 a 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 19 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
Interface, through RESTCONF server, to the security controller. The Interface, through RESTCONF server, to the security controller. 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" ?>
<policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"> <policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
<policy-name>security_policy_for_blocking_malicious_voip_packets</policy-name> <policy-name>security_policy_for_blocking_malicious_voip_packets</policy-name>
<rule> <rule>
<rule-name>Block_malicious_voip_and_volte_packets</rule-name> <rule-name>Block_malicious_voip_and_volte_packets</rule-name>
skipping to change at page 52, line 52 skipping to change at page 39, line 51
</condition> </condition>
<action> <action>
<primary-action>drop</primary-action> <primary-action>drop</primary-action>
</action> </action>
<ipsec-method> <ipsec-method>
<method>ipsec-ikeless</method> <method>ipsec-ikeless</method>
</ipsec-method> </ipsec-method>
</rule> </rule>
</policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"> </policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
Figure 26: An XML Example for VoIP Security Service Figure 19: 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".
2. The rule name is "Block_malicious_voip_and_volte_packets". 2. The rule name is "Block_malicious_voip_and_volte_packets".
3. The Source-target is "malicious-id". This can be a single ID or 3. The Source-target is "malicious-id". This can be a single ID or
a list of IDs, depending on how the ID are stored in the a list of IDs, depending on how the ID are stored in the
skipping to change at page 53, line 28 skipping to change at page 40, line 28
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".
6. The IPsec method used for nsf traffic steering is set to "ipsec- 6. The IPsec method used for nsf traffic steering is set to "ipsec-
ikeless". ikeless".
10.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company 9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web
Web Server 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
skipping to change at page 54, line 29 skipping to change at page 41, line 29
</condition> </condition>
<action> <action>
<primary-action>drop</primary-action> <primary-action>drop</primary-action>
</action> </action>
<ipsec-method> <ipsec-method>
<method>ipsec-ikeless</method> <method>ipsec-ikeless</method>
</ipsec-method> </ipsec-method>
</rule> </rule>
</policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"> </policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
Figure 27: An XML Example for DDoS-attack Mitigation Figure 20: 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".
3. The destination target is "webservers". "webservers" is the key 3. The destination target is "webservers". "webservers" is the key
which represents the list containing information, such as IP which represents the list containing information, such as IP
addresses and ports, about web-servers. addresses and ports, about web-servers.
skipping to change at page 55, line 8 skipping to change at page 42, line 8
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 used for nsf traffic steering is set to "ipsec- 7. The IPsec method used for nsf traffic steering is set to "ipsec-
ike". ike".
11. Security Considerations 10. Security Considerations
The data model for the I2NSF Consumer-Facing Interface is based on The data model for the I2NSF Consumer-Facing Interface is based on
the I2NSF framework [RFC8329], so the same security considerations the I2NSF framework [RFC8329], so the same security considerations
with the I2NSF framework should be included in this document. The with the I2NSF framework should be included in this document. The
data model needs a secure communication channel to protect the data model needs a secure communication channel to protect the
Consumer-Facing Interface between the I2NSF User and Security Consumer-Facing Interface between the I2NSF User and Security
Controller. Controller.
12. IANA Considerations 11. 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.
This document requests IANA to register the following YANG module in This document requests IANA to register the following YANG module in
the "YANG Module Names" registry [RFC7950]. the "YANG Module Names" registry [RFC7950].
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 12. Acknowledgments
13.1. Normative References This work was supported by Institute of Information & Communications
Technology Planning & Evaluation (IITP) grant funded by the Korea
MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based
Security Intelligence Technology Development for the Customized
Security Service Provisioning).
13. 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 authors sincerely appreciate their
contributions.
The following are co-authors of this document:
Hyoungshick Kim
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
EMail: hyoung@skku.edu
Eunsoo Kim
Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
EMail: eskim86@skku.edu
Seungjin Lee
Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
EMail: jine33@skku.edu
Jinyong Tim Kim
Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
EMail: timkim@skku.edu
Anil Lohiya
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
US
EMail: alohiya@juniper.net
Dave Qi
Bloomberg
731 Lexington Avenue
New York, NY 10022
US
EMail: DQI@bloomberg.net
Nabil Bitar
Nokia
755 Ravendale Drive
Mountain View, CA 94043
US
EMail: nabil.bitar@nokia.com
Senad Palislamovic
Nokia
755 Ravendale Drive
Mountain View, CA 94043
US
EMail: senad.palislamovic@nokia.com
Liang Xia
Huawei
101 Software Avenue
Nanjing, Jiangsu 210012
China
EMail: Frank.Xialiang@huawei.com
14. References
14.1. Normative References
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003, DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>. <https://www.rfc-editor.org/info/rfc3444>.
[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>.
skipping to change at page 56, line 32 skipping to change at page 45, line 37
[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>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", BCP 216, RFC 8407, Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018, DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>. <https://www.rfc-editor.org/info/rfc8407>.
13.2. Informative References 14.2. Informative References
[client-facing-inf-req] [client-facing-inf-req]
Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
S., and L. Xia, "Requirements for Client-Facing Interface S., and L. Xia, "Requirements for Client-Facing Interface
to Security Controller", draft-ietf-i2nsf-client-facing- to Security Controller", draft-ietf-i2nsf-client-facing-
interface-req-05 (work in progress), May 2018. interface-req-05 (work in progress), May 2018.
[i2nsf-capability-im] [i2nsf-capability-im]
Xia, L., Strassner, J., Basile, C., and D. Lopez, Xia, L., Strassner, J., Basile, C., and D. Lopez,
"Information Model of NSFs Capabilities", draft-ietf- "Information Model of NSFs Capabilities", draft-ietf-
i2nsf-capability-05 (work in progress), April 2019. i2nsf-capability-05 (work in progress), April 2019.
[i2nsf-ipsec] [i2nsf-ipsec]
Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-
Garcia, "Software-Defined Networking (SDN)-based IPsec Garcia, "Software-Defined Networking (SDN)-based IPsec
Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow- Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow-
protection-05 (work in progress), July 2019. protection-07 (work in progress), August 2019.
[i2nsf-terminology] [i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF) Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-08 (work in Terminology", draft-ietf-i2nsf-terminology-08 (work in
progress), July 2019. progress), July 2019.
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface-
dm-05 dm-06
The following are major changes made from draft-ietf-i2nsf-consumer-
facing-interface-dm-05:
o The container policy-mgnt-auth-method uses a list, and the policy-
mgmt-auth-method consists of choice-cases.
o Policy-role is changed from container to list. The access-profile
in the policy-role is not removed. Instead, it is placed inside
policy-user.
o Container Condition consists of choice-cases to show that it is
capable of configuring different triggering conditions.
o The enforce-type in Event container use a choice-case statement.
This change shows the clarity that the enforce-type is relevant to
each case (i.e., enforce-type == admin or time).
o The name for container "recursive" is changed to "frequency".
This container represents how frequently the rule is enforced, so
the name "frequency" is more appropriate.
o The certificate based authentication method is modified so that a
certificate server can handle more than one (list) of certificate
types.
The minor changes are as follows:
o Typos are corrected.
o IPv6 as well as IPv4 are included.
o Some misused types are corrected (e.g., enum -> identity)
o Some descriptions that are unclear, mistaken, or shortly explained
are rewritten.
Appendix B. Acknowledgments
This work was supported by Institute of Information & Communications
Technology Planning & Evaluation (IITP) grant funded by the Korea
MSIT (Ministry of Science and ICT) (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 authors sincerely appreciate their
contributions.
The following are co-authors of this document:
Hyoungshick Kim
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
EMail: hyoung@skku.edu
Seungjin Lee
Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
EMail: jine33@skku.edu
Jinyong Tim Kim
Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
EMail: timkim@skku.edu The following changes are made from draft-ietf-i2nsf-consumer-facing-
interface-dm-06:
Anil Lohiya o This version has reflected the comments from Jan Lindblad.
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
US
EMail: alohiya@juniper.net o In Section 1, Figure 1 is modified such that "Multi-Tenancy" is
Dave Qi deleted because "Multi-Tenancy" can be described by "Endpoint
Bloomberg Groups" in a policy rule.
731 Lexington Avenue
New York, NY 10022
US
EMail: DQI@bloomberg.net o In Section 4, Figure 2 is modified such that the YANG data model
of a policy having at least one rule has a hierarchical structure
rather than a flat structure by deleing the "Multi-Tenancy" field.
Nabil Bitar o The section named "Information Model for Multi-Tenancy" is
Nokia deleted. The multi-tenancy can be specified by "Endpoint Groups"
755 Ravendale Drive along with "Network Configuration Access Control Model (NACM)"
Mountain View, CA 94043 mechanisms.
US
EMail: nabil.bitar@nokia.com o In Section 5.1, "NACM" is applied in "user-group" and for its
access control.
Senad Palislamovic o In Section 5.2, Figure 10 is modified because the "protocol" field
Nokia was missed in the previous version.
755 Ravendale Drive
Mountain View, CA 94043
US
EMail: senad.palislamovic@nokia.com o Section 7 is added as "Network Configuration Access Control Model
(NACM)" in order to provide the Consumer-Facing Interface with the
existing access control mechanisms. Also, the reference of
[RFC8341] is added for NACM.
Liang Xia o The section named "Role-based Access Control (RBAC)" is deleted
Huawei since this access control can be replaced by "NACM".
101 Software Avenue
Nanjing, Jiangsu 210012
China
EMail: Frank.Xialiang@huawei.com o In Section 8, the YANG data module is modified according to the
above changes.
Authors' Addresses Authors' Addresses
Jaehoon Paul Jeong Jaehoon Paul Jeong
Department of Computer Science and Engineering Department of Computer Science and Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
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
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Eunsoo Kim Chaehong Chung
Department of Electronic, Electrical and Computer Engineering Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 31 299 4104 Phone: +82 31 299 4957
EMail: eskim86@skku.edu EMail: darkhong@skku.edu
URI: http://seclab.skku.edu/people/eunsoo-kim/
Tae-Jin Ahn Tae-Jin Ahn
Korea Telecom Korea Telecom
70 Yuseong-Ro, Yuseong-Gu 70 Yuseong-Ro, Yuseong-Gu
Daejeon 305-811 Daejeon 305-811
Republic of Korea Republic of Korea
Phone: +82 42 870 8409 Phone: +82 42 870 8409
EMail: taejin.ahn@kt.com EMail: taejin.ahn@kt.com
 End of changes. 199 change blocks. 
1251 lines changed or deleted 631 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/