idnits 2.17.1 draft-hyun-i2nsf-registration-interface-im-05.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 2, 2018) is 2122 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 277, but not defined Summary: 1 error (**), 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 3, 2019 T. Roh 6 S. Wi 7 Sungkyunkwan University 8 J. Park 9 ETRI 10 July 2, 2018 12 Registration Interface Information Model 13 draft-hyun-i2nsf-registration-interface-im-05 15 Abstract 17 This document describes an information model for Interface to Network 18 Security Functions (I2NSF) Registration Interface between Security 19 Controller and Developer's Management System (DMS). The information 20 model is required to support NSF instance via the registration 21 interface. This document explains the procedures over I2NSF 22 registration interface for these functionalities. It also describes 23 the detailed information which should be exchanged via I2NSF 24 registration interface. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 3, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 4 65 5.1. NSF Instance Managment Mechanism . . . . . . . . . . . . 5 66 5.2. NSF Registration Mechanism . . . . . . . . . . . . . . . 6 67 5.3. NSF Access Information . . . . . . . . . . . . . . . . . 6 68 5.4. NSF Capability Information (Capabilities of an NSF 69 instance) . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5.4.1. Performance Capabilities . . . . . . . . . . . . . . 7 71 5.5. Role-based Access Control List . . . . . . . . . . . . . 8 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 8.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Appendix A. Lifecycle Managmenet Mechanism . . . . . . . . . . . 12 78 Appendix B. Changes from draft-hyun-i2nsf-registration- 79 interface-im-04 . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 A number of virtual network security function instances typically 85 exist in Interface to Network Security Functions (I2NSF) framework 86 [RFC8329]. Since these NSF instances may have different security 87 capabilities, it is important to register the security capabilities 88 of each NSF instance into the security controller after they have 89 been created. In addition, it is required to instantiate NSFs of 90 some required security capabilities on demand. As an example, if 91 additional security capabilities are required to meet the new 92 security requirements that an I2NSF user requests, the security 93 controller should be able to request the DMS to instantiate NSFs that 94 have the required security capabilities. 96 This document describes the information model which is required for 97 the registration interface between security controller and 98 developer's management system to support registration and 99 instantiation of NSFs. It further describes the procedure based on 100 the information model which should be performed by the security 101 controller and the developer's management system via the registration 102 interface. 104 2. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Terminology 112 This document uses the terminology described in 113 [i2nsf-terminology][capability-im][RFC8329] [nsf-triggered-steering]. 115 o Network Security Function (NSF): A function that is responsible 116 for specific treatment of received packets. A Network Security 117 Function can act at various layers of a protocol stack (e.g., at 118 the network layer or other OSI layers). Sample Network Security 119 Service Functions are as follows: Firewall, Intrusion Prevention/ 120 Detection System (IPS/IDS), Deep Packet Inspection (DPI), 121 Application Visibility and Control (AVC), network virus and 122 malware scanning, sandbox, Data Loss Prevention (DLP), Distributed 123 Denial of Service (DDoS) mitigation and TLS proxy 124 [nsf-triggered-steering]. 126 o Advanced Inspection/Action: As like the I2NSF information model 127 for NSF-facing interface [capability-im], Advanced Inspection/ 128 Action means that a security function calls another security 129 function for further inspection based on its own inspection result 130 [nsf-triggered-steering]. 132 o Network Security Function Profile (NSF Profile): NSF Profile 133 specifies the security and performance capability of an NSF 134 instance. Each NSF instance has its own NSF Profile which 135 describes the type of security service it can provide and its 136 performance capabilinty. [nsf-triggered-steering]. 138 4. Objectives 140 o Registering NSF instances from Developer's Management System: 141 Depending on system's security requirements, it may require some 142 NSFs by default. In this case, DMS creates these default NSF 143 instances without the need of receiving requests from Security 144 Controller. After creating them, DMS notifies Security Controller 145 of those NSF instances via registration interface. 147 o Creating an NSF instance to serve another NSF's inspection 148 request: In I2NSF framework, an NSF can trigger another type of 149 NSF(s) for more advanced security inspection of the traffic. In 150 this case, the next NSF is determined by the current NSF's 151 inspection result and client's policy. However, if there is no 152 available NSF instance to serve the former NSF's request, we 153 should create an NSF instance by requesting Developer's Management 154 System (DMS) through registration interface. 156 o Creating NSF instances required to enforce security policy rules 157 from Client: In I2NSF framework, users decide which security 158 service is necessary in the system. If there is no NSF instances 159 to enforce the client's security policy, then we should also 160 create the required instances by requesting DMS via registration 161 interface. 163 o Deleting unnecessary NSF instances: In I2NSF framework, users 164 decide which security service is unnecessary in the system. If 165 there is unused NSF instances to enforce the client's security 166 policy, then we should also delete the existing instances by 167 requesting DMS via registration interface. 169 o Updating an NSF instances: After NSF instance is registered in 170 I2NSF framework, capability of NSF instance can occur added and 171 changed. This situation should be recognized by the security 172 controller of the I2NSF framework. Therefore, if there is updated 173 NSF instances, DMS notifies Security Controller of those NSF 174 instances via registration interface. 176 5. Information Model 178 The I2NSF registration interface was only used for registering new 179 NSF instances to Security Controller. In this document, however, we 180 extend its utilization to support on demand NSF instantiation/de- 181 instantiation and describe the information that should be exchanged 182 via the registration interface for the functionality. Moreover, we 183 also define the information model of NSF Profile because, for 184 registration interface, NSF Profile (i.e., capabilities of an NSF) 185 needs to be clarified so that the components of I2NSF framework can 186 exchange the set of capabilities in a standardized manner. This is 187 typically done through the following process: 189 1) Security Controller first recognizes the set of capabilities 190 (i.e., NSF Profile) or the signature of a specific NSF required 191 or wasted in the current system. 193 2) Developer's Management System (DMS) matches the recognized 194 information to an NSF based on the information model definition. 196 3) Developer's Management System creates or eliminates NSFs matching 197 with the above information. 199 4) Security Controller can then add/remove the corresponding NSF 200 instance to/from its list of available NSF instances in the 201 system. 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Registration Interface Information Model | 205 | | 206 | +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | 207 | | Instance Management | | Registration | | 208 | | Sub-Model | | Sub-Model | | 209 | +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 1: Registration Interface Information Model 214 As illustrated in Figure 1, the information model for Registration 215 Interface consists of two sub-models: instance management, 216 registration sub-models. The instance management functionality and 217 the registration functionality use NSF Profile to achieve their 218 goals. In this context, NSF Profile is the capability objects that 219 describe and/or prescribe inspection capability an NSF instance can 220 provide. 222 5.1. NSF Instance Managment Mechanism 224 For the instance management of NSFs, Security Controller in I2NSF 225 framework requires two types of requests: Instantiation Request and 226 Deinstantiation Request. Security Controller sends the request 227 messages to DMS when required. Once receiving the request, DMS 228 conducts creating/eliminating the corresponding NSF instance and 229 responds Security Controller with the results. 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+ 232 | Instantiation/Re-instantiation | | De-instantiation | 233 | Request | | Request | 234 +-+-+-+-+-+-+-+-+-^-+-+-+-+-+-+-+-+ +-+-+-+-+-^-+-+-+-+-+ 235 | | 236 | | 237 | | 238 | | 239 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 240 | NSF Capability | | NSF Access | 241 | Information | | Information | 242 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 244 Figure 2: Overview of Instance Management Sub-Model 246 5.2. NSF Registration Mechanism 248 In order to register a new NSF instance, DMS should generate a 249 Registration Message to Security Controller. A Registration Message 250 consists of an NSF Profile and an NSF Access Information. The former 251 describes the inspection capability of the new NSF instance and the 252 latter is for enabling network access to the new instance from other 253 components. After this registration process, as explained in 254 [capability-im], the I2NSF capability interface can conduct 255 controlling and monitoring the new registered NSF instance. 257 +-+-+-+-+-+-+-+-+ 258 | NSF | 259 | Registration | 260 +-+-+-+-^-+-+-+-+ 261 | 262 +-------------------------------------+ 263 | | | 264 | | | 265 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 266 | NSF Capability | | NSF Access | | NSF Rold-based | 267 | Information | | Information | | ACL | 268 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 270 Figure 3: Registration Mechanism Sub-Model Overview 272 5.3. NSF Access Information 274 NSF Access Information contains the followings that are required to 275 communicate with an NSF: IPv4 address, IPv6 address, port number, and 276 supported transport protocol(s) (e.g., Virtual Extensible LAN (VXLAN) 277 [RFC 7348], Generic Protocol Extension for VXLAN (VXLAN-GPE) 279 [draft-ietf-nvo3-vxlan-gpe], Generic Route Encapsulation (GRE), 280 Ethernet etc.). In this document, NSF Access Information is used to 281 identify a specific NSF instance (i.e. NSF Access Information is the 282 signature(unique identifier) of an NSF instance in the overall 283 system). 285 5.4. NSF Capability Information (Capabilities of an NSF instance) 287 NSF Profile basically describes the inspection capabilities of an NSF 288 instance. In Figure 4, we show capability objects of an NSF 289 instance. Following the information model of NSF capabilities 290 defiend in [capability-im], we share the same security capabilities: 291 Network-Security Capabilities, Content-Security Capabilities, and 292 Attack Mitigation Capabilities. Also, NSF Profile additionally 293 contains the performance capabilities and role-Based access control 294 list (ACL) as shown in Figure 4. 296 +-+-+-+-+-+-+-+-+ 297 | Capability | 298 | Objects | 299 +-+-+-+-^-+-+-+-+ 300 | 301 | 302 +---------------+-------+--------------+ 303 | | | 304 | | | 305 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 306 |Network-Security | |Content-Security | | 307 | Capabilities | | Capabilities | | 308 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 309 | 310 +-----------------------+--------------+ 311 | | 312 | | 313 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 314 | Performance | |Attack Mitigation| 315 | Capabilities | | Capabilities | 316 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 318 Figure 4: NSF Profile Overview 320 5.4.1. Performance Capabilities 322 This information represents the processing capability of an NSF. 323 This information can be used to determine whether the NSF is in 324 congestion by comparing this with the workload that the NSF currently 325 undergoes. Moreover, this information can specify an available 326 amount of each type of resources such as processing power which are 327 available on the NSF. (The registration interface can control the 328 usages and limitations of the created instance and make the 329 appropriate request according to the status.) As illustrated in 330 Figure 5, this information consists of two items: Processing and 331 Bandwidth. Processing information describes the NSF's available 332 processing power. Bandwidth describes the information about 333 available network amount in two cases, outbound, inbound. This two 334 information can be used for the NSF's instance request. 336 +-+-+-+-+-+-+-+-+-+ 337 | Performance | 338 | Capabilities | 339 +-+-+-+-^-+-+-+-+-+ 340 | 341 +----------------------------+ 342 | | 343 | | 344 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 345 | Processing | | Bandwidth | 346 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 348 Figure 5: Performance Capability Overview 350 5.5. Role-based Access Control List 352 This information specifies access policies of an NSF to determine 353 whether to permit or deny the access of an entity to the NSF based on 354 the role given to the entity. Each NSF is associated with a role- 355 based access control list (ACL) so that it can determine whether to 356 permit or deny the access request from an entity. Figure 6 and 357 Figure 7 show the structure of the role-based ACL, which is composed 358 of role-id, access-type, and permit/deny. The role-id identifies 359 roles of entities (e.g., administrator, developer etc.). The access- 360 type identifies the specific type of access requests such as NSF rule 361 configuration/update and NSF monitoring. Consequently, the role- 362 based ACL in Figure 6 and Figure 7 specifies a set of access-types to 363 be permitted and to be denied by each role-id. 365 +-+-+-+-+-+-+-+-+ 366 | Role-based | 367 | ACL | 368 +-+-+-+-+-+-+-+-+ 369 | 370 +-----------------------------------+ 371 | | 372 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 373 | Role-id 1 | ... | Role-id N | 374 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 376 Figure 6: Role-based Access Control List 378 +-+-+-+-+-+-+-+-+ 379 | Role-id i | 380 +-+-+-+-+-+-+-+-+ 381 | 382 +---------------------------------+ 383 | | 384 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 385 | Permit | | Deny | 386 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 387 | | 388 +------------------+ +------------------+ 389 | | | | 390 +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ 391 |access-type| ... |access-type| |access-type| ... |access-type| 392 | p1 | | pn | | d1 | | dn | 393 +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ 395 Figure 7: Role-id Subtree 397 6. Security Considerations 399 The information model of the registration interface is based on the 400 I2NSF framework without any architectural changes. Thus, this 401 document shares the security considerations of the I2NSF framwork 402 that are specified in [RFC8329] for the purpose of achieving secure 403 communication between components in the proposed architecture. 405 7. Acknowledgments 407 This work was supported by Institute for Information & communications 408 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 409 (No.R-20160222-002755, Cloud based Security Intelligence Technology 410 Development for the Customized Security Service Provisioning). 412 This document has greatly benefited from inputs by SangUk Woo and 413 YunSuk Yeo. 415 8. References 417 8.1. Normative References 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, March 1997. 422 8.2. Informative References 424 [capability-im] 425 Xia, L., Strassner, J., Basile, C., and D. Lopez, 426 "Information Model of NSFs Capabilities", draft-ietf- 427 i2nsf-capability-01 (work in progress), April 2018. 429 [draft-ietf-nvo3-vxlan-gpe] 430 Maino, Ed., F., Kreeger, Ed., L., and U. Elzur, Ed., 431 "Generic Protocol Extension for VXLAN", draft-ietf-nvo3- 432 vxlan-gpe-06 (work in progress), April 2018. 434 [i2nsf-nsf-monitoring] 435 Hong, D., Jeong, J., Kim, J., Hares, S., Xia, L., and H. 436 Birkholz, "YANG Data Model for Monitoring I2NSF Network 437 Security Functions", draft-hong-i2nsf-nsf-monitoring-data- 438 model-03 (work in progress), March 2018. 440 [i2nsf-terminology] 441 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 442 Birkholz, "Interface to Network Security Functions (I2NSF) 443 Terminology", draft-ietf-i2nsf-terminology-05 (work in 444 progress), January 2018. 446 [nfv-architecture] 447 Yang, Hyunsik. and Younghan. Kim, "I2NSF on the NFV 448 Reference Architecture", draft-yang-i2nsf-nfv- 449 architecture-01 (work in progress), March 2018. 451 [nfv-framework] 452 "Network Functions Virtualisation (NFV); Architectureal 453 Framework", ETSI GS NFV 002 ETSI GS NFV 002 V1.1.1, 454 October 2013. 456 [nsf-triggered-steering] 457 Hyun, S., Jeong, J., Park, J., and S. Hares, "Service 458 Function Chaining-Enabled I2NSF Architecture", draft-hyun- 459 i2nsf-nsf-triggered-steering-05 (work in progress), March 460 2018. 462 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 463 Kumar, "Framework for Interface to Network Security 464 Functions", RFC 8329, February 2018. 466 Appendix A. Lifecycle Managmenet Mechanism 468 NFV can be used to virtualize NSFs in I2NSF systems, and DMSs likely 469 perform life-cycle management of NSF instances via Ve-Vnfm interface 470 [nfv-framework] in this environment. The security controller 471 periodically gathers information of NSF instances via the monitoring 472 interface [i2nsf-nsf-monitoring]. This information can be 473 additionally used for life-cycle management of NSF instances, and so 474 the security controller can deliver the information to the DMSs via 475 the registration interface. 477 Appendix B. Changes from draft-hyun-i2nsf-registration-interface-im-04 479 The following changes are made from draft-hyun-i2nsf-registration- 480 interface-im-04: 482 o Section 4 has been revised to discuss about updating an modified 483 NSF instance via registration interface. 485 o Figures 2, 3 and 4 have been updated. 487 o Appendix A has been added to discuss about the use of the 488 registration interface related to lifecycle management. 490 o The references have been updated to reflect the latest documents. 492 Authors' Addresses 494 Sangwon Hyun 495 Department of Computer Engineering 496 Chosun University 497 309, Pilmun-daero, Dong-gu 498 Gwangju, Jeollanam-do 61452 499 Republic of Korea 501 EMail: shyun@chosun.ac.kr 502 Jaehoon Paul Jeong 503 Department of Software 504 Sungkyunkwan University 505 2066 Seobu-Ro, Jangan-Gu 506 Suwon, Gyeonggi-Do 16419 507 Republic of Korea 509 Phone: +82 31 299 4957 510 Fax: +82 31 290 7996 511 EMail: pauljeong@skku.edu 512 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 514 TaeKyun Roh 515 Department of Software 516 Sungkyunkwan University 517 2066 Seobu-Ro, Jangan-Gu 518 Suwon, Gyeonggi-Do 16419 519 Republic of Korea 521 Phone: +82 31 290 7222 522 Fax: +82 31 299 6673 523 EMail: tkroh0198@skku.edu 524 URI: http://imtl.skku.ac.kr/xe/index.php?mid=board_YoKq57 526 SaRang Wi 527 Department of Software 528 Sungkyunkwan University 529 2066 Seobu-Ro, Jangan-Gu 530 Suwon, Gyeonggi-Do 16419 531 Republic of Korea 533 Phone: +82 31 290 7222 534 Fax: +82 31 299 6673 535 EMail: dnl9795@skku.edu 536 URI: http://imtl.skku.ac.kr/xe/index.php?mid=board_YoKq57 538 Jung-Soo Park 539 Electronics and Telecommunications Research Institute 540 218 Gajeong-Ro, Yuseong-Gu 541 Daejeon 305-700 542 Republic of Korea 544 Phone: +82 42 860 6514 545 EMail: pjs@etri.re.kr