draft-ietf-i2nsf-consumer-facing-interface-dm-00.txt   draft-ietf-i2nsf-consumer-facing-interface-dm-01.txt 
Network Working Group J. Jeong Network Working Group J. Jeong
Internet-Draft E. Kim Internet-Draft E. Kim
Intended status: Standards Track Sungkyunkwan University Intended status: Standards Track Sungkyunkwan University
Expires: September 6, 2018 T. Ahn Expires: January 3, 2019 T. Ahn
Korea Telecom Korea Telecom
R. Kumar R. Kumar
Juniper Networks Juniper Networks
S. Hares S. Hares
Huawei Huawei
March 5, 2018 July 2, 2018
I2NSF Consumer-Facing Interface YANG Data Model I2NSF Consumer-Facing Interface YANG Data Model
draft-ietf-i2nsf-consumer-facing-interface-dm-00 draft-ietf-i2nsf-consumer-facing-interface-dm-01
Abstract Abstract
This document describes a YANG data model for the Consumer-Facing This document describes a YANG data model for the Consumer-Facing
Interface between an Interface to Network Security Functions (I2NSF) Interface between an Interface to Network Security Functions (I2NSF)
User and Security Controller in an I2NSF system in a Network User and Security Controller in an I2NSF system in a Network
Functions Virtualization (NFV) environment. The data model is Functions Virtualization (NFV) environment. The data model is
required for enabling different users of a given I2NSF system to required for enabling different users of a given I2NSF system to
define, manage, and monitor security policies for specific flows define, manage, and monitor security policies for specific flows
within an administrative domain. within an administrative domain.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Data Modeling for Security Policies for Consumer-Facing 4. Data Modeling for Security Policies for Consumer-Facing
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. YANG Data Model for Security Policies for Consumer-Facing 5. YANG Data Model for Security Policies for Consumer-Facing
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Normative References . . . . . . . . . . . . . . . . . . 36 9.1. Normative References . . . . . . . . . . . . . . . . . . 37
9.2. Informative References . . . . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Changes from draft-jeong-i2nsf-consumer-facing- Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-
interface-dm-05 . . . . . . . . . . . . . . . . . . 38 interface-dm-00 . . . . . . . . . . . . . . . . . . 39
Appendix B. Use Case: Policy Instance Example for VoIP/VoLTE Appendix B. Use Case: Policy Instance Example for VoIP/VoLTE
Security Services . . . . . . . . . . . . . . . . . 38 Security Services . . . . . . . . . . . . . . . . . 39
Appendix C. Policy Instance YANG Example for VoIP/VoLTE Security Appendix C. Policy Instance YANG Example for VoIP/VoLTE Security
Services . . . . . . . . . . . . . . . . . . . . . . 40 Services . . . . . . . . . . . . . . . . . . . . . . 41
Appendix D. Example XML output for VoIP service . . . . . . . . 50 Appendix D. Example XML output for VoIP service . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This document provides a YANG [RFC6020] data model that defines the This document provides a YANG [RFC6020] data model that defines the
required data for the Consumer-Facing Interface between an Interface required data for the Consumer-Facing Interface between an Interface
to Network Security Functions (I2NSF) User and Security Controller in to Network Security Functions (I2NSF) User and Security Controller in
an I2NSF system [i2nsf-framework] in a Network Functions an I2NSF system [i2nsf-framework] in a Network Functions
Virtualization (NFV) environment. The data model is required for Virtualization (NFV) environment. The data model is required for
enabling different users of a given I2NSF system to define, manage enabling different users of a given I2NSF system to define, manage
skipping to change at page 4, line 7 skipping to change at page 4, line 7
facilitate the efficient delivery of the control or management facilitate the efficient delivery of the control or management
messages. messages.
This data model is designed to support the I2NSF framework that can This data model is designed to support the I2NSF framework that can
be extended according to the security needs. In other words, the be extended according to the security needs. In other words, the
model design is independent of the content and meaning of specific model design is independent of the content and meaning of specific
policies as well as the implementation approach. This document policies as well as the implementation approach. This document
suggests a VoIP/VoLTE security service as a use case for policy rule suggests a VoIP/VoLTE security service as a use case for policy rule
generation. generation.
+-----------------+ +-----------------+
| | | |
| Consumer Facing +------>+ Consumer Facing |
| Interface | | Interface |
|Information Model| | Data Model |
+--------+--------+ +-----------------+
^
|
|
+-------------+-------------+
| |
| Policy-general |
| |
+-------------+-------------+
^
|
+------------+-------------+------------+--------------+
| | | | |
+-----+----+ +----+-----+ +----+----+ +----+----+ +------+-----+
| | | | | | | | | |
| Multi | | Endpoint | | Policy | | Threat | | Telemetry |
| tenancy | | groups | | | | feed | | data |
+----------+ +----------+ +----+----+ +---------+ +------------+
^
|
|
+------+------+
| |
| Rule |
| |
+------+------+
^
|
+----------------+----------------+
| | |
+------+------+ +------+------+ +------+------+
| | | | | |
| Event | | Condition | | Action |
| | | | | |
+-------------+ +-------------+ +-------------+
Figure 1: High-level-abstraction for Consumer Facing Interface
Multi-tenancy in this document enables multiple administrative Multi-tenancy in this document enables multiple administrative
domains in order to manage application resources. An Enterprise domains in order to manage application resources. An Enterprise
organization may have multiple tenants or departments such as HR, organization may have multiple tenants or departments such as HR,
finance, and legal. Thus, we need an object which defines a set of finance, and legal. Thus, we need an object which defines a set of
permissions assigned to a user in an organization that wants to 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 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 assign policy users to a job function or a set of permissions within
the organization. The policy-role object SHALL have Name, Date and the organization. The policy-role object SHALL have Name, Date and
access-profile to grant or deny permissions for the perpose of access-profile to grant or deny permissions for the perpose of
security policy management. security policy management.
skipping to change at page 5, line 40 skipping to change at page 6, line 35
| | +--rw role string | | +--rw role string
| +--rw policy-mgnt-auth-method* [policy-mgnt-auth-method-id] | +--rw policy-mgnt-auth-method* [policy-mgnt-auth-method-id]
| +--rw policy-mgnt-auth-method-id uint16 | +--rw policy-mgnt-auth-method-id uint16
| +--rw name string | +--rw name string
| +--rw date yang:date-and-time | +--rw date yang:date-and-time
| +--rw authentication-method enumeration | +--rw authentication-method enumeration
| +--rw mutual-authentication boolean | +--rw mutual-authentication boolean
| +--rw token-server inet:ipv4-address | +--rw token-server inet:ipv4-address
| +--rw certificate-server inet:ipv4-address | +--rw certificate-server inet:ipv4-address
| +--rw single-sing-on-server inet:ipv4-address | +--rw single-sing-on-server inet:ipv4-address
+--rw end-group +--rw endpoint-group
| +--rw meta-data-source* [meta-data-source-id] | +--rw meta-data-source* [meta-data-source-id]
| | +--rw meta-data-source-id uint16 | | +--rw meta-data-source-id uint16
| | +--rw name string | | +--rw name string
| | +--rw date yang:date-and-time | | +--rw date yang:date-and-time
| | +--rw tag-type? boolean | | +--rw tag-type? boolean
| | +--rw tag-server-information? inet:ipv4-address | | +--rw tag-server-information? inet:ipv4-address
| | +--rw tag-application-protocol? string | | +--rw tag-application-protocol? string
| | +--rw tag-server-credential? string | | +--rw tag-server-credential? string
| +--rw user-group* [user-group-id] | +--rw user-group* [user-group-id]
| | +--rw user-group-id uint16 | | +--rw user-group-id uint16
skipping to change at page 7, line 44 skipping to change at page 8, line 39
| +--rw qos-marking? uint16 | +--rw qos-marking? uint16
+--rw telemetry-destination* [telemetry-destination-id] +--rw telemetry-destination* [telemetry-destination-id]
+--rw telemetry-destination-id uint16 +--rw telemetry-destination-id uint16
+--rw name? string +--rw name? string
+--rw date? yang:date-and-time +--rw date? yang:date-and-time
+--rw collector-source? inet:ipv4-address +--rw collector-source? inet:ipv4-address
+--rw collector-credentials? string +--rw collector-credentials? string
+--rw data-encoding? string +--rw data-encoding? string
+--rw data-transport? enumeration +--rw data-transport? enumeration
Figure 1: Generic Data Model for Security Policies for cf Interface Figure 2: Generic Data Model for Security Policies for cf Interface
5. YANG Data Model for Security Policies for Consumer-Facing Interface 5. YANG Data Model for Security Policies for Consumer-Facing Interface
This section describes a YANG data model for Consumer-Facing This section describes a YANG data model for Consumer-Facing
Interface, based on the information model of Consumer-Facing Interface, based on the information model of Consumer-Facing
Interface to security controller [client-facing-inf-im]. Interface to security controller [client-facing-inf-im].
<CODE BEGINS> file "policy-general.yang" <CODE BEGINS> file "policy-general.yang"
module ietf-policy-general { module ietf-policy-general {
namespace namespace
skipping to change at page 8, line 47 skipping to change at page 9, line 37
WG Chair: Linda Dunbar WG Chair: Linda Dunbar
<mailto:Linda.duhbar@huawei.com> <mailto:Linda.duhbar@huawei.com>
Editor: Jaehoon Paul Jeong Editor: Jaehoon Paul Jeong
<mailto:pauljeong@skku.edu>"; <mailto:pauljeong@skku.edu>";
description description
"This module defines a YANG data module for consumer-facing "This module defines a YANG data module for consumer-facing
interface to security controller."; interface to security controller.";
revision "2018-03-05"{ revision "2018-07-02"{
description "fourth revision"; description "fourth revision";
reference reference
"draft-kumar-i2nsf-client-facing-interface-im-04"; "draft-kumar-i2nsf-client-facing-interface-im-04";
} }
//Groupings //Groupings
container policy { container policy {
description description
"This object is a policy instance to have "This object is a policy instance to have
complete information such as where and when complete information such as where and when
a policy need to be applied."; a policy need to be applied.";
list rule { list rule {
key "rule-id"; key "rule-id";
leaf rule-id { leaf rule-id {
skipping to change at page 19, line 10 skipping to change at page 20, line 4
} }
leaf single-sing-on-server { leaf single-sing-on-server {
type inet:ipv4-address; type inet:ipv4-address;
mandatory true; mandatory true;
description description
"The single-sign-on-server information "The single-sign-on-server information
if the authentication method is if the authentication method is
single-sign-on-based"; single-sign-on-based";
} }
} }
} }
container end-group { container endpoint-group {
description description
"A logical entity in their business "A logical entity in their business
environment, where a security policy environment, where a security policy
is to be applied."; is to be applied.";
list meta-data-source { list meta-data-source {
key "meta-data-source-id"; key "meta-data-source-id";
leaf meta-data-source-id { leaf meta-data-source-id {
type uint16; type uint16;
mandatory true; mandatory true;
skipping to change at page 36, line 4 skipping to change at page 36, line 46
} }
enum buffer-over-udp{ enum buffer-over-udp{
description description
"telemetry data protocol is buffer over UDP."; "telemetry data protocol is buffer over UDP.";
} }
} }
description description
"This field contains streaming telemetry data "This field contains streaming telemetry data
protocols. This could be gRPC, protocol protocols. This could be gRPC, protocol
buffer over UDP, etc."; buffer over UDP, etc.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 3: YANG for policy-general
Figure 2: YANG for policy-general
6. Security Considerations 6. 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.
7. Acknowledgements 7. 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).
This document has greatly benefited from inputs by Hyoungshick Kim, This document has greatly benefited from inputs by Hyoungshick Kim,
Mahdi F. Dachmehchi, Seungjin Lee, Jinyong Tim Kim, and Daeyoung Mahdi F. Dachmehchi, Seungjin Lee, Jinyong Tim Kim, and Daeyoung
Hyun. Hyun.
skipping to change at page 38, line 5 skipping to change at page 39, line 5
[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-04 Security Controller", draft-ietf-i2nsf-terminology-04
(work in progress), July 2017. (work in progress), July 2017.
[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.
Appendix A. Changes from draft-jeong-i2nsf-consumer-facing-interface- Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface-
dm-05 dm-00
The following changes have been made from draft-jeong-i2nsf-consumer- The following changes have been made from draft-jeong-i2nsf-consumer-
facing-interface-dm-05: facing-interface-dm-05:
o In Section 4, the YANG has been modified to represent a policy o In Section 3, the high-level abstraction of the consumer facing
delivered over the consumer facing interface. More specifically, interface has been added.
the YANG model has been modified so that a policy-domain object
can have multiple tenants, and as a result, the policy-tenant leaf
in the tree is added to be the child of policy-domain object.
This clarifies the relationship between a domain and tenants.
o The overall organization of the YANG data model and its data types o The overall organization of the YANG data model and its data types
have also been reviewed and corrected, and produced the have also been reviewed and corrected, and produced the
corresponding data tree as shown in the Section 5. The reviewed corresponding data tree as shown in the Section 5.
data tree model and YANG fully adopted Event-Condition-Action
(ECA) scheme as suggested in the most recent draft about the I2NSF
Consumer-Facing Interface Information Model [client-facing-inf-im]
and I2NSF Framework [i2nsf-framework].
o The data tree model in Appendix B and Yang in Appendix C have also
been modified for better adoption of ECA based policy generation.
o A revised version of an example XML format output is as shown in
Appendix D for VoIP service policy based on Yang in Appendix C.
o Overall editorial errors have been corrected. o Overall editorial errors have been corrected.
Appendix B. Use Case: Policy Instance Example for VoIP/VoLTE Security Appendix B. Use Case: Policy Instance Example for VoIP/VoLTE Security
Services Services
A common scenario for VoIP/VoLTE policy enforcement could be that a A common scenario for VoIP/VoLTE policy enforcement could be that a
malicious call is made to a benign user of any telecommunication malicious call is made to a benign user of any telecommunication
company. For example, imagine a case wherea company "A" employs a company. For example, imagine a case wherea company "A" employs a
hacker with a malicious attempt to hack a user's phone with malware. hacker with a malicious attempt to hack a user's phone with malware.
skipping to change at page 40, line 23 skipping to change at page 41, line 9
| +--rw signature-server? inet:ipv4-address | +--rw signature-server? inet:ipv4-address
| +--rw file-types? string | +--rw file-types? string
| +--rw malware-signatures? string | +--rw malware-signatures? string
+--rw event-map-group* [event-map-group-id] +--rw event-map-group* [event-map-group-id]
+--rw event-map-group-id uint16 +--rw event-map-group-id uint16
+--rw name? string +--rw name? string
+--rw date? yang:date-and-time +--rw date? yang:date-and-time
+--rw security-events? string +--rw security-events? string
+--rw threat-map? string +--rw threat-map? string
Figure 3: Policy Instance Example for VoIP/VoLTE Security Services Figure 4: Policy Instance Example for VoIP/VoLTE Security Services
Appendix C. Policy Instance YANG Example for VoIP/VoLTE Security Appendix C. Policy Instance YANG Example for VoIP/VoLTE Security
Services Services
The following YANG data model is a policy instance for VoIP/VoLTE The following YANG data model is a policy instance for VoIP/VoLTE
security services. The policy-calendar can act as a scheduler to set security services. The policy-calendar can act as a scheduler to set
the start time and end time to block malicious calls which use the start time and end time to block malicious calls which use
suspicious IDs, or calls from other countries. suspicious IDs, or calls from other countries.
<CODE BEGINS> file "ietf-i2nsf-cf-interface-voip.yang" <CODE BEGINS> file "ietf-i2nsf-cf-interface-voip.yang"
skipping to change at page 41, line 23 skipping to change at page 42, line 9
WG Chair: Linda Dunbar WG Chair: Linda Dunbar
<mailto:Linda.duhbar@huawei.com> <mailto:Linda.duhbar@huawei.com>
Editor: Jaehoon Paul Jeong Editor: Jaehoon Paul Jeong
<mailto:pauljeong@skku.edu>"; <mailto:pauljeong@skku.edu>";
description description
"This module defines a YANG data module for consumer-facing "This module defines a YANG data module for consumer-facing
interface to security controller."; interface to security controller.";
revision "2018-03-05"{ revision "2018-07-02"{
description "sixth revision"; description "sixth revision";
reference reference
"draft-kumar-i2nsf-client-facing-interface-im-04"; "draft-kumar-i2nsf-client-facing-interface-im-04";
} }
container policy-voip { container policy-voip {
description description
"This object is a policy instance to have "This object is a policy instance to have
complete information such as where and when complete information such as where and when
a policy need to be applied."; a policy need to be applied.";
skipping to change at page 50, line 33 skipping to change at page 51, line 19
type string; type string;
description description
"This contains a list of threat levels."; "This contains a list of threat levels.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 4: Policy Instance YANG Example for VoIP Security Services Figure 5: Policy Instance YANG Example for VoIP Security Services
Appendix D. Example XML output for VoIP service Appendix D. Example XML output for VoIP service
In this section, we present an XML example for VoIP service. Here, In this section, we present an XML example for VoIP service. Here,
we are going to drop calls commin from a country with an Ip from we are going to drop calls commin from a country with an Ip from
South Africa that is classified as malicious. South Africa that is classified as malicious.
<?xml version="1.1" encoding="UTF-8"?> <?xml version="1.1" encoding="UTF-8"?>
<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0"> <rpc message-id="1" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0">
<edit-config> <edit-config>
skipping to change at page 51, line 46 skipping to change at page 52, line 32
<owner-id>01</owner-id> <owner-id>01</owner-id>
<name>i2nsf-admin</name> <name>i2nsf-admin</name>
</owner> </owner>
</rule-voip> </rule-voip>
</policy-voip> </policy-voip>
</i2nsf-cf-interface-voip-req> </i2nsf-cf-interface-voip-req>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
Figure 5: An XML example for VoIP service Figure 6: An XML example for VoIP service
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
 End of changes. 24 change blocks. 
46 lines changed or deleted 75 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/