idnits 2.17.1 draft-ietf-i2nsf-registration-interface-dm-11.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 473 has weird spacing: '...average uint1...' == Line 477 has weird spacing: '...average uint1...' == Line 480 has weird spacing: '...average uint...' == Line 496 has weird spacing: '...rw port ine...' -- The document date (21 August 2021) is 979 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) == Outdated reference: A later version (-32) exists of draft-ietf-i2nsf-capability-data-model-17 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-08 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-11 Summary: 1 error (**), 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: 22 February 2022 T. Roh 6 S. Wi 7 Sungkyunkwan University 8 J. Park 9 ETRI 10 21 August 2021 12 I2NSF Registration Interface YANG Data Model 13 draft-ietf-i2nsf-registration-interface-dm-11 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 22 February 2022. 42 Copyright Notice 44 Copyright (c) 2021 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 Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . 9 66 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . 12 72 5.2. YANG Data Modules . . . . . . . . . . . . . . . . . . . . 12 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 A.1. Example 1: Registration for the Capabilities of a General 81 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 22 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/ 87 VoLTE 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-10 . . . . . . 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). The meaning of the 155 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: Time Capabilities, Event Capabilities, 253 Condition Capabilities, Action Capabilities, Resolution Strategy 254 Capabilities, Default Action Capabilities, and IPsec Method 255 [RFC9061]. Also, NSF Capability Information additionally contains 256 the performance capabilities of an 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 | Time | | Event | | Condition | | Action | | 276 | Capabilities| | Capabilities| | Capabilities| | Capabilities| | 277 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | 278 | 279 +---------------------+---------------------+-------+ 280 | | | 281 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ 282 | Resolution | | Default | | IPsec | 283 | Strategy | | Action | | Method | 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-reg-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* [capability-name] 399 +--rw capability-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 | uses nsf-access-info 408 +--rw capability-name 409 +--rw ip 410 +--rw port 412 Figure 6: YANG Tree of NSF Capability Registration Module 414 When registering an NSF to Security Controller, DMS uses this module 415 to describe what capabilities the NSF can offer. DMS includes the 416 network access information of the NSF which is required to make a 417 network connection with the NSF as well as the capability description 418 of the NSF. 420 5.1.2.2. NSF Capability Query 422 This section expands the nsf-capability-query in Figure 5. 424 I2NSF Capability Query 425 +---x nsf-capability-query 426 +---w input 427 | +---w query-nsf-capability 428 | | uses ietf-i2nsf-capability 429 +--ro output 430 +--ro nsf-access-info 431 | uses nsf-access-info 432 +--rw capability-name 433 +--rw ip 434 +--rw port 436 Figure 7: YANG Tree of NSF Capability Query Module 438 Security Controller MAY require some additional capabilities to 439 provide the security service requested by an I2NSF user, but none of 440 the registered NSFs has the required capabilities. In this case, 441 Security Controller makes a description of the required capabilities 442 using this module and then queries DMS about which NSF(s) can provide 443 these capabilities. Use NETCONF RPCs to send a NSF capability query. 444 Input data is query-i2nsf-capability-info and output data is nsf- 445 access-info. In Figure 7, the ietf-i2nsf-capability refers to the 446 module defined in [I-D.ietf-i2nsf-capability-data-model]. 448 5.1.3. NSF Capability Information 450 This section expands the nsf-capability-info in Figure 6 and 451 Figure 7. 453 NSF Capability Information 454 +--rw nsf-capability-info 455 +--rw security-capability 456 | uses ietf-i2nsf-capability 457 +--rw performance-capability 458 | uses nsf-performance-capability 460 Figure 8: YANG Tree of I2NSF NSF Capability Information 462 In Figure 8, the ietf-i2nsf-capability refers to the module defined 463 in [I-D.ietf-i2nsf-capability-data-model]. The performance- 464 capability is used to specify the performance capability of an NSF. 466 5.1.3.1. NSF Performance Capability 468 This section expands the nsf-performance-capability in Figure 8. 470 NSF Performance Capability 471 +--rw nsf-performance-capability 472 +--rw processing 473 | +--rw processing-average uint16 474 | +--rw processing-peak uint16 475 +--rw bandwidth 476 | +--rw outbound 477 | | +--rw outbound-average uint16 478 | | +--rw outbound-peak uint16 479 | +--rw inbound 480 | | +--rw inbound-average uint16 481 | | +--rw inbound-peak uint16 483 Figure 9: YANG Tree of I2NSF NSF Performance Capability 485 This module is used to specify the performance capabilities of an NSF 486 when registering or initiating the NSF. 488 5.1.4. NSF Access Information 490 This section expands the nsf-access-info in Figure 6. 492 NSF Access Information 493 +--rw nsf-access-info 494 +--rw capability-name string 495 +--rw ip inet:ip-address 496 +--rw port inet:port-number 498 Figure 10: YANG Tree of I2NSF NSF Access Informantion 500 This module contains the network access information of an NSF that is 501 required to enable network communications with the NSF. The field of 502 ip can have either an IPv4 address or an IPv6 address. 504 5.2. YANG Data Modules 506 This section provides a YANG module of the data model for the 507 registration interface between Security Controller and Developer's 508 Management System, as defined in Section 4. 510 This YANG module imports from [RFC6991], and makes a reference to 511 [I-D.ietf-i2nsf-capability-data-model]. 513 file "ietf-i2nsf-reg-interface@2021-08-21.yang" 514 module ietf-i2nsf-reg-interface { 515 yang-version 1.1; 517 namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"; 519 prefix nsfreg; 521 // RFC Ed.: replace occurences of XXXX with actual RFC number and 522 // remove this note 524 import ietf-inet-types { 525 prefix inet; 526 reference "RFC 6991"; 527 } 528 import ietf-i2nsf-capability { 529 prefix cap; 530 // RFC Ed.: replace YYYY with actual RFC number of 531 // draft-ietf-i2nsf-capability-data-model and remove this note. 532 reference "RFC YYYY: I2NSF Capability YANG Data Model"; 533 } 535 organization 536 "IETF I2NSF (Interface to Network Security Functions) 537 Working Group"; 539 contact 540 "WG Web: 541 WG List: 543 Editor: Sangwon Hyun 544 546 Editor: Jaehoon Paul Jeong 547 "; 549 description 550 "This module defines a YANG data model for I2NSF 551 Registration Interface. 553 Copyright (c) 2021 IETF Trust and the persons 554 identified as authors of the code. All rights reserved. 556 Redistribution and use in source and binary forms, with or 557 without modification, is permitted pursuant to, and subject 558 to the license terms contained in, the Simplified BSD License 559 set forth in Section 4.c of the IETF Trust's Legal Provisions 560 Relating to IETF Documents 561 (http://trustee.ietf.org/license-info). 563 This version of this YANG module is part of RFC XXXX; see 564 the RFC itself for full legal notices."; 566 // RFC Ed.: replace XXXX with actual RFC number and remove 567 // this note 569 revision "2021-08-21" { 570 description "Initial revision"; 571 reference 572 "RFC XXXX: I2NSF Registration Interface YANG Data Model"; 573 // RFC Ed.: replace XXXX with actual RFC number and remove 574 // this note 575 } 577 grouping nsf-performance-capability { 578 description 579 "Description of the performance capabilities of an NSF"; 581 container processing { 582 description 583 "Processing power of an NSF in the unit of GHz (gigahertz)"; 585 leaf processing-average { 586 type uint16; 587 units "GHz"; 588 description 589 "Average processing power"; 590 } 591 leaf processing-peak { 592 type uint16; 593 units "GHz"; 594 description 595 "Peak processing power"; 596 } 597 } 598 container bandwidth { 599 description 600 "Network bandwidth available on an NSF 601 in the unit of Mbps (megabits per second)"; 603 container outbound { 604 description 605 "Outbound network bandwidth"; 606 leaf outbound-average { 607 type uint32; 608 units "Mbps"; 609 description 610 "Average outbound bandwidth"; 611 } 612 leaf outbound-peak { 613 type uint32; 614 units "Mbps"; 615 description 616 "Peak outbound bandwidth"; 617 } 618 } 619 container inbound { 620 description 621 "Inbound network bandwidth"; 622 leaf inbound-average { 623 type uint32; 624 units "Mbps"; 625 description 626 "Average inbound bandwidth"; 627 } 628 leaf inbound-peak { 629 type uint32; 630 units "Mbps"; 631 description 632 "Peak inbound bandwidth"; 633 } 634 } 635 } 636 } 638 grouping nsf-capability-info { 639 description 640 "Capability description of an NSF"; 641 container security-capability { 642 description 643 "Description of the security capabilities of an NSF"; 644 uses cap:nsf-capabilities; 645 // RFC Ed.: replace YYYY with actual RFC number of 646 // draft-ietf-i2nsf-capability-data-model and remove this note. 647 reference "RFC YYYY: I2NSF Capability YANG Data Model"; 648 } 649 container performance-capability { 650 description 651 "Description of the performance capabilities of an NSF"; 652 uses nsf-performance-capability; 653 } 654 } 656 grouping nsf-access-info { 657 description 658 "Information required to access an NSF"; 659 leaf capability-name { 660 type string; 661 description 662 "Unique name of this NSF's capability"; 663 } 664 leaf ip { 665 type inet:ip-address; 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 "capability-name"; 682 description 683 "Required information for registration"; 684 leaf capability-name { 685 type string; 686 mandatory true; 687 description 688 "Unique name of this registered NSF"; 689 } 690 container nsf-capability-info { 691 description 692 "Capability description of this NSF"; 693 uses nsf-capability-info; 694 } 695 container nsf-access-info { 696 description 697 "Network access information of this NSF"; 698 uses nsf-access-info; 699 } 700 } 701 } 703 rpc nsf-capability-query { 704 description 705 "Description of the capabilities that the 706 Security Controller requests to the DMS"; 707 input { 708 container query-nsf-capability { 709 description 710 "Description of the capabilities to request"; 711 uses cap:nsf-capabilities; 712 // RFC Ed.: replace YYYY with actual RFC number of 713 // draft-ietf-i2nsf-capability-data-model and remove this note. 714 reference "RFC YYYY: I2NSF Capability YANG Data Model"; 715 } 716 } 717 output { 718 container nsf-access-info { 719 description 720 "Network access information of an NSF 721 with the requested capabilities"; 722 uses nsf-access-info; 723 } 724 } 725 } 726 } 727 729 Figure 11: Registration Interface YANG Data Model 731 6. IANA Considerations 733 This document requests IANA to register the following URI in the 734 "IETF XML Registry" [RFC3688]: 736 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface 737 Registrant Contact: The IESG. 738 XML: N/A; the requested URI is an XML namespace. 740 This document requests IANA to register the following YANG module in 741 the "YANG Module Names" registry [RFC7950][RFC8525]: 743 Name: ietf-i2nsf-reg-interface 744 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface 745 Prefix: nsfreg 746 Reference: RFC XXXX 748 // RFC Ed.: replace XXXX with actual RFC number and remove 749 // this note 751 7. Security Considerations 753 The YANG module specified in this document defines a data schema 754 designed to be accessed through network management protocols such as 755 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 756 the secure transport layer, and the required secure transport is 757 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 758 and the required secure transport is TLS [RFC8446]. 760 The NETCONF access control model [RFC8341] provides a means of 761 restricting access to specific NETCONF or RESTCONF users to a 762 preconfigured subset of all available NETCONF or RESTCONF protocol 763 operations and content. 765 There are a number of data nodes defined in this YANG module that are 766 writable/creatable/deletable (i.e., config true, which is the 767 default). These data nodes MAY be considered sensitive or vulnerable 768 in some network environments. Write operations (e.g., edit-config) 769 to these data nodes without proper protection can have a negative 770 effect on network operations. These are the subtrees and data nodes 771 and their sensitivity/vulnerability: 773 * nsf-registrations: The attacker MAY exploit this to register a 774 compromised or malicious NSF instead of a legitimate NSF with the 775 Security Controller. 777 * nsf-performance-capability: The attacker MAY provide incorrect 778 information of the performance capability of any target NSF by 779 illegally modifying this. 781 * nsf-capability-info: The attacker MAY provide incorrect 782 information of the security capability of any target NSF by 783 illegally modifying this. 785 * nsf-access-info: The attacker MAY provide incorrect network access 786 information of any target NSF by illegally modifying this. 788 Some of the readable data nodes in this YANG module MAY be considered 789 sensitive or vulnerable in some network environments. It is thus 790 important to control read access (e.g., via get, get-config, or 791 notification) to these data nodes. These are the subtrees and data 792 nodes and their sensitivity/vulnerability: 794 * nsf-registrations: The attacker MAY try to gather some sensitive 795 information of a registered NSF by sniffing this. 797 * nsf-performance-capability: The attacker MAY gather the 798 performance capability information of any target NSF and misuse 799 the information for subsequent attacks. 801 * nsf-capability-info: The attacker MAY gather the security 802 capability information of any target NSF and misuse the 803 information for subsequent attacks. 805 * nsf-access-info: The attacker MAY gather the network access 806 information of any target NSF and misuse the information for 807 subsequent attacks. 809 The RPC operation in this YANG module MAY be considered sensitive or 810 vulnerable in some network environments. It is thus important to 811 control access to this operation. The following is the operation and 812 its sensitivity/vulnerability: 814 * nsf-capability-query: The attacker MAY exploit this RPC operation 815 to deteriorate the availability of the DMS and/or gather the 816 information of some interested NSFs from the DMS. 818 8. References 820 8.1. Normative References 822 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 823 Requirement Levels", BCP 14, RFC 2119, 824 DOI 10.17487/RFC2119, March 1997, 825 . 827 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 828 DOI 10.17487/RFC3688, January 2004, 829 . 831 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 832 and A. Bierman, Ed., "Network Configuration Protocol 833 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 834 . 836 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 837 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 838 . 840 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 841 RFC 6991, DOI 10.17487/RFC6991, July 2013, 842 . 844 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 845 RFC 7950, DOI 10.17487/RFC7950, August 2016, 846 . 848 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 849 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 850 . 852 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 853 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 854 May 2017, . 856 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 857 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 858 . 860 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 861 Access Control Model", STD 91, RFC 8341, 862 DOI 10.17487/RFC8341, March 2018, 863 . 865 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 866 Documents Containing YANG Data Models", BCP 216, RFC 8407, 867 DOI 10.17487/RFC8407, October 2018, 868 . 870 [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 871 S., and N. Bahadur, "A YANG Data Model for the Routing 872 Information Base (RIB)", RFC 8431, DOI 10.17487/RFC8431, 873 September 2018, . 875 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 876 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 877 . 879 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 880 and R. Wilton, "YANG Library", RFC 8525, 881 DOI 10.17487/RFC8525, March 2019, 882 . 884 [I-D.ietf-i2nsf-capability-data-model] 885 Hares, S., Jeong, J. (., Kim, J. (., Moskowitz, R., and Q. 886 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 887 Internet-Draft, draft-ietf-i2nsf-capability-data-model-17, 888 14 August 2021, . 891 8.2. Informative References 893 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 894 Reserved for Documentation", RFC 3849, 895 DOI 10.17487/RFC3849, July 2004, 896 . 898 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 899 Reserved for Documentation", RFC 5737, 900 DOI 10.17487/RFC5737, January 2010, 901 . 903 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 904 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 905 eXtensible Local Area Network (VXLAN): A Framework for 906 Overlaying Virtualized Layer 2 Networks over Layer 3 907 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 908 . 910 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 911 Kumar, "Framework for Interface to Network Security 912 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 913 . 915 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 916 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 917 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 918 Model", Work in Progress, Internet-Draft, draft-ietf- 919 i2nsf-nsf-monitoring-data-model-08, 29 April 2021, 920 . 923 [RFC9061] Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 924 Garcia, "A YANG Data Model for IPsec Flow Protection Based 925 on Software-Defined Networking (SDN)", RFC 9061, 926 DOI 10.17487/RFC9061, July 2021, 927 . 929 [I-D.ietf-nvo3-vxlan-gpe] 930 (Editor), F. M., (editor), L. K., and U. E. (editor), 931 "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Work 932 in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-11, 933 6 March 2021, . 936 [nfv-framework] 937 "Network Functions Virtualisation (NFV); Architectureal 938 Framework", ETSI GS NFV 002 ETSI GS NFV 002 V1.1.1, 939 October 2013. 941 Appendix A. XML Examples of I2NSF Registration Interface Data Model 943 This section describes XML examples of the I2NSF Registration 944 Interface data model under the assumption of registering several 945 types of NSFs and querying NSF capability. 947 A.1. Example 1: Registration for the Capabilities of a General Firewall 949 This section shows an XML example for registering the capabilities of 950 a general firewall in either IPv4 networks [RFC5737] or IPv6 networks 951 [RFC3849]. 953 956 957 general_firewall_capability 958 959 960 961 962 cap:next-header 963 cap:source-address 964 cap:destination-address 965 cap:source-port-number 966 cap:destination-port-number 967 968 969 970 971 cap:pass 972 973 974 cap:drop 975 976 977 cap:mirror 978 979 980 cap:pass 981 982 983 cap:drop 984 985 986 cap:mirror 987 988 990 991 992 993 1000 994 5000 995 996 997 998 1000 999 5000 1000 1001 1002 1000 1003 5000 1004 1005 1006 1007 1008 1009 general_firewall 1010 192.0.2.11 1011 3000 1012 1013 1014 1016 Figure 12: Configuration XML for Registration of a General 1017 Firewall in an IPv4 Network 1019 Figure 12 shows the configuration XML for registering a general 1020 firewall in an IPv4 network [RFC5737] and its capabilities as 1021 follows. 1023 1. The instance name of the NSF is general_firewall. 1025 2. The NSF can inspect IPv4 protocol header field, source 1026 address(es), and destination address(es) 1028 3. The NSF can inspect the port number(s) for the transport layer 1029 protocol, i.e., TCP. 1031 4. The NSF can determine whether the packets are allowed to pass, 1032 drop, or mirror. 1034 5. The NSF can support IPsec not through IKEv2, but through a 1035 Security Controller [RFC9061]. 1037 6. The NSF can have processing power and bandwidth. 1039 7. The IPv4 address of the NSF is 192.0.2.11. 1041 8. The port of the NSF is 3000. 1043 1046 1047 general_firewall_capability 1048 1049 1050 1051 1052 cap:next-header 1053 cap:source-address 1054 cap:destination-address 1055 cap:source-port-number 1056 cap:destination-port-number 1057 1058 1059 1060 1061 cap:pass 1062 1063 1064 cap:drop 1065 1066 1067 cap:mirror 1068 1069 1070 cap:pass 1071 1072 1073 cap:drop 1074 1075 1076 cap:mirror 1077 1078 1079 1080 1081 1082 1000 1083 5000 1084 1085 1086 1087 1000 1088 5000 1089 1090 1091 1000 1092 5000 1093 1094 1095 1096 1097 1098 general_firewall 1099 2001:DB8:0:1::11 1100 3000 1101 1102 1103 1105 Figure 13: Configuration XML for Registration of a General 1106 Firewall in an IPv6 Network 1108 In addition, Figure 13 shows the configuration XML for registering a 1109 general firewall in an IPv6 network [RFC3849] and its capabilities as 1110 follows. 1112 1. The instance name of the NSF is general_firewall. 1114 2. The NSF can inspect IPv6 next header, flow direction, source 1115 address(es), and destination address(es) 1117 3. The NSF can inspect the port number(s) and flow direction for the 1118 transport layer protocol, i.e., TCP and UDP. 1120 4. The NSF can determine whether the packets are allowed to pass, 1121 drop, or mirror. 1123 5. The NSF can have processing power and bandwidth. 1125 6. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1127 7. The port of the NSF is 3000. 1129 A.2. Example 2: Registration for the Capabilities of a Time-based 1130 Firewall 1132 This section shows an XML example for registering the capabilities of 1133 a time-based firewall in either IPv4 networks [RFC5737] or IPv6 1134 networks [RFC3849]. 1136 1139 1140 time_based_firewall_capability 1141 1142 1143 1144 cap:absolute-time 1145 cap:periodic-time 1146 1147 1148 1149 cap:ipv4-protocol 1150 cap:source-address 1151 cap:destination-address 1152 cap:source-port-number 1153 cap:destination-port-number 1154 1155 1156 1157 1158 cap:pass 1159 1160 1161 cap:drop 1162 1163 1164 cap:mirror 1165 1166 1167 cap:pass 1168 1169 1170 cap:drop 1171 1172 1173 cap:mirror 1174 1175 1176 1177 1178 1179 1000 1180 5000 1181 1182 1183 1184 1000 1185 5000 1186 1187 1188 1000 1189 5000 1190 1191 1192 1193 1194 1195 time_based_firewall 1196 192.0.2.11 1197 3000 1198 1199 1200 1202 Figure 14: Configuration XML for Registration of a Time-based 1203 Firewall in an IPv4 Network 1205 Figure 14 shows the configuration XML for registering a time-based 1206 firewall in an IPv4 network [RFC5737] and its capabilities as 1207 follows. 1209 1. The instance name of the NSF is time_based_firewall. 1211 2. The NSF can enforce the security policy rule according to 1212 absolute time and periodic time. 1214 3. The NSF can inspect the IPv4 protocol header field, flow 1215 direction, source address(es), and destination address(es). 1217 4. The NSF can determine whether the packets are allowed to pass, 1218 drop, or mirror. 1220 5. The NSF can have processing power and bandwidth. 1222 6. The IPv4 address of the NSF is 192.0.2.11. 1224 7. The port of the NSF is 3000. 1226 1229 1230 time_based_firewall_capability 1231 1232 1233 1234 cap:absolute-time 1235 cap:periodic-time 1236 1237 1238 1239 cap:ipv6-protocol 1240 cap:source-address 1241 cap:destination-address 1242 cap:source-port-number 1243 cap:destination-port-number 1244 1245 1246 1247 1248 cap:pass 1249 1250 1251 cap:drop 1252 1253 1254 cap:mirror 1255 1256 1257 cap:pass 1258 1259 1260 cap:drop 1261 1262 1263 cap:mirror 1264 1265 1266 1267 1268 1269 1000 1270 5000 1271 1272 1273 1274 1000 1275 5000 1276 1277 1278 1000 1279 5000 1281 1282 1283 1284 1285 1286 time_based_firewall 1287 2001:DB8:0:1::11 1288 3000 1289 1290 1291 1293 Figure 15: Configuration XML for Registration of a Time-based 1294 Firewall in an IPv6 Network 1296 In addition, Figure 15 shows the configuration XML for registering a 1297 time-based firewall in an IPv6 network [RFC3849] and its capabilities 1298 as follows. 1300 1. The instance name of the NSF is time_based_firewall. 1302 2. The NSF can enforce the security policy rule according to 1303 absolute time and periodic time. 1305 3. The NSF can inspect the IPv6 protocol header field, flow 1306 direction, source address(es), and destination address(es).. 1308 4. The NSF can determine whether the packets are allowed to pass, 1309 drop, or mirror. 1311 5. The NSF can have processing power and bandwidth. 1313 6. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1315 7. The port of the NSF is 3000. 1317 A.3. Example 3: Registration for the Capabilities of a Web Filter 1319 This section shows an XML example for registering the capabilities of 1320 a web filter in either IPv4 networks [RFC5737] or IPv6 networks 1321 [RFC3849]. 1323 1326 1327 web_filter 1328 1329 1330 1331 1332 cap:user-defined 1333 1334 1335 1336 1337 cap:pass 1338 1339 1340 cap:drop 1341 1342 1343 cap:mirror 1344 1345 1346 cap:pass 1347 1348 1349 cap:drop 1350 1351 1352 cap:mirror 1353 1354 1355 1356 1357 1358 1000 1359 5000 1360 1361 1362 1363 1000 1364 5000 1365 1366 1367 1000 1368 5000 1369 1370 1371 1372 1373 1374 web_filter 1375 192.0.2.11 1376 3000 1378 1379 1380 1382 Figure 16: Configuration XML for Registration of a Web Filter in 1383 an IPv4 Network 1385 Figure 16 shows the configuration XML for registering a web filter in 1386 an IPv4 network [RFC5737] and its capabilities are as follows. 1388 1. The instance name of the NSF is web_filter. 1390 2. The NSF can inspect URL from a pre-defined database or a added 1391 new URL by user (user-defined). 1393 3. The NSF can determine whether the packets are allowed to pass, 1394 drop, or mirror. 1396 4. The NSF can have processing power and bandwidth. 1398 5. The IPv4 address of the NSF is 192.0.2.11. 1400 6. The port of the NSF is 3000. 1402 1405 1406 web_filter 1407 1408 1409 1410 1411 cap:user-defined 1412 cap:pre-defined 1413 1414 1415 1416 1417 cap:pass 1418 1419 1420 cap:drop 1421 1422 1423 cap:mirror 1424 1425 1426 cap:pass 1427 1428 1429 cap:drop 1430 1431 1432 cap:mirror 1433 1434 1435 1436 1437 1438 1000 1439 5000 1440 1441 1442 1443 1000 1444 5000 1445 1446 1447 1000 1448 5000 1449 1450 1451 1452 1453 1454 web_filter 1455 2001:DB8:0:1::11 1456 3000 1457 1458 1459 1461 Figure 17: Configuration XML for Registration of a Web Filter in 1462 an IPv6 Network 1464 In addition, Figure 17 shows the configuration XML for registering a 1465 web filter in an IPv6 network [RFC3849] and its capabilities are as 1466 follows. 1468 1. The instance name of the NSF is web_filter. 1470 2. The NSF can inspect URL from a pre-defined database or a added 1471 new URL by user (user-defined). 1473 3. The NSF can determine whether the packets are allowed to pass, 1474 drop, or mirror. 1476 4. The NSF can have processing power and bandwidth. 1478 5. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1480 6. The port of the NSF is 3000. 1482 A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE 1483 Filter 1485 This section shows an XML example for registering the capabilities of 1486 a VoIP/VoLTE filter in either IPv4 networks [RFC5737] or IPv6 1487 networks [RFC3849]. 1489 1492 1493 voip_volte_filter 1494 1495 1496 1497 1498 cap:call-id 1499 1500 1501 1502 1503 cap:pass 1504 1505 1506 cap:drop 1507 1508 1509 cap:mirror 1510 1511 1512 cap:pass 1513 1514 1515 cap:drop 1516 1517 1518 cap:mirror 1519 1520 1522 1523 1524 1525 1000 1526 5000 1527 1528 1529 1530 1000 1531 5000 1532 1533 1534 1000 1535 5000 1536 1537 1538 1539 1540 1541 voip_volte_filter 1542 192.0.2.11 1543 3000 1544 1545 1546 1548 Figure 18: Configuration XML for Registration of a VoIP/VoLTE 1549 Filter in an IPv4 Network 1551 Figure 18 shows the configuration XML for registering a VoIP/VoLTE 1552 filter in an IPv4 network [RFC5737] and its capabilities are as 1553 follows. 1555 1. The instance name of the NSF is voip_volte_filter. 1557 2. The NSF can inspect a call id for VoIP/VoLTE packets. 1559 3. The NSF can determine whether the packets are allowed to pass, 1560 drop, or mirror. 1562 4. The NSF can have processing power and bandwidth. 1564 5. The IPv4 address of the NSF is 192.0.2.11. 1566 6. The port of the NSF is 3000. 1568 1571 1572 voip_volte_filter 1573 1574 1575 1576 1577 cap:call-id 1578 1579 1580 1581 1582 cap:pass 1583 1584 1585 cap:drop 1586 1587 1588 cap:mirror 1589 1590 1591 cap:pass 1592 1593 1594 cap:drop 1595 1596 1597 cap:mirror 1598 1599 1600 1601 1602 1603 1000 1604 5000 1605 1606 1607 1608 1000 1609 5000 1610 1611 1612 1000 1613 5000 1614 1615 1617 1618 1619 1620 voip_volte_filter 1621 2001:DB8:0:1::11 1622 3000 1623 1624 1625 1627 Figure 19: Configuration XML for Registration of a VoIP/VoLTE 1628 Filter in an IPv6 Network 1630 Figure 19 shows the configuration XML for registering a VoIP/VoLTE 1631 filter in an IPv6 network [RFC3849] and its capabilities are as 1632 follows. 1634 1. The instance name of the NSF is voip_volte_filter. 1636 2. The NSF can inspect a call id for VoIP/VoLTE packets. 1638 3. The NSF can determine whether the packets are allowed to pass, 1639 drop, or mirror. 1641 4. The NSF can have processing power and bandwidth. 1643 5. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1645 6. The port of the NSF is 3000. 1647 A.5. Example 5: Registration for the Capabilities of a DDoS Mitigator 1649 This section shows an XML example for registering the capabilities of 1650 a DDoS mitigator in either IPv4 networks [RFC5737] or IPv6 networks 1651 [RFC3849]. 1653 1656 1657 anti_DDoS 1658 1659 1660 1661 1662 1663 cap:packet-rate 1664 1665 1666 cap:flow-rate 1667 1668 1669 cap:byte-rate 1670 1671 1672 1673 1674 1675 cap:pass 1676 1677 1678 cap:drop 1679 1680 1681 cap:mirror 1682 1683 1684 cap:rate-limit 1685 1686 1687 cap:pass 1688 1689 1690 cap:drop 1691 1692 1693 cap:mirror 1694 1695 1696 cap:rate-limit 1697 1698 1699 1700 1701 1702 1000 1703 5000 1704 1705 1706 1707 1000 1708 5000 1709 1710 1711 1000 1712 5000 1714 1715 1716 1717 1718 1719 1720 http_and_https_flood_mitigation 1721 1722 192.0.2.11 1723 3000 1724 1725 1726 1728 Figure 20: Configuration XML for Registration of a DDoS Mitigator 1729 in an IPv4 Network 1731 Figure 20 shows the configuration XML for registering a DDoS 1732 mitigator in an IPv4 network [RFC5737] and its capabilities are as 1733 follows. 1735 1. The instance name of the NSF is anti_DDoS. 1737 2. The NSF can detect the amount of packet, flow, and byte rate in 1738 the network for potential DDoS Attack. 1740 3. The NSF can determine whether the packets are allowed to pass, 1741 drop, or mirror. 1743 4. The NSF can have processing power and bandwidth. 1745 5. The IPv4 address of the NSF is 192.0.2.11. 1747 6. The port of the NSF is 3000. 1749 1752 1753 1754 anti_DDoS 1755 1756 1757 1758 1759 1760 1761 cap:packet-rate 1763 1764 1765 cap:flow-rate 1766 1767 1768 cap:byte-rate 1769 1770 1771 1772 1773 1774 cap:pass 1775 1776 1777 cap:drop 1778 1779 1780 cap:mirror 1781 1782 1783 cap:rate-limit 1784 1785 1786 cap:pass 1787 1788 1789 cap:drop 1790 1791 1792 cap:mirror 1793 1794 1795 cap:rate-limit 1796 1797 1798 1799 1800 1801 1000 1802 5000 1803 1804 1805 1806 1000 1807 5000 1808 1809 1810 1000 1811 5000 1812 1813 1814 1815 1816 1817 1818 anti_DDoS 1819 1820 2001:DB8:0:1::11 1821 3000 1822 1823 1824 1826 Figure 21: Configuration XML for Registration of a DDoS Mitigator 1827 in an IPv6 Network 1829 In addition, Figure 21 shows the configuration XML for registering a 1830 DDoS mitigator in an IPv6 network [RFC3849] and its capabilities are 1831 as follows. 1833 1. The instance name of the NSF is anti_DDoS. 1835 2. The NSF can detect the amount of packet, flow, and byte rate in 1836 the network for potential DDoS Attack. 1838 3. The NSF can determine whether the packets are allowed to pass, 1839 drop, mirror, or rate-limit. 1841 4. The NSF can have processing power and bandwidth. 1843 5. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1845 6. The port of the NSF is 3000. 1847 A.6. Example 6: Query for the Capabilities of a Time-based Firewall 1849 This section shows an XML example for querying the capabilities of a 1850 time-based firewall in either IPv4 networks [RFC5737] or IPv6 1851 networks [RFC3849]. 1853 1855 1858 1859 absolute-time 1860 periodic-time 1861 1862 1863 cap:ipv4-protocol 1864 cap:source-address 1865 cap:destination-address 1866 1867 1868 1869 1870 cap:pass 1871 1872 1873 cap:drop 1874 1875 1876 cap:mirror 1877 1878 1879 cap:pass 1880 1881 1882 cap:drop 1883 1884 1885 cap:mirror 1886 1887 1888 1889 1890 1892 1894 1896 time-based-firewall 1897 192.0.2.11 1898 3000 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 3000. 1910 1912 1915 1916 absolute-time 1917 periodic-time 1918 1919 1920 cap:ipv6-protocol 1921 cap:source-address 1922 cap:destination-address 1923 1924 1925 1926 1927 cap:pass 1928 1929 1930 cap:drop 1931 1932 1933 cap:mirror 1934 1935 1936 cap:pass 1937 1938 1939 cap:drop 1940 1941 1942 cap:mirror 1943 1944 1945 1946 1947 1949 1951 1953 time-based-firewall 1954 2001:DB8:0:1::11 1955 3000 1956 1957 1959 Figure 23: Configuration XML for Query of a Time-based Firewall 1960 in an IPv6 Network 1962 In addition, Figure 23 shows the XML configuration for querying the 1963 capabilities of a time-based firewall in an IPv6 network [RFC3849]. 1964 The access information of the announced time-based firewall has the 1965 IPv6 address of 2001:DB8:0:1::11 and the port number of 3000. 1967 Appendix B. NSF Lifecycle Management in NFV Environments 1969 Network Functions Virtualization (NFV) can be used to implement I2NSF 1970 framework. In NFV environments, NSFs are deployed as virtual network 1971 functions (VNFs). Security Controller can be implemented as an 1972 Element Management (EM) of the NFV architecture, and is connected 1973 with the VNF Manager (VNFM) via the Ve-Vnfm interface 1974 [nfv-framework]. Security Controller can use this interface for the 1975 purpose of the lifecycle management of NSFs. If some NSFs need to be 1976 instantiated to enforce security policies in the I2NSF framework, 1977 Security Controller could request the VNFM to instantiate them 1978 through the Ve-Vnfm interface. Or if an NSF, running as a VNF, is 1979 not used by any traffic flows for a time period, Security Controller 1980 MAY request deinstantiating it through the interface for efficient 1981 resource utilization. 1983 Appendix C. Acknowledgments 1985 This work was supported by Institute of Information & Communications 1986 Technology Planning & Evaluation (IITP) grant funded by the Korea 1987 MSIT (Ministry of Science and ICT) (No. 2016-0-00078, Cloud Based 1988 Security Intelligence Technology Development for the Customized 1989 Security Service Provisioning). This work was supported in part by 1990 the IITP (2020-0-00395, Standard Development of Blockchain based 1991 Network Management Automation Technology). 1993 Appendix D. Contributors 1995 This document is made by the group effort of I2NSF working group. 1996 Many people actively contributed to this document, such as Reshad 1997 Rahman. The authors sincerely appreciate their contributions. 1999 The following are co-authors of this document: 2001 Patrick Lingga Department of Electrical and Computer Engineering 2002 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 2003 16419 Republic of Korea EMail: patricklink@skku.edu 2005 Jinyong Tim Kim Department of Electronic, Electrical and Computer 2006 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 2007 Gyeonggi-do 16419 Republic of Korea EMail: timkim@skku.edu 2009 Chaehong Chung Department of Electronic, Electrical and Computer 2010 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 2011 Gyeonggi-do 16419 Republic of Korea EMail: darkhong@skku.edu 2013 Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA EMail: 2014 shares@ndzh.com 2016 Diego R. Lopez Telefonica I+D Jose Manuel Lara, 9 Seville, 41013 2017 Spain EMail: diego.r.lopez@telefonica.com 2019 Appendix E. Changes from draft-ietf-i2nsf-registration-interface-dm-10 2021 The following changes are made from draft-ietf-i2nsf-registration- 2022 interface-dm-10: 2024 * This version has been updated to synchronize with other I2NSF 2025 documents. 2027 Authors' Addresses 2029 Sangwon Hyun (editor) 2030 Department of Computer Engineering 2031 Myongji University 2032 116 Myongji-ro, Cheoin-gu 2033 Yongin 2034 Gyeonggi-do 2035 17058 2036 Republic of Korea 2038 Email: shyun@mju.ac.kr 2039 Jaehoon Paul Jeong (editor) 2040 Department of Computer Science and Engineering 2041 Sungkyunkwan University 2042 2066 Seobu-Ro, Jangan-Gu 2043 Suwon 2044 Gyeonggi-Do 2045 16419 2046 Republic of Korea 2048 Phone: +82 31 299 4957 2049 Email: pauljeong@skku.edu 2050 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2052 Taekyun Roh 2053 Department of Electronic, Electrical and Computer Engineering 2054 Sungkyunkwan University 2055 2066 Seobu-Ro, Jangan-Gu 2056 Suwon 2057 Gyeonggi-Do 2058 16419 2059 Republic of Korea 2061 Phone: +82 31 290 7222 2062 Email: tkroh0198@skku.edu 2064 Sarang Wi 2065 Department of Electronic, Electrical and Computer Engineering 2066 Sungkyunkwan University 2067 2066 Seobu-Ro, Jangan-Gu 2068 Suwon 2069 Gyeonggi-Do 2070 16419 2071 Republic of Korea 2073 Phone: +82 31 290 7222 2074 Email: dnl9795@skku.edu 2076 Jung-Soo Park 2077 Electronics and Telecommunications Research Institute 2078 218 Gajeong-Ro, Yuseong-Gu 2079 Daejeon 2080 305-700 2081 Republic of Korea 2083 Phone: +82 42 860 6514 2084 Email: pjs@etri.re.kr