< draft-ietf-i2nsf-consumer-facing-interface-dm-02.txt   draft-ietf-i2nsf-consumer-facing-interface-dm-03.txt >
I2NSF Working Group J. Jeong I2NSF Working Group J. Jeong
Internet-Draft E. Kim Internet-Draft E. Kim
Intended status: Standards Track Sungkyunkwan University Intended status: Standards Track Sungkyunkwan University
Expires: May 8, 2019 T. Ahn Expires: September 12, 2019 T. Ahn
Korea Telecom Korea Telecom
R. Kumar R. Kumar
Juniper Networks Juniper Networks
S. Hares S. Hares
Huawei Huawei
November 4, 2018 March 11, 2019
I2NSF Consumer-Facing Interface YANG Data Model I2NSF Consumer-Facing Interface YANG Data Model
draft-ietf-i2nsf-consumer-facing-interface-dm-02 draft-ietf-i2nsf-consumer-facing-interface-dm-03
Abstract Abstract
This document describes a YANG data model for the Consumer-Facing This document describes an information model and a YANG data model
Interface between an Interface to Network Security Functions (I2NSF) for the Consumer-Facing Interface between an Interface to Network
User and Security Controller in an I2NSF system in a Network Security Functions (I2NSF) User and Security Controller in an I2NSF
Functions Virtualization (NFV) environment. The data model is system in a Network Functions Virtualization (NFV) environment. The
required for enabling different users of a given I2NSF system to information model defines various managed objects and relationship
define, manage, and monitor security policies for specific flows among these objects needed to build the interface. The information
within an administrative domain. model is organized based on the "Event-condition-Event" (ECA) policy
model defined by a capability information model for Interface to
Network Security Functions (I2NSF)[draft-ietf-i2nsf-capability], and
the data model is defined for enabling different users of a given
I2NSF system to define, manage, and monitor security policies for
specific flows within an administrative domain.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 8, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Data Modeling for Security Policies for Consumer-Facing 4. Information Model for Policy . . . . . . . . . . . . . . . . 5
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Event Sub-Model . . . . . . . . . . . . . . . . . . . . . 6
4.1. YANG Data Model for Security Policies for Consumer-Facing 4.2. Condition Sub-Model . . . . . . . . . . . . . . . . . . . 7
Interface . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Action Sub-Model . . . . . . . . . . . . . . . . . . . . 9
5. Use Case: Policy Instance Example for VoIP/VoLTE Security 5. Information Model for Multi-Tenancy . . . . . . . . . . . . . 9
Services . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1. Policy-Domain . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Policy Instance YANG Example for VoIP/VoLTE Security 5.2. Policy-Tenant . . . . . . . . . . . . . . . . . . . . . . 11
Services . . . . . . . . . . . . . . . . . . . . . . . . 35 5.3. Policy-Role . . . . . . . . . . . . . . . . . . . . . . . 12
6. Example XML Output for Various Use Cases . . . . . . . . . . 45 5.4. Policy-User . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Case 1: VoIP Security Service . . . . . . . . . . . . . . 45 5.5. Policy Management Authentication Method . . . . . . . . . 13
6.2. Case 2: DDoS-Attack Mitigation . . . . . . . . . . . . . 47 6. Information Model for Policy Endpoint Groups . . . . . . . . 14
6.3. Case 3: Time-Based Firewall . . . . . . . . . . . . . . . 48 6.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Case 4: Time-Based Web-Filter . . . . . . . . . . . . . . 49 6.2. Device-Group . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Case 5: Threat-Feed Configuration . . . . . . . . . . . . 50 6.3. Location-Group . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 51 7. Information Model for Threat Prevention . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 7.1. Threat-Feed . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 51 7.2. Payload-content . . . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 52 8. Role-Based Acess Control (RBAC) . . . . . . . . . . . . . . . 19
9. YANG Data Model for Security Policies for Consumer-Facing
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Example XML Output for Various Scenarios . . . . . . . . . . 37
10.1. DB registration: Information of positions and devices
(Endpoint group) . . . . . . . . . . . . . . . . . . . . 38
10.2. Scenario 1: Block SNS access during business hours . . . 38
10.3. Scenario 2: Block malicious VoIP/VoLTE packets coming to
the company . . . . . . . . . . . . . . . . . . . . . . 40
10.4. Scenario 3: Mitigate HTTP and HTTPS flood attacks on a
company web Server . . . . . . . . . . . . . . . . . . . 41
11. Security Considerations . . . . . . . . . . . . . . . . . . . 43
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing- Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-
interface-dm-01 . . . . . . . . . . . . . . . . . . 53 interface-dm-02 . . . . . . . . . . . . . . . . . . 46
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 53 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 46
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 53 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
This document provides a YANG [RFC6020] data model that defines the In I2NSF framework, each vendor can register their NSFs using the
required data for the Consumer-Facing Interface between an Interface Vendor Management System (VMS). Assuming that vendors also provide
to Network Security Functions (I2NSF) User and Security Controller in the front-end web applications registered with the I2NSF provider,
an I2NSF system [i2nsf-framework] in a Network Functions the Consumer-Facing Interface is required because the web
Virtualization (NFV) environment. The data model is required for applications developed by each vendor need to have a standard
enabling different users of a given I2NSF system to define, manage interface specifying the data types used when I2NSF user and security
and monitor security policies for specific flows within an controller communicate using this interface. Therefore, this
administrative domain. This document defines a YANG data model based document specifies the required information, their data types, and
on the information model of I2NSF Consumer-Facing Interface encoding schemes so that any data (security policy) transferred
[client-facing-inf-im]. through the Consumer-Facing Interface can easily be translated by the
security controller into low-level security policies. The translated
policies are delivered to Network Security Functions (NSFs) according
to their respective security capabilities for securiy enforcement.
The Consumer-Facing Interface would be built using a set of objects,
with each object capturing a unique set of information from Security
Admin (i.e., I2NSF User [RFC8329]) needed to express a Security
Policy. An object may have relationship with various other objects
to express a complete set of requirement. An information model
captures the managed objects and relationship among these objects.
The information model proposed in this document is structured in
accordance with the "Event-Condition-Event" (ECA) policy model.
An NSF Capability model is proposed in [draft-ietf-i2nsf-capability]
as the basic model for both the NSF-Facing interface and Consumer-
Facing Interface security policy model of this document.
[RFC3444] explains differences between an information and data model.
This document use the guidelines in [RFC3444] to define both the
information and data model for Consumer-Facing Interface. Figure 1
shows a high-level abstraction of Consumer-Facing Interface. A data
model, which represents an implementation of the information model in
a specific data representation language, is also defined in the later
sections of this document (see section 10).
+-----------------+ +-----------------+
| Consumer-facing | | Consumer-facing |
| Interface +--->+ Interface |
|Information Model| | Data Model |
+--------+--------+ +-----------------+
^
|
+-------------+-------------+------------+
| | | |
+----+----+ +-----+----+ +-----+----+ +----+----+
| Multi | | Policy | | Endpoint | | Threat |
| Tenancy | | | | groups | | feed |
+---------+ +-----+----+ +----------+ +---------+
^
|
+------+------+
| Rule |
+------+------+
^
|
+----------------+----------------+
| | |
+------+------+ +------+------+ +------+------+
| Event | | Condition | | Action |
+-------------+ +-------------+ +-------------+
Figure 1: Diagram for High-level Abstraction of Consumer-Facing
Interface
Data models are defined at a lower level of abstraction and provide Data models are defined at a lower level of abstraction and provide
many details. They provide details about the implementation of a many details. They provide details about the implementation of a
protocol's specification, e.g., rules that explain how to map managed protocol's specification, e.g., rules that explain how to map managed
objects onto lower-level protocol constructs. Since conceptual objects onto lower-level protocol constructs. Since conceptual
models can be implemented in different ways, multiple data models can models can be implemented in different ways, multiple data models can
be derived by a single information model. be derived by a single information model.
The efficient and flexible provisioning of network functions by NFV The efficient and flexible provisioning of network functions by NFV
leads to a rapid advance in the network industry. As practical leads to a rapid advance in the network industry. As practical
skipping to change at page 3, line 30 skipping to change at page 5, line 9
functions (VNF) in the NFV system. By the efficient virtual functions (VNF) in the NFV system. By the efficient virtual
technology, these VNFs might be automatically provisioned and technology, these VNFs might be automatically provisioned and
dynamically migrated based on real-time security requirements. This dynamically migrated based on real-time security requirements. This
document presents a YANG data model to implement security functions document presents a YANG data model to implement security functions
based on NFV. based on NFV.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC3444]. document are to be interpreted as described in RFC 2119 [RFC3444]
RFC8174 [RFC8174].
3. Terminology 3. Terminology
This document uses the terminology described in This document uses the terminology described in
[i2nsf-terminology][client-facing-inf-im][client-facing-inf-req]. [i2nsf-terminology][client-facing-inf-im][client-facing-inf-req].
4. Data Modeling for Security Policies for Consumer-Facing Interface This document follows the guidelines of [RFC6087], uses the common
YANG types defined in [RFC6991], and adopts the Network Management
Datastore Architecture (NMDA). The meaning of the symbols in tree
diagrams is defined in [RFC8340].
4. Information Model for Policy
A Policy object represents a mechanism to express a Security Policy
by Security Admin (i.e., I2NSF User) using Consumer-Facing Interface
toward Security Controller; the policy would be enforced on an NSF.
Figure 2 shows the XML instance of the Policy object. The Policy
object SHALL have following information:
Name: This field identifies the name of this object.
Date: Date when this object was created or last modified.
Rules: This field contains a list of rules. If the rule does not
have a user-defined precedence, then any conflict must be
manually resolved.
+--rw policy
+--rw policy-name? string
+--rw rule* [rule-name]
+--rw event
+--rw condition
+--rw action
Figure 2: Policy YANG Data tree
A policy is a container of Rules. In order to express a Rule, a Rule
must have complete information such as where and when a policy needs
to be applied. This is done by defining a set of managed objects and
relationship among them. A Policy Rule may be related segmentation,
threat mitigation or telemetry data collection from an NSF in the
network, which will be specified as the sub-model of the policy model
in the subsequent sections. Figure 3 shows the XML instance of the
Rule object. The rule object SHALL have the following information:
Name: This field identifies the name of this object.
Date: This field indicates the date when this object was created
or last modified.
Event: This field includes the information to determine whether
the Rule Condition can be evaluated or not. See details in
Section 3.1.
Condition: This field contains all the checking conditions to
apply to the objective traffic. See details in
Section 4.2.
Action: This field identifies the action taken when a rule is
matched. There is always an implicit action to drop
traffic if no rule is matched for a traffic type. See
details in Section 4.3.
Owner: This field contains the onwer of the rule. For example,
the person who created it, and eligible for modifying it.
+--rw rule* [rule-name]
+--rw rule-name string
+--rw date? yang:date-and-time
+--rw event* [name]
+--rw condition
+--rw action
+--rw owner? string
Figure 3: YANG Data tree for Rule
4.1. Event Sub-Model
The Event Object contains information related to scheduling a Rule.
The Rule could be activated based on a time calendar or security
event including threat level changes. Figure 4 shows the XML
instance of the Event object. Event object SHALL have following
information:
Name: This field identifies the name of this object.
Date: This field indicates the date when this object was created
or last modified.
Event-Type: This field identifies whether the event of triggering
policy enforcement is "ADMIN-ENFORCED", "TIME-ENFORCED" or
"EVENT-ENFORCED".
Time-Information: This field contains a time calendar such as
"BEGIN-TIME" and "END-TIME" for one time enforcement or
recurring time calendar for periodic enforcement.
+--rw event
+--rw name? string
+--rw date? yang:date-and-time
+--rw event-type enumeration
+--rw time-information
+--rw time
| +--rw begin-time begin-time-type
| +--rw end-time end-time-type
+--rw recursive
+--rw recur boolean
+--rw recursive-type? enumeration
Figure 4: Event sub-model YANG data tree
4.2. Condition Sub-Model
This object represents Conditions that Security Admin wants 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 sub-model
consists of 3 different types of three containers each representing
different cases, such as general firewall and ddos-mitigation cases,
and a case when the condition is based on the payload strings of
packets. Each containers have source-target and destination-target
to represent the source and destination for each case. Figure 5
shows the XML instance of the Condition object.The Condition submodel
SHALL have following information:
Firewall-condition: This field represents the general firewall
case, where a security admin can set up firewall conditions
using the information present in this field. The source
and destination is represented as source-target and
destination-target, each referring to the IP-address-based
groups defined in the endpoint-group.
DDoS-condition: This field represents the condition for DDoS
mitigation, where a security admin can set up DDoS
mitigation conditions using the information present in this
field. The source and destination is represented as
source-target and destination-target, each referring to the
device-groups defined and registered in the endpoint-group.
Custom-condition: This field contains the payload string
information. This information is useful when security rule
condition is based on the string contents of incoming or
outgoing packets. The source and destination is
represented as source-target and destination-target, each
referring to the payload-groups defined and registered in
the endpoint-group.
+--rw condition
+--rw firewall-condition
| +--rw source-target
| | +--rw src-target? -> /policy
| | /endpoint-group
| | /user-group
| | /name
| +--rw destination-target
| | +--rw dest-target* -> /policy
| | /endpoint-group
| | /user-group
| | /name
+--rw ddos-condition
| +--rw source-target
| | +--rw src-target* -> /policy
| | /endpoint-group
| | /device-group
| | /name
| +--rw destination-target
| | +--rw dest-target* -> /policy
| | /endpoint-group
| | /device-group
| | /name
| +--rw rate-limit
| +--rw packet-per-second? uint8
+--rw custom-condition
| +--rw source-target
| | +--rw src-target* -> /policy
| | /threat-prevention
| | /payload-content
| | /name
| +--rw destination-target
| | +--rw dest-target? -> /policy
| | /threat-prevention
| | /payload-content
| | /name
+--rw threat-feed-condition
+--rw source-target
| +--rw src-target* -> /policy
| /threat-prevention
| /threat-feed-list
| /name
+--rw destination-target
+--rw dest-target? -> /policy
/threat-prevention
/threat-feed-list
/name
Figure 5: Condition sub-model YANG data tree
4.3. Action Sub-Model
This object represents actions that Security Admin wants to perform
based on certain traffic class. Figure 6 shows the XML instance of
the Action object. The Action object SHALL have following
information:
Name: This field identifies the name of this object.
Date: This field indicates the date when this object was created
or last modified.
Action: This field identifies the action when a rule is matched
by an NSF. The action could be one of "PASS", "DROP",
"ALERT", "MIRROR", and "LOG".
+--rw action
+--rw name string
+--rw date yang:date-and-time
+--rw action string
Figure 6: Action sub-model YANG data tree
5. Information Model for Multi-Tenancy
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 any 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 XML instance of the Policy-domain object. Multi-tenancy model
should be able to work in all such environments. The Policy-Domain
object SHALL have following information:
Name: Name of the organization or customer representing this
domain.
Address: Address of the organization or customer.
Contact: Contact information of the organization or customer.
Date: Date when this account was created or last modified.
Authentication-Method: Authentication method to be used for this
domain. It should be a reference to a "Policy-Management-
Authentication-Method" object.
+--rw policy-domain* [name]
+--rw name string
+--rw date? yang:date-and-time
+--rw address? string
+--rw contact? string
+--rw policy-tenant* [name]
+--rw authentication-method? -> /policy
/multi-tenancy
/policy-mgnt-auth-method
/name
...
...
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 XML
instance of the Policy-tenant object. The Policy-Tenant object SHALL
have following information:
Name: Name of the Department or Division within an organization.
Date: Date when this account was created or last modified.
Domain: This field identifies the domain to which this tenant
belongs. This should be a reference to a Policy-Domain
object.
+--rw policy-tenant* [name]
+--rw name string
+--rw date? yang:date-and-time
+--rw domain? -> /policy
/multi-tenancy
/policy-domain
/name
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
XML instance of the Policy-role object. The Policy-Role object SHALL
have the following information:
Name: This field identifies the name of the role.
Date: Date when this role was created or last modified.
Access-Profile: This field identifies the access profile for the
role. The profile grants or denies the permissions to
access Endpoint Groups for the purpose of policy management
or may restrict certain operations related to policy
managements. There are two permission types, read-only and
read-and-write, to choose from for each access-profile.
+--rw policy-role
| +--rw name? string
| +--rw date? yang:date-and-time
| +--rw access-profile* [name]
| +--rw name string
| +--rw date? yang:date-and-time
| +--rw permission-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 XML instance of the Policy-user object. The Policy-User object
SHALL have the following information:
Name: Name of a user.
Date: Date when this user was created or last modified.
Password: User password for basic authentication.
Email: E-mail address of the user.
Scope-Type: This field identifies whether the user has domain-
wide or tenant-wide privileges.
Role: This field should be a reference to a Policy-Role object
that defines the specific permissions.
+--rw policy-user* [name]
| +--rw name string
| +--rw date? yang:date-and-time
| +--rw password? string
| +--rw email? string
| +--rw scope-type? identityref
| +--rw role? -> /policy
/multi-tenancy
/policy-role
/access-profile
/name
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 XML instance of the Policy
Management Authentication Method onject. This Policy-Management-
Authentication-Method object SHALL have the following information:
Name: This field identifies name of this object.
Date: Date when this object was created or last modified.
Authentication-Method: This field identifies the authentication
methods. It could be a password-based, token-based,
certificate-based or single sign-on authentication.
Mutual-Authentication: This field indicates whether mutual
authentication is mandatory or not.
Token-Server: This field stores the information about server that
validates the token submitted as credentials.
Certificate-Server: This field stores the information about
server that validates certificates submitted as
credentials.
Single Sign-on-Server: This field stores the information about
server that validates user credentials.
+--rw policy-mgnt-auth-method* [name]
+--rw name string
+--rw date? yang:date-and-time
+--rw mutual-authentication? boolean
+--rw password
| +--rw password? password-type
+--rw token
| +--rw token? string
| +--rw token-server? inet:ipv4-address
+--rw certificate
| +--rw certificate? certificate-type
| +--rw certificate-server? inet:ipv4-address
+--rw single-sign-on
+--rw credential? certificate-type
+--rw certificate-server? inet:ipv4-address
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-
construct based policies. Security Admin would create and use these
objects to represent a logical entity in their business environment,
where a Security Policy is to be applied. There are multiple managed
objects that constitute a Policy Endpoint Group as shown in
Figure 13. Figure 14 shows the XML instance of the endpoint-group
object. shows the XML instance of the User-group object.. This
section lists these objects and relationship among them.
+-------------------+
| Endpoint Group |
+---------+---------+
^
|
+--------------+----------------+
1..n | 1..n | 1..n |
+-----+----+ +------+-----+ +-------+------+
|User-group| |Device-group| |Location-group|
+----------+ +------------+ +--------------+
Figure 13: Endpoint Group Diagram
+--rw endpoint-group
+--rw user-group* [name]
| ...
+--rw device-group* [name]
| ...
+--rw location-group* [name]
...
Figure 14: Endpoint Group YANG data tree
6.1. User Group
This object represents a User-group. Figure 15 shows the XML
instance of the User-group object.The User-Group object SHALL have
the following information:
Name: This field identifies the name of this object.
Date: Date when this object was created or last modified.
IP-Address: This field identifies the IP address of a user.
Range-IP-Address: This field is a range of IP addresses of users.
+--rw user-group* [name]
+--rw name string
+--rw date? yang:date-and-time
+--rw (match-type)?
+--:(exact-match)
| +--rw ip-address* inet:ipv4-address
+--:(range-match)
+--rw range-ip-address* [start-ip-address end-ip-address]
+--rw start-ip-address inet:ipv4-address
+--rw end-ip-address inet:ip-address
Figure 15: User group YANG data tree
6.2. Device-Group
This object represents a Device-group. Figure 16 shows the XML
instance of the Device-group object.The Device-Group object SHALL
have the following information:
Name: This field identifies the name of this object.
Date: Date when this object was created or last modified.
IP-Address: This field identifies the IP address of a device.
Range-IP-Address: This field is a range of IP addresses of
devices.
+--rw device-group* [name]
+--rw name string
+--rw date? yang:date-and-time
+--rw (match-type)?
+--:(exact-match)
| +--rw ip-address* inet:ipv4-address
+--:(range-match)
+--rw range-ip-address* [start-ip-address end-ip-address]
+--rw start-ip-address inet:ipv4-address
+--rw end-ip-address inet:ip-address
Figure 16: Device group YANG data tree
6.3. Location-Group
This object represents a location group based on either tag or other
information. Figure 17 shows the XML instance of the Location-group
object. The Location-group object SHALL have the following
information:
Name: This field identifies the name of this object.
Date: Date when this object was created or last modified.
continent: to identify which continent the location group member
is based at.
+--rw location-group* [name]
+--rw name string
+--rw date? yang:date-and-time
+--rw continent? identityref
Figure 17: Location group YANG data tree
7. Information Model for Threat Prevention
The threat prevention plays an important part in the overall security
posture by reducing the attack surfaces. This information could come
from various threat feeds (i.e., sources for obtaining the threat
information), such as EmergingThreats.com or AlienVault.com. There
are multiple managed objects that constitute this category. This
section lists these objects and relationship among them. Figure 19
shows the XML instance of a Threat-prevention object.
+-------------------+
| Threat Prevention |
+---------+---------+
^
|
+---------+---------+
1..n | 1..n |
+------+------+ +--------+--------+
| Threat-feed | | payload-content |
+-------------+ +-----------------+
Figure 18: Threat Prevention Diagram
+--rw threat-prevention
| +--rw threat-feed-list* [name]
| ...
| +--rw payload-content* [name]
| ...
Figure 19: Threat Prevention YANG data tree
7.1. Threat-Feed
This object represents a threat feed which provides signatures of
malicious activities. Figure 20 shows the XML instance of a Threat-
feed-list. The Threat-Feed object SHALL have the following
information:
Name: This field identifies the name of this object.
Date: Date when this object was created or last modified.
Threat-feed-Server: This field identifies the information about
the feed provider, it may be an external service or local
server.
Threat-file-types: This field identifies the information about
the file types identified and reported by the threat-feed.
signatures: This field contains the signatures of malicious
programs or activities provided by the threat-feed.
+--rw threat-feed-list* [name]
+--rw name string
+--rw date? yang:date-and-time
+--rw threat-feed-server
| +--rw (match-type)?
| | +--:(exact-match)
| | | +--rw ip-address* inet:ipv4-address
| | +--:(range-match)
| | +--rw range-ip-address* [start-ip-address end-ip-address]
| | +--rw start-ip-address inet:ipv4-address
| | +--rw end-ip-address inet:ip-address
| +--rw threat-feed-description? string
+--rw threat-file-types* identityref
+--rw signatures* string
Figure 20: Threat feed YANG data tree
7.2. Payload-content
This object represents a custom list created for the purpose of
defining exception to threat feeds. Figure 21 shows the XML instance
of a Payload-content list. The Payload-content object SHALL have the
following information:
Name: This field identifies the name of this object.
Date: Date when this object was created or last modified.
List-Content: This field contains contents such as IP addresses
or URL names.
+--rw payload-content* [name]
| +--rw name string
| +--rw date? yang:date-and-time
| +--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.
+--------------+
| |
| User 1 + (has many)
| |\
+--------------+ \ +---------------+ +-------------+
. \ | | (has many) | |
. --->+ List of roles +----------->+ Permissions |
+--------------+ / | | | |
| | / +---------------+ +-------------+
| User n +/
| | (has many)
+--------------+
Figure 22: RBAC Diagram
As shown in Figure 22, a role represents a collection of permissions
(e.g., accessing a file server or other particular resources). A
role may be assigned to one or multiple users. Both roles and
permissions can be organized in a hirarchy. A role may consists of
other roles and permissions.
Following are the steps required to build RBAC:
1. Defining roles and permissions.
2. Establishing relations among roles and permissions.
3. Defining users.
4. Associating rules with roles and permissions.
5. assigning roles to users.
9. YANG Data Model for Security Policies for Consumer-Facing Interface
The main objective of this data model is to fully transform the The main objective of this data model is to fully transform the
information model [client-facing-inf-im] into a YANG data model that information model [client-facing-inf-im] into a YANG data model that
can be used for delivering control and management messages via the can be used for delivering control and management messages via the
Consumer-Facing Interface between an I2NSF User and Security Consumer-Facing Interface between an I2NSF User and Security
Controller for the I2NSF User's high-level security policies. Controller for the I2NSF User's high-level security policies.
The semantics of the data model must be aligned with the information The semantics of the data model must be aligned with the information
model of the Consumer-Facing Interface. The transformation of the model of the Consumer-Facing Interface. The transformation of the
information model was performed so that this YANG data model can information model was performed so that this YANG data model can
facilitate the efficient delivery of the control or management facilitate the efficient delivery of the control or management
messages. messages.
This data model is designed to support the I2NSF framework that can This data model is designed to support the I2NSF framework that can
be extended according to the security needs. In other words, the be extended according to the security needs. In other words, the
model design is independent of the content and meaning of specific model design is independent of the content and meaning of specific
policies as well as the implementation approach. This document policies as well as the implementation approach. This document
suggests a VoIP/VoLTE security service as a use case for policy rule suggests a VoIP/VoLTE security service as a use case for policy rule
generation. generation.
Multi-tenancy in this document 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 departments. Thus, we need an
object which defines a set of permissions assigned to a user in an
organization that wants to manage its own Security Policies. You can
think of it as a way to assign policy users to a job function or a
set of permissions within the organization. The policy-role object
SHALL have Name, Date and access-profile to grant or deny permissions
for the perpose of security policy management.
module: policy-general
+--rw policy
| +--rw rule* [rule-id]
| +--rw rule-id uint16
| +--rw name? string
| +--rw date? yang:date-and-time
| +--rw case? string
| +--rw event* [event-id]
| | +--rw event-id string
| | +--rw name? string
| | +--rw date? yang:date-and-time
| | +--rw event-type? string
| | +--rw time-information? string
| | +--rw event-map-group? -> /threat-feed/event-map-group
| | /event-map-group-id
| | +--rw enable? boolean
| +--rw condition* [condition-id]
| | +--rw condition-id string
| | +--rw source? string
| | +--rw destination? string
| | +--rw match? boolean
| | +--rw match-direction? string
| | +--rw exception? string
| +--rw policy-action* [policy-action-id]
| +--rw policy-action-id string
| +--rw name? string
| +--rw date? yang:date-and-time
| +--rw primary-action? string
| +--rw secondary-action? string
| +--rw owner? string
+--rw multi-tenancy
| +--rw policy-domain* [policy-domain-id]
| | +--rw policy-domain-id uint16
| | +--rw name string
| | +--rw address? string
| | +--rw contact string
| | +--rw date yang:date-and-time
| | +--rw policy-tenant* [policy-tenant-id]
| | | +--rw policy-tenant-id uint16
| | | +--rw name string
| | | +--rw date yang:date-and-time
| | | +--rw domain? -> /multi-tenancy
| | | /policy-domain
| | | /policy-domain-id
| | +--rw authentication-method? -> /multi-tenancy
| | /policy-mgnt-auth-method
| | /policy-mgnt-auth-method-id
| +--rw policy-role* [policy-role-id]
| | +--rw policy-role-id uint16
| | +--rw name string
| | +--rw date yang:date-and-time
| | +--rw access-profile string
| +--rw policy-user* [policy-user-id]
| | +--rw policy-user-id uint16
| | +--rw name string
| | +--rw date yang:date-and-time
| | +--rw password string
| | +--rw email string
| | +--rw scope-type? string
| | +--rw scope-reference? string
| | +--rw role string
| +--rw policy-mgnt-auth-method* [policy-mgnt-auth-method-id]
| +--rw policy-mgnt-auth-method-id uint16
| +--rw name string
| +--rw date yang:date-and-time
| +--rw authentication-method enumeration
| +--rw mutual-authentication boolean
| +--rw token-server inet:ipv4-address
| +--rw certificate-server inet:ipv4-address
| +--rw single-sing-on-server inet:ipv4-address
+--rw endpoint-group
| +--rw meta-data-source* [meta-data-source-id]
| | +--rw meta-data-source-id uint16
| | +--rw name string
| | +--rw date yang:date-and-time
| | +--rw tag-type? boolean
| | +--rw tag-server-information? inet:ipv4-address
| | +--rw tag-application-protocol? string
| | +--rw tag-server-credential? string
| +--rw user-group* [user-group-id]
| | +--rw user-group-id uint16
| | +--rw name? string
| | +--rw date? yang:date-and-time
| | +--rw group-type? enumeration
| | +--rw meta-data-server? inet:ipv4-address
| | +--rw group-member? string
| | +--rw risk-level? uint16
| +--rw device-group* [device-group-id]
| | +--rw device-group-id uint16
| | +--rw name? string
| | +--rw date? yang:date-and-time
| | +--rw group-type? enumeration
| | +--rw meta-data-server? inet:ipv4-address
| | +--rw group-member? string
| | +--rw risk-level? uint16
| +--rw application-group* [application-group-id]
| | +--rw application-group-id uint16
| | +--rw name? string
| | +--rw date? yang:date-and-time
| | +--rw group-type? enumeration
| | +--rw meta-data-server? inet:ipv4-address
| | +--rw group-member? string
| | +--rw risk-level? uint16
| +--rw location-group* [location-group-id]
| +--rw location-group-id uint16
| +--rw name? string
| +--rw date? yang:date-and-time
| +--rw group-type? enumeration
| +--rw meta-data-server? inet:ipv4-address
| +--rw group-member? string
| +--rw risk-level? uint16
+--rw threat-feed
| +--rw threat-feed* [threat-feed-id]
| | +--rw threat-feed-id uint16
| | +--rw name? string
| | +--rw date? yang:date-and-time
| | +--rw feed-type enumeration
| | +--rw feed-server? inet:ipv4-address
| | +--rw feed-priority? uint16
| +--rw custom-list* [custom-list-id]
| | +--rw custom-list-id uint16
| | +--rw name? string
| | +--rw date? yang:date-and-time
| | +--rw list-type enumeration
| | +--rw list-property enumeration
| | +--rw list-content? string
| +--rw malware-scan-group* [malware-scan-group-id]
| | +--rw malware-scan-group-id uint16
| | +--rw name? string
| | +--rw date? yang:date-and-time
| | +--rw signature-server? inet:ipv4-address
| | +--rw file-types? string
| | +--rw malware-signatures? string
| +--rw event-map-group* [event-map-group-id]
| +--rw event-map-group-id uint16
| +--rw name? string
| +--rw date? yang:date-and-time
| +--rw security-events? string
| +--rw threat-map? string
+--rw telemetry-data
+--rw telemetry-data* [telemetry-data-id]
| +--rw telemetry-data-id uint16
| +--rw name? string
| +--rw date? yang:date-and-time
| +--rw logs? boolean
| +--rw syslogs? boolean
| +--rw snmp? boolean
| +--rw sflow? boolean
| +--rw netflow? boolean
| +--rw interface-stats? boolean
+--rw telemetry-source* [telemetry-source-id]
| +--rw telemetry-source-id uint16
| +--rw name? string
| +--rw date? yang:date-and-time
| +--rw source-type? enumeration
| +--rw nsf-source? inet:ipv4-address
| +--rw nsf-credentials? string
| +--rw collection-interval? uint16
| +--rw collection-method? enumeration
| +--rw heartbeat-interval? uint16
| +--rw qos-marking? uint16
+--rw telemetry-destination* [telemetry-destination-id]
+--rw telemetry-destination-id uint16
+--rw name? string
+--rw date? yang:date-and-time
+--rw collector-source? inet:ipv4-address
+--rw collector-credentials? string
+--rw data-encoding? string
+--rw data-transport? enumeration
Figure 1: Generic Data Model for Security Policies for cf Interface
4.1. YANG Data Model for Security Policies for Consumer-Facing
Interface
This section describes a YANG data model for Consumer-Facing This section describes a YANG data model for Consumer-Facing
Interface, based on the information model of Consumer-Facing Interface, based on the information model of Consumer-Facing
Interface to security controller [client-facing-inf-im]. Interface to security controller [client-facing-inf-im].
<CODE BEGINS> file "policy-general.yang" <CODE BEGINS> file "ietf-cfi-policy.yang"
module ietf-policy-general { module ietf-i2nsf-cfi-policy {
yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-policy-general"; "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy";
prefix prefix
cf-interface; cfi-policy;
import ietf-yang-types{ import ietf-yang-types{
prefix yang; prefix yang;
reference
"Section 3 of RFC 6991";
} }
import ietf-inet-types{ import ietf-inet-types{
prefix inet; prefix inet;
reference
"Section 4 of RFC 6991";
} }
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 WG Chair: Adrian Farrel
<mailto:Adrain@olddog.co.uk> <mailto:Adrain@olddog.co.uk>
WG Chair: Linda Dunbar WG Chair: Linda Dunbar
<mailto:Linda.duhbar@huawei.com> <mailto:Linda.duhbar@huawei.com>
Editor: Jaehoon Paul Jeong Editor: Jaehoon Paul Jeong
<mailto:pauljeong@skku.edu>"; <mailto:pauljeong@skku.edu>";
description description
"This module defines a YANG data module for consumer-facing "This module is a YANG module for Consumer-Facing Interface.
interface to security controller."; Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision "2018-11-04"{ revision "2019-03-11"{
description "fourth revision"; description "latest revision";
reference reference
"draft-kumar-i2nsf-client-facing-interface-im-04"; "draft-ietf-consumer-facing-interface-dm-02";
} }
//Groupings identity permission-type {
container policy {
description description
"This object is a policy instance to have "Base identity for the permission types.";
complete information such as where and when }
a policy need to be applied.";
list rule { identity read-only {
key "rule-id"; base permission-type;
leaf rule-id { description
type uint16; "Identity for read-only permission.";
description }
"This is ID for rules."; identity read-and-write {
} base permission-type;
description description
"This is a container for rules."; "Identity for read permission.";
leaf name { }
type string;
description
"This field idenfifies the name of this object.";
}
leaf date {
type yang:date-and-time;
description
"Date this object was created or last
modified";
}
leaf case {
type string;
description
"to identify whether the rule belongs to
web filter or enterprise mode.";
}
list event {
key "event-id";
description
"This represents the security event of a
policy-rule.";
leaf event-id { identity scope-type {
type string; description
mandatory true; "Base Identity for scope-type.";
description }
"This represents the event-id."; identity tenant-wide {
} base scope-type;
leaf name { description
type string; "Base Identity for tenant-wide scope type.";
description }
"This field idenfifies the name of this object."; identity domain-wide {
} base scope-type;
leaf date { description
type yang:date-and-time; "Base Identity for domain-wide scope type.";
description }
"Date this object was created or last
modified";
}
leaf event-type {
type string;
description
"This field identifies the event of
policy enforcement trigger type.";
}
leaf time-information {
type string;
description
"This field contains time calendar such as
BEGIN-TIME and END-TIME for one time
enforcement or recurring time calendar for
periodic enforcement.";
}
leaf event-map-group {
type leafref {
path "/threat-feed/event-map-group/event-map-group-id";
}
description
"This field contains security events or threat
map in order to determine when a policy need
to be activated. This is a reference to
Evnet-Map-Group.";
}
leaf enable {
type boolean;
description
"This determines whether the condition
matches the security event or not.";
}
}
list condition {
key "condition-id";
description
"This represents the condition of a
policy-rule.";
leaf condition-id { identity malware-file-type {
type string; description
description "Base identity for malware file types.";
"This represents the condition-id."; }
} identity executable-file {
leaf source { base malware-file-type;
type string; description
description "Identity for executable file types.";
"This field identifies the source of }
the traffic. This could be reference to identity doc-file {
either 'Policy Endpoint Group' or base malware-file-type;
'Threat-Feed' or 'Custom-List' if Security description
Admin wants to specify the source; otherwise, "Identity for Microsoft document file types.";
the default is to match all traffic."; }
} identity html-app-file {
leaf destination { base malware-file-type;
type string; description
description "Identity for html application file types.";
"This field identifies the source of }
the traffic. This could be reference to identity javascript-file {
either 'Policy Endpoint Group' or base malware-file-type;
'Threat-Feed' or 'Custom-List' if Security description
Admin wants to specify the source; otherwise, "Identity for Javascript file types.";
the default is to match all traffic."; }
} identity pdf-file {
leaf match { base malware-file-type;
type boolean; description
description "Identity for pdf file types.";
"This field identifies the match criteria used to }
evaluate whether the specified action need to be identity dll-file {
taken or not. This could be either a Policy- base malware-file-type;
Endpoint-Group identifying a Application set or a description
set of traffic rules."; "Identity for dll file types.";
} }
leaf match-direction { identity msi-file {
type string; base malware-file-type;
description description
"This field identifies if the match criteria is "Identity for Microsoft installer file types.";
to evaluated for both direction of the traffic or }
only in one direction with default of allowing in
the other direction for stateful match conditions.
This is optional and by default rule should apply
in both directions.";
}
leaf exception {
type string;
description
"This field identifies the exception
consideration when a rule is evaluated for a
given communication. This could be reference to
Policy-Endpoint-Group object or set of traffic
matching criteria.";
}
}
list policy-action {
key "policy-action-id";
leaf policy-action-id {
type string;
mandatory true;
description
"this represents the policy-action-id.";
}
description
"This object represents actions that a
Security Admin wants to perform based on
a certain traffic class.";
leaf name { identity security-event-type {
type string; description
description "Base identity for security event types.";
"The name of the policy-action object."; }
} identity ddos {
leaf date { base malware-file-type;
type yang:date-and-time; description
description "Identity for DDoS event types.";
"When the object was created or last }
modified."; identity spyware {
} base malware-file-type;
leaf primary-action { description
type string; "Identity for spyware event types.";
}
identity trojan {
base malware-file-type;
description
"Identity for Trojan infection event types.";
}
identity ransomeware {
base malware-file-type;
description
"Identity for ransomeware infection event types.";
}
identity continent {
description
"Base Identity for continent types.";
}
identity africa {
base continent;
description
"Identity for africa.";
}
identity asia {
base continent;
description
"Identity for asia.";
}
identity europe {
base continent;
description
"Identity for europe.";
}
identity north-america {
base continent;
description
"Identity for north-america.";
}
identity south-america {
base continent;
description
"Identity for south-america.";
}
identity oceania {
base continent;
description
"Identity for Oceania";
}
typedef certificate-type {
type enumeration {
enum cer {
description description
"This field identifies the action when a rule "The extension type is '.cer'.";
is matched by NSF. The action could be one of
'PERMIT', 'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS',
'AUTHENTICATE-SESSION', 'IPS, 'APP-FIREWALL', etc.";
} }
leaf secondary-action { enum crt {
type string;
description description
"This field identifies additional actions if "The extension type is '.crt'.";
a rule is matched. This could be one of 'LOG',
'SYSLOG', 'SESSION-LOG', etc.";
} }
leaf owner { enum key {
type string;
description description
"This field defines the owner of this "The extension type is '.key'.";
policy. Only the owner is authorized to
modify the contents of the policy.";
} }
}
} }
} description
container multi-tenancy { "CRT certificate extension, which is used for certificates.
description The certificates may be encoded as binary DER or as ASCII PEM.
"The descriptions of multi-tenancy."; 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.";
}
list policy-domain { grouping meta {
key "policy-domain-id"; description
"The purpose of this grouping is to avoid repetition of same fields, such as 'name' and 'date'.";
leaf name {
type string;
description "This is the name for an entity.";
}
leaf date {
type yang:date-and-time;
description "This is the date when the entity is created or modified.";
}
}
leaf policy-domain-id { grouping ip-address {
type uint16; description
description "There are two types to configure a security policy
"This represents the list of domains."; 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 {
leaf-list ip-address {
type inet:ipv4-address;
description description
"this represent the list of policy domains"; "Exactly matches the IP address specified.";
leaf name {
type string;
mandatory true;
description
"Name of the organization or customer representing
this domain.";
}
leaf address {
type string;
description
"address of an organization or customer.";
}
leaf contact {
type string;
mandatory true;
description
"contact information of the organization
or customer.";
}
leaf date {
type yang:date-and-time;
mandatory true;
description
"The date when this account was created
or last modified.";
}
list policy-tenant {
key "policy-tenant-id";
leaf policy-tenant-id {
type uint16;
description
"The policy tenant id.";
}
description
"This represents the list of tenants";
leaf name {
type string;
mandatory true;
description
"Name of the Department or Division within
an organization.";
}
leaf date {
type yang:date-and-time;
mandatory true;
description
"Date this account was created or last modified.";
}
leaf domain {
type leafref {
path "/multi-tenancy/policy-domain/policy-domain-id";
}
description
"This field identifies the domain to which this
tenant belongs. This should be reference to a
'Policy-Domain' object.";
}
}
leaf authentication-method {
type leafref {
path "/multi-tenancy/policy-mgnt-auth-method/policy-mgnt-auth-method-id";
}
description
"Authentication method to be used for this domain.
It should be a reference to a 'policy-mgmt-auth-method'
object.";
}
} }
list policy-role { }
key "policy-role-id"; case range-match {
list range-ip-address {
leaf policy-role-id { key "start-ip-address end-ip-address";
type uint16; leaf start-ip-address {
mandatory true; type inet:ipv4-address;
description
"This defines a set of permissions assigned
to a user in an organization that want to manage
its own Security Policies.";
}
description
"This represents the list of policy roles.";
leaf name {
type string;
mandatory true;
description
"This field identifies name of the role.";
}
leaf date {
type yang:date-and-time;
mandatory true;
description description
"Date this role was created or last modified."; "Start IP address for a range match.";
} }
leaf access-profile { leaf end-ip-address {
type string; type inet:ip-address;
mandatory true;
description description
"This field identifies the access profile for the "End IP address for a range match.";
role. The profile grants or denies access to policy
objects. Multiple access profiles can be
concatenated together.";
}
}
list policy-user {
key "policy-user-id";
leaf policy-user-id {
type uint16;
description
"This represents the policy-user-id.";
} }
description description
"This represents the list of policy users."; "Range match for an IP-address.";
leaf name {
type string;
mandatory true;
description
"The name of a user.";
}
leaf date {
type yang:date-and-time;
mandatory true;
description
"Date this user was created or last modified";
}
leaf password {
type string;
mandatory true;
description
"User password for basic authentication";
}
leaf email {
type string;
mandatory true;
description
"The email account of a user";
}
leaf scope-type {
type string;
description
"identifies whether a user has domain-wide
or tenant-wide privileges";
}
leaf scope-reference {
type string;
description
"This references policy-domain or policy-tenant
to identify the scope.";
}
leaf role {
type string;
mandatory true;
description
"This references policy-role to define specific
permissions";
}
} }
list policy-mgnt-auth-method { }
key "policy-mgnt-auth-method-id"; }
}
leaf policy-mgnt-auth-method-id { grouping user-group {
type uint16; description
description "This grouping is to remove repetition of
"This represents the authentication method id."; 'name' and 'ip-address' fields.";
} uses meta;
description uses ip-address;
"The descriptions of policy management }
authentication methods.";
leaf name {
type string;
mandatory true;
description
"name of the authentication method";
}
leaf date {
type yang:date-and-time;
mandatory true;
description
"date when the authentication method
was created";
}
leaf authentication-method {
type enumeration{
enum password{
description
"password-based authentication.";
}
enum token{
description
"token-based authentication.";
}
enum certificate{
description
"certificate-based authentication.";
}
}
mandatory true;
description
"The description of authentication method;
token-based, password, certificate,
single-sign-on";
}
leaf mutual-authentication {
type boolean;
mandatory true;
description
"To identify whether the authentication
is mutual";
}
leaf token-server {
type inet:ipv4-address;
mandatory true;
description
"The token-server information if the
authentication method is token-based";
}
leaf certificate-server {
type inet:ipv4-address;
mandatory true;
description
"The certificate-server information if
the authentication method is certificate-based";
}
leaf single-sing-on-server {
type inet:ipv4-address;
mandatory true;
description
"The single-sign-on-server information
if the authentication method is
single-sign-on-based";
}
}
}
container endpoint-group {
description
"A logical entity in their business
environment, where a security policy
is to be applied.";
list meta-data-source { grouping device-group {
key "meta-data-source-id"; description
leaf meta-data-source-id { "This grouping is to remove repetition of
type uint16; 'name', 'ip-address', and 'protocol' fields.";
mandatory true; uses meta;
description uses ip-address;
"This represents the meta-data source id."; leaf-list protocol {
} type string;
description description
"This represents the meta-data source."; "This represents the port numbers of devices.";
}
}
leaf name { grouping location-group {
type string; description
mandatory true; "This grouping is to remove repetition of
description 'name' and 'continent' fields.";
"This identifies the name of the uses meta;
meta-datas-ource."; leaf continent {
} type identityref {
leaf date { base continent;
type yang:date-and-time;
mandatory true;
description
"This identifies the date this object was
created or last modified.";
}
leaf tag-type {
type boolean;
description
"This identifies the group type; user group,
app group or device group.";
}
leaf tag-server-information {
type inet:ipv4-address;
description
"The description of suthentication method;
token-based, password, certificate,
single-sign-on";
}
leaf tag-application-protocol {
type string;
description
"This filed identifies the protocol e.g. LDAP,
Active Directory, or CMDB";
}
leaf tag-server-credential {
type string;
description
"This field identifies the credential
information needed to access the tag server";
}
} }
list user-group{ description
key "user-group-id"; "location-group-based on geo-ip of
respective continent.";
}
leaf user-group-id { }
type uint16;
mandatory true;
description
"This represents the the user group id.";
}
description
"This represents the user group.";
leaf name { grouping payload-string {
type string; description
description "This grouping is to remove repetition of
"This field identifies the name of user-group."; 'name' and 'content' fields.";
} uses meta;
leaf date { leaf-list content {
type yang:date-and-time; type string;
description description
"when this user-group was created or last modified."; "This represents the payload string content.";
} }
leaf group-type { }
type enumeration{
enum user-tag{
description
"The user group is based on user-tag.";
}
enum user-name{
description
"The user group is based on user-name.";
}
enum ip-address{
description
"The user group is based on ip-address.";
}
}
description
"This describes the group type; User-tag,
User-name or IP-address.";
}
leaf meta-data-server {
type inet:ipv4-address;
description
"This references metadata source";
}
leaf group-member { container policy {
type string; leaf policy-name {
description type string;
"This describes the user-tag information"; description
} "The name which identifies the policy.";
}
description
"There can be a multiple number of security rules in
a policy object. This object is a policy instance to
have complete information such as where and when a
policy need to be applied.";
leaf risk-level { list rule {
type uint16; leaf rule-name {
description type string;
"This represents the threat level; valid range mandatory true;
may be 0 to 9."; description
} "This represents the name for rules.";
} }
list device-group { key "rule-name";
key "device-group-id"; description
leaf device-group-id { "There can be a single or multiple number of rules.";
type uint16;
description
"This represents a device group id.";
}
description
"This represents a device group.";
leaf name {
type string;
description
"This field identifies the name of
a device-group.";
} leaf date {
leaf date { type yang:date-and-time;
type yang:date-and-time; description
description "Date this object was created or last
"The date when this group was create or modified";
last modified."; }
} list event {
leaf group-type { uses meta;
type enumeration{ key "name";
enum device-tag{
description
"The device group is based on device-tag.";
}
enum device-name{
description
"The device group is based on device-name.";
}
enum ip-address{
description
"The device group is based on ip-address.";
}
}
description
"This describes the group type; device-tag,
device-name or IP-address.";
}
leaf meta-data-server {
type inet:ipv4-address;
description
"This references meta-data-source
object.";
}
leaf group-member {
type string;
description
"This describes the device-tag, device-name or
IP-address information";
}
leaf risk-level {
type uint16;
description
"This represents the threat level; valid range
may be 0 to 9.";
}
}
list application-group{
key "application-group-id";
leaf application-group-id {
type uint16;
description description
"This represents an application group id."; "This represents the event map group name.";
leaf security-event {
type identityref {
base security-event-type;
} }
description description
"This represents an application group."; "This contains the description of security events.";
leaf name {
type string;
description
"This field identifies the name of
an application group";
}
leaf date {
type yang:date-and-time;
description
"The date when this group was created or
last modified.";
}
leaf group-type {
type enumeration{
enum application-tag{
description
"The application group is based on application-tag.";
}
enum device-name{
description
"The application group is based on application-name.";
}
enum ip-address{
description
"The application group is based on ip-address.";
}
}
description
"This identifies the group type;
application-tag, application-name or
IP-address.";
}
leaf meta-data-server {
type inet:ipv4-address;
description
"This references meta-data-source
object.";
}
leaf group-member {
type string;
description
"This describes the application-tag,
application-name or IP-address information";
}
leaf risk-level {
type uint16;
description
"This represents the threat level; valid range
may be 0 to 9.";
}
} }
list location-group{ leaf enforce-type {
key "location-group-id"; type enumeration{
leaf location-group-id { enum admin-enforced {
type uint16; description
description "The enforcement type is admin-enforced.";
"This represents a location group id."; }
enum time-enforced {
description
"The enforcement type is time-enforced.";
}
enum event-enforced {
description
"The enforcement type is event-enforced.";
}
} }
description description
"This represents a location group."; "This field identifies the event of
policy enforcement trigger type.";
}
container time-information {
description
"The container for time-information.";
leaf begin-time {
type string;
description
"This is start time for time zone";
}
leaf end-time {
type string;
description
"This is end time for time zone";
}
}
container recursive {
description
"The container to represent the recursiveness
of the rule.";
leaf recur {
type boolean;
description
"recursive enforcement";
leaf name { }
type string; leaf recursive-type{
description type enumeration{
"This field identifies the name of enum daily {
a location group"; description
} "The recursive type is daily.";
leaf date { }
type yang:date-and-time; enum weekly {
description description
"The date when this group was created or "The recursive type is weekly.";
last modified."; }
} enum monthly {
leaf group-type { description
type enumeration{ "The recursive type is monthly.";
enum location-tag{ }
description }
"The location group is based on location-tag."; description
} "This leaf identifies the recursive type.";
enum location-name{ }
}
}
container condition {
description
"The conditions for general security policies.";
container firewall-condition {
description
"The general firewall condition.";
container source-target {
description description
"The location group is based on location-name."; "This represents the source.";
leaf src-target {
type leafref {
path "/policy/endpoint-group/user-group/name";
}
description
"This describes the paths to
the source reference.";
}
} }
enum ip-address{ container destination-target {
description description
"The location group is based on ip-address."; "This represents the destination.";
} leaf-list dest-target {
type leafref {
path "/policy/endpoint-group/user-group/name";
}
description
"This describes the paths to the
destination target reference.";
}
}
} }
description container ddos-condition {
"This identifies the group type; description
location-tag, location-name or "The condition for DDoS mitigation.";
IP-address."; container source-target {
}
leaf meta-data-server {
type inet:ipv4-address;
description
"This references meta-data-source
object.";
}
leaf group-member {
type string;
description
"This describes the location-tag,
location-name or IP-address information";
}
leaf risk-level {
type uint16;
description
"This represents the threat level; valid range
may be 0 to 9.";
}
}
}
container threat-feed {
description
"this describes the list of threat-feed.";
list threat-feed {
key "threat-feed-id";
leaf threat-feed-id {
type uint16;
mandatory true;
description
"This represents the threat-feed-id.";
}
description
"This represents the threat feed within the
threat-prevention-list.";
leaf name {
type string;
description
"Name of the theat feed.";
}
leaf date {
type yang:date-and-time;
description
"when the threat-feed was created.";
}
leaf feed-type {
type enumeration {
enum unknown {
description description
"feed-type is unknown."; "This represents the source.";
leaf-list src-target {
type leafref {
path "/policy/endpoint-group/device-group/name";
}
description
"This describes the path to the
source target references.";
}
} }
enum ip-address { container destination-target {
description description
"feed-type is IP address."; "This represents the target.";
leaf-list dest-target {
type leafref {
path "/policy/endpoint-group/device-group/name";
}
description
"This describes the path to the
destination target references.";
}
} }
enum url { container rate-limit {
description description "This describes the rate-limit.";
"feed-type is URL."; leaf packet-per-second {
type uint8;
description
"The rate-limit limits the amount of incoming packets.";
}
} }
} }
mandatory true; container custom-condition {
description description
"This determined whether the feed-type is IP address "The condition based on packet contents.";
based or URL based."; container source-target {
}
leaf feed-server {
type inet:ipv4-address;
description
"this contains threat feed server information.";
}
leaf feed-priority {
type uint16;
description
"this describes the priority of the threat from
0 to 5, where 0 means the threat is minimum and
5 meaning the maximum.";
}
}
list custom-list {
key "custom-list-id";
leaf custom-list-id {
type uint16;
description
"this describes the custom-list-id.";
}
description
"this describes the threat-prevention custom list.";
leaf name {
type string;
description
"Name of the custom-list.";
}
leaf date {
type yang:date-and-time;
description
"when the custom list was created.";
}
leaf list-type {
type enumeration {
enum unknown {
description
"list-type is unknown.";
}
enum ip-address {
description
"list-type is IP address.";
}
enum mac-address {
description description
"list-type is MAC address."; "This represents the source.";
leaf-list src-target {
type leafref {
path "/policy/threat-prevention/payload-content/name";
}
description
"Describes the payload string
content condition source.";
}
} }
enum url { container destination-target {
description description
"list-type is URL."; "This represents the destination.";
leaf dest-target {
type leafref {
path "/policy/threat-prevention/payload-content/name";
}
description
"Describes the payload string
content condition destination.";
}
} }
} }
mandatory true; container threat-feed-condition {
description description
"This determined whether the feed-type is IP address "The condition based on the threat-feed information.";
based or URL based."; container source-target {
}
leaf list-property {
type enumeration {
enum unknown {
description
"list-property is unknown.";
}
enum blacklist {
description description
"list-property is blacklist."; "This represents the source.";
leaf-list src-target {
type leafref {
path "/policy/threat-prevention/threat-feed-list/name";
}
description "Describes the threat-feed
condition source.";
}
} }
enum whitelist { container destination-target {
description description
"list-property is whitelist."; "This represents the destination.";
leaf dest-target {
type leafref {
path "/policy/threat-prevention/threat-feed-list/name";
}
description "Describes the threat-feed
condition destination.";
}
} }
} }
mandatory true;
description
"This determined whether the list-type is blacklist
or whitelist.";
}
leaf list-content {
type string;
description
"This describes the contents of the custom-list.";
}
} }
list malware-scan-group { container action {
key "malware-scan-group-id"; description
leaf malware-scan-group-id { "This is the action container.";
type uint16; leaf primary-action {
type string;
mandatory true; mandatory true;
description description
"This is the malware-scan-group-id."; "This field identifies the action when a rule
} is matched by NSF. The action could be one of
'PERMIT', 'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS',
'AUTHENTICATE-SESSION', 'IPS, 'APP-FIREWALL', etc.";
}
leaf secondary-action {
type string;
description description
"This represents the malware-scan-group."; "This field identifies additional actions if
leaf name { a rule is matched. This could be one of 'LOG',
type string; 'SYSLOG', 'SESSION-LOG', etc.";
description }
"Name of the malware-scan-group.";
}
leaf date {
type yang:date-and-time;
description
"when the malware-scan-group was created.";
}
leaf signature-server {
type inet:ipv4-address;
description
"This describes the signature server of the
malware-scan-group.";
}
leaf file-types {
type string;
description
"This contains a list of file types needed to
be scanned for the virus.";
}
leaf malware-signatures {
type string;
description
"This contains a list of malware signatures or hash.";
}
} }
list event-map-group { leaf owner {
key "event-map-group-id"; type string;
leaf event-map-group-id {
type uint16;
mandatory true;
description
"This is the event-map-group-id.";
}
description description
"This represents the event map group."; "This field defines the owner of this
policy. Only the owner is authorized to
leaf name { modify the contents of the policy.";
type string;
description
"Name of the event-map.";
}
leaf date {
type yang:date-and-time;
description
"when the event-map was created.";
}
leaf security-events {
type string;
description
"This contains a list of security events.";
}
leaf threat-map {
type string;
description
"This contains a list of threat levels.";
}
} }
} }
container telemetry-data {
description
"Telemetry provides visibility into the network
activities which can be tapped for further
security analytics, e.g., detecting potential
vulnerabilities, malicious activities, etc.";
list telemetry-data { container multi-tenancy {
key "telemetry-data-id"; description
"The multi-tenant environment information
in which the policy is applied. The Rules
in the Policy can refer to sub-objects
(e.g., domain, tenant, role, and user) of it.";
leaf telemetry-data-id { list policy-domain {
type uint16; uses meta;
mandatory true; key "name";
leaf address {
type string;
description description
"This is ID for telemetry-data-id."; "The address details of the organization
} or customer.";
}
leaf contact {
type string;
description description
"This is ID for telemetry-data."; "contact information of the organization
leaf name { or customer.";
type string; }
list policy-tenant {
uses meta;
key "name";
description
"This represents the list of tenants";
leaf domain {
type leafref {
path "/policy/multi-tenancy/policy-domain/name";
}
description description
"Name of the telemetry-data object."; "This field identifies the domain to which this
tenant belongs. This should be reference to a
'Policy-Domain' object.";
} }
leaf date { }
type yang:date-and-time; leaf authentication-method {
description type leafref {
"This field states when the telemery-data path "/policy/multi-tenancy/policy-mgnt-auth-method/name";
object was created.";
} }
leaf logs { description
type boolean; "Authentication method to be used for this domain.
It should be a reference to a 'policy-mgmt-auth-method'
object.";
}
description
"This represents the list of policy domains.";
}
container policy-role {
uses meta;
description
"This represents the list of policy roles.";
list access-profile {
uses meta;
key "name";
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;
}
default read-only;
description description
"This field identifies whether logs "Permission type for access-profile: read-only
need to be collected."; or read-and-write.";
} }
leaf syslogs { }
type boolean; }
description list policy-user {
"This field identifies whether System logs uses meta;
need to be collected."; key "name";
description
"This represents the policy users.";
leaf password {
type string;
description
"User password for basic authentication";
}
leaf email {
type string;
description
"The email account of a user";
}
leaf scope-type {
type identityref {
base scope-type;
} }
leaf snmp { default tenant-wide;
type boolean; description
description "identifies whether a user has domain-wide
"This field identifies whether 'SNMP traps' and or tenant-wide privileges";
'SNMP alarms' need to be collected."; }
leaf role {
type leafref {
path "/policy/multi-tenancy/policy-role/access-profile/name";
} }
leaf sflow { description
type boolean; "This represents the reference to the
access-profiles.";
}
}
list policy-mgnt-auth-method {
uses meta;
key "name";
leaf mutual-authentication {
type boolean;
description description
"This field identifies whether 'sFlow' data "To identify whether the authentication
need to be collected."; is mutual.";
} }
leaf netflow { container password {
type boolean; leaf password {
type string;
description description
"This field identifies whether 'NetFlow' data "This should be defined using the
need to be collected."; regular expression.";
} }
leaf interface-stats { description
type boolean; "This represents the password method.";
}
container token {
leaf token {
type string;
description description
"This field identifies whether 'Interface' data "This should be defined according to
such as packet bytes and counts need to be the token scheme.";
collected.";
} }
}
list telemetry-source {
key "telemetry-source-id";
leaf telemetry-source-id {
type uint16;
mandatory true;
description description
"This is ID for telemetry-source-id."; "This represents the token method.";
leaf token-server {
type inet:ipv4-address;
description
"The token-server information if the
authentication method is token-based";
}
} }
container certificate {
description description
"This is ID for telemetry-source."; "This represents the certificate method.";
leaf name { leaf certificate {
type string; type certificate-type;
description description
"This identifies the name of this object."; "This represents the certificate-type.";
} }
leaf date { leaf certificate-server {
type yang:date-and-time; type inet:ipv4-address;
description description
"Date this object was created or last modified"; "The certificate-server information if
the authentication method is
certificate-based";
} }
leaf source-type { }
type enumeration { container single-sign-on {
enum network-nsf { description
description "This represents the authentication method
"NSF telemetry source type is network-nsf."; for single-sing-on.";
} leaf credential {
type certificate-type;
enum firewall-nsf {
description
"NSF telemetry source type is firewall-nsf.";
}
enum ids-nsf {
description
"NSF telemetry source type is ids-nsf.";
}
enum ips-nsf {
description
"NSF telemetry source type is ips-nsf.";
}
enum proxy-nsf {
description
"NSF telemetry source type is proxy-nsf.";
}
enum other-nsf {
description
"NSF telemetry source type is other-nsf.";
}
}
description description
"This should have one of the following type of "This represents the authentication
the NSF telemetry source: NETWORK-NSF, using user credentials.";
FIREWALL-NSF, IDS-NSF, IPS-NSF,
PROXY-NSF, VPN-NSF, DNS, ACTIVE-DIRECTORY,
IP Reputation Authority, Web Reputation
Authority, Anti-Malware Sandbox, Honey Pot,
DHCP, Other Third Party, ENDPOINT";
} }
leaf nsf-source { leaf certificate-server {
type inet:ipv4-address; type inet:ipv4-address;
description description
"This field contains information such as "The certificate-server information if
IP address and protocol (UDP or TCP) port the authentication method is
number of the NSF providing telemetry data."; certificate-based";
} }
leaf nsf-credentials { }
type string; description
"This represents the policy managegement method.";
}
}
container endpoint-group {
description
"A logical entity in their business
environment, where a security policy
is to be applied.";
list user-group {
uses user-group;
key "name";
description description
"This field contains username and password "This represents the user group.";
to authenticate with the NSF.";
} }
leaf collection-interval { list device-group {
type uint16; uses device-group;
units seconds; key "name";
default 5000;
description description
"This field contains time in milliseconds "This represents the device group.";
between each data collection. For example,
a value of 5000 means data is streamed to
collector every 5 seconds. Value of 0 means
data streaming is event-based";
} }
leaf collection-method { list location-group{
type enumeration { uses location-group;
enum unknown { key "name";
description
"collection-method is unknown.";
}
enum push-based {
description
"collection-method is PUSH-based.";
}
enum pull-based {
description
"collection-method is PULL-based.";
}
}
description description
"This field contains a method of collection, "This represents the location group.";
i.e., whether it is PUSH-based or PULL-based.";
} }
leaf heartbeat-interval {
type uint16; }
units seconds; container threat-prevention {
description
"this describes the list of threat-prevention.";
list threat-feed-list {
uses meta;
key "name";
description description
"time in seconds the source sends telemetry "This represents the threat feed list.";
heartbeat."; container threat-feed-server {
} uses ip-address;
leaf qos-marking {
type uint16;
description description
"DSCP value must be contained in this field."; "This describes the threat-feed server.";
leaf threat-feed-description {
type string;
description
"This object containes threat-feed
description.";
}
} }
} leaf-list threat-file-types {
list telemetry-destination { type identityref {
key "telemetry-destination-id"; base malware-file-type;
}
leaf telemetry-destination-id { default executable-file;
type uint16; description
description "This contains a list of file types needed to
"this represents the telemetry-destination-id"; be scanned for the virus.";
} }
description leaf-list signatures {
"This object contains information related to
telemetry destination. The destination is
usually a collector which is either a part of
Security Controller or external system
such as Security Information and Event
Management (SIEM).";
leaf name {
type string; type string;
description description
"This identifies the name of this object."; "This contains a list of signatures or hash
of the threats.";
} }
leaf date { }
type yang:date-and-time; list payload-content {
uses payload-string;
key "name";
description description
"Date this object was created or last "This represents the payload-string group.";
modified";
}
leaf collector-source {
type inet:ipv4-address;
description
"This field contains information such as
IP address and protocol (UDP or TCP) port
number for the collector's destination.";
}
leaf collector-credentials {
type string;
description
"This field contains the username and
password for the collector.";
}
leaf data-encoding {
type string;
description
"This field contains the telemetry data encoding
in the form of schema.";
}
leaf data-transport {
type enumeration{
enum grpc {
description
"telemetry data protocol is grpc.";
}
enum buffer-over-udp{
description
"telemetry data protocol is buffer over UDP.";
}
}
description
"This field contains streaming telemetry data
protocols. This could be gRPC, protocol
buffer over UDP, etc.";
}
} }
} }
} }
}
<CODE ENDS> <CODE ENDS>
Figure 2: YANG for policy-general Figure 23: YANG for policy-general
5. Use Case: Policy Instance Example for VoIP/VoLTE Security Services
A common scenario for VoIP/VoLTE policy enforcement could be that a
malicious call is made to a benign user of any telecommunication
company. For example, imagine a case wherea company "A" employs a
hacker with a malicious attempt to hack a user's phone with malware.
The company "A" is located in a country, such as Africa, and uses the
user's hacked phone to call the company. The hacked user is unaware
of the company "A" so complains about the international call that was
made to the company "B", which is the user's telecommunications
company. The company "A" charges the company "B" for the
international call. The company "B" cannot charge the user for the
call, and has no choice but to pay the company "A". The following
shows the example data tree model for the VoIP/VoLTE services.
Multi-tenancy, endpoint groups, threat prevention, and telemetry data
components are general part of the tree model, so we can just modify
the policy instance in order to generate and enforce high-level
policies. The policy-calendar can act as a scheduler to set the star
and end time to block calls which uses suspicious ids, or calls from
other countries.
module: policy-voip
+--rw policy-voip
| +--rw rule-voip* [rule-voip-id]
| | +--rw rule-voip-id uint16
| | +--rw name? string
| | +--rw date? yang:date-and-time
| | +--rw event* [event-id]
| | | +--rw event-id string
| | | +--rw name? string
| | | +--rw date? yang:date-and-time
| | | +--rw event-type? string
| | | +--rw Time-Information? string
| | | +--rw event-map-group? -> /threat-feed/event-map-group
| | | /event-map-group-id
| | | +--rw enable? boolean
| | +--rw condition* [condition-id]
| | | +--rw condition-id string
| | | +--rw source-caller? -> /threat-feed/threat-feed
| | | /threat-feed-id
| | | +--rw destination-callee? -> /threat-feed/custom-list
| | | /custom-list-id
| | | +--rw match? boolean
| | | +--rw match-direction? string
| | | +--rw exception? string
| | +--rw action* [action-id]
| | | +--rw action-id string
| | | +--rw name? string
| | | +--rw date? yang:date-and-time
| | | +--rw primary-action? string
| | | +--rw secondary-action? string
| | +--rw precedence? uint16
| +--rw owner* [owner-id]
| +--rw owner-id string
| +--rw name? string
| +--rw date? yang:date-and-time
+--rw threat-feed
+--rw threat-feed* [threat-feed-id]
| +--rw threat-feed-id uint16
| +--rw name? string
| +--rw date? yang:date-and-time
| +--rw feed-type enumeration
| +--rw feed-server? inet:ipv4-address
| +--rw feed-priority? uint16
+--rw custom-list* [custom-list-id]
| +--rw custom-list-id uint16
| +--rw name? string
| +--rw date? yang:date-and-time
| +--rw list-type enumeration
| +--rw list-property enumeration
| +--rw list-content? string
+--rw malware-scan-group* [malware-scan-group-id]
| +--rw malware-scan-group-id uint16
| +--rw name? string
| +--rw date? yang:date-and-time
| +--rw signature-server? inet:ipv4-address
| +--rw file-types? string
| +--rw malware-signatures? string
+--rw event-map-group* [event-map-group-id]
+--rw event-map-group-id uint16
+--rw name? string
+--rw date? yang:date-and-time
+--rw security-events? string
+--rw threat-map? string
Figure 3: Policy Instance Example for VoIP/VoLTE Security Services
5.1. Policy Instance YANG Example for VoIP/VoLTE Security Services
The following YANG data model is a policy instance for VoIP/VoLTE
security services. The policy-calendar can act as a scheduler to set
the start time and end time to block malicious calls which use
suspicious IDs, or calls from other countries.
<CODE BEGINS> file "ietf-i2nsf-cf-interface-voip.yang"
module ietf-policy-voip {
namespace
"urn:ietf:params:xml:ns:yang:ietf-policy-voip";
prefix
"cf-interface";
import ietf-yang-types{
prefix yang;
}
import ietf-inet-types{
prefix inet;
}
organization
"IETF I2NSF (Interface to Network Security Functions)
Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org>
WG Chair: Adrian Farrel
<mailto:Adrain@olddog.co.uk>
WG Chair: Linda Dunbar
<mailto:Linda.duhbar@huawei.com>
Editor: Jaehoon Paul Jeong
<mailto:pauljeong@skku.edu>";
description
"This module defines a YANG data module for consumer-facing
interface to security controller.";
revision "2018-11-04"{
description "sixth revision";
reference
"draft-kumar-i2nsf-client-facing-interface-im-07";
}
container policy-voip {
description
"This object is a policy instance to have
complete information such as where and when
a policy need to be applied.";
list rule-voip {
key "rule-voip-id";
leaf rule-voip-id {
type uint16;
mandatory true;
description
"This is ID for rules.";
}
description
"This is a container for rules.";
leaf name {
type string;
description
"This field idenfifies the name of this object.";
}
leaf date {
type yang:date-and-time;
description
"Date this object was created or last
modified";
}
list event {
key "event-id";
description
"This represents the security event of a
policy-rule.";
leaf event-id {
type string;
mandatory true;
description
"This represents the event-id.";
}
leaf name {
type string;
description
"This field idenfifies the name of this object.";
}
leaf date {
type yang:date-and-time;
description
"Date this object was created or last
modified";
}
leaf event-type {
type string;
description
"This field identifies the event event type
.";
}
leaf Time-Information {
type string;
description
"This field contains time calendar such as
BEGIN-TIME and END-TIME for one time
enforcement or recurring time calendar for
periodic enforcement.";
}
leaf event-map-group {
type leafref{
path "/threat-feed/event-map-group/event-map-group-id";
}
description
"This field contains security events or threat
map in order to determine when a policy need
to be activated. This is a reference to
Evnet-Map-Group.";
}
leaf enable {
type boolean;
description
"This determines whether the condition
matches the security event or not.";
}
}
list condition {
key "condition-id";
description
"This represents the condition of a
policy-rule.";
leaf condition-id {
type string;
description
"This represents the condition-id.";
}
leaf source-caller {
type leafref {
path "/threat-feed/threat-feed/threat-feed-id";
}
description
"This field identifies the source of
the traffic. This could be reference to
either 'Policy Endpoint Group' or
'Threat-Feed' or 'Custom-List' if Security
Admin wants to specify the source; otherwise,
the default is to match all traffic.";
}
leaf destination-callee {
type leafref {
path "/threat-feed/custom-list/custom-list-id";
}
description
"This field identifies the source of
the traffic. This could be reference to
either 'Policy Endpoint Group' or
'Threat-Feed' or 'Custom-List' if Security
Admin wants to specify the source; otherwise,
the default is to match all traffic.";
}
leaf match {
type boolean;
description
"This field identifies the match criteria used to
evaluate whether the specified action need to be
taken or not. This could be either a Policy-
Endpoint-Group identifying a Application set or a
set of traffic rules.";
}
leaf match-direction {
type string;
description
"This field identifies if the match criteria is
to evaluated for both direction of the traffic or
only in one direction with default of allowing in
the other direction for stateful match conditions.
This is optional and by default rule should apply
in both directions.";
}
leaf exception {
type string;
description
"This field identifies the exception
consideration when a rule is evaluated for a
given communication. This could be reference to
Policy-Endpoint-Group object or set of traffic
matching criteria.";
}
}
list action {
key "action-id";
leaf action-id {
type string;
mandatory true;
description
"this represents the policy-action-id.";
}
description
"This object represents actions that a
Security Admin wants to perform based on
a certain traffic class.";
leaf name {
type string;
description
"The name of the policy-action object.";
}
leaf date {
type yang:date-and-time;
description
"When the object was created or last
modified.";
}
leaf primary-action {
type string;
description
"This field identifies the action when a rule
is matched by NSF. The action could be one of
'PERMIT', 'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS',
'AUTHENTICATE-SESSION', 'IPS, 'APP-FIREWALL', etc.";
}
leaf secondary-action {
type string;
description
"This field identifies additional actions if
a rule is matched. This could be one of 'LOG',
'SYSLOG', 'SESSION-LOG', etc.";
}
}
leaf precedence {
type uint16;
description
"This field identifies the precedence
assigned to this rule by Security Admin.
This is helpful in conflict resolution
when two or more rules match a given
traffic class.";
}
}
list owner {
key "owner-id";
leaf owner-id {
type string;
mandatory true;
description
"this represents the owner-id.";
}
description
"This field defines the owner of this policy.
Only the owner is authorized to modify the
contents of the policy.";
leaf name {
type string;
description
"The name of the owner.";
}
leaf date {
type yang:date-and-time;
description
"When the object was created or last
modified.";
}
}
}
container threat-feed {
description
"this describes the list of threat-feed.";
list threat-feed {
key "threat-feed-id";
leaf threat-feed-id {
type uint16;
mandatory true;
description
"This represents the threat-feed-id.";
}
description
"This represents the threat feed within the
threat-prevention-list.";
leaf name {
type string;
description
"Name of the theat feed.";
}
leaf date { 10. Example XML Output for Various Scenarios
type yang:date-and-time;
description
"when the threat-feed was created.";
}
leaf feed-type { This section describes the XML instances for different policies
type enumeration { examples that are delivered through Consumer-Facing Interface. The
enum unknown { considered use cases are: VoIP/VoLTE security service, DDoS-attack
description mitigation, time-based firewall as a web-filter.
"feed-type is unknown.";
}
enum ip-address {
description
"feed-type is IP address.";
}
enum url {
description
"feed-type is URL.";
}
}
mandatory true;
description
"This determined whether the feed-type is IP address
based or URL based.";
}
leaf feed-server { 10.1. DB registration: Information of positions and devices (Endpoint
type inet:ipv4-address; group)
description
"this contains threat feed server information.";
}
leaf feed-priority { In order to create a rule of a security policy, it is essential to
type uint16; first register data (those which are used to form such rule) to the
description database. For example, The endpoint group consists of three
"this describes the priority of the threat from different groups: user-group, device-group, and payload-group. Each
0 to 5, where 0 means the threat is minimum and of these groups have separate group members with information other
5 meaning the maximum."; than meta ("name" or "date"), such as ip-addresses or protocols used
} by devices. Figure 24 shows an example XML representation of the
} registered information for the user-group and device-group.
list custom-list {
key "custom-list-id";
leaf custom-list-id {
type uint16;
description
"this describes the custom-list-id.";
}
description
"this describes the threat-prevention custom list.";
leaf name {
type string;
description
"Name of the custom-list.";
}
leaf date { <?xml version="1.0" encoding="UTF-8" ?>
type yang:date-and-time; <ietf-i2nsf-cfi-policy:endpoint-group>
description <user-group>
"when the custom list was created."; <name>employees</name>
} <range-ip-address>
<start-ip-address>221.159.112.1</start-ip-address>
<end-ip-address>221.159.112.90</end-ip-address>
</range-ip-address>
</user-group>
<device-group>
<name>webservers</name>
<range-ip-address>
<start-ip-address>221.159.112.91</start-ip-address>
<end-ip-address>221.159.112.97</end-ip-address>
</range-ip-address>
<protocol>http</protocol>
<protocol>https</protocol>
</device-group>
</ietf-i2nsf-cfi-policy:endpoint-group>
leaf list-type { Figure 24: Registering user-group and device-group information
type enumeration {
enum unknown {
description
"list-type is unknown.";
}
enum ip-address {
description
"list-type is IP address.";
}
enum mac-address {
description
"list-type is MAC address.";
}
enum url {
description
"list-type is URL.";
}
}
mandatory true;
description
"This determined whether the feed-type is IP address
based or URL based.";
}
leaf list-property {
type enumeration {
enum unknown {
description
"list-property is unknown.";
}
enum blacklist {
description
"list-property is blacklist.";
}
enum whitelist {
description
"list-property is whitelist.";
}
}
mandatory true;
description
"This determined whether the list-type is blacklist
or whitelist.";
}
leaf list-content { 10.2. Scenario 1: Block SNS access during business hours
type string;
description
"This describes the contents of the custom-list.";
}
}
list malware-scan-group {
key "malware-scan-group-id";
leaf malware-scan-group-id {
type uint16;
mandatory true;
description
"This is the malware-scan-group-id.";
}
description
"This represents the malware-scan-group.";
leaf name {
type string;
description
"Name of the malware-scan-group.";
}
leaf date { The first example scenario is to "block SNS access during business
type yang:date-and-time; hours" using a time-based firewall policy. In this scenario, all
description users registered as "employee" in the user-group list are unable to
"when the malware-scan-group was created."; access Social Networking Services (SNS) during the office hours. The
} XML instance is described below:
leaf signature-server { <?xml version="1.0" encoding="UTF-8" ?>
type inet:ipv4-address; <ietf-i2nsf-cfi-policy:policy>
description <policy-name>security_policy_for_blocking_sns</policy-name>
"This describes the signature server of the <rule>
malware-scan-group."; <rule-name>block_access_to_sns_during_office_hours</rule-name>
} <event>
<time-information>
<begin-time>09:00</begin-time>
<end-time>18:00</end-time>
</time-information>
</event>
<condition>
<firewall-condition>
<source-target>
<src-target>employees</src-target>
</source-target>
</firewall-condition>
<custom-condition>
<destination-target>
<dest-target>sns-websites</dest-target>
</destination-target>
</custom-condition>
</condition>
<action>
<primary-action>drop</primary-action>
</action>
</rule>
</ietf-i2nsf-cfi-policy:policy>
leaf file-types { Figure 25: An XML Example for Time-based Firewall
type string;
description
"This contains a list of file types needed to
be scanned for the virus.";
}
leaf malware-signatures { Time-based-condition Firewall
type string;
description
"This contains a list of malware signatures or hash.";
}
}
list event-map-group {
key "event-map-group-id";
leaf event-map-group-id {
type uint16;
mandatory true;
description
"This is the event-map-group-id.";
}
description
"This represents the event map group.";
leaf name {
type string;
description
"Name of the event-map.";
}
leaf date { 1. The policy name is "security_policy_for_blocking_sns".
type yang:date-and-time;
description
"when the event-map was created.";
}
leaf security-events { 2. The rule name is "block_access_to_sns_during_office_hours".
type string;
description
"This contains a list of security events.";
}
leaf threat-map { 3. The Source-target is "employees".
type string;
description
"This contains a list of threat levels.";
}
}
}
}
<CODE ENDS>
Figure 4: Policy Instance YANG Example for VoIP Security Services 4. The destination target is "sns-websites". "sns-websites" is the
key which represents the list containing the information, such as
URL, about sns-websites.
6. Example XML Output for Various Use Cases 5. The action required is to "drop" any attempt to connect to
websites related to Social networking.
In this section, we present an XML example for various use cases. 10.3. Scenario 2: Block malicious VoIP/VoLTE packets coming to the
Here, we show the policy examples that can be delivered through company
consumer-facing interface. For now, the considered use cases are:
VoIP security service, DDoS-attack mitigation, time-based firewall,
and web-filter.
6.1. Case 1: VoIP Security Service The second example scenario is to "block malicious VoIP/VoLTE packets
coming to the company" using a VoIP policy. In this scenario, the
calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that
are classified as malicious are dropped. The IP addresses of 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
cases assume that the security administrators or someone responsible
for the existing and newly generated policies, are not aware of which
and/or how many NSFs are needed to meet the security requirements.
Figure 26 represents the XML document generated from YANG discussed
in previous sections. Once a high-level seucurity policy is created
by a security admin, it is delivered by the Consumer-Facing
Interface, through RESTCONF server, to the security controller. The
XML instance is described below:
The first example is a VoIP policy. Here, we are going to drop calls <?xml version="1.0" encoding="UTF-8" ?>
commin from a country with an Ip from South Africa that is classified <ietf-i2nsf-cfi-policy:policy>
as malicious. The below figure shows the XML document generated by <policy-name>security_policy_for_blocking_malicious_voip_packets</policy-name>
using the YANG data tree as shown in the previous section. <rule>
<rule-name>Block_malicious_voip_and_volte_packets</rule-name>
<condition>
<custom-condition>
<source-target>
<src-target>malicious-id</src-target>
</source-target>
</custom-condition>
<firewall-condition>
<destination-target>
<dest-target>employees</dest-target>
</destination-target>
</firewall-condition>
</condition>
<action>
<primary-action>drop</primary-action>
</action>
</rule>
</ietf-i2nsf-cfi-policy:policy>
<?xml version="1.1" encoding="UTF-8"?> Figure 26: An XML Example for VoIP Security Service
<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<i2nsf-cf-interface-voip-req nc:operation="create">
<policy-voip>
<rule-voip>
<rule-voip-id>01</rule-voip-id>
<rule-voip-name>voip-policy-example</rule-voip-name>
<rule-voip-date>2017.10.25/20:30:32</rule-voip-date>
<event>
<event-id>01</event-id>
<event-name>voip_call</event-name>
<event-date>2017.10.25/20:30:32</event-date>
<event-type>malicious</event-type>
<event-map-group>19</event-map-group>
<enable>True</enable>
</event>
<condition>
<condition-id>01</condition-id>
<source-caller>105.176.0.0</source-caller>
<destination-callee>192.168.171.35</destination-callee>
<time-information>
<begin-time>22:00</begin-time>
<end-time>08:00</end-time>
</time-information>
<match-direction>default</match-direction>
<exeption>00</exeption>
</condition>
<action>
<action-id>01</action-id>
<action-name>action-voip</action-name>
<action-date>2017.10.25/20:30:32</action-date>
<primary-action>DENY</primary-action>
<secondary-action>LOG</secondary-action>
</action>
<precedence>none</precedence>
<owner>
<owner-id>01</owner-id>
<name>i2nsf-admin</name>
</owner>
</rule-voip>
</policy-voip>
</i2nsf-cf-interface-voip-req>
</config>
</edit-config>
</rpc>
Figure 5: An XML Example for VoIP Security Service
6.2. Case 2: DDoS-Attack Mitigation Custom-condition Firewall
The second example is a DDoS-attack mitigation policy. Here, the 1. The policy name is
time information is not set because the service provided by the "security_policy_for_blocking_malicious_voip_packets".
network should be maintained at all times. If the packets sent by
any sources are more than the set threshold, then the admin can set
the percentage of the packets to be dropped to safely maintain the
service.
<?xml version="1.1" encoding="UTF-8"?> 2. The rule name is "Block_malicious_voip_and_volte_packets".
<rpc message-id="2" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<i2nsf-cf-interface-ddos-req nc:operation="create">
<policy-ddos>
<rule-ddos>
<rule-ddos-id>03</rule-ddos-id>
<rule-ddos-name>ddos-policy-example</rule-ddos-name>
<rule-ddos-date>2018.10.25/11:25:32</rule-ddos-date>
<event>
<event-id>03</event-id>
<event-name>ddos</event-name>
<event-date>2018.10.25/11:25:32</event-date>
<event-type>ddos</event-type>
<event-map-group>03</event-map-group>
<enable>True</enable>
</event>
<condition>
<condition-id>03</condition-id>
<source-ip>Any</source-ip>
<destination-ip>192.168.173.37</destination-ip>
<threshold>30</threshold>
<time-information>
<begin-time>--:--</begin-time>
<end-time>--:--</end-time>
</time-information>
<match-direction>default</match-direction>
<exeption>00</exeption>
</condition>
<action>
<action-id>03</action-id>
<action-name>action-ddos</action-name>
<action-date>2018.10.25/11:25:32</action-date>
<primary-action>REJECT</primary-action>
<secondary-action>LOG</secondary-action>
</action>
<precedence>none</precedence>
<owner>
<owner-id>03</owner-id>
<name>i2nsf-admin</name>
</owner>
</rule-ddos>
</policy-ddos>
</i2nsf-cf-interface-ddos-req>
</config>
</edit-config>
</rpc>
Figure 6: An XML Example for DDoS-attack Mitigation 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
database. The "malicious-id" is the key so that the security
admin can read every stored malicious VOIP IDs that are named as
"malicious-id".
6.3. Case 3: Time-Based Firewall 4. The destination target is "employees". "employees" is the key
which represents the list containing information about employees,
such as IP addresses.
The third example is a time-based firewall policy. Consider a Smart 5. The action required is "drop" when any incoming packets are from
Factory which operates from 9 am to 7 pm during the working days. "malicious-id".
During these hours, only the admin responsible for operating the
factory is allow to access a control system. The below figure show
that any access during outside the operating hours is rejected.
<?xml version="1.1" encoding="UTF-8"?> 10.4. Scenario 3: Mitigate HTTP and HTTPS flood attacks on a company
<rpc message-id="3" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0"> web Server
<edit-config>
<target>
<running/>
</target>
<config>
<i2nsf-cf-interface-fw-req nc:operation="create">
<policy-fw>
<rule-fw>
<rule-fw-id>01</rule-fw-id>
<rule-fw-name>fw-policy-example</rule-fw-name>
<rule-fw-date>2018.10.25/11:19:05</rule-fw-date>
<event>
<event-id>01</event-id>
<event-name>invalid_access</event-name>
<event-date>2018.10.25/11:19:05</event-date>
<event-type>invalid</event-type>
<event-map-group>02</event-map-group>
<enable>True</enable>
</event>
<condition>
<condition-id>02</condition-id>
<source-ip>115.176.0.1</source-ip>
<destination-ip>192.168.173.41</destination-ip>
<time-information>
<begin-time>09:00</begin-time>
<end-time>17:00</end-time>
</time-information>
<match-direction>default</match-direction>
<exeption>00</exeption>
</condition>
<action>
<action-id>02</action-id>
<action-name>action-fw</action-name>
<action-date>2018.10.25/11:19:05</action-date>
<primary-action>PASS</primary-action>
<secondary-action>LOG</secondary-action>
</action>
<precedence>none</precedence>
<owner>
<owner-id>02</owner-id>
<name>i2nsf-admin</name>
</owner>
</rule-fw>
</policy-fw>
</i2nsf-cf-interface-fw-req>
</config>
</edit-config>
</rpc>
Figure 7: An XML Example for Time-based Firewall The third example scenario is to "Mitigate HTTP and HTTPS flood
attacks on a company web Server" using a DDoS-attack mitigation
policy. Here, the time information is not set because the service
provided by the network should be maintained at all times. If the
packets sent by any sources are more than the set threshold, then the
admin can set the percentage of the packets to be dropped to safely
maintain the service. In this scenario, the source is set as "any"
to block any sources which send abnormal amount of packets. The
destination is set as "web_server01". Once the rule is set and
delivered and enforced to the nsfs by the securiy controller, the
NSFs will monitor the incoming packet amounts and the destination to
act according to the rule set. The XML instance is described below:
6.4. Case 4: Time-Based Web-Filter <?xml version="1.0" encoding="UTF-8" ?>
<ietf-i2nsf-cfi-policy:policy>
<policy-name>security_policy_for_ddos_attacks</policy-name>
<rule>
<rule-name>100_packets_per_second</rule-name>
<condition>
<ddos-condition>
<destination-target>
<dest-target>webservers</dest-target>
</destination-target>
<rate-limit>
<packet-per-second>100</packet-per-second>
</rate-limit>
</ddos-condition>
</condition>
<action>
<primary-action>drop</primary-action>
</action>
</rule>
</ietf-i2nsf-cfi-policy:policy>
The last example is a time-based web-filter policy. Let us suppose Figure 27: An XML Example for DDoS-attack Mitigation
that a owner of an enterprise wants to forbid access to a specific
set of websites, such as Facebook, Youtube, Instagram, etc. The
below figure shows an example policy an admin of a sector or
department can deploy.
<?xml version="1.1" encoding="UTF-8"?> DDoS-condition Firewall
<rpc message-id="4" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<i2nsf-cf-interface-wf-req nc:operation="create">
<policy-wf>
<rule-wf>
<rule-wf-id>03</rule-wf-id>
<rule-wf-name>wf-policy-example</rule-wf-name>
<rule-wf-date>2018.10.26/14:03:17</rule-wf-date>
<event>
<event-id>04</event-id>
<event-name>wf</event-name>
<event-date>2018.10.26/14:03:17</event-date>
<event-type>wf</event-type>
<event-map-group>04</event-map-group>
<enable>True</enable>
</event>
<condition>
<condition-id>04</condition-id>
<source-ip>192.168.1.3</source-ip>
<destination-url>www.facebook.com</destination-url>
<time-information>
<begin-time>09:00</begin-time>
<end-time>18:00</end-time>
</time-information>
<match-direction>default</match-direction>
<exeption>00</exeption>
</condition>
<action>
<action-id>04</action-id>
<action-name>action-wf</action-name>
<action-date>2018.10.26/14:03:17</action-date>
<primary-action>REJECT</primary-action>
<secondary-action>LOG</secondary-action>
</action>
<precedence>none</precedence>
<owner>
<owner-id>03</owner-id>
<name>i2nsf-admin</name>
</owner>
</rule-wf>
</policy-wf>
</i2nsf-cf-interface-wf-req>
</config>
</edit-config>
</rpc>
Figure 8: An XML Example for Time-based Web-filter 1. The policy name is "security_policy_for_ddos_attacks".
6.5. Case 5: Threat-Feed Configuration 2. The rule name is "100_packets_per_second".
The threat-feed container described above can convey various sources 3. The destination target is "webservers". "webservers" is the key
containing information concerning security threats. One good example which represents the list containing information, such as IP
can be STIX. STIX (Structured Threat Information Expression) is a addresses and ports, about web-servers.
language and serialization format used to exchange cyber threat
intelligence (CTI). It is a lanauge to describe threat information
in a standardized format to enable exchanging and sharing them. The
blow figure show the necessary configuration, which can be generated
and delivered by consumer-facing interface.
... 4. The rate limit exists to limit the incoming amount of packets per
... second. In this case the rate limit is "100" packets per second.
<configuration-tf> This amount depends on the packet receiving capacity of the
<threat-feed> server devices.
<threat-feed-id>02</threat-feed-id>
<threat-feed-name>stix</threat-feed-name>
<threat-feed-date>2018.10.25/11:25:32</threat-feed-date>
<threat-feed-type>ip-address</threat-feed-type>
<feed-server>105.134.171.24</feed-server>
<feed-priority>ip-address</feed-priority>
</threat-feed>
</configuration-tf>
...
...
Figure 9: An XML Example for Threat-feed Configuration 5. The Source-target is all sources which send abnormal amount of
packets.
Usually, STIX can be obtained from a TAXII server which contains a 6. The action required is to "drop" packet reception is more than
collection of cyber threat information formatted in STIX. Here, the 100 packets per second.
"feed-server" leaf contains the ip-address of the TAXII server, so
that recent threat related information can be collected when the
configuration is set.
7. Security Considerations 11. Security Considerations
The data model for the I2NSF Consumer-Facing Interface is derived The data model for the I2NSF Consumer-Facing Interface is derived
from the I2NSF Consumer-Facing Interface Information Model from the I2NSF Consumer-Facing Interface Information Model
[client-facing-inf-im], so the same security considerations with the [client-facing-inf-im], so the same security considerations with the
information model should be included in this document. The data information model should be included in this document. The data
model needs to support a mechanism to protect Consumer-Facing model needs to support a mechanism to protect Consumer-Facing
Interface to Security Controller. Interface to Security Controller.
8. References 12. IANA Considerations
8.1. Normative References This document requests IANA to register the following URI in the
"IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
Registrant Contact: The I2NSF.
XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in
the "YANG Module Names" registry [RFC7950].
name: ietf-i2nsf-cfi-policy
namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
prefix: cfi-policy
reference: RFC 7950
13. References
13.1. Normative References
[RFC3444] Pras, A., "On the Difference between Information Models [RFC3444] Pras, A., "On the Difference between Information Models
and Data Models", RFC 3444, January 2003. and Data Models", RFC 3444, January 2003.
8.2. Informative References 13.2. Informative References
[client-facing-inf-im] [client-facing-inf-im]
Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
S., and L. Xia, "Information model for Client-Facing S., and L. Xia, "Information model for Client-Facing
Interface to Security Controller", draft-kumar-i2nsf- Interface to Security Controller", draft-kumar-i2nsf-
client-facing-interface-im-07 (work in progress), July client-facing-interface-im-07 (work in progress), July
2018. 2018.
[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-framework] [draft-ietf-i2nsf-capability]
Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Xia, L., Strassner, J., Huawei, Basile, C., PoliTo, Lopez,
Kumar, "Framework for Interface to Network Security D., and TID, "Information Model of NSFs Capabilities",
Functions", RFC 8329, February 2018. draft-ietf-i2nsf-capability-04 (work in progress), October
2018.
[i2nsf-terminology] [i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Birkholz, H., and L. Hares, S., Strassner, J., Lopez, D., Birkholz, H., and L.
Xia, "Information model for Client-Facing Interface to Xia, "Information model for Client-Facing Interface to
Security Controller", draft-ietf-i2nsf-terminology-06 Security Controller", draft-ietf-i2nsf-terminology-07
(work in progress), July 2018. (work in progress), January 2019.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
January 2011, <https://www.rfc-editor.org/info/rfc6087>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
and J. Jeong, "Interface to Network Security Functions
(I2NSF): Problem Statement and Use Cases", RFC 8192,
DOI 10.17487/RFC8192, July 2017,
<https://www.rfc-editor.org/info/rfc8192>.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
<https://www.rfc-editor.org/info/rfc8329>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface-
dm-01 dm-02
The following changes have been made from draft-ietf-i2nsf-consumer- The following changes have been made from draft-ietf-i2nsf-consumer-
facing-interface-dm-01: facing-interface-dm-02:
o In Section 6, four additional XML output examples (VoIP, DDoS- o In this version of the WG draft, we merged the
attack, Time-based Firewall and Web-filter) for security policies [client-facing-inf-im] and draft-ietf-i2nsf-consumer-facing-
are added. Also, an example XML output for Threat-feed interface-dm-02 drafts. In sections 4 to 9, we describe the
configuration is added using STIX and TAXII as a threat-feed information model for the security policies delivered through the
example. Consumer-Facing Interface. In sections 10 to 12, we provide and
discuss the YANG data model and example XML outputs of security
policies for various use cases.
o The overall organization of the YANG data model and its data types o In Section 10, the following changes have been made: For "time-
have also been reviewed and corrected, and produced the information" container in event sub-module list, the enforcement
corresponding data tree as shown in the Sections 4 and 5. type is defined into three different types (admin-enforced, time-
enforced, and event-enforced). Also, begin-time and end-time type
has been defined seperately. The security policies can now be set
recursively (daily, weekly, and monthly).
o Overall editorial errors have been corrected. o "policy-role" now has the access-profile container, and previlege
can be set separately per profile.
o "policy-user" information, such as email and password is newly
defined by regular expressions.
o "authentication-method" in "policy-mgnt-auth-method" has been
modified. More specifically, the authentication-method type has
been changed from string to choice so that one can choose between
password, token, and certificate. If not selected, password is
used as a default.
o "Certificate-type" has been re-defined to include common
certificate extensions, such as ".CRT", "CER", and "KEY".
o Used groupings to represent the groups in the Endpoint groups.
o Added examples for registering information (i.e., endpoint-groups,
threat-prevention, and multi-tenancy.)
Appendix B. Acknowledgments Appendix B. Acknowledgments
This work was supported by Institute for Information & communications This work was supported by Institute for Information & communications
Technology Promotion(IITP) grant funded by the Korea government(MSIP) Technology Promotion(IITP) grant funded by the Korea government(MSIP)
(No.R-20160222-002755, Cloud based Security Intelligence Technology (No.R-20160222-002755, Cloud based Security Intelligence Technology
Development for the Customized Security Service Provisioning). Development for the Customized Security Service Provisioning).
Appendix C. Contributors Appendix C. Contributors
This document is made by the group effort of I2NSF working group. This document is made by the group effort of I2NSF working group.
Many people actively contributed to this document, such as Mahdi F. Many people actively contributed to this document, such as Mahdi F.
Dachmehchi and Daeyoung Hyun. The following are considered co- Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their
authors: contributions.
o Hyoungshick Kim (Sungkyunkwan University) The following are co-authors of this document:
o Seungjin Lee (Sungkyunkwan University) Hyoungshick Kim
Department of Software
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
o Jinyong Tim Kim (Sungkyunkwan University) EMail: hyoung@skku.edu
Seungjin Lee
Department of Electrical and Computer Engineering
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
EMail: jine33@skku.edu
Jinyong Tim Kim
Department of Electrical and Computer Engineering
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
Authors' Addresses Authors' Addresses
Jaehoon Paul Jeong Jaehoon Paul Jeong
Department of Software Department of Software
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 31 299 4957 Phone: +82 31 299 4957
Fax: +82 31 290 7996 Fax: +82 31 290 7996
EMail: pauljeong@skku.edu EMail: pauljeong@skku.edu
 End of changes. 175 change blocks. 
2166 lines changed or deleted 1814 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/