idnits 2.17.1 draft-kim-i2nsf-security-management-architecture-02.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 5, 2016) is 2757 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: April 8, 2017 J. Jeong 6 Sungkyunkwan University 7 S. Lee 8 Korea Telecom 9 October 5, 2016 11 An Architecture for Security Management in I2NSF Framework 12 draft-kim-i2nsf-security-management-architecture-02 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 Event 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, security 27 management for VoIP-VoLTE and time-dependent access control. 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 April 8, 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. Event 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 6.3. Security Management for Time-Dependent Access Control . . 9 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 89 Appendix A. Changes from 90 draft-kim-i2nsf-security-management-architecture-01 . 10 92 1. Introduction 94 To enforce a user's high-level security policy into the I2NSF 95 framework [i2nsf-framework], I2NSF Client delivers such a policy to 96 Security Controller via Client Facing Interface. In this document, 97 an architecture for security management is proposed for a given high- 98 level policy in the I2NSF framework. This architecture contains 99 I2NSF Client, Security Management System (i.e., Security Controller 100 and Developer's Management System), and NSFs in the I2NSF framework. 101 I2NSF Client includes Application Logic, Policy Updater, and Event 102 Collector. Security Controller contains Security Policy Manager and 103 NSF Capability Manager. 105 Security Policy Manager and NSF Capability Manager in Security 106 Controller are responsible for controlling the updated security 107 policy which will be given by Policy Updater in I2NSF Client via 108 Client Facing Interface. If a new policy were created or existing 109 policies needed to be updated, Policy Updater delivers them to 110 Security Controller. On the other hand, when an event occurs for NSF 111 to change a low-level policy, NSF sends the event to Security 112 Controlleri. Security Controller then forwards it to Event 113 Collector. Next, Event Collector sends it to Application Logic. 114 Application Logic then updates the current policies in accordance 115 with the event. 117 In this document, we propose a security management architecture that 118 integrates additional components for security management into the 119 I2NSF framework. Our architecture is designed to support flexible 120 and effective security policies. Application Logic generates a high- 121 level policy and Policy Updater sends it to Security Policy Manager 122 via Client Facing Interface. Security Policy Manager maps the high- 123 level policy into several low-level policies in Security Controller. 124 After mapping, the low-level policies are distributed to NSF(s) so 125 that they can be enforced in them. 127 2. Objectives 129 The two main objectives for security management architecture in this 130 document are as follows. 132 o High-level security management: To propose the design of a generic 133 security management architecture to support the enforcement of 134 flexible and effective security policies in NSFs. 136 o Automatic update of security policies: To provide the reflection 137 of the updated low-level security policies for new security 138 attacks on the corresponding high-level security policies. 140 3. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 4. Terminology 148 This document uses the terminology described in [i2nsf-framework]. 149 In addition, the following terms are defined below: 151 o Application Logic: It is a component in the security management 152 architecture which generates high-level security policies to block 153 or mitigate security attacks. 155 o Policy Updater: It is a component which forwards a high-level 156 security policy to Security Controller. The high-level policy is 157 received from Application Logic. 159 o Security Policy Manager: It maps a high-level security policy 160 received from Policy Updater into low-level security policies, and 161 vice versa. 163 o NSF Capability Manager: It is a component which stores the NSF 164 capability registered by Developer's Management System via 165 Registration Interface and shares it with Security Policy Manger 166 to generate the corresponding low-level security policies. 168 o Event Collector: It is a component which receives an event from 169 Security Controller, which should be reflected by updating (or 170 generating) a high-level policy in Application Logic. 172 5. Architecture of Security Management 174 This section describes a security management architecture in I2NSF 175 and focuses on Security Management System containing Security 176 Controller and Developer's Management System. It also explains some 177 basic operations of Security Controller and describes the details of 178 each component consisting the architecture. 180 Figure 1 shows a security management architecture in the I2NSF 181 framework. The architecture is designed to support the enforcement 182 of flexible and effective security policies. Application Logic in 183 I2NSF Client generates a high-level policy in accordance with new 184 security attacks, and Policy Updater in I2NSF Client then sends the 185 policy to Security Policy Manager in Security Controller. Security 186 Policy Manager maps the high-level policy into several low-level 187 policies which are relevant to NSF capability registered into NSF 188 Capability Manager. After mapping, the low-level policies are 189 distributed to NSF(s) by Security Policy Manager through NSF Facing 190 Interface. In the following sections, we explain the details of each 191 component. 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | I2NSF Client | 195 | +-+-+-+-+-+-+-+-+-+-+-+ | 196 | -->| Application Logic |<-- | 197 | | +-+-+-+-+-+-+-+-+-+-+-+ | | 198 | | | | 199 | | | | 200 | +-+-+-+v+-+-+-+-+-+ +-+-+-+v+-+-+-+ | 201 | | Policy Updater | | Event | | 202 | +-+-+-+-+-+-+-+-+-+ | Collector | | 203 | | +-+-+-+^+-+-+-+ | 204 | | | | 205 | | | | 206 | | ------------------- | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | Client Facing Interface 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 |Security Management System| | | 211 | +-+-+-+-+-+-+-+-+-+v+-+-+-+-+ | 212 | |Security Controller | | 213 | | +-+-+-+-+-+ +-+-+-+-+-+-+ | Registration | 214 | | |Security | |NSF | | Interface +-+-+-+-+-+-+-+ | 215 | | |Policy | |Capability | |<----------->| Developer's | | 216 | | |Manager | |Manager | | | Mgnt System | | 217 | | +-+-+-+-+-+ +-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ | 218 | +-+-+-+-+-+-^-+-+-+-+-+-+-+-+ | 219 +-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | NSF Facing Interface 221 +-+-+v+-+-+ 222 | NSF | 223 +-+-+-+-+-+ 225 Figure 1: Security Management Architecture in I2NSF 227 5.1. Security Policy Manager 229 Security Policy Manager is a component which receives a high-level 230 policy from Policy Updater via Client Facing Interface, and maps the 231 high-level policy into several low-level policies which are relevant 232 to a given NSF capability from NSF Capability Manager. Additionally, 233 Security Policy Manager delivers those policies to NSF(s) via NSF 234 Facing Interface. 236 On the other hand, when an event that requires the low-level policies 237 to be changed happens in NSF, NSF sends the event to Security Policy 238 Manager via NSF Facing Interface. Security Policy Manager then sends 239 it to Event collector via Client Facing Interface. 241 5.2. NSF Capability Manager 243 NSF Capability Manager is a component integrated into Security 244 Controller. It stores the NSF capability registered by Developer's 245 Management System via Registration Interface and shares it with 246 Security Policy Manager so that Security Policy Manager can generate 247 low-level policies relevant to a given NSF capability. Moreover, 248 whenever a new NSF is registered, NSF Capability Manager requests 249 Developer's Management System to register the NSF capability into the 250 management table of NSF Capability Manager via Registration 251 Interface. On the other hand, when the existing NSF is deleted, NSF 252 Capability Manager eliminates the NSF capability from its management 253 table. 255 5.3. Developer's Management System 257 Developer's Management System is a component which registers a new 258 NSF's capability to NSF Capability Manager via Registration 259 Interface. Moreover, in case there are some updates in the 260 registered NSF, such updates will be delivered from Developer's 261 Management System to NSF Capability Manager. 263 5.4. Application Logic 265 Application Logic is a component which generates a high-level 266 security policy to block or mitigate security attacks, and sends the 267 generated policies to Policy Updater. However, this component is out 268 of our standardization scope. We explain its detailed operations in 269 two use cases in Section 6. 271 5.5. Policy Updater 273 Policy Updater is a component which receives a high-level security 274 policy generated by Application Logic and delivers it to Security 275 Policy Manager via Client Facing Interface. 277 5.6. Event Collector 279 Event Collector receives an event from Security Controller, which 280 should be reflected by updating (or generating) a high-level policy 281 in Application Logic. The procedure of receiving an event in NSF is 282 necessary because a low-level security policy can be updated 283 according to a specific event that occurred in an NSF. After 284 receiving the event, Event Collector forwards it to Application Logic 285 so that Application Logic can update (or generate) a high-level 286 security policy based on the event received from Security Controller. 288 6. Use Cases 290 A generic architecture is designed to react to security attacks that 291 can occur in a real world environment. This section shows the 292 procedure of the defense for security attacks in the I2NSF framework 293 [i2nsf-framework] for a given list of security attacks in malware 294 domains, VoIP/VoLTE security attacks, and time-dependent access 295 control. 297 6.1. Security Management for the List of Malware Domains 299 Malware domain blacklisting maintains and publishes the blacklists of 300 IP addresses of possible attacking hosts, servers, and networks that 301 are suspicious of malicious activities. Figure 2 shows a security 302 management architecture for Malware Domain Blacklisting. 304 Based on the malware domain blacklisting, the list of malware domains 305 can be updated either manually or automatically by Malware Domain 306 Manager in I2NSF Client. Malware Domain Manager also periodically 307 generates a new high-level security policy to prevent the delivery of 308 packets from/to those newly added malware domains and enforce the 309 low-level security policies in NSF. Additionally, Malware Domain 310 Manager sends the new high-level security policy to Policy Updater, 311 which forwards it to Security Controller. 313 When NSF detects a new dangerous domain, the corresponding IP 314 addresses are sent by an NSF to Security controller via NSF Facing 315 Interface. Security Controller delivers the IP addresses to Event 316 Collector, which in turn forwards the IP addresses to Dangerous 317 Domain Manager. Finally, Dangerous Domain Manager updates the 318 Dangerous domain database. 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | I2NSF Client | 322 | +-+-+-+-+-+-+-+-+-+-+-+-+ | 323 | -->|Malware Domain Manager |<-- | 324 | | +-+-+-+-+-+-+-+-+-+-+-+-+ | | 325 | | | | 326 | | | | 327 | +-+-+-+v+-+-+-+-+-+ +-+-+-+-+v+-+-+ | 328 | | Policy Updater | | Event | | 329 | +-+-+-+-+-+-+-+-+-+ | Collector | | 330 | | +-+-+-+^+-+-+-+ | 331 | | | | 332 | | | | 333 | | ------------------- | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | |Client Facing Interface 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 |Security Management System| | 338 | +-+-+-+-+-+-+-+-+-+v+-+-+-+-+ | 339 | |Security Controller | | 340 | | +-+-+-+-+-+ +-+-+-+-+-+-+ | Registration | 341 | | |Security | |NSF | | Interface +-+-+-+-+-+-+-+ | 342 | | |Policy | |Capability | |<----------->| Developer's | | 343 | | |Manager | |Manager | | | Mgnt System | | 344 | | +-+-+-+-+-+ +-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ | 345 | +-+-+-+-+-+-^-+-+-+-+-+-+-+-+ | 346 +-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 |NSF Facing Interface 348 +-+-+v+-+-+ 349 | NSF | 350 +-+-+-+-+-+ 352 Figure 2: Malware Domain Blacklisting 354 6.2. Security Management for VoIP-VoLTE 356 VoIP-VoLTE security management maintains and publishes the blacklists 357 of IP addresses, source ports, expire time, user-agents, and Session 358 Initiation Protocol (SIP) URIs of SIP device that are suspicious of 359 illegal call and authentication. In our generic security management 360 architecture, VoIP-VoLTE Security Manager is plays the role of 361 Application Logic for VoIP-VoLTE security services in Figure 1. 363 Based on VoIP-VoLTE security management, the list of illegal devices 364 information can be updated either manually or automatically by VoIP- 365 VoLTE Security Manager as Application Logic. Also, VoIP-VoLTE 366 Security Manager periodically generates a new high-level security 367 policy to prevent the delivery of packets from/to those newly added 368 VoIP-VoLTE attackers and enforce the low-level security policies in 369 NSF. It sends the new high-level security policy to Policy Updater, 370 which forwards it to Security Controller. 372 When the NSF detects an anomalous message or call delivered from a 373 domain, the domain information such as an IP address, user-agents and 374 expire time values is sent by an NSF to Security Controller via NSF 375 Facing Interface. Security Controller delivers it to Event 376 Collector. Event Collector forwards the detected domain information 377 to VoIP-VoLTE Security Manager, and then VoIP-VoLTE Security Manager 378 updates the VoIP-VoLTE database. 380 6.3. Security Management for Time-Dependent Access Control 382 Time-dependent access control policies manage a user's access to 383 particular websites during a certain period of time. For example, in 384 a company, a manager blocks employees' access to Youtube, which is a 385 big distraction during working hours. 387 Based on time-dependent access control, I2NSF Client registers the 388 list of blocked websites and blocking time at Application logic. 389 Application logic stores the list into database and generates a high- 390 level security policy (e.g., blocking the access to websites by 391 checking the blocked websites and blocking time in the list). 392 Application logic delivers it to Policy updater, and then Policy 393 updater forwards it to Security controller. In Security controller, 394 Security policy manager maps the high-level policy to low-level 395 policies, and then it sends the corresponding NSFs to enforce the 396 low-level policies. 398 7. Security Considerations 400 The security management architecture is derived from the I2NSF 401 framework [i2nsf-framework], so the security considerations of the 402 I2NSF framework should be included in this document. Especially, 403 proper secure communication channels should be used for the delivery 404 of control or management messages amongst the components in the 405 proposed architecture. 407 8. Acknowledgements 409 This work was supported by Institute for Information & communications 410 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 411 (No.R-20160222-002755, Cloud based Security Intelligence Technology 412 Development for the Customized Security Service Provisioning). This 413 document has greatly benefited from inputs by Mahdi Daghmehchi- 414 Firoozjaei, Eunsoo Kim, Soyoung Kim, and Tae-Jin Ahn. 416 9. References 418 9.1. Normative References 420 [RFC2119] Bradner, S., "Key words for use in RFCs to 421 Indicate Requirement Levels", BCP 14, RFC 2119, 422 March 1997. 424 9.2. Informative References 426 [i2nsf-framework] Lopez, E., Lopez, D., Dunbar, L., Strassner, J., 427 Zhuang, X., Parrott, J., Krishnan, R., Durbha, S., 428 Kumar, R., and A. Lohiya, "Framework for Interface 429 to Network Security Functions", 430 draft-ietf-i2nsf-framework-03 (work in progress), 431 August 2016. 433 Appendix A. Changes from 434 draft-kim-i2nsf-security-management-architecture-01 436 The following changes were made from 437 draft-kim-i2nsf-security-management-architecture-01: 439 o This version reflects the framework for I2NSF in 440 draft-ietf-i2nsf-framework-03. 442 o As a term change, Policy Collector is renamed Event Collector. 444 o A new use case for time-dependent access control is added. 446 o As a logic change, NSF generates an event rather than an updated 447 low-level policy for a new security attack, and then sends it to 448 Security Controller. 450 Authors' Addresses 452 Hyoungshick Kim 453 Department of Software 454 Sungkyunkwan University 455 2066 Seobu-Ro, Jangan-Gu 456 Suwon, Gyeonggi-Do 16419 457 Republic of Korea 459 Phone: +82 31 299 4324 460 Fax: +82 31 290 7996 461 EMail: hyoung@skku.edu 462 URI: http://seclab.skku.edu/people/hyoungshick-kim/ 463 Hoon Ko 464 Department of Computer Science and Engineering 465 Sungkyunkwan University 466 2066 Seobu-Ro, Jangan-Gu 467 Suwon, Gyeonggi-Do 16419 468 Republic of Korea 470 Phone: +82-31-299-4104 471 EMail: skoh21@skku.edu 473 Sanghak Oh 474 Department of Software 475 Sungkyunkwan University 476 2066 Seobu-Ro, Jangan-Gu 477 Suwon, Gyeonggi-Do 16419 478 Republic of Korea 480 Phone: +82-31-299-4104 481 EMail: osh09@skku.edu 483 Jaehoon Paul Jeong 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 299 4957 491 Fax: +82 31 290 7996 492 EMail: pauljeong@skku.edu 493 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 495 Se-Hui Lee 496 Korea Telecom 497 70 Yuseong-Ro, Yuseong-Gu 498 Daejeon 305-811 499 Republic of Korea 501 Phone: +82 42 870 8162 502 EMail: sehuilee@kt.com