idnits 2.17.1 draft-hyun-i2nsf-registration-interface-im-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.) 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 (October 31, 2016) is 2732 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 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 S. Woo 4 Intended status: Standards Track Y. Yeo 5 Expires: May 4, 2017 J. Jeong 6 Sungkyunkwan University 7 J. Park 8 ETRI 9 October 31, 2016 11 Registration Interface Information Model 12 draft-hyun-i2nsf-registration-interface-im-00 14 Abstract 16 This document describes an information model for Interface to Network 17 Security Functions (I2NSF) Registration Interface between Security 18 Controller and Developer's Management System. The information model 19 is required for Network Security Function (NSF) instance registration 20 and dynamic life cycle management of NSF instances. This document 21 explains the procedures over I2NSF registration interface for these 22 functionalities. It also describes the detailed information which 23 should be exchanged via I2NSF registration interface. 25 Status of This Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on May 4, 2017. 48 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 5 69 5.1. Life-Cycle Managment Mechanism . . . . . . . . . . . . . . 6 70 5.2. Registration Mechanism . . . . . . . . . . . . . . . . . . 6 71 5.3. NSF Access Information . . . . . . . . . . . . . . . . . . 7 72 5.4. NSF Profile (Capabilities of an NSF instance) . . . . . . 7 73 5.4.1. Packet Content-Matching Capability . . . . . . . . . . 8 74 5.4.2. Content-Matching Capability . . . . . . . . . . . . . 8 75 5.4.3. Context-Matching Capability . . . . . . . . . . . . . 8 76 5.4.4. Attack-Mitigation Capability . . . . . . . . . . . . . 9 77 5.4.5. Action Capability . . . . . . . . . . . . . . . . . . 9 78 5.4.6. Performance Capability . . . . . . . . . . . . . . . . 9 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 A number of virtual network security function instances typically 88 exist in Interface to Network Security Functions (I2NSF) framework 89 [i2nsf-framework]. In this environment, it is important to 90 dynamically manage a Network Security Function (NSF) instance pool 91 for efficient resource utilization. For instance, if a certain NSF 92 instance is receiving an excessive amount of traffic beyond its 93 capacity, an additional instance for the same security function 94 should be created. If an NSF instance is idle for a period of time, 95 it would be better to destroy it to avoid resource waste. In 96 addition, the existing information model for NSF facing interface 97 requires an NSF to trigger another type of NSF for further inspection 98 [capability-interface-im]. In this case, if there is no available 99 instance for the latter NSF, a new NSF should be instantiated. 100 Similarly, in order to enforce a security policy from the client, all 101 the required NSF instances should be created. 103 This document describes the procedures which should be performed on 104 the registration interface between security controller and 105 developer's management system to dynamically manage a pool of NSF 106 instances. It further describes the detailed information which 107 should be exchanged between security controller and developer's 108 management system. 110 2. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Terminology 118 This document uses the terminology described in 119 [i2nsf-terminology][capability-interface-im][i2nsf-framework] 120 [nsf-triggered-steering]. 122 o Network Security Function (NSF): A function that is responsible 123 for specific treatment of received packets. A Network Security 124 Function can act at various layers of a protocol stack (e.g., at 125 the network layer or other OSI layers). Sample Network Security 126 Service Functions are as follows: Firewall, Intrusion Prevention/ 127 Detection System (IPS/IDS), Deep Packet Inspection (DPI), 128 Application Visibility and Control (AVC), network virus and 129 malware scanning, sandbox, Data Loss Prevention (DLP), Distributed 130 Denial of Service (DDoS) mitigation and TLS proxy 131 [nsf-triggered-steering]. 133 o Advanced Inspection/Action: As like the I2NSF information model 134 for NSF facing interface [capability-interface-im], Advanced 135 Inspection/Action means that a security function calls another 136 security function for further inspection based on its own 137 inspection result [nsf-triggered-steering]. 139 o Network Security Function Profile (NSF Profile): NSF Profile 140 specifies the inspection capabilities of the associated NSF 141 instance. Each NSF instance has its own NSF Profile to specify 142 the type of security service and its resource capacity 143 [nsf-triggered-steering]. 145 4. Objectives 147 o Efficient network resource utilization through dynamic 148 instantiation of NSFs and load balancing: In I2NSF framework, it 149 is sometimes possible that a specific NSF experiences heavy 150 traffic loads. For example, under DDoS attacks, a huge volume of 151 traffic would be driven to DoS attack mitigator function to cope 152 with the attacks. In this case, we should allocate a large 153 portion of resources to that DoS attack mitigator function by 154 creating a sufficient number of DoS mitigator instances. After 155 the attack is terminated, we should eliminate some of the 156 instances no longer used. In this way, we can achieve efficient 157 resource utilization. For this purpose, it is indispensable to 158 define an information model of registration interface for dynamic 159 instantiation/elimination of NSF instances. 161 o Creating an NSF instance to serve another NSF's inspection 162 request: In I2NSF framework, an NSF triggers another type of 163 NSF(s) when the traffic requires further security inspection. The 164 following NSF is determined by previous NSF's inspection result 165 and client's policy. However, if there is no available instance 166 of the latter NSF required by the former NSF, we should be able to 167 create an NSF instance via Developer's Management System (DMS) and 168 registration interface. 170 o Creating NSF instances required to enforce security policy rules 171 from Client: In I2NSF framework, client decides which security 172 service is necessary in the system. If there is no NSF instances 173 to fully support the client's security requirements, then we 174 should also create the required instances by requesting DMS via 175 registration interface. 177 o Registering NSF instances by Developer's Management System: 178 Depending on system's security requirements, it may require some 179 NSFs by default. In this case, DMS creates these default NSF 180 instances without the need of receiving requests from Security 181 Controller. DMS then notifies Security Controller of those NSF 182 instances via registration interface. 184 5. Information Model 186 The I2NSF registration interface was only used for registering new 187 NSF instances to Security Controller. In this document, however, we 188 extend its utilization to support dynamic NSF life cycle management 189 and describe the information that should be exchanged via the 190 registration interface for the functionality . Moreover, we also 191 define the information model of NSF Profile because, for registration 192 interface, NSF Profile (i.e., capabilities of an NSF) needs to be 193 clarified so that the components of I2NSF framework can exchange the 194 set of capabilities in a standardized manner. This is typically done 195 through the following process:: 197 1) Security Controller first recognizes the set of capabilities 198 (i.e., NSF Profile) or the signature of a specific NSF required 199 or wasted in the current system. 201 2) Developer's Management System (DMS) matches the recognized 202 information to an NSF based on the information model definition. 204 3) Developer's Management System creates or eliminates NSFs matching 205 with the above information. 207 4) Security Controller can then add/remove the corresponding NSF 208 instance to/from its list of available NSF instances in the 209 system. 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Registration Interface Model Design | 213 | | 214 | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | 215 | |Life-Cycle Management| | Registration | | 216 | | Sub-Model | | Sub-Model | | 217 | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 1: The Registration Interface Model Design 222 As illustrated in Figure 1, the information model for Registration 223 Interface consists of two sub-models: life-cycle management, 224 registration sub-models. The life-cycle management functionality and 225 the registration functionality use NSF Profile to achieve their 226 goals. In this context, NSF Profile is the capability objects that 227 describe and/or prescribe inspection capability an NSF instance can 228 provide. 230 5.1. Life-Cycle Managment Mechanism 232 For the life-cycle management of NSFs, Security Controller in I2NSF 233 framework requires two types of requests: Instance Creation and 234 Elimination Request Messages. Security Controller sends the request 235 messages to DMS when required. Once receiving the request, DMS 236 conducts creating/eliminating the corresponding NSF instance and 237 responds Security Controller with the results. There are several 238 cases requiring creation of a new NSF instance which provides 239 specific security inspection functionalities and elimination of an 240 existing NSF which is unused for a period of time. For example, 242 1) When an NSF triggers an advanced inspection of the suspicious 243 traffic via another type of NSF whose instance is currently 244 unavailable in the system. 246 2) When an NSF instance undergoes an excessive amount of traffic 248 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 249 |Instance Creation| | Instance Elimination | 250 | Request Message | | Request Message | 251 +-+-+-+-^-+-+-+-+-+ +-+-+-+-+-+^+-+-+-+-+-+-+ 252 | | 253 | | 254 | | 255 | | 256 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 257 | NSF Profile | | NSF Access | 258 +-+-+-+-+-+-+-+-+ | Information | 259 +-+-+-+-+-+-+-+-+ 261 Figure 2: Life-Cycle Management Sub-Model Overview 263 5.2. Registration Mechanism 265 In order to register a new NSF instance, DMS should generate a 266 Registration Message to Security Controller. A Registration Message 267 consists of an NSF Profile and an NSF Access Information. The former 268 describes the inspection capability of the new NSF instance and the 269 latter is for enabling network access to the new instance from other 270 components. After this registration process, as explained in 271 [capability-interface-im], the I2NSF capability interface can conduct 272 controlling and monitoring the new registered NSF instance. 274 +-+-+-+-+-+-+-+-+ 275 | Registration | 276 | Message | 277 +-+-+-+-^-+-+-+-+ 278 | 279 +-----------------------------+ 280 | | 281 | | 282 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 283 | NSF Profile | | NSF Access | 284 | | | Information | 285 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 287 Figure 3: Registration Mechanism Sub-Model Overview 289 5.3. NSF Access Information 291 NSF Access Information can contain IPv4 Address, IPv6 Address, 292 Transport Protocol, Port Number etc. In this document, NSF Access 293 Information is used to identify a specific NSF instance (i.e. NSF 294 Access Information is the signature of an NSF instance in the overall 295 system). 297 5.4. NSF Profile (Capabilities of an NSF instance) 299 NSF Profile basically refers the inspection capabilities of an NSF 300 instance. As illustrated in Figure 4, it can be split into five 301 capabilities (Content-Matching, Context-Matching, Attack-Mitigation, 302 Action, Performance Capabilities). We share security capabilities 303 which are defined in Section 3 (Overall Analysis of Security 304 Capability) in [capability-interface-im] for the first five 305 capabilities and append one additional capability. 307 +-+-+-+-+-+-+-+-+ 308 | Capability | 309 | Objects | 310 +-+-+-+-^-+-+-+-+ 311 | 312 +--------------------+--------------------+-----------+ 313 | | | | 314 | | | | 315 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 316 |Content-Matching | |Content-Matching | |Context-Matching | | 317 | (Packet) | | Capability | | Capability | | 318 | Capability | | | | | | 319 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 320 | 321 +--------------------+--------------------+-----------+ 322 | | | 323 | | | 324 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 325 |Attack Mitigation| | Action | | Performance | 326 | Capability | | Capability | | Capability | 327 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 329 Figure 4: NSF Profile Overview 331 5.4.1. Packet Content-Matching Capability 333 Refer to the kind of information or attributes acquired directly from 334 the packet headers or payloads that can be used in the security 335 policy. It can be any fields or attributes in the packet L2/L3/L4 336 header, or special segment of bytes in the packet payload. 337 [capability-interface-im] 339 5.4.2. Content-Matching Capability 341 Content security is another category of security capabilities applied 342 to application layer. Through detecting the contents carried over 343 the traffic in application layer, these capabilities can realize 344 various security functions, such as defending against intrusion, 345 inspecting virus, filtering malicious URL or junk email, blocking 346 illegal web access or malicious data retrieval. 347 [capability-interface-im] 349 5.4.3. Context-Matching Capability 351 This capability refers to the content information for the received 352 packets. It can be User, Schedule, Region, Target, State and 353 Direction information. [capability-interface-im] 355 5.4.4. Attack-Mitigation Capability 357 This category of security capabilities is used to detect and mitigate 358 various types of network attacks. Today's common network attacks can 359 be classified into the following sets, and each set further consists 360 of a number of specific attacks: [capability-interface-im] 362 o DDoS attacks: 364 * Network layer DDoS attacks: Examples include SYN flood, UDP 365 flood, ICMP flood, IP fragment flood, IPv6 Routing header 366 attack, and IPv6 duplicate address detection attack; 368 * Application layer DDoS attacks: Examples include http flood, 369 https flood, cache-bypass http floods, WordPress XML RPC 370 floods, ssl DDoS. 372 o Single-packet attack: 374 * Scanning and sniffing attacks: IP sweep, port scanning, etc 376 * Malformed packet attacks: Ping of Death, Teardrop, etc 378 * Special packet attacks: Oversized ICMP, Tracert, IP timestamp 379 option packets, etc 381 5.4.5. Action Capability 383 NSFs provide security functions by executing various Actions, which 384 at least includes: [capability-interface-im] 386 o Ingress actions, such as pass, drop, mirroring, etc; 388 o Egress actions, such as invoke signaling, tunnel encapsulation, 389 packet forwarding and/or transformation; 391 o Applying a specific Functional Profile or signature (NSF Profile) 392 - The functional profile or signature file defines the security 393 capabilities for content security control and/or attack mitigation 394 control. One goal of I2NSF is to standardize the form and 395 functional interface of those security capabilities while 396 supporting vendor-specific implementations of each. 398 5.4.6. Performance Capability 400 This capability represents hardware capacity information such as the 401 amount of traffic it can process per second. In addition, this 402 information can specify an available amount of each type of resources 403 such as processing power and memory etc. an NSF instance has. 405 6. Security Considerations 407 The information model of the registration interface is based on the 408 I2NSF framework without any architectural changes. Thus, this 409 document shares the security considerations of the I2NSF framwork 410 architecture that are specified in [i2nsf-framework] for the purpose 411 of achieving secure communication among components in the proposed 412 architecture. 414 7. Acknowledgements 416 This work was supported by Institute for Information & communications 417 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 418 (No.R-20160222-002755, Cloud based Security Intelligence Technology 419 Development for the Customized Security Service Provisioning). 421 8. References 423 8.1. Normative References 425 [RFC2119] Bradner, S., "Key words for use in RFCs to 426 Indicate Requirement Levels", BCP 14, 427 RFC 2119, March 1997. 429 8.2. Informative References 431 [capability-interface-im] Xia, L., Zhang, D., Lopez, E., Bouthors, 432 N., and L. Fang, "Information Model of 433 Interface to Network Security Functions 434 Capability Interface", 435 draft-xia-i2nsf-capability-interface-im-06 436 (work in progress), July 2016. 438 [i2nsf-framework] Lopez, E., Lopez, D., Dunbar, L., 439 Strassner, J., Zhuang, X., Parrott, J., 440 Krishnan, R., Durbha, S., Kumar, R., and 441 A. Lohiya, "Framework for Interface to 442 Network Security Functions", 443 draft-ietf-i2nsf-framework-03 (work in 444 progress), October 2016. 446 [i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, 447 L., and H. Birkholz, "Interface to Network 448 Security Functions (I2NSF) Terminology", 449 draft-ietf-i2nsf-terminology-01 (work in 450 progress), October 2016. 452 [nsf-triggered-steering] Hyun, S., Woo, S., Yeo, Y., Jeong, J., and 453 J. Park, "NSF-Triggered Traffic Steering", 454 draft-hyun-i2nsf-nsf-triggered-steering- 455 in-i2nsf-00 (work in progress). 457 Authors' Addresses 459 Sangwon Hyun 460 Department of Software 461 Sungkyunkwan University 462 2066 Seobu-Ro, Jangan-Gu 463 Suwon, Gyeonggi-Do 16419 464 Republic of Korea 466 Phone: +82 31 290 7222 467 Fax: +82 31 299 6673 468 EMail: swhyun77@skku.edu 469 URI: http://imtl.skku.ac.kr/ 471 SangUk Woo 472 Department of Software 473 Sungkyunkwan University 474 2066 Seobu-Ro, Jangan-Gu 475 Suwon, Gyeonggi-Do 16419 476 Republic of Korea 478 Phone: +82 31 290 7222 479 Fax: +82 31 299 6673 480 EMail: suwoo@imtl.skku.ac.kr, 481 URI: http://imtl.skku.ac.kr/index.php?mid=member_student 483 YunSuk Yeo 484 Department of Software 485 Sungkyunkwan University 486 2066 Seobu-Ro, Jangan-Gu 487 Suwon, Gyeonggi-Do 16419 488 Republic of Korea 490 Phone: +82 31 290 7222 491 Fax: +82 31 299 6673 492 EMail: yunsuk@imtl.skku.ac.kr, 493 URI: http://imtl.skku.ac.kr/index.php?mid=member_student 494 Jaehoon Paul Jeong 495 Department of Software 496 Sungkyunkwan University 497 2066 Seobu-Ro, Jangan-Gu 498 Suwon, Gyeonggi-Do 16419 499 Republic of Korea 501 Phone: +82 31 299 4957 502 Fax: +82 31 290 7996 503 EMail: pauljeong@skku.edu 504 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 506 Jung-Soo Park 507 Electronics and Telecommunications Research Institute 508 218 Gajeong-Ro, Yuseong-Gu 509 Daejeon 305-700 510 Republic of Korea 512 Phone: +82 42 860 6514 513 EMail: pjs@etri.re.kr