idnits 2.17.1 draft-ietf-i2nsf-registration-interface-dm-03.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 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 465 has weird spacing: '...average uint1...' == Line 469 has weird spacing: '...average uint1...' == Line 472 has weird spacing: '...average uint...' -- The document date (March 28, 2019) is 1856 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 328, but not defined ** Obsolete normative reference: RFC 6087 (Obsoleted by RFC 8407) Summary: 2 errors (**), 0 flaws (~~), 6 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 Chosun University 4 Intended status: Standards Track J. Jeong 5 Expires: September 29, 2019 T. Roh 6 S. Wi 7 Sungkyunkwan University 8 J. Park 9 ETRI 10 March 28, 2019 12 I2NSF Registration Interface YANG Data Model 13 draft-ietf-i2nsf-registration-interface-dm-03 15 Abstract 17 This document defines an information model and a YANG data model for 18 Interface to Network Security Functions (I2NSF) Registration 19 Interface between Security Controller and Developer's Management 20 System (DMS). The objective of these information and data models is 21 to support NSF capability registration and query via I2NSF 22 Registration Interface. 24 Editorial Note (To be removed by RFC Editor) 26 Please update these statements within the document with the RFC 27 number to be assigned to this document: 29 "This version of this YANG module is part of RFC XXXX;" 31 "RFC XXXX: I2NSF Registration Interface YANG Data Model" 33 "reference: RFC XXXX" 35 Please update the "revision" date of the YANG module. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 29, 2019. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 73 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 5 76 5.1. NSF Capability Registration . . . . . . . . . . . . . . . 5 77 5.1.1. NSF Capability Information . . . . . . . . . . . . . 6 78 5.1.2. NSF Access Information . . . . . . . . . . . . . . . 8 79 5.2. NSF Capability Query . . . . . . . . . . . . . . . . . . 8 80 6. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 6.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 8 82 6.1.1. Definition of Symbols in Tree Diagrams . . . . . . . 9 83 6.1.2. I2NSF Registration Interface . . . . . . . . . . . . 9 84 6.1.3. NSF Capability Information . . . . . . . . . . . . . 11 85 6.1.4. NSF Access Information . . . . . . . . . . . . . . . 11 86 6.2. YANG Data Modules . . . . . . . . . . . . . . . . . . . . 12 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 9.2. Informative References . . . . . . . . . . . . . . . . . 17 92 Appendix A. XML Example of Registration Interface Data Model . . 19 93 A.1. Example 1: Registration for Capabilities of General 94 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 19 95 A.2. Example 2: Registration for Capabilities of Time based 96 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 20 98 A.3. Example 3: Registration for Capabilities of Web Filter . 22 99 A.4. Example 4: Registration for Capabilities of VoIP/VoLTE 100 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 A.5. Example 5: Registration for Capabilities of HTTP and 102 HTTPS Flood Mitigation . . . . . . . . . . . . . . . . . 25 103 A.6. Example 6: Query for Capabilities of Time based Firewall 27 104 Appendix B. NSF Lifecycle Managmenet in NFV Environments . . . . 29 105 Appendix C. Changes from draft-ietf-i2nsf-registration- 106 interface-dm-02 . . . . . . . . . . . . . . . . . . 29 107 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 29 108 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 29 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 111 1. Introduction 113 A number of network security functions may exist in Interface to 114 Network Security Functions (I2NSF) framework [RFC8329]. Since these 115 NSFs likely have different security capabilities, it is important to 116 register the security capabilities of each NSF into the security 117 controller. In addition, it is required to search NSFs of some 118 required security capabilities on demand. As an example, if 119 additional security capabilities are required to serve some security 120 service request(s) from an I2NSF user, the security controller should 121 be able to request the DMS for NSFs that have the required security 122 capabilities. 124 This document describes an information model (see Section 5) and a 125 YANG [RFC7950] data model (see Section 6) for the I2NSF Registration 126 Interface [RFC8329] between the security controller and the 127 developer's management system (DMS) to support NSF capability 128 registration and query and NSF initiation request via the 129 registration interface. It also describes the operations which 130 should be performed by the security controller and the DMS via the 131 Registration Interface using the defined model. 133 2. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 3. Terminology 141 This document uses the following terms defined in 142 [i2nsf-terminology], [capability-im], [RFC8329], 143 [nsf-triggered-steering], [supa-policy-data-model], and 144 [supa-policy-info-model] 145 o Network Security Function (NSF): A function that is responsible 146 for specific treatment of received packets. A Network Security 147 Function can act at various layers of a protocol stack (e.g., at 148 the network layer or other OSI layers). Sample Network Security 149 Service Functions are as follows: Firewall, Intrusion Prevention/ 150 Detection System (IPS/IDS), Deep Packet Inspection (DPI), 151 Application Visibility and Control (AVC), network virus and 152 malware scanning, sandbox, Data Loss Prevention (DLP), Distributed 153 Denial of Service (DDoS) mitigation and TLS proxy. 154 [nsf-triggered-steering] 156 o Data Model: A data model is a representation of concepts of 157 interest to an environment in a form that is dependent on data 158 repository, data definition language, query language, 159 implementation language, and protocol. [supa-policy-info-model] 161 o Information Model: An information model is a representation of 162 concepts of interest to an environment in a form that is 163 independent of data repository, data definition language, query 164 language, implementation language, and protocol. 165 [supa-policy-info-model] 167 o YANG: This document follows the guidelines of [RFC6087], uses the 168 common YANG types defined in [RFC6991], and adopts the Network 169 Management Datastore Architecture (NMDA). The meaning of the 170 symbols in tree diagrams is defined in [RFC8340]. 172 4. Objectives 174 o Registering NSFs to I2NSF framework: Developer's Management System 175 (DMS) in I2NSF framework is typically run by an NSF vendor, and 176 uses Registration Interface to provide NSFs developed by the NSF 177 vendor to Security Controller. DMS registers NSFs and their 178 capabilities to I2NSF framework through Registration Interface. 179 For the registered NSFs, Security Controller maintains a catalog 180 of the capabilities of those NSFs. 182 o Updating the capabilities of registered NSFs: After an NSF is 183 registered into Security Controller, some modifications on the 184 capability of the NSF may be required later. In this case, DMS 185 uses Registration Interface to update the capability of the NSF, 186 and this update should be reflected on the catalog of NSFs. 188 o Querying DMS about some required capabilities: Security Controller 189 may need some additional capabilities to serve the security 190 service request from an I2NSF user, but none of the registered 191 NSFs has the required capabilities. In this case, Security 192 Controller may query DMS about NSF(s) that can provide the 193 required capabilities via Registration Interface. 195 5. Information Model 197 The I2NSF registration interface is used by Security Controller and 198 Developer's Management System (DMS) in I2NSF framework. The 199 following summarizes the operations done through the registration 200 interface: 202 1) DMS registers NSFs and their capabilities to Security Controller 203 via the registration interface. DMS also uses the registration 204 interface to update the capabilities of the NSFs registered 205 previously. 207 2) In case that Security Controller fails to find any registered NSF 208 that can provide some required capabilities, Security Controller 209 queries DMS about NSF(s) having the required capabilities via the 210 registration interface. 212 Figure 1 shows the information model of the I2NSF registration 213 interface, which consists of three submodels: NSF capability 214 registration, and NSF capability query. Each submodel is used for 215 the operations listed above. The remainder of this section will 216 provide more in-depth explanations of each submodel. 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | I2NSF Registration Interface Information Model | 220 | | 221 | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 222 | | NSF Capability | | NSF Capability | | 223 | | Registration | | Query | | 224 | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 1: I2NSF Registration Interface Information Model 229 5.1. NSF Capability Registration 231 This submodel is used by DMS to register an NSF to Security 232 Controller. Figure 2 shows how this submodel is constructed. The 233 most important part in Figure 2 is the NSF capability, and this 234 specifies the set of capabilities that the NSF to be registered can 235 offer. The NSF Name contains a unique name of this NSF with the 236 specified set of capabilities. When registering the NSF, DMS 237 additionally includes the network access information of the NSF which 238 is required to enable network communications with the NSF. 240 The following will further explain the NSF capability information and 241 the NSF access information in more detail. 243 +-+-+-+-+-+-+-+-+-+ 244 | NSF Capability | 245 | Registration | 246 +-+-+-+-^-+-+-+-+-+ 247 | 248 +---------------------+--------------------+ 249 | | | 250 | | | 251 +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 252 | NSF | | NSF Capability| | NSF Access | 253 | Name | | Information | | Information | 254 +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 256 Figure 2: NSF Capability Registration Sub-Model 258 5.1.1. NSF Capability Information 260 NSF Capability Information basically describes the security 261 capabilities of an NSF. In Figure 3, we show capability objects of 262 an NSF. Following the information model of NSF capabilities defiend 263 in [capability-im], we share the same security capabilities: Network 264 Security Capabilities, Content Security Capabilities, and Attack 265 Mitigation Capabilities. Also, NSF Capability Information 266 additionally contains the performance capabilities of an NSF as shown 267 in Figure 3. 269 +-+-+-+-+-+-+-+-+-+ 270 | NSF Capability | 271 | Information | 272 +-+-+-+-^-+-+-+-+-+ 273 | 274 | 275 +---------------+-------+--------------+ 276 | | | 277 | | | 278 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 279 |Network Security | |Content Security | | 280 | Capabilities | | Capabilities | | 281 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 282 | 283 +-----------------------+--------------+ 284 | | 285 | | 286 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 287 | Performance | |Attack Mitigation| 288 | Capabilities | | Capabilities | 289 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 291 Figure 3: NSF Capability Information 293 5.1.1.1. Performance Capabilities 295 This information represents the processing capability of an NSF. 296 This information can be used to determine whether the NSF is in 297 congestion by comparing this with the workload that the NSF currently 298 undergoes. Moreover, this information can specify an available 299 amount of each type of resources such as processing power which are 300 available on the NSF. (The registration interface can control the 301 usages and limitations of the created instance and make the 302 appropriate request according to the status.) As illustrated in 303 Figure 4, this information consists of two items: Processing and 304 Bandwidth. Processing information describes the NSF's available 305 processing power. Bandwidth describes the information about 306 available network amount in two cases, outbound, inbound. This two 307 information can be used for the NSF's instance request. 309 +-+-+-+-+-+-+-+-+-+ 310 | Performance | 311 | Capabilities | 312 +-+-+-+-^-+-+-+-+-+ 313 | 314 +----------------------------+ 315 | | 316 | | 317 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 318 | Processing | | Bandwidth | 319 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 321 Figure 4: Performance Capability Overview 323 5.1.2. NSF Access Information 325 NSF Access Information contains the followings that are required to 326 communicate with an NSF: IPv4 address, IPv6 address, port number, and 327 supported transport protocol(s) (e.g., Virtual Extensible LAN (VXLAN) 328 [RFC 7348], Generic Protocol Extension for VXLAN (VXLAN-GPE) 329 [draft-ietf-nvo3-vxlan-gpe], Generic Route Encapsulation (GRE), 330 Ethernet etc.). In this document, NSF Access Information is used to 331 identify a specific NSF instance (i.e. NSF Access Information is the 332 signature(unique identifier) of an NSF instance in the overall 333 system). 335 5.2. NSF Capability Query 337 Security Controller may require some additional capabilities to serve 338 the security service request from an I2NSF user, but none of the 339 registered NSFs has the required capabilities. In this case, 340 Security Controller makes a description of the required capabilities 341 by using the NSF capability information sub-model in Section 5.1.1, 342 and sends DMS a query about which NSF(s) can provide these 343 capabilities. 345 6. Data Model 347 6.1. YANG Tree Diagram 349 This section provides an overview of the YANG Tree diagram of the 350 I2NSF registration interface. 352 6.1.1. Definition of Symbols in Tree Diagrams 354 A simplified graphical representation of the data model is used in 355 this section. The meaning of the symbols used in the following 356 diagrams [RFC8431] is as follows: 358 Brackets "[" and "]" enclose list keys. 360 Abbreviations before data node names: "rw" means configuration 361 (read-write) and "ro" state data (read-only). 363 Symbols after data node names: "?" means an optional node and "*" 364 denotes a "list" and "leaf-list". 366 Parentheses enclose choice and case nodes, and case nodes are also 367 marked with a colon (":"). 369 Ellipsis ("...") stands for contents of subtrees that are not 370 shown. 372 6.1.2. I2NSF Registration Interface 374 module : ietf-i2nsf-reg-interface 375 +--rw nsf-capability-registration 376 | uses i2nsf-nsf-registrations 378 rpcs : 379 +---x nsf-capability-query 380 | uses i2nsf-nsf-capability-query 382 Figure 5: YANG tree of I2NSF Registration Interface 384 The I2NSF registration interface is used for the following purposes. 385 Developer's Management System (DMS) registers NSFs and their 386 capabilities into Security Controller via the registration interface. 387 In case that Security Controller fails to find any NSF among the 388 registered NSFs which can provide some required capabilities, 389 Security Controller uses the registration interface to query DMS 390 about NSF(s) having the required capabilities. The following 391 sections describe the YANG data models to support these operations. 393 6.1.2.1. NSF Capability Registration 395 This section expands the i2nsf-nsf-registrations in Figure 5. 397 NSF Capability Registration 398 +--rw i2nsf-nsf-registrations 399 +--rw i2nsf-nsf-capability-registration* [nsf-name] 400 +--rw nsf-name string 401 +--rw nsf-capability-info 402 | uses i2nsf-nsf-capability-info 403 +--rw nsf-access-info 404 | uses i2nsf-nsf-access-info 406 Figure 6: YANG tree of NSF Capability Registration 408 When registering an NSF to Security Controller, DMS uses this module 409 to describe what capabilities the NSF can offer. DMS includes the 410 network access information of the NSF which is required to make a 411 network connection with the NSF as well as the capability description 412 of the NSF. 414 6.1.2.2. NSF Capability Query 416 This section expands the i2nsf-nsf-capability-query in Figure 5. 418 NSF Capability Query 419 +---x i2nsf-nsf-capability-query 420 +---w input 421 | +---w query-i2nsf-capability-info 422 | | uses ietf-i2nsf-capability 423 +--ro output 424 +--ro nsf-access-info 425 | uses i2nsf-nsf-access-info 427 Figure 7: YANG tree of NSF Capability Query 429 Security Controller may require some additional capabilities to 430 provide the security service requested by an I2NSF user, but none of 431 the registered NSFs has the required capabilities. In this case, 432 Security Controller makes a description of the required capabilities 433 using this module and then queries DMS about which NSF(s) can provide 434 these capabilities. Use NETCONF RPCs to send a NSF capability query. 435 Input data is query-i2nsf-capability-info and output data is nsf- 436 access-info. In Figure 7, the ietf-i2nsf-capability refers to the 437 module defined in [i2nsf-capability-dm]. 439 6.1.3. NSF Capability Information 441 This section expands the i2nsf-nsf-capability-info in Figure 6 and 442 Figure 7. 444 NSF Capability Information 445 +--rw i2nsf-nsf-capability-info 446 +--rw i2nsf-capability 447 | uses ietf-i2nsf-capability 448 +--rw nsf-performance-capability 449 | uses i2nsf-nsf-performance-capability 451 Figure 8: YANG tree of I2NSF NSF Capability Information 453 In Figure 8, the ietf-i2nsf-capability refers to the module defined 454 in [i2nsf-capability-dm]. The i2nsf-nsf-performance-capability is 455 used to specify the performance capability of an NSF. 457 6.1.3.1. NSF Performance Capability 459 This section expands the i2nsf-nsf-performance-capability in 460 Figure 8. 462 NSF Performance Capability 463 +--rw i2nsf-nsf-performance-capability 464 +--rw processing 465 | +--rw processing-average uint16 466 | +--rw processing-peak uint16 467 +--rw bandwidth 468 | +--rw outbound 469 | | +--rw outbound-average uint16 470 | | +--rw outbound-peak uint16 471 | +--rw inbound 472 | | +--rw inbound-average uint16 473 | | +--rw inbound-peak uint16 475 Figure 9: YANG tree of I2NSF NSF Performance Capability 477 This module is used to specify the performance capabilities of an NSF 478 when registering or initiating the NSF. 480 6.1.4. NSF Access Information 482 This section expands the i2nsf-nsf-access-info in Figure 6. 484 NSF Access Information 485 +--rw i2nsf-nsf-access-info 486 +--rw nsf-instance-name string 487 +--rw nsf-address inet:ipv4-address 488 +--rw nsf-port-number inet:port-number 490 Figure 10: YANG tree of I2NSF NSF Access Informantion 492 This module contains the network access information of an NSF that is 493 required to enable network communications with the NSF. 495 6.2. YANG Data Modules 497 This section introduces a YANG data module for the information model 498 of the required data for the registration interface between Security 499 Controller and Developer's Management System, as defined in 500 Section 5. 502 file "ietf-i2nsf-reg-interface@2019-03-28.yang" 504 module ietf-i2nsf-reg-interface{ 505 yang-version 1.1; 506 namespace 507 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"; 508 prefix "iiregi"; 510 import ietf-inet-types{ 511 prefix inet; 512 reference "RFC 6991"; 513 } 514 import ietf-i2nsf-capability{ 515 prefix capa; 516 reference "draft-ietf-i2nsf-capability 517 -data-model-04"; 518 } 519 organization 520 "IETF I2NSF (Interface to Network Security Functions) 521 Working Group"; 523 contact 524 "WG Web: 526 WG List: 528 WG Chair: Linda Dunbar 529 531 Editor: Sangwon Hyun 532 534 Editor: Jaehoon Paul Jeong 535 537 Editor: Taekyun Roh 538 540 Editor: Sarang Wi 541 543 Editor: Jung-Soo Park 544 "; 546 description 548 "It defines a YANG data model for Registration Interface. 549 Copyright (c) 2018 IETF Trust and the persons identified as 550 authors of the code. All rights reserved. 552 Redistribution and use in source and binary forms, with or 553 without modification, is permitted pursuant to, and subject 554 to the license terms contained in, the Simplified BSD License 555 set forth in Section 4.c of the IETF Trust's Legal Provisions 556 Relating to IETF Documents 557 (http://trustee.ietf.org/license-info). 559 This version of this YANG module is part of RFC XXXX; see 560 the RFC itself for full legal notices."; 562 revision 2019-03-28 { 563 description "The third revision"; 564 reference 565 "RFC XXXX: I2NSF Registration Interface YANG Data Model"; 566 } 567 rpc i2nsf-nsf-capability-query { 568 description 569 "Capability information that the 570 Security Controller 571 sends to the DMS"; 572 input{ 573 container query-i2nsf-capability-info { 574 description 575 "i2nsf capability information"; 576 uses "capa:nsf-capabilities"; 577 reference 578 "draft-ietf-i2nsf-capability 579 -data-model-04"; 580 } 581 } 582 output{ 583 container nsf-access-info { 584 description 585 "nsf access information"; 586 uses i2nsf-nsf-access-info; 588 } 589 } 590 } 591 container i2nsf-nsf-registrations{ 592 description 593 "i2nsf-nsf-registrations"; 594 list i2nsf-nsf-capability-registration { 595 key "nsf-name"; 596 description 597 "Requeired information for registration"; 598 leaf nsf-name { 599 type string; 600 mandatory true; 601 description 602 "nsf-name"; 603 } 604 container nsf-capability-info { 605 description 606 "nsf-capability-information"; 607 uses i2nsf-nsf-capability-info; 608 } 609 container nsf-access-info { 610 description 611 "nsf-access-info"; 612 uses i2nsf-nsf-access-info; 613 } 614 } 615 } 617 grouping i2nsf-nsf-performance-capability { 618 description 619 "NSF performance capailities"; 620 container processing{ 621 description 622 "processing info"; 623 leaf processing-average{ 624 type uint16; 625 description 626 "processing-average"; 628 } 629 leaf processing-peak{ 630 type uint16; 631 description 632 "processing peak"; 633 } 634 } 635 container bandwidth{ 636 description 637 "bandwidth info"; 639 container outbound{ 640 description 641 "outbound"; 642 leaf outbound-average{ 643 type uint16; 644 description 645 "outbound-average"; 646 } 647 leaf outbound-peak{ 648 type uint16; 649 description 650 "outbound-peak"; 651 } 652 } 653 container inbound{ 654 description 655 "inbound"; 656 leaf inbound-average{ 657 type uint16; 658 description 659 "inbound-average"; 660 } 661 leaf inbound-peak{ 662 type uint16; 663 description 664 "inbound-peak"; 665 } 666 } 667 } 668 } 669 grouping i2nsf-nsf-capability-info { 670 description 671 "Detail information of an NSF"; 672 container i2nsf-capability { 673 description 674 "ietf i2nsf capability information"; 675 uses "capa:nsf-capabilities"; 676 reference "draft-ietf-i2nsf-capability 677 -data-model-04"; 678 } 679 container nsf-performance-capability { 680 description 681 "performance capability"; 682 uses i2nsf-nsf-performance-capability; 683 } 684 } 686 grouping i2nsf-nsf-access-info { 687 description 688 "NSF access information"; 689 leaf nsf-instance-name { 690 type string; 691 description 692 "nsf-instance-name"; 693 } 694 leaf nsf-address { 695 type inet:ipv4-address; 696 mandatory true; 697 description 698 "nsf-address"; 699 } 700 leaf nsf-port-address { 701 type inet:port-number; 702 description 703 "nsf-port-address"; 704 } 705 } 706 } 707 709 Figure 11: Registration Interface YANG Data Model 711 7. IANA Considerations 713 This document requests IANA to register the following URI in the 714 "IETF XML Registry" [RFC3688]: 716 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface 717 Registrant Contact: The IESG. 718 XML: N/A; the requested URI is an XML namespace. 720 This document requests IANA to register the following YANG module in 721 the "YANG Module Names" registry [RFC7950]. 723 Name: ietf-i2nsf-reg-interface 724 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface 725 Prefix: iiregi 726 Reference: RFC XXXX 728 8. Security Considerations 730 This document introduces no additional security threats and SHOULD 731 follow the security requirements as stated in [RFC8329]. 733 9. References 735 9.1. Normative References 737 [RFC2119] Bradner, S., "Key words for use in RFCs toIndicate 738 Requirement Levels", RFC 2119, March 1997. 740 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 741 2004. 743 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 744 Data Model Documents", RFC 6087, January 2011. 746 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 747 July 2013. 749 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 750 RFC 7950, August 2016. 752 [RFC8340] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", 753 RFC 8340, March 2018. 755 9.2. Informative References 757 [capability-im] 758 Xia, L., Strassner, J., Basile, C., and D. Lopez, 759 "Information Model of NSFs Capabilities", draft-i2nsf- 760 capability-04 (work in progress), October 2018. 762 [draft-ietf-nvo3-vxlan-gpe] 763 Maino, Ed., F., Kreeger, Ed., L., and U. Elzur, Ed., 764 "Generic Protocol Extension for VXLAN", draft-ietf-nvo3- 765 vxlan-gpe-06 (work in progress), April 2018. 767 [i2nsf-capability-dm] 768 Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin, 769 "I2NSF Capability YANG Data Model", draft-ietf-i2nsf- 770 capability-data-model-02 (work in progress), November 771 2018. 773 [i2nsf-terminology] 774 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 775 Birkholz, "Interface to Network Security Functions (I2NSF) 776 Terminology", draft-ietf-i2nsf-terminology-07 (work in 777 progress), January 2019. 779 [nfv-framework] 780 "Network Functions Virtualisation (NFV); Architectureal 781 Framework", ETSI GS NFV 002 ETSI GS NFV 002 V1.1.1, 782 October 2013. 784 [nsf-triggered-steering] 785 Hyun, S., Jeong, J., Park, J., and S. Hares, "Service 786 Function Chaining-Enabled I2NSF Architecture", draft-hyun- 787 i2nsf-nsf-triggered-steering-06 (work in progress), July 788 2018. 790 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 791 Kumar, "Framework for Interface to Network Security 792 Functions", RFC 8329, February 2018. 794 [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 795 S., and N. Bahadur, "A YANG Data Model for Routing 796 Information Base (RIB)", RFC 8431, September 2018. 798 [supa-policy-data-model] 799 Halpern, J., Strassner, J., and S. van der Meer, "Generic 800 Policy Data Model for Simplified Use of Policy 801 Abstractions (SUPA)", draft-ietf-supa-generic-policy-data- 802 model-04 (work in progress), June 2017. 804 [supa-policy-info-model] 805 Strassner, J., Halpern, J., and S. van der Meer, "Generic 806 Policy Information Model for Simplified Use of Policy 807 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 808 model-03 (work in progress), May 2017. 810 Appendix A. XML Example of Registration Interface Data Model 812 This section describes XML examples of the I2NSF Registration 813 Interface data model in five NSF Registration examples and one NSF 814 Capability Query example. 816 A.1. Example 1: Registration for Capabilities of General Firewall 818 This section shows a configuration example for capabilities 819 registration of general firewall. 821 824 825 general_firewall_capability 826 827 828 829 830 capa:ipv4-protocol 831 capa:exact-ipv4-address 832 capa:range-ipv4-address 833 capa:exact-tcp-port-num 834 capa:range-tcp-port-num 835 836 837 838 capa:pass 839 capa:drop 840 capa:alert 841 capa:pass 842 capa:drop 843 capa:alert 844 845 ikeless 846 847 848 849 1000 850 5000 851 852 853 854 1000 855 5000 856 857 858 1000 859 5000 860 861 862 863 864 865 general_firewall 866 221.159.112.100 867 3000 868 869 870 872 Figure 12: Configuration XML for Registration of General Firewall 874 Figure 12 shows the configuration XML for registration of general 875 firewall and its capabilities are as follows. 877 1. The instance name of the NSF is general_firewall. 879 2. The NSF can inspect protocol, exact IPv4 address, and range IPv4 880 address for IPv4 packets. 882 3. The NSF can inspect exact port number and range port number for 883 tcp packets. 885 4. The NSF can control whether the packets are allowed to pass, 886 drop, or alert. 888 5. The NSF can support IPsec not through IKEv2, but through a 889 Security Controller. 891 6. The NSF can have processing power and bandwidth. 893 7. The location of the NSF is 221.159.112.100. 895 8. The port of the NSF is 3000. 897 A.2. Example 2: Registration for Capabilities of Time based Firewall 899 This section shows a configuration example for capabilities 900 registration of time based firewall. 902 905 906 time_based_firewall_capability 907 908 909 absolute-time 910 periodic-time 911 912 913 capa:ipv4-protocol 914 capa:exact-ipv4-address 915 capa:range-ipv4-address 916 917 918 919 capa:pass 920 capa:drop 921 capa:alert 922 capa:pass 923 capa:drop 924 capa:alert 925 926 ike 927 928 929 930 1000 931 5000 932 933 934 935 1000 936 5000 937 938 939 1000 940 5000 941 942 943 944 945 946 time_based_firewall 947 221.159.112.110 948 3000 949 950 951 953 Figure 13: Configuration XML for Registration of Time based Firewall 955 Figure 13 shows the configuration XML for registration of time based 956 firewall and its capabilities are as follows. 958 1. The instance name of the NSF is time_based_firewall. 960 2. The NSF can execute the security policy rule according to 961 absolute time and periodic time. 963 3. The NSF can inspect protocol, exact IPv4 address, and range IPv4 964 address for IPv4 packets. 966 4. The NSF can control whether the packets are allowed to pass, 967 drop, or alert. 969 5. The NSF can support IPsec through IKEv2. 971 6. The NSF can have processing power and bandwidth. 973 7. The location of the NSF is 221.159.112.110. 975 8. The port of the NSF is 3000. 977 A.3. Example 3: Registration for Capabilities of Web Filter 979 This section shows a configuration example for capabilities 980 registration of web filter. 982 985 986 web_filter_capability 987 988 989 990 991 capa:user-defined 992 993 994 995 capa:pass 996 capa:drop 997 capa:alert 998 capa:pass 999 capa:drop 1000 capa:alert 1002 1003 ikeless 1004 1005 1006 1007 1000 1008 5000 1009 1010 1011 1012 1000 1013 5000 1014 1015 1016 1000 1017 5000 1018 1019 1020 1021 1022 1023 web_filter 1024 221.159.112.120 1025 3000 1026 1027 1028 1030 Figure 14: Configuration XML for Registration of Web Filter 1032 Figure 14 shows the configuration XML for registration of web filter 1033 and its capabilities are as follows. 1035 1. The instance name of the NSF is web_filter. 1037 2. The NSF can inspect url for http and https packets. 1039 3. The NSF can control whether the packets are allowed to pass, 1040 drop, or alert. 1042 4. The NSF can support IPsec not through IKEv2, but through a 1043 Security Controller. 1045 5. The NSF can have processing power and bandwidth. 1047 6. The location of the NSF is 221.159.112.120. 1049 7. The port of the NSF is 3000. 1051 A.4. Example 4: Registration for Capabilities of VoIP/VoLTE Filter 1053 This section shows a configuration example for capabilities 1054 registration of VoIP/VoLTE filter. 1056 1059 1060 voip_volte_filter_capability 1061 1062 1063 1064 1065 capa:voice-id 1066 1067 1068 1069 capa:pass 1070 capa:drop 1071 capa:alert 1072 capa:pass 1073 capa:drop 1074 capa:alert 1075 1076 ikeless 1077 1078 1079 1080 1000 1081 5000 1082 1083 1084 1085 1000 1086 5000 1087 1088 1089 1000 1090 5000 1091 1092 1093 1094 1095 1096 voip_volte_filter 1097 221.159.112.130 1098 3000 1099 1100 1101 1103 Figure 15: Configuration XML for Registration of VoIP/VoLTE Filter 1105 Figure 15 shows the configuration XML for registration of VoIP/VoLTE 1106 filter and its capabilities are as follows. 1108 1. The instance name of the NSF is voip_volte_filter. 1110 2. The NSF can inspect voice id for VoIP/VoLTE packets. 1112 3. The NSF can control whether the packets are allowed to pass, 1113 drop, or alert. 1115 4. The NSF can support IPsec not through IKEv2, but through a 1116 Security Controller. 1118 5. The NSF can have processing power and bandwidth. 1120 6. The location of the NSF is 221.159.112.130. 1122 7. The port of the NSF is 3000. 1124 A.5. Example 5: Registration for Capabilities of HTTP and HTTPS Flood 1125 Mitigation 1127 This section shows a configuration example for capabilities 1128 registration of http and https flood mitigation. 1130 1133 1134 1135 http_and_h ttps_flood_mitigation_capability 1136 1137 1138 1139 1140 1141 capa:http-flood-action 1142 capa:https-flood-action 1143 1145 1146 1147 capa:pass 1148 capa:drop 1149 capa:alert 1150 capa:pass 1151 capa:drop 1152 capa:alert 1153 1154 ike 1155 1156 1157 1158 1000 1159 5000 1160 1161 1162 1163 1000 1164 5000 1165 1166 1167 1000 1168 5000 1169 1170 1171 1172 1173 1174 1175 http_and_https_flood_mitigation 1176 1177 221.159.112.140 1178 3000 1179 1180 1181 1183 Figure 16: Configuration XML for Registration of of HTTP and HTTPS 1184 Flood Mitigation 1186 Figure 16 shows the configuration XML for registration of VoIP/VoLTE 1187 filter and its capabilities are as follows. 1189 1. The instance name of the NSF is http_and_https_flood_mitigation. 1191 2. The NSF can control the amount of packets for http and https 1192 packets. 1194 3. The NSF can control whether the packets are allowed to pass, 1195 drop, or alert. 1197 4. The NSF can support IPsec through IKEv2. 1199 5. The NSF can have processing power and bandwidth. 1201 6. The location of the NSF is 221.159.112.140. 1203 7. The port of the NSF is 3000. 1205 A.6. Example 6: Query for Capabilities of Time based Firewall 1207 This section shows a configuration example for capabilities query of 1208 Time based Firewall. 1210 1212 1215 1216 absolute-time 1217 periodic-time 1218 1219 1220 capa:ipv4-protocol 1221 capa:exact-ipv4-address 1222 capa:range-ipv4-address 1223 1224 1225 1226 capa:pass 1227 capa:drop 1228 capa:alert 1229 capa:pass 1230 capa:drop 1231 capa:alert 1232 1233 ikeless 1234 1235 1236 1238 1240 1242 time-based-firewall 1243 221.159.223.250 1244 8080 1245 1246 1248 Figure 17: Configuration XML for Query of Time based Firewall 1250 Figure 17 shows the configuration of input data and output data XML 1251 for nsf capability query of time based firewall. 1253 Appendix B. NSF Lifecycle Managmenet in NFV Environments 1255 Network Functions Virtualization (NFV) can be used to implement I2NSF 1256 framework. In NFV environments, NSFs are deployed as virtual network 1257 functions (VNFs). Security Controller can be implemented as an 1258 Element Management (EM) of the NFV architecture, and is connected 1259 with the VNF Manager (VNFM) via the Ve-Vnfm interface 1260 [nfv-framework]. Security Controller can use this interface for the 1261 purpose of the lifecycle management of NSFs. If some NSFs need to be 1262 instantiated to enforce security policies in the I2NSF framework, 1263 Security Controller could request the VNFM to instantiate them 1264 through the Ve-Vnfm interface. Or if an NSF, running as a VNF, is 1265 not used by any traffic flows for a time period, Security Controller 1266 may request deinstantiating it through the interface for efficient 1267 resource utilization. 1269 Appendix C. Changes from draft-ietf-i2nsf-registration-interface-dm-02 1271 The following changes have been made from draft-ietf-i2nsf- 1272 registration-interface-dm-02: 1274 o Appendix A. added an IPsec field in the XML examples of the 1275 registration interface data model for five NSF Registration 1276 examples and one NSF Capability Query example. 1278 Appendix D. Acknowledgments 1280 This work was supported by Institute for Information & communications 1281 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 1282 (No.R-20160222-002755, Cloud based Security Intelligence Technology 1283 Development for the Customized Security Service Provisioning). 1285 Appendix E. Contributors 1287 This document is made by the group effort of I2NSF working group. 1288 Many people actively contributed to this document. The following are 1289 considered co-authors: 1291 o Jinyong Tim Kim (Sungkyunkwan University) 1293 o Susan Hares (Huawei) 1295 o Diego R. Lopez (Telefonica) 1297 o Chung, Chaehong (Sungkyunkwan University) 1299 Authors' Addresses 1301 Sangwon Hyun 1302 Department of Computer Engineering 1303 Chosun University 1304 309, Pilmun-daero, Dong-gu 1305 Gwangju, Jeollanam-do 61452 1306 Republic of Korea 1308 EMail: shyun@chosun.ac.kr 1310 Jaehoon Paul Jeong 1311 Department of Software 1312 Sungkyunkwan University 1313 2066 Seobu-Ro, Jangan-Gu 1314 Suwon, Gyeonggi-Do 16419 1315 Republic of Korea 1317 Phone: +82 31 299 4957 1318 Fax: +82 31 290 7996 1319 EMail: pauljeong@skku.edu 1320 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1322 Taekyun Roh 1323 Electrical Computer Engineering 1324 Sungkyunkwan University 1325 2066 Seobu-Ro, Jangan-Gu 1326 Suwon, Gyeonggi-Do 16419 1327 Republic of Korea 1329 Phone: +82 31 290 7222 1330 Fax: +82 31 299 6673 1331 EMail: tkroh0198@skku.edu 1333 Sarang Wi 1334 Electrical Computer Engineering 1335 Sungkyunkwan University 1336 2066 Seobu-Ro, Jangan-Gu 1337 Suwon, Gyeonggi-Do 16419 1338 Republic of Korea 1340 Phone: +82 31 290 7222 1341 Fax: +82 31 299 6673 1342 EMail: dnl9795@skku.edu 1343 Jung-Soo Park 1344 Electronics and Telecommunications Research Institute 1345 218 Gajeong-Ro, Yuseong-Gu 1346 Daejeon 305-700 1347 Republic of Korea 1349 Phone: +82 42 860 6514 1350 EMail: pjs@etri.re.kr