idnits 2.17.1 draft-kim-i2nsf-consumer-facing-interface-dm-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 == Line 358 has weird spacing: '...vent-id uint ...' == Line 360 has weird spacing: '...enabled bool...' == Line 363 has weird spacing: '...cy-name strin...' == Line 364 has weird spacing: '...rule-id uint...' == Line 366 has weird spacing: '...andling boole...' == (5 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2016) is 2727 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) ** Downref: Normative reference to an Informational RFC: RFC 3444 Summary: 2 errors (**), 0 flaws (~~), 8 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 D. Daghmehchi 5 Expires: May 4, 2017 J. Jeong 6 Sungkyunkwan University 7 T. Ahn 8 Korea Telecom 9 October 31, 2016 11 I2NSF Data Model of Consumer-Facing Interface for Security Management 12 draft-kim-i2nsf-consumer-facing-interface-dm-00 14 Abstract 16 This document describes a data model for security management that is 17 based on Interface to Network Security Functions (I2NSF) by using 18 Network Functions Virtualization (NFV). This document proposes a 19 security management architecture based on I2NSF framework. Note that 20 the I2NSF framework consists of I2NSF User, Security Management 21 System (i.e., Security Controller and Developer's Management System), 22 and NSF instances in the lowest layer of the framework. I2NSF User 23 consists of Application Logic, Policy Updater, and Event Collector. 24 Security Controller consists of Security Policy Manager and NSF 25 Capability Manager. This document explains a data model to perform 26 the missions for a security service (i.e., VoIP-VoLTE) in I2NSF 27 security management system. 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 May 4, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 72 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 5. Architecture of Security Management . . . . . . . . . . . . . 5 74 5.1. I2NSF User . . . . . . . . . . . . . . . . . . . . . . . . 6 75 5.2. Security Management System . . . . . . . . . . . . . . . . 7 76 5.3. NSF Instances . . . . . . . . . . . . . . . . . . . . . . 7 77 6. Use Case: VoIP-VoLTE Security Service . . . . . . . . . . . . 7 78 6.1. Security Management for VoIP-VoLTE Security Service . . . 8 79 6.2. Data Model for VoIP-VoLTE Security Service . . . . . . . . 8 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 Basically, information model and data model are used to defining the 89 managed objects in the network management. Despite of some 90 overlapped details, they have different characters in the view of 91 network management. Generally, the main purpose of information model 92 is to model managed objects at a conceptual level, with no dependent 93 of any specific implementations or protocols. To make a clear 94 overall design, the information model should hide all protocol and 95 implementation details defining relationships between managed 96 objects. Based on this, the information models can be implemented in 97 different ways and mapped on different protocols. They are neutral 98 to protocols. In general, information models can be defined in an 99 informal way, using natural languages such as English. Furthermore, 100 it seems advisable to use object-oriented techniques to describe an 101 information model. 103 Data models are defined at a lower level of abstraction and provide 104 many details. They provide details about the implementation and 105 protocols' specification, e.g., rules that explain how to map managed 106 objects onto lower-level protocol constructs. Since conceptual 107 models can be implemented in different ways, multiple data models can 108 be derived by a single information model. 110 The impressive role of the network functions virtualization (NFV) in 111 the network management leads to a rapid advent of NFV in this 112 industry. As practical applications, network security functions 113 (NSFs), such as firewall, intrusion detection system (IDS) and 114 intrusion protection system (IPS), can also be provided as virtual 115 network functions (VNF). By virtual technology, these VNFs might be 116 automatically provisioned and dynamically migrated based on real-time 117 security requirements. This document presents an information model 118 to implement security functions based on NFV. 120 This document proposes a data modeling in an architecture for 121 security management [i2nsf-security-management], which is based on 122 I2NSF framework [i2nsf-framework]. This I2NSF framework contains 123 I2NSF User, Security Management System (i.e., Security Controller and 124 Developer's Management System), and NSFs in the NSF instance layer. 125 The security management architecture has more detailed structures for 126 core components in the I2NSF framework. I2NSF User includes 127 Application Logic, Policy Updater, and Event Collector. Security 128 Controller contains Security Policy Manager and NSF Capability 129 Manager. 131 Application Logic generates a high-level policy and Policy Updater 132 sends it to Security Policy Manager via Consumer-Facing Interface. 133 Security Policy Manager maps the high-level policy into several low- 134 level policies in Security Controller. After mapping, the low-level 135 policies are distributed to NSF(s) via NSF-Facing Interface so that 136 they can be enforced in them. When an event occurs for NSF to change 137 a low-level policy, NSF sends the event to Security Controller via 138 NSF-Facing Interface. Security Controller then forwards it to Event 139 Collector via Consumer-Facing Interface. Next, Event Collector sends 140 it to Application Logic. Application Logic then updates the current 141 policies in accordance with the event. 143 This document proposes a data model for security services in the 144 security management architecture in [i2nsf-security-management] so 145 that the security management architecture can support flexible and 146 effective security policies. 148 2. Objectives 150 The two main objectives for security management architecture in this 151 document are as follows. 153 o High-level security management: To propose the design of a generic 154 security management architecture to support the enforcement of 155 flexible and effective security policies in NSFs. 157 o Automatic update of security policies: To provide the reflection 158 of the updated low-level security policies for new security 159 attacks on the corresponding high-level security policies. 161 3. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC3444]. 167 4. Terminology 169 This document uses the terminology described in 170 [i2nsf-framework][i2nsf-security-management]. In addition, the 171 following terms are defined below: 173 o Application Logic: It is a component in the security management 174 architecture which generates high-level security policies to block 175 or mitigate security attacks. 177 o Policy Updater: It is a component which forwards a high-level 178 security policy to Security Controller. The high-level policy is 179 received from Application Logic. 181 o Security Policy Manager: It maps a high-level security policy 182 received from Policy Updater into low-level security policies, and 183 vice versa. 185 o NSF Capability Manager: It is a component which stores the NSF 186 capability registered by Developer's Management System via 187 Registration Interface and shares it with Security Policy Manger 188 to generate the corresponding low-level security policies. 190 o Event Collector: It is a component which receives an event from 191 Security Controller, which should be reflected by updating (or 192 generating) a high-level policy in Application Logic. 194 5. Architecture of Security Management 196 Generally, Data models are often represented in formal data 197 definition languages that are specific to the management protocol 198 being used. Based on NFV, the structure of the proposed model is 199 based on VNFs to provide a flexible and effective security policies. 200 Figure 1 illustrates the structure of the suggested model. The 201 architecture is designed based on three layers: I2NSF user, security 202 management system, and NSF instances. The high level security 203 policies are defined and distributed in the I2NSF user layer. 204 Translating the high level security policies relevant to NSF 205 capability and delivering them to NSF interfaces are performed in the 206 security management system. 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | I2NSF User | 210 | +-+-+-+-+-+-+-+-+-+-+-+ | 211 | ---| Application Logic |<-- | 212 | | +-+-+-+-+-+-+-+-+-+-+-+ | | 213 | | | | 214 | | | | 215 | +-+-+-+v+-+-+-+-+-+ +-+-+-+v+-+-+-+ | 216 | | Policy Updater | | Event | | 217 | +-+-+-+-+-+-+-+-+-+ | Collector | | 218 | | +-+-+-+^+-+-+-+ | 219 | | | | 220 | | | | 221 | | ------------------- | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | Consumer-Facing Interface 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |Security Management System| | | 226 | +-+-+-+-+-+-+-+-+-+v+-+-+-+-+ | 227 | |Security Controller | | 228 | | +-+-+-+-+-+ +-+-+-+-+-+-+ | Registration | 229 | | |Security | |NSF | | Interface +-+-+-+-+-+-+-+ | 230 | | |Policy | |Capability | |<----------->| Developer's | | 231 | | |Manager | |Manager | | | Mgnt System | | 232 | | +-+-+-+-+-+ +-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ | 233 | +-+-+-+-+-+-^-+-+-+-+-+-+-+-+ | 234 +-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 |--------------------------------- NSF-Facing Interface 236 +-+-+-+-+-+-+-|-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+ 237 |NSF Instances| | | | 238 | +-+-+v+-+-+ +-+-+v+-+-+ +-+-+v+-+-+ | 239 | | NSF | | NSF | . . . | NSF | | 240 | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Figure 1: Security Management Architecture in I2NSF 245 5.1. I2NSF User 247 I2NSF User layer consists of three components; Application logic, 248 Policy Updater, and Event Collector. The Application logic is a 249 component which generates high level security policies. To this end, 250 it receives the event for updating (or generating) a high level 251 policy from Event collector and updates (or generates) a high level 252 policy based on the collected events. After that, the high level 253 policy is sent to Policy updater in order to distribute it to 254 Security controller(s). In order to update (or generate) a high 255 level policy, Event collector receives the events sent by Security 256 controller and sends them to Application logic. Based on these 257 feedbacks, the Application logic can update (or generate) high level 258 security policies. 260 5.2. Security Management System 262 In the security management system layer, the Security policy manager 263 receives a high level policy from Policy updater via Consumer-Facing 264 Interface and maps this policy into several low level policies. 265 These low level policies are relevant to a given NSF capability that 266 is registered into NSF capability manager. Moreover, Security policy 267 manager delivers those policies to NSF(s) via NSF-Facing Interface. 269 To generate low level policies relevant to a given NSF capability, 270 the NSF capability manager stores an NSF's capability registered by 271 Developer's management system and shares it with Security policy 272 manager. Whenever a new NSF is registered, NSF capability manager 273 requests Developer's management system to register the NSF's 274 capability into the management table of NSF capability manager via 275 Registration Interface. Developer's management system is another 276 part of security management system to registers a new NSF's 277 capability into NSF capability manager. 279 5.3. NSF Instances 281 All NSFs are located at this layer. After mapping the high level 282 policies to low level policies, the Security policy manager delivers 283 those policies to NSF(s) through NSF-Facing Interface. 285 6. Use Case: VoIP-VoLTE Security Service 287 As a use case for implementation, VoIP-VoLTE security management is 288 considered to develop a data model. Based on this, the VoIP-VoLTE 289 security manager acts as Application logic for VoIP-VoLTE security 290 services and defines the security conditions. Based on VoIP-VoLTE 291 security management, the list of illegal devices information is 292 stored in VoIP-VoLTE database and can be updated either manually or 293 automatically by VoIP-VoLTE security manager. To define the 294 policies, information of dangerous domain blacklists (e.g., IP 295 addresses and source ports), time management (e.g., access time and 296 expire time), user-agent (e.g., priority levels), and Session 297 Initiation Protocol (SIP) URIs of an SIP device that are suspicious 298 of illegal call or authentication is published by VoIP-VoLTE security 299 manager. Accordingly, ahe list of illegal devices, which is 300 automatically (or manually) updated, is stored in VoIP-VoLTE 301 database. The VoIP-VoLTE security manager periodically loads this 302 list to generate a new high level security policy (e.g., the blocking 303 list of illegal devices using IP address, source ports, etc) to 304 prevent the delivery of packets from/to those newly added VoIP-VoLTE 305 attackers. 307 When the NSF detects an anomalous message or call delivered from a 308 domain, the information of the domain such as an IP address, user- 309 agents and expire time values is sent by an NSF to Security 310 controller via NSF-Facing Interface. Security controller delivers it 311 to Event collector. Event collector forwards the detected domain 312 information to VoIP-VoLTE security manager, and then VoIP-VoLTE 313 security manager updates the VoIP-VoLTE database. 315 6.1. Security Management for VoIP-VoLTE Security Service 317 VoIP-VoLTE security management maintains and publishes the blacklists 318 of IP addresses, source ports, expire time, user-agents, and Session 319 Initiation Protocol (SIP) URIs of SIP device that are suspicious of 320 illegal call and authentication. In our generic security management 321 architecture, VoIP-VoLTE Security Manager is plays the role of 322 Application Logic for VoIP-VoLTE security services in Figure 1. 324 Based on VoIP-VoLTE security management, the list of illegal devices 325 information can be updated either manually or automatically by VoIP- 326 VoLTE Security Manager as Application Logic. Also, VoIP-VoLTE 327 Security Manager periodically generates a new high-level security 328 policy to prevent the delivery of packets from/to those newly added 329 VoIP-VoLTE attackers and enforce the low-level security policies in 330 NSF. It sends the new high-level security policy to Policy Updater, 331 which forwards it to Security Controller. 333 When the NSF detects an anomalous message or call delivered from a 334 domain, the domain information such as an IP address, user-agents and 335 expire time values is sent by an NSF to Security Controller via NSF 336 Facing Interface. Security Controller delivers it to Event 337 Collector. Event Collector forwards the detected domain information 338 to VoIP-VoLTE Security Manager, and then VoIP-VoLTE Security Manager 339 updates the VoIP-VoLTE database. 341 6.2. Data Model for VoIP-VoLTE Security Service 343 To implement the model, three parameters have been considered to 344 define the high level policies; blacklisting countries, time interval 345 specification, and caller's priority levels. If the administrator 346 sets a new high-level security policy, a data model parser in I2NSF 347 User interprets the policy and generates an XML file in accordance 348 with YANG data model. In order to enable interaction between I2NSF 349 User and Security management system, a communication channel based on 350 RESTCONF is implemented. Basically, the data model is defined based 351 on the security policy requirements to detect the suspicious calls in 352 VoIP-VoLTE services. Figure 2 shows a part of this data model. 354 +--: (policy) 355 +--rw policy-lifecycle *(policy-lifecycel-id) 356 | +--rw expiration-event 357 | | +--rw enabled boolean 358 | | +--rw event-id uint 16 359 | +--rw expiration-time 360 | +--rw enabled boolean 361 | +--rw time data-and-time 362 +--rw policy-rule *[policy-rule-id] 363 | +--rw policy-name string 364 | +--rw policy-rule-id uint 16 365 | +--rw service 366 | | +--voip-handling boolean 367 | | +--volet-handling boolean 368 | +--rw condition *[condition-id] 369 | +--rw caller 370 | | +--rw caller-id uint 16 371 | | +--rw caller-location 372 | | +--rw country string 373 | | +--rw city string 374 | +--rw callee 375 | | +--rw callee-id uint 16 376 | | +--rw callee-location 377 | | +--rw country string 378 | | +--rw city string 379 | +--rw valid-time-interval 380 | +--rw start-time data-and-time 381 | +--rw end-time data-and-time 382 +--rw action 383 +--rw (action-type)? 384 +--: (ingress-action) 385 | +--rw permit? boolean 386 | +--rw mirror? boolean 387 | +--rw log? boolean 388 +--: (engress-type) 389 +--rw redirection? boolean 391 Figure 2: Data Model for VoIP-VoLTE Security Service 393 The data model consists of policy life cycle management, policy rule, 394 and action. The policy life cycle field specifies an expiration time 395 and/or a set of expiration events to determine the life-time of the 396 policy itself. The policy rule field represents the specific 397 information about a high-level policy such as service types, 398 conditions and valid time interval. The action field specifies which 399 actions should be taken. For example, call traffic from a 400 blacklisted caller location at an unusual time of day (included in 401 the valid-time-interval) could be blocked and sequentially forwarded 402 to a pre-defined host for Deep Packet Inspection (DPI) when both 403 permit and mirror are assigned true. 405 To translate a high level policy into a set of low level policies, 406 the security management system is implemented. After translating the 407 high-level security policy, Security management system generates low- 408 level security policies to specify the actions network traffic from 409 and/or to those IP addresses. The data model parser generates an XML 410 _le for a low-level security policy and delivers it to proper NSF 411 instances. Security management system also interprets security 412 events generated by NSF into a high-level log message in a YANG data 413 model and delivers it to I2NSF Users in the opposite direction. 415 In this case, we select a firewall application as an NSF instance to 416 determine whether a VoIP-VoLTE call is suspicious or not by checking 417 the caller's and callee's locations and call time. When a call has 418 suspicious behavior patterns, its network traffic could be 419 effectively blocked by the firewall application according to the low- 420 level security policy. The results for the firewall application 421 would be delivered in a YANG data model to the Security management 422 system through the RESTCONF protocol. Multiple NSF instances can be 423 considered depending on specific situations. For example, 424 additionally DPI can be used for analyzing the network traffic from 425 suspicious callers. 427 7. Security Considerations 429 The security management architecture is derived from the I2NSF 430 framework [i2nsf-framework], so the security considerations of the 431 I2NSF framework should be included in this document. Especially, 432 proper secure communication channels should be used for the delivery 433 of control or management messages amongst the components in the 434 proposed architecture. 436 8. Acknowledgements 438 This work was supported by Institute for Information & communications 439 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 440 (No.R-20160222-002755, Cloud based Security Intelligence Technology 441 Development for the Customized Security Service Provisioning). This 442 document has greatly benefited from inputs by Sanghak Oh, Eunsoo Kim, 443 Soyoung Kim, and Se-Hui Lee. 445 9. References 446 9.1. Normative References 448 [RFC3444] Pras, A., "On the Difference between 449 Information Models and Data Models", 450 RFC 3444, January 2003. 452 9.2. Informative References 454 [i2nsf-framework] Lopez, D., Lopez, E., Dunbar, L., 455 Strassner, J., and R. Kumar, "Framework 456 for Interface to Network Security 457 Functions", 458 draft-ietf-i2nsf-framework-04 (work in 459 progress), October 2016. 461 [i2nsf-security-management] Kim, H., Ko, H., Oh, S., Jeong, J., and 462 S. Lee, "An Architecture for Security 463 Management in I2NSF Framework", draft- 464 kim-i2nsf-security-management- 465 architecture-03 (work in progress), 466 October 2016. 468 Authors' Addresses 470 Hyoungshick Kim 471 Department of Software 472 Sungkyunkwan University 473 2066 Seobu-Ro, Jangan-Gu 474 Suwon, Gyeonggi-Do 16419 475 Republic of Korea 477 Phone: +82 31 299 4324 478 Fax: +82 31 290 7996 479 EMail: hyoung@skku.edu 480 URI: http://seclab.skku.edu/people/hyoungshick-kim/ 482 Hoon Ko 483 Department of Computer Science and Engineering 484 Sungkyunkwan University 485 2066 Seobu-Ro, Jangan-Gu 486 Suwon, Gyeonggi-Do 16419 487 Republic of Korea 489 Phone: +82-31-299-4104 490 EMail: skoh21@skku.edu 491 Mahdi Daghmehchi Firoozjaei 492 Department of Electical and Computer Enginering 493 Sungkyunkwan University 494 2066 Seobu-Ro, Jangan-Gu 495 Suwon, Gyeonggi-Do 16419 496 Republic of Korea 498 Phone: +82-31-299-4104 499 EMail: mdaghmechi@skku.edu 501 Jaehoon Paul Jeong 502 Department of Software 503 Sungkyunkwan University 504 2066 Seobu-Ro, Jangan-Gu 505 Suwon, Gyeonggi-Do 16419 506 Republic of Korea 508 Phone: +82 31 299 4957 509 Fax: +82 31 290 7996 510 EMail: pauljeong@skku.edu 511 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 513 Tae-Jin Ahn 514 Korea Telecom 515 70 Yuseong-Ro, Yuseong-Gu 516 Daejeon 305-811 517 Republic of Korea 519 Phone: +82 42 870 8409 520 EMail: taejin.ahn@kt.com