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