idnits 2.17.1 draft-jeong-i2nsf-consumer-facing-interface-dm-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 (March 13, 2017) is 2601 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 (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong 3 Internet-Draft D. Daghmehchi 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: September 14, 2017 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 March 13, 2017 13 Consumer-Facing Interface YANG Data Model for Interface to Network 14 Security Functions 15 draft-jeong-i2nsf-consumer-facing-interface-dm-01 17 Abstract 19 This document describes a YANG data model for security management 20 that is based on Interface to Network Security Functions (I2NSF) by 21 using Network Functions Virtualization (NFV). This document proposes 22 a security management architecture based on I2NSF framework. Note 23 that the I2NSF framework consists of I2NSF User, Security Management 24 System (i.e., Security Controller and Developer's Management System), 25 and the instances of Network Security Functions (NSFs) in the lowest 26 layer of the framework. I2NSF User consists of Application Logic, 27 Policy Updater, and Event Collector. Security Controller consists of 28 Security Policy Manager and NSF Capability Manager. This document 29 explains a data model to perform the missions for a security service 30 (i.e., VoIP-VoLTE) in I2NSF security management system. 32 Status of This Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on September 14, 2017. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 75 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 5. Architecture of Security Management . . . . . . . . . . . . . 5 77 5.1. I2NSF User . . . . . . . . . . . . . . . . . . . . . . . . 6 78 5.2. Security Management System . . . . . . . . . . . . . . . . 7 79 5.3. NSF Instances . . . . . . . . . . . . . . . . . . . . . . 7 80 6. Use Case: VoIP-VoLTE Security Service . . . . . . . . . . . . 7 81 6.1. Security Management for VoIP-VoLTE Security Service . . . 8 82 6.2. Data Modeling for VoIP-VoLTE Security Service . . . . . . 8 83 6.3. YANG Data Model for VoIP-VoLTE Security Service . . . . . 11 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 89 Appendix A. Changes from 90 draft-jeong-i2nsf-consumer-facing-interface-dm-00 . . 19 92 1. Introduction 94 Basically, information model and data model are used to defining the 95 managed objects in the network management. Despite of some 96 overlapped details, they have different characters in the view of 97 network management. Generally, the main purpose of information model 98 is to model managed objects at a conceptual level, with no dependent 99 of any specific implementations or protocols. To make a clear 100 overall design, the information model should hide all protocol and 101 implementation details defining relationships between managed 102 objects. Based on this, the information models can be implemented in 103 different ways and mapped on different protocols. They are neutral 104 to protocols. In general, information models can be defined in an 105 informal way, using natural languages such as English. Furthermore, 106 it seems advisable to use object-oriented techniques to describe an 107 information model. 109 Data models are defined at a lower level of abstraction and provide 110 many details. They provide details about the implementation and 111 protocols' specification, e.g., rules that explain how to map managed 112 objects onto lower-level protocol constructs. Since conceptual 113 models can be implemented in different ways, multiple data models can 114 be derived by a single information model. 116 The impressive role of the network functions virtualization (NFV) in 117 the network management leads to a rapid advent of NFV in this 118 industry. As practical applications, network security functions 119 (NSFs), such as firewall, intrusion detection system (IDS) and 120 intrusion protection system (IPS), can also be provided as virtual 121 network functions (VNF). By virtual technology, these VNFs might be 122 automatically provisioned and dynamically migrated based on real-time 123 security requirements. This document presents an information model 124 to implement security functions based on NFV. 126 This document proposes a data modeling in an architecture for 127 security management [i2nsf-security-mgnt], which is based on I2NSF 128 framework [i2nsf-framework], the requirements and information model 129 for I2NSF consumer-facing interface (i.e., client-facing interface) 130 to security controller [client-facing-inf-req] 131 [client-facing-inf-im]. This I2NSF framework contains I2NSF User, 132 Security Management System (i.e., Security Controller and Developer's 133 Management System), and NSFs in the NSF instance layer. The security 134 management architecture has more detailed structures for core 135 components in the I2NSF framework. I2NSF User includes Application 136 Logic, Policy Updater, and Event Collector. Security Controller 137 contains Security Policy Manager and NSF Capability Manager. 139 Application Logic generates a high-level policy and Policy Updater 140 sends it to Security Policy Manager via Consumer-Facing Interface. 141 Security Policy Manager maps the high-level policy into several low- 142 level policies in Security Controller. After mapping, the low-level 143 policies are distributed to NSF(s) via NSF-Facing Interface so that 144 they can be enforced in them. When an event occurs for NSF to change 145 a low-level policy, NSF sends the event to Security Controller via 146 NSF-Facing Interface. Security Controller then forwards it to Event 147 Collector via Consumer-Facing Interface. Next, Event Collector sends 148 it to Application Logic. Application Logic then updates the current 149 policies in accordance with the event. 151 This document proposes a data model for security services in the 152 security management architecture in [i2nsf-security-mgnt] so that the 153 security management architecture can support flexible and effective 154 security policies. 156 2. Objectives 158 The two main objectives for security management architecture in this 159 document are as follows: 161 o High-level security management: To propose the design of a generic 162 security management architecture to support the enforcement of 163 flexible and effective security policies in NSFs. 165 o Automatic update of security policies: To provide the reflection 166 of the updated low-level security policies for new security 167 attacks on the corresponding high-level security policies. 169 3. Requirements Language 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC3444]. 175 4. Terminology 177 This document uses the terminology described in 178 [i2nsf-framework][i2nsf-security-mgnt]. In addition, the following 179 terms are defined below: 181 o Application Logic: It is a component in the security management 182 architecture which generates high-level security policies to block 183 or mitigate security attacks. 185 o Policy Updater: It is a component which forwards a high-level 186 security policy to Security Controller. The high-level policy is 187 received from Application Logic. 189 o Security Policy Manager: It maps a high-level security policy 190 received from Policy Updater into low-level security policies, and 191 vice versa. 193 o NSF Capability Manager: It is a component which stores the NSF 194 capability registered by Developer's Management System via 195 Registration Interface and shares it with Security Policy Manger 196 to generate the corresponding low-level security policies. 198 o Event Collector: It is a component which receives an event from 199 Security Controller, which should be reflected by updating (or 200 generating) a high-level policy in Application Logic. 202 5. Architecture of Security Management 204 Generally, Data models are often represented in formal data 205 definition languages that are specific to the management protocol 206 being used. Based on NFV, the structure of the proposed model is 207 based on VNFs to provide a flexible and effective security policies. 208 Figure 1 illustrates the structure of the suggested model. The 209 architecture is designed based on three layers: I2NSF user, security 210 management system, and NSF instances. The high level security 211 policies are defined and distributed in the I2NSF user layer. 212 Translating the high level security policies relevant to NSF 213 capability and delivering them to NSF interfaces are performed in the 214 security management system. 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | I2NSF User | 218 | +-+-+-+-+-+-+-+-+-+-+-+ | 219 | ---| Application Logic |<-- | 220 | | +-+-+-+-+-+-+-+-+-+-+-+ | | 221 | | | | 222 | | | | 223 | +-+-+-+v+-+-+-+-+-+ +-+-+-+v+-+-+-+ | 224 | | Policy Updater | | Event | | 225 | +-+-+-+-+-+-+-+-+-+ | Collector | | 226 | | +-+-+-+^+-+-+-+ | 227 | | | | 228 | | | | 229 | | ------------------- | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Consumer-Facing Interface | | Consumer-Facing Interface 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |Security Management System| | | 234 | +-+-+-+-+-+-+-+-+-+v+-+-+-+-+ | 235 | |Security Controller | | 236 | | +-+-+-+-+-+ +-+-+-+-+-+-+ | Registration | 237 | | |Security | |NSF | | Interface +-+-+-+-+-+-+-+ | 238 | | |Policy | |Capability | |<----------->| Developer's | | 239 | | |Manager | |Manager | | | Mgnt System | | 240 | | +-+-+-+-+-+ +-+-+-+-+-+-+ | +-+-+-+-+-+-+-+ | 241 | +-+-+-+-+-+-^-+-+-+-+-+-+-+-+ | 242 +-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |--------------------------------- NSF-Facing Interface 244 +-+-+-+-+-+-+-|-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+ 245 |NSF Instances| | | | 246 | +-+-+v+-+-+ +-+-+v+-+-+ +-+-+v+-+-+ | 247 | | NSF-1 | | NSF-2 | . . . | NSF-n | | 248 | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Figure 1: Security Management Architecture in I2NSF 253 5.1. I2NSF User 255 I2NSF User layer consists of three components; Application logic, 256 Policy Updater, and Event Collector. The Application logic is a 257 component which generates high level security policies. To this end, 258 it receives the event for updating (or generating) a high level 259 policy from Event collector and updates (or generates) a high level 260 policy based on the collected events. After that, the high level 261 policy is sent to Policy updater in order to distribute it to 262 Security controller(s). In order to update (or generate) a high 263 level policy, Event collector receives the events sent by Security 264 controller and sends them to Application logic. Based on these 265 feedbacks, the Application logic can update (or generate) high level 266 security policies. 268 5.2. Security Management System 270 In the security management system layer, the Security policy manager 271 receives a high level policy from Policy updater via Consumer-Facing 272 Interface and maps this policy into several low level policies. 273 These low level policies are relevant to a given NSF capability that 274 is registered into NSF capability manager. Moreover, Security policy 275 manager delivers those policies to NSF(s) via NSF-Facing Interface. 277 To generate low level policies relevant to a given NSF capability, 278 the NSF capability manager stores an NSF's capability registered by 279 Developer's management system and shares it with Security policy 280 manager. Whenever a new NSF is registered, NSF capability manager 281 requests Developer's management system to register the NSF's 282 capability into the management table of NSF capability manager via 283 Registration Interface. Developer's management system is another 284 part of security management system to registers a new NSF's 285 capability into NSF capability manager. 287 5.3. NSF Instances 289 All NSFs are located at this layer. After mapping the high level 290 policies to low level policies, the Security policy manager delivers 291 those policies to NSF(s) through NSF-Facing Interface. 293 6. Use Case: VoIP-VoLTE Security Service 295 As a use case for implementation, VoIP-VoLTE security management is 296 considered to develop a data model. Based on this, the VoIP-VoLTE 297 security manager acts as Application logic for VoIP-VoLTE security 298 services and defines the security conditions. Based on VoIP-VoLTE 299 security management, the list of illegal devices information is 300 stored in VoIP-VoLTE database and can be updated either manually or 301 automatically by VoIP-VoLTE security manager. To define the 302 policies, information of dangerous domain blacklists (e.g., IP 303 addresses and source ports), time management (e.g., access time and 304 expire time), user-agent (e.g., priority levels), and Session 305 Initiation Protocol (SIP) URIs of an SIP device that are suspicious 306 of illegal call or authentication is published by VoIP-VoLTE security 307 manager. Accordingly, ahe list of illegal devices, which is 308 automatically (or manually) updated, is stored in VoIP-VoLTE 309 database. The VoIP-VoLTE security manager periodically loads this 310 list to generate a new high level security policy (e.g., the blocking 311 list of illegal devices using IP address, source ports, etc) to 312 prevent the delivery of packets from/to those newly added VoIP-VoLTE 313 attackers. 315 When the NSF detects an anomalous message or call delivered from a 316 domain, the information of the domain such as an IP address, user- 317 agents and expire time values is sent by an NSF to Security 318 controller via NSF-Facing Interface. Security controller delivers it 319 to Event collector. Event collector forwards the detected domain 320 information to VoIP-VoLTE security manager, and then VoIP-VoLTE 321 security manager updates the VoIP-VoLTE database. 323 6.1. Security Management for VoIP-VoLTE Security Service 325 VoIP-VoLTE security management maintains and publishes the blacklists 326 of IP addresses, source ports, expire time, user-agents, and Session 327 Initiation Protocol (SIP) URIs of SIP device that are suspicious of 328 illegal call and authentication. In our generic security management 329 architecture, VoIP-VoLTE Security Manager is plays the role of 330 Application Logic for VoIP-VoLTE security services in Figure 1. 332 Based on VoIP-VoLTE security management, the list of illegal devices 333 information can be updated either manually or automatically by VoIP- 334 VoLTE Security Manager as Application Logic. Also, VoIP-VoLTE 335 Security Manager periodically generates a new high-level security 336 policy to prevent the delivery of packets from/to those newly added 337 VoIP-VoLTE attackers and enforce the low-level security policies in 338 NSF. It sends the new high-level security policy to Policy Updater, 339 which forwards it to Security Controller. 341 When the NSF detects an anomalous message or call delivered from a 342 domain, the domain information such as an IP address, user-agents and 343 expire time values is sent by an NSF to Security Controller via NSF 344 Facing Interface. Security Controller delivers it to Event 345 Collector. Event Collector forwards the detected domain information 346 to VoIP-VoLTE Security Manager, and then VoIP-VoLTE Security Manager 347 updates the VoIP-VoLTE database. 349 6.2. Data Modeling for VoIP-VoLTE Security Service 351 The data model for VoIP-VoLTE Security Service is derived from i2nsf 352 consumer-facing interface information model. The main objective of 353 this data model is to fully transform the information model into a 354 YANG data model that can be used for delivering security policies to 355 successfully orchestrate control or management messages between the 356 components in the proposed security management architecture. 358 The sementics of the data model must align with those of client- 359 facing interface to security controller information model. The 360 transformation of the information model was done by hand, and thus, 361 certain changes were made to reflect the fact that this is a YANG 362 data model. 364 This data model is a framework that can be extended according to the 365 security needs. In other words, the model design is independent of 366 the content and meaning of specific policies, as well as the 367 implementation approach. Here, the volte/voip security service is 368 used as an example case for policy rule generation. 370 To implement the model, three parameters have been considered to 371 define the high level policies; blacklisting countries, time interval 372 specification, and caller's priority levels. If the administrator 373 sets a new high-level security policy, a data model parser in I2NSF 374 User interprets the policy and generates an XML file in accordance 375 with a YANG data model. In order to enable interaction between I2NSF 376 User and Security management system, a communication channel based on 377 RESTCONF is implemented. Basically, the data model is defined based 378 on the security policy requirements to detect the suspicious calls in 379 VoIP-VoLTE service. Figure 2 shows a generic data model of VoIP- 380 VoLTE security service. 382 +--: (ieft-i2nsf-policy) 383 +--rw policy-lifecycle-list 384 | +--rw policy-lifecycle-container *(policy-lifecycle-id) 385 | +--rw expiration-event 386 | | +--rw enabled boolean 387 | | +--rw event-id uint 16 388 | | +--rw event-date date-and-time 389 | +--rw expiration-time 390 | +--rw enabled boolean 391 | +--rw time date-and-time 392 +--rw policy-rule-list 393 | +--rw policy-rule-container *[policy-rule-id] 394 | +--rw policy-rule-id uint 16 395 | +--rw policy-name string 396 | +--rw policy-date date-and-time 397 | +--rw service 398 | | +--voip-handling boolean 399 | | +--volte-handling boolean 400 | +--rw condition *[condition-id] 401 | +--rw caller 402 | | +--rw caller-id uint 16 403 | | +--rw caller-location 404 | | +--rw country string 405 | | +--rw city string 406 | +--rw callee 407 | | +--rw callee-id uint 16 408 | | +--rw callee-location 409 | | +--rw country string 410 | | +--rw city string 411 | +--rw valid-time-interval 412 | +--rw start-time data-and-time 413 | +--rw end-time data-and-time 414 +--rw action-list 415 | +--rw action-container 416 | +--rw action-date date-and-time 417 | +--rw action-name string 418 | +--: (action-name-ingress) 419 | | +--rw permit? boolean 420 | | +--rw mirror? boolean 421 | | +--rw log? boolean 422 | +--: (action-name-engress) 423 | +--rw redirection? boolean 424 | 425 +--rw update-list 426 +--rw update-container *(update-id) 427 +--rw update-event 428 | +--rw update-event-id uint 16 429 | +--rw update-enabled boolean 430 | +--rw update-event-date date-and-time 431 | +--rw update-log string 432 +--rw update-time date-and-time 434 Figure 2: Generic Data Model for VoIP-VoLTE Security Service 436 The data model consists of policy life cycle management, policy rule, 437 and action. The policy life cycle field specifies an expiration time 438 and/or a set of expiration events to determine the life-time of the 439 policy itself. The policy rule field represents the specific 440 information about a high-level policy such as service types, 441 conditions and valid time interval. The action field specifies which 442 actions should be taken. For example, call traffic from a 443 blacklisted caller location at an unusual time of day (included in 444 the valid-time-interval) could be blocked and sequentially forwarded 445 to a pre-defined host for Deep Packet Inspection (DPI) when both 446 permit and mirror are assigned true. 448 To translate a high level policy into a set of low level policies, 449 the security management system is implemented. After translating the 450 high-level security policy, Security management system generates low- 451 level security policies to specify the actions network traffic from 452 and/or to those IP addresses. The data model parser generates an XML 453 _le for a low-level security policy and delivers it to proper NSF 454 instances. Security management system also interprets security 455 events generated by NSF into a high-level log message in a YANG data 456 model and delivers it to I2NSF Users in the opposite direction. 458 In this case, we select a firewall application as an NSF instance to 459 determine whether a VoIP-VoLTE call is suspicious or not by checking 460 the caller's and callee's locations and call time. When a call has 461 suspicious behavior patterns, its network traffic could be 462 effectively blocked by the firewall application according to the low- 463 level security policy. The results for the firewall application 464 would be delivered in a YANG data model to the Security management 465 system through the RESTCONF protocol. Multiple NSF instances can be 466 considered depending on specific situations. For example, 467 additionally DPI can be used for analyzing the network traffic from 468 suspicious callers. 470 6.3. YANG Data Model for VoIP-VoLTE Security Service 472 This section describes a YANG data model for VoIP-VoLTE security 473 service, which is based on the information of consumer-facing 474 interface to security controller [client-facing-inf-im]. 476 file "ietf-i2nsf-consumer-facing-interface.yang" 478 module ietf-i2nsf-consumer-facing-interface { 479 namespace 480 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-consumer-facing-interface"; 481 prefix 482 capability-interface; 484 import ietf-yang-types { 485 prefix yang; 486 } 488 organization 489 "IETF I2NSF (Interface to Network Security Functions) 490 Working Group"; 492 contact 493 "WG Web: 494 WG List: 496 WG Chair: Adrian Farrel 497 499 WG Chair: Linda Dunbar 500 502 Editor: Jaehoon Paul Jeong 503 "; 505 description 506 "This module defines a YANG data module for consumer-facing 507 interface to security controller."; 508 revision "2016-11-13"{ 509 description "Initial revision"; 510 reference 511 "draft-kumar-i2nsf-client-facing-interface-im-01"; 512 } 514 //Groupings 515 grouping policy { 516 description 517 "policy is a grouping including a set of security rules 518 according to certain logic, i.e., their similarity or mutual 519 relations, etc. The network security policy is able 520 to apply over both the unidirectional and bidirectional 521 traffic across the NSF."; 523 list policy-lifecycle { 524 key "policy-lifecycle-id"; 525 description 526 "The ID of the policy lifecycle for each policy. 527 This must be unique."; 529 leaf policy-lifecycle-id { 530 type uint16; 531 mandatory true; 532 description 533 "This is policy lifecycle-id."; 534 } 536 container expiration-event { 537 description 538 "The event which makes the policy expired."; 540 leaf enabled { 541 type boolean; 542 mandatory true; 543 description 544 "This represents whether the policy is enabled or 545 disabled."; 546 } 548 leaf event-id { 549 type uint16; 550 mandatory true; 551 description 552 "The ID of the event. This must be unique."; 554 } 555 leaf event-date { 556 type yang:date-and-time; 557 mandatory true; 558 description 559 "The date when the event is triggered."; 560 } 561 } 563 container expiration-time { 564 description 565 "The time when the policy is expired."; 567 leaf enabled { 568 type boolean; 569 mandatory true; 570 description 571 "This represents whether the policy is enabled or 572 disabled."; 573 } 575 leaf time { 576 type yang:date-and-time; 577 mandatory true; 578 description 579 "The time when the policy is enabled."; 580 } 581 } 582 } 584 list policy-rule { 585 key "policy-rule-id"; 586 description 587 "The ID of the policy rule. 588 This is key for policy-rule-list. 589 This must be unique."; 591 leaf policy-name { 592 type string; 593 mandatory true; 594 description 595 "The name of the policy. 596 This must be unique."; 597 } 599 leaf policy-rule-id { 600 type uint16; 601 mandatory true; 602 description 603 "The ID of the policy rule. This must be unique."; 604 } 606 leaf policy-rule-date { 607 type yang:date-and-time; 608 mandatory true; 609 description 610 "The date when the date-and-time when the policy is 611 created."; 612 } 614 container service { 615 description 616 "The services which NSFs could perform to manage the 617 security attacks. 618 This consists of voip-handling and volte-handling. 619 This will be extended in later version."; 621 leaf voip-handling { 622 type boolean; 623 mandatory true; 624 description 625 "This field represents whether the policy contains 626 handling the voip packet flow."; 627 } 629 leaf volte-handling { 630 type boolean; 631 mandatory true; 632 description 633 "This field represents whether the policy contains 634 handling the volte packet flow."; 635 } 636 } 638 list condition { 639 key "condition-id"; 640 description 641 "The ID of the condition. This must be unique."; 643 leaf condition-id { 644 type uint16; 645 mandatory true; 646 description 647 "This is condition id"; 648 } 649 container caller { 650 description 651 "The caller of VoIP-VoLTE call"; 653 leaf caller-id { 654 type uint16; 655 mandatory true; 656 description 657 "The ID of the caller. This must be unique."; 658 } 660 container caller-location { 661 description 662 "The location of the caller."; 664 leaf country { 665 type string; 666 mandatory true; 667 description 668 "The country of the caller."; 669 } 671 leaf city { 672 type string; 673 mandatory true; 674 description 675 "The city of the caller."; 676 } 677 } 678 } 680 container callee { 681 description 682 "The callee of VoIP-VoLTE call."; 684 leaf callee-id { 685 type uint16; 686 mandatory true; 687 description 688 "The ID of the callee. This must be unique."; 689 } 691 container callee-location { 692 description 693 "The location of the callee."; 695 leaf country { 696 type string; 697 mandatory true; 698 description 699 "The country of the callee."; 700 } 702 leaf city { 703 type string; 704 mandatory true; 705 description 706 "The city of the callee."; 707 } 708 } 709 } 711 container valid-time-interval { 712 description 713 "The time when the policy starts or ends to be valid."; 715 leaf start-time { 716 type yang:date-and-time; 717 mandatory true; 718 description 719 "The time when the policy starts to be valid."; 720 } 722 leaf end-time { 723 type yang:date-and-time; 724 mandatory true; 725 description 726 "The time when the policy ends to be valid."; 727 } 728 } 729 } 730 } 732 container action { 733 description 734 "TBD"; 736 choice action-type { 737 description 738 "The flow-based NSFs realize the network security 739 functions by executing various Actions, which at least 740 includes ingress-action, egress-action, and 741 advanced-action."; 743 case ingress-action { 744 description 745 "The ingress actions consist of permit, mirror and log."; 747 leaf permit { 748 type boolean; 749 mandatory true; 750 description 751 "Packet flow is permitted or denyed."; 752 } 754 leaf mirror { 755 type boolean; 756 mandatory true; 757 description 758 "Packet flow is mirroried."; 759 } 761 leaf log { 762 type boolean; 763 mandatory true; 764 description 765 "Packet flow is logged."; 766 } 767 } 769 case engress-type { 770 description 771 "The egress action consists of redirection. TBD"; 773 leaf redirection { 774 type boolean; 775 mandatory true; 776 description 777 "Packet flow is redireted."; 778 } 779 } 781 container update { 782 description 783 "The event which makes the policy expired."; 785 leaf update-id { 786 type uint16; 787 mandatory true; 788 description 789 "The policy update-id to distingush each update. 790 This must be unique."; 791 } 793 leaf update-event-id { 794 type uint16; 795 mandatory true; 796 description 797 "The ID of the event. This must be unique."; 798 } 800 leaf update-enabled { 801 type boolean; 802 mandatory true; 803 description 804 "The update is enabled or disabled."; 805 } 806 leaf update-event-date { 807 type yang:date-and-time; 808 mandatory true; 809 description 810 "The date when the update-event is triggered."; 811 } 812 leaf update-log { 813 type boolean; 814 mandatory true; 815 description 816 "To log update and its description"; 817 } 818 } 819 } 820 } 821 } 822 } 824 826 Figure 3: YANG Data Model for VoIP-VoLTE Security Service 828 7. Security Considerations 830 The security management architecture is derived from the I2NSF 831 framework [i2nsf-framework], so the security considerations of the 832 I2NSF framework should be included in this document. Especially, 833 proper secure communication channels should be used for the delivery 834 of control or management messages amongst the components in the 835 proposed architecture. 837 8. Acknowledgements 839 This work was supported by Institute for Information & communications 840 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 841 (No.R-20160222-002755, Cloud based Security Intelligence Technology 842 Development for the Customized Security Service Provisioning). This 843 document has greatly benefited from inputs by Hyoungshick Kim, Hoon 844 Ko, Sanghak Oh, Eunsoo Kim, Jinyong Tim Kim, Daeyoung Hyun, and Se- 845 Hui Lee. 847 9. References 849 9.1. Normative References 851 [RFC3444] Pras, A., "On the Difference between 852 Information Models and Data Models", 853 RFC 3444, January 2003. 855 9.2. Informative References 857 [i2nsf-framework] Lopez, D., Lopez, E., Dunbar, L., Strassner, 858 J., and R. Kumar, "Framework for Interface 859 to Network Security Functions", 860 draft-ietf-i2nsf-framework-04 (work in 861 progress), October 2016. 863 [i2nsf-security-mgnt] Kim, H., Ko, H., Oh, S., Jeong, J., and S. 864 Lee, "An Architecture for Security 865 Management in I2NSF Framework", draft-kim- 866 i2nsf-security-management-architecture-03 867 (work in progress), October 2016. 869 [client-facing-inf-req] Kumar, R., Lohiya, A., Qi, D., Bitar, N., 870 Palislamovic, S., and L. Xia, "Requirements 871 for Client-Facing Interface to Security 872 Controller", draft-ietf-i2nsf-client-facing- 873 interface-req-00 (work in progress), 874 October 2016. 876 [client-facing-inf-im] Kumar, R., Lohiya, A., Qi, D., Bitar, N., 877 Palislamovic, S., and L. Xia, "Information 878 model for Client-Facing Interface to 879 Security Controller", draft-kumar-i2nsf- 880 client-facing-interface-im-01 (work in 881 progress), October 2016. 883 Appendix A. Changes from 884 draft-jeong-i2nsf-consumer-facing-interface-dm-00 886 The following changes are made from 887 draft-jeong-i2nsf-consumer-facing-interface-dm-00: 889 o Miscellaneous expressions in the whole descriptions are corrected. 891 o A YANG data model is clarified to efficiently support VoIP-VoLTE 892 security services. 894 Authors' Addresses 896 Jaehoon Paul Jeong 897 Department of Software 898 Sungkyunkwan University 899 2066 Seobu-Ro, Jangan-Gu 900 Suwon, Gyeonggi-Do 16419 901 Republic of Korea 903 Phone: +82 31 299 4957 904 Fax: +82 31 290 7996 905 EMail: pauljeong@skku.edu 906 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 908 Mahdi Daghmehchi Firoozjaei 909 Department of Electical and Computer Enginering 910 Sungkyunkwan University 911 2066 Seobu-Ro, Jangan-Gu 912 Suwon, Gyeonggi-Do 16419 913 Republic of Korea 915 Phone: +82-31-299-4104 916 EMail: mdaghmechi@skku.edu 918 Tae-Jin Ahn 919 Korea Telecom 920 70 Yuseong-Ro, Yuseong-Gu 921 Daejeon 305-811 922 Republic of Korea 924 Phone: +82 42 870 8409 925 EMail: taejin.ahn@kt.com 926 Rakesh Kumar 927 Juniper Networks 928 1133 Innovation Way 929 Sunnyvale, CA 94089 930 USA 932 Phone: 933 EMail: rkkumar@juniper.net 935 Susan Hares 936 Huawei 937 7453 Hickory Hill 938 Saline, MI 48176 939 USA 941 Phone: +1-734-604-0332 942 EMail: shares@ndzh.com