idnits 2.17.1 draft-kim-i2nsf-security-management-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 4, 2016) is 2852 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 H. Kim 3 Internet-Draft H. Ko 4 Intended status: Standards Track S. Oh 5 Expires: January 5, 2017 J. Jeong 6 Sungkyunkwan University 7 S. Lee 8 Korea Telecom 9 July 4, 2016 11 An Architecture for Security Management in I2NSF Framework 12 draft-kim-i2nsf-security-management-architecture-01 14 Abstract 16 This document describes an architecture for security management in 17 the Interface to Network Security Functions (I2NSF) framework. This 18 security management architecture consists of I2NSF Client, Security 19 Management System (i.e., Security Controller and Developer's 20 Management System), and Network Security Functions (NSFs) in the 21 I2NSF framework. I2NSF Client consists of Application Logic, Policy 22 Updater, and Policy Collector. Security Controller consists of 23 Security Policy Manager and NSF Capability Manager. This document 24 explains their missions and the processing of security management in 25 a high level. It also describes representative use cases, such as 26 security management for the list of malware domains and security 27 management for VoIP-VoLTE. 29 Status of This Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on January 5, 2017. 52 Copyright Notice 54 Copyright (c) 2016 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4 72 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 5. Architecture of Security Management . . . . . . . . . . . . . . 4 74 5.1. Security Policy Manager . . . . . . . . . . . . . . . . . . 5 75 5.2. NSF Capability Manager . . . . . . . . . . . . . . . . . . 6 76 5.3. Developer's Management System . . . . . . . . . . . . . . . 6 77 5.4. Application Logic . . . . . . . . . . . . . . . . . . . . . 6 78 5.5. Policy Updater . . . . . . . . . . . . . . . . . . . . . . 6 79 5.6. Policy Collector . . . . . . . . . . . . . . . . . . . . . 6 80 6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 6.1. Security Management for the List of Malware Domains . . . . 7 82 6.2. Security Management for VoIP-VoLTE . . . . . . . . . . . . 8 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 89 1. Introduction 91 To enforce a user's high-level security policy into the I2NSF 92 framework [i2nsf-framework], I2NSF Client delivers such a policy to 93 Security Controller via Client Facing Interface. In this document, 94 an architecture for security management is proposed for a given high- 95 level policy in the I2NSF framework. This architecture contains 96 I2NSF Client, Security Management System (i.e., Security Controller 97 and Developer's Management System), and NSFs in the I2NSF framework. 98 I2NSF Client includes Application Logic, Policy Updater, and Policy 99 Collector. Security Controller contains Security Policy Manager and 100 NSF Capability Manager. 102 Security Policy Manager and NSF Capability Manager in Security 103 Controller are responsible for controlling the updated security 104 policy which will be given by Policy Updater in I2NSF Client via 105 Client Facing Interface. Policy Updater delivers new or updated 106 policies to Security Controller. On the other hand, when an event 107 occurs for NSF to change a low-level policy, Policy Collector 108 receives the correspondingly updated high-level policy via Security 109 Controller. Next, it also updates accordingly the current policies 110 in Application Logic. 112 In this document, we propose a security management architecture that 113 integrates additional components for security management into the 114 I2NSF framework. Our architecture is designed to support flexible 115 and effective security policies. Application Logic generates the 116 high-level policy and Policy Updater sends it to Security Policy 117 Manager via Client Facing Interface. Security Policy Manager maps 118 the high-level policy into several low-level policies in Security 119 Controller. After mapping into those policies, Security Policy 120 Manager sends them to NSF(s) so that they can be enforced into the 121 NSF(s). 123 2. Objectives 125 This document has two main objectives for security management 126 architecture as follows. 128 o High-level security management: To propose the design of a generic 129 security management architecture to support the enforcement of 130 flexible and effective security policies in NSFs. 132 o Automatic update of security policies: To provide the reflection 133 of the updated low-level security policies for new security 134 attacks on the corresponding high-level security policies. 136 3. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 4. Terminology 144 This document uses the terminology described in [i2nsf-framework]. 145 In addition, the following terms are defined below: 147 o Application Logic: It is a component in the security management 148 architecture which generates high-level security policies to block 149 or mitigate security attacks. 151 o Policy Updater: It is a component which forwards a high-level 152 security policy, which is received from Application Logic, to 153 Security Controller. 155 o Security Policy Manager: It maps a high-level security policy 156 received from Policy Updater into low-level security policies, and 157 vice verse. 159 o NSF Capability Manager: It is a component which stores the NSF 160 capability registered by Developer's Management System via 161 Registration Interface and shares it to Security Policy Manger to 162 generate the corresponding low-level security policies. 164 o Policy Collector: It is a component that forwards the updated 165 high-level security policy to Application Logic. 167 5. Architecture of Security Management 169 This section describes a security management architecture in I2NSF 170 and focuses on Security Management System having Security Controller 171 and Developer's Management System. It also explains basic operations 172 of Security Controller. In addition, it describes the details about 173 each component of the architecture. 175 Figure 1 shows a security management architecture in the I2NSF 176 framework. The architecture is designed to support the enforcement 177 of flexible and effective security policies. Application Logic in 178 I2NSF Client generates a high-level policy in accordance with new 179 security attacks and then Policy Updater in I2NSF Client sends such a 180 policy to Security Policy Manager in Security Controller. Security 181 Policy Manager maps the high-level policy into several low-level 182 policies relevant to NSF capability registered into NSF Capability 183 Manager. After such a mapping into low-level policies, Security 184 Policy Manager delivers those policies to NSF through NSF Facing 185 Interface. In following sections, we explain the details of each 186 component. 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | I2NSF Client | 190 | +-+-+-+-+-+-+-+-+-+-+-+ | 191 | -->| Application Logic |<-- | 192 | | +-+-+-+-+-+-+-+-+-+-+-+ | | 193 | | | | 194 | | | | 195 | +-+-+-+v+-+-+-+-+-+ +-+-+-+v+-+-+-+ | 196 | | Policy Updater | | Policy | | 197 | +-+-+-+-+-+-+-+-+-+ | Collector | | 198 | | +-+-+-+^+-+-+-+ | 199 | | | | 200 | | | | 201 | | ------------------- | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | | Client Facing Interface 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 |Security Management System| | | 206 | +-+-+-+-+-+-+-+-+-+v+-+-+-+-+ | 207 | |Security Controller | | 208 | | +-+-+-+-+-+ +-+-+-+-+-+-+ | Registration | 209 | | |Security | |NSF | | Interface +-+-+-+-+-+-+-+ | 210 | | |Policy | |Capability | |<----------->| Developer's | | 211 | | |Manager | |Manager | | | Mgnt System | | 212 | | +-+-+-+-+-+ +-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ | 213 | +-+-+-+-+-+-^-+-+-+-+-+-+-+-+ | 214 +-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | NSF Facing Interface 216 +-+-+v+-+-+ 217 | NSF | 218 +-+-+-+-+-+ 220 Figure 1: Security Management Architecture in I2NSF 222 5.1. Security Policy Manager 224 Security Policy Manager is a component which receives a high-level 225 policy from Policy Updater via Client Facing Interface, and maps the 226 high-level policy into several low-level policies relevant to a given 227 NSF capability from NSF Capability Manager. Moreover, Security 228 Policy Manager delivers those policies to NSF(s) via NSF Facing 229 Interface. 231 On the other hand, when an event that needs to change the low-level 232 policy happens in NSF, NSF sends the changed low-level policy to 233 Security Policy Manager via NSF Facing Interface. Security Policy 234 Manager maps such changed low-level policy into the high-level policy 235 and sends it to Policy Collector via Client Facing Interface. 237 5.2. NSF Capability Manager 239 NSF Capability Manager is a component integrated into Security 240 Controller. It stores the NSF capability registered by Developer's 241 Management System via Registration Interface and shares it to 242 Security Policy Manager so that Security Policy Manager can generate 243 low-level policies relevant to a given NSF capability. Moreover, 244 whenever a new NSF is registered, NSF Capability Manager requests 245 Developer's Management System to register the NSF capability into the 246 management table of NSF Capability Manager via Registration 247 Interface. On the other hand, when the existing NSF is deleted, NSF 248 Capability Manager eliminates the NSF capability from its management 249 table. 251 5.3. Developer's Management System 253 Developer's Management System is a component which registers a new 254 NSF's capability to NSF Capability Manager via Registration 255 Interface. Moreover, in the case where there is some update in the 256 registered NSF, such an update will be delivered from Developer's 257 Management System to NSF Capability Manager. 259 5.4. Application Logic 261 Application Logic is a component which generates a high-level 262 security policy to block or mitigate security attacks. It sends the 263 generated policies to Policy Updater. However, this component is out 264 of our standardization scope. We explain its detailed operations in 265 two use cases in Section 6. 267 5.5. Policy Updater 269 Policy Updater is a component which receives a high-level security 270 policy generated by Application Logic and delivers it to Security 271 Policy Manager via Client Facing Interface. 273 5.6. Policy Collector 275 Policy Collector is a component which receives the updated high level 276 security policy from Security Controller via Client Facing Interface. 277 Such an update is required because the corresponding low-level 278 security policy is updated by some event that occurred in an NSF. 279 After receiving it, Policy Collector forwards it to Application Logic 280 so that Application Logic can update the corresponding high-level 281 security policy received from Security Controller. 283 6. Use Cases 285 A generic architecture is designed to react to possible security 286 attacks. This section shows the procedure of the defense for 287 security attacks in the I2NSF framework [i2nsf-framework] for a given 288 list of security attacks in malware domains and VoIP/VoLTE security 289 attacks. 291 6.1. Security Management for the List of Malware Domains 293 Malware domain blacklisting maintains and publishes the blacklists of 294 IP addresses of possible attacking hosts, servers, and networks that 295 are suspicious of malicious activities. Figure 2 shows a security 296 management architecture for Malware Domain Blacklisting. 298 Based on the malware domain blacklisting, the list of malware domains 299 can be updated either manually or automatically by Malware Domain 300 Manager in I2NSF Client. Also, Malware Domain Manager periodically 301 generates a new high-level security policy to prevent the delivery of 302 packets from/to those newly added malware domains and enforce the 303 low-level security policies in NSF. It sends the new high-level 304 security policy to Policy Updater, which forwards it to Security 305 Controller. 307 An updated low-level policy is sent by an NSF to Security Controller 308 via NSF Facing Interface so that Security Controller can generate the 309 corresponding high-level security policy. Security Controller 310 delivers the high-level security policy to Policy Collector. Policy 311 Collector forwards the policy to Malware Domain Manager as an 312 Application Logic. 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | I2NSF Client | 316 | +-+-+-+-+-+-+-+-+-+-+-+-+ | 317 | -->|Malware Domain Manager |<-- | 318 | | +-+-+-+-+-+-+-+-+-+-+-+-+ | | 319 | | | | 320 | | | | 321 | +-+-+-+v+-+-+-+-+-+ +-+-+-+-+v+-+-+ | 322 | | Policy Updater | | Policy | | 323 | +-+-+-+-+-+-+-+-+-+ | Collector | | 324 | | +-+-+-+^+-+-+-+ | 325 | | | | 326 | | | | 327 | | ------------------- | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | |Client Facing Interface 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |Security Management System| | 332 | +-+-+-+-+-+-+-+-+-+v+-+-+-+-+ | 333 | |Security Controller | | 334 | | +-+-+-+-+-+ +-+-+-+-+-+-+ | Registration | 335 | | |Security | |NSF | | Interface +-+-+-+-+-+-+-+ | 336 | | |Policy | |Capability | |<----------->| Developer's | | 337 | | |Manager | |Manager | | | Mgnt System | | 338 | | +-+-+-+-+-+ +-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ | 339 | +-+-+-+-+-+-^-+-+-+-+-+-+-+-+ | 340 +-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 |NSF Facing Interface 342 +-+-+v+-+-+ 343 | NSF | 344 +-+-+-+-+-+ 346 Figure 2: Malware Domain Blacklisting 348 6.2. Security Management for VoIP-VoLTE 350 VoIP-VoLTE security management maintains and publishes the blacklists 351 of IP addresses, source ports, expire time, user-agent, and Session 352 Initiation Protocol (SIP) URIs of SIP device that are suspicious of 353 illegal call and authentication. In our generic security management 354 architecture, VoIP-VoLTE Security Manager is Application Logic for 355 VoIP-VoLTE security services in Figure 1. 357 Based on VoIP-VoLTE security management, the list of illegal devices 358 information can be updated either manually or automatically by VoIP- 359 VoLTE Security Manager as Application Logic. Also, VoIP-VoLTE 360 Security Manager periodically generates a new high-level security 361 policy to prevent the delivery of packets from/to those newly added 362 VoIP-VoLTE attackers and enforce the low-level security policies in 363 NSF. It sends the new high-level security policy to Policy Updater, 364 which forwards it to Security Controller. 366 An updated low-level policy for VoIP-VoLTE attacks is sent by an NSF 367 to Security Controller via NSF Facing Interface so that Security 368 Controller can generate the corresponding high-level security policy, 369 such as IP addresses, user-agents, and expire time values that need 370 to be added by Security Controller. Security Controller delivers the 371 high-level security policy to Policy Collector. Policy Collector 372 forwards the policy to VoIP-VoLTE Security Manager as an Application 373 Logic. 375 7. Security Considerations 377 The security management architecture is derived from the I2NSF 378 framework [i2nsf-framework], so the security considerations of the 379 I2NSF framework should be included in this document. Especially, 380 proper secure communication channels should be used the delivery of 381 control or management messages among the components in the proposed 382 architecture. 384 8. Acknowledgements 386 This work was supported by Institute for Information & communications 387 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 388 (No.R-20160222-002755, Cloud based Security Intelligence Technology 389 Development for the Customized Security Service Provisioning). This 390 document has greatly benefited from inputs by Mahdi Daghmehchi- 391 Firoozjaei, Eunsoo Kim, Soyoung Kim, and Tae-Jin Ahn. 393 9. References 395 9.1. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to 398 Indicate Requirement Levels", BCP 14, RFC 2119, 399 March 1997. 401 9.2. Informative References 403 [i2nsf-framework] Lopez, E., Lopez, D., Dunbar, L., Strassner, J., 404 Zhuang, X., Parrott, J., Krishnan, R., and S. 405 Durbha, "Framework for Interface to Network 406 Security Functions", 407 draft-ietf-i2nsf-framework-00 , May 2016. 409 Authors' Addresses 411 Hyoungshick Kim 412 Department of Software 413 Sungkyunkwan University 414 2066 Seobu-Ro, Jangan-Gu 415 Suwon, Gyeonggi-Do 16419 416 Republic of Korea 418 Phone: +82 31 299 4324 419 Fax: +82 31 290 7996 420 EMail: hyoung@skku.edu 421 URI: http://seclab.skku.edu/people/hyoungshick-kim/ 423 Hoon Ko 424 Department of Computer Science and Engineering 425 Sungkyunkwan University 426 2066 Seobu-Ro, Jangan-Gu 427 Suwon, Gyeonggi-Do 16419 428 Republic of Korea 430 Phone: +82-31-299-4104 431 EMail: skoh21@skku.edu 433 Sanghak Oh 434 Department of Software 435 Sungkyunkwan University 436 2066 Seobu-Ro, Jangan-Gu 437 Suwon, Gyeonggi-Do 16419 438 Republic of Korea 440 Phone: +82-31-299-4104 441 EMail: osh09@skku.edu 442 Jaehoon Paul Jeong 443 Department of Software 444 Sungkyunkwan University 445 2066 Seobu-Ro, Jangan-Gu 446 Suwon, Gyeonggi-Do 16419 447 Republic of Korea 449 Phone: +82 31 299 4957 450 Fax: +82 31 290 7996 451 EMail: pauljeong@skku.edu 452 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 454 Se-Hui Lee 455 Korea Telecom 456 70 Yuseong-Ro, Yuseong-Gu 457 Daejeon 305-811 458 Republic of Korea 460 Phone: +82 42 870 8162 461 EMail: sehuilee@kt.com