idnits 2.17.1 draft-ietf-i2nsf-registration-interface-dm-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 470 has weird spacing: '...average uint1...' == Line 474 has weird spacing: '...average uint1...' == Line 477 has weird spacing: '...average uint...' == Line 492 has weird spacing: '...rw port ine...' -- The document date (23 May 2022) is 702 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 8329 == Outdated reference: A later version (-32) exists of draft-ietf-i2nsf-capability-data-model-31 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-18 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-12 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group S. Hyun, Ed. 3 Internet-Draft Myongji University 4 Intended status: Standards Track J. Jeong, Ed. 5 Expires: 24 November 2022 T. Roh 6 S. Wi 7 Sungkyunkwan University 8 J. Park 9 ETRI 10 23 May 2022 12 I2NSF Registration Interface YANG Data Model 13 draft-ietf-i2nsf-registration-interface-dm-17 15 Abstract 17 This document defines an information model and a YANG data model for 18 Registration Interface between Security Controller and Developer's 19 Management System (DMS) in the Interface to Network Security 20 Functions (I2NSF) framework to register Network Security Functions 21 (NSF) of the DMS with the Security Controller. The objective of 22 these information and data models is to support NSF capability 23 registration and query via I2NSF Registration Interface. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 24 November 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Information Model . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. NSF Capability Registration . . . . . . . . . . . . . . . 5 63 4.1.1. NSF Capability Information . . . . . . . . . . . . . 6 64 4.1.2. NSF Access Information . . . . . . . . . . . . . . . 8 65 4.2. NSF Capability Query . . . . . . . . . . . . . . . . . . 8 66 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 8 68 5.1.1. Definition of Symbols in Tree Diagrams . . . . . . . 9 69 5.1.2. I2NSF Registration Interface . . . . . . . . . . . . 9 70 5.1.3. NSF Capability Information . . . . . . . . . . . . . 11 71 5.1.4. NSF Access Information . . . . . . . . . . . . . . . 11 72 5.2. YANG Data Modules . . . . . . . . . . . . . . . . . . . . 12 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 77 8.2. Informative References . . . . . . . . . . . . . . . . . 20 78 Appendix A. XML Examples of I2NSF Registration Interface Data 79 Model . . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 A.1. Example 1: Registration for the Capabilities of a General 81 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 21 82 A.2. Example 2: Registration for the Capabilities of a 83 Time-based Firewall . . . . . . . . . . . . . . . . . . . 25 84 A.3. Example 3: Registration for the Capabilities of a Web 85 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 29 86 A.4. Example 4: Registration for the Capabilities of a VoIP/VoCN 87 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 33 88 A.5. Example 5: Registration for the Capabilities of a DDoS 89 Mitigator . . . . . . . . . . . . . . . . . . . . . . . . 36 90 A.6. Example 6: Query for the Capabilities of a Time-based 91 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 40 92 Appendix B. NSF Lifecycle Management in NFV Environments . . . . 43 93 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 43 94 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 43 95 Appendix E. Changes from 96 draft-ietf-i2nsf-registration-interface-dm-16 . . . . . . 44 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 99 1. Introduction 101 A number of Network Security Functions (NSF) may exist in the 102 Interface to Network Security Functions (I2NSF) framework [RFC8329]. 103 Since each of these NSFs likely has different security capabilities 104 from each other, it is important to register the security 105 capabilities of the NSF with the security controller. In addition, 106 it is required to search NSFs of some required security capabilities 107 on demand. As an example, if additional security capabilities are 108 required to serve some security service request(s) from an I2NSF 109 user, the security controller SHOULD be able to request the DMS for 110 NSFs that have the required security capabilities. 112 This document describes an information model (see Section 4) and a 113 YANG [RFC7950] data model (see Section 5) for the I2NSF Registration 114 Interface [RFC8329] between the security controller and the 115 developer's management system (DMS) to support NSF capability 116 registration and query via the registration interface. It also 117 describes the operations which SHOULD be performed by the security 118 controller and the DMS via the Registration Interface using the 119 defined model. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 This document uses the following terms defined in [RFC8329] and 130 [I-D.ietf-i2nsf-capability-data-model]. 132 * Network Security Function (NSF): A function that is responsible 133 for a specific treatment of received packets. A Network Security 134 Function can act at various layers of a protocol stack (e.g., at 135 the network layer or other OSI layers). Sample Network Security 136 Service Functions are as follows: Firewall, Intrusion Prevention/ 137 Detection System (IPS/IDS), Deep Packet Inspection (DPI), 138 Application Visibility and Control (AVC), network virus and 139 malware scanning, sandbox, Data Loss Prevention (DLP), Distributed 140 Denial of Service (DDoS) mitigation and TLS proxy. 142 * Data Model: A data model is a representation of concepts of 143 interest to an environment in a form that is dependent on data 144 repository, data definition language, query language, 145 implementation language, and protocol. 147 * Information Model: An information model is a representation of 148 concepts of interest to an environment in a form that is 149 independent of data repository, data definition language, query 150 language, implementation language, and protocol. 152 * YANG: This document follows the guidelines of [RFC8407], uses the 153 common YANG types defined in [RFC6991], and adopts the Network 154 Management Datastore Architecture (NMDA) [RFC8342]. The meaning 155 of the symbols in tree diagrams is defined in [RFC8340]. 157 3. Objectives 159 * Registering NSFs to I2NSF framework: Developer's Management System 160 (DMS) in I2NSF framework is typically run by an NSF vendor, and 161 uses Registration Interface to provide NSFs developed by the NSF 162 vendor to Security Controller. DMS registers NSFs and their 163 capabilities to I2NSF framework through Registration Interface. 164 For the registered NSFs, Security Controller maintains a catalog 165 of the capabilities of those NSFs. 167 * Updating the capabilities of registered NSFs: After an NSF is 168 registered into Security Controller, some modifications on the 169 capability of the NSF MAY be required later. In this case, DMS 170 uses Registration Interface to update the capability of the NSF, 171 and this update SHOULD be reflected in the catalog of NSFs. 173 * Asking DMS about some required capabilities: In cases that some 174 security capabilities are required to serve the security service 175 request from an I2NSF user, Security Controller searches through 176 the registered NSFs to find ones that can provide the required 177 capabilities. But Security Controller might fail to find any NSFs 178 having the required capabilities among the registered NSFs. In 179 this case, Security Controller needs to request DMS for additional 180 NSF(s) that can provide the required security capabilities via 181 Registration Interface. 183 4. Information Model 185 The I2NSF registration interface is used by Security Controller and 186 Developer's Management System (DMS) in I2NSF framework. The 187 following summarizes the operations done through the registration 188 interface: 190 1) DMS registers NSFs and their capabilities to Security Controller 191 via the registration interface. DMS also uses the registration 192 interface to update the capabilities of the NSFs registered 193 previously. 195 2) In case that Security Controller fails to find some required 196 capabilities from any registered NSF that can provide, Security 197 Controller queries DMS about NSF(s) having the required 198 capabilities via the registration interface. 200 Figure 1 shows the information model of the I2NSF registration 201 interface, which consists of two submodels: NSF capability 202 registration and NSF capability query. Each submodel is used for the 203 operations listed above. The remainder of this section will provide 204 in-depth explanations of each submodel. 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | I2NSF Registration Interface Information Model | 208 | | 209 | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 210 | | NSF Capability | | NSF Capability | | 211 | | Registration | | Query | | 212 | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 1: I2NSF Registration Interface Information Model 217 4.1. NSF Capability Registration 219 This submodel is used by DMS to register an NSF with Security 220 Controller. Figure 2 shows how this submodel is constructed. The 221 most important part in Figure 2 is the NSF capability, and this 222 specifies the set of capabilities that the NSF to be registered can 223 offer. The NSF Name contains a unique name of this NSF with the 224 specified set of capabilities. When registering the NSF, DMS 225 additionally includes the network access information of the NSF which 226 is required to enable network communications with the NSF. 228 The following will further explain the NSF capability information and 229 the NSF access information in more detail. 231 +-+-+-+-+-+-+-+-+-+ 232 | NSF Capability | 233 | Registration | 234 +-+-+-+-+^+-+-+-+-+ 235 | 236 +---------------------+--------------------+ 237 | | | 238 | | | 239 +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 240 | NSF | | NSF Capability| | NSF Access | 241 | Name | | Information | | Information | 242 +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 244 Figure 2: NSF Capability Registration Sub-Model 246 4.1.1. NSF Capability Information 248 NSF Capability Information basically describes the security 249 capabilities of an NSF. In Figure 3, we show capability objects of 250 an NSF. Following the information model of NSF capabilities defined 251 in [I-D.ietf-i2nsf-capability-data-model], we share the same I2NSF 252 security capabilities: Directional Capabilities, Event Capabilities, 253 Condition Capabilities, Action Capabilities, Resolution Strategy 254 Capabilities, Default Action Capabilities. Also, NSF Capability 255 Information additionally contains the performance capabilities of an 256 NSF as shown in Figure 3. 258 +-+-+-+-+-+-+-+-+-+ 259 | NSF Capability | 260 | Information | 261 +-+-+-+-^-+-+-+-+-+ 262 | 263 | 264 +----------------------+----------------------+ 265 | | 266 | | 267 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 268 | I2NSF | | Performance | 269 | Capabilities | | Capabilities | 270 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 271 | 272 +------+-------------+----------------+----------------+-------+ 273 | | | | | 274 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | 275 | Directional | | Event | | Condition | | Action | | 276 | Capabilities| | Capabilities| | Capabilities| | Capabilities| | 277 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | 278 | 279 +--------------------+--------------------+-------+ 280 | | 281 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 282 | Resolution | | Default | 283 | Strategy | | Action | 284 | Capabilities| | Capabilities| 285 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 287 Figure 3: NSF Capability Information 289 4.1.1.1. Performance Capabilities 291 This information represents the processing capability of an NSF. 292 Assuming that the current workload status of each NSF is being 293 collected through NSF monitoring 294 [I-D.ietf-i2nsf-nsf-monitoring-data-model], this capability 295 information of the NSF can be used to determine whether the NSF is in 296 congestion by comparing it with the current workload of the NSF. 297 Moreover, this information can specify an available amount of each 298 type of resource, such as processing power which are available on the 299 NSF. (The registration interface can control the usages and 300 limitations of the created instance and make the appropriate request 301 according to the status.) As illustrated in Figure 4, this 302 information consists of two items: Processing and Bandwidth. 303 Processing information describes the NSF's available processing 304 power. Bandwidth describes the information about available network 305 amount in two cases, outbound, inbound. These two information can be 306 used for the NSF's instance request. 308 +-+-+-+-+-+-+-+-+-+ 309 | Performance | 310 | Capabilities | 311 +-+-+-+-^-+-+-+-+-+ 312 | 313 +----------------------------+ 314 | | 315 | | 316 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 317 | Processing | | Bandwidth | 318 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 320 Figure 4: Performance Capability Overview 322 4.1.2. NSF Access Information 324 NSF Access Information contains the followings that are required to 325 communicate with an NSF: IPv4 address, IPv6 address, port number, and 326 supported transport protocol(s) (e.g., Virtual Extensible LAN (VXLAN) 327 [RFC7348], Generic Protocol Extension for VXLAN (VXLAN-GPE) 328 [I-D.ietf-nvo3-vxlan-gpe], Generic Route Encapsulation (GRE), 329 Ethernet etc.). In this document, NSF Access Information is used to 330 identify a specific NSF instance (i.e. NSF Access Information is the 331 signature(unique identifier) of an NSF instance in the overall 332 system). 334 4.2. NSF Capability Query 336 Security Controller MAY require some additional capabilities to serve 337 the security service request from an I2NSF user, but none of the 338 registered NSFs has the required capabilities. In this case, 339 Security Controller makes a description of the required capabilities 340 by using the NSF capability information sub-model in Section 4.1.1, 341 and sends DMS a query about which NSF(s) can provide these 342 capabilities. 344 5. Data Model 346 5.1. YANG Tree Diagram 348 This section provides the YANG Tree diagram of the I2NSF registration 349 interface. 351 5.1.1. Definition of Symbols in Tree Diagrams 353 A simplified graphical representation of the data model is used in 354 this section. The meaning of the symbols used in the following 355 diagrams [RFC8431] is as follows: 357 Brackets "[" and "]" enclose list keys. 359 Abbreviations before data node names: "rw" means configuration 360 (read-write) and "ro" state data (read-only). 362 Symbols after data node names: "?" means an optional node and "*" 363 denotes a "list" and "leaf-list". 365 Parentheses enclose choice and case nodes, and case nodes are also 366 marked with a colon (":"). 368 Ellipsis ("...") stands for contents of subtrees that are not 369 shown. 371 5.1.2. I2NSF Registration Interface 373 module : ietf-i2nsf-registration-interface 374 +--rw nsf-capability-registration 375 | uses nsf-registrations 377 rpcs : 378 +---x i2nsf-capability-query 379 | uses nsf-capability-query 381 Figure 5: YANG Tree of I2NSF Registration Interface 383 The I2NSF registration interface is used for the following purposes. 384 Developer's Management System (DMS) registers NSFs and their 385 capabilities into Security Controller via the registration interface. 386 In case that Security Controller fails to find any NSF among the 387 registered NSFs which can provide some required capabilities, 388 Security Controller uses the registration interface to query DMS 389 about NSF(s) having the required capabilities. The following 390 sections describe the YANG data models to support these operations. 392 5.1.2.1. NSF Capability Registration 394 This section expands the i2nsf-nsf-registrations in Figure 5. 396 NSF Capability Registration 397 +--rw nsf-registrations 398 +--rw nsf-information* [nsf-name] 399 +--rw nsf-name string 400 +--rw nsf-capability-info 401 | uses nsf-capability-info 402 +--rw security-capability 403 | uses ietf-i2nsf-capability 404 +--rw performance-capability 405 | uses performance-capability 406 +--rw nsf-access-info 407 +--rw ip 408 +--rw port 410 Figure 6: YANG Tree of NSF Capability Registration Module 412 When registering an NSF to Security Controller, DMS uses this module 413 to describe what capabilities the NSF can offer. DMS includes the 414 network access information of the NSF which is required to make a 415 network connection with the NSF as well as the capability description 416 of the NSF. 418 5.1.2.2. NSF Capability Query 420 This section expands the nsf-capability-query in Figure 5. 422 I2NSF Capability Query 423 +---x nsf-capability-query 424 +---w input 425 | +---w query-nsf-capability 426 | | uses ietf-i2nsf-capability 427 +--ro output 428 +--ro nsf-access-info 429 +--rw nsf-name 430 +--rw ip 431 +--rw port 433 Figure 7: YANG Tree of NSF Capability Query Module 435 Security Controller MAY require some additional capabilities to 436 provide the security service requested by an I2NSF user, but none of 437 the registered NSFs has the required capabilities. In this case, 438 Security Controller makes a description of the required capabilities 439 using this module and then queries DMS about which NSF(s) can provide 440 these capabilities. Use NETCONF RPCs to send a NSF capability query. 441 Input data is query-i2nsf-capability-info and output data is nsf- 442 access-info. In Figure 7, the ietf-i2nsf-capability refers to the 443 module defined in [I-D.ietf-i2nsf-capability-data-model]. 445 5.1.3. NSF Capability Information 447 This section expands the nsf-capability-info in Figure 6 and 448 Figure 7. 450 NSF Capability Information 451 +--rw nsf-capability-info 452 +--rw security-capability 453 | uses ietf-i2nsf-capability 454 +--rw performance-capability 455 | uses nsf-performance-capability 457 Figure 8: YANG Tree of I2NSF NSF Capability Information 459 In Figure 8, the ietf-i2nsf-capability refers to the module defined 460 in [I-D.ietf-i2nsf-capability-data-model]. The performance- 461 capability is used to specify the performance capability of an NSF. 463 5.1.3.1. NSF Performance Capability 465 This section expands the nsf-performance-capability in Figure 8. 467 NSF Performance Capability 468 +--rw nsf-performance-capability 469 +--rw processing 470 | +--rw processing-average uint16 471 | +--rw processing-peak uint16 472 +--rw bandwidth 473 | +--rw outbound 474 | | +--rw outbound-average uint16 475 | | +--rw outbound-peak uint16 476 | +--rw inbound 477 | | +--rw inbound-average uint16 478 | | +--rw inbound-peak uint16 480 Figure 9: YANG Tree of I2NSF NSF Performance Capability 482 This module is used to specify the performance capabilities of an NSF 483 when registering or initiating the NSF. 485 5.1.4. NSF Access Information 487 This section expands the nsf-access-info in Figure 6. 489 NSF Access Information 490 +--rw nsf-access-info 491 +--rw ip inet:ip-address-no-zone 492 +--rw port inet:port-number 494 Figure 10: YANG Tree of I2NSF NSF Access Informantion 496 This module contains the network access information of an NSF that is 497 required to enable network communications with the NSF. The field of 498 ip can have either an IPv4 address or an IPv6 address. 500 5.2. YANG Data Modules 502 This section provides a YANG module of the data model for the 503 registration interface between Security Controller and Developer's 504 Management System, as defined in Section 4. 506 This YANG module imports from [RFC6991] and 507 [I-D.ietf-i2nsf-capability-data-model]. 509 file "ietf-i2nsf-registration-interface@2022-05-23.yang" 510 module ietf-i2nsf-registration-interface { 511 yang-version 1.1; 513 namespace 514 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-registration-interface"; 516 prefix 517 i2nsfri; 519 //RFC Ed.: replace occurences of XXXX with actual RFC number and 520 //remove this note 522 import ietf-inet-types { 523 prefix inet; 524 reference "RFC 6991"; 525 } 526 import ietf-i2nsf-capability { 527 prefix i2nsfcap; 528 // RFC Ed.: replace YYYY with actual RFC number of 529 // draft-ietf-i2nsf-capability-data-model and remove this note. 530 reference "RFC YYYY: I2NSF Capability YANG Data Model"; 531 } 533 organization 534 "IETF I2NSF (Interface to Network Security Functions) 535 Working Group"; 537 contact 538 "WG Web: 539 WG List: 541 Editor: Sangwon Hyun 542 544 Editor: Jaehoon Paul Jeong 545 "; 547 description 548 "This module defines a YANG data model for I2NSF 549 Registration Interface. 551 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 552 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 553 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 554 document are to be interpreted as described in BCP 14 555 (RFC 2119) (RFC 8174) when, and only when, they appear 556 in all capitals, as shown here. 558 Copyright (c) 2022 IETF Trust and the persons 559 identified as authors of the code. All rights reserved. 561 Redistribution and use in source and binary forms, with or 562 without modification, is permitted pursuant to, and subject 563 to the license terms contained in, the Revised BSD License 564 set forth in Section 4.c of the IETF Trust's Legal Provisions 565 Relating to IETF Documents 566 (https://trustee.ietf.org/license-info). 568 This version of this YANG module is part of RFC XXXX; see 569 the RFC itself for full legal notices."; 571 revision "2022-05-23" { 572 description "Initial revision"; 573 reference 574 "RFC XXXX: I2NSF Registration Interface YANG Data Model"; 575 // RFC Ed.: replace XXXX with actual RFC number and remove 576 // this note 577 } 579 grouping nsf-performance-capability { 580 description 581 "Description of the performance capabilities of an NSF"; 583 container processing { 584 description 585 "Processing power of an NSF in the unit of GHz (gigahertz)"; 587 leaf processing-average { 588 type uint16; 589 units "GHz"; 590 description 591 "Average processing power"; 592 } 593 leaf processing-peak { 594 type uint16; 595 units "GHz"; 596 description 597 "Peak processing power"; 598 } 599 } 601 container bandwidth { 602 description 603 "Network bandwidth available on an NSF 604 in the unit of Mbps (megabits per second)"; 606 container outbound { 607 description 608 "Outbound network bandwidth"; 609 leaf outbound-average { 610 type uint32; 611 units "Mbps"; 612 description 613 "Average outbound bandwidth"; 614 } 615 leaf outbound-peak { 616 type uint32; 617 units "Mbps"; 618 description 619 "Peak outbound bandwidth"; 620 } 621 } 623 container inbound { 624 description 625 "Inbound network bandwidth"; 626 leaf inbound-average { 627 type uint32; 628 units "Mbps"; 629 description 630 "Average inbound bandwidth"; 631 } 632 leaf inbound-peak { 633 type uint32; 634 units "Mbps"; 635 description 636 "Peak inbound bandwidth"; 637 } 639 } 640 } 641 } 643 grouping nsf-capability-info { 644 description 645 "Capability description of an NSF"; 646 container security-capability { 647 description 648 "Description of the security capabilities of an NSF"; 649 uses i2nsfcap:nsf-capabilities; 650 reference "RFC YYYY: I2NSF Capability YANG Data Model"; 651 // RFC Ed.: replace YYYY with actual RFC number of 652 // draft-ietf-i2nsf-capability-data-model and remove this note. 653 } 654 container performance-capability { 655 description 656 "Description of the performance capabilities of an NSF"; 657 uses nsf-performance-capability; 658 } 659 } 661 grouping nsf-access-info { 662 description 663 "Information required to access an NSF"; 664 leaf ip { 665 type inet:ip-address-no-zone; 666 description 667 "Either an IPv4 address or an IPv6 address of this NSF"; 668 } 669 leaf port { 670 type inet:port-number; 671 description 672 "Port available on this NSF"; 673 } 674 } 676 container nsf-registrations { 677 description 678 "Information of an NSF that DMS registers 679 to Security Controller"; 680 list nsf-information { 681 key "nsf-name"; 682 description 683 "Required information for registration"; 684 leaf nsf-name { 685 type string; 686 description 687 "The name of this registered NSF. The NSF name MUST be unique 688 to identify the NSF with the capability. The name can be an 689 arbitrary string including FQDN (Fully Qualified Domain 690 Name)."; 691 } 692 container nsf-capability-info { 693 description 694 "Capability description of this NSF"; 695 uses nsf-capability-info; 696 } 697 container nsf-access-info { 698 description 699 "Network access information of this NSF"; 700 uses nsf-access-info; 701 } 702 } 703 } 705 rpc nsf-capability-query { 706 description 707 "Description of the capabilities that the 708 Security Controller requests to the DMS"; 709 input { 710 container query-nsf-capability { 711 description 712 "Description of the capabilities to request"; 713 uses i2nsfcap:nsf-capabilities; 714 reference "RFC YYYY: I2NSF Capability YANG Data Model"; 715 //RFC Ed.: replace YYYY with actual RFC number of 716 //draft-ietf-i2nsf-capability-data-model and remove this note. 717 } 718 } 719 output { 720 container nsf-access-info { 721 description 722 "Network access information of an NSF 723 with the requested capabilities"; 724 leaf nsf-name { 725 type string; 726 description 727 "The name of this registered NSF. The NSF name MUST be 728 unique to identify the NSF with the capability. The name 729 can be an arbitrary string including FQDN (Fully Qualified 730 Domain Name)."; 731 } 732 uses nsf-access-info; 733 } 734 } 736 } 737 } 738 740 Figure 11: Registration Interface YANG Data Model 742 6. IANA Considerations 744 This document requests IANA to register the following URI in the 745 "IETF XML Registry" [RFC3688]: 747 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-registration-interface 748 Registrant Contact: The IESG. 749 XML: N/A; the requested URI is an XML namespace. 751 This document requests IANA to register the following YANG module in 752 the "YANG Module Names" registry [RFC7950][RFC8525]: 754 Name: ietf-i2nsf-registration-interface 755 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-registration-interface 756 Prefix: i2nsfri 757 Reference: RFC XXXX 759 // RFC Ed.: replace XXXX with actual RFC number and remove 760 // this note 762 7. Security Considerations 764 The YANG module specified in this document defines a data schema 765 designed to be accessed through network management protocols such as 766 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 767 the secure transport layer, and the required secure transport is 768 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 769 and the required secure transport is TLS [RFC8446]. 771 The NETCONF access control model [RFC8341] provides a means of 772 restricting access to specific NETCONF or RESTCONF users to a 773 preconfigured subset of all available NETCONF or RESTCONF protocol 774 operations and content. 776 There are a number of data nodes defined in this YANG module that are 777 writable/creatable/deletable (i.e., config true, which is the 778 default). These data nodes MAY be considered sensitive or vulnerable 779 in some network environments. Write operations (e.g., edit-config) 780 to these data nodes without proper protection can have a negative 781 effect on network operations. These are the subtrees and data nodes 782 and their sensitivity/vulnerability: 784 * nsf-registrations: The attacker MAY exploit this to register a 785 compromised or malicious NSF instead of a legitimate NSF with the 786 Security Controller. 788 * nsf-performance-capability: The attacker MAY provide incorrect 789 information of the performance capability of any target NSF by 790 illegally modifying this. 792 * nsf-capability-info: The attacker MAY provide incorrect 793 information of the security capability of any target NSF by 794 illegally modifying this. 796 * nsf-access-info: The attacker MAY provide incorrect network access 797 information of any target NSF by illegally modifying this. 799 Some of the readable data nodes in this YANG module MAY be considered 800 sensitive or vulnerable in some network environments. It is thus 801 important to control read access (e.g., via get, get-config, or 802 notification) to these data nodes. These are the subtrees and data 803 nodes and their sensitivity/vulnerability: 805 * nsf-registrations: The attacker MAY try to gather some sensitive 806 information of a registered NSF by sniffing this. 808 * nsf-performance-capability: The attacker MAY gather the 809 performance capability information of any target NSF and misuse 810 the information for subsequent attacks. 812 * nsf-capability-info: The attacker MAY gather the security 813 capability information of any target NSF and misuse the 814 information for subsequent attacks. 816 * nsf-access-info: The attacker MAY gather the network access 817 information of any target NSF and misuse the information for 818 subsequent attacks. 820 The RPC operation in this YANG module MAY be considered sensitive or 821 vulnerable in some network environments. It is thus important to 822 control access to this operation. The following is the operation and 823 its sensitivity/vulnerability: 825 * nsf-capability-query: The attacker MAY exploit this RPC operation 826 to deteriorate the availability of the DMS and/or gather the 827 information of some interested NSFs from the DMS. 829 8. References 831 8.1. Normative References 833 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 834 Requirement Levels", BCP 14, RFC 2119, 835 DOI 10.17487/RFC2119, March 1997, 836 . 838 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 839 DOI 10.17487/RFC3688, January 2004, 840 . 842 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 843 and A. Bierman, Ed., "Network Configuration Protocol 844 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 845 . 847 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 848 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 849 . 851 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 852 RFC 6991, DOI 10.17487/RFC6991, July 2013, 853 . 855 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 856 RFC 7950, DOI 10.17487/RFC7950, August 2016, 857 . 859 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 860 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 861 . 863 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 864 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 865 May 2017, . 867 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 868 Kumar, "Framework for Interface to Network Security 869 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 870 . 872 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 873 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 874 . 876 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 877 Access Control Model", STD 91, RFC 8341, 878 DOI 10.17487/RFC8341, March 2018, 879 . 881 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 882 and R. Wilton, "Network Management Datastore Architecture 883 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 884 . 886 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 887 Documents Containing YANG Data Models", BCP 216, RFC 8407, 888 DOI 10.17487/RFC8407, October 2018, 889 . 891 [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 892 S., and N. Bahadur, "A YANG Data Model for the Routing 893 Information Base (RIB)", RFC 8431, DOI 10.17487/RFC8431, 894 September 2018, . 896 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 897 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 898 . 900 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 901 and R. Wilton, "YANG Library", RFC 8525, 902 DOI 10.17487/RFC8525, March 2019, 903 . 905 [I-D.ietf-i2nsf-capability-data-model] 906 Hares, S., Jeong, J. P., Kim, J. T., Moskowitz, R., and Q. 907 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 908 Internet-Draft, draft-ietf-i2nsf-capability-data-model-31, 909 14 May 2022, . 912 8.2. Informative References 914 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 915 Reserved for Documentation", RFC 3849, 916 DOI 10.17487/RFC3849, July 2004, 917 . 919 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 920 Reserved for Documentation", RFC 5737, 921 DOI 10.17487/RFC5737, January 2010, 922 . 924 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 925 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 926 eXtensible Local Area Network (VXLAN): A Framework for 927 Overlaying Virtualized Layer 2 Networks over Layer 3 928 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 929 . 931 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 932 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 933 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 934 Model", Work in Progress, Internet-Draft, draft-ietf- 935 i2nsf-nsf-monitoring-data-model-18, 19 April 2022, 936 . 939 [I-D.ietf-nvo3-vxlan-gpe] 940 (Editor), F. M., (editor), L. K., and U. E. (editor), 941 "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Work 942 in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-12, 943 22 September 2021, . 946 [nfv-framework] 947 "Network Functions Virtualisation (NFV); Architectureal 948 Framework", ETSI GS NFV 002 ETSI GS NFV 002 V1.1.1, 949 October 2013. 951 Appendix A. XML Examples of I2NSF Registration Interface Data Model 953 This section describes XML examples of the I2NSF Registration 954 Interface data model under the assumption of registering several 955 types of NSFs and querying NSF capability. 957 A.1. Example 1: Registration for the Capabilities of a General Firewall 959 This section shows an XML example for registering the capabilities of 960 a general firewall in either IPv4 networks [RFC5737] or IPv6 networks 961 [RFC3849]. 963 966 967 general_firewall 968 969 970 971 972 i2nsfcap:next-header 973 i2nsfcap:source-address 974 i2nsfcap:destination-address 975 i2nsfcap:source-port-number 976 i2nsfcap:destination-port-number 977 978 979 980 981 i2nsfcap:pass 982 983 984 i2nsfcap:drop 985 986 987 i2nsfcap:mirror 988 989 990 i2nsfcap:pass 991 992 993 i2nsfcap:drop 994 995 996 i2nsfcap:mirror 997 998 999 1000 1001 1002 1000 1003 5000 1004 1005 1006 1007 1000 1008 5000 1009 1010 1011 1000 1012 5000 1013 1014 1015 1016 1017 1018 192.0.2.11 1019 49152 1020 1021 1022 1024 Figure 12: Configuration XML for Registration of a General 1025 Firewall in an IPv4 Network 1027 Figure 12 shows the configuration XML for registering a general 1028 firewall in an IPv4 network [RFC5737] and its capabilities as 1029 follows. 1031 1. The instance name of the NSF is general_firewall. 1033 2. The NSF can inspect IPv4 protocol header field, source 1034 address(es), and destination address(es). 1036 3. The NSF can inspect the port number(s) for the transport layer 1037 protocol, i.e., TCP. 1039 4. The NSF can determine whether the packets are allowed to pass, 1040 drop, or mirror. 1042 5. The NSF can have processing power and bandwidth. 1044 6. The IPv4 address of the NSF is 192.0.2.11. 1046 7. The port of the NSF is 49152. 1048 1051 1052 general_firewall 1053 1054 1055 1056 1057 i2nsfcap:next-header 1058 i2nsfcap:source-address 1059 i2nsfcap:destination-address 1060 i2nsfcap:source-port-number 1061 i2nsfcap:destination-port-number 1062 1063 1064 1065 1066 i2nsfcap:pass 1067 1068 1069 i2nsfcap:drop 1070 1071 1072 i2nsfcap:mirror 1073 1074 1075 i2nsfcap:pass 1076 1077 1078 i2nsfcap:drop 1079 1080 1081 i2nsfcap:mirror 1082 1083 1084 1085 1086 1087 1000 1088 5000 1089 1090 1091 1092 1000 1093 5000 1094 1095 1096 1000 1097 5000 1098 1099 1100 1101 1102 1103 2001:db8:0:1::11 1104 49152 1105 1106 1108 1110 Figure 13: Configuration XML for Registration of a General 1111 Firewall in an IPv6 Network 1113 In addition, Figure 13 shows the configuration XML for registering a 1114 general firewall in an IPv6 network [RFC3849] and its capabilities as 1115 follows. 1117 1. The instance name of the NSF is general_firewall. 1119 2. The NSF can inspect IPv6 next header, flow direction, source 1120 address(es), and destination address(es) 1122 3. The NSF can inspect the port number(s) and flow direction for the 1123 transport layer protocol, i.e., TCP and UDP. 1125 4. The NSF can determine whether the packets are allowed to pass, 1126 drop, or mirror. 1128 5. The NSF can have processing power and bandwidth. 1130 6. The IPv6 address of the NSF is 2001:db8:0:1::11. 1132 7. The port of the NSF is 49152. 1134 A.2. Example 2: Registration for the Capabilities of a Time-based 1135 Firewall 1137 This section shows an XML example for registering the capabilities of 1138 a time-based firewall in either IPv4 networks [RFC5737] or IPv6 1139 networks [RFC3849]. 1141 1144 1145 time_based_firewall 1146 1147 1148 1149 1150 i2nsfcap:next-header 1151 i2nsfcap:source-address 1152 i2nsfcap:destination-address 1153 i2nsfcap:source-port-number 1154 i2nsfcap:destination-port-number 1155 1156 1157 i2nsfcap:absolute-time 1158 i2nsfcap:periodic-time 1159 1160 1161 1162 1163 i2nsfcap:pass 1164 1165 1166 i2nsfcap:drop 1167 1168 1169 i2nsfcap:mirror 1170 1171 1172 i2nsfcap:pass 1173 1174 1175 i2nsfcap:drop 1176 1177 1178 i2nsfcap:mirror 1179 1180 1181 1182 1183 1184 1000 1185 5000 1186 1187 1188 1189 1000 1190 5000 1191 1192 1193 1000 1194 5000 1195 1196 1197 1198 1199 1200 192.0.2.11 1201 49152 1202 1203 1205 1207 Figure 14: Configuration XML for Registration of a Time-based 1208 Firewall in an IPv4 Network 1210 Figure 14 shows the configuration XML for registering a time-based 1211 firewall in an IPv4 network [RFC5737] and its capabilities as 1212 follows. 1214 1. The instance name of the NSF is time_based_firewall. 1216 2. The NSF can enforce the security policy rule according to 1217 absolute time and periodic time. 1219 3. The NSF can inspect the IPv4 protocol header field, IPv4 source 1220 address(es), IPv4 destination address(es), TCP source port 1221 number(s), and TCP destination port number(s). 1223 4. The NSF can determine whether the packets are allowed to pass, 1224 drop, or mirror. 1226 5. The NSF can have processing power and bandwidth. 1228 6. The IPv4 address of the NSF is 192.0.2.11. 1230 7. The port of the NSF is 49152. 1232 1235 1236 time_based_firewall 1237 1238 1239 1240 1241 i2nsfcap:next-header 1242 i2nsfcap:source-address 1243 i2nsfcap:destination-address 1244 i2nsfcap:source-port-number 1245 i2nsfcap:destination-port-number 1246 1247 1248 i2nsfcap:absolute-time 1249 i2nsfcap:periodic-time 1250 1251 1252 1253 1254 i2nsfcap:pass 1255 1256 1257 i2nsfcap:drop 1258 1259 1260 i2nsfcap:mirror 1261 1262 1263 i2nsfcap:pass 1264 1265 1266 i2nsfcap:drop 1267 1268 1269 i2nsfcap:mirror 1270 1271 1272 1273 1274 1275 1000 1276 5000 1277 1278 1279 1280 1000 1281 5000 1282 1283 1284 1000 1285 5000 1286 1287 1288 1289 1290 1291 2001:db8:0:1::11 1292 49152 1293 1294 1295 1297 Figure 15: Configuration XML for Registration of a Time-based 1298 Firewall in an IPv6 Network 1300 In addition, Figure 15 shows the configuration XML for registering a 1301 time-based firewall in an IPv6 network [RFC3849] and its capabilities 1302 as follows. 1304 1. The instance name of the NSF is time_based_firewall. 1306 2. The NSF can enforce the security policy rule according to 1307 absolute time and periodic time. 1309 3. The NSF can inspect the IPv6 next header field, IPv6 source 1310 address(es), IPv6 destination address(es), TCP source port 1311 number(s), and TCP destination port number(s). 1313 4. The NSF can determine whether the packets are allowed to pass, 1314 drop, or mirror. 1316 5. The NSF can have processing power and bandwidth. 1318 6. The IPv6 address of the NSF is 2001:db8:0:1::11. 1320 7. The port of the NSF is 49152. 1322 A.3. Example 3: Registration for the Capabilities of a Web Filter 1324 This section shows an XML example for registering the capabilities of 1325 a web filter in either IPv4 networks [RFC5737] or IPv6 networks 1326 [RFC3849]. 1328 1331 1332 web_filter 1333 1334 1335 1336 1337 1338 i2nsfcap:user-defined 1339 1340 1341 1342 1343 1344 i2nsfcap:pass 1345 1346 1347 i2nsfcap:drop 1349 1350 1351 i2nsfcap:mirror 1352 1353 1354 i2nsfcap:pass 1355 1356 1357 i2nsfcap:drop 1358 1359 1360 i2nsfcap:mirror 1361 1362 1363 1364 1365 1366 1000 1367 5000 1368 1369 1370 1371 1000 1372 5000 1373 1374 1375 1000 1376 5000 1377 1378 1379 1380 1381 1382 192.0.2.11 1383 49152 1384 1385 1386 1388 Figure 16: Configuration XML for Registration of a Web Filter in 1389 an IPv4 Network 1391 Figure 16 shows the configuration XML for registering a web filter in 1392 an IPv4 network [RFC5737] and its capabilities are as follows. 1394 1. The instance name of the NSF is web_filter. 1396 2. The NSF can inspect URL from a pre-defined database or a added 1397 new URL by user (user-defined). 1399 3. The NSF can determine whether the packets are allowed to pass, 1400 drop, or mirror. 1402 4. The NSF can have processing power and bandwidth. 1404 5. The IPv4 address of the NSF is 192.0.2.11. 1406 6. The port of the NSF is 49152. 1408 1411 1412 web_filter 1413 1414 1415 1416 1417 1418 i2nsfcap:user-defined 1419 1420 1421 i2nsfcap:pre-defined 1422 1423 1424 1425 1426 1427 i2nsfcap:pass 1428 1429 1430 i2nsfcap:drop 1431 1432 1433 i2nsfcap:mirror 1434 1435 1436 i2nsfcap:pass 1437 1438 1439 i2nsfcap:drop 1440 1441 1442 i2nsfcap:mirror 1443 1445 1446 1447 1448 1449 1000 1450 5000 1451 1452 1453 1454 1000 1455 5000 1456 1457 1458 1000 1459 5000 1460 1461 1462 1463 1464 1465 2001:db8:0:1::11 1466 49152 1467 1468 1469 1471 Figure 17: Configuration XML for Registration of a Web Filter in 1472 an IPv6 Network 1474 In addition, Figure 17 shows the configuration XML for registering a 1475 web filter in an IPv6 network [RFC3849] and its capabilities are as 1476 follows. 1478 1. The instance name of the NSF is web_filter. 1480 2. The NSF can inspect URL from a pre-defined database or a added 1481 new URL by user (user-defined). 1483 3. The NSF can determine whether the packets are allowed to pass, 1484 drop, or mirror. 1486 4. The NSF can have processing power and bandwidth. 1488 5. The IPv6 address of the NSF is 2001:db8:0:1::11. 1490 6. The port of the NSF is 49152. 1492 A.4. Example 4: Registration for the Capabilities of a VoIP/VoCN Filter 1494 This section shows an XML example for registering the capabilities of 1495 a Voice over Internet Protocol (VoIP) and Voice over Cellular Network 1496 (VoCN) filter in either IPv4 networks [RFC5737] or IPv6 networks 1497 [RFC3849]. 1499 1502 1503 voip_vocn_filter 1504 1505 1506 1507 1508 1509 i2nsfcap:call-id 1510 1511 1512 1513 1514 1515 i2nsfcap:pass 1516 1517 1518 i2nsfcap:drop 1519 1520 1521 i2nsfcap:mirror 1522 1523 1524 i2nsfcap:pass 1525 1526 1527 i2nsfcap:drop 1528 1529 1530 i2nsfcap:mirror 1531 1532 1533 1534 1535 1536 1000 1537 5000 1538 1539 1540 1541 1000 1542 5000 1543 1544 1545 1000 1546 5000 1547 1548 1549 1550 1551 1552 192.0.2.11 1553 49152 1554 1555 1556 1558 Figure 18: Configuration XML for Registration of a VoIP/VoLTE 1559 Filter in an IPv4 Network 1561 Figure 18 shows the configuration XML for registering a VoIP/VoLTE 1562 filter in an IPv4 network [RFC5737] and its capabilities are as 1563 follows. 1565 1. The instance name of the NSF is voip_volte_filter. 1567 2. The NSF can inspect a call id for VoIP/VoLTE packets. 1569 3. The NSF can determine whether the packets are allowed to pass, 1570 drop, or mirror. 1572 4. The NSF can have processing power and bandwidth. 1574 5. The IPv4 address of the NSF is 192.0.2.11. 1576 6. The port of the NSF is 49152. 1578 1581 1582 voip_vocn_filter 1583 1584 1585 1586 1587 1588 i2nsfcap:call-id 1589 1590 1591 1592 1593 1594 i2nsfcap:pass 1595 1596 1597 i2nsfcap:drop 1598 1599 1600 i2nsfcap:mirror 1601 1602 1603 i2nsfcap:pass 1604 1605 1606 i2nsfcap:drop 1607 1608 1609 i2nsfcap:mirror 1610 1611 1612 1613 1614 1615 1000 1616 5000 1617 1618 1619 1620 1000 1621 5000 1622 1623 1624 1000 1625 5000 1626 1627 1628 1629 1630 1631 2001:db8:0:1::11 1632 49152 1633 1634 1635 1636 Figure 19: Configuration XML for Registration of a VoIP/VoLTE 1637 Filter in an IPv6 Network 1639 Figure 19 shows the configuration XML for registering a VoIP/VoLTE 1640 filter in an IPv6 network [RFC3849] and its capabilities are as 1641 follows. 1643 1. The instance name of the NSF is voip_volte_filter. 1645 2. The NSF can inspect a call id for VoIP/VoLTE packets. 1647 3. The NSF can determine whether the packets are allowed to pass, 1648 drop, or mirror. 1650 4. The NSF can have processing power and bandwidth. 1652 5. The IPv6 address of the NSF is 2001:db8:0:1::11. 1654 6. The port of the NSF is 49152. 1656 A.5. Example 5: Registration for the Capabilities of a DDoS Mitigator 1658 This section shows an XML example for registering the capabilities of 1659 a DDoS mitigator in either IPv4 networks [RFC5737] or IPv6 networks 1660 [RFC3849]. 1662 1665 1666 anti_DDoS 1667 1668 1669 1670 1671 1672 i2nsfcap:packet-rate 1673 1674 1675 i2nsfcap:flow-rate 1676 1677 1678 i2nsfcap:byte-rate 1679 1680 1681 1682 1683 1684 i2nsfcap:pass 1685 1686 1687 i2nsfcap:drop 1688 1689 1690 i2nsfcap:mirror 1691 1692 1693 i2nsfcap:rate-limit 1694 1695 1696 i2nsfcap:pass 1697 1698 1699 i2nsfcap:drop 1700 1701 1702 i2nsfcap:mirror 1703 1704 1705 i2nsfcap:rate-limit 1706 1707 1708 1709 1710 1711 1000 1712 5000 1713 1714 1715 1716 1000 1717 5000 1718 1719 1720 1000 1721 5000 1722 1723 1724 1725 1726 1727 192.0.2.11 1728 49152 1729 1730 1731 1732 Figure 20: Configuration XML for Registration of a DDoS Mitigator 1733 in an IPv4 Network 1735 Figure 20 shows the configuration XML for registering a DDoS 1736 mitigator in an IPv4 network [RFC5737] and its capabilities are as 1737 follows. 1739 1. The instance name of the NSF is anti_DDoS. 1741 2. The NSF can detect the amount of packet, flow, and byte rate in 1742 the network for potential DDoS Attack. 1744 3. The NSF can determine whether the packets are allowed to pass, 1745 drop, or mirror. 1747 4. The NSF can have processing power and bandwidth. 1749 5. The IPv4 address of the NSF is 192.0.2.11. 1751 6. The port of the NSF is 49152. 1753 1756 1757 anti_DDoS 1758 1759 1760 1761 1762 1763 i2nsfcap:packet-rate 1764 1765 1766 i2nsfcap:flow-rate 1767 1768 1769 i2nsfcap:byte-rate 1770 1771 1772 1773 1774 1775 i2nsfcap:pass 1776 1777 1778 i2nsfcap:drop 1779 1780 1781 i2nsfcap:mirror 1782 1783 1784 i2nsfcap:rate-limit 1785 1786 1787 i2nsfcap:pass 1788 1789 1790 i2nsfcap:drop 1791 1792 1793 i2nsfcap:mirror 1794 1795 1796 i2nsfcap:rate-limit 1797 1798 1799 1800 1801 1802 1000 1803 5000 1804 1805 1806 1807 1000 1808 5000 1809 1810 1811 1000 1812 5000 1813 1814 1815 1816 1817 1818 2001:db8:0:1::11 1819 49152 1820 1821 1822 1824 Figure 21: Configuration XML for Registration of a DDoS Mitigator 1825 in an IPv6 Network 1827 In addition, Figure 21 shows the configuration XML for registering a 1828 DDoS mitigator in an IPv6 network [RFC3849] and its capabilities are 1829 as follows. 1831 1. The instance name of the NSF is anti_DDoS. 1833 2. The NSF can detect the amount of packet, flow, and byte rate in 1834 the network for potential DDoS Attack. 1836 3. The NSF can determine whether the packets are allowed to pass, 1837 drop, mirror, or rate-limit. 1839 4. The NSF can have processing power and bandwidth. 1841 5. The IPv6 address of the NSF is 2001:db8:0:1::11. 1843 6. The port of the NSF is 49152. 1845 A.6. Example 6: Query for the Capabilities of a Time-based Firewall 1847 This section shows an XML example for querying the capabilities of a 1848 time-based firewall in either IPv4 networks [RFC5737] or IPv6 1849 networks [RFC3849]. 1851 1853 1856 1857 1858 i2nsfcap:absolute-time 1859 i2nsfcap:periodic-time 1860 1861 1862 1863 i2nsfcap:next-header 1864 i2nsfcap:source-address 1865 i2nsfcap:destination-address 1866 1867 1868 1869 1870 i2nsfcap:pass 1871 1872 1873 i2nsfcap:drop 1874 1875 1876 i2nsfcap:mirror 1877 1878 1879 i2nsfcap:pass 1880 1881 1882 i2nsfcap:drop 1883 1884 1885 i2nsfcap:mirror 1886 1887 1888 1889 1890 1892 1894 1896 time_based_firewall 1897 192.0.2.11 1898 49152 1899 1900 1902 Figure 22: Configuration XML for Query of a Time-based Firewall 1903 in an IPv4 Network 1905 Figure 22 shows the XML configuration for querying the capabilities 1906 of a time-based firewall in an IPv4 network [RFC5737]. The access 1907 information of the announced time-based firewall has the IPv4 address 1908 of 192.0.2.11 and the port number of 49152. 1910 1912 1915 1916 1917 i2nsfcap:absolute-time 1918 i2nsfcap:periodic-time 1919 1920 1921 1922 i2nsfcap:next-header 1923 i2nsfcap:source-address 1924 i2nsfcap:destination-address 1925 1926 1927 1928 1929 i2nsfcap:pass 1930 1931 1932 i2nsfcap:drop 1933 1934 1935 i2nsfcap:mirror 1936 1937 1938 i2nsfcap:pass 1939 1940 1941 i2nsfcap:drop 1942 1943 1944 i2nsfcap:mirror 1945 1946 1947 1948 1949 1951 1953 1955 time_based_firewall 1956 2001:db8:0:1::11 1957 49152 1958 1959 1961 Figure 23: Configuration XML for Query of a Time-based Firewall 1962 in an IPv6 Network 1964 In addition, Figure 23 shows the XML configuration for querying the 1965 capabilities of a time-based firewall in an IPv6 network [RFC3849]. 1966 The access information of the announced time-based firewall has the 1967 IPv6 address of 2001:db8:0:1::11 and the port number of 49152. 1969 Appendix B. NSF Lifecycle Management in NFV Environments 1971 Network Functions Virtualization (NFV) can be used to implement I2NSF 1972 framework. In NFV environments, NSFs are deployed as virtual network 1973 functions (VNFs). Security Controller can be implemented as an 1974 Element Management (EM) of the NFV architecture, and is connected 1975 with the VNF Manager (VNFM) via the Ve-Vnfm interface 1976 [nfv-framework]. Security Controller can use this interface for the 1977 purpose of the lifecycle management of NSFs. If some NSFs need to be 1978 instantiated to enforce security policies in the I2NSF framework, 1979 Security Controller could request the VNFM to instantiate them 1980 through the Ve-Vnfm interface. Or if an NSF, running as a VNF, is 1981 not used by any traffic flows for a time period, Security Controller 1982 MAY request deinstantiating it through the interface for efficient 1983 resource utilization. 1985 Appendix C. Acknowledgments 1987 This document is a product by the I2NSF Working Group (WG) including 1988 WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This 1989 document took advantage of the review and comments from the following 1990 people: Roman Danyliw, Reshad Rahman (YANG doctor), and Tom Petch. 1991 We authors sincerely appreciate their sincere efforts and kind help. 1993 This work was supported by Institute of Information & Communications 1994 Technology Planning & Evaluation (IITP) grant funded by the Korea 1995 MSIT (Ministry of Science and ICT) (No. 2016-0-00078, Cloud Based 1996 Security Intelligence Technology Development for the Customized 1997 Security Service Provisioning). This work was supported in part by 1998 the IITP (2020-0-00395, Standard Development of Blockchain based 1999 Network Management Automation Technology). 2001 Appendix D. Contributors 2003 The following are co-authors of this document: 2005 Patrick Lingga - Department of Electrical and Computer Engineering, 2006 Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, Gyeonggi-do 2007 16419, Republic of Korea, EMail: patricklink@skku.edu 2009 Jinyong (Tim) Kim - Department of Electronic, Electrical and Computer 2010 Engineering, Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, 2011 Gyeonggi-do 16419, Republic of Korea, EMail: timkim@skku.edu 2013 Chaehong Chung - Department of Electronic, Electrical and Computer 2014 Engineering, Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, 2015 Gyeonggi-do 16419, Republic of Korea, EMail: darkhong@skku.edu 2016 Susan Hares - Huawei, 7453 Hickory Hill, Saline, MI 48176, USA, 2017 EMail: shares@ndzh.com 2019 Diego R. Lopez - Telefonica I+D, Jose Manuel Lara, 9, Seville, 2020 41013, Spain, EMail: diego.r.lopez@telefonica.com 2022 Appendix E. Changes from draft-ietf-i2nsf-registration-interface-dm-16 2024 The following changes are made from draft-ietf-i2nsf-registration- 2025 interface-dm-16: 2027 * The YANG module's prefix is updated from 'nsfreg' to 'i2nsfri'. 2029 * The YANG module's name is updated from 'ietf-i2nsf-reg-interface' 2030 to 'ietf-i2nsf-registration-interface'. 2032 * The prefix for importing the I2NSF Capability YANG module is 2033 updated following the prefix change in I2NSF Capability YANG 2034 module [I-D.ietf-i2nsf-capability-data-model]. The examples are 2035 also updated following the new prefix. 2037 Authors' Addresses 2039 Sangwon Hyun (editor) 2040 Department of Computer Engineering 2041 Myongji University 2042 116 Myongji-ro, Cheoin-gu 2043 Yongin 2044 Gyeonggi-do 2045 17058 2046 Republic of Korea 2047 Email: shyun@mju.ac.kr 2049 Jaehoon Paul Jeong (editor) 2050 Department of Computer Science and Engineering 2051 Sungkyunkwan University 2052 2066 Seobu-Ro, Jangan-Gu 2053 Suwon 2054 Gyeonggi-Do 2055 16419 2056 Republic of Korea 2057 Phone: +82 31 299 4957 2058 Email: pauljeong@skku.edu 2059 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2060 Taekyun Roh 2061 Department of Electronic, Electrical and Computer Engineering 2062 Sungkyunkwan University 2063 2066 Seobu-Ro, Jangan-Gu 2064 Suwon 2065 Gyeonggi-Do 2066 16419 2067 Republic of Korea 2068 Phone: +82 31 290 7222 2069 Email: tkroh0198@skku.edu 2071 Sarang Wi 2072 Department of Electronic, Electrical and Computer Engineering 2073 Sungkyunkwan University 2074 2066 Seobu-Ro, Jangan-Gu 2075 Suwon 2076 Gyeonggi-Do 2077 16419 2078 Republic of Korea 2079 Phone: +82 31 290 7222 2080 Email: dnl9795@skku.edu 2082 Jung-Soo Park 2083 Electronics and Telecommunications Research Institute 2084 218 Gajeong-Ro, Yuseong-Gu 2085 Daejeon 2086 305-700 2087 Republic of Korea 2088 Phone: +82 42 860 6514 2089 Email: pjs@etri.re.kr