idnits 2.17.1 draft-ietf-i2nsf-registration-interface-dm-02.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 8 instances of too long lines in the document, the longest one being 3 characters 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 11, 2019) is 1870 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 12, 2019 T. Roh 6 S. Wi 7 Sungkyunkwan University 8 J. Park 9 ETRI 10 March 11, 2019 12 I2NSF Registration Interface YANG Data Model 13 draft-ietf-i2nsf-registration-interface-dm-02 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 12, 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 . . . . . . . . . . . . . . . . . 26 103 A.6. Example 6: Query for Capabilities of Time based Firewall 28 104 Appendix B. NSF Lifecycle Managmenet in NFV Environments . . . . 29 105 Appendix C. Changes from draft-ietf-i2nsf-registration- 106 interface-dm-01 . . . . . . . . . . . . . . . . . . 29 107 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 29 108 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 30 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-11.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-02"; 518 } 519 organization 520 "IETF I2NSF (Interface to Network Security Functions) 521 Working Group"; 523 contact 524 "WG Web: 525 WG List: 527 WG Chair: Linda Dunbar 528 530 Editor: Sangwon Hyun 531 532 Editor: Jaehoon Paul Jeong 533 535 Editor: Taekyun Roh 536 538 Editor: Sarang Wi 539 541 Editor: Jung-Soo Park 542 "; 544 description 546 "It defines a YANG data model for Registration Interface. 547 Copyright (c) 2018 IETF Trust and the persons identified as 548 authors of the code. All rights reserved. 550 Redistribution and use in source and binary forms, with or 551 without modification, is permitted pursuant to, and subject 552 to the license terms contained in, the Simplified BSD License 553 set forth in Section 4.c of the IETF Trust's Legal Provisions 554 Relating to IETF Documents 555 (http://trustee.ietf.org/license-info). 557 This version of this YANG module is part of RFC XXXX; see 558 the RFC itself for full legal notices."; 560 revision 2019-03-11 { 561 description "The third revision"; 562 reference 563 "RFC XXXX: I2NSF Registration Interface YANG Data Model"; 564 } 565 rpc i2nsf-nsf-capability-query { 566 description 567 "Capability information that the 568 Security Controller 569 sends to the DMS"; 570 input{ 571 container query-i2nsf-capability-info { 572 description 573 "i2nsf capability information"; 574 uses "capa:nsf-capabilities"; 575 reference 576 "draft-ietf-i2nsf-capability 577 -data-model-02"; 578 } 580 } 581 output{ 582 container nsf-access-info { 583 description 584 "nsf access information"; 585 uses i2nsf-nsf-access-info; 587 } 588 } 589 } 590 container i2nsf-nsf-registrations{ 591 description 592 "i2nsf-nsf-registrations"; 593 list i2nsf-nsf-capability-registration { 594 key "nsf-name"; 595 description 596 "Requeired information for registration"; 597 leaf nsf-name { 598 type string; 599 mandatory true; 600 description 601 "nsf-name"; 602 } 603 container nsf-capability-info { 604 description 605 "nsf-capability-information"; 606 uses i2nsf-nsf-capability-info; 607 } 608 container nsf-access-info { 609 description 610 "nsf-access-info"; 611 uses i2nsf-nsf-access-info; 612 } 613 } 614 } 615 grouping i2nsf-nsf-performance-capability { 616 description 617 "NSF performance capailities"; 618 container processing{ 619 description 620 "processing info"; 621 leaf processing-average{ 622 type uint16; 623 description 624 "processing-average"; 625 } 626 leaf processing-peak{ 627 type uint16; 628 description 629 "processing peak"; 630 } 631 } 632 container bandwidth{ 633 description 634 "bandwidth info"; 635 container outbound{ 636 description 637 "outbound"; 638 leaf outbound-average{ 639 type uint16; 640 description 641 "outbound-average"; 642 } 643 leaf outbound-peak{ 644 type uint16; 645 description 646 "outbound-peak"; 647 } 648 } 649 container inbound{ 650 description 651 "inbound"; 652 leaf inbound-average{ 653 type uint16; 654 description 655 "inbound-average"; 656 } 657 leaf inbound-peak{ 658 type uint16; 659 description 660 "inbound-peak"; 661 } 662 } 663 } 664 } 665 grouping i2nsf-nsf-capability-info { 666 description 667 "Detail information of an NSF"; 668 container i2nsf-capability { 669 description 670 "ietf i2nsf capability information"; 671 uses "capa:nsf-capabilities"; 672 reference "draft-ietf-i2nsf-capability 673 -data-model-02"; 674 } 675 container nsf-performance-capability { 676 description 677 "performance capability"; 678 uses i2nsf-nsf-performance-capability; 679 } 680 } 682 grouping i2nsf-nsf-access-info { 683 description 684 "NSF access information"; 685 leaf nsf-instance-name { 686 type string; 687 description 688 "nsf-instance-name"; 689 } 690 leaf nsf-address { 691 type inet:ipv4-address; 692 mandatory true; 693 description 694 "nsf-address"; 695 } 696 leaf nsf-port-address { 697 type inet:port-number; 698 description 699 "nsf-port-address"; 700 } 701 } 702 } 704 706 Figure 11: Registration Interface YANG Data Model 708 7. IANA Considerations 710 This document requests IANA to register the following URI in the 711 "IETF XML Registry" [RFC3688]: 713 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface 714 Registrant Contact: The IESG. 715 XML: N/A; the requested URI is an XML namespace. 717 This document requests IANA to register the following YANG module in 718 the "YANG Module Names" registry [RFC7950]. 720 Name: ietf-i2nsf-reg-interface 721 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface 722 Prefix: iiregi 723 Reference: RFC XXXX 725 8. Security Considerations 727 This document introduces no additional security threats and SHOULD 728 follow the security requirements as stated in [RFC8329]. 730 9. References 732 9.1. Normative References 734 [RFC2119] Bradner, S., "Key words for use in RFCs toIndicate 735 Requirement Levels", RFC 2119, March 1997. 737 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 738 2004. 740 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 741 Data Model Documents", RFC 6087, January 2011. 743 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 744 July 2013. 746 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 747 RFC 7950, August 2016. 749 [RFC8340] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", 750 RFC 8340, March 2018. 752 9.2. Informative References 754 [capability-im] 755 Xia, L., Strassner, J., Basile, C., and D. Lopez, 756 "Information Model of NSFs Capabilities", draft-i2nsf- 757 capability-04 (work in progress), October 2018. 759 [draft-ietf-nvo3-vxlan-gpe] 760 Maino, Ed., F., Kreeger, Ed., L., and U. Elzur, Ed., 761 "Generic Protocol Extension for VXLAN", draft-ietf-nvo3- 762 vxlan-gpe-06 (work in progress), April 2018. 764 [i2nsf-capability-dm] 765 Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin, 766 "I2NSF Capability YANG Data Model", draft-ietf-i2nsf- 767 capability-data-model-02 (work in progress), November 768 2018. 770 [i2nsf-terminology] 771 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 772 Birkholz, "Interface to Network Security Functions (I2NSF) 773 Terminology", draft-ietf-i2nsf-terminology-07 (work in 774 progress), January 2019. 776 [nfv-framework] 777 "Network Functions Virtualisation (NFV); Architectureal 778 Framework", ETSI GS NFV 002 ETSI GS NFV 002 V1.1.1, 779 October 2013. 781 [nsf-triggered-steering] 782 Hyun, S., Jeong, J., Park, J., and S. Hares, "Service 783 Function Chaining-Enabled I2NSF Architecture", draft-hyun- 784 i2nsf-nsf-triggered-steering-06 (work in progress), July 785 2018. 787 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 788 Kumar, "Framework for Interface to Network Security 789 Functions", RFC 8329, February 2018. 791 [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 792 S., and N. Bahadur, "A YANG Data Model for Routing 793 Information Base (RIB)", RFC 8431, September 2018. 795 [supa-policy-data-model] 796 Halpern, J., Strassner, J., and S. van der Meer, "Generic 797 Policy Data Model for Simplified Use of Policy 798 Abstractions (SUPA)", draft-ietf-supa-generic-policy-data- 799 model-04 (work in progress), June 2017. 801 [supa-policy-info-model] 802 Strassner, J., Halpern, J., and S. van der Meer, "Generic 803 Policy Information Model for Simplified Use of Policy 804 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 805 model-03 (work in progress), May 2017. 807 Appendix A. XML Example of Registration Interface Data Model 809 This section describes XML examples of the I2NSF Registration 810 Interface data model in five NSF Registration examples and one NSF 811 Capability Query example. 813 A.1. Example 1: Registration for Capabilities of General Firewall 815 This section shows a configuration example for capabilities 816 registration of general firewall. 818 821 822 general_firewall_capability 823 824 825 826 827 capa:ipv4-protocol 828 capa:exact-ipv4-address 829 capa:range-ipv4-address 830 capa:exact-tcp-port-num 831 capa:range-tcp-port-num 832 833 834 835 capa:pass 836 capa:drop 837 capa:alert 838 capa:pass 839 capa:drop 840 capa:alert 841 842 843 844 845 1000 846 5000 847 848 849 850 1000 851 5000 852 853 854 1000 855 5000 856 857 858 859 860 861 general_firewall 862 221.159.112.100 863 3000 864 865 866 868 Figure 12: Configuration XML for Registration of General Firewall 870 Figure 12 shows the configuration XML for registration of general 871 firewall and its capabilities are as follows. 873 1. The instance name of the NSF is general_firewall. 875 2. The NSF can inspect protocol, exact IPv4 address, and range IPv4 876 address for IPv4 packets. 878 3. The NSF can inspect exact port number and range port number for 879 tcp packets. 881 4. The NSF can control whether the packets are allowed to pass, 882 drop, or alert. 884 5. The NSF can have processing power and bandwidth. 886 6. The location of the NSF is 221.159.112.100. 888 7. The port of the NSF is 3000. 890 A.2. Example 2: Registration for Capabilities of Time based Firewall 892 This section shows a configuration example for capabilities 893 registration of time based firewall. 895 898 899 time_based_firewall_capability 900 901 902 absolute-time 903 periodic-time 904 905 906 capa:ipv4-protocol 907 capa:exact-ipv4-address 908 capa:range-ipv4-address 909 910 911 912 capa:pass 913 capa:drop 914 capa:alert 915 capa:pass 916 capa:drop 917 capa:alert 918 919 920 921 922 1000 923 5000 924 925 926 927 1000 928 5000 929 930 931 1000 932 5000 933 934 935 936 937 938 time_based_firewall 939 221.159.112.110 940 3000 941 942 943 945 Figure 13: Configuration XML for Registration of Time based Firewall 947 Figure 13 shows the configuration XML for registration of time based 948 firewall and its capabilities are as follows. 950 1. The instance name of the NSF is time_based_firewall. 952 2. The NSF can execute the security policy rule according to 953 absolute time and periodic time. 955 3. The NSF can inspect protocol, exact IPv4 address, and range IPv4 956 address for IPv4 packets. 958 4. The NSF can control whether the packets are allowed to pass, 959 drop, or alert. 961 5. The NSF can have processing power and bandwidth. 963 6. The location of the NSF is 221.159.112.110. 965 7. The port of the NSF is 3000. 967 A.3. Example 3: Registration for Capabilities of Web Filter 969 This section shows a configuration example for capabilities 970 registration of web filter. 972 975 976 web_filter_capability 977 978 979 980 981 capa:url 982 983 984 985 capa:pass 986 capa:drop 987 capa:alert 988 capa:pass 989 capa:drop 990 capa:alert 991 992 993 994 995 1000 996 5000 997 998 999 1000 1000 1001 5000 1002 1003 1004 1000 1005 5000 1006 1007 1008 1009 1010 1011 web_filter 1012 221.159.112.120 1013 3000 1014 1015 1016 1018 Figure 14: Configuration XML for Registration of Web Filter 1020 Figure 14 shows the configuration XML for registration of web filter 1021 and its capabilities are as follows. 1023 1. The instance name of the NSF is web_filter. 1025 2. The NSF can inspect url for http and https packets. 1027 3. The NSF can control whether the packets are allowed to pass, 1028 drop, or alert. 1030 4. The NSF can have processing power and bandwidth. 1032 5. The location of the NSF is 221.159.112.120. 1034 6. The port of the NSF is 3000. 1036 A.4. Example 4: Registration for Capabilities of VoIP/VoLTE Filter 1038 This section shows a configuration example for capabilities 1039 registration of VoIP/VoLTE filter. 1041 1044 1045 voip_volte_filter_capability 1046 1047 1048 1049 1050 capa:voice-id 1051 1052 1053 1054 capa:pass 1055 capa:drop 1056 capa:alert 1057 capa:pass 1058 capa:drop 1059 capa:alert 1060 1061 1062 1063 1064 1000 1065 5000 1066 1067 1068 1069 1000 1070 5000 1071 1072 1073 1000 1074 5000 1075 1076 1077 1078 1079 1080 voip_volte_filter 1081 221.159.112.130 1082 3000 1083 1084 1085 1087 Figure 15: Configuration XML for Registration of VoIP/VoLTE Filter 1089 Figure 15 shows the configuration XML for registration of VoIP/VoLTE 1090 filter and its capabilities are as follows. 1092 1. The instance name of the NSF is voip_volte_filter. 1094 2. The NSF can inspect voice id for VoIP/VoLTE packets. 1096 3. The NSF can control whether the packets are allowed to pass, 1097 drop, or alert. 1099 4. The NSF can have processing power and bandwidth. 1101 5. The location of the NSF is 221.159.112.130. 1103 6. The port of the NSF is 3000. 1105 A.5. Example 5: Registration for Capabilities of HTTP and HTTPS Flood 1106 Mitigation 1108 This section shows a configuration example for capabilities 1109 registration of http and https flood mitigation. 1111 1114 1115 1116 http_and_https_flood_mitigation_capability 1117 1118 1119 1120 1121 1122 capa:http-flood-action 1123 capa:https-flood-action 1124 1125 1126 1127 capa:pass 1128 capa:drop 1129 capa:alert 1130 capa:pass 1131 capa:drop 1132 capa:alert 1133 1134 1135 1136 1137 1000 1138 5000 1139 1140 1141 1142 1000 1143 5000 1144 1145 1146 1000 1147 5000 1148 1149 1150 1151 1152 1153 1154 http_and_https_flood_mitigation 1155 1156 221.159.112.140 1157 3000 1158 1159 1160 1162 Figure 16: Configuration XML for Registration of of HTTP and HTTPS 1163 Flood Mitigation 1165 Figure 16 shows the configuration XML for registration of VoIP/VoLTE 1166 filter and its capabilities are as follows. 1168 1. The instance name of the NSF is http_and_https_flood_mitigation. 1170 2. The NSF can control the amount of packets for http and https 1171 packets. 1173 3. The NSF can control whether the packets are allowed to pass, 1174 drop, or alert. 1176 4. The NSF can have processing power and bandwidth. 1178 5. The location of the NSF is 221.159.112.140. 1180 6. The port of the NSF is 3000. 1182 A.6. Example 6: Query for Capabilities of Time based Firewall 1184 This section shows a configuration example for capabilities query of 1185 Time based Firewall. 1187 1189 1192 1193 absolute-time 1194 periodic-time 1195 1196 1197 capa:ipv4-protocol 1198 capa:exact-ipv4-address 1199 capa:range-ipv4-address 1200 1201 1202 1203 capa:pass 1204 capa:drop 1205 capa:alert 1206 capa:pass 1207 capa:drop 1208 capa:alert 1209 1210 1211 1212 1214 1216 1218 time-based-firewall 1219 221.159.223.250 1220 8080 1221 1222 1224 Figure 17: Configuration XML for Query of Time based Firewall 1226 Figure 17 shows the configuration of input data and output data XML 1227 for nsf capability query of time based firewall. 1229 Appendix B. NSF Lifecycle Managmenet in NFV Environments 1231 Network Functions Virtualization (NFV) can be used to implement I2NSF 1232 framework. In NFV environments, NSFs are deployed as virtual network 1233 functions (VNFs). Security Controller can be implemented as an 1234 Element Management (EM) of the NFV architecture, and is connected 1235 with the VNF Manager (VNFM) via the Ve-Vnfm interface 1236 [nfv-framework]. Security Controller can use this interface for the 1237 purpose of the lifecycle management of NSFs. If some NSFs need to be 1238 instantiated to enforce security policies in the I2NSF framework, 1239 Security Controller could request the VNFM to instantiate them 1240 through the Ve-Vnfm interface. Or if an NSF, running as a VNF, is 1241 not used by any traffic flows for a time period, Security Controller 1242 may request deinstantiating it through the interface for efficient 1243 resource utilization. 1245 Appendix C. Changes from draft-ietf-i2nsf-registration-interface-dm-01 1247 The following changes have been made from draft-ietf-i2nsf- 1248 registration-interface-dm-01: 1250 o Section 4 has been revised to clarify major objectives of the 1251 I2NSF registration interface: NSF capability registration, NSF 1252 capability query. 1254 o Section 5 has been revised to describe the above-mentioned major 1255 operations of the I2NSF registration interface. Section 5.1 1256 describes the information model for registering NSFs and their 1257 capabilities. Section 5.2 describes the information model for 1258 querying NSFs based on a description of required capabilities. 1260 o In section 6, the data model has been revised according to the 1261 revised information model. 1263 o Appendix A. has been revised to describe the XML examples of the 1264 registration interface data model in five NSF Registration 1265 examples and one NSF Capability Query example. 1267 Appendix D. Acknowledgments 1269 This work was supported by Institute for Information & communications 1270 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 1271 (No.R-20160222-002755, Cloud based Security Intelligence Technology 1272 Development for the Customized Security Service Provisioning). 1274 Appendix E. Contributors 1276 This document is made by the group effort of I2NSF working group. 1277 Many people actively contributed to this document. The following are 1278 considered co-authors: 1280 o Jinyong Tim Kim (Sungkyunkwan University) 1282 o Susan Hares (Huawei) 1284 o Diego R. Lopez (Telefonica) 1286 o Chung, Chaehong (Sungkyunkwan University) 1288 Authors' Addresses 1290 Sangwon Hyun 1291 Department of Computer Engineering 1292 Chosun University 1293 309, Pilmun-daero, Dong-gu 1294 Gwangju, Jeollanam-do 61452 1295 Republic of Korea 1297 EMail: shyun@chosun.ac.kr 1299 Jaehoon Paul Jeong 1300 Department of Software 1301 Sungkyunkwan University 1302 2066 Seobu-Ro, Jangan-Gu 1303 Suwon, Gyeonggi-Do 16419 1304 Republic of Korea 1306 Phone: +82 31 299 4957 1307 Fax: +82 31 290 7996 1308 EMail: pauljeong@skku.edu 1309 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1310 Taekyun Roh 1311 Electrical Computer Engineering 1312 Sungkyunkwan University 1313 2066 Seobu-Ro, Jangan-Gu 1314 Suwon, Gyeonggi-Do 16419 1315 Republic of Korea 1317 Phone: +82 31 290 7222 1318 Fax: +82 31 299 6673 1319 EMail: tkroh0198@skku.edu 1321 Sarang Wi 1322 Electrical Computer Engineering 1323 Sungkyunkwan University 1324 2066 Seobu-Ro, Jangan-Gu 1325 Suwon, Gyeonggi-Do 16419 1326 Republic of Korea 1328 Phone: +82 31 290 7222 1329 Fax: +82 31 299 6673 1330 EMail: dnl9795@skku.edu 1332 Jung-Soo Park 1333 Electronics and Telecommunications Research Institute 1334 218 Gajeong-Ro, Yuseong-Gu 1335 Daejeon 305-700 1336 Republic of Korea 1338 Phone: +82 42 860 6514 1339 EMail: pjs@etri.re.kr