idnits 2.17.1 draft-ietf-i2nsf-registration-interface-dm-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of too long lines in the document, the longest one being 8 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 489 has weird spacing: '...address inet:...' -- The document date (November 4, 2018) is 1972 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 259, but not defined Summary: 2 errors (**), 0 flaws (~~), 3 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: May 8, 2019 T. Roh 6 S. Wi 7 Sungkyunkwan University 8 J. Park 9 ETRI 10 November 4, 2018 12 I2NSF Registration Interface YANG Data Model 13 draft-ietf-i2nsf-registration-interface-dm-01 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 search, instantiation and registration according to 22 required security capabilities via I2NSF Registration Interface. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 8, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. NSF Registration Mechanism . . . . . . . . . . . . . . . 5 64 5.2. NSF Access Information . . . . . . . . . . . . . . . . . 6 65 5.3. NSF Capability Information (Capabilities of an NSF 66 Instance) . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.3.1. Performance Capabilities . . . . . . . . . . . . . . 7 68 5.4. Role-based Access Control List . . . . . . . . . . . . . 8 69 6. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.1. High-Level YANG . . . . . . . . . . . . . . . . . . . . . 9 71 6.1.1. Definition of Symbols in Tree Diagrams . . . . . . . 9 72 6.1.2. Registration Interface . . . . . . . . . . . . . . . 10 73 6.1.3. Registration Request . . . . . . . . . . . . . . . . 10 74 6.1.4. Instance Management Request . . . . . . . . . . . . . 10 75 6.1.5. NSF Capability Information . . . . . . . . . . . . . 11 76 6.1.6. NSF Access Information . . . . . . . . . . . . . . . 12 77 6.1.7. NSF Performance Capability . . . . . . . . . . . . . 12 78 6.1.8. Role-Based ACL(Access Control List) . . . . . . . . . 12 79 6.2. YANG Modules . . . . . . . . . . . . . . . . . . . . . . 13 80 6.2.1. XML Example of Registration Interface Data Model . . 17 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 84 8.2. Informative References . . . . . . . . . . . . . . . . . 19 85 Appendix A. NSF Lifecycle Managmenet in NFV Environments . . . . 21 86 Appendix B. Changes from draft-ietf-i2nsf-registration- 87 interface-dm-00 . . . . . . . . . . . . . . . . . . 21 88 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 21 89 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 21 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 A number of virtual network security function instances typically 95 exist in Interface to Network Security Functions (I2NSF) framework 96 [RFC8329]. Since these NSF instances may have different security 97 capabilities, it is important to register the security capabilities 98 of each NSF instance into the security controller after they have 99 been created. In addition, it is required to search or instantiate 100 NSFs of some required security capabilities on demand. As an 101 example, if additional security capabilities are required to meet the 102 new security requirements that an I2NSF user requests, the security 103 controller should be able to request the DMS for NSFs that have the 104 required security capabilities. 106 This document describes an information model (see Section 5) and a 107 YANG [RFC6020] data model (see Section 6) for the I2NSF Registration 108 Interface [RFC8329] between the security controller and the 109 developer's management system (DMS) to support NSF search, 110 instantiation and registration according to required security 111 capabilities. It also describes the procedure which should be 112 performed by the security controller and the DMS via the Registration 113 Interface using the defined model. 115 2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Terminology 123 This document uses the following terms defined in 124 [i2nsf-terminology], [capability-im], [RFC8329], 125 [nsf-triggered-steering], [supa-policy-data-model], and 126 [supa-policy-info-model] 128 o Network Security Function (NSF): A function that is responsible 129 for specific treatment of received packets. A Network Security 130 Function can act at various layers of a protocol stack (e.g., at 131 the network layer or other OSI layers). Sample Network Security 132 Service Functions are as follows: Firewall, Intrusion Prevention/ 133 Detection System (IPS/IDS), Deep Packet Inspection (DPI), 134 Application Visibility and Control (AVC), network virus and 135 malware scanning, sandbox, Data Loss Prevention (DLP), Distributed 136 Denial of Service (DDoS) mitigation and TLS proxy. 137 [nsf-triggered-steering] 139 o Advanced Inspection/Action: As like the I2NSF information model 140 for NSF facing interface [capability-im], Advanced Inspection/ 141 Action means that a security function calls another security 142 function for further inspection based on its own inspection 143 result. [nsf-triggered-steering] 145 o NSF Profile (NSF Capability Information): NSF Capability 146 Information specifies the inspection capabilities of the 147 associated NSF instance. Each NSF instance has its own NSF 148 Capability Information to specify the type of security service it 149 provides and its resource capacity etc. [nsf-triggered-steering] 151 o Data Model: A data model is a representation of concepts of 152 interest to an environment in a form that is dependent on data 153 repository, data definition language, query language, 154 implementation language, and protocol. [supa-policy-info-model] 156 o Information Model: An information model is a representation of 157 concepts of interest to an environment in a form that is 158 independent of data repository, data definition language, query 159 language, implementation language, and protocol. 160 [supa-policy-info-model] 162 4. Objectives 164 o Registering NSFs to I2NSF framework: Developer's Management System 165 (DMS) in I2NSF framework is typically run by an NSF vendor, and 166 uses Registration Interface to provide NSFs developed by the NSF 167 vendor to Security Controller. DMS registers NSFs and their 168 capabilities to I2NSF framework through Registration Interface, so 169 that Security Controller can use those capabilities by 170 instantiating the NSFs once they are required. Once NSFs are 171 registered to I2NSF framework, a catalog of the NSFs and their 172 capabilities is created and provided to Security Controller. When 173 we consider the implementation of I2NSF framework based on NFV 174 technology, the catalog of the NSFs may be prepared and managed by 175 NFV MANO. 177 o Updating the capabilities of registered NSFs: After an NSF is 178 registered into I2NSF framework, some modifications on the 179 capability of the NSF may be required later. In this case, DMS 180 uses Registration Interface to update the capability of the NSF, 181 and this update should be reflected on the catalog of NSFs. 183 o Retrieving the catalog of NSFs: Security Controller uses 184 Registration Interface to retrieve the catalog of available NSFs 185 and their capabilities. Enforcing security policy requires a set 186 of security capabilities that is provided by a set of NSFs. Once 187 receiving a request of security policy from an I2NSF user, 188 Security Controller figures out what capabilities are required to 189 enforce the security policy. Security Controller then searches 190 the catalog of NSFs for the required capabilities, and finally 191 determines a set of NSFs that is necessary to enforce the 192 requested policy. 194 o Requesting NSF instantiation: If some NSFs need to be instantiated 195 to enforce requested security policy, Security Controller makes a 196 request to instantiate them through Registration Interface. Or if 197 an NSF, running as a virtual NSF in the NFV environment, is not 198 used by any traffic flows for a time period, Security Controller 199 may request deinstantiating it through Registration Interface for 200 the purpose of efficient resource utilization. 202 5. Information Model 204 The I2NSF registration interface is used by Security Controller and 205 Developer's Management System (DMS) in I2NSF framework. The 206 following summarizes the process typically done through the 207 registration interface: 209 1) DMS registers NSFs to I2NSF framework through the registration 210 interface. DMS also uses the registration interface to update 211 the capabilities of the NSFs registered in the framework. 213 2) Once NSFs are registered to I2NSF framework, a catalog of the 214 NSFs and their capabilities is created and provided to Security 215 Controller via the registration interface. 217 3) Security Controller searches the catalog of NSFs for the 218 capabilities required to enforce security policies requested by 219 I2NSF users, and selects some of the NSFs that can provide the 220 required capabilities. 222 4) Security Controller requests the instantiation of the selected 223 NSFs via the registration interface. 225 This section clarifies the information model that is required to 226 support the process described above. 228 5.1. NSF Registration Mechanism 230 In order to register a new NSF, DMS should generate a registration 231 message to Security Controller. A registration message consists of 232 an NSF capability information and an NSF Access Information. The 233 former describes the security capability that the new NSF can provide 234 and the latter is for enabling network access to the NSF from other 235 components. After this registration process, as explained in 236 [capability-im], the I2NSF capability interface can conduct 237 controlling and monitoring the new registered NSF. 239 +-+-+-+-+-+-+-+-+ 240 | NSF | 241 | Registration | 242 +-+-+-+-^-+-+-+-+ 243 | 244 +-------------------------------------+ 245 | | | 246 | | | 247 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 248 | NSF Capability | | NSF Access | | NSF Rold-based | 249 | Information | | Information | | ACL | 250 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 252 Figure 1: Registration Mechanism Sub-Model Overview 254 5.2. NSF Access Information 256 NSF Access Information contains the followings that are required to 257 communicate with an NSF: IPv4 address, IPv6 address, port number, and 258 supported transport protocol(s) (e.g., Virtual Extensible LAN (VXLAN) 259 [RFC 7348], Generic Protocol Extension for VXLAN (VXLAN-GPE) 260 [draft-ietf-nvo3-vxlan-gpe], Generic Route Encapsulation (GRE), 261 Ethernet etc.). In this document, NSF Access Information is used to 262 identify a specific NSF instance (i.e. NSF Access Information is the 263 signature(unique identifier) of an NSF instance in the overall 264 system). 266 5.3. NSF Capability Information (Capabilities of an NSF Instance) 268 NSF Profile basically describes the inspection capabilities of an NSF 269 instance. In Figure 2, we show capability objects of an NSF 270 instance. Following the information model of NSF capabilities 271 defiend in [capability-im], we share the same security capabilities: 272 Network-Security Capabilities, Content-Security Capabilities, and 273 Attack Mitigation Capabilities. Also, NSF Profile additionally 274 contains the performance capabilities and role-Based access control 275 list (ACL) as shown in Figure 2. 277 +-+-+-+-+-+-+-+-+ 278 | Capability | 279 | Objects | 280 +-+-+-+-^-+-+-+-+ 281 | 282 | 283 +---------------+-------+--------------+ 284 | | | 285 | | | 286 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 287 |Network-Security | |Content-Security | | 288 | Capabilities | | Capabilities | | 289 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 290 | 291 +-----------------------+--------------+ 292 | | 293 | | 294 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 295 | Performance | |Attack Mitigation| 296 | Capabilities | | Capabilities | 297 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 299 Figure 2: NSF Profile Overview 301 5.3.1. Performance Capabilities 303 This information represents the processing capability of an NSF. 304 This information can be used to determine whether the NSF is in 305 congestion by comparing this with the workload that the NSF currently 306 undergoes. Moreover, this information can specify an available 307 amount of each type of resources such as processing power which are 308 available on the NSF. (The registration interface can control the 309 usages and limitations of the created instance and make the 310 appropriate request according to the status.) As illustrated in 311 Figure 3, this information consists of two items: Processing and 312 Bandwidth. Processing information describes the NSF's available 313 processing power. Bandwidth describes the information about 314 available network amount in two cases, outbound, inbound. This two 315 information can be used for the NSF's instance request. 317 +-+-+-+-+-+-+-+-+-+ 318 | Performance | 319 | Capabilities | 320 +-+-+-+-^-+-+-+-+-+ 321 | 322 +----------------------------+ 323 | | 324 | | 325 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 326 | Processing | | Bandwidth | 327 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 329 Figure 3: Performance Capability Overview 331 5.4. Role-based Access Control List 333 This information specifies access policies of an NSF to determine 334 whether to permit or deny the access of an entity to the NSF based on 335 the role given to the entity. Each NSF is associated with a role- 336 based access control list (ACL) so that it can determine whether to 337 permit or deny the access request from an entity. Figure 4 and 338 Figure 5 show the structure of the role-based ACL, which is composed 339 of role-id, access-type, and permit/deny. The role-id identifies 340 roles of entities (e.g., administrator, developer etc.). The access- 341 type identifies the specific type of access requests such as NSF rule 342 configuration/update and NSF monitoring. Consequently, the role- 343 based ACL in Figure 4 and Figure 5 specifies a set of access-types to 344 be permitted and to be denied by each role-id. 346 +-+-+-+-+-+-+-+-+ 347 | Role-based | 348 | ACL | 349 +-+-+-+-+-+-+-+-+ 350 | 351 +-----------------------------------+ 352 | | 353 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 354 | Role-id 1 | ... | Role-id N | 355 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 357 Figure 4: Role-based Access Control List 358 +-+-+-+-+-+-+-+-+ 359 | Role-id i | 360 +-+-+-+-+-+-+-+-+ 361 | 362 +---------------------------------+ 363 | | 364 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 365 | Permit | | Deny | 366 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 367 | | 368 +------------------+ +------------------+ 369 | | | | 370 +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ 371 |access-type| ... |access-type| |access-type| ... |access-type| 372 | p1 | | pn | | d1 | | dn | 373 +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ 375 Figure 5: Role-id Subtree 377 6. Data Model 379 6.1. High-Level YANG 381 This section provides an overview of the high level YANG. 383 6.1.1. Definition of Symbols in Tree Diagrams 385 A simplified graphical representation of the data model is used in 386 this section. The meaning of the symbols used in the following 387 diagrams [i2rs-rib-data-model] is as follows: 389 Brackets "[" and "]" enclose list keys. 391 Abbreviations before data node names: "rw" means configuration 392 (read-write) and "ro" state data (read-only). 394 Symbols after data node names: "?" means an optional node and "*" 395 denotes a "list" and "leaf-list". 397 Parentheses enclose choice and case nodes, and case nodes are also 398 marked with a colon (":"). 400 Ellipsis ("...") stands for contents of subtrees that are not 401 shown. 403 6.1.2. Registration Interface 405 module : ietf-i2nsf-regs-interface-model 406 +--rw regs-req 407 | uses i2nsf-regs-req 408 +--rw instance-mgnt-req 409 | uses i2nsf-instance-mgnt-req 411 Figure 6: High-Level YANG of I2NSF Registration Interface 413 Each of these sections mirror sections of Section 5. 415 6.1.3. Registration Request 417 This section expands the i2nsf-regs-req in Figure 6. 419 Registration Request 420 +--rw i2nsf-regs-req 421 +--rw nsf-capability-information 422 | uses i2nsf-nsf-capability-information 423 +--rw nsf-access-info 424 | uses i2nsf-nsf-access-info 426 Figure 7: High-Level YANG of I2NSF Registration Request 428 Registration Request contains the capability information of newly 429 created NSF to notify its capability to Security Controller. The 430 request also contains Network Access Information so that the Security 431 Controller can access the NSF. 433 6.1.4. Instance Management Request 435 This section expands the i2nsf-instance-mgnt-req in Figure 6. 437 Instance Management Request 438 +--rw i2nsf-instance-mgnt-req 439 +--rw req-level uint16 440 +--rw req-id uint64 441 +--rw (req-type)? 442 +--rw (instanciation-request) 443 +--rw in-nsf-capability-information 444 | uses i2nsf-nsf-capability-information 445 +--rw (deinstanciation-request) 446 +--rw de-nsf-access-info 447 | uses i2nsf-nsf-access-info 448 +--rw (updating-request) 449 +--rw update-nsf-capability-information 450 | uses i2nsf-nsf-capability-information 452 Figure 8: High-Level YANG of I2NSF Instance Mgnt Request 454 Instance management request consists of two types: instanciation- 455 request, deinstanciation-request, and updating-request. The 456 instanciation-request is used to request generation of a new NSF 457 instance with NSF Capability Information which specifies required NSF 458 capability information. The deinstanciation-request is used to 459 remove an existing NSF with NSF Access Information. The updating nsf 460 request is used to updating a existing NSf information with NSF 461 capabilities. 463 6.1.5. NSF Capability Information 465 This section expands the i2nsf-nsf-capability-information in Figure 7 466 and Figure 8. 468 NSF Capability Information 469 +--rw i2nsf-nsf-capability-information 470 +--rw i2nsf-capability 471 | uses ietf-i2nsf-capability 472 +--rw performance-capability 473 | uses i2nsf-nsf-performance-caps 475 Figure 9: High-Level YANG of I2NSF NSF Capability Information 477 In Figure 9, ietf-i2nsf-capability refers module ietf-i2nsf- 478 capability in [i2nsf-capability-dm]. We add the performance 479 capability because it is absent in [i2nsf-capability-dm] and 480 [netmod-acl-model] 482 6.1.6. NSF Access Information 484 This section expands the i2nsf-nsf-access-info in Figure 7 and 485 Figure 8. 487 NSF Access Information 488 +--rw i2nsf-nsf-access-info 489 +--rw nsf-address inet:ipv4-address 490 +--rw nsf-port-address inet:port-number 492 Figure 10: High-Level YANG of I2NSF NSF Access Informantion 494 This information is used by other components to access an NSF. 496 6.1.7. NSF Performance Capability 498 This section expands the i2nsf-nsf-performance-caps in Figure 9. 500 NSF Performance Capability 501 +--rw i2nsf-nsf-performance-caps 502 +--rw processing 503 | +--rw processing-average uint16 504 | +--rw processing-peak uint16 505 +--rw bandwidth 506 | +--rw outbound 507 | | +--rw outbound-average uint16 508 | | +--rw outbound-peak uint16 509 | +--rw inbound 510 | | +--rw inbound-average uint16 511 | | +--rw inbound-peak uint16 513 Figure 11: High-Level YANG of I2NSF NSF Performance Capability 515 When the Security Controller requests the Developer Management System 516 to create a new NSF instance, the performance capability is used to 517 specify the performance requirements of the new instance. 519 6.1.8. Role-Based ACL(Access Control List) 521 This section expands the ietf-netmod-acl-model in [netmod-acl-model]. 523 Role-Based ACL 524 +--rw role-based-acl 525 uses ietf-netmod-acl-model 527 Figure 12: Role-Based ACL 529 In [netmod-acl-model], ietf-netmod-acl-model refers module ietf- 530 netmod-acl-model in [netmod-acl-model]. We add the role-based ACL 531 because it is absent in [i2nsf-capability-dm]. 533 6.2. YANG Modules 535 This section introduces a YANG module for the information model of 536 the required data for the registration interface between Security 537 Controller and Developer's Management System, as defined in 538 Section 5. 540 file "ietf-i2nsf-regs-interface@2018-11-04.yang" 541 module ietf-i2nsf-regs-interface { 542 namespace 543 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-regs-interface"; 544 prefix 545 regs-interface; 546 import ietf-inet-types{ 547 prefix inet; 548 } 550 organization 551 "IETF I2NSF (Interface to Network Security Functions) 552 Working Group"; 554 contact 555 "WG Web: 556 WG List: 558 WG Chair: Adrian Farrel 559 561 WG Chair: Linda Dunbar 562 564 Editor: Sangwon Hyun 565 567 Editor: Jaehoon Paul Jeong 568 570 Editor: Taekyun Roh 571 573 Editor: Sarang Wi 574 576 Editor: Jung-Soo Park 577 "; 579 description 580 "It defines a YANG data module for Registration Interface."; 581 revision "2018-11-04"{ 582 description "The second revision"; 583 reference 584 "draft-ietf-i2nsf-capability-data-model-01"; 585 } 586 list interface-container{ 587 key "interface-name"; 588 description 589 "i2nsf-reg-interface-container"; 590 leaf interface-name{ 591 type string; 592 description 593 "interface name"; 594 } 595 container i2nsf-regs-req { 596 description 597 "The capability information of newly 598 created NSF to notify its 599 capability to Security Controller"; 600 container nsf-capability-information { 601 description 602 "nsf-capability-information"; 603 uses i2nsf-nsf-capability-information; 604 } 605 container nsf-access-info { 606 description 607 "nsf-access-info"; 608 uses i2nsf-nsf-access-info; 609 } 610 container ietf-netmod-acl-model{ 611 description 612 "netmod-acl-model"; 613 uses ietf-netmod-acl-model; 614 } 615 } 616 container i2nsf-instance-mgnt-req { 617 description 618 "Required information for instanciation-request, 619 deinstanciation-request and updating-request"; 620 leaf req-level { 621 type uint16; 622 description 623 "req-level"; 624 } 625 leaf req-id { 626 type uint64; 627 mandatory true; 628 description 629 "req-id"; 630 } 631 choice req-type { 632 description 633 "req-type"; 634 case instanciation-request { 635 description 636 "instanciation-request"; 637 container in-nsf-capability-information { 638 description 639 "nsf-capability-information"; 640 uses i2nsf-nsf-capability-information; 641 } 642 } 643 case deinstanciation-request { 644 description 645 "deinstanciation-request"; 646 container de-nsf-access-info { 647 description 648 "nsf-access-info"; 649 uses i2nsf-nsf-access-info; 650 } 651 } 652 case updating-request { 653 description 654 "updating nsf's information"; 655 container update-nsf-capability-information { 656 description 657 "nsf-capability-information"; 658 uses i2nsf-nsf-capability-information; 659 } 660 } 661 } 662 } 663 } 664 grouping i2nsf-nsf-performance-caps { 665 description 666 "NSF performance capailities"; 667 container processing{ 668 description 669 "processing info"; 670 leaf processing-average{ 671 type uint16; 672 description 673 "processing-average"; 674 } 675 leaf processing-peak{ 676 type uint16; 677 description 678 "processing peak"; 679 } 680 } 681 container bandwidth{ 682 description 683 "bandwidth info"; 684 container inbound{ 685 description 686 "inbound"; 687 leaf inbound-average{ 688 type uint16; 689 description 690 "inbound-average"; 691 } 692 leaf inbound-peak{ 693 type uint16; 694 description 695 "inbound-peak"; 696 } 697 } 698 container outbound{ 699 description 700 "outbound"; 701 leaf outbound-average{ 702 type uint16; 703 description 704 "outbound-average"; 705 } 706 leaf outbound-peak{ 707 type uint16; 708 description 709 "outbound-peak"; 710 } 711 } 712 } 713 } 714 grouping i2nsf-nsf-capability-information { 715 description 716 "Detail information of an NSF"; 717 container performance-capability { 718 uses i2nsf-nsf-performance-caps; 719 description 720 "performance-capability"; 722 } 723 container i2nsf-capability { 724 description 725 "It refers draft-ietf-i2nsf-capability-data-model-01.txt 726 later"; 727 } 728 } 729 grouping ietf-netmod-acl-model { 730 description 731 "Detail information"; 732 container role-based-acl { 733 description 734 "It refers draft-ietf-netmod-acl-model-19.txt 735 later"; 736 } 737 } 738 grouping i2nsf-nsf-access-info { 739 description 740 "NSF access information"; 741 leaf nsf-address { 742 type inet:ipv4-address; 743 mandatory true; 744 description 745 "nsf-address"; 746 } 747 leaf nsf-port-address { 748 type inet:port-number; 749 description 750 "nsf-port-address"; 751 } 752 } 753 } 755 757 Figure 13: Data Model of I2NSF Registration Interface 759 6.2.1. XML Example of Registration Interface Data Model 761 Requirement: Registering the IDS NSF with VoIP/VoLTE security 762 capability using Registration interface. 764 Here is the configuration xml for this Registration Interface: 766 767 768 769 770 771 772 773 774 775 776 777 1 778 779 780 781 true 782 783 ids-service 784 785 786 787 true 788 789 790 ips-service 791 792 793 794 795 796 797 798 799 800 1000 801 5000 802 803 804 805 1000 806 5000 807 808 809 1000 810 5000 811 812 813 814 815 816 10.0.0.1 817 145 819 820 821 822 823 825 Figure 14: Registration Interface example 827 7. Security Considerations 829 This document introduces no additional security threats and SHOULD 830 follow the security requirements as stated in [RFC8329]. 832 8. References 834 8.1. Normative References 836 [RFC2119] Bradner, S., "Key words for use in RFCs toIndicate 837 Requirement Levels", RFC 2119, March 1997. 839 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 840 Network Configuration Protocol (NETCONF)", RFC 6020, 841 October 2010. 843 8.2. Informative References 845 [capability-im] 846 Xia, L., Strassner, J., Basile, C., and D. Lopez, 847 "Information Model of NSFs Capabilities", draft-i2nsf- 848 capability-02 (work in progress), July 2018. 850 [draft-ietf-nvo3-vxlan-gpe] 851 Maino, Ed., F., Kreeger, Ed., L., and U. Elzur, Ed., 852 "Generic Protocol Extension for VXLAN", draft-ietf-nvo3- 853 vxlan-gpe-06 (work in progress), April 2018. 855 [i2nsf-capability-dm] 856 Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin, 857 "I2NSF Capability YANG Data Model", draft-ietf-i2nsf- 858 capability-data-model-01 (work in progress), July 2018. 860 [i2nsf-terminology] 861 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 862 Birkholz, "Interface to Network Security Functions (I2NSF) 863 Terminology", draft-ietf-i2nsf-terminology-06 (work in 864 progress), July 2018. 866 [i2rs-rib-data-model] 867 Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 868 S., and N. Bahadur, "A YANG Data Model for Routing 869 Information Base (RIB)", draft-ietf-i2rs-rib-data-model-15 870 (work in progress), May 2018. 872 [netmod-acl-model] 873 Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, 874 "Network Access Control List (ACL) YANG Data Model", 875 draft-ietf-netmod-acl-model-19 (work in progress), April 876 2018. 878 [nfv-framework] 879 "Network Functions Virtualisation (NFV); Architectureal 880 Framework", ETSI GS NFV 002 ETSI GS NFV 002 V1.1.1, 881 October 2013. 883 [nsf-triggered-steering] 884 Hyun, S., Jeong, J., Park, J., and S. Hares, "Service 885 Function Chaining-Enabled I2NSF Architecture", draft-hyun- 886 i2nsf-nsf-triggered-steering-06 (work in progress), July 887 2018. 889 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 890 Kumar, "Framework for Interface to Network Security 891 Functions", RFC 8329, February 2018. 893 [supa-policy-data-model] 894 Halpern, J., Strassner, J., and S. van der Meer, "Generic 895 Policy Data Model for Simplified Use of Policy 896 Abstractions (SUPA)", draft-ietf-supa-generic-policy-data- 897 model-04 (work in progress), June 2017. 899 [supa-policy-info-model] 900 Strassner, J., Halpern, J., and S. van der Meer, "Generic 901 Policy Information Model for Simplified Use of Policy 902 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 903 model-03 (work in progress), May 2017. 905 Appendix A. NSF Lifecycle Managmenet in NFV Environments 907 Network Functions Virtualization (NFV) can be used to implement I2NSF 908 framework. In NFV environments, NSFs are deployed as virtual network 909 functions (VNFs). Security Controller can be implemented as an 910 Element Management (EM) of the NFV architecture, and is connected 911 with the VNF Manager (VNFM) via the Ve-Vnfm interface 912 [nfv-framework]. Security Controller can use this interface for the 913 purpose of the lifecycle management of NSFs. If some NSFs need to be 914 instantiated to enforce security policies in the I2NSF framework, 915 Security Controller could request the VNFM to instantiate them 916 through the Ve-Vnfm interface. Or if an NSF, running as a VNF, is 917 not used by any traffic flows for a time period, Security Controller 918 may request deinstantiating it through the interface for efficient 919 resource utilization. 921 Appendix B. Changes from draft-ietf-i2nsf-registration-interface-dm-00 923 The following changes have been made from draft-ietf-i2nsf- 924 registration-interface-dm-00: 926 o Section 4 has been revised to clarify the major objectives of the 927 I2NSF registration interface, considering the register-select- 928 instantiate operation sequence that is typically performed through 929 the registration interface in I2NSF framework based on NFV. 931 o Section 5 has been revised as well based on the register-select- 932 instantiate operation sequence. 934 o Appendix A has been added to clarify the lifecycle management of 935 NSFs in I2NSF framework based on NFV. 937 Appendix C. Acknowledgments 939 This work was supported by Institute for Information & communications 940 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 941 (No.R-20160222-002755, Cloud based Security Intelligence Technology 942 Development for the Customized Security Service Provisioning). 944 Appendix D. Contributors 946 This document is made by the group effort of I2NSF working group. 947 Many people actively contributed to this document. The following are 948 considered co-authors: 950 o Jinyong Tim Kim (Sungkyunkwan University) 952 o Susan Hares (Huawei) 953 o Diego R. Lopez (Telefonica) 955 Authors' Addresses 957 Sangwon Hyun 958 Department of Computer Engineering 959 Chosun University 960 309, Pilmun-daero, Dong-gu 961 Gwangju, Jeollanam-do 61452 962 Republic of Korea 964 EMail: shyun@chosun.ac.kr 966 Jaehoon Paul Jeong 967 Department of Software 968 Sungkyunkwan University 969 2066 Seobu-Ro, Jangan-Gu 970 Suwon, Gyeonggi-Do 16419 971 Republic of Korea 973 Phone: +82 31 299 4957 974 Fax: +82 31 290 7996 975 EMail: pauljeong@skku.edu 976 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 978 Taekyun Roh 979 Electrical Computer Engineering 980 Sungkyunkwan University 981 2066 Seobu-Ro, Jangan-Gu 982 Suwon, Gyeonggi-Do 16419 983 Republic of Korea 985 Phone: +82 31 290 7222 986 Fax: +82 31 299 6673 987 EMail: tkroh0198@skku.edu 988 URI: http://imtl.skku.ac.kr/xe/index.php?mid=board_YoKq57 989 Sarang Wi 990 Electrical Computer Engineering 991 Sungkyunkwan University 992 2066 Seobu-Ro, Jangan-Gu 993 Suwon, Gyeonggi-Do 16419 994 Republic of Korea 996 Phone: +82 31 290 7222 997 Fax: +82 31 299 6673 998 EMail: dnl9795@skku.edu 999 URI: http://imtl.skku.ac.kr/xe/index.php?mid=board_YoKq57 1001 Jung-Soo Park 1002 Electronics and Telecommunications Research Institute 1003 218 Gajeong-Ro, Yuseong-Gu 1004 Daejeon 305-700 1005 Republic of Korea 1007 Phone: +82 42 860 6514 1008 EMail: pjs@etri.re.kr