idnits 2.17.1 draft-ietf-i2nsf-registration-interface-dm-13.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 : ---------------------------------------------------------------------------- No issues found here. 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 (4 October 2021) is 935 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-19 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-10 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-12 Summary: 0 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: 7 April 2022 T. Roh 6 S. Wi 7 Sungkyunkwan University 8 J. Park 9 ETRI 10 4 October 2021 12 I2NSF Registration Interface YANG Data Model 13 draft-ietf-i2nsf-registration-interface-dm-13 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 7 April 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 . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . 26 84 A.3. Example 3: Registration for the Capabilities of a Web 85 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . . . . . . . . . 41 92 Appendix B. NSF Lifecycle Management in NFV Environments . . . . 43 93 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 44 94 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 44 95 Appendix E. Changes from 96 draft-ietf-i2nsf-registration-interface-dm-11 . . . . . . 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: 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* [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 makes a reference to 507 [I-D.ietf-i2nsf-capability-data-model]. 509 file "ietf-i2nsf-reg-interface@2021-10-04.yang" 510 module ietf-i2nsf-reg-interface { 511 yang-version 1.1; 513 namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"; 514 prefix nsfreg; 516 //RFC Ed.: replace occurences of XXXX with actual RFC number and 517 //remove this note 519 import ietf-inet-types { 520 prefix inet; 521 reference "RFC 6991"; 522 } 523 import ietf-i2nsf-capability { 524 prefix nsfcap; 525 // RFC Ed.: replace YYYY with actual RFC number of 526 // draft-ietf-i2nsf-capability-data-model and remove this note. 527 reference "RFC YYYY: I2NSF Capability YANG Data Model"; 528 } 530 organization 531 "IETF I2NSF (Interface to Network Security Functions) 532 Working Group"; 534 contact 535 "WG Web: 536 WG List: 538 Editor: Sangwon Hyun 539 541 Editor: Jaehoon Paul Jeong 542 "; 544 description 545 "This module defines a YANG data model for I2NSF 546 Registration Interface. 548 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 549 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 550 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 551 document are to be interpreted as described in BCP 14 552 (RFC 2119) (RFC 8174) when, and only when, they appear 553 in all capitals, as shown here. 555 Copyright (c) 2021 IETF Trust and the persons 556 identified as authors of the code. All rights reserved. 558 Redistribution and use in source and binary forms, with or 559 without modification, is permitted pursuant to, and subject 560 to the license terms contained in, the Simplified BSD License 561 set forth in Section 4.c of the IETF Trust's Legal Provisions 562 Relating to IETF Documents 563 (https://trustee.ietf.org/license-info). 565 This version of this YANG module is part of RFC XXXX; see 566 the RFC itself for full legal notices."; 568 revision "2021-10-04" { 569 description "Initial revision"; 570 reference 571 "RFC XXXX: I2NSF Registration Interface YANG Data Model"; 572 // RFC Ed.: replace XXXX with actual RFC number and remove 573 // this note 574 } 576 grouping nsf-performance-capability { 577 description 578 "Description of the performance capabilities of an NSF"; 580 container processing { 581 description 582 "Processing power of an NSF in the unit of GHz (gigahertz)"; 584 leaf processing-average { 585 type uint16; 586 units "GHz"; 587 description 588 "Average processing power"; 589 } 590 leaf processing-peak { 591 type uint16; 592 units "GHz"; 593 description 594 "Peak processing power"; 595 } 596 } 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 } 620 container inbound { 621 description 622 "Inbound network bandwidth"; 623 leaf inbound-average { 624 type uint32; 625 units "Mbps"; 626 description 627 "Average inbound bandwidth"; 628 } 629 leaf inbound-peak { 630 type uint32; 631 units "Mbps"; 632 description 633 "Peak inbound bandwidth"; 634 } 635 } 636 } 637 } 639 grouping nsf-capability-info { 640 description 641 "Capability description of an NSF"; 642 container security-capability { 643 description 644 "Description of the security capabilities of an NSF"; 645 uses nsfcap:nsf-capabilities; 646 reference "RFC YYYY: I2NSF Capability YANG Data Model"; 647 // RFC Ed.: replace YYYY with actual RFC number of 648 // draft-ietf-i2nsf-capability-data-model and remove this note. 649 } 650 container performance-capability { 651 description 652 "Description of the performance capabilities of an NSF"; 653 uses nsf-performance-capability; 654 } 655 } 657 grouping nsf-access-info { 658 description 659 "Information required to access an NSF"; 660 leaf ip { 661 type inet:ip-address-no-zone; 662 description 663 "Either an IPv4 address or an IPv6 address of this NSF"; 664 } 665 leaf port { 666 type inet:port-number; 667 description 668 "Port available on this NSF"; 669 } 670 } 672 container nsf-registrations { 673 description 674 "Information of an NSF that DMS registers 675 to Security Controller"; 676 list nsf-information { 677 key "nsf-name"; 678 description 679 "Required information for registration"; 680 leaf nsf-name { 681 type string; 682 description 683 "The name of this registered NSF. The NSF name MUST be unique 684 to identify the NSF with the capability. The name can be an 685 arbitrary string including FQDN (Fully Qualified Domain 686 Name)."; 687 } 688 container nsf-capability-info { 689 description 690 "Capability description of this NSF"; 691 uses nsf-capability-info; 692 } 693 container nsf-access-info { 694 description 695 "Network access information of this NSF"; 696 uses nsf-access-info; 697 } 698 } 699 } 701 rpc nsf-capability-query { 702 description 703 "Description of the capabilities that the 704 Security Controller requests to the DMS"; 705 input { 706 container query-nsf-capability { 707 description 708 "Description of the capabilities to request"; 709 uses nsfcap:nsf-capabilities; 710 reference "RFC YYYY: I2NSF Capability YANG Data Model"; 711 //RFC Ed.: replace YYYY with actual RFC number of 712 //draft-ietf-i2nsf-capability-data-model and remove this note. 713 } 714 } 715 output { 716 container nsf-access-info { 717 description 718 "Network access information of an NSF 719 with the requested capabilities"; 720 leaf nsf-name { 721 type string; 722 description 723 "The name of this registered NSF. The NSF name MUST be 724 unique to identify the NSF with the capability. The name 725 can be an arbitrary string including FQDN (Fully Qualified 726 Domain Name)."; 727 } 728 uses nsf-access-info; 729 } 730 } 731 } 732 } 733 735 Figure 11: Registration Interface YANG Data Model 737 6. IANA Considerations 739 This document requests IANA to register the following URI in the 740 "IETF XML Registry" [RFC3688]: 742 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface 743 Registrant Contact: The IESG. 744 XML: N/A; the requested URI is an XML namespace. 746 This document requests IANA to register the following YANG module in 747 the "YANG Module Names" registry [RFC7950][RFC8525]: 749 Name: ietf-i2nsf-reg-interface 750 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface 751 Prefix: nsfreg 752 Reference: RFC XXXX 754 // RFC Ed.: replace XXXX with actual RFC number and remove 755 // this note 757 7. Security Considerations 759 The YANG module specified in this document defines a data schema 760 designed to be accessed through network management protocols such as 761 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 762 the secure transport layer, and the required secure transport is 763 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 764 and the required secure transport is TLS [RFC8446]. 766 The NETCONF access control model [RFC8341] provides a means of 767 restricting access to specific NETCONF or RESTCONF users to a 768 preconfigured subset of all available NETCONF or RESTCONF protocol 769 operations and content. 771 There are a number of data nodes defined in this YANG module that are 772 writable/creatable/deletable (i.e., config true, which is the 773 default). These data nodes MAY be considered sensitive or vulnerable 774 in some network environments. Write operations (e.g., edit-config) 775 to these data nodes without proper protection can have a negative 776 effect on network operations. These are the subtrees and data nodes 777 and their sensitivity/vulnerability: 779 * nsf-registrations: The attacker MAY exploit this to register a 780 compromised or malicious NSF instead of a legitimate NSF with the 781 Security Controller. 783 * nsf-performance-capability: The attacker MAY provide incorrect 784 information of the performance capability of any target NSF by 785 illegally modifying this. 787 * nsf-capability-info: The attacker MAY provide incorrect 788 information of the security capability of any target NSF by 789 illegally modifying this. 791 * nsf-access-info: The attacker MAY provide incorrect network access 792 information of any target NSF by illegally modifying this. 794 Some of the readable data nodes in this YANG module MAY be considered 795 sensitive or vulnerable in some network environments. It is thus 796 important to control read access (e.g., via get, get-config, or 797 notification) to these data nodes. These are the subtrees and data 798 nodes and their sensitivity/vulnerability: 800 * nsf-registrations: The attacker MAY try to gather some sensitive 801 information of a registered NSF by sniffing this. 803 * nsf-performance-capability: The attacker MAY gather the 804 performance capability information of any target NSF and misuse 805 the information for subsequent attacks. 807 * nsf-capability-info: The attacker MAY gather the security 808 capability information of any target NSF and misuse the 809 information for subsequent attacks. 811 * nsf-access-info: The attacker MAY gather the network access 812 information of any target NSF and misuse the information for 813 subsequent attacks. 815 The RPC operation in this YANG module MAY be considered sensitive or 816 vulnerable in some network environments. It is thus important to 817 control access to this operation. The following is the operation and 818 its sensitivity/vulnerability: 820 * nsf-capability-query: The attacker MAY exploit this RPC operation 821 to deteriorate the availability of the DMS and/or gather the 822 information of some interested NSFs from the DMS. 824 8. References 826 8.1. Normative References 828 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 829 Requirement Levels", BCP 14, RFC 2119, 830 DOI 10.17487/RFC2119, March 1997, 831 . 833 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 834 DOI 10.17487/RFC3688, January 2004, 835 . 837 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 838 and A. Bierman, Ed., "Network Configuration Protocol 839 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 840 . 842 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 843 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 844 . 846 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 847 RFC 6991, DOI 10.17487/RFC6991, July 2013, 848 . 850 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 851 RFC 7950, DOI 10.17487/RFC7950, August 2016, 852 . 854 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 855 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 856 . 858 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 859 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 860 May 2017, . 862 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 863 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 864 . 866 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 867 Access Control Model", STD 91, RFC 8341, 868 DOI 10.17487/RFC8341, March 2018, 869 . 871 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 872 and R. Wilton, "Network Management Datastore Architecture 873 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 874 . 876 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 877 Documents Containing YANG Data Models", BCP 216, RFC 8407, 878 DOI 10.17487/RFC8407, October 2018, 879 . 881 [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 882 S., and N. Bahadur, "A YANG Data Model for the Routing 883 Information Base (RIB)", RFC 8431, DOI 10.17487/RFC8431, 884 September 2018, . 886 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 887 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 888 . 890 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 891 and R. Wilton, "YANG Library", RFC 8525, 892 DOI 10.17487/RFC8525, March 2019, 893 . 895 [I-D.ietf-i2nsf-capability-data-model] 896 Hares, S., Jeong, J. (., Kim, J. (., Moskowitz, R., and Q. 897 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 898 Internet-Draft, draft-ietf-i2nsf-capability-data-model-19, 899 28 September 2021, . 902 8.2. Informative References 904 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 905 Reserved for Documentation", RFC 3849, 906 DOI 10.17487/RFC3849, July 2004, 907 . 909 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 910 Reserved for Documentation", RFC 5737, 911 DOI 10.17487/RFC5737, January 2010, 912 . 914 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 915 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 916 eXtensible Local Area Network (VXLAN): A Framework for 917 Overlaying Virtualized Layer 2 Networks over Layer 3 918 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 919 . 921 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 922 Kumar, "Framework for Interface to Network Security 923 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 924 . 926 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 927 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 928 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 929 Model", Work in Progress, Internet-Draft, draft-ietf- 930 i2nsf-nsf-monitoring-data-model-10, 15 September 2021, 931 . 934 [RFC9061] Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 935 Garcia, "A YANG Data Model for IPsec Flow Protection Based 936 on Software-Defined Networking (SDN)", RFC 9061, 937 DOI 10.17487/RFC9061, July 2021, 938 . 940 [I-D.ietf-nvo3-vxlan-gpe] 941 (Editor), F. M., (editor), L. K., and U. E. (editor), 942 "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Work 943 in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-12, 944 22 September 2021, . 947 [nfv-framework] 948 "Network Functions Virtualisation (NFV); Architectureal 949 Framework", ETSI GS NFV 002 ETSI GS NFV 002 V1.1.1, 950 October 2013. 952 Appendix A. XML Examples of I2NSF Registration Interface Data Model 954 This section describes XML examples of the I2NSF Registration 955 Interface data model under the assumption of registering several 956 types of NSFs and querying NSF capability. 958 A.1. Example 1: Registration for the Capabilities of a General Firewall 960 This section shows an XML example for registering the capabilities of 961 a general firewall in either IPv4 networks [RFC5737] or IPv6 networks 962 [RFC3849]. 964 967 968 general_firewall 969 970 971 972 973 nsfcap:next-header 974 nsfcap:source-address 975 nsfcap:destination-address 976 nsfcap:source-port-number 977 nsfcap:destination-port-number 978 979 980 981 982 nsfcap:pass 983 984 985 nsfcap:drop 986 987 988 nsfcap:mirror 989 990 991 nsfcap:pass 992 993 994 nsfcap:drop 995 996 997 nsfcap:mirror 998 999 1000 1001 1002 1003 1000 1004 5000 1005 1006 1007 1008 1000 1009 5000 1010 1011 1012 1000 1013 5000 1014 1015 1016 1017 1018 1019 192.0.2.11 1020 49152 1021 1022 1023 1025 Figure 12: Configuration XML for Registration of a General 1026 Firewall in an IPv4 Network 1028 Figure 12 shows the configuration XML for registering a general 1029 firewall in an IPv4 network [RFC5737] and its capabilities as 1030 follows. 1032 1. The instance name of the NSF is general_firewall. 1034 2. The NSF can inspect IPv4 protocol header field, source 1035 address(es), and destination address(es) 1037 3. The NSF can inspect the port number(s) for the transport layer 1038 protocol, i.e., TCP. 1040 4. The NSF can determine whether the packets are allowed to pass, 1041 drop, or mirror. 1043 5. The NSF can support IPsec not through IKEv2, but through a 1044 Security Controller [RFC9061]. 1046 6. The NSF can have processing power and bandwidth. 1048 7. The IPv4 address of the NSF is 192.0.2.11. 1050 8. The port of the NSF is 49152. 1052 1055 1056 general_firewall 1057 1058 1059 1060 1061 nsfcap:next-header 1062 nsfcap:source-address 1063 nsfcap:destination-address 1064 nsfcap:source-port-number 1065 nsfcap:destination-port-number 1066 1067 1068 1069 1070 nsfcap:pass 1071 1072 1073 nsfcap:drop 1074 1075 1076 nsfcap:mirror 1077 1078 1079 nsfcap:pass 1080 1081 1082 nsfcap:drop 1083 1084 1085 nsfcap:mirror 1086 1087 1088 1089 1090 1091 1000 1092 5000 1093 1094 1095 1096 1000 1097 5000 1098 1099 1100 1000 1101 5000 1102 1103 1104 1105 1106 1107 2001:DB8:0:1::11 1108 49152 1109 1110 1111 1113 Figure 13: Configuration XML for Registration of a General 1114 Firewall in an IPv6 Network 1116 In addition, Figure 13 shows the configuration XML for registering a 1117 general firewall in an IPv6 network [RFC3849] and its capabilities as 1118 follows. 1120 1. The instance name of the NSF is general_firewall. 1122 2. The NSF can inspect IPv6 next header, flow direction, source 1123 address(es), and destination address(es) 1125 3. The NSF can inspect the port number(s) and flow direction for the 1126 transport layer protocol, i.e., TCP and UDP. 1128 4. The NSF can determine whether the packets are allowed to pass, 1129 drop, or mirror. 1131 5. The NSF can have processing power and bandwidth. 1133 6. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1135 7. The port of the NSF is 49152. 1137 A.2. Example 2: Registration for the Capabilities of a Time-based 1138 Firewall 1140 This section shows an XML example for registering the capabilities of 1141 a time-based firewall in either IPv4 networks [RFC5737] or IPv6 1142 networks [RFC3849]. 1144 1147 1148 time_based_firewall 1149 1150 1151 1152 nsfcap:absolute-time 1153 nsfcap:periodic-time 1154 1155 1156 1157 nsfcap:next-header 1158 nsfcap:source-address 1159 nsfcap:destination-address 1160 nsfcap:source-port-number 1161 nsfcap:destination-port-number 1162 1163 1164 1165 1166 nsfcap:pass 1167 1168 1169 nsfcap:drop 1170 1171 1172 nsfcap:mirror 1174 1175 1176 nsfcap:pass 1177 1178 1179 nsfcap:drop 1180 1181 1182 nsfcap:mirror 1183 1184 1185 1186 1187 1188 1000 1189 5000 1190 1191 1192 1193 1000 1194 5000 1195 1196 1197 1000 1198 5000 1199 1200 1201 1202 1203 1204 192.0.2.11 1205 49152 1206 1207 1208 1210 Figure 14: Configuration XML for Registration of a Time-based 1211 Firewall in an IPv4 Network 1213 Figure 14 shows the configuration XML for registering a time-based 1214 firewall in an IPv4 network [RFC5737] and its capabilities as 1215 follows. 1217 1. The instance name of the NSF is time_based_firewall. 1219 2. The NSF can enforce the security policy rule according to 1220 absolute time and periodic time. 1222 3. The NSF can inspect the IPv4 protocol header field, IPv4 source 1223 address(es), IPv4 destination address(es), TCP source port 1224 number(s), and TCP destination port number(s). 1226 4. The NSF can determine whether the packets are allowed to pass, 1227 drop, or mirror. 1229 5. The NSF can have processing power and bandwidth. 1231 6. The IPv4 address of the NSF is 192.0.2.11. 1233 7. The port of the NSF is 49152. 1235 1238 1239 time_based_firewall 1240 1241 1242 1243 nsfcap:absolute-time 1244 nsfcap:periodic-time 1245 1246 1247 1248 nsfcap:next-header 1249 nsfcap:source-address 1250 nsfcap:destination-address 1251 nsfcap:source-port-number 1252 nsfcap:destination-port-number 1253 1254 1255 1256 1257 nsfcap:pass 1258 1259 1260 nsfcap:drop 1261 1262 1263 nsfcap:mirror 1264 1265 1266 nsfcap:pass 1267 1268 1269 nsfcap:drop 1271 1272 1273 nsfcap:mirror 1274 1275 1276 1277 1278 1279 1000 1280 5000 1281 1282 1283 1284 1000 1285 5000 1286 1287 1288 1000 1289 5000 1290 1291 1292 1293 1294 1295 2001:DB8:0:1::11 1296 49152 1297 1298 1299 1301 Figure 15: Configuration XML for Registration of a Time-based 1302 Firewall in an IPv6 Network 1304 In addition, Figure 15 shows the configuration XML for registering a 1305 time-based firewall in an IPv6 network [RFC3849] and its capabilities 1306 as follows. 1308 1. The instance name of the NSF is time_based_firewall. 1310 2. The NSF can enforce the security policy rule according to 1311 absolute time and periodic time. 1313 3. The NSF can inspect the IPv6 next header field, IPv6 source 1314 address(es), IPv6 destination address(es), TCP source port 1315 number(s), and TCP destination port number(s). 1317 4. The NSF can determine whether the packets are allowed to pass, 1318 drop, or mirror. 1320 5. The NSF can have processing power and bandwidth. 1322 6. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1324 7. The port of the NSF is 49152. 1326 A.3. Example 3: Registration for the Capabilities of a Web Filter 1328 This section shows an XML example for registering the capabilities of 1329 a web filter in either IPv4 networks [RFC5737] or IPv6 networks 1330 [RFC3849]. 1332 1335 1336 web_filter 1337 1338 1339 1340 1341 nsfcap:user-defined 1342 1343 1344 1345 1346 nsfcap:pass 1347 1348 1349 nsfcap:drop 1350 1351 1352 nsfcap:mirror 1353 1354 1355 nsfcap:pass 1356 1357 1358 nsfcap:drop 1359 1360 1361 nsfcap:mirror 1362 1363 1364 1365 1366 1367 1000 1368 5000 1369 1370 1371 1372 1000 1373 5000 1374 1375 1376 1000 1377 5000 1378 1379 1380 1381 1382 1383 192.0.2.11 1384 49152 1385 1386 1387 1389 Figure 16: Configuration XML for Registration of a Web Filter in 1390 an IPv4 Network 1392 Figure 16 shows the configuration XML for registering a web filter in 1393 an IPv4 network [RFC5737] and its capabilities are as follows. 1395 1. The instance name of the NSF is web_filter. 1397 2. The NSF can inspect URL from a pre-defined database or a added 1398 new URL by user (user-defined). 1400 3. The NSF can determine whether the packets are allowed to pass, 1401 drop, or mirror. 1403 4. The NSF can have processing power and bandwidth. 1405 5. The IPv4 address of the NSF is 192.0.2.11. 1407 6. The port of the NSF is 49152. 1409 1412 1413 web_filter 1414 1415 1416 1417 1418 nsfcap:user-defined 1419 nsfcap:pre-defined 1420 1421 1422 1423 1424 nsfcap:pass 1425 1426 1427 nsfcap:drop 1428 1429 1430 nsfcap:mirror 1431 1432 1433 nsfcap:pass 1434 1435 1436 nsfcap:drop 1437 1438 1439 nsfcap:mirror 1440 1441 1442 1443 1444 1445 1000 1446 5000 1447 1448 1449 1450 1000 1451 5000 1452 1453 1454 1000 1455 5000 1456 1457 1458 1459 1460 1461 2001:DB8:0:1::11 1462 49152 1463 1465 1466 1468 Figure 17: Configuration XML for Registration of a Web Filter in 1469 an IPv6 Network 1471 In addition, Figure 17 shows the configuration XML for registering a 1472 web filter in an IPv6 network [RFC3849] and its capabilities are as 1473 follows. 1475 1. The instance name of the NSF is web_filter. 1477 2. The NSF can inspect URL from a pre-defined database or a added 1478 new URL by user (user-defined). 1480 3. The NSF can determine whether the packets are allowed to pass, 1481 drop, or mirror. 1483 4. The NSF can have processing power and bandwidth. 1485 5. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1487 6. The port of the NSF is 49152. 1489 A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE 1490 Filter 1492 This section shows an XML example for registering the capabilities of 1493 a VoIP/VoLTE filter in either IPv4 networks [RFC5737] or IPv6 1494 networks [RFC3849]. 1496 1499 1500 voip_volte_filter 1501 1502 1503 1504 1505 nsfcap:call-id 1506 1507 1508 1509 1510 nsfcap:pass 1511 1512 1513 nsfcap:drop 1514 1515 1516 nsfcap:mirror 1517 1518 1519 nsfcap:pass 1520 1521 1522 nsfcap:drop 1523 1524 1525 nsfcap:mirror 1526 1527 1528 1529 1530 1531 1000 1532 5000 1533 1534 1535 1536 1000 1537 5000 1538 1539 1540 1000 1541 5000 1542 1543 1544 1545 1546 1547 192.0.2.11 1548 49152 1549 1550 1551 1553 Figure 18: Configuration XML for Registration of a VoIP/VoLTE 1554 Filter in an IPv4 Network 1556 Figure 18 shows the configuration XML for registering a VoIP/VoLTE 1557 filter in an IPv4 network [RFC5737] and its capabilities are as 1558 follows. 1560 1. The instance name of the NSF is voip_volte_filter. 1562 2. The NSF can inspect a call id for VoIP/VoLTE packets. 1564 3. The NSF can determine whether the packets are allowed to pass, 1565 drop, or mirror. 1567 4. The NSF can have processing power and bandwidth. 1569 5. The IPv4 address of the NSF is 192.0.2.11. 1571 6. The port of the NSF is 49152. 1573 1576 1577 voip_volte_filter 1578 1579 1580 1581 1582 nsfcap:call-id 1583 1584 1585 1586 1587 nsfcap:pass 1588 1589 1590 nsfcap:drop 1591 1592 1593 nsfcap:mirror 1594 1595 1596 nsfcap:pass 1597 1598 1599 nsfcap:drop 1600 1601 1602 nsfcap:mirror 1603 1604 1605 1606 1607 1608 1000 1609 5000 1611 1612 1613 1614 1000 1615 5000 1616 1617 1618 1000 1619 5000 1620 1621 1622 1623 1624 1625 2001:DB8:0:1::11 1626 49152 1627 1628 1629 1631 Figure 19: Configuration XML for Registration of a VoIP/VoLTE 1632 Filter in an IPv6 Network 1634 Figure 19 shows the configuration XML for registering a VoIP/VoLTE 1635 filter in an IPv6 network [RFC3849] and its capabilities are as 1636 follows. 1638 1. The instance name of the NSF is voip_volte_filter. 1640 2. The NSF can inspect a call id for VoIP/VoLTE packets. 1642 3. The NSF can determine whether the packets are allowed to pass, 1643 drop, or mirror. 1645 4. The NSF can have processing power and bandwidth. 1647 5. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1649 6. The port of the NSF is 49152. 1651 A.5. Example 5: Registration for the Capabilities of a DDoS Mitigator 1653 This section shows an XML example for registering the capabilities of 1654 a DDoS mitigator in either IPv4 networks [RFC5737] or IPv6 networks 1655 [RFC3849]. 1657 1660 1661 anti_DDoS 1662 1663 1664 1665 1666 1667 nsfcap:packet-rate 1668 1669 1670 nsfcap:flow-rate 1671 1672 1673 nsfcap:byte-rate 1674 1675 1676 1677 1678 1679 nsfcap:pass 1680 1681 1682 nsfcap:drop 1683 1684 1685 nsfcap:mirror 1686 1687 1688 nsfcap:rate-limit 1689 1690 1691 nsfcap:pass 1692 1693 1694 nsfcap:drop 1695 1696 1697 nsfcap:mirror 1698 1699 1700 nsfcap:rate-limit 1701 1702 1703 1704 1705 1706 1000 1707 5000 1708 1709 1710 1711 1000 1712 5000 1713 1714 1715 1000 1716 5000 1717 1718 1719 1720 1721 1722 192.0.2.11 1723 49152 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 49152. 1749 1752 1753 anti_DDoS 1754 1755 1756 1757 1758 1759 nsfcap:packet-rate 1760 1761 1762 nsfcap:flow-rate 1763 1764 1765 nsfcap:byte-rate 1766 1767 1768 1769 1770 1771 nsfcap:pass 1772 1773 1774 nsfcap:drop 1775 1776 1777 nsfcap:mirror 1778 1779 1780 nsfcap:rate-limit 1781 1782 1783 nsfcap:pass 1784 1785 1786 nsfcap:drop 1787 1788 1789 nsfcap:mirror 1790 1791 1792 nsfcap:rate-limit 1793 1794 1795 1796 1797 1798 1000 1799 5000 1800 1801 1802 1803 1000 1804 5000 1805 1806 1807 1000 1808 5000 1809 1810 1811 1812 1813 1814 2001:DB8:0:1::11 1815 49152 1816 1817 1818 1820 Figure 21: Configuration XML for Registration of a DDoS Mitigator 1821 in an IPv6 Network 1823 In addition, Figure 21 shows the configuration XML for registering a 1824 DDoS mitigator in an IPv6 network [RFC3849] and its capabilities are 1825 as follows. 1827 1. The instance name of the NSF is anti_DDoS. 1829 2. The NSF can detect the amount of packet, flow, and byte rate in 1830 the network for potential DDoS Attack. 1832 3. The NSF can determine whether the packets are allowed to pass, 1833 drop, mirror, or rate-limit. 1835 4. The NSF can have processing power and bandwidth. 1837 5. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1839 6. The port of the NSF is 49152. 1841 A.6. Example 6: Query for the Capabilities of a Time-based Firewall 1843 This section shows an XML example for querying the capabilities of a 1844 time-based firewall in either IPv4 networks [RFC5737] or IPv6 1845 networks [RFC3849]. 1847 1849 1852 1853 absolute-time 1854 periodic-time 1855 1856 1857 nsfcap:next-header 1858 nsfcap:source-address 1859 nsfcap:destination-address 1860 1861 1862 1863 1864 nsfcap:pass 1865 1866 1867 nsfcap:drop 1868 1869 1870 nsfcap:mirror 1871 1872 1873 nsfcap:pass 1874 1875 1876 nsfcap:drop 1877 1878 1879 nsfcap:mirror 1880 1881 1882 1883 1884 1886 1888 1890 time_based_firewall 1891 192.0.2.11 1892 49152 1893 1894 1896 Figure 22: Configuration XML for Query of a Time-based Firewall 1897 in an IPv4 Network 1899 Figure 22 shows the XML configuration for querying the capabilities 1900 of a time-based firewall in an IPv4 network [RFC5737]. The access 1901 information of the announced time-based firewall has the IPv4 address 1902 of 192.0.2.11 and the port number of 49152. 1904 1906 1909 1910 absolute-time 1911 periodic-time 1912 1913 1914 nsfcap:next-header 1915 nsfcap:source-address 1916 nsfcap:destination-address 1917 1918 1919 1920 1921 nsfcap:pass 1922 1923 1924 nsfcap:drop 1925 1926 1927 nsfcap:mirror 1928 1929 1930 nsfcap:pass 1931 1932 1933 nsfcap:drop 1934 1935 1936 nsfcap:mirror 1938 1939 1940 1941 1942 1944 1946 1948 time_based_firewall 1949 2001:DB8:0:1::11 1950 49152 1951 1952 1954 Figure 23: Configuration XML for Query of a Time-based Firewall 1955 in an IPv6 Network 1957 In addition, Figure 23 shows the XML configuration for querying the 1958 capabilities of a time-based firewall in an IPv6 network [RFC3849]. 1959 The access information of the announced time-based firewall has the 1960 IPv6 address of 2001:DB8:0:1::11 and the port number of 49152. 1962 Appendix B. NSF Lifecycle Management in NFV Environments 1964 Network Functions Virtualization (NFV) can be used to implement I2NSF 1965 framework. In NFV environments, NSFs are deployed as virtual network 1966 functions (VNFs). Security Controller can be implemented as an 1967 Element Management (EM) of the NFV architecture, and is connected 1968 with the VNF Manager (VNFM) via the Ve-Vnfm interface 1969 [nfv-framework]. Security Controller can use this interface for the 1970 purpose of the lifecycle management of NSFs. If some NSFs need to be 1971 instantiated to enforce security policies in the I2NSF framework, 1972 Security Controller could request the VNFM to instantiate them 1973 through the Ve-Vnfm interface. Or if an NSF, running as a VNF, is 1974 not used by any traffic flows for a time period, Security Controller 1975 MAY request deinstantiating it through the interface for efficient 1976 resource utilization. 1978 Appendix C. Acknowledgments 1980 This work was supported by Institute of Information & Communications 1981 Technology Planning & Evaluation (IITP) grant funded by the Korea 1982 MSIT (Ministry of Science and ICT) (No. 2016-0-00078, Cloud Based 1983 Security Intelligence Technology Development for the Customized 1984 Security Service Provisioning). This work was supported in part by 1985 the IITP (2020-0-00395, Standard Development of Blockchain based 1986 Network Management Automation Technology). 1988 Appendix D. Contributors 1990 This document is made by the group effort of I2NSF working group. 1991 Many people actively contributed to this document, such as Reshad 1992 Rahman. The authors sincerely appreciate their contributions. 1994 The following are co-authors of this document: 1996 Patrick Lingga Department of Electrical and Computer Engineering 1997 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 1998 16419 Republic of Korea EMail: patricklink@skku.edu 2000 Jinyong Tim Kim Department of Electronic, Electrical and Computer 2001 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 2002 Gyeonggi-do 16419 Republic of Korea EMail: timkim@skku.edu 2004 Chaehong Chung Department of Electronic, Electrical and Computer 2005 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 2006 Gyeonggi-do 16419 Republic of Korea EMail: darkhong@skku.edu 2008 Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA EMail: 2009 shares@ndzh.com 2011 Diego R. Lopez Telefonica I+D Jose Manuel Lara, 9 Seville, 41013 2012 Spain EMail: diego.r.lopez@telefonica.com 2014 Appendix E. Changes from draft-ietf-i2nsf-registration-interface-dm-11 2016 The following changes are made from draft-ietf-i2nsf-registration- 2017 interface-dm-11: 2019 * This version has been updated to synchronize with other I2NSF 2020 documents. 2022 Authors' Addresses 2023 Sangwon Hyun (editor) 2024 Department of Computer Engineering 2025 Myongji University 2026 116 Myongji-ro, Cheoin-gu 2027 Yongin 2028 Gyeonggi-do 2029 17058 2030 Republic of Korea 2032 Email: shyun@mju.ac.kr 2034 Jaehoon Paul Jeong (editor) 2035 Department of Computer Science and Engineering 2036 Sungkyunkwan University 2037 2066 Seobu-Ro, Jangan-Gu 2038 Suwon 2039 Gyeonggi-Do 2040 16419 2041 Republic of Korea 2043 Phone: +82 31 299 4957 2044 Email: pauljeong@skku.edu 2045 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2047 Taekyun Roh 2048 Department of Electronic, Electrical and Computer Engineering 2049 Sungkyunkwan University 2050 2066 Seobu-Ro, Jangan-Gu 2051 Suwon 2052 Gyeonggi-Do 2053 16419 2054 Republic of Korea 2056 Phone: +82 31 290 7222 2057 Email: tkroh0198@skku.edu 2059 Sarang Wi 2060 Department of Electronic, Electrical and Computer Engineering 2061 Sungkyunkwan University 2062 2066 Seobu-Ro, Jangan-Gu 2063 Suwon 2064 Gyeonggi-Do 2065 16419 2066 Republic of Korea 2067 Phone: +82 31 290 7222 2068 Email: dnl9795@skku.edu 2070 Jung-Soo Park 2071 Electronics and Telecommunications Research Institute 2072 218 Gajeong-Ro, Yuseong-Gu 2073 Daejeon 2074 305-700 2075 Republic of Korea 2077 Phone: +82 42 860 6514 2078 Email: pjs@etri.re.kr