idnits 2.17.1 draft-ietf-i2nsf-registration-interface-dm-00.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 525 has weird spacing: '...address inet:...' -- The document date (October 20, 2018) is 2008 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 295, 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 Network Working Group S. Hyun 3 Internet-Draft Chosun University 4 Intended status: Standards Track J. Jeong 5 Expires: April 23, 2019 T. Roh 6 S. Wi 7 Sungkyunkwan University 8 J. Park 9 ETRI 10 October 20, 2018 12 I2NSF Registration Interface Data Model 13 draft-ietf-i2nsf-registration-interface-dm-00 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 April 23, 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 Instance Managment Mechanism . . . . . . . . . . . . 6 64 5.2. NSF Registration Mechanism . . . . . . . . . . . . . . . 6 65 5.3. NSF Access Information . . . . . . . . . . . . . . . . . 7 66 5.4. NSF Capability Information (Capabilities of an NSF 67 instance) . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.4.1. Performance Capabilities . . . . . . . . . . . . . . 8 69 5.5. Role-based Access Control List . . . . . . . . . . . . . 9 70 6. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6.1. High-Level YANG . . . . . . . . . . . . . . . . . . . . . 10 72 6.1.1. Definition of Symbols in Tree Diagrams . . . . . . . 10 73 6.1.2. Registration Interface . . . . . . . . . . . . . . . 11 74 6.1.3. Registration Request . . . . . . . . . . . . . . . . 11 75 6.1.4. Instance Management Request . . . . . . . . . . . . . 11 76 6.1.5. NSF Capability Information . . . . . . . . . . . . . 12 77 6.1.6. NSF Access Information . . . . . . . . . . . . . . . 13 78 6.1.7. NSF Performance Capability . . . . . . . . . . . . . 13 79 6.1.8. Role-Based ACL(Access Control List) . . . . . . . . . 13 80 6.2. YANG Modules . . . . . . . . . . . . . . . . . . . . . . 14 81 6.2.1. XML Example of Registration Interface Data Model . . 18 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 83 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 86 9.2. Informative References . . . . . . . . . . . . . . . . . 20 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 A number of virtual network security function instances typically 92 exist in Interface to Network Security Functions (I2NSF) framework 93 [RFC8329]. Since these NSF instances may have different security 94 capabilities, it is important to register the security capabilities 95 of each NSF instance into the security controller after they have 96 been created. In addition, it is required to search or instantiate 97 NSFs of some required security capabilities on demand. As an 98 example, if additional security capabilities are required to meet the 99 new security requirements that an I2NSF user requests, the security 100 controller should be able to request the DMS for NSFs that have the 101 required security capabilities. 103 This document describes an information model (see Section 5) and a 104 YANG [RFC6020] data model (see Section 6) for the I2NSF Registration 105 Interface [RFC8329] between the security controller and the 106 developer's management system (DMS) to support NSF search, 107 instantiation and registration according to required security 108 capabilities. It also describes the procedure which should be 109 performed by the security controller and the DMS via the Registration 110 Interface using the defined model. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Terminology 120 This document uses the following terms defined in 121 [i2nsf-terminology], [capability-im], [RFC8329], 122 [nsf-triggered-steering], [supa-policy-data-model], and 123 [supa-policy-info-model] 125 o Network Security Function (NSF): A function that is responsible 126 for specific treatment of received packets. A Network Security 127 Function can act at various layers of a protocol stack (e.g., at 128 the network layer or other OSI layers). Sample Network Security 129 Service Functions are as follows: Firewall, Intrusion Prevention/ 130 Detection System (IPS/IDS), Deep Packet Inspection (DPI), 131 Application Visibility and Control (AVC), network virus and 132 malware scanning, sandbox, Data Loss Prevention (DLP), Distributed 133 Denial of Service (DDoS) mitigation and TLS proxy. 134 [nsf-triggered-steering] 136 o Advanced Inspection/Action: As like the I2NSF information model 137 for NSF facing interface [capability-im], Advanced Inspection/ 138 Action means that a security function calls another security 139 function for further inspection based on its own inspection 140 result. [nsf-triggered-steering] 142 o NSF Profile (NSF Capability Information): NSF Capability 143 Information specifies the inspection capabilities of the 144 associated NSF instance. Each NSF instance has its own NSF 145 Capability Information to specify the type of security service it 146 provides and its resource capacity etc. [nsf-triggered-steering] 148 o Data Model: A data model is a representation of concepts of 149 interest to an environment in a form that is dependent on data 150 repository, data definition language, query language, 151 implementation language, and protocol. [supa-policy-info-model] 153 o Information Model: An information model is a representation of 154 concepts of interest to an environment in a form that is 155 independent of data repository, data definition language, query 156 language, implementation language, and protocol. 157 [supa-policy-info-model] 159 4. Objectives 161 o Registering NSF instances from Developer's Management System: 162 Depending on system's security requirements, it may require some 163 NSFs by default. In this case, DMS creates these default NSF 164 instances and notifies Security Controller of those NSF instances 165 via Registration Interface. 167 o Requesting NSF instances with required security capabilities: 168 I2NSF users request security policies to Security Controller, and 169 enforcing the security policies requires a set of security 170 capabilities. In addition, when an NSF triggers another type of 171 NSF(s) for more advanced security inspection of a given traffic, 172 some security capabilities are also required to perform the 173 advanced security inspection. If Security Controller has no NSF 174 instance registered with the requried capabilities, Security 175 Controller requests DMS for new NSF instances that can provide the 176 required capabilities. Once receiving this request, DMS could 177 first search its inventory for NSF instances with the required 178 capabilities. If DMS fails to find any NSF instance, it creates 179 new NSF instances with the required security capabilities and 180 registers the NSF instances to Security Controller. 182 o Deleting unnecessary NSF instances: In I2NSF framework, users 183 decide which security service is unnecessary in the system. If 184 there exist any unused NSF instances, then we should delete the 185 existing instances by requesting DMS via registration interface. 187 o Updating NSF instances: After an NSF instance is registered into 188 I2NSF framework, some changes may happen on the capability of the 189 NSF instance. These changes should be informed to Security 190 Controller. For this, after updating some NSF instances, DMS 191 notifies Security Controller of the update via registration 192 interface. 194 5. Information Model 196 The I2NSF registration interface was only used for registering new 197 NSF instances to Security Controller. In this document, however, we 198 extend its utilization to support on demand NSF instantiation/de- 199 instantiation and describe the information that should be exchanged 200 via the registration interface for the functionality. Moreover, we 201 also define the information model of NSF Profile because, for 202 registration interface, NSF Profile (i.e., capabilities of an NSF) 203 needs to be clarified so that the components of I2NSF framework can 204 exchange the set of capabilities in a standardized manner. This is 205 typically done through the following process: 207 1) Security Controller first recognizes the set of capabilities 208 (i.e., NSF Profile) or the signature of a specific NSF required 209 or wasted in the current system. 211 2) Developer's Management System (DMS) matches the recognized 212 information to an NSF based on the information model definition. 214 3) Developer's Management System creates or eliminates NSFs matching 215 with the above information. 217 4) Security Controller can then add/remove the corresponding NSF 218 instance to/from its list of available NSF instances in the 219 system. 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Registration Interface Information Model | 223 | | 224 | +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | 225 | | Instance Management | | Registration | | 226 | | Sub-Model | | Sub-Model | | 227 | +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 1: Registration Interface Information Model 232 As illustrated in Figure 1, the information model for Registration 233 Interface consists of two sub-models: instance management, 234 registration sub-models. The instance management functionality and 235 the registration functionality use NSF Profile to achieve their 236 goals. In this context, NSF Profile is the capability objects that 237 describe and/or prescribe inspection capability an NSF instance can 238 provide. 240 5.1. NSF Instance Managment Mechanism 242 For the instance management of NSFs, Security Controller in I2NSF 243 framework requires two types of requests: Instantiation Request and 244 Deinstantiation Request. Security Controller sends the request 245 messages to DMS when required. Once receiving the request, DMS 246 conducts creating/eliminating the corresponding NSF instance and 247 responds Security Controller with the results. 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+ 250 | Instantiation/Re-instantiation | | De-instantiation | 251 | Request | | Request | 252 +-+-+-+-+-+-+-+-+-^-+-+-+-+-+-+-+-+ +-+-+-+-+-^-+-+-+-+-+ 253 | | 254 | | 255 | | 256 | | 257 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 258 | NSF Capability | | NSF Access | 259 | Information | | Information | 260 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 262 Figure 2: Overview of Instance Management Sub-Model 264 5.2. NSF Registration Mechanism 266 In order to register a new NSF instance, DMS should generate a 267 Registration Message to Security Controller. A Registration Message 268 consists of an NSF Profile and an NSF Access Information. The former 269 describes the inspection capability of the new NSF instance and the 270 latter is for enabling network access to the new instance from other 271 components. After this registration process, as explained in 272 [capability-im], the I2NSF capability interface can conduct 273 controlling and monitoring the new registered NSF instance. 275 +-+-+-+-+-+-+-+-+ 276 | NSF | 277 | Registration | 278 +-+-+-+-^-+-+-+-+ 279 | 280 +-------------------------------------+ 281 | | | 282 | | | 283 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 284 | NSF Capability | | NSF Access | | NSF Rold-based | 285 | Information | | Information | | ACL | 286 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 288 Figure 3: Registration Mechanism Sub-Model Overview 290 5.3. NSF Access Information 292 NSF Access Information contains the followings that are required to 293 communicate with an NSF: IPv4 address, IPv6 address, port number, and 294 supported transport protocol(s) (e.g., Virtual Extensible LAN (VXLAN) 295 [RFC 7348], Generic Protocol Extension for VXLAN (VXLAN-GPE) 296 [draft-ietf-nvo3-vxlan-gpe], Generic Route Encapsulation (GRE), 297 Ethernet etc.). In this document, NSF Access Information is used to 298 identify a specific NSF instance (i.e. NSF Access Information is the 299 signature(unique identifier) of an NSF instance in the overall 300 system). 302 5.4. NSF Capability Information (Capabilities of an NSF instance) 304 NSF Profile basically describes the inspection capabilities of an NSF 305 instance. In Figure 4, we show capability objects of an NSF 306 instance. Following the information model of NSF capabilities 307 defiend in [capability-im], we share the same security capabilities: 308 Network-Security Capabilities, Content-Security Capabilities, and 309 Attack Mitigation Capabilities. Also, NSF Profile additionally 310 contains the performance capabilities and role-Based access control 311 list (ACL) as shown in Figure 4. 313 +-+-+-+-+-+-+-+-+ 314 | Capability | 315 | Objects | 316 +-+-+-+-^-+-+-+-+ 317 | 318 | 319 +---------------+-------+--------------+ 320 | | | 321 | | | 322 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 323 |Network-Security | |Content-Security | | 324 | Capabilities | | Capabilities | | 325 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 326 | 327 +-----------------------+--------------+ 328 | | 329 | | 330 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 331 | Performance | |Attack Mitigation| 332 | Capabilities | | Capabilities | 333 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 335 Figure 4: NSF Profile Overview 337 5.4.1. Performance Capabilities 339 This information represents the processing capability of an NSF. 340 This information can be used to determine whether the NSF is in 341 congestion by comparing this with the workload that the NSF currently 342 undergoes. Moreover, this information can specify an available 343 amount of each type of resources such as processing power which are 344 available on the NSF. (The registration interface can control the 345 usages and limitations of the created instance and make the 346 appropriate request according to the status.) As illustrated in 347 Figure 5, this information consists of two items: Processing and 348 Bandwidth. Processing information describes the NSF's available 349 processing power. Bandwidth describes the information about 350 available network amount in two cases, outbound, inbound. This two 351 information can be used for the NSF's instance request. 353 +-+-+-+-+-+-+-+-+-+ 354 | Performance | 355 | Capabilities | 356 +-+-+-+-^-+-+-+-+-+ 357 | 358 +----------------------------+ 359 | | 360 | | 361 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 362 | Processing | | Bandwidth | 363 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 365 Figure 5: Performance Capability Overview 367 5.5. Role-based Access Control List 369 This information specifies access policies of an NSF to determine 370 whether to permit or deny the access of an entity to the NSF based on 371 the role given to the entity. Each NSF is associated with a role- 372 based access control list (ACL) so that it can determine whether to 373 permit or deny the access request from an entity. Figure 6 and 374 Figure 7 show the structure of the role-based ACL, which is composed 375 of role-id, access-type, and permit/deny. The role-id identifies 376 roles of entities (e.g., administrator, developer etc.). The access- 377 type identifies the specific type of access requests such as NSF rule 378 configuration/update and NSF monitoring. Consequently, the role- 379 based ACL in Figure 6 and Figure 7 specifies a set of access-types to 380 be permitted and to be denied by each role-id. 382 +-+-+-+-+-+-+-+-+ 383 | Role-based | 384 | ACL | 385 +-+-+-+-+-+-+-+-+ 386 | 387 +-----------------------------------+ 388 | | 389 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 390 | Role-id 1 | ... | Role-id N | 391 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 393 Figure 6: Role-based Access Control List 394 +-+-+-+-+-+-+-+-+ 395 | Role-id i | 396 +-+-+-+-+-+-+-+-+ 397 | 398 +---------------------------------+ 399 | | 400 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 401 | Permit | | Deny | 402 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 403 | | 404 +------------------+ +------------------+ 405 | | | | 406 +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ 407 |access-type| ... |access-type| |access-type| ... |access-type| 408 | p1 | | pn | | d1 | | dn | 409 +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ 411 Figure 7: Role-id Subtree 413 6. Data Model 415 6.1. High-Level YANG 417 This section provides an overview of the high level YANG. 419 6.1.1. Definition of Symbols in Tree Diagrams 421 A simplified graphical representation of the data model is used in 422 this section. The meaning of the symbols used in the following 423 diagrams [i2rs-rib-data-model] is as follows: 425 Brackets "[" and "]" enclose list keys. 427 Abbreviations before data node names: "rw" means configuration 428 (read-write) and "ro" state data (read-only). 430 Symbols after data node names: "?" means an optional node and "*" 431 denotes a "list" and "leaf-list". 433 Parentheses enclose choice and case nodes, and case nodes are also 434 marked with a colon (":"). 436 Ellipsis ("...") stands for contents of subtrees that are not 437 shown. 439 6.1.2. Registration Interface 441 module : ietf-i2nsf-regs-interface-model 442 +--rw regs-req 443 | uses i2nsf-regs-req 444 +--rw instance-mgnt-req 445 | uses i2nsf-instance-mgnt-req 447 Figure 8: High-Level YANG of I2NSF Registration Interface 449 Each of these sections mirror sections of Section 5. 451 6.1.3. Registration Request 453 This section expands the i2nsf-regs-req in Figure 8. 455 Registration Request 456 +--rw i2nsf-regs-req 457 +--rw nsf-capability-information 458 | uses i2nsf-nsf-capability-information 459 +--rw nsf-access-info 460 | uses i2nsf-nsf-access-info 462 Figure 9: High-Level YANG of I2NSF Registration Request 464 Registration Request contains the capability information of newly 465 created NSF to notify its capability to Security Controller. The 466 request also contains Network Access Information so that the Security 467 Controller can access the NSF. 469 6.1.4. Instance Management Request 471 This section expands the i2nsf-instance-mgnt-req in Figure 8. 473 Instance Management Request 474 +--rw i2nsf-instance-mgnt-req 475 +--rw req-level uint16 476 +--rw req-id uint64 477 +--rw (req-type)? 478 +--rw (instanciation-request) 479 +--rw in-nsf-capability-information 480 | uses i2nsf-nsf-capability-information 481 +--rw (deinstanciation-request) 482 +--rw de-nsf-access-info 483 | uses i2nsf-nsf-access-info 484 +--rw (updating-request) 485 +--rw update-nsf-capability-information 486 | uses i2nsf-nsf-capability-information 488 Figure 10: High-Level YANG of I2NSF Instance Mgnt Request 490 Instance management request consists of two types: instanciation- 491 request, deinstanciation-request, and updating-request. The 492 instanciation-request is used to request generation of a new NSF 493 instance with NSF Capability Information which specifies required NSF 494 capability information. The deinstanciation-request is used to 495 remove an existing NSF with NSF Access Information. The updating nsf 496 request is used to updating a existing NSf information with NSF 497 capabilities. 499 6.1.5. NSF Capability Information 501 This section expands the i2nsf-nsf-capability-information in Figure 9 502 and Figure 10. 504 NSF Capability Information 505 +--rw i2nsf-nsf-capability-information 506 +--rw i2nsf-capability 507 | uses ietf-i2nsf-capability 508 +--rw performance-capability 509 | uses i2nsf-nsf-performance-caps 511 Figure 11: High-Level YANG of I2NSF NSF Capability Information 513 In Figure 11, ietf-i2nsf-capability refers module ietf-i2nsf- 514 capability in [i2nsf-capability-dm]. We add the performance 515 capability because it is absent in [i2nsf-capability-dm] and 516 [netmod-acl-model] 518 6.1.6. NSF Access Information 520 This section expands the i2nsf-nsf-access-info in Figure 9 and 521 Figure 10. 523 NSF Access Information 524 +--rw i2nsf-nsf-access-info 525 +--rw nsf-address inet:ipv4-address 526 +--rw nsf-port-address inet:port-number 528 Figure 12: High-Level YANG of I2NSF NSF Access Informantion 530 This information is used by other components to access an NSF. 532 6.1.7. NSF Performance Capability 534 This section expands the i2nsf-nsf-performance-caps in Figure 11. 536 NSF Performance Capability 537 +--rw i2nsf-nsf-performance-caps 538 +--rw processing 539 | +--rw processing-average uint16 540 | +--rw processing-peak uint16 541 +--rw bandwidth 542 | +--rw outbound 543 | | +--rw outbound-average uint16 544 | | +--rw outbound-peak uint16 545 | +--rw inbound 546 | | +--rw inbound-average uint16 547 | | +--rw inbound-peak uint16 549 Figure 13: High-Level YANG of I2NSF NSF Performance Capability 551 When the Security Controller requests the Developer Management System 552 to create a new NSF instance, the performance capability is used to 553 specify the performance requirements of the new instance. 555 6.1.8. Role-Based ACL(Access Control List) 557 This section expands the ietf-netmod-acl-model in [netmod-acl-model]. 559 Role-Based ACL 560 +--rw role-based-acl 561 uses ietf-netmod-acl-model 563 Figure 14: Role-Based ACL 565 In [netmod-acl-model], ietf-netmod-acl-model refers module ietf- 566 netmod-acl-model in [netmod-acl-model]. We add the role-based ACL 567 because it is absent in [i2nsf-capability-dm]. 569 6.2. YANG Modules 571 This section introduces a YANG module for the information model of 572 the required data for the registration interface between Security 573 Controller and Developer's Management System, as defined in 574 Section 5. 576 file "ietf-i2nsf-regs-interface@2018-07-26.yang" 577 module ietf-i2nsf-regs-interface { 578 namespace 579 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-regs-interface"; 580 prefix 581 regs-interface; 582 import ietf-inet-types{ 583 prefix inet; 584 } 586 organization 587 "IETF I2NSF (Interface to Network Security Functions) 588 Working Group"; 590 contact 591 "WG Web: 592 WG List: 594 WG Chair: Adrian Farrel 595 597 WG Chair: Linda Dunbar 598 600 Editor: Sangwon Hyun 601 603 Editor: Jaehoon Paul Jeong 604 606 Editor: Taekyun Roh 607 609 Editor: Sarang Wi 610 612 Editor: Jung-Soo Park 613 "; 615 description 616 "It defines a YANG data module for Registration Interface."; 617 revision "2018-07-26"{ 618 description "The second revision"; 619 reference 620 "draft-ietf-i2nsf-capability-data-model-01"; 621 } 622 list interface-container{ 623 key "interface-name"; 624 description 625 "i2nsf-reg-interface-container"; 626 leaf interface-name{ 627 type string; 628 description 629 "interface name"; 630 } 631 container i2nsf-regs-req { 632 description 633 "The capability information of newly 634 created NSF to notify its 635 capability to Security Controller"; 636 container nsf-capability-information { 637 description 638 "nsf-capability-information"; 639 uses i2nsf-nsf-capability-information; 640 } 641 container nsf-access-info { 642 description 643 "nsf-access-info"; 644 uses i2nsf-nsf-access-info; 645 } 646 container ietf-netmod-acl-model{ 647 description 648 "netmod-acl-model"; 649 uses ietf-netmod-acl-model; 650 } 651 } 652 container i2nsf-instance-mgnt-req { 653 description 654 "Required information for instanciation-request, 655 deinstanciation-request and updating-request"; 656 leaf req-level { 657 type uint16; 658 description 659 "req-level"; 660 } 661 leaf req-id { 662 type uint64; 663 mandatory true; 664 description 665 "req-id"; 666 } 667 choice req-type { 668 description 669 "req-type"; 670 case instanciation-request { 671 description 672 "instanciation-request"; 673 container in-nsf-capability-information { 674 description 675 "nsf-capability-information"; 676 uses i2nsf-nsf-capability-information; 677 } 678 } 679 case deinstanciation-request { 680 description 681 "deinstanciation-request"; 682 container de-nsf-access-info { 683 description 684 "nsf-access-info"; 685 uses i2nsf-nsf-access-info; 686 } 687 } 688 case updating-request { 689 description 690 "updating nsf's information"; 691 container update-nsf-capability-information { 692 description 693 "nsf-capability-information"; 694 uses i2nsf-nsf-capability-information; 695 } 696 } 697 } 698 } 699 } 700 grouping i2nsf-nsf-performance-caps { 701 description 702 "NSF performance capailities"; 703 container processing{ 704 description 705 "processing info"; 706 leaf processing-average{ 707 type uint16; 708 description 709 "processing-average"; 710 } 711 leaf processing-peak{ 712 type uint16; 713 description 714 "processing peak"; 715 } 716 } 717 container bandwidth{ 718 description 719 "bandwidth info"; 720 container inbound{ 721 description 722 "inbound"; 723 leaf inbound-average{ 724 type uint16; 725 description 726 "inbound-average"; 727 } 728 leaf inbound-peak{ 729 type uint16; 730 description 731 "inbound-peak"; 732 } 733 } 734 container outbound{ 735 description 736 "outbound"; 737 leaf outbound-average{ 738 type uint16; 739 description 740 "outbound-average"; 741 } 742 leaf outbound-peak{ 743 type uint16; 744 description 745 "outbound-peak"; 746 } 747 } 748 } 749 } 750 grouping i2nsf-nsf-capability-information { 751 description 752 "Detail information of an NSF"; 753 container performance-capability { 754 uses i2nsf-nsf-performance-caps; 755 description 756 "performance-capability"; 758 } 759 container i2nsf-capability { 760 description 761 "It refers draft-ietf-i2nsf-capability-data-model-01.txt 762 later"; 763 } 764 } 765 grouping ietf-netmod-acl-model { 766 description 767 "Detail information"; 768 container role-based-acl { 769 description 770 "It refers draft-ietf-netmod-acl-model-19.txt 771 later"; 772 } 773 } 774 grouping i2nsf-nsf-access-info { 775 description 776 "NSF access information"; 777 leaf nsf-address { 778 type inet:ipv4-address; 779 mandatory true; 780 description 781 "nsf-address"; 782 } 783 leaf nsf-port-address { 784 type inet:port-number; 785 description 786 "nsf-port-address"; 787 } 788 } 789 } 791 793 Figure 15: Data Model of I2NSF Registration Interface 795 6.2.1. XML Example of Registration Interface Data Model 797 Requirement: Registering the IDS NSF with VoIP/VoLTE security 798 capability using Registration interface. 800 Here is the configuration xml for this Registration Interface: 802 803 804 805 806 807 808 809 810 811 812 813 1 814 815 816 817 true 818 819 ids-service 820 821 822 823 true 824 825 826 ips-service 827 828 829 830 831 832 833 834 835 836 1000 837 5000 838 839 840 841 1000 842 5000 843 844 845 1000 846 5000 847 848 849 850 851 852 10.0.0.1 853 145 855 856 857 858 859 861 Figure 16: Registration Interface example 863 7. Security Considerations 865 This document introduces no additional security threats and SHOULD 866 follow the security requirements as stated in [RFC8329]. 868 8. Acknowledgments 870 This work was supported by Institute for Information & communications 871 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 872 (No.R-20160222-002755, Cloud based Security Intelligence Technology 873 Development for the Customized Security Service Provisioning). 875 9. References 877 9.1. Normative References 879 [RFC2119] Bradner, S., "Key words for use in RFCs toIndicate 880 Requirement Levels", RFC 2119, March 1997. 882 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 883 Network Configuration Protocol (NETCONF)", RFC 6020, 884 October 2010. 886 9.2. Informative References 888 [capability-im] 889 Xia, L., Strassner, J., Basile, C., and D. Lopez, 890 "Information Model of NSFs Capabilities", draft-i2nsf- 891 capability-02 (work in progress), July 2018. 893 [draft-ietf-nvo3-vxlan-gpe] 894 Maino, Ed., F., Kreeger, Ed., L., and U. Elzur, Ed., 895 "Generic Protocol Extension for VXLAN", draft-ietf-nvo3- 896 vxlan-gpe-06 (work in progress), April 2018. 898 [i2nsf-capability-dm] 899 Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin, 900 "I2NSF Capability YANG Data Model", draft-ietf-i2nsf- 901 capability-data-model-01 (work in progress), July 2018. 903 [i2nsf-terminology] 904 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 905 Birkholz, "Interface to Network Security Functions (I2NSF) 906 Terminology", draft-ietf-i2nsf-terminology-06 (work in 907 progress), July 2018. 909 [i2rs-rib-data-model] 910 Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 911 S., and N. Bahadur, "A YANG Data Model for Routing 912 Information Base (RIB)", draft-ietf-i2rs-rib-data-model-15 913 (work in progress), May 2018. 915 [netmod-acl-model] 916 Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, 917 "Network Access Control List (ACL) YANG Data Model", 918 draft-ietf-netmod-acl-model-19 (work in progress), April 919 2018. 921 [nsf-triggered-steering] 922 Hyun, S., Jeong, J., Park, J., and S. Hares, "Service 923 Function Chaining-Enabled I2NSF Architecture", draft-hyun- 924 i2nsf-nsf-triggered-steering-06 (work in progress), July 925 2018. 927 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 928 Kumar, "Framework for Interface to Network Security 929 Functions", RFC 8329, February 2018. 931 [supa-policy-data-model] 932 Halpern, J., Strassner, J., and S. van der Meer, "Generic 933 Policy Data Model for Simplified Use of Policy 934 Abstractions (SUPA)", draft-ietf-supa-generic-policy-data- 935 model-04 (work in progress), June 2017. 937 [supa-policy-info-model] 938 Strassner, J., Halpern, J., and S. van der Meer, "Generic 939 Policy Information Model for Simplified Use of Policy 940 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 941 model-03 (work in progress), May 2017. 943 Authors' Addresses 944 Sangwon Hyun 945 Department of Computer Engineering 946 Chosun University 947 309, Pilmun-daero, Dong-gu 948 Gwangju, Jeollanam-do 61452 949 Republic of Korea 951 EMail: shyun@chosun.ac.kr 953 Jaehoon Paul Jeong 954 Department of Software 955 Sungkyunkwan University 956 2066 Seobu-Ro, Jangan-Gu 957 Suwon, Gyeonggi-Do 16419 958 Republic of Korea 960 Phone: +82 31 299 4957 961 Fax: +82 31 290 7996 962 EMail: pauljeong@skku.edu 963 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 965 Taekyun Roh 966 Electrical Computer Engineering 967 Sungkyunkwan University 968 2066 Seobu-Ro, Jangan-Gu 969 Suwon, Gyeonggi-Do 16419 970 Republic of Korea 972 Phone: +82 31 290 7222 973 Fax: +82 31 299 6673 974 EMail: tkroh0198@skku.edu 975 URI: http://imtl.skku.ac.kr/xe/index.php?mid=board_YoKq57 977 Sarang Wi 978 Electrical Computer Engineering 979 Sungkyunkwan University 980 2066 Seobu-Ro, Jangan-Gu 981 Suwon, Gyeonggi-Do 16419 982 Republic of Korea 984 Phone: +82 31 290 7222 985 Fax: +82 31 299 6673 986 EMail: dnl9795@skku.edu 987 URI: http://imtl.skku.ac.kr/xe/index.php?mid=board_YoKq57 988 Jung-Soo Park 989 Electronics and Telecommunications Research Institute 990 218 Gajeong-Ro, Yuseong-Gu 991 Daejeon 305-700 992 Republic of Korea 994 Phone: +82 42 860 6514 995 EMail: pjs@etri.re.kr