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