--- 1/draft-ietf-i2nsf-consumer-facing-interface-dm-01.txt 2018-11-04 03:13:25.392331900 -0800 +++ 2/draft-ietf-i2nsf-consumer-facing-interface-dm-02.txt 2018-11-04 03:13:25.492334290 -0800 @@ -1,24 +1,24 @@ -Network Working Group J. Jeong +I2NSF Working Group J. Jeong Internet-Draft E. Kim Intended status: Standards Track Sungkyunkwan University -Expires: January 3, 2019 T. Ahn +Expires: May 8, 2019 T. Ahn Korea Telecom R. Kumar Juniper Networks S. Hares Huawei - July 2, 2018 + November 4, 2018 I2NSF Consumer-Facing Interface YANG Data Model - draft-ietf-i2nsf-consumer-facing-interface-dm-01 + draft-ietf-i2nsf-consumer-facing-interface-dm-02 Abstract This document describes a YANG data model for the Consumer-Facing Interface between an Interface to Network Security Functions (I2NSF) User and Security Controller in an I2NSF system in a Network Functions Virtualization (NFV) environment. The data model is required for enabling different users of a given I2NSF system to define, manage, and monitor security policies for specific flows within an administrative domain. @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 3, 2019. + This Internet-Draft will expire on May 8, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -55,36 +55,41 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Data Modeling for Security Policies for Consumer-Facing Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 5. YANG Data Model for Security Policies for Consumer-Facing - Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 - 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 37 - 9.2. Informative References . . . . . . . . . . . . . . . . . 37 + 4.1. YANG Data Model for Security Policies for Consumer-Facing + Interface . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5. Use Case: Policy Instance Example for VoIP/VoLTE Security + Services . . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 5.1. Policy Instance YANG Example for VoIP/VoLTE Security + Services . . . . . . . . . . . . . . . . . . . . . . . . 35 + 6. Example XML Output for Various Use Cases . . . . . . . . . . 45 + 6.1. Case 1: VoIP Security Service . . . . . . . . . . . . . . 45 + 6.2. Case 2: DDoS-Attack Mitigation . . . . . . . . . . . . . 47 + 6.3. Case 3: Time-Based Firewall . . . . . . . . . . . . . . . 48 + 6.4. Case 4: Time-Based Web-Filter . . . . . . . . . . . . . . 49 + 6.5. Case 5: Threat-Feed Configuration . . . . . . . . . . . . 50 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 51 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 51 + 8.2. Informative References . . . . . . . . . . . . . . . . . 52 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing- - interface-dm-00 . . . . . . . . . . . . . . . . . . 39 - Appendix B. Use Case: Policy Instance Example for VoIP/VoLTE - Security Services . . . . . . . . . . . . . . . . . 39 - Appendix C. Policy Instance YANG Example for VoIP/VoLTE Security - Services . . . . . . . . . . . . . . . . . . . . . . 41 - Appendix D. Example XML output for VoIP service . . . . . . . . 51 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 + interface-dm-01 . . . . . . . . . . . . . . . . . . 53 + Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 53 + Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 53 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction This document provides a YANG [RFC6020] data model that defines the required data for the Consumer-Facing Interface between an Interface to Network Security Functions (I2NSF) User and Security Controller in an I2NSF system [i2nsf-framework] in a Network Functions Virtualization (NFV) environment. The data model is required for enabling different users of a given I2NSF system to define, manage and monitor security policies for specific flows within an @@ -135,73 +140,30 @@ facilitate the efficient delivery of the control or management messages. This data model is designed to support the I2NSF framework that can be extended according to the security needs. In other words, the model design is independent of the content and meaning of specific policies as well as the implementation approach. This document suggests a VoIP/VoLTE security service as a use case for policy rule 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 domains in order to manage application resources. An Enterprise - organization may have multiple tenants or departments such as HR, - finance, and legal. 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. + 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 @@ -359,23 +321,24 @@ | +--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 2: Generic Data Model for Security Policies for cf Interface + Figure 1: Generic Data Model for Security Policies for cf Interface -5. YANG Data Model for Security Policies for Consumer-Facing Interface +4.1. YANG Data Model for Security Policies for Consumer-Facing + Interface This section describes a YANG data model for Consumer-Facing Interface, based on the information model of Consumer-Facing Interface to security controller [client-facing-inf-im]. file "policy-general.yang" module ietf-policy-general { namespace "urn:ietf:params:xml:ns:yang:ietf-policy-general"; prefix @@ -403,26 +366,25 @@ WG Chair: Linda Dunbar Editor: Jaehoon Paul Jeong "; description "This module defines a YANG data module for consumer-facing interface to security controller."; - revision "2018-07-02"{ + revision "2018-11-04"{ description "fourth revision"; reference "draft-kumar-i2nsf-client-facing-interface-im-04"; } - //Groupings container policy { description "This object is a policy instance to have complete information such as where and when a policy need to be applied."; list rule { key "rule-id"; leaf rule-id { @@ -773,42 +703,39 @@ "This represents the policy-user-id."; } description "This represents the list of policy users."; 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 @@ -1719,104 +1560,24 @@ } description "This field contains streaming telemetry data protocols. This could be gRPC, protocol buffer over UDP, etc."; } } } } - Figure 3: YANG for policy-general - -6. Security Considerations - - The data model for the I2NSF Consumer-Facing Interface is derived - from the I2NSF Consumer-Facing Interface Information Model - [client-facing-inf-im], so the same security considerations with the - information model should be included in this document. The data - model needs to support a mechanism to protect Consumer-Facing - Interface to Security Controller. - -7. Acknowledgments - - This work was supported by Institute for Information & communications - Technology Promotion(IITP) grant funded by the Korea government(MSIP) - (No.R-20160222-002755, Cloud based Security Intelligence Technology - Development for the Customized Security Service Provisioning). - This document has greatly benefited from inputs by Hyoungshick Kim, - Mahdi F. Dachmehchi, Seungjin Lee, Jinyong Tim Kim, and Daeyoung - Hyun. - -8. Contributors - - I2NSF is a group effort. The following people actively contributed - to the consumer facing interface data model, and are considered co- - authors: o Hyoungshick Kim (Sungkyunkwan University) o Seungjin Lee - (Sungkyunkwan University) - -9. References - -9.1. Normative References - - [RFC3444] Pras, A., "On the Difference between Information Models - and Data Models", RFC 3444, January 2003. - -9.2. Informative References - - [client-facing-inf-im] - Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, - S., and L. Xia, "Information model for Client-Facing - Interface to Security Controller", draft-kumar-i2nsf- - client-facing-interface-im-04 (work in progress), July - 2017. - - [client-facing-inf-req] - Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, - S., and L. Xia, "Requirements for Client-Facing Interface - to Security Controller", draft-ietf-i2nsf-client-facing- - interface-req-03 (work in progress), July 2017. - - [i2nsf-framework] - Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. - Kumar, "Framework for Interface to Network Security - Functions", draft-ietf-i2nsf-framework-08 (work in - progress), October 2017. - - [i2nsf-terminology] - Hares, S., Strassner, J., Lopez, D., Birkholz, H., and L. - Xia, "Information model for Client-Facing Interface to - Security Controller", draft-ietf-i2nsf-terminology-04 - (work in progress), July 2017. - - [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the - Network Configuration Protocol (NETCONF)", RFC 6020, - October 2010. - -Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- - dm-00 - - The following changes have been made from draft-jeong-i2nsf-consumer- - facing-interface-dm-05: - - o In Section 3, the high-level abstraction of the consumer facing - interface has been added. - - o The overall organization of the YANG data model and its data types - have also been reviewed and corrected, and produced the - corresponding data tree as shown in the Section 5. - - o Overall editorial errors have been corrected. + Figure 2: YANG for policy-general -Appendix B. Use Case: Policy Instance Example for VoIP/VoLTE Security - Services +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 @@ -1887,24 +1648,23 @@ | +--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 4: Policy Instance Example for VoIP/VoLTE Security Services + Figure 3: Policy Instance Example for VoIP/VoLTE Security Services -Appendix C. Policy Instance YANG Example for VoIP/VoLTE Security - 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. file "ietf-i2nsf-cf-interface-voip.yang" module ietf-policy-voip { namespace @@ -1933,26 +1692,25 @@ WG Chair: Linda Dunbar Editor: Jaehoon Paul Jeong "; description "This module defines a YANG data module for consumer-facing interface to security controller."; - revision "2018-07-02"{ + revision "2018-11-04"{ description "sixth revision"; reference - "draft-kumar-i2nsf-client-facing-interface-im-04"; + "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; @@ -2375,60 +2127,68 @@ } leaf threat-map { type string; description "This contains a list of threat levels."; } } } } - - Figure 5: Policy Instance YANG Example for VoIP Security Services + Figure 4: Policy Instance YANG Example for VoIP Security Services -Appendix D. Example XML output for VoIP service +6. Example XML Output for Various Use Cases - In this section, we present an XML example for VoIP service. Here, - we are going to drop calls commin from a country with an Ip from - South Africa that is classified as malicious. + In this section, we present an XML example for various use cases. + Here, we show the policy examples that can be delivered through + consumer-facing interface. For now, the considered use cases are: + VoIP security service, DDoS-attack mitigation, time-based firewall, + and web-filter. + +6.1. Case 1: VoIP Security Service + + The first example is a VoIP policy. Here, we are going to drop calls + commin from a country with an Ip from South Africa that is classified + as malicious. The below figure shows the XML document generated by + using the YANG data tree as shown in the previous section. 01 voip-policy-example 2017.10.25/20:30:32 01 voip_call 2017.10.25/20:30:32 malicious - - 22:00 - 08:00 - 19 True 01 105.176.0.0 192.168.171.35 + + 22:00 + 08:00 + default 00 01 action-voip 2017.10.25/20:30:32 DENY LOG @@ -2436,25 +2196,326 @@ 01 i2nsf-admin + Figure 5: An XML Example for VoIP Security Service - Figure 6: An XML example for VoIP service +6.2. Case 2: DDoS-Attack Mitigation -Authors' Addresses + The second example is a DDoS-attack mitigation policy. Here, the + time information is not set because the service provided by the + network should be maintained at all times. If the packets sent by + any sources are more than the set threshold, then the admin can set + the percentage of the packets to be dropped to safely maintain the + service. + + + + + + + + + + + 03 + ddos-policy-example + 2018.10.25/11:25:32 + + 03 + ddos + 2018.10.25/11:25:32 + ddos + 03 + True + + + 03 + Any + 192.168.173.37 + 30 + + --:-- + --:-- + + default + 00 + + + 03 + action-ddos + 2018.10.25/11:25:32 + REJECT + LOG + + none + + 03 + i2nsf-admin + + + + + + + + + Figure 6: An XML Example for DDoS-attack Mitigation + +6.3. Case 3: Time-Based Firewall + + The third example is a time-based firewall policy. Consider a Smart + Factory which operates from 9 am to 7 pm during the working days. + During these hours, only the admin responsible for operating the + factory is allow to access a control system. The below figure show + that any access during outside the operating hours is rejected. + + + + + + + + + + + + 01 + fw-policy-example + 2018.10.25/11:19:05 + + 01 + invalid_access + 2018.10.25/11:19:05 + invalid + 02 + True + + + 02 + 115.176.0.1 + 192.168.173.41 + + 09:00 + 17:00 + + default + 00 + + + 02 + action-fw + 2018.10.25/11:19:05 + PASS + LOG + + none + + 02 + i2nsf-admin + + + + + + + + + Figure 7: An XML Example for Time-based Firewall + +6.4. Case 4: Time-Based Web-Filter + + The last example is a time-based web-filter policy. Let us suppose + that a owner of an enterprise wants to forbid access to a specific + set of websites, such as Facebook, Youtube, Instagram, etc. The + below figure shows an example policy an admin of a sector or + department can deploy. + + + + + + + + + + + + 03 + wf-policy-example + 2018.10.26/14:03:17 + + 04 + wf + 2018.10.26/14:03:17 + wf + 04 + True + + + 04 + 192.168.1.3 + www.facebook.com + + 09:00 + 18:00 + + default + 00 + + + 04 + action-wf + 2018.10.26/14:03:17 + REJECT + LOG + + none + + 03 + i2nsf-admin + + + + + + + + + Figure 8: An XML Example for Time-based Web-filter + +6.5. Case 5: Threat-Feed Configuration + + The threat-feed container described above can convey various sources + containing information concerning security threats. One good example + can be STIX. STIX (Structured Threat Information Expression) is a + language and serialization format used to exchange cyber threat + intelligence (CTI). It is a lanauge to describe threat information + in a standardized format to enable exchanging and sharing them. The + blow figure show the necessary configuration, which can be generated + and delivered by consumer-facing interface. + + ... + ... + + + 02 + stix + 2018.10.25/11:25:32 + ip-address + 105.134.171.24 + ip-address + + + ... + ... + + Figure 9: An XML Example for Threat-feed Configuration + + Usually, STIX can be obtained from a TAXII server which contains a + collection of cyber threat information formatted in STIX. Here, the + "feed-server" leaf contains the ip-address of the TAXII server, so + that recent threat related information can be collected when the + configuration is set. + +7. Security Considerations + + The data model for the I2NSF Consumer-Facing Interface is derived + from the I2NSF Consumer-Facing Interface Information Model + [client-facing-inf-im], so the same security considerations with the + information model should be included in this document. The data + model needs to support a mechanism to protect Consumer-Facing + Interface to Security Controller. + +8. References + +8.1. Normative References + + [RFC3444] Pras, A., "On the Difference between Information Models + and Data Models", RFC 3444, January 2003. + +8.2. Informative References + + [client-facing-inf-im] + Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, + S., and L. Xia, "Information model for Client-Facing + Interface to Security Controller", draft-kumar-i2nsf- + client-facing-interface-im-07 (work in progress), July + 2018. + + [client-facing-inf-req] + Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, + S., and L. Xia, "Requirements for Client-Facing Interface + to Security Controller", draft-ietf-i2nsf-client-facing- + interface-req-05 (work in progress), May 2018. + + [i2nsf-framework] + Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. + Kumar, "Framework for Interface to Network Security + Functions", RFC 8329, February 2018. + + [i2nsf-terminology] + Hares, S., Strassner, J., Lopez, D., Birkholz, H., and L. + Xia, "Information model for Client-Facing Interface to + Security Controller", draft-ietf-i2nsf-terminology-06 + (work in progress), July 2018. + + [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the + Network Configuration Protocol (NETCONF)", RFC 6020, + October 2010. + +Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- + dm-01 + + The following changes have been made from draft-ietf-i2nsf-consumer- + facing-interface-dm-01: + + o In Section 6, four additional XML output examples (VoIP, DDoS- + attack, Time-based Firewall and Web-filter) for security policies + are added. Also, an example XML output for Threat-feed + configuration is added using STIX and TAXII as a threat-feed + example. + + o The overall organization of the YANG data model and its data types + have also been reviewed and corrected, and produced the + corresponding data tree as shown in the Sections 4 and 5. + + o Overall editorial errors have been corrected. + +Appendix B. Acknowledgments + + This work was supported by Institute for Information & communications + Technology Promotion(IITP) grant funded by the Korea government(MSIP) + (No.R-20160222-002755, Cloud based Security Intelligence Technology + Development for the Customized Security Service Provisioning). + +Appendix C. Contributors + + This document is made by the group effort of I2NSF working group. + Many people actively contributed to this document, such as Mahdi F. + Dachmehchi and Daeyoung Hyun. The following are considered co- + authors: + + o Hyoungshick Kim (Sungkyunkwan University) + + o Seungjin Lee (Sungkyunkwan University) + + o Jinyong Tim Kim (Sungkyunkwan University) + +Authors' Addresses Jaehoon Paul Jeong Department of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Fax: +82 31 290 7996 EMail: pauljeong@skku.edu