--- 1/draft-ietf-i2nsf-consumer-facing-interface-dm-11.txt 2020-09-08 06:14:29.613406676 -0700 +++ 2/draft-ietf-i2nsf-consumer-facing-interface-dm-12.txt 2020-09-08 06:14:29.709409103 -0700 @@ -1,24 +1,24 @@ I2NSF Working Group J. Jeong, Ed. Internet-Draft C. Chung Intended status: Standards Track Sungkyunkwan University -Expires: March 10, 2021 T. Ahn +Expires: March 12, 2021 T. Ahn Korea Telecom R. Kumar Juniper Networks S. Hares Huawei - September 6, 2020 + September 8, 2020 I2NSF Consumer-Facing Interface YANG Data Model - draft-ietf-i2nsf-consumer-facing-interface-dm-11 + draft-ietf-i2nsf-consumer-facing-interface-dm-12 Abstract This document describes an information model and 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 information model defines various types of managed objects and the relationship among them needed to build the interface. The information model is based on the "Event-Condition-Action" (ECA) @@ -36,21 +36,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 March 10, 2021. + This Internet-Draft will expire on March 12, 2021. Copyright Notice Copyright (c) 2020 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 @@ -73,38 +73,38 @@ 4.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Location Group . . . . . . . . . . . . . . . . . . . . . 13 5. Information Model for Threat Prevention . . . . . . . . . . . 14 5.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 15 6. Network Configuration Access Control Model (NACM) for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . . . . . . 16 7. YANG Data Model of Consumer-Facing Interface . . . . . . . . 18 7.1. YANG Module of Consumer-Facing Interface . . . . . . . . 18 8. XML Configuration Examples of High-Level Security Policy - Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 + Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.1. Database Registration: Information of Positions and - Devices (Endpoint Group) . . . . . . . . . . . . . . . . 42 - 8.2. Scenario 1: Block SNS Access during Business Hours . . . 44 + Devices (Endpoint Group) . . . . . . . . . . . . . . . . 41 + 8.2. Scenario 1: Block SNS Access during Business Hours . . . 43 8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to - a Company . . . . . . . . . . . . . . . . . . . . . . . . 46 + a Company . . . . . . . . . . . . . . . . . . . . . . . . 45 8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a - Company Web Server . . . . . . . . . . . . . . . . . . . 48 + Company Web Server . . . . . . . . . . . . . . . . . . . 47 9. XML Configuration Example of a User Group's Access Control - for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 49 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 - 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 - 14.1. Normative References . . . . . . . . . . . . . . . . . . 54 - 14.2. Informative References . . . . . . . . . . . . . . . . . 56 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 + for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 48 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 50 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 + 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 53 + 14.2. Informative References . . . . . . . . . . . . . . . . . 55 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 1. Introduction In a framework of Interface to Network Security Functions (I2NSF) [RFC8329], each vendor can register their NSFs using a Developer's Management System (DMS). Assuming that vendors also provide the front-end web applications registered with an I2NSF User, the Consumer-Facing Interface is required because the web applications developed by each vendor need to have a standard interface specifying the data types used when the I2NSF User and Security Controller @@ -184,23 +184,23 @@ in the NFV system. By the efficient virtualization technology, these VNFs might be automatically provisioned and dynamically migrated based on real-time security requirements. This document presents a YANG data model to implement security functions based on NFV. 2. Terminology This document uses the terminology described in [RFC8329]. This document follows the guidelines of [RFC8407], uses the common - YANG types defined in [I-D.ietf-netmod-rfc6991-bis], and adopts the - Network Management Datastore Architecture (NMDA). The meaning of the - symbols in tree diagrams is defined in [RFC8340]. + 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]. 3. Information Model for Policy A Policy object represents a mechanism to express a Security Policy by Security Administrator (i.e., I2NSF User) using Consumer-Facing Interface toward Security Controller; the policy would be enforced on an NSF. Figure 2 shows the YANG tree of the Policy object. The Policy object SHALL have the following information: Name: This field identifies the name of this object. @@ -756,25 +756,25 @@ policies as well as the implementation approach. With the YANG data model of I2NSF Consumer-Facing Interface, this document suggests use cases for security policy rules such as time- based firewall, VoIP/VoLTE security service, and DDoS-attack mitigation in Section 8. 7.1. YANG Module of Consumer-Facing Interface This section describes a YANG module of Consumer-Facing Interface. - This YANG module imports from [I-D.ietf-netmod-rfc6991-bis]. It - makes references to [RFC0854][RFC0913][RFC0959][RFC1081][RFC1631][RFC - 2616][RFC2818][RFC4250][RFC5321]. + This YANG module imports from [RFC6991]. It makes references to [RFC + 0854][RFC0913][RFC0959][RFC1081][RFC1631][RFC2616][RFC2818][RFC4250][ + RFC5321]. - file "ietf-i2nsf-cfi-policy@2020-09-06.yang" + file "ietf-i2nsf-cfi-policy@2020-09-08.yang" module ietf-i2nsf-cfi-policy { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; prefix nsfcfi; import ietf-inet-types{ prefix inet; } @@ -813,21 +813,21 @@ 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."; // RFC Ed.: replace XXXX with an actual RFC number and remove // this note. - revision "2020-09-06"{ + revision "2020-09-08"{ description "Initial revision."; reference "RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model"; // RFC Ed.: replace XXXX with an actual RFC number and remove // this note. } identity malware-file-type { description @@ -1200,25 +1200,20 @@ * Typedefs */ typedef time { type string { pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; } description "The time type represents an instance of time of zero-duration that recurs every day."; - reference - "RFC 6991-bis: Common YANG Data Types - typedef time is used."; - - // RFC Ed.: When RFC 6991-bis becomes an RFC, remove 'typedef time' - // this note. } /* * Groupings */ grouping ipv4-list { description "Grouping for an IPv4 address list."; leaf-list ipv4 { @@ -1544,51 +1540,28 @@ } container period{ when "../../frequency!='only-once'"; description "This represents the repetition time. In the case where the frequency is weekly, the days can be set."; leaf start-time { type time; - // RFC Ed.: When RFC 6991-bis becomes an RFC, time must - // be replaced with yang:time. - // this note. - description "This is a period's start time for an event."; - reference - "RFC 6991-bis: Common YANG Data Types - The time type - represents an instance of time of zero-duration that - recurs every day."; - - // RFC Ed.: Replace 6991-bis with an actual RFC number - // and remove this note. - } leaf end-time { type time; - // RFC Ed.: When RFC 6991-bis becomes an RFC, time must - // be replaced with yang:time. - // this note. - description "This is a period's end time for an event."; - reference - "RFC 6991-bis: Common YANG Data Types - The time type - represents an instance of time of zero-duration that - recurs every day."; - - // RFC Ed.: Replace 6991-bis with an actual RFC number - // and remove this note. } leaf-list day { when "../../../frequency='weekly'"; type identityref{ base day; } min-elements 1; description "This represents the repeated day of every week (e.g., @@ -2377,24 +2350,20 @@ 101 Software Avenue Nanjing, Jiangsu 210012 China EMail: Frank.Xialiang@huawei.com 14. References 14.1. Normative References - [I-D.ietf-netmod-rfc6991-bis] - Schoenwaelder, J., "Common YANG Data Types", draft-ietf- - netmod-rfc6991-bis-04 (work in progress), July 2020. - [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, . [RFC0913] Lottor, M., "Simple File Transfer Protocol", RFC 913, DOI 10.17487/RFC0913, September 1984, . [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, @@ -2454,20 +2423,24 @@ [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", + RFC 6991, DOI 10.17487/RFC6991, July 2013, + . + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,