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