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