idnits 2.17.1 draft-ietf-i2nsf-registration-interface-dm-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 475 has weird spacing: '...average uint1...' == Line 479 has weird spacing: '...average uint1...' == Line 482 has weird spacing: '...average uint...' == Line 498 has weird spacing: '...rw port ine...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 9, 2020) is 1481 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) == Missing Reference: 'RFC 7348' is mentioned on line 329, but not defined == Unused Reference: 'RFC6087' is defined on line 818, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6087 (Obsoleted by RFC 8407) ** Downref: Normative reference to an Informational RFC: RFC 8329 Summary: 3 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 3 Internet-Draft Myongji University 4 Intended status: Standards Track J. Jeong 5 Expires: September 10, 2020 T. Roh 6 S. Wi 7 Sungkyunkwan University 8 J. Park 9 ETRI 10 March 9, 2020 12 I2NSF Registration Interface YANG Data Model 13 draft-ietf-i2nsf-registration-interface-dm-07 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 into 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 September 10, 2020. 42 Copyright Notice 44 Copyright (c) 2020 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 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 4 64 5.1. NSF Capability Registration . . . . . . . . . . . . . . . 5 65 5.1.1. NSF Capability Information . . . . . . . . . . . . . 6 66 5.1.2. NSF Access Information . . . . . . . . . . . . . . . 8 67 5.2. NSF Capability Query . . . . . . . . . . . . . . . . . . 8 68 6. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 8 70 6.1.1. Definition of Symbols in Tree Diagrams . . . . . . . 9 71 6.1.2. I2NSF Registration Interface . . . . . . . . . . . . 9 72 6.1.3. NSF Capability Information . . . . . . . . . . . . . 11 73 6.1.4. NSF Access Information . . . . . . . . . . . . . . . 12 74 6.2. YANG Data Modules . . . . . . . . . . . . . . . . . . . . 12 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 79 9.2. Informative References . . . . . . . . . . . . . . . . . 20 80 Appendix A. XML Example of Registration Interface Data Model . . 22 81 A.1. Example 1: Registration for Capabilities of General 82 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 22 83 A.2. Example 2: Registration for Capabilities of Time based 84 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 23 85 A.3. Example 3: Registration for Capabilities of Web Filter . 25 86 A.4. Example 4: Registration for Capabilities of VoIP/VoLTE 87 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 27 88 A.5. Example 5: Registration for Capabilities of HTTP and 89 HTTPS Flood Mitigation . . . . . . . . . . . . . . . . . 28 90 A.6. Example 6: Query for Capabilities of Time based Firewall 30 91 Appendix B. NSF Lifecycle Management in NFV Environments . . . . 32 92 Appendix C. Changes from draft-ietf-i2nsf-registration- 93 interface-dm-05 . . . . . . . . . . . . . . . . . . 32 94 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 32 95 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 32 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 98 1. Introduction 100 A number of Network Security Functions (NSF) may exist in the 101 Interface to Network Security Functions (I2NSF) framework [RFC8329]. 102 Since each of these NSFs likely has different security capabilities 103 from each other, it is important to register the security 104 capabilities of the NSF into the security controller. In addition, 105 it is required to search NSFs of some required security capabilities 106 on demand. As an example, if additional security capabilities are 107 required to serve some security service request(s) from an I2NSF 108 user, the security controller should be able to request the DMS for 109 NSFs that have the required security capabilities. 111 This document describes an information model (see Section 5) and a 112 YANG [RFC7950] data model (see Section 6) for the I2NSF Registration 113 Interface [RFC8329] between the security controller and the 114 developer's management system (DMS) to support NSF capability 115 registration and query via the registration interface. It also 116 describes the operations which should be performed by the security 117 controller and the DMS via the Registration Interface using the 118 defined model. 120 2. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in 125 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 126 as shown here. 128 3. Terminology 130 This document uses the following terms defined in 131 [i2nsf-terminology], [capability-dm], [RFC8329], 132 [supa-policy-data-model], and [supa-policy-info-model] 134 o Network Security Function (NSF): A function that is responsible 135 for a specific treatment of received packets. A Network Security 136 Function can act at various layers of a protocol stack (e.g., at 137 the network layer or other OSI layers). Sample Network Security 138 Service Functions are as follows: Firewall, Intrusion Prevention/ 139 Detection System (IPS/IDS), Deep Packet Inspection (DPI), 140 Application Visibility and Control (AVC), network virus and 141 malware scanning, sandbox, Data Loss Prevention (DLP), Distributed 142 Denial of Service (DDoS) mitigation and TLS proxy. 144 o Data Model: A data model is a representation of concepts of 145 interest to an environment in a form that is dependent on data 146 repository, data definition language, query language, 147 implementation language, and protocol. [supa-policy-info-model] 149 o Information Model: An information model is a representation of 150 concepts of interest to an environment in a form that is 151 independent of data repository, data definition language, query 152 language, implementation language, and protocol. 153 [supa-policy-info-model] 155 o YANG: This document follows the guidelines of [RFC8407], uses the 156 common YANG types defined in [RFC6991], and adopts the Network 157 Management Datastore Architecture (NMDA). The meaning of the 158 symbols in tree diagrams is defined in [RFC8340]. 160 4. Objectives 162 o Registering NSFs to I2NSF framework: Developer's Management System 163 (DMS) in I2NSF framework is typically run by an NSF vendor, and 164 uses Registration Interface to provide NSFs developed by the NSF 165 vendor to Security Controller. DMS registers NSFs and their 166 capabilities to I2NSF framework through Registration Interface. 167 For the registered NSFs, Security Controller maintains a catalog 168 of the capabilities of those NSFs. 170 o Updating the capabilities of registered NSFs: After an NSF is 171 registered into Security Controller, some modifications on the 172 capability of the NSF may be required later. In this case, DMS 173 uses Registration Interface to update the capability of the NSF, 174 and this update should be reflected in the catalog of NSFs. 176 o Asking DMS about some required capabilities: In cases that some 177 security capabilities are required to serve the security service 178 request from an I2NSF user, Security Controller searches through 179 the registered NSFs to find ones that can provide the required 180 capabilities. But Security Controller might fail to find any NSFs 181 having the required capabilities among the registered NSFs. In 182 this case, Security Controller needs to request DMS for additional 183 NSF(s) that can provide the required security capabilities via 184 Registration Interface. 186 5. Information Model 188 The I2NSF registration interface is used by Security Controller and 189 Developer's Management System (DMS) in I2NSF framework. The 190 following summarizes the operations done through the registration 191 interface: 193 1) DMS registers NSFs and their capabilities to Security Controller 194 via the registration interface. DMS also uses the registration 195 interface to update the capabilities of the NSFs registered 196 previously. 198 2) In case that Security Controller fails to find some required 199 capabilities from any registered NSF that can provide , Security 200 Controller queries DMS about NSF(s) having the required 201 capabilities via the registration interface. 203 Figure 1 shows the information model of the I2NSF registration 204 interface, which consists of two submodels: NSF capability 205 registration and NSF capability query. Each submodel is used for the 206 operations listed above. The remainder of this section will provide 207 in-depth explanations of each submodel. 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | I2NSF Registration Interface Information Model | 211 | | 212 | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 213 | | NSF Capability | | NSF Capability | | 214 | | Registration | | Query | | 215 | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Figure 1: I2NSF Registration Interface Information Model 220 5.1. NSF Capability Registration 222 This submodel is used by DMS to register an NSF to Security 223 Controller. Figure 2 shows how this submodel is constructed. The 224 most important part in Figure 2 is the NSF capability, and this 225 specifies the set of capabilities that the NSF to be registered can 226 offer. The NSF Name contains a unique name of this NSF with the 227 specified set of capabilities. When registering the NSF, DMS 228 additionally includes the network access information of the NSF which 229 is required to enable network communications with the NSF. 231 The following will further explain the NSF capability information and 232 the NSF access information in more detail. 234 +-+-+-+-+-+-+-+-+-+ 235 | NSF Capability | 236 | Registration | 237 +-+-+-+-^-+-+-+-+-+ 238 | 239 +---------------------+--------------------+ 240 | | | 241 | | | 242 +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 243 | NSF | | NSF Capability| | NSF Access | 244 | Name | | Information | | Information | 245 +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 247 Figure 2: NSF Capability Registration Sub-Model 249 5.1.1. NSF Capability Information 251 NSF Capability Information basically describes the security 252 capabilities of an NSF. In Figure 3, we show capability objects of 253 an NSF. Following the information model of NSF capabilities defined 254 in [capability-dm], we share the same I2NSF security capabilities: 255 Time Capabilities, Event Capabilities, Condition Capabilities, Action 256 Capabilities, Resolution Strategy Capabilities, Default Action 257 Capabilities, and IPsec Method [i2nsf-ipsec]. Also, NSF Capability 258 Information additionally contains the performance capabilities of an 259 NSF as shown in Figure 3. 261 +-+-+-+-+-+-+-+-+-+ 262 | NSF Capability | 263 | Information | 264 +-+-+-+-^-+-+-+-+-+ 265 | 266 | 267 +----------------------+----------------------+ 268 | | 269 | | 270 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 271 | I2NSF | | Performance | 272 | Capabilities | | Capabilities | 273 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 274 | 275 +--+-----------------+------------------+-----------------+-------+ 276 | | | | | 277 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | 278 | Time | | Event | | Condition | | Action | | 279 | Capabilities| | Capabilities| | Capabilities| | Capabilities| | 280 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | 281 | 282 +----------------------+--------------------+-------+ 283 | | | 284 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ 285 | Resolution | | Default | | IPsec | 286 | Strategy | | Action | | Method | 287 | Capabilities| | Capabilities| +-+-+-+-+-+-+ 288 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 290 Figure 3: NSF Capability Information 292 5.1.1.1. Performance Capabilities 294 This information represents the processing capability of an NSF. 295 Assuming that the current workload status of each NSF is being 296 collected through NSF monitoring [i2nsf-monitoring], this capability 297 information of the NSF can be used to determine whether the NSF is in 298 congestion by comparing it with the current workload of the NSF. 299 Moreover, this information can specify an available amount of each 300 type of resource, such as processing power which are available on the 301 NSF. (The registration interface can control the usages and 302 limitations of the created instance and make the appropriate request 303 according to the status.) As illustrated in Figure 4, this 304 information consists of two items: Processing and Bandwidth. 305 Processing information describes the NSF's available processing 306 power. Bandwidth describes the information about available network 307 amount in two cases, outbound, inbound. These two information can be 308 used for the NSF's instance request. 310 +-+-+-+-+-+-+-+-+-+ 311 | Performance | 312 | Capabilities | 313 +-+-+-+-^-+-+-+-+-+ 314 | 315 +----------------------------+ 316 | | 317 | | 318 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 319 | Processing | | Bandwidth | 320 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 322 Figure 4: Performance Capability Overview 324 5.1.2. NSF Access Information 326 NSF Access Information contains the followings that are required to 327 communicate with an NSF: IPv4 address, IPv6 address, port number, and 328 supported transport protocol(s) (e.g., Virtual Extensible LAN (VXLAN) 329 [RFC 7348], Generic Protocol Extension for VXLAN (VXLAN-GPE) 330 [nvo3-vxlan-gpe], Generic Route Encapsulation (GRE), Ethernet etc.). 331 In this document, NSF Access Information is used to identify a 332 specific NSF instance (i.e. NSF Access Information is the 333 signature(unique identifier) of an NSF instance in the overall 334 system). 336 5.2. NSF Capability Query 338 Security Controller may require some additional capabilities to serve 339 the security service request from an I2NSF user, but none of the 340 registered NSFs has the required capabilities. In this case, 341 Security Controller makes a description of the required capabilities 342 by using the NSF capability information sub-model in Section 5.1.1, 343 and sends DMS a query about which NSF(s) can provide these 344 capabilities. 346 6. Data Model 348 6.1. YANG Tree Diagram 350 This section provides the YANG Tree diagram of the I2NSF registration 351 interface. 353 6.1.1. Definition of Symbols in Tree Diagrams 355 A simplified graphical representation of the data model is used in 356 this section. The meaning of the symbols used in the following 357 diagrams [RFC8431] is as follows: 359 Brackets "[" and "]" enclose list keys. 361 Abbreviations before data node names: "rw" means configuration 362 (read-write) and "ro" state data (read-only). 364 Symbols after data node names: "?" means an optional node and "*" 365 denotes a "list" and "leaf-list". 367 Parentheses enclose choice and case nodes, and case nodes are also 368 marked with a colon (":"). 370 Ellipsis ("...") stands for contents of subtrees that are not 371 shown. 373 6.1.2. I2NSF Registration Interface 375 module : ietf-i2nsf-reg-interface 376 +--rw nsf-capability-registration 377 | uses nsf-registrations 379 rpcs : 380 +---x i2nsf-capability-query 381 | uses nsf-capability-query 383 Figure 5: YANG Tree of I2NSF Registration Interface 385 The I2NSF registration interface is used for the following purposes. 386 Developer's Management System (DMS) registers NSFs and their 387 capabilities into Security Controller via the registration interface. 388 In case that Security Controller fails to find any NSF among the 389 registered NSFs which can provide some required capabilities, 390 Security Controller uses the registration interface to query DMS 391 about NSF(s) having the required capabilities. The following 392 sections describe the YANG data models to support these operations. 394 6.1.2.1. NSF Capability Registration 396 This section expands the i2nsf-nsf-registrations in Figure 5. 398 NSF Capability Registration 399 +--rw nsf-registrations 400 +--rw nsf-information* [capability-name] 401 +--rw capability-name string 402 +--rw nsf-capability-info 403 | uses nsf-capability-info 404 +--rw security-capability 405 | uses ietf-i2nsf-capability 406 +--rw performance-capability 407 | uses performance-capability 408 +--rw nsf-access-info 409 | uses nsf-access-info 410 +--rw capability-name 411 +--rw ip 412 +--rw port 414 Figure 6: YANG Tree of NSF Capability Registration Module 416 When registering an NSF to Security Controller, DMS uses this module 417 to describe what capabilities the NSF can offer. DMS includes the 418 network access information of the NSF which is required to make a 419 network connection with the NSF as well as the capability description 420 of the NSF. 422 6.1.2.2. NSF Capability Query 424 This section expands the nsf-capability-query in Figure 5. 426 I2NSF Capability Query 427 +---x nsf-capability-query 428 +---w input 429 | +---w query-nsf-capability 430 | | uses ietf-i2nsf-capability 431 +--ro output 432 +--ro nsf-access-info 433 | uses nsf-access-info 434 +--rw capability-name 435 +--rw ip 436 +--rw port 438 Figure 7: YANG Tree of NSF Capability Query Module 440 Security Controller may require some additional capabilities to 441 provide the security service requested by an I2NSF user, but none of 442 the registered NSFs has the required capabilities. In this case, 443 Security Controller makes a description of the required capabilities 444 using this module and then queries DMS about which NSF(s) can provide 445 these capabilities. Use NETCONF RPCs to send a NSF capability query. 446 Input data is query-i2nsf-capability-info and output data is nsf- 447 access-info. In Figure 7, the ietf-i2nsf-capability refers to the 448 module defined in [capability-dm]. 450 6.1.3. NSF Capability Information 452 This section expands the nsf-capability-info in Figure 6 and 453 Figure 7. 455 NSF Capability Information 456 +--rw nsf-capability-info 457 +--rw security-capability 458 | uses ietf-i2nsf-capability 459 +--rw performance-capability 460 | uses nsf-performance-capability 462 Figure 8: YANG Tree of I2NSF NSF Capability Information 464 In Figure 8, the ietf-i2nsf-capability refers to the module defined 465 in [capability-dm]. The performance-capability is used to specify 466 the performance capability of an NSF. 468 6.1.3.1. NSF Performance Capability 470 This section expands the nsf-performance-capability in Figure 8. 472 NSF Performance Capability 473 +--rw nsf-performance-capability 474 +--rw processing 475 | +--rw processing-average uint16 476 | +--rw processing-peak uint16 477 +--rw bandwidth 478 | +--rw outbound 479 | | +--rw outbound-average uint16 480 | | +--rw outbound-peak uint16 481 | +--rw inbound 482 | | +--rw inbound-average uint16 483 | | +--rw inbound-peak uint16 485 Figure 9: YANG Tree of I2NSF NSF Performance Capability 487 This module is used to specify the performance capabilities of an NSF 488 when registering or initiating the NSF. 490 6.1.4. NSF Access Information 492 This section expands the nsf-access-info in Figure 6. 494 NSF Access Information 495 +--rw nsf-access-info 496 +--rw capability-name string 497 +--rw ip inet:ip-address 498 +--rw port inet:port-number 500 Figure 10: YANG Tree of I2NSF NSF Access Informantion 502 This module contains the network access information of an NSF that is 503 required to enable network communications with the NSF. 505 6.2. YANG Data Modules 507 This section provides YANG modules of the data model for the 508 registration interface between Security Controller and Developer's 509 Management System, as defined in Section 5. 511 file "ietf-i2nsf-reg-interface@2020-03-09.yang" 513 module ietf-i2nsf-reg-interface { 514 yang-version 1.1; 516 namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"; 518 prefix nsfreg; 520 import ietf-inet-types { 521 prefix inet; 522 reference "RFC 6991"; 523 } 524 import ietf-i2nsf-capability { 525 prefix capa; 526 reference "draft-ietf-i2nsf-capability-data-model-05"; 527 } 529 organization 530 "IETF I2NSF (Interface to Network Security Functions) 531 Working Group"; 533 contact 534 "WG Web: 535 WG List: 537 Editor: Sangwon Hyun 538 539 Editor: Jaehoon Paul Jeong 540 541 Editor: Taekyun Roh 542 543 Editor: Sarang Wi 544 545 Editor: Jung-Soo Park 546 "; 548 description 549 "This module defines a YANG data model for I2NSF 550 registration interface. 552 Copyright (c) 2020 IETF Trust and the persons 553 identified as authors of the code. All rights reserved. 555 Redistribution and use in source and binary forms, with or 556 without modification, is permitted pursuant to, and subject 557 to the license terms contained in, the Simplified BSD License 558 set forth in Section 4.c of the IETF Trust's Legal Provisions 559 Relating to IETF Documents 560 (http://trustee.ietf.org/license-info). 562 This version of this YANG module is part of RFC XXXX; see 563 the RFC itself for full legal notices."; 565 revision "2020-03-09" { 566 description "Initial revision"; 567 reference 568 "RFC XXXX: I2NSF Registration Interface YANG Data Model"; 569 } 571 grouping nsf-performance-capability { 572 description 573 "Description of the performance capabilities of an NSF"; 575 container processing { 576 description 577 "Processing power of an NSF in the unit of GHz (gigahertz)"; 579 leaf processing-average { 580 type uint16; 581 description 582 "Average processing power"; 583 } 584 leaf processing-peak { 585 type uint16; 586 description 587 "Peak processing power"; 588 } 589 } 590 container bandwidth { 591 description 592 "Network bandwidth available on an NSF 593 in the unit of Mbps (megabits per second)"; 595 container outbound { 596 description 597 "Outbound network bandwidth"; 598 leaf outbound-average { 599 type uint32; 600 units "Mbps"; 601 description 602 "Average outbound bandwidth"; 603 } 604 leaf outbound-peak { 605 type uint32; 606 units "Mbps"; 607 description 608 "Peak outbound bandwidth"; 609 } 610 } 611 container inbound { 612 description 613 "Inbound network bandwidth"; 614 leaf inbound-average { 615 type uint32; 616 units "Mbps"; 617 description 618 "Average inbound bandwidth"; 619 } 620 leaf inbound-peak { 621 type uint32; 622 units "Mbps"; 623 description 624 "Peak inbound bandwidth"; 625 } 626 } 627 } 628 } 630 grouping nsf-capability-info { 631 description 632 "Capability description of an NSF"; 633 container security-capability { 634 description 635 "Description of the security capabilities of an NSF"; 636 uses capa:nsf-capabilities; 637 reference "draft-ietf-i2nsf-capability-data-model-05"; 638 } 639 container performance-capability { 640 description 641 "Description of the performance capabilities of an NSF"; 642 uses nsf-performance-capability; 643 } 644 } 646 grouping nsf-access-info { 647 description 648 "Information required to access an NSF"; 649 leaf capability-name { 650 type string; 651 description 652 "Unique name of this NSF's capability"; 653 } 654 leaf ip { 655 type inet:ip-address; 656 description 657 "IPv4/IPv6 address of this NSF"; 658 } 659 leaf port { 660 type inet:port-number; 661 description 662 "Port available on this NSF"; 663 } 664 } 666 container nsf-registrations { 667 description 668 "Information of an NSF that DMS registers 669 to Security Controller"; 670 list nsf-information { 671 key "capability-name"; 672 description 673 "Required information for registration"; 674 leaf capability-name { 675 type string; 676 mandatory true; 677 description 678 "Unique name of this registered NSF"; 679 } 680 container nsf-capability-info { 681 description 682 "Capability description of this NSF"; 683 uses nsf-capability-info; 684 } 685 container nsf-access-info { 686 description 687 "Network access information of this NSF"; 688 uses nsf-access-info; 689 } 690 } 691 } 693 rpc nsf-capability-query { 694 description 695 "Description of the capabilities that the 696 Security Controller requests to the DMS"; 697 input { 698 container query-nsf-capability { 699 description 700 "Description of the capabilities to request"; 701 uses capa:nsf-capabilities; 702 reference 703 "draft-ietf-i2nsf-capability-data-model-05"; 704 } 705 } 706 output { 707 container nsf-access-info { 708 description 709 "Network access information of an NSF 710 with the requested capabilities"; 711 uses nsf-access-info; 712 } 713 } 714 } 715 } 717 719 Figure 11: Registration Interface YANG Data Model 721 7. IANA Considerations 723 This document requests IANA to register the following URI in the 724 "IETF XML Registry" [RFC3688]: 726 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface 727 Registrant Contact: The IESG. 728 XML: N/A; the requested URI is an XML namespace. 730 This document requests IANA to register the following YANG module in 731 the "YANG Module Names" registry [RFC7950]. 733 Name: ietf-i2nsf-reg-interface 734 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface 735 Prefix: nsfreg 736 Reference: RFC XXXX 738 8. Security Considerations 740 The YANG module specified in this document defines a data schema 741 designed to be accessed through network management protocols such as 742 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 743 the secure transport layer, and the required secure transport is 744 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 745 and the required secure transport is TLS [RFC8446]. 747 The NETCONF access control model [RFC8341] provides a means of 748 restricting access to specific NETCONF or RESTCONF users to a 749 preconfigured subset of all available NETCONF or RESTCONF protocol 750 operations and content. 752 There are a number of data nodes defined in this YANG module that are 753 writable/creatable/deletable (i.e., config true, which is the 754 default). These data nodes may be considered sensitive or vulnerable 755 in some network environments. Write operations (e.g., edit-config) 756 to these data nodes without proper protection can have a negative 757 effect on network operations. These are the subtrees and data nodes 758 and their sensitivity/vulnerability: 760 o nsf-registrations: The attacker may exploit this to register a 761 compromised or malicious NSF instead of a legitimate NSF to the 762 Security Controller. 764 o nsf-performance-capability: The attacker may provide incorrect 765 information of the performance capability of any target NSF by 766 illegally modifying this. 768 o nsf-capability-info: The attacker may provide incorrect 769 information of the security capability of any target NSF by 770 illegally modifying this. 772 o nsf-access-info: The attacker may provide incorrect network access 773 information of any target NSF by illegally modifying this. 775 Some of the readable data nodes in this YANG module may be considered 776 sensitive or vulnerable in some network environments. It is thus 777 important to control read access (e.g., via get, get-config, or 778 notification) to these data nodes. These are the subtrees and data 779 nodes and their sensitivity/vulnerability: 781 o nsf-registrations: The attacker may try to gather some sensitive 782 information of a registered NSF by sniffing this. 784 o nsf-performance-capability: The attacker may gather the 785 performance capability information of any target NSF and misuse 786 the information for subsequent attacks. 788 o nsf-capability-info: The attacker may gather the security 789 capability information of any target NSF and misuse the 790 information for subsequent attacks. 792 o nsf-access-info: The attacker may gather the network access 793 information of any target NSF and misuse the information for 794 subsequent attacks. 796 The RPC operation in this YANG module may be considered sensitive or 797 vulnerable in some network environments. It is thus important to 798 control access to this operation. The following is the operation and 799 its sensitivity/vulnerability: 801 o nsf-capability-query: The attacker may exploit this RPC operation 802 to deteriorate the availability of the DMS and/or gather the 803 information of some interested NSFs from the DMS. 805 9. References 807 9.1. Normative References 809 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 810 Requirement Levels", BCP 14, RFC 2119, 811 DOI 10.17487/RFC2119, March 1997, 812 . 814 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 815 DOI 10.17487/RFC3688, January 2004, 816 . 818 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 819 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 820 January 2011, . 822 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 823 and A. Bierman, Ed., "Network Configuration Protocol 824 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 825 . 827 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 828 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 829 . 831 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 832 RFC 6991, DOI 10.17487/RFC6991, July 2013, 833 . 835 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 836 RFC 7950, DOI 10.17487/RFC7950, August 2016, 837 . 839 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 840 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 841 . 843 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 844 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 845 May 2017, . 847 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 848 Kumar, "Framework for Interface to Network Security 849 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 850 . 852 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 853 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 854 . 856 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 857 Access Control Model", STD 91, RFC 8341, 858 DOI 10.17487/RFC8341, March 2018, 859 . 861 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 862 Documents Containing YANG Data Models", BCP 216, RFC 8407, 863 DOI 10.17487/RFC8407, October 2018, 864 . 866 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 867 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 868 . 870 9.2. Informative References 872 [capability-dm] 873 Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin, 874 "I2NSF Capability YANG Data Model", draft-ietf-i2nsf- 875 capability-data-model-05 (work in progress), July 2019. 877 [i2nsf-ipsec] 878 Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 879 Garcia, "Software-Defined Networking (SDN)-based IPsec 880 Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow- 881 protection-07 (work in progress), August 2019. 883 [i2nsf-monitoring] 884 Jeong, J., Chung, C., Hares, S., Xia, L., and H. Birkholz, 885 "I2NSF NSF Monitoring YANG Data Model", draft-ietf-i2nsf- 886 nsf-monitoring-data-model-02 (work in progress), November 887 2019. 889 [i2nsf-terminology] 890 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 891 Birkholz, "Interface to Network Security Functions (I2NSF) 892 Terminology", draft-ietf-i2nsf-terminology-08 (work in 893 progress), July 2019. 895 [nfv-framework] 896 "Network Functions Virtualisation (NFV); Architectureal 897 Framework", ETSI GS NFV 002 ETSI GS NFV 002 V1.1.1, 898 October 2013. 900 [nvo3-vxlan-gpe] 901 Maino, Ed., F., Kreeger, Ed., L., and U. Elzur, Ed., 902 "Generic Protocol Extension for VXLAN", draft-ietf-nvo3- 903 vxlan-gpe-09 (work in progress), December 2019. 905 [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 906 S., and N. Bahadur, "A YANG Data Model for Routing 907 Information Base (RIB)", RFC 8431, September 2018. 909 [supa-policy-data-model] 910 Halpern, J., Strassner, J., and S. van der Meer, "Generic 911 Policy Data Model for Simplified Use of Policy 912 Abstractions (SUPA)", draft-ietf-supa-generic-policy-data- 913 model-04 (work in progress), June 2017. 915 [supa-policy-info-model] 916 Strassner, J., Halpern, J., and S. van der Meer, "Generic 917 Policy Information Model for Simplified Use of Policy 918 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 919 model-03 (work in progress), May 2017. 921 Appendix A. XML Example of Registration Interface Data Model 923 This section describes XML examples of the I2NSF Registration 924 Interface data model under the assumption of registering several 925 types of NSFs and querying NSF capability. 927 A.1. Example 1: Registration for Capabilities of General Firewall 929 This section shows an XML example for registering the capabilities of 930 general firewall. 932 935 936 general_firewall_capability 937 938 939 940 941 capa:ipv4-protocol 942 capa:exact-ipv4-address 943 capa:range-ipv4-address 944 capa:exact-tcp-port-num 945 capa:range-tcp-port-num 946 947 948 949 capa:pass 950 capa:drop 951 capa:alert 952 capa:pass 953 capa:drop 954 capa:alert 955 956 capa:ikeless 957 958 959 960 1000 961 5000 962 963 964 965 1000 966 5000 967 968 969 1000 970 5000 971 972 973 974 975 976 general_firewall 977 2001:DB8:8:4::2 978 3000 979 980 981 983 Figure 12: Configuration XML for Registration of General Firewall 985 Figure 12 shows the configuration XML for registering the general 986 firewall and its capabilities as follows. 988 1. The instance name of the NSF is general_firewall. 990 2. The NSF can inspect protocol, exact IPv4 address, and range IPv4 991 address for IPv4 packets. 993 3. The NSF can inspect exact port number and range port number for 994 tcp packets. 996 4. The NSF can determine whether the packets are allowed to pass, 997 drop, or alert. 999 5. The NSF can support IPsec not through IKEv2, but through a 1000 Security Controller [i2nsf-ipsec]. 1002 6. The NSF can have processing power and bandwidth. 1004 7. The location of the NSF is 2001:DB8:8:4::2. 1006 8. The port of the NSF is 3000. 1008 A.2. Example 2: Registration for Capabilities of Time based Firewall 1010 This section shows an XML example for registering the capabilities of 1011 time-based firewall. 1013 1016 1017 time_based_firewall_capability 1018 1019 1020 absolute-time 1021 periodic-time 1022 1023 1024 capa:ipv4-protocol 1025 capa:exact-ipv4-address 1026 capa:range-ipv4-address 1027 1028 1029 1030 capa:pass 1031 capa:drop 1032 capa:alert 1033 capa:pass 1034 capa:drop 1035 capa:alert 1036 1037 capa:ike 1038 1039 1040 1041 1000 1042 5000 1043 1044 1045 1046 1000 1047 5000 1048 1049 1050 1000 1051 5000 1052 1053 1054 1055 1056 1057 time_based_firewall 1058 2001:DB8:8:4::3 1059 3000 1060 1061 1062 1064 Figure 13: Configuration XML for Registration of Time based Firewall 1066 Figure 13 shows the configuration XML for registering the time-based 1067 firewall and its capabilities as follows. 1069 1. The instance name of the NSF is time_based_firewall. 1071 2. The NSF can enforce the security policy rule according to 1072 absolute time and periodic time. 1074 3. The NSF can inspect protocol, exact IPv4 address, and range IPv4 1075 address for IPv4 packets. 1077 4. The NSF can determine whether the packets are allowed to pass, 1078 drop, or alert. 1080 5. The NSF can support IPsec through IKEv2 [i2nsf-ipsec]. 1082 6. The NSF can have processing power and bandwidth. 1084 7. The location of the NSF is 2001:DB8:8:4::3. 1086 8. The port of the NSF is 3000. 1088 A.3. Example 3: Registration for Capabilities of Web Filter 1090 This section shows an XML example for registering the capabilities of 1091 web filter. 1093 1096 1097 web_filter 1098 1099 1100 1101 1102 capa:user-defined 1103 1104 1105 1106 capa:pass 1107 capa:drop 1108 capa:alert 1109 capa:pass 1110 capa:drop 1111 capa:alert 1113 1114 capa:ikeless 1115 1116 1117 1118 1000 1119 5000 1120 1121 1122 1123 1000 1124 5000 1125 1126 1127 1000 1128 5000 1129 1130 1131 1132 1133 1134 web_filter 1135 2001:DB8:8:4::4 1136 3000 1137 1138 1139 1141 Figure 14: Configuration XML for Registration of Web Filter 1143 Figure 14 shows the configuration XML for registering the web filter, 1144 and its capabilities are as follows. 1146 1. The instance name of the NSF is web_filter. 1148 2. The NSF can inspect url for http and https packets. 1150 3. The NSF can determine whether the packets are allowed to pass, 1151 drop, or alert. 1153 4. The NSF can support IPsec not through IKEv2, but through a 1154 Security Controller [i2nsf-ipsec]. 1156 5. The NSF can have processing power and bandwidth. 1158 6. The location of the NSF is 2001:DB8:8:4::4. 1160 7. The port of the NSF is 3000. 1162 A.4. Example 4: Registration for Capabilities of VoIP/VoLTE Filter 1164 This section shows an XML example for registering the capabilities of 1165 VoIP/VoLTE filter. 1167 1170 1171 voip_volte_filter 1172 1173 1174 1175 1176 capa:voice-id 1177 1178 1179 1180 capa:pass 1181 capa:drop 1182 capa:alert 1183 capa:pass 1184 capa:drop 1185 capa:alert 1186 1187 capa:ikeless 1188 1189 1190 1191 1000 1192 5000 1193 1194 1195 1196 1000 1197 5000 1198 1199 1200 1000 1201 5000 1202 1203 1204 1205 1206 1207 voip_volte_filter 1208 2001:DB8:8:4::5 1209 3000 1210 1211 1212 1214 Figure 15: Configuration XML for Registration of VoIP/VoLTE Filter 1216 Figure 15 shows the configuration XML for registering VoIP/VoLTE 1217 filter, and its capabilities are as follows. 1219 1. The instance name of the NSF is voip_volte_filter. 1221 2. The NSF can inspect voice id for VoIP/VoLTE packets. 1223 3. The NSF can determine whether the packets are allowed to pass, 1224 drop, or alert. 1226 4. The NSF can support IPsec not through IKEv2, but through a 1227 Security Controller [i2nsf-ipsec]. 1229 5. The NSF can have processing power and bandwidth. 1231 6. The location of the NSF is 2001:DB8:8:4::5. 1233 7. The port of the NSF is 3000. 1235 A.5. Example 5: Registration for Capabilities of HTTP and HTTPS Flood 1236 Mitigation 1238 This section shows an XML example for registering the capabilities of 1239 http and https flood mitigation. 1241 1244 1245 1246 http_and_https_flood_mitigation 1247 1248 1249 1250 1251 1252 capa:http-flood-action 1253 capa:https-flood-action 1254 1256 1257 1258 capa:pass 1259 capa:drop 1260 capa:alert 1261 capa:pass 1262 capa:drop 1263 capa:alert 1264 1265 capa:ike 1266 1267 1268 1269 1000 1270 5000 1271 1272 1273 1274 1000 1275 5000 1276 1277 1278 1000 1279 5000 1280 1281 1282 1283 1284 1285 1286 http_and_https_flood_mitigation 1287 1288 2001:DB8:8:4::6 1289 3000 1290 1291 1292 1294 Figure 16: Configuration XML for Registration of of HTTP and HTTPS 1295 Flood Mitigation 1297 Figure 16 shows the configuration XML for registering the http and 1298 https flood mitigator, and its capabilities are as follows. 1300 1. The instance name of the NSF is http_and_https_flood_mitigation. 1302 2. The NSF can control the amount of packets for http and https 1303 packets. 1305 3. The NSF can determine whether the packets are allowed to pass, 1306 drop, or alert. 1308 4. The NSF can support IPsec through IKEv2 [i2nsf-ipsec]. 1310 5. The NSF can have processing power and bandwidth. 1312 6. The location of the NSF is 2001:DB8:8:4::6. 1314 7. The port of the NSF is 3000. 1316 A.6. Example 6: Query for Capabilities of Time based Firewall 1318 This section shows an XML example for querying the capabilities of 1319 time-based firewall. 1321 1323 1326 1327 absolute-time 1328 periodic-time 1329 1330 1331 capa:ipv4-protocol 1332 capa:exact-ipv4-address 1333 capa:range-ipv4-address 1334 1335 1336 1337 capa:pass 1338 capa:drop 1339 capa:alert 1340 capa:pass 1341 capa:drop 1342 capa:alert 1343 1344 capa:ikeless 1345 1346 1347 1349 1351 1353 time-based-firewall 1354 2001:DB8:8:4::7 1355 8080 1356 1357 1359 Figure 17: Configuration XML for Query of Time-based Firewall 1361 Figure 17 shows the XML configuration for querying the capabilities 1362 of the time-based firewall. 1364 Appendix B. NSF Lifecycle Management in NFV Environments 1366 Network Functions Virtualization (NFV) can be used to implement I2NSF 1367 framework. In NFV environments, NSFs are deployed as virtual network 1368 functions (VNFs). Security Controller can be implemented as an 1369 Element Management (EM) of the NFV architecture, and is connected 1370 with the VNF Manager (VNFM) via the Ve-Vnfm interface 1371 [nfv-framework]. Security Controller can use this interface for the 1372 purpose of the lifecycle management of NSFs. If some NSFs need to be 1373 instantiated to enforce security policies in the I2NSF framework, 1374 Security Controller could request the VNFM to instantiate them 1375 through the Ve-Vnfm interface. Or if an NSF, running as a VNF, is 1376 not used by any traffic flows for a time period, Security Controller 1377 may request deinstantiating it through the interface for efficient 1378 resource utilization. 1380 Appendix C. Changes from draft-ietf-i2nsf-registration-interface-dm-05 1382 The following changes have been made from draft-ietf-i2nsf- 1383 registration-interface-dm-06: 1385 o This version is revised according to the comments from Reshad 1386 Rahman who reviewed this document as a YANG doctor. 1388 o The data definition statements (i.e., container nsf-registrations) 1389 are moved after the groupings and before the rpc statements. 1391 o This version checked the indentations over the entire YANG module 1392 and corrected three indentation errors such as uses capa:nsf- 1393 capabilities, uses nsf-capability-info, and uses nsf-access-info. 1395 Appendix D. Acknowledgments 1397 This work was supported by Institute of Information & Communications 1398 Technology Planning & Evaluation (IITP) grant funded by the Korea 1399 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 1400 Security Intelligence Technology Development for the Customized 1401 Security Service Provisioning). 1403 Appendix E. Contributors 1405 This document is made by the group effort of I2NSF working group. 1406 Many people actively contributed to this document. The following are 1407 considered co-authors: 1409 o Jinyong Tim Kim (Sungkyunkwan University) 1411 o Chaehong Chung (Sungkyunkwan University) 1412 o Susan Hares (Huawei) 1414 o Diego R. Lopez (Telefonica) 1416 Authors' Addresses 1418 Sangwon Hyun 1419 Department of Computer Engineering 1420 Myongji University 1421 116 Myongji-ro, Cheoin-gu 1422 Yongin, Gyeonggi-do 17058 1423 Republic of Korea 1425 EMail: shyun@mju.ac.kr 1427 Jaehoon Paul Jeong 1428 Department of Computer Science and Engineering 1429 Sungkyunkwan University 1430 2066 Seobu-Ro, Jangan-Gu 1431 Suwon, Gyeonggi-Do 16419 1432 Republic of Korea 1434 Phone: +82 31 299 4957 1435 Fax: +82 31 290 7996 1436 EMail: pauljeong@skku.edu 1437 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1439 Taekyun Roh 1440 Department of Electronic, Electrical and Computer Engineering 1441 Sungkyunkwan University 1442 2066 Seobu-Ro, Jangan-Gu 1443 Suwon, Gyeonggi-Do 16419 1444 Republic of Korea 1446 Phone: +82 31 290 7222 1447 Fax: +82 31 299 6673 1448 EMail: tkroh0198@skku.edu 1449 Sarang Wi 1450 Department of Electronic, Electrical and Computer Engineering 1451 Sungkyunkwan University 1452 2066 Seobu-Ro, Jangan-Gu 1453 Suwon, Gyeonggi-Do 16419 1454 Republic of Korea 1456 Phone: +82 31 290 7222 1457 Fax: +82 31 299 6673 1458 EMail: dnl9795@skku.edu 1460 Jung-Soo Park 1461 Electronics and Telecommunications Research Institute 1462 218 Gajeong-Ro, Yuseong-Gu 1463 Daejeon 305-700 1464 Republic of Korea 1466 Phone: +82 42 860 6514 1467 EMail: pjs@etri.re.kr