--- 1/draft-ietf-i2nsf-registration-interface-dm-11.txt 2021-09-15 10:13:14.496426815 -0700 +++ 2/draft-ietf-i2nsf-registration-interface-dm-12.txt 2021-09-15 10:13:14.576428820 -0700 @@ -1,23 +1,23 @@ I2NSF Working Group S. Hyun, Ed. Internet-Draft Myongji University Intended status: Standards Track J. Jeong, Ed. -Expires: 22 February 2022 T. Roh +Expires: 19 March 2022 T. Roh S. Wi Sungkyunkwan University J. Park ETRI - 21 August 2021 + 15 September 2021 I2NSF Registration Interface YANG Data Model - draft-ietf-i2nsf-registration-interface-dm-11 + draft-ietf-i2nsf-registration-interface-dm-12 Abstract This document defines an information model and a YANG data model for Registration Interface between Security Controller and Developer's Management System (DMS) in the Interface to Network Security Functions (I2NSF) framework to register Network Security Functions (NSF) of the DMS with the Security Controller. The objective of these information and data models is to support NSF capability registration and query via I2NSF Registration Interface. @@ -30,21 +30,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 22 February 2022. + This Internet-Draft will expire on 19 March 2022. Copyright Notice Copyright (c) 2021 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 carefully, as they describe your rights @@ -86,21 +86,21 @@ A.4. Example 4: Registration for the Capabilities of a VoIP/ VoLTE Filter . . . . . . . . . . . . . . . . . . . . . . 33 A.5. Example 5: Registration for the Capabilities of a DDoS Mitigator . . . . . . . . . . . . . . . . . . . . . . . . 36 A.6. Example 6: Query for the Capabilities of a Time-based Firewall . . . . . . . . . . . . . . . . . . . . . . . . 40 Appendix B. NSF Lifecycle Management in NFV Environments . . . . 43 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 43 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 43 Appendix E. Changes from - draft-ietf-i2nsf-registration-interface-dm-10 . . . . . . 44 + draft-ietf-i2nsf-registration-interface-dm-11 . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction A number of Network Security Functions (NSF) may exist in the Interface to Network Security Functions (I2NSF) framework [RFC8329]. Since each of these NSFs likely has different security capabilities from each other, it is important to register the security capabilities of the NSF with the security controller. In addition, it is required to search NSFs of some required security capabilities @@ -485,39 +485,39 @@ This module is used to specify the performance capabilities of an NSF when registering or initiating the NSF. 5.1.4. NSF Access Information This section expands the nsf-access-info in Figure 6. NSF Access Information +--rw nsf-access-info +--rw capability-name string - +--rw ip inet:ip-address + +--rw ip inet:ip-address-no-zone +--rw port inet:port-number Figure 10: YANG Tree of I2NSF NSF Access Informantion This module contains the network access information of an NSF that is required to enable network communications with the NSF. The field of ip can have either an IPv4 address or an IPv6 address. 5.2. YANG Data Modules This section provides a YANG module of the data model for the registration interface between Security Controller and Developer's Management System, as defined in Section 4. This YANG module imports from [RFC6991], and makes a reference to [I-D.ietf-i2nsf-capability-data-model]. - file "ietf-i2nsf-reg-interface@2021-08-21.yang" + file "ietf-i2nsf-reg-interface@2021-09-15.yang" module ietf-i2nsf-reg-interface { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"; prefix nsfreg; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note @@ -530,50 +530,50 @@ // RFC Ed.: replace YYYY with actual RFC number of // draft-ietf-i2nsf-capability-data-model and remove this note. reference "RFC YYYY: I2NSF Capability YANG Data Model"; } organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact - "WG Web: + "WG Web: WG List: Editor: Sangwon Hyun Editor: Jaehoon Paul Jeong "; description "This module defines a YANG data model for I2NSF Registration Interface. Copyright (c) 2021 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). + (https://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 actual RFC number and remove // this note - revision "2021-08-21" { + revision "2021-09-15" { description "Initial revision"; reference "RFC XXXX: I2NSF Registration Interface YANG Data Model"; // RFC Ed.: replace XXXX with actual RFC number and remove // this note } grouping nsf-performance-capability { description "Description of the performance capabilities of an NSF"; @@ -655,21 +655,21 @@ grouping nsf-access-info { description "Information required to access an NSF"; leaf capability-name { type string; description "Unique name of this NSF's capability"; } leaf ip { - type inet:ip-address; + type inet:ip-address-no-zone; description "Either an IPv4 address or an IPv6 address of this NSF"; } leaf port { type inet:port-number; description "Port available on this NSF"; } } @@ -909,23 +909,23 @@ [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, . [I-D.ietf-i2nsf-nsf-monitoring-data-model] Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. Birkholz, "I2NSF NSF Monitoring Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf- - i2nsf-nsf-monitoring-data-model-08, 29 April 2021, + i2nsf-nsf-monitoring-data-model-09, 24 August 2021, . + monitoring-data-model-09.txt>. [RFC9061] Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- Garcia, "A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)", RFC 9061, DOI 10.17487/RFC9061, July 2021, . [I-D.ietf-nvo3-vxlan-gpe] (Editor), F. M., (editor), L. K., and U. E. (editor), "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Work @@ -1139,21 +1139,21 @@ time_based_firewall_capability cap:absolute-time cap:periodic-time - cap:ipv4-protocol + cap:next-header cap:source-address cap:destination-address cap:source-port-number cap:destination-port-number cap:pass @@ -1204,22 +1204,23 @@ Figure 14 shows the configuration XML for registering a time-based firewall in an IPv4 network [RFC5737] and its capabilities as follows. 1. The instance name of the NSF is time_based_firewall. 2. The NSF can enforce the security policy rule according to absolute time and periodic time. - 3. The NSF can inspect the IPv4 protocol header field, flow - direction, source address(es), and destination address(es). + 3. The NSF can inspect the IPv4 protocol header field, IPv4 source + address(es), IPv4 destination address(es), TCP source port + number(s), and TCP destination port number(s). 4. The NSF can determine whether the packets are allowed to pass, drop, or mirror. 5. The NSF can have processing power and bandwidth. 6. The IPv4 address of the NSF is 192.0.2.11. 7. The port of the NSF is 3000. @@ -1229,21 +1230,21 @@ time_based_firewall_capability cap:absolute-time cap:periodic-time - cap:ipv6-protocol + cap:next-header cap:source-address cap:destination-address cap:source-port-number cap:destination-port-number cap:pass @@ -1295,22 +1295,23 @@ In addition, Figure 15 shows the configuration XML for registering a time-based firewall in an IPv6 network [RFC3849] and its capabilities as follows. 1. The instance name of the NSF is time_based_firewall. 2. The NSF can enforce the security policy rule according to absolute time and periodic time. - 3. The NSF can inspect the IPv6 protocol header field, flow - direction, source address(es), and destination address(es).. + 3. The NSF can inspect the IPv6 next header field, IPv6 source + address(es), IPv6 destination address(es), TCP source port + number(s), and TCP destination port number(s). 4. The NSF can determine whether the packets are allowed to pass, drop, or mirror. 5. The NSF can have processing power and bandwidth. 6. The IPv6 address of the NSF is 2001:DB8:0:1::11. 7. The port of the NSF is 3000. @@ -1807,23 +1806,21 @@ 5000 1000 5000 - - anti_DDoS - + anti_DDoS 2001:DB8:0:1::11 3000 Figure 21: Configuration XML for Registration of a DDoS Mitigator in an IPv6 Network In addition, Figure 21 shows the configuration XML for registering a @@ -1853,21 +1850,21 @@ absolute-time periodic-time - cap:ipv4-protocol + cap:next-header cap:source-address cap:destination-address cap:pass cap:drop @@ -1910,21 +1907,21 @@ absolute-time periodic-time - cap:ipv6-protocol + cap:next-header cap:source-address cap:destination-address cap:pass cap:drop @@ -2009,24 +2006,24 @@ Chaehong Chung Department of Electronic, Electrical and Computer Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 16419 Republic of Korea EMail: darkhong@skku.edu Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA EMail: shares@ndzh.com Diego R. Lopez Telefonica I+D Jose Manuel Lara, 9 Seville, 41013 Spain EMail: diego.r.lopez@telefonica.com -Appendix E. Changes from draft-ietf-i2nsf-registration-interface-dm-10 +Appendix E. Changes from draft-ietf-i2nsf-registration-interface-dm-11 The following changes are made from draft-ietf-i2nsf-registration- - interface-dm-10: + interface-dm-11: * This version has been updated to synchronize with other I2NSF documents. Authors' Addresses Sangwon Hyun (editor) Department of Computer Engineering Myongji University 116 Myongji-ro, Cheoin-gu