idnits 2.17.1 draft-ietf-i2nsf-consumer-facing-interface-dm-03.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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 29 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 265 has weird spacing: '...le-name str...' == Line 693 has weird spacing: '...address ine...' == Line 721 has weird spacing: '...address ine...' == Line 808 has weird spacing: '...address inet...' -- The document date (March 11, 2019) is 1873 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) == Unused Reference: 'RFC6020' is defined on line 2002, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 2022, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3444 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group J. Jeong 3 Internet-Draft E. Kim 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: September 12, 2019 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 March 11, 2019 13 I2NSF Consumer-Facing Interface YANG Data Model 14 draft-ietf-i2nsf-consumer-facing-interface-dm-03 16 Abstract 18 This document describes an information model and a YANG data model 19 for the Consumer-Facing Interface between an Interface to Network 20 Security Functions (I2NSF) User and Security Controller in an I2NSF 21 system in a Network Functions Virtualization (NFV) environment. The 22 information model defines various managed objects and relationship 23 among these objects needed to build the interface. The information 24 model is organized based on the "Event-condition-Event" (ECA) policy 25 model defined by a capability information model for Interface to 26 Network Security Functions (I2NSF)[draft-ietf-i2nsf-capability], and 27 the data model is defined for enabling different users of a given 28 I2NSF system to define, manage, and monitor security policies for 29 specific flows within an administrative domain. 31 Status of This Memo 33 This Internet-Draft is submitted 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). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 12, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Information Model for Policy . . . . . . . . . . . . . . . . 5 69 4.1. Event Sub-Model . . . . . . . . . . . . . . . . . . . . . 6 70 4.2. Condition Sub-Model . . . . . . . . . . . . . . . . . . . 7 71 4.3. Action Sub-Model . . . . . . . . . . . . . . . . . . . . 9 72 5. Information Model for Multi-Tenancy . . . . . . . . . . . . . 9 73 5.1. Policy-Domain . . . . . . . . . . . . . . . . . . . . . . 10 74 5.2. Policy-Tenant . . . . . . . . . . . . . . . . . . . . . . 11 75 5.3. Policy-Role . . . . . . . . . . . . . . . . . . . . . . . 12 76 5.4. Policy-User . . . . . . . . . . . . . . . . . . . . . . . 12 77 5.5. Policy Management Authentication Method . . . . . . . . . 13 78 6. Information Model for Policy Endpoint Groups . . . . . . . . 14 79 6.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 15 80 6.2. Device-Group . . . . . . . . . . . . . . . . . . . . . . 16 81 6.3. Location-Group . . . . . . . . . . . . . . . . . . . . . 16 82 7. Information Model for Threat Prevention . . . . . . . . . . . 17 83 7.1. Threat-Feed . . . . . . . . . . . . . . . . . . . . . . . 18 84 7.2. Payload-content . . . . . . . . . . . . . . . . . . . . . 19 85 8. Role-Based Acess Control (RBAC) . . . . . . . . . . . . . . . 19 86 9. YANG Data Model for Security Policies for Consumer-Facing 87 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 10. Example XML Output for Various Scenarios . . . . . . . . . . 37 89 10.1. DB registration: Information of positions and devices 90 (Endpoint group) . . . . . . . . . . . . . . . . . . . . 38 91 10.2. Scenario 1: Block SNS access during business hours . . . 38 92 10.3. Scenario 2: Block malicious VoIP/VoLTE packets coming to 93 the company . . . . . . . . . . . . . . . . . . . . . . 40 94 10.4. Scenario 3: Mitigate HTTP and HTTPS flood attacks on a 95 company web Server . . . . . . . . . . . . . . . . . . . 41 97 11. Security Considerations . . . . . . . . . . . . . . . . . . . 43 98 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 100 13.1. Normative References . . . . . . . . . . . . . . . . . . 43 101 13.2. Informative References . . . . . . . . . . . . . . . . . 43 102 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing- 103 interface-dm-02 . . . . . . . . . . . . . . . . . . 46 104 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 46 105 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 47 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 108 1. Introduction 110 In I2NSF framework, each vendor can register their NSFs using the 111 Vendor Management System (VMS). Assuming that vendors also provide 112 the front-end web applications registered with the I2NSF provider, 113 the Consumer-Facing Interface is required because the web 114 applications developed by each vendor need to have a standard 115 interface specifying the data types used when I2NSF user and security 116 controller communicate using this interface. Therefore, this 117 document specifies the required information, their data types, and 118 encoding schemes so that any data (security policy) transferred 119 through the Consumer-Facing Interface can easily be translated by the 120 security controller into low-level security policies. The translated 121 policies are delivered to Network Security Functions (NSFs) according 122 to their respective security capabilities for securiy enforcement. 124 The Consumer-Facing Interface would be built using a set of objects, 125 with each object capturing a unique set of information from Security 126 Admin (i.e., I2NSF User [RFC8329]) needed to express a Security 127 Policy. An object may have relationship with various other objects 128 to express a complete set of requirement. An information model 129 captures the managed objects and relationship among these objects. 130 The information model proposed in this document is structured in 131 accordance with the "Event-Condition-Event" (ECA) policy model. 133 An NSF Capability model is proposed in [draft-ietf-i2nsf-capability] 134 as the basic model for both the NSF-Facing interface and Consumer- 135 Facing Interface security policy model of this document. 137 [RFC3444] explains differences between an information and data model. 138 This document use the guidelines in [RFC3444] to define both the 139 information and data model for Consumer-Facing Interface. Figure 1 140 shows a high-level abstraction of Consumer-Facing Interface. A data 141 model, which represents an implementation of the information model in 142 a specific data representation language, is also defined in the later 143 sections of this document (see section 10). 145 +-----------------+ +-----------------+ 146 | Consumer-facing | | Consumer-facing | 147 | Interface +--->+ Interface | 148 |Information Model| | Data Model | 149 +--------+--------+ +-----------------+ 150 ^ 151 | 152 +-------------+-------------+------------+ 153 | | | | 154 +----+----+ +-----+----+ +-----+----+ +----+----+ 155 | Multi | | Policy | | Endpoint | | Threat | 156 | Tenancy | | | | groups | | feed | 157 +---------+ +-----+----+ +----------+ +---------+ 158 ^ 159 | 160 +------+------+ 161 | Rule | 162 +------+------+ 163 ^ 164 | 165 +----------------+----------------+ 166 | | | 167 +------+------+ +------+------+ +------+------+ 168 | Event | | Condition | | Action | 169 +-------------+ +-------------+ +-------------+ 171 Figure 1: Diagram for High-level Abstraction of Consumer-Facing 172 Interface 174 Data models are defined at a lower level of abstraction and provide 175 many details. They provide details about the implementation of a 176 protocol's specification, e.g., rules that explain how to map managed 177 objects onto lower-level protocol constructs. Since conceptual 178 models can be implemented in different ways, multiple data models can 179 be derived by a single information model. 181 The efficient and flexible provisioning of network functions by NFV 182 leads to a rapid advance in the network industry. As practical 183 applications, network security functions (NSFs), such as firewall, 184 intrusion detection system (IDS)/intrusion protection system (IPS), 185 and attack mitigation, can also be provided as virtual network 186 functions (VNF) in the NFV system. By the efficient virtual 187 technology, these VNFs might be automatically provisioned and 188 dynamically migrated based on real-time security requirements. This 189 document presents a YANG data model to implement security functions 190 based on NFV. 192 2. Requirements Language 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in RFC 2119 [RFC3444] 197 RFC8174 [RFC8174]. 199 3. Terminology 201 This document uses the terminology described in 202 [i2nsf-terminology][client-facing-inf-im][client-facing-inf-req]. 204 This document follows the guidelines of [RFC6087], uses the common 205 YANG types defined in [RFC6991], and adopts the Network Management 206 Datastore Architecture (NMDA). The meaning of the symbols in tree 207 diagrams is defined in [RFC8340]. 209 4. Information Model for Policy 211 A Policy object represents a mechanism to express a Security Policy 212 by Security Admin (i.e., I2NSF User) using Consumer-Facing Interface 213 toward Security Controller; the policy would be enforced on an NSF. 214 Figure 2 shows the XML instance of the Policy object. The Policy 215 object SHALL have following information: 217 Name: This field identifies the name of this object. 219 Date: Date when this object was created or last modified. 221 Rules: This field contains a list of rules. If the rule does not 222 have a user-defined precedence, then any conflict must be 223 manually resolved. 225 +--rw policy 226 +--rw policy-name? string 227 +--rw rule* [rule-name] 228 +--rw event 229 +--rw condition 230 +--rw action 232 Figure 2: Policy YANG Data tree 234 A policy is a container of Rules. In order to express a Rule, a Rule 235 must have complete information such as where and when a policy needs 236 to be applied. This is done by defining a set of managed objects and 237 relationship among them. A Policy Rule may be related segmentation, 238 threat mitigation or telemetry data collection from an NSF in the 239 network, which will be specified as the sub-model of the policy model 240 in the subsequent sections. Figure 3 shows the XML instance of the 241 Rule object. The rule object SHALL have the following information: 243 Name: This field identifies the name of this object. 245 Date: This field indicates the date when this object was created 246 or last modified. 248 Event: This field includes the information to determine whether 249 the Rule Condition can be evaluated or not. See details in 250 Section 3.1. 252 Condition: This field contains all the checking conditions to 253 apply to the objective traffic. See details in 254 Section 4.2. 256 Action: This field identifies the action taken when a rule is 257 matched. There is always an implicit action to drop 258 traffic if no rule is matched for a traffic type. See 259 details in Section 4.3. 261 Owner: This field contains the onwer of the rule. For example, 262 the person who created it, and eligible for modifying it. 264 +--rw rule* [rule-name] 265 +--rw rule-name string 266 +--rw date? yang:date-and-time 267 +--rw event* [name] 268 +--rw condition 269 +--rw action 270 +--rw owner? string 272 Figure 3: YANG Data tree for Rule 274 4.1. Event Sub-Model 276 The Event Object contains information related to scheduling a Rule. 277 The Rule could be activated based on a time calendar or security 278 event including threat level changes. Figure 4 shows the XML 279 instance of the Event object. Event object SHALL have following 280 information: 282 Name: This field identifies the name of this object. 284 Date: This field indicates the date when this object was created 285 or last modified. 287 Event-Type: This field identifies whether the event of triggering 288 policy enforcement is "ADMIN-ENFORCED", "TIME-ENFORCED" or 289 "EVENT-ENFORCED". 291 Time-Information: This field contains a time calendar such as 292 "BEGIN-TIME" and "END-TIME" for one time enforcement or 293 recurring time calendar for periodic enforcement. 295 +--rw event 296 +--rw name? string 297 +--rw date? yang:date-and-time 298 +--rw event-type enumeration 299 +--rw time-information 300 +--rw time 301 | +--rw begin-time begin-time-type 302 | +--rw end-time end-time-type 303 +--rw recursive 304 +--rw recur boolean 305 +--rw recursive-type? enumeration 307 Figure 4: Event sub-model YANG data tree 309 4.2. Condition Sub-Model 311 This object represents Conditions that Security Admin wants to apply 312 the checking on the traffic in order to determine whether the set of 313 actions in the Rule can be executed or not. The condition sub-model 314 consists of 3 different types of three containers each representing 315 different cases, such as general firewall and ddos-mitigation cases, 316 and a case when the condition is based on the payload strings of 317 packets. Each containers have source-target and destination-target 318 to represent the source and destination for each case. Figure 5 319 shows the XML instance of the Condition object.The Condition submodel 320 SHALL have following information: 322 Firewall-condition: This field represents the general firewall 323 case, where a security admin can set up firewall conditions 324 using the information present in this field. The source 325 and destination is represented as source-target and 326 destination-target, each referring to the IP-address-based 327 groups defined in the endpoint-group. 329 DDoS-condition: This field represents the condition for DDoS 330 mitigation, where a security admin can set up DDoS 331 mitigation conditions using the information present in this 332 field. The source and destination is represented as 333 source-target and destination-target, each referring to the 334 device-groups defined and registered in the endpoint-group. 336 Custom-condition: This field contains the payload string 337 information. This information is useful when security rule 338 condition is based on the string contents of incoming or 339 outgoing packets. The source and destination is 340 represented as source-target and destination-target, each 341 referring to the payload-groups defined and registered in 342 the endpoint-group. 344 +--rw condition 345 +--rw firewall-condition 346 | +--rw source-target 347 | | +--rw src-target? -> /policy 348 | | /endpoint-group 349 | | /user-group 350 | | /name 351 | +--rw destination-target 352 | | +--rw dest-target* -> /policy 353 | | /endpoint-group 354 | | /user-group 355 | | /name 356 +--rw ddos-condition 357 | +--rw source-target 358 | | +--rw src-target* -> /policy 359 | | /endpoint-group 360 | | /device-group 361 | | /name 362 | +--rw destination-target 363 | | +--rw dest-target* -> /policy 364 | | /endpoint-group 365 | | /device-group 366 | | /name 367 | +--rw rate-limit 368 | +--rw packet-per-second? uint8 369 +--rw custom-condition 370 | +--rw source-target 371 | | +--rw src-target* -> /policy 372 | | /threat-prevention 373 | | /payload-content 374 | | /name 375 | +--rw destination-target 376 | | +--rw dest-target? -> /policy 377 | | /threat-prevention 378 | | /payload-content 379 | | /name 380 +--rw threat-feed-condition 381 +--rw source-target 382 | +--rw src-target* -> /policy 383 | /threat-prevention 384 | /threat-feed-list 385 | /name 386 +--rw destination-target 387 +--rw dest-target? -> /policy 388 /threat-prevention 389 /threat-feed-list 390 /name 392 Figure 5: Condition sub-model YANG data tree 394 4.3. Action Sub-Model 396 This object represents actions that Security Admin wants to perform 397 based on certain traffic class. Figure 6 shows the XML instance of 398 the Action object. The Action object SHALL have following 399 information: 401 Name: This field identifies the name of this object. 403 Date: This field indicates the date when this object was created 404 or last modified. 406 Action: This field identifies the action when a rule is matched 407 by an NSF. The action could be one of "PASS", "DROP", 408 "ALERT", "MIRROR", and "LOG". 410 +--rw action 411 +--rw name string 412 +--rw date yang:date-and-time 413 +--rw action string 415 Figure 6: Action sub-model YANG data tree 417 5. Information Model for Multi-Tenancy 419 Multi-tenancy is an important aspect of any application that enables 420 multiple administrative domains in order to manage application 421 resources. An Enterprise organization may have multiple tenants or 422 departments such as Human Resources (HR), Finance, and Legal, with 423 each tenant having a need to manage their own Security Policies. In 424 a Service Provider, a tenant could represent a Customer that wants to 425 manage its own Security Policies. There are multiple managed objects 426 that constitute multi-tenancy aspects as shown in Figure 7. This 427 section lists these objects and any relationship among these objects. 428 Below diagram shows an example of multi-tenancy in an Enterprise 429 domain. 431 +-------------------+ 432 (Multi-Tenancy) | Domain | 433 |(e.g., Enterprise) | 434 +---------+---------+ 435 ^ 436 | 437 +--------------------+--------------------+ 438 | | | 439 +--------+-------+ +---------+--------+ +--------+--------+ 440 | Department 1 | | Department 2 | | Department n | 441 +--------+-------+ +---------+--------+ +--------+--------+ 442 ^ ^ ^ 443 | | | 444 +--------+--------+ +-----------------+ +--------+--------+ 445 | Sub-domain 1..n | | Sub-domain 1..n | | Sub-domain 1..n | 446 +--------+--------+ +--------+--------+ +--------+--------+ 447 ^ ^ ^ 448 | | | 449 +--------+--------+ +--------+--------+ +--------+--------+ 450 | Tenant 1..n | | Tenant 1..n | | Tenant 1..n | 451 +-----------------+ +-----------------+ +-----------------+ 453 Figure 7: Multi-tenancy Diagram 455 5.1. Policy-Domain 457 This object defines a boundary for the purpose of policy management 458 within a Security Controller. This may vary based on how the 459 Security Controller is deployed and hosted. For example, if an 460 Enterprise hosts a Security Controller in their network; the domain 461 in this case could just be the one that represents that Enterprise. 462 But if a Cloud Service Provider hosts managed services, then a domain 463 could represent a single customer of that Provider. Figure 8 shows 464 the XML instance of the Policy-domain object. Multi-tenancy model 465 should be able to work in all such environments. The Policy-Domain 466 object SHALL have following information: 468 Name: Name of the organization or customer representing this 469 domain. 471 Address: Address of the organization or customer. 473 Contact: Contact information of the organization or customer. 475 Date: Date when this account was created or last modified. 477 Authentication-Method: Authentication method to be used for this 478 domain. It should be a reference to a "Policy-Management- 479 Authentication-Method" object. 481 +--rw policy-domain* [name] 482 +--rw name string 483 +--rw date? yang:date-and-time 484 +--rw address? string 485 +--rw contact? string 486 +--rw policy-tenant* [name] 487 +--rw authentication-method? -> /policy 488 /multi-tenancy 489 /policy-mgnt-auth-method 490 /name 491 ... 492 ... 494 Figure 8: Policy domain YANG data tree 496 5.2. Policy-Tenant 498 This object defines an entity within an organization. The entity 499 could be a department or business unit within an Enterprise 500 organization that would like to manage its own Policies due to 501 regulatory compliance or business reasons. Figure 9 shows the XML 502 instance of the Policy-tenant object. The Policy-Tenant object SHALL 503 have following information: 505 Name: Name of the Department or Division within an organization. 507 Date: Date when this account was created or last modified. 509 Domain: This field identifies the domain to which this tenant 510 belongs. This should be a reference to a Policy-Domain 511 object. 513 +--rw policy-tenant* [name] 514 +--rw name string 515 +--rw date? yang:date-and-time 516 +--rw domain? -> /policy 517 /multi-tenancy 518 /policy-domain 519 /name 521 Figure 9: Policy tenant YANG data tree 523 5.3. Policy-Role 525 This object defines a set of permissions assigned to a user in an 526 organization that wants to manage its own Security Policies. It 527 provides a convenient way to assign policy users to a job function or 528 a set of permissions within the organization. Figure 10 shows the 529 XML instance of the Policy-role object. The Policy-Role object SHALL 530 have the following information: 532 Name: This field identifies the name of the role. 534 Date: Date when this role was created or last modified. 536 Access-Profile: This field identifies the access profile for the 537 role. The profile grants or denies the permissions to 538 access Endpoint Groups for the purpose of policy management 539 or may restrict certain operations related to policy 540 managements. There are two permission types, read-only and 541 read-and-write, to choose from for each access-profile. 543 +--rw policy-role 544 | +--rw name? string 545 | +--rw date? yang:date-and-time 546 | +--rw access-profile* [name] 547 | +--rw name string 548 | +--rw date? yang:date-and-time 549 | +--rw permission-type? identityref 551 Figure 10: Policy role YANG data tree 553 5.4. Policy-User 555 This object represents a unique identity of a user within an 556 organization. The identity authenticates with Security Controller 557 using credentials such as a password or token in order to perform 558 policy management. A user may be an individual, system, or 559 application requiring access to Security Controller. Figure 11 shows 560 the XML instance of the Policy-user object. The Policy-User object 561 SHALL have the following information: 563 Name: Name of a user. 565 Date: Date when this user was created or last modified. 567 Password: User password for basic authentication. 569 Email: E-mail address of the user. 571 Scope-Type: This field identifies whether the user has domain- 572 wide or tenant-wide privileges. 574 Role: This field should be a reference to a Policy-Role object 575 that defines the specific permissions. 577 +--rw policy-user* [name] 578 | +--rw name string 579 | +--rw date? yang:date-and-time 580 | +--rw password? string 581 | +--rw email? string 582 | +--rw scope-type? identityref 583 | +--rw role? -> /policy 584 /multi-tenancy 585 /policy-role 586 /access-profile 587 /name 589 Figure 11: Policy user YANG data tree 591 5.5. Policy Management Authentication Method 593 This object represents authentication schemes supported by Security 594 Controller. Figure 12 shows the XML instance of the Policy 595 Management Authentication Method onject. This Policy-Management- 596 Authentication-Method object SHALL have the following information: 598 Name: This field identifies name of this object. 600 Date: Date when this object was created or last modified. 602 Authentication-Method: This field identifies the authentication 603 methods. It could be a password-based, token-based, 604 certificate-based or single sign-on authentication. 606 Mutual-Authentication: This field indicates whether mutual 607 authentication is mandatory or not. 609 Token-Server: This field stores the information about server that 610 validates the token submitted as credentials. 612 Certificate-Server: This field stores the information about 613 server that validates certificates submitted as 614 credentials. 616 Single Sign-on-Server: This field stores the information about 617 server that validates user credentials. 619 +--rw policy-mgnt-auth-method* [name] 620 +--rw name string 621 +--rw date? yang:date-and-time 622 +--rw mutual-authentication? boolean 623 +--rw password 624 | +--rw password? password-type 625 +--rw token 626 | +--rw token? string 627 | +--rw token-server? inet:ipv4-address 628 +--rw certificate 629 | +--rw certificate? certificate-type 630 | +--rw certificate-server? inet:ipv4-address 631 +--rw single-sign-on 632 +--rw credential? certificate-type 633 +--rw certificate-server? inet:ipv4-address 635 Figure 12: Policy management authentication method YANG data tree 637 6. Information Model for Policy Endpoint Groups 639 The Policy Endpoint Group is a very important part of building User- 640 construct based policies. Security Admin would create and use these 641 objects to represent a logical entity in their business environment, 642 where a Security Policy is to be applied. There are multiple managed 643 objects that constitute a Policy Endpoint Group as shown in 644 Figure 13. Figure 14 shows the XML instance of the endpoint-group 645 object. shows the XML instance of the User-group object.. This 646 section lists these objects and relationship among them. 648 +-------------------+ 649 | Endpoint Group | 650 +---------+---------+ 651 ^ 652 | 653 +--------------+----------------+ 654 1..n | 1..n | 1..n | 655 +-----+----+ +------+-----+ +-------+------+ 656 |User-group| |Device-group| |Location-group| 657 +----------+ +------------+ +--------------+ 659 Figure 13: Endpoint Group Diagram 661 +--rw endpoint-group 662 +--rw user-group* [name] 663 | ... 664 +--rw device-group* [name] 665 | ... 666 +--rw location-group* [name] 667 ... 669 Figure 14: Endpoint Group YANG data tree 671 6.1. User Group 673 This object represents a User-group. Figure 15 shows the XML 674 instance of the User-group object.The User-Group object SHALL have 675 the following information: 677 Name: This field identifies the name of this object. 679 Date: Date when this object was created or last modified. 681 IP-Address: This field identifies the IP address of a user. 683 Range-IP-Address: This field is a range of IP addresses of users. 685 +--rw user-group* [name] 686 +--rw name string 687 +--rw date? yang:date-and-time 688 +--rw (match-type)? 689 +--:(exact-match) 690 | +--rw ip-address* inet:ipv4-address 691 +--:(range-match) 692 +--rw range-ip-address* [start-ip-address end-ip-address] 693 +--rw start-ip-address inet:ipv4-address 694 +--rw end-ip-address inet:ip-address 696 Figure 15: User group YANG data tree 698 6.2. Device-Group 700 This object represents a Device-group. Figure 16 shows the XML 701 instance of the Device-group object.The Device-Group object SHALL 702 have the following information: 704 Name: This field identifies the name of this object. 706 Date: Date when this object was created or last modified. 708 IP-Address: This field identifies the IP address of a device. 710 Range-IP-Address: This field is a range of IP addresses of 711 devices. 713 +--rw device-group* [name] 714 +--rw name string 715 +--rw date? yang:date-and-time 716 +--rw (match-type)? 717 +--:(exact-match) 718 | +--rw ip-address* inet:ipv4-address 719 +--:(range-match) 720 +--rw range-ip-address* [start-ip-address end-ip-address] 721 +--rw start-ip-address inet:ipv4-address 722 +--rw end-ip-address inet:ip-address 724 Figure 16: Device group YANG data tree 726 6.3. Location-Group 728 This object represents a location group based on either tag or other 729 information. Figure 17 shows the XML instance of the Location-group 730 object. The Location-group object SHALL have the following 731 information: 733 Name: This field identifies the name of this object. 735 Date: Date when this object was created or last modified. 737 continent: to identify which continent the location group member 738 is based at. 740 +--rw location-group* [name] 741 +--rw name string 742 +--rw date? yang:date-and-time 743 +--rw continent? identityref 745 Figure 17: Location group YANG data tree 747 7. Information Model for Threat Prevention 749 The threat prevention plays an important part in the overall security 750 posture by reducing the attack surfaces. This information could come 751 from various threat feeds (i.e., sources for obtaining the threat 752 information), such as EmergingThreats.com or AlienVault.com. There 753 are multiple managed objects that constitute this category. This 754 section lists these objects and relationship among them. Figure 19 755 shows the XML instance of a Threat-prevention object. 757 +-------------------+ 758 | Threat Prevention | 759 +---------+---------+ 760 ^ 761 | 762 +---------+---------+ 763 1..n | 1..n | 764 +------+------+ +--------+--------+ 765 | Threat-feed | | payload-content | 766 +-------------+ +-----------------+ 768 Figure 18: Threat Prevention Diagram 770 +--rw threat-prevention 771 | +--rw threat-feed-list* [name] 772 | ... 773 | +--rw payload-content* [name] 774 | ... 776 Figure 19: Threat Prevention YANG data tree 778 7.1. Threat-Feed 780 This object represents a threat feed which provides signatures of 781 malicious activities. Figure 20 shows the XML instance of a Threat- 782 feed-list. The Threat-Feed object SHALL have the following 783 information: 785 Name: This field identifies the name of this object. 787 Date: Date when this object was created or last modified. 789 Threat-feed-Server: This field identifies the information about 790 the feed provider, it may be an external service or local 791 server. 793 Threat-file-types: This field identifies the information about 794 the file types identified and reported by the threat-feed. 796 signatures: This field contains the signatures of malicious 797 programs or activities provided by the threat-feed. 799 +--rw threat-feed-list* [name] 800 +--rw name string 801 +--rw date? yang:date-and-time 802 +--rw threat-feed-server 803 | +--rw (match-type)? 804 | | +--:(exact-match) 805 | | | +--rw ip-address* inet:ipv4-address 806 | | +--:(range-match) 807 | | +--rw range-ip-address* [start-ip-address end-ip-address] 808 | | +--rw start-ip-address inet:ipv4-address 809 | | +--rw end-ip-address inet:ip-address 810 | +--rw threat-feed-description? string 811 +--rw threat-file-types* identityref 812 +--rw signatures* string 814 Figure 20: Threat feed YANG data tree 816 7.2. Payload-content 818 This object represents a custom list created for the purpose of 819 defining exception to threat feeds. Figure 21 shows the XML instance 820 of a Payload-content list. The Payload-content object SHALL have the 821 following information: 823 Name: This field identifies the name of this object. 825 Date: Date when this object was created or last modified. 827 List-Content: This field contains contents such as IP addresses 828 or URL names. 830 +--rw payload-content* [name] 831 | +--rw name string 832 | +--rw date? yang:date-and-time 833 | +--rw content* string 835 Figure 21: Payload-content in YANG data tree 837 8. Role-Based Acess Control (RBAC) 839 Role-Based Access Control (RBAC) provides a powerful and centralized 840 control within a network. It is a policy neutral access control 841 mechanism defined around roles and privileges. The components of 842 RBAC, such as role-permissions, user-role and role-role 843 relationships, make it simple to perform user assignments. 845 +--------------+ 846 | | 847 | User 1 + (has many) 848 | |\ 849 +--------------+ \ +---------------+ +-------------+ 850 . \ | | (has many) | | 851 . --->+ List of roles +----------->+ Permissions | 852 +--------------+ / | | | | 853 | | / +---------------+ +-------------+ 854 | User n +/ 855 | | (has many) 856 +--------------+ 858 Figure 22: RBAC Diagram 860 As shown in Figure 22, a role represents a collection of permissions 861 (e.g., accessing a file server or other particular resources). A 862 role may be assigned to one or multiple users. Both roles and 863 permissions can be organized in a hirarchy. A role may consists of 864 other roles and permissions. 866 Following are the steps required to build RBAC: 868 1. Defining roles and permissions. 870 2. Establishing relations among roles and permissions. 872 3. Defining users. 874 4. Associating rules with roles and permissions. 876 5. assigning roles to users. 878 9. YANG Data Model for Security Policies for Consumer-Facing Interface 880 The main objective of this data model is to fully transform the 881 information model [client-facing-inf-im] into a YANG data model that 882 can be used for delivering control and management messages via the 883 Consumer-Facing Interface between an I2NSF User and Security 884 Controller for the I2NSF User's high-level security policies. 886 The semantics of the data model must be aligned with the information 887 model of the Consumer-Facing Interface. The transformation of the 888 information model was performed so that this YANG data model can 889 facilitate the efficient delivery of the control or management 890 messages. 892 This data model is designed to support the I2NSF framework that can 893 be extended according to the security needs. In other words, the 894 model design is independent of the content and meaning of specific 895 policies as well as the implementation approach. This document 896 suggests a VoIP/VoLTE security service as a use case for policy rule 897 generation. 899 This section describes a YANG data model for Consumer-Facing 900 Interface, based on the information model of Consumer-Facing 901 Interface to security controller [client-facing-inf-im]. 903 file "ietf-cfi-policy.yang" 904 module ietf-i2nsf-cfi-policy { 905 yang-version 1.1; 906 namespace 907 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; 908 prefix 909 cfi-policy; 911 import ietf-yang-types{ 912 prefix yang; 913 reference 914 "Section 3 of RFC 6991"; 915 } 917 import ietf-inet-types{ 918 prefix inet; 919 reference 920 "Section 4 of RFC 6991"; 921 } 923 organization 924 "IETF I2NSF (Interface to Network Security Functions) 925 Working Group"; 927 contact 928 "WG Web: 929 WG List: 931 WG Chair: Adrian Farrel 932 934 WG Chair: Linda Dunbar 935 937 Editor: Jaehoon Paul Jeong 938 "; 940 description 941 "This module is a YANG module for Consumer-Facing Interface. 942 Copyright (c) 2018 IETF Trust and the persons identified as 943 authors of the code. All rights reserved. 944 Redistribution and use in source and binary forms, with or 945 without modification, is permitted pursuant to, and subject 946 to the license terms contained in, the Simplified BSD License 947 set forth in Section 4.c of the IETF Trust's Legal Provisions 948 Relating to IETF Documents 949 (http://trustee.ietf.org/license-info). 950 This version of this YANG module is part of RFC XXXX; see 951 the RFC itself for full legal notices."; 953 revision "2019-03-11"{ 954 description "latest revision"; 955 reference 956 "draft-ietf-consumer-facing-interface-dm-02"; 957 } 958 identity permission-type { 959 description 960 "Base identity for the permission types."; 961 } 963 identity read-only { 964 base permission-type; 965 description 966 "Identity for read-only permission."; 967 } 968 identity read-and-write { 969 base permission-type; 970 description 971 "Identity for read permission."; 972 } 974 identity scope-type { 975 description 976 "Base Identity for scope-type."; 977 } 978 identity tenant-wide { 979 base scope-type; 980 description 981 "Base Identity for tenant-wide scope type."; 982 } 983 identity domain-wide { 984 base scope-type; 985 description 986 "Base Identity for domain-wide scope type."; 987 } 989 identity malware-file-type { 990 description 991 "Base identity for malware file types."; 992 } 993 identity executable-file { 994 base malware-file-type; 995 description 996 "Identity for executable file types."; 997 } 998 identity doc-file { 999 base malware-file-type; 1000 description 1001 "Identity for Microsoft document file types."; 1002 } 1003 identity html-app-file { 1004 base malware-file-type; 1005 description 1006 "Identity for html application file types."; 1007 } 1008 identity javascript-file { 1009 base malware-file-type; 1010 description 1011 "Identity for Javascript file types."; 1012 } 1013 identity pdf-file { 1014 base malware-file-type; 1015 description 1016 "Identity for pdf file types."; 1017 } 1018 identity dll-file { 1019 base malware-file-type; 1020 description 1021 "Identity for dll file types."; 1022 } 1023 identity msi-file { 1024 base malware-file-type; 1025 description 1026 "Identity for Microsoft installer file types."; 1027 } 1029 identity security-event-type { 1030 description 1031 "Base identity for security event types."; 1032 } 1033 identity ddos { 1034 base malware-file-type; 1035 description 1036 "Identity for DDoS event types."; 1037 } 1038 identity spyware { 1039 base malware-file-type; 1040 description 1041 "Identity for spyware event types."; 1042 } 1043 identity trojan { 1044 base malware-file-type; 1045 description 1046 "Identity for Trojan infection event types."; 1047 } 1048 identity ransomeware { 1049 base malware-file-type; 1050 description 1051 "Identity for ransomeware infection event types."; 1052 } 1053 identity continent { 1054 description 1055 "Base Identity for continent types."; 1056 } 1058 identity africa { 1059 base continent; 1060 description 1061 "Identity for africa."; 1062 } 1063 identity asia { 1064 base continent; 1065 description 1066 "Identity for asia."; 1067 } 1068 identity europe { 1069 base continent; 1070 description 1071 "Identity for europe."; 1072 } 1073 identity north-america { 1074 base continent; 1075 description 1076 "Identity for north-america."; 1077 } 1078 identity south-america { 1079 base continent; 1080 description 1081 "Identity for south-america."; 1082 } 1083 identity oceania { 1084 base continent; 1085 description 1086 "Identity for Oceania"; 1087 } 1088 typedef certificate-type { 1090 type enumeration { 1091 enum cer { 1092 description 1093 "The extension type is '.cer'."; 1094 } 1095 enum crt { 1096 description 1097 "The extension type is '.crt'."; 1098 } 1099 enum key { 1100 description 1101 "The extension type is '.key'."; 1102 } 1103 } 1104 description 1105 "CRT certificate extension, which is used for certificates. 1106 The certificates may be encoded as binary DER or as ASCII PEM. 1107 The CER and CRT extensions are nearly synonymous. Most common 1108 among *nix systems. CER certificate extension, which is an 1109 alternate form of .crt (Microsoft Convention) You can use MS to 1110 convert .crt to .cer (.both DER encoded .cer, or base64[PEM] 1111 encoded .cer). The KEY extension is used both for public and 1112 private PKCS#8 keys. The keys may be encoded as binary DER or 1113 as ASCII PEM."; 1114 } 1116 grouping meta { 1117 description 1118 "The purpose of this grouping is to avoid repetition of same fields, such as 'name' and 'date'."; 1119 leaf name { 1120 type string; 1121 description "This is the name for an entity."; 1122 } 1123 leaf date { 1124 type yang:date-and-time; 1125 description "This is the date when the entity is created or modified."; 1126 } 1127 } 1129 grouping ip-address { 1130 description 1131 "There are two types to configure a security policy 1132 for IPv4 address, such as exact match and range match."; 1133 choice match-type { 1134 description 1135 "User can choose between 'exact match' and 'range match'."; 1136 case exact-match { 1137 leaf-list ip-address { 1138 type inet:ipv4-address; 1139 description 1140 "Exactly matches the IP address specified."; 1141 } 1142 } 1143 case range-match { 1144 list range-ip-address { 1145 key "start-ip-address end-ip-address"; 1146 leaf start-ip-address { 1147 type inet:ipv4-address; 1148 description 1149 "Start IP address for a range match."; 1150 } 1151 leaf end-ip-address { 1152 type inet:ip-address; 1153 description 1154 "End IP address for a range match."; 1155 } 1156 description 1157 "Range match for an IP-address."; 1158 } 1159 } 1160 } 1161 } 1163 grouping user-group { 1164 description 1165 "This grouping is to remove repetition of 1166 'name' and 'ip-address' fields."; 1167 uses meta; 1168 uses ip-address; 1169 } 1171 grouping device-group { 1172 description 1173 "This grouping is to remove repetition of 1174 'name', 'ip-address', and 'protocol' fields."; 1175 uses meta; 1176 uses ip-address; 1177 leaf-list protocol { 1178 type string; 1179 description 1180 "This represents the port numbers of devices."; 1181 } 1182 } 1184 grouping location-group { 1185 description 1186 "This grouping is to remove repetition of 1187 'name' and 'continent' fields."; 1188 uses meta; 1189 leaf continent { 1190 type identityref { 1191 base continent; 1192 } 1193 description 1194 "location-group-based on geo-ip of 1195 respective continent."; 1196 } 1198 } 1200 grouping payload-string { 1201 description 1202 "This grouping is to remove repetition of 1203 'name' and 'content' fields."; 1204 uses meta; 1205 leaf-list content { 1206 type string; 1207 description 1208 "This represents the payload string content."; 1209 } 1210 } 1212 container policy { 1213 leaf policy-name { 1214 type string; 1215 description 1216 "The name which identifies the policy."; 1217 } 1218 description 1219 "There can be a multiple number of security rules in 1220 a policy object. This object is a policy instance to 1221 have complete information such as where and when a 1222 policy need to be applied."; 1224 list rule { 1225 leaf rule-name { 1226 type string; 1227 mandatory true; 1228 description 1229 "This represents the name for rules."; 1230 } 1231 key "rule-name"; 1232 description 1233 "There can be a single or multiple number of rules."; 1235 leaf date { 1236 type yang:date-and-time; 1237 description 1238 "Date this object was created or last 1239 modified"; 1240 } 1241 list event { 1242 uses meta; 1243 key "name"; 1244 description 1245 "This represents the event map group name."; 1247 leaf security-event { 1248 type identityref { 1249 base security-event-type; 1250 } 1251 description 1252 "This contains the description of security events."; 1253 } 1254 leaf enforce-type { 1255 type enumeration{ 1256 enum admin-enforced { 1257 description 1258 "The enforcement type is admin-enforced."; 1259 } 1260 enum time-enforced { 1261 description 1262 "The enforcement type is time-enforced."; 1263 } 1264 enum event-enforced { 1265 description 1266 "The enforcement type is event-enforced."; 1267 } 1268 } 1269 description 1270 "This field identifies the event of 1271 policy enforcement trigger type."; 1272 } 1273 container time-information { 1274 description 1275 "The container for time-information."; 1276 leaf begin-time { 1277 type string; 1278 description 1279 "This is start time for time zone"; 1280 } 1281 leaf end-time { 1282 type string; 1283 description 1284 "This is end time for time zone"; 1285 } 1286 } 1287 container recursive { 1288 description 1289 "The container to represent the recursiveness 1290 of the rule."; 1291 leaf recur { 1292 type boolean; 1293 description 1294 "recursive enforcement"; 1296 } 1297 leaf recursive-type{ 1298 type enumeration{ 1299 enum daily { 1300 description 1301 "The recursive type is daily."; 1302 } 1303 enum weekly { 1304 description 1305 "The recursive type is weekly."; 1306 } 1307 enum monthly { 1308 description 1309 "The recursive type is monthly."; 1310 } 1311 } 1312 description 1313 "This leaf identifies the recursive type."; 1314 } 1315 } 1316 } 1317 container condition { 1318 description 1319 "The conditions for general security policies."; 1320 container firewall-condition { 1321 description 1322 "The general firewall condition."; 1323 container source-target { 1324 description 1325 "This represents the source."; 1326 leaf src-target { 1327 type leafref { 1328 path "/policy/endpoint-group/user-group/name"; 1329 } 1330 description 1331 "This describes the paths to 1332 the source reference."; 1333 } 1334 } 1335 container destination-target { 1336 description 1337 "This represents the destination."; 1338 leaf-list dest-target { 1339 type leafref { 1340 path "/policy/endpoint-group/user-group/name"; 1341 } 1342 description 1343 "This describes the paths to the 1344 destination target reference."; 1345 } 1346 } 1347 } 1348 container ddos-condition { 1349 description 1350 "The condition for DDoS mitigation."; 1351 container source-target { 1352 description 1353 "This represents the source."; 1354 leaf-list src-target { 1355 type leafref { 1356 path "/policy/endpoint-group/device-group/name"; 1357 } 1358 description 1359 "This describes the path to the 1360 source target references."; 1361 } 1362 } 1363 container destination-target { 1364 description 1365 "This represents the target."; 1366 leaf-list dest-target { 1367 type leafref { 1368 path "/policy/endpoint-group/device-group/name"; 1369 } 1370 description 1371 "This describes the path to the 1372 destination target references."; 1373 } 1374 } 1375 container rate-limit { 1376 description "This describes the rate-limit."; 1377 leaf packet-per-second { 1378 type uint8; 1379 description 1380 "The rate-limit limits the amount of incoming packets."; 1381 } 1382 } 1383 } 1384 container custom-condition { 1385 description 1386 "The condition based on packet contents."; 1387 container source-target { 1388 description 1389 "This represents the source."; 1390 leaf-list src-target { 1391 type leafref { 1392 path "/policy/threat-prevention/payload-content/name"; 1393 } 1394 description 1395 "Describes the payload string 1396 content condition source."; 1397 } 1398 } 1399 container destination-target { 1400 description 1401 "This represents the destination."; 1402 leaf dest-target { 1403 type leafref { 1404 path "/policy/threat-prevention/payload-content/name"; 1405 } 1406 description 1407 "Describes the payload string 1408 content condition destination."; 1409 } 1410 } 1411 } 1412 container threat-feed-condition { 1413 description 1414 "The condition based on the threat-feed information."; 1415 container source-target { 1416 description 1417 "This represents the source."; 1418 leaf-list src-target { 1419 type leafref { 1420 path "/policy/threat-prevention/threat-feed-list/name"; 1421 } 1422 description "Describes the threat-feed 1423 condition source."; 1424 } 1425 } 1426 container destination-target { 1427 description 1428 "This represents the destination."; 1429 leaf dest-target { 1430 type leafref { 1431 path "/policy/threat-prevention/threat-feed-list/name"; 1432 } 1433 description "Describes the threat-feed 1434 condition destination."; 1435 } 1436 } 1437 } 1438 } 1439 container action { 1440 description 1441 "This is the action container."; 1442 leaf primary-action { 1443 type string; 1444 mandatory true; 1445 description 1446 "This field identifies the action when a rule 1447 is matched by NSF. The action could be one of 1448 'PERMIT', 'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS', 1449 'AUTHENTICATE-SESSION', 'IPS, 'APP-FIREWALL', etc."; 1450 } 1451 leaf secondary-action { 1452 type string; 1453 description 1454 "This field identifies additional actions if 1455 a rule is matched. This could be one of 'LOG', 1456 'SYSLOG', 'SESSION-LOG', etc."; 1457 } 1458 } 1459 leaf owner { 1460 type string; 1461 description 1462 "This field defines the owner of this 1463 policy. Only the owner is authorized to 1464 modify the contents of the policy."; 1465 } 1466 } 1468 container multi-tenancy { 1469 description 1470 "The multi-tenant environment information 1471 in which the policy is applied. The Rules 1472 in the Policy can refer to sub-objects 1473 (e.g., domain, tenant, role, and user) of it."; 1475 list policy-domain { 1476 uses meta; 1477 key "name"; 1478 leaf address { 1479 type string; 1480 description 1481 "The address details of the organization 1482 or customer."; 1483 } 1484 leaf contact { 1485 type string; 1486 description 1487 "contact information of the organization 1488 or customer."; 1489 } 1490 list policy-tenant { 1491 uses meta; 1492 key "name"; 1493 description 1494 "This represents the list of tenants"; 1495 leaf domain { 1496 type leafref { 1497 path "/policy/multi-tenancy/policy-domain/name"; 1498 } 1499 description 1500 "This field identifies the domain to which this 1501 tenant belongs. This should be reference to a 1502 'Policy-Domain' object."; 1503 } 1504 } 1505 leaf authentication-method { 1506 type leafref { 1507 path "/policy/multi-tenancy/policy-mgnt-auth-method/name"; 1508 } 1509 description 1510 "Authentication method to be used for this domain. 1511 It should be a reference to a 'policy-mgmt-auth-method' 1512 object."; 1513 } 1514 description 1515 "This represents the list of policy domains."; 1516 } 1517 container policy-role { 1518 uses meta; 1519 description 1520 "This represents the list of policy roles."; 1521 list access-profile { 1522 uses meta; 1523 key "name"; 1524 description 1525 "This field identifies the access profile for the 1526 role. The profile grants or denies access to policy 1527 objects."; 1528 leaf permission-type { 1529 type identityref { 1530 base permission-type; 1531 } 1532 default read-only; 1533 description 1534 "Permission type for access-profile: read-only 1535 or read-and-write."; 1537 } 1538 } 1539 } 1540 list policy-user { 1541 uses meta; 1542 key "name"; 1543 description 1544 "This represents the policy users."; 1545 leaf password { 1546 type string; 1547 description 1548 "User password for basic authentication"; 1549 } 1550 leaf email { 1551 type string; 1552 description 1553 "The email account of a user"; 1554 } 1555 leaf scope-type { 1556 type identityref { 1557 base scope-type; 1558 } 1559 default tenant-wide; 1560 description 1561 "identifies whether a user has domain-wide 1562 or tenant-wide privileges"; 1563 } 1564 leaf role { 1565 type leafref { 1566 path "/policy/multi-tenancy/policy-role/access-profile/name"; 1567 } 1568 description 1569 "This represents the reference to the 1570 access-profiles."; 1571 } 1572 } 1573 list policy-mgnt-auth-method { 1574 uses meta; 1575 key "name"; 1576 leaf mutual-authentication { 1577 type boolean; 1578 description 1579 "To identify whether the authentication 1580 is mutual."; 1581 } 1582 container password { 1583 leaf password { 1584 type string; 1585 description 1586 "This should be defined using the 1587 regular expression."; 1588 } 1589 description 1590 "This represents the password method."; 1591 } 1592 container token { 1593 leaf token { 1594 type string; 1595 description 1596 "This should be defined according to 1597 the token scheme."; 1598 } 1599 description 1600 "This represents the token method."; 1601 leaf token-server { 1602 type inet:ipv4-address; 1603 description 1604 "The token-server information if the 1605 authentication method is token-based"; 1606 } 1607 } 1608 container certificate { 1609 description 1610 "This represents the certificate method."; 1611 leaf certificate { 1612 type certificate-type; 1613 description 1614 "This represents the certificate-type."; 1615 } 1616 leaf certificate-server { 1617 type inet:ipv4-address; 1618 description 1619 "The certificate-server information if 1620 the authentication method is 1621 certificate-based"; 1622 } 1623 } 1624 container single-sign-on { 1625 description 1626 "This represents the authentication method 1627 for single-sing-on."; 1628 leaf credential { 1629 type certificate-type; 1630 description 1631 "This represents the authentication 1632 using user credentials."; 1634 } 1635 leaf certificate-server { 1636 type inet:ipv4-address; 1637 description 1638 "The certificate-server information if 1639 the authentication method is 1640 certificate-based"; 1641 } 1642 } 1643 description 1644 "This represents the policy managegement method."; 1645 } 1646 } 1647 container endpoint-group { 1648 description 1649 "A logical entity in their business 1650 environment, where a security policy 1651 is to be applied."; 1652 list user-group { 1653 uses user-group; 1654 key "name"; 1655 description 1656 "This represents the user group."; 1657 } 1658 list device-group { 1659 uses device-group; 1660 key "name"; 1661 description 1662 "This represents the device group."; 1663 } 1664 list location-group{ 1665 uses location-group; 1666 key "name"; 1667 description 1668 "This represents the location group."; 1669 } 1671 } 1672 container threat-prevention { 1673 description 1674 "this describes the list of threat-prevention."; 1675 list threat-feed-list { 1676 uses meta; 1677 key "name"; 1678 description 1679 "This represents the threat feed list."; 1680 container threat-feed-server { 1681 uses ip-address; 1682 description 1683 "This describes the threat-feed server."; 1684 leaf threat-feed-description { 1685 type string; 1686 description 1687 "This object containes threat-feed 1688 description."; 1689 } 1690 } 1691 leaf-list threat-file-types { 1692 type identityref { 1693 base malware-file-type; 1694 } 1695 default executable-file; 1696 description 1697 "This contains a list of file types needed to 1698 be scanned for the virus."; 1699 } 1700 leaf-list signatures { 1701 type string; 1702 description 1703 "This contains a list of signatures or hash 1704 of the threats."; 1705 } 1706 } 1707 list payload-content { 1708 uses payload-string; 1709 key "name"; 1710 description 1711 "This represents the payload-string group."; 1712 } 1713 } 1714 } 1715 } 1716 1718 Figure 23: YANG for policy-general 1720 10. Example XML Output for Various Scenarios 1722 This section describes the XML instances for different policies 1723 examples that are delivered through Consumer-Facing Interface. The 1724 considered use cases are: VoIP/VoLTE security service, DDoS-attack 1725 mitigation, time-based firewall as a web-filter. 1727 10.1. DB registration: Information of positions and devices (Endpoint 1728 group) 1730 In order to create a rule of a security policy, it is essential to 1731 first register data (those which are used to form such rule) to the 1732 database. For example, The endpoint group consists of three 1733 different groups: user-group, device-group, and payload-group. Each 1734 of these groups have separate group members with information other 1735 than meta ("name" or "date"), such as ip-addresses or protocols used 1736 by devices. Figure 24 shows an example XML representation of the 1737 registered information for the user-group and device-group. 1739 1740 1741 1742 employees 1743 1744 221.159.112.1 1745 221.159.112.90 1746 1747 1748 1749 webservers 1750 1751 221.159.112.91 1752 221.159.112.97 1753 1754 http 1755 https 1756 1757 1759 Figure 24: Registering user-group and device-group information 1761 10.2. Scenario 1: Block SNS access during business hours 1763 The first example scenario is to "block SNS access during business 1764 hours" using a time-based firewall policy. In this scenario, all 1765 users registered as "employee" in the user-group list are unable to 1766 access Social Networking Services (SNS) during the office hours. The 1767 XML instance is described below: 1769 1770 1771 security_policy_for_blocking_sns 1772 1773 block_access_to_sns_during_office_hours 1774 1775 1776 09:00 1777 18:00 1778 1779 1780 1781 1782 1783 employees 1784 1785 1786 1787 1788 sns-websites 1789 1790 1791 1792 1793 drop 1794 1795 1796 1798 Figure 25: An XML Example for Time-based Firewall 1800 Time-based-condition Firewall 1802 1. The policy name is "security_policy_for_blocking_sns". 1804 2. The rule name is "block_access_to_sns_during_office_hours". 1806 3. The Source-target is "employees". 1808 4. The destination target is "sns-websites". "sns-websites" is the 1809 key which represents the list containing the information, such as 1810 URL, about sns-websites. 1812 5. The action required is to "drop" any attempt to connect to 1813 websites related to Social networking. 1815 10.3. Scenario 2: Block malicious VoIP/VoLTE packets coming to the 1816 company 1818 The second example scenario is to "block malicious VoIP/VoLTE packets 1819 coming to the company" using a VoIP policy. In this scenario, the 1820 calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that 1821 are classified as malicious are dropped. The IP addresses of the 1822 employees and malicious VOIP IDs should be blocked are stored in the 1823 database or datastore of the enterprise. Here and the rest of the 1824 cases assume that the security administrators or someone responsible 1825 for the existing and newly generated policies, are not aware of which 1826 and/or how many NSFs are needed to meet the security requirements. 1827 Figure 26 represents the XML document generated from YANG discussed 1828 in previous sections. Once a high-level seucurity policy is created 1829 by a security admin, it is delivered by the Consumer-Facing 1830 Interface, through RESTCONF server, to the security controller. The 1831 XML instance is described below: 1833 1834 1835 security_policy_for_blocking_malicious_voip_packets 1836 1837 Block_malicious_voip_and_volte_packets 1838 1839 1840 1841 malicious-id 1842 1843 1844 1845 1846 employees 1847 1848 1849 1850 1851 drop 1852 1853 1854 1856 Figure 26: An XML Example for VoIP Security Service 1858 Custom-condition Firewall 1860 1. The policy name is 1861 "security_policy_for_blocking_malicious_voip_packets". 1863 2. The rule name is "Block_malicious_voip_and_volte_packets". 1865 3. The Source-target is "malicious-id". This can be a single ID or 1866 a list of IDs, depending on how the ID are stored in the 1867 database. The "malicious-id" is the key so that the security 1868 admin can read every stored malicious VOIP IDs that are named as 1869 "malicious-id". 1871 4. The destination target is "employees". "employees" is the key 1872 which represents the list containing information about employees, 1873 such as IP addresses. 1875 5. The action required is "drop" when any incoming packets are from 1876 "malicious-id". 1878 10.4. Scenario 3: Mitigate HTTP and HTTPS flood attacks on a company 1879 web Server 1881 The third example scenario is to "Mitigate HTTP and HTTPS flood 1882 attacks on a company web Server" using a DDoS-attack mitigation 1883 policy. Here, the time information is not set because the service 1884 provided by the network should be maintained at all times. If the 1885 packets sent by any sources are more than the set threshold, then the 1886 admin can set the percentage of the packets to be dropped to safely 1887 maintain the service. In this scenario, the source is set as "any" 1888 to block any sources which send abnormal amount of packets. The 1889 destination is set as "web_server01". Once the rule is set and 1890 delivered and enforced to the nsfs by the securiy controller, the 1891 NSFs will monitor the incoming packet amounts and the destination to 1892 act according to the rule set. The XML instance is described below: 1894 1895 1896 security_policy_for_ddos_attacks 1897 1898 100_packets_per_second 1899 1900 1901 1902 webservers 1903 1904 1905 100 1906 1907 1908 1909 1910 drop 1911 1912 1913 1915 Figure 27: An XML Example for DDoS-attack Mitigation 1917 DDoS-condition Firewall 1919 1. The policy name is "security_policy_for_ddos_attacks". 1921 2. The rule name is "100_packets_per_second". 1923 3. The destination target is "webservers". "webservers" is the key 1924 which represents the list containing information, such as IP 1925 addresses and ports, about web-servers. 1927 4. The rate limit exists to limit the incoming amount of packets per 1928 second. In this case the rate limit is "100" packets per second. 1929 This amount depends on the packet receiving capacity of the 1930 server devices. 1932 5. The Source-target is all sources which send abnormal amount of 1933 packets. 1935 6. The action required is to "drop" packet reception is more than 1936 100 packets per second. 1938 11. Security Considerations 1940 The data model for the I2NSF Consumer-Facing Interface is derived 1941 from the I2NSF Consumer-Facing Interface Information Model 1942 [client-facing-inf-im], so the same security considerations with the 1943 information model should be included in this document. The data 1944 model needs to support a mechanism to protect Consumer-Facing 1945 Interface to Security Controller. 1947 12. IANA Considerations 1949 This document requests IANA to register the following URI in the 1950 "IETF XML Registry" [RFC3688]: 1952 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 1953 Registrant Contact: The I2NSF. 1954 XML: N/A; the requested URI is an XML namespace. 1956 This document requests IANA to register the following YANG module in 1957 the "YANG Module Names" registry [RFC7950]. 1959 name: ietf-i2nsf-cfi-policy 1960 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 1961 prefix: cfi-policy 1962 reference: RFC 7950 1964 13. References 1966 13.1. Normative References 1968 [RFC3444] Pras, A., "On the Difference between Information Models 1969 and Data Models", RFC 3444, January 2003. 1971 13.2. Informative References 1973 [client-facing-inf-im] 1974 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 1975 S., and L. Xia, "Information model for Client-Facing 1976 Interface to Security Controller", draft-kumar-i2nsf- 1977 client-facing-interface-im-07 (work in progress), July 1978 2018. 1980 [client-facing-inf-req] 1981 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 1982 S., and L. Xia, "Requirements for Client-Facing Interface 1983 to Security Controller", draft-ietf-i2nsf-client-facing- 1984 interface-req-05 (work in progress), May 2018. 1986 [draft-ietf-i2nsf-capability] 1987 Xia, L., Strassner, J., Huawei, Basile, C., PoliTo, Lopez, 1988 D., and TID, "Information Model of NSFs Capabilities", 1989 draft-ietf-i2nsf-capability-04 (work in progress), October 1990 2018. 1992 [i2nsf-terminology] 1993 Hares, S., Strassner, J., Lopez, D., Birkholz, H., and L. 1994 Xia, "Information model for Client-Facing Interface to 1995 Security Controller", draft-ietf-i2nsf-terminology-07 1996 (work in progress), January 2019. 1998 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1999 DOI 10.17487/RFC3688, January 2004, 2000 . 2002 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 2003 Network Configuration Protocol (NETCONF)", RFC 6020, 2004 October 2010. 2006 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2007 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 2008 January 2011, . 2010 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2011 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2012 . 2014 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2015 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2016 . 2018 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2019 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2020 May 2017, . 2022 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2023 and J. Jeong, "Interface to Network Security Functions 2024 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2025 DOI 10.17487/RFC8192, July 2017, 2026 . 2028 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2029 Kumar, "Framework for Interface to Network Security 2030 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2031 . 2033 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2034 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2035 . 2037 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- 2038 dm-02 2040 The following changes have been made from draft-ietf-i2nsf-consumer- 2041 facing-interface-dm-02: 2043 o In this version of the WG draft, we merged the 2044 [client-facing-inf-im] and draft-ietf-i2nsf-consumer-facing- 2045 interface-dm-02 drafts. In sections 4 to 9, we describe the 2046 information model for the security policies delivered through the 2047 Consumer-Facing Interface. In sections 10 to 12, we provide and 2048 discuss the YANG data model and example XML outputs of security 2049 policies for various use cases. 2051 o In Section 10, the following changes have been made: For "time- 2052 information" container in event sub-module list, the enforcement 2053 type is defined into three different types (admin-enforced, time- 2054 enforced, and event-enforced). Also, begin-time and end-time type 2055 has been defined seperately. The security policies can now be set 2056 recursively (daily, weekly, and monthly). 2058 o "policy-role" now has the access-profile container, and previlege 2059 can be set separately per profile. 2061 o "policy-user" information, such as email and password is newly 2062 defined by regular expressions. 2064 o "authentication-method" in "policy-mgnt-auth-method" has been 2065 modified. More specifically, the authentication-method type has 2066 been changed from string to choice so that one can choose between 2067 password, token, and certificate. If not selected, password is 2068 used as a default. 2070 o "Certificate-type" has been re-defined to include common 2071 certificate extensions, such as ".CRT", "CER", and "KEY". 2073 o Used groupings to represent the groups in the Endpoint groups. 2075 o Added examples for registering information (i.e., endpoint-groups, 2076 threat-prevention, and multi-tenancy.) 2078 Appendix B. Acknowledgments 2080 This work was supported by Institute for Information & communications 2081 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 2082 (No.R-20160222-002755, Cloud based Security Intelligence Technology 2083 Development for the Customized Security Service Provisioning). 2085 Appendix C. Contributors 2087 This document is made by the group effort of I2NSF working group. 2088 Many people actively contributed to this document, such as Mahdi F. 2089 Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their 2090 contributions. 2092 The following are co-authors of this document: 2094 Hyoungshick Kim 2095 Department of Software 2096 2066 Seo-ro Jangan-gu 2097 Suwon, Gyeonggi-do 16419 2098 Republic of Korea 2100 EMail: hyoung@skku.edu 2102 Seungjin Lee 2103 Department of Electrical and Computer Engineering 2104 2066 Seo-ro Jangan-gu 2105 Suwon, Gyeonggi-do 16419 2106 Republic of Korea 2108 EMail: jine33@skku.edu 2110 Jinyong Tim Kim 2111 Department of Electrical and Computer Engineering 2112 2066 Seo-ro Jangan-gu 2113 Suwon, Gyeonggi-do 16419 2114 Republic of Korea 2116 EMail: timkim@skku.edu 2118 Anil Lohiya 2119 Juniper Networks 2120 1133 Innovation Way 2121 Sunnyvale, CA 94089 2122 US 2124 EMail: alohiya@juniper.net 2126 Dave Qi 2127 Bloomberg 2128 731 Lexington Avenue 2129 New York, NY 10022 2130 US 2132 EMail: DQI@bloomberg.net 2134 Nabil Bitar 2135 Nokia 2136 755 Ravendale Drive 2137 Mountain View, CA 94043 2138 US 2140 EMail: nabil.bitar@nokia.com 2142 Senad Palislamovic 2143 Nokia 2144 755 Ravendale Drive 2145 Mountain View, CA 94043 2146 US 2148 EMail: senad.palislamovic@nokia.com 2150 Liang Xia 2151 Huawei 2152 101 Software Avenue 2153 Nanjing, Jiangsu 210012 2154 China 2156 EMail: Frank.Xialiang@huawei.com 2158 Authors' Addresses 2160 Jaehoon Paul Jeong 2161 Department of Software 2162 Sungkyunkwan University 2163 2066 Seobu-Ro, Jangan-Gu 2164 Suwon, Gyeonggi-Do 16419 2165 Republic of Korea 2167 Phone: +82 31 299 4957 2168 Fax: +82 31 290 7996 2169 EMail: pauljeong@skku.edu 2170 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2171 Eunsoo Kim 2172 Department of Electrical and Computer Engineering 2173 Sungkyunkwan University 2174 2066 Seobu-Ro, Jangan-Gu 2175 Suwon, Gyeonggi-Do 16419 2176 Republic of Korea 2178 Phone: +82 31 299 4104 2179 EMail: eskim86@skku.edu 2180 URI: http://seclab.skku.edu/people/eunsoo-kim/ 2182 Tae-Jin Ahn 2183 Korea Telecom 2184 70 Yuseong-Ro, Yuseong-Gu 2185 Daejeon 305-811 2186 Republic of Korea 2188 Phone: +82 42 870 8409 2189 EMail: taejin.ahn@kt.com 2191 Rakesh Kumar 2192 Juniper Networks 2193 1133 Innovation Way 2194 Sunnyvale, CA 94089 2195 USA 2197 EMail: rkkumar@juniper.net 2199 Susan Hares 2200 Huawei 2201 7453 Hickory Hill 2202 Saline, MI 48176 2203 USA 2205 Phone: +1-734-604-0332 2206 EMail: shares@ndzh.com