idnits 2.17.1 draft-ietf-i2nsf-consumer-facing-interface-dm-04.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 10 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 708 has weird spacing: '...address ine...' == Line 736 has weird spacing: '...address ine...' == Line 823 has weird spacing: '...address inet...' -- The document date (April 4, 2019) is 1842 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 2051, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 2072, 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: October 6, 2019 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 April 4, 2019 13 I2NSF Consumer-Facing Interface YANG Data Model 14 draft-ietf-i2nsf-consumer-facing-interface-dm-04 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)[i2nsf-capability-im], and the data 27 model is defined for enabling different users of a given I2NSF system 28 to define, manage, and monitor security policies for specific flows 29 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 October 6, 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 . . . . . . . . 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 . . . . . . . . . . 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-03 . . . . . . . . . . . . . . . . . . 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 requirement. 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-Event" (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 use 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 by 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 virtual technology, these VNFs 192 might be automatically provisioned and dynamically migrated based on 193 real-time security requirements. This document presents a YANG data 194 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 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: This field contains the information about IPsec type. 267 There are two types such as IPsec-IKE and IPsec-IKEless 268 [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 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 3 different types of three 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: This field contains the information about IPsec type. 627 There are two types; 1) IPsec-IKE and IPsec-IKEless. 629 Single Sign-on-Server: This field stores the information about 630 server that validates user credentials. 632 +--rw policy-mgnt-auth-method* [name] 633 +--rw name string 634 +--rw date? yang:date-and-time 635 +--rw mutual-authentication? boolean 636 +--rw password 637 | +--rw password? password-type 638 +--rw token 639 | +--rw token? string 640 | +--rw token-server? inet:ipv4-address 641 +--rw certificate 642 | +--rw certificate? certificate-type 643 | +--rw certificate-server? inet:ipv4-address 644 +--rw ipsec* [ipsec-method] 645 | +--rw ipsec-method identityref 646 +--rw single-sign-on 647 +--rw credential? certificate-type 648 +--rw certificate-server? inet:ipv4-address 650 Figure 12: Policy Management Authentication Method YANG Data Tree 652 6. Information Model for Policy Endpoint Groups 654 The Policy Endpoint Group is a very important part of building User- 655 Construct based policies. A Security Administrator would create and 656 use these objects to represent a logical entity in their business 657 environment, where a Security Policy is to be applied. There are 658 multiple managed objects that constitute a Policy's Endpoint Group as 659 shown in Figure 13. Figure 14 shows the XML instance of the 660 Endpoint-Group object. This section lists these objects and 661 relationship among them. 663 +-------------------+ 664 | Endpoint Group | 665 +---------+---------+ 666 ^ 667 | 668 +--------------+----------------+ 669 1..n | 1..n | 1..n | 670 +-----+----+ +------+-----+ +-------+------+ 671 |User-group| |Device-group| |Location-group| 672 +----------+ +------------+ +--------------+ 674 Figure 13: Endpoint Group Diagram 676 +--rw endpoint-group 677 +--rw user-group* [name] 678 | ... 679 +--rw device-group* [name] 680 | ... 681 +--rw location-group* [name] 682 ... 684 Figure 14: Endpoint Group YANG Data Tree 686 6.1. User Group 688 This object represents a User-Group. Figure 15 shows the XML 689 instance of the User-Group object. The User-Group object SHALL have 690 the following information: 692 Name: This field identifies the name of this object. 694 Date: Date when this object was created or last modified. 696 IP-Address: This field identifies the IP address of a user. 698 Range-IP-Address: This field is a range of IP addresses of users. 700 +--rw user-group* [name] 701 +--rw name string 702 +--rw date? yang:date-and-time 703 +--rw (match-type)? 704 +--:(exact-match) 705 | +--rw ip-address* inet:ipv4-address 706 +--:(range-match) 707 +--rw range-ip-address* [start-ip-address end-ip-address] 708 +--rw start-ip-address inet:ipv4-address 709 +--rw end-ip-address inet:ip-address 711 Figure 15: User Group YANG Data Tree 713 6.2. Device Group 715 This object represents a Device-Group. Figure 16 shows the XML 716 instance of the Device-group object.The Device-Group object SHALL 717 have the following information: 719 Name: This field identifies the name of this object. 721 Date: Date when this object was created or last modified. 723 IP-Address: This field identifies the IP address of a device. 725 Range-IP-Address: This field is a range of IP addresses of 726 devices. 728 +--rw device-group* [name] 729 +--rw name string 730 +--rw date? yang:date-and-time 731 +--rw (match-type)? 732 +--:(exact-match) 733 | +--rw ip-address* inet:ipv4-address 734 +--:(range-match) 735 +--rw range-ip-address* [start-ip-address end-ip-address] 736 +--rw start-ip-address inet:ipv4-address 737 +--rw end-ip-address inet:ip-address 739 Figure 16: Device Group YANG Data Tree 741 6.3. Location Group 743 This object represents a location group based on either tag or other 744 information. Figure 17 shows the XML instance of the Location-Group 745 object. The Location-Group object SHALL have the following 746 information: 748 Name: This field identifies the name of this object. 750 Date: Date when this object was created or last modified. 752 continent: to identify which continent the location group member 753 is based at. 755 +--rw location-group* [name] 756 +--rw name string 757 +--rw date? yang:date-and-time 758 +--rw continent? identityref 760 Figure 17: Location Group YANG Data Tree 762 7. Information Model for Threat Prevention 764 The threat prevention plays an important part in the overall security 765 posture by reducing the attack surfaces. This information could come 766 from various threat feeds (i.e., sources for obtaining the threat 767 information), such as EmergingThreats.com or AlienVault.com. There 768 are multiple managed objects that constitute this category. This 769 section lists these objects and relationship among them. Figure 19 770 shows the XML instance of a Threat-Prevention object. 772 +-------------------+ 773 | Threat Prevention | 774 +---------+---------+ 775 ^ 776 | 777 +---------+---------+ 778 1..n | 1..n | 779 +------+------+ +--------+--------+ 780 | Threat-feed | | payload-content | 781 +-------------+ +-----------------+ 783 Figure 18: Threat Prevention Diagram 785 +--rw threat-prevention 786 | +--rw threat-feed-list* [name] 787 | ... 788 | +--rw payload-content* [name] 789 | ... 791 Figure 19: Threat Prevention YANG Data Tree 793 7.1. Threat Feed 795 This object represents a threat feed which provides signatures of 796 malicious activities. Figure 20 shows the XML instance of a Threat- 797 feed-list. The Threat-Feed object SHALL have the following 798 information: 800 Name: This field identifies the name of this object. 802 Date: Date when this object was created or last modified. 804 Threat-feed-Server: This field identifies the information about 805 the feed provider, it may be an external service or local 806 server. 808 Threat-file-types: This field identifies the information about 809 the file types identified and reported by the threat-feed. 811 signatures: This field contains the signatures of malicious 812 programs or activities provided by the threat-feed. 814 +--rw threat-feed-list* [name] 815 +--rw name string 816 +--rw date? yang:date-and-time 817 +--rw threat-feed-server 818 | +--rw (match-type)? 819 | | +--:(exact-match) 820 | | | +--rw ip-address* inet:ipv4-address 821 | | +--:(range-match) 822 | | +--rw range-ip-address* [start-ip-address end-ip-address] 823 | | +--rw start-ip-address inet:ipv4-address 824 | | +--rw end-ip-address inet:ip-address 825 | +--rw threat-feed-description? string 826 +--rw threat-file-types* identityref 827 +--rw signatures* string 829 Figure 20: Threat Feed YANG Data Tree 831 7.2. Payload Content 833 This object represents a custom list created for the purpose of 834 defining exception to threat feeds. Figure 21 shows the XML instance 835 of a Payload-content list. The Payload-Content object SHALL have the 836 following information: 838 Name: This field identifies the name of this object. 840 Date: Date when this object was created or last modified. 842 List-Content: This field contains contents such as IP addresses 843 or URL names. 845 +--rw payload-content* [name] 846 | +--rw name string 847 | +--rw date? yang:date-and-time 848 | +--rw content* string 850 Figure 21: Payload Content in YANG Data Tree 852 8. Role-based Acess Control (RBAC) 854 Role-Based Access Control (RBAC) provides a powerful and centralized 855 control within a network. It is a policy neutral access control 856 mechanism defined around roles and privileges. The components of 857 RBAC, such as role-permissions, user-role and role-role 858 relationships, make it simple to perform user assignments. 860 +--------------+ 861 | | 862 | User 1 + (has many) 863 | |\ 864 +--------------+ \ +---------------+ +-------------+ 865 . \ | | (has many) | | 866 . --->+ List of roles +----------->+ Permissions | 867 +--------------+ / | | | | 868 | | / +---------------+ +-------------+ 869 | User n +/ 870 | | (has many) 871 +--------------+ 873 Figure 22: Role-based Acess Control Diagram 875 As shown in Figure 22, a role represents a collection of permissions 876 (e.g., accessing a file server or other particular resources). A 877 role may be assigned to one or multiple users. Both roles and 878 permissions can be organized in a hirarchy. A role may consists of 879 other roles and permissions. 881 Following are the steps required to build RBAC: 883 1. Defining roles and permissions. 885 2. Establishing relations among roles and permissions. 887 3. Defining users. 889 4. Associating rules with roles and permissions. 891 5. assigning roles to users. 893 9. YANG Data Model for Security Policies for Consumer-Facing Interface 895 The main objective of this data model is to provide both an 896 information model and the corresponding YANG data model of I2NSF 897 Consumer-Facing Interface. This interface can be used to deliver 898 control and management messages between an I2NSF User and Security 899 Controller for the I2NSF User's high-level security policies. 901 The semantics of the data model must be aligned with the information 902 model of the Consumer-Facing Interface. The transformation of the 903 information model was performed so that this YANG data model can 904 facilitate the efficient delivery of the control or management 905 messages. 907 This data model is designed to support the I2NSF framework that can 908 be extended according to the security needs. In other words, the 909 model design is independent of the content and meaning of specific 910 policies as well as the implementation approach. This document 911 suggests a VoIP/VoLTE security service as a use case for policy rule 912 generation. 914 This section describes a YANG data model for Consumer-Facing 915 Interface, based on the information model of Consumer-Facing 916 Interface to Security Controller. 918 file "ietf-cfi-policy.yang" 919 module ietf-i2nsf-cfi-policy { 920 yang-version 1.1; 921 namespace 922 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; 923 prefix 924 cfi-policy; 926 import ietf-yang-types{ 927 prefix yang; 928 reference 929 "Section 3 of RFC 6991"; 930 } 932 import ietf-inet-types{ 933 prefix inet; 934 reference 935 "Section 4 of RFC 6991"; 936 } 938 organization 939 "IETF I2NSF (Interface to Network Security Functions) 940 Working Group"; 942 contact 943 "WG Web: 944 WG List: 946 WG Chair: Adrian Farrel 947 949 WG Chair: Linda Dunbar 950 952 Editor: Jaehoon Paul Jeong 953 "; 955 description 956 "This module is a YANG module for Consumer-Facing Interface. 957 Copyright (c) 2018 IETF Trust and the persons identified as 958 authors of the code. All rights reserved. 959 Redistribution and use in source and binary forms, with or 960 without modification, is permitted pursuant to, and subject 961 to the license terms contained in, the Simplified BSD License 962 set forth in Section 4.c of the IETF Trust's Legal Provisions 963 Relating to IETF Documents 964 (http://trustee.ietf.org/license-info). 965 This version of this YANG module is part of RFC XXXX; see 966 the RFC itself for full legal notices."; 968 revision "2019-04-04"{ 969 description "latest revision"; 970 reference 971 "draft-ietf-consumer-facing-interface-dm-03"; 972 } 973 identity permission-type { 974 description 975 "Base identity for the permission types."; 976 } 978 identity read-only { 979 base permission-type; 980 description 981 "Identity for read-only permission."; 982 } 983 identity read-and-write { 984 base permission-type; 985 description 986 "Identity for read permission."; 987 } 989 identity scope-type { 990 description 991 "Base Identity for scope-type."; 992 } 993 identity tenant-wide { 994 base scope-type; 995 description 996 "Base Identity for tenant-wide scope type."; 997 } 998 identity domain-wide { 999 base scope-type; 1000 description 1001 "Base Identity for domain-wide scope type."; 1002 } 1004 identity malware-file-type { 1005 description 1006 "Base identity for malware file types."; 1007 } 1008 identity executable-file { 1009 base malware-file-type; 1010 description 1011 "Identity for executable file types."; 1012 } 1013 identity doc-file { 1014 base malware-file-type; 1015 description 1016 "Identity for Microsoft document file types."; 1017 } 1018 identity html-app-file { 1019 base malware-file-type; 1020 description 1021 "Identity for html application file types."; 1022 } 1023 identity javascript-file { 1024 base malware-file-type; 1025 description 1026 "Identity for Javascript file types."; 1027 } 1028 identity pdf-file { 1029 base malware-file-type; 1030 description 1031 "Identity for pdf file types."; 1032 } 1033 identity dll-file { 1034 base malware-file-type; 1035 description 1036 "Identity for dll file types."; 1037 } 1038 identity msi-file { 1039 base malware-file-type; 1040 description 1041 "Identity for Microsoft installer file types."; 1042 } 1044 identity security-event-type { 1045 description 1046 "Base identity for security event types."; 1047 } 1048 identity ddos { 1049 base malware-file-type; 1050 description 1051 "Identity for DDoS event types."; 1052 } 1053 identity spyware { 1054 base malware-file-type; 1055 description 1056 "Identity for spyware event types."; 1057 } 1058 identity trojan { 1059 base malware-file-type; 1060 description 1061 "Identity for Trojan infection event types."; 1062 } 1063 identity ransomeware { 1064 base malware-file-type; 1065 description 1066 "Identity for ransomeware infection event types."; 1067 } 1068 identity ipsec-type { 1069 description 1070 "Base identity for the IPsec types."; 1071 } 1073 identity ike { 1074 base ipsec-type; 1075 description 1076 "Identity for ipsec-ike"; 1077 } 1079 identity ikeless { 1080 base ipsec-type; 1081 description 1082 "Identity for ipsec-ikeless"; 1083 } 1085 identity continent { 1086 description 1087 "Base Identity for continent types."; 1088 } 1090 identity africa { 1091 base continent; 1092 description 1093 "Identity for africa."; 1094 } 1095 identity asia { 1096 base continent; 1097 description 1098 "Identity for asia."; 1099 } 1100 identity europe { 1101 base continent; 1102 description 1103 "Identity for europe."; 1104 } 1105 identity north-america { 1106 base continent; 1107 description 1108 "Identity for north-america."; 1109 } 1110 identity south-america { 1111 base continent; 1112 description 1113 "Identity for south-america."; 1114 } 1115 identity oceania { 1116 base continent; 1117 description 1118 "Identity for Oceania"; 1119 } 1120 typedef certificate-type { 1122 type enumeration { 1123 enum cer { 1124 description 1125 "The extension type is '.cer'."; 1126 } 1127 enum crt { 1128 description 1129 "The extension type is '.crt'."; 1130 } 1131 enum key { 1132 description 1133 "The extension type is '.key'."; 1134 } 1135 } 1136 description 1137 "CRT certificate extension, which is used for certificates. 1138 The certificates may be encoded as binary DER or as ASCII PEM. 1139 The CER and CRT extensions are nearly synonymous. Most common 1140 among *nix systems. CER certificate extension, which is an 1141 alternate form of .crt (Microsoft Convention) You can use MS to 1142 convert .crt to .cer (.both DER encoded .cer, or base64[PEM] 1143 encoded .cer). The KEY extension is used both for public and 1144 private PKCS#8 keys. The keys may be encoded as binary DER or 1145 as ASCII PEM."; 1146 } 1148 grouping meta { 1149 description 1150 "The purpose of this grouping is to avoid repetition 1151 of same fields, such as 'name' and 'date'."; 1152 leaf name { 1153 type string; 1154 description "This is the name for an entity."; 1155 } 1156 leaf date { 1157 type yang:date-and-time; 1158 description "This is the date when the entity is 1159 created or modified."; 1160 } 1161 } 1163 grouping ip-address { 1164 description 1165 "There are two types to configure a security policy 1166 for IPv4 address, such as exact match and range match."; 1167 choice match-type { 1168 description 1169 "User can choose between 'exact match' and 'range match'."; 1170 case exact-match { 1171 leaf-list ip-address { 1172 type inet:ipv4-address; 1173 description 1174 "Exactly matches the IP address specified."; 1175 } 1176 } 1177 case range-match { 1178 list range-ip-address { 1179 key "start-ip-address end-ip-address"; 1180 leaf start-ip-address { 1181 type inet:ipv4-address; 1182 description 1183 "Start IP address for a range match."; 1184 } 1185 leaf end-ip-address { 1186 type inet:ip-address; 1187 description 1188 "End IP address for a range match."; 1189 } 1190 description 1191 "Range match for an IP-address."; 1192 } 1193 } 1194 } 1195 } 1197 grouping user-group { 1198 description 1199 "This grouping is to remove repetition of 1200 'name' and 'ip-address' fields."; 1201 uses meta; 1202 uses ip-address; 1203 } 1205 grouping device-group { 1206 description 1207 "This grouping is to remove repetition of 1208 'name', 'ip-address', and 'protocol' fields."; 1209 uses meta; 1210 uses ip-address; 1211 leaf-list protocol { 1212 type string; 1213 description 1214 "This represents the port numbers of devices."; 1215 } 1216 } 1218 grouping location-group { 1219 description 1220 "This grouping is to remove repetition of 1221 'name' and 'continent' fields."; 1222 uses meta; 1223 leaf continent { 1224 type identityref { 1225 base continent; 1226 } 1227 description 1228 "location-group-based on geo-ip of 1229 respective continent."; 1230 } 1231 } 1233 grouping payload-string { 1234 description 1235 "This grouping is to remove repetition of 1236 'name' and 'content' fields."; 1237 uses meta; 1238 leaf-list content { 1239 type string; 1240 description 1241 "This represents the payload string content."; 1242 } 1243 } 1245 container policy { 1246 leaf policy-name { 1247 type string; 1248 description 1249 "The name which identifies the policy."; 1250 } 1251 description 1252 "There can be a multiple number of security rules in 1253 a policy object. This object is a policy instance to 1254 have complete information such as where and when a 1255 policy need to be applied."; 1257 list rule { 1258 leaf rule-name { 1259 type string; 1260 description 1261 "This represents the name for rules."; 1262 } 1263 key "rule-name"; 1264 description 1265 "There can be a single or multiple number of rules."; 1267 leaf date { 1268 type yang:date-and-time; 1269 description 1270 "Date this object was created or last 1271 modified"; 1272 } 1273 container event { 1274 description 1275 "This represents the event map group name."; 1276 leaf security-event { 1277 type identityref { 1278 base security-event-type; 1279 } 1280 description 1281 "This contains the description of security events."; 1282 } 1283 leaf enforce-type { 1284 type enumeration{ 1285 enum admin-enforced { 1286 description 1287 "The enforcement type is admin-enforced."; 1288 } 1289 enum time-enforced { 1290 description 1291 "The enforcement type is time-enforced."; 1292 } 1293 enum event-enforced { 1294 description 1295 "The enforcement type is event-enforced."; 1296 } 1297 } 1298 description 1299 "This field identifies the event of 1300 policy enforcement trigger type."; 1301 } 1302 container time-information { 1303 description 1304 "The container for time-information."; 1305 leaf begin-time { 1306 type string; 1307 description 1308 "This is start time for time zone"; 1309 } 1310 leaf end-time { 1311 type string; 1312 description 1313 "This is end time for time zone"; 1314 } 1315 } 1316 container recursive { 1317 description 1318 "The container to represent the recursiveness 1319 of the rule."; 1320 leaf recur { 1321 type boolean; 1322 description 1323 "recursive enforcement"; 1324 } 1325 leaf recursive-type{ 1326 type enumeration{ 1327 enum daily { 1328 description 1329 "The recursive type is daily."; 1330 } 1331 enum weekly { 1332 description 1333 "The recursive type is weekly."; 1334 } 1335 enum monthly { 1336 description 1337 "The recursive type is monthly."; 1338 } 1339 } 1340 description 1341 "This leaf identifies the recursive type."; 1342 } 1343 } 1344 } 1345 container condition { 1346 description 1347 "The conditions for general security policies."; 1348 container firewall-condition { 1349 description 1350 "The general firewall condition."; 1351 container source-target { 1352 description 1353 "This represents the source."; 1354 leaf src-target { 1355 type leafref { 1356 path "/policy/endpoint-group/user-group/name"; 1357 } 1358 description 1359 "This describes the paths to 1360 the source reference."; 1361 } 1362 } 1363 container destination-target { 1364 description 1365 "This represents the destination."; 1366 leaf-list dest-target { 1367 type leafref { 1368 path "/policy/endpoint-group/user-group/name"; 1369 } 1370 description 1371 "This describes the paths to the 1372 destination target reference."; 1373 } 1374 } 1375 } 1376 container ddos-condition { 1377 description 1378 "The condition for DDoS mitigation."; 1379 container source-target { 1380 description 1381 "This represents the source."; 1382 leaf-list src-target { 1383 type leafref { 1384 path "/policy/endpoint-group/device-group/name"; 1385 } 1386 description 1387 "This describes the path to the 1388 source target references."; 1389 } 1390 } 1391 container destination-target { 1392 description 1393 "This represents the target."; 1394 leaf-list dest-target { 1395 type leafref { 1396 path "/policy/endpoint-group/device-group/name"; 1397 } 1398 description 1399 "This describes the path to the 1400 destination target references."; 1401 } 1402 } 1403 container rate-limit { 1404 description "This describes the rate-limit."; 1405 leaf packet-per-second { 1406 type uint8; 1407 description 1408 "The rate-limit limits the amount of incoming packets."; 1409 } 1410 } 1411 } 1412 container custom-condition { 1413 description 1414 "The condition based on packet contents."; 1415 container source-target { 1416 description 1417 "This represents the source."; 1418 leaf-list src-target { 1419 type leafref { 1420 path "/policy/threat-prevention/payload-content/name"; 1421 } 1422 description 1423 "Describes the payload string 1424 content condition source."; 1425 } 1426 } 1427 container destination-target { 1428 description 1429 "This represents the destination."; 1430 leaf dest-target { 1431 type leafref { 1432 path "/policy/threat-prevention/payload-content/name"; 1433 } 1434 description 1435 "Describes the payload string 1436 content condition destination."; 1437 } 1438 } 1439 } 1440 container threat-feed-condition { 1441 description 1442 "The condition based on the threat-feed information."; 1443 container source-target { 1444 description 1445 "This represents the source."; 1446 leaf-list src-target { 1447 type leafref { 1448 path "/policy/threat-prevention/threat-feed-list/name"; 1449 } 1450 description "Describes the threat-feed 1451 condition source."; 1453 } 1454 } 1455 container destination-target { 1456 description 1457 "This represents the destination."; 1458 leaf dest-target { 1459 type leafref { 1460 path "/policy/threat-prevention/threat-feed-list/name"; 1461 } 1462 description "Describes the threat-feed 1463 condition destination."; 1464 } 1465 } 1466 } 1467 } 1468 container action { 1469 description 1470 "This is the action container."; 1471 leaf primary-action { 1472 type string; 1473 description 1474 "This field identifies the action when a rule 1475 is matched by NSF. The action could be one of 1476 'PERMIT', 'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS', 1477 'AUTHENTICATE-SESSION', 'IPS, 'APP-FIREWALL', etc."; 1478 } 1479 leaf secondary-action { 1480 type string; 1481 description 1482 "This field identifies additional actions if 1483 a rule is matched. This could be one of 'LOG', 1484 'SYSLOG', 'SESSION-LOG', etc."; 1485 } 1486 } 1487 container ipsec { 1488 description 1489 "This container represents the IPsec-IKE/IKEless cases."; 1490 leaf ipsec-method { 1491 type leafref { 1492 path "/policy/multi-tenancy/policy-mgnt-auth-method/ipsec/ipsec-method"; 1493 } 1494 description 1495 "This represents the IPsec-method, which 1496 is defined by policy-mgny-auth-method."; 1497 } 1498 } 1499 leaf owner { 1500 type string; 1501 description 1502 "This field defines the owner of this 1503 policy. Only the owner is authorized to 1504 modify the contents of the policy."; 1505 } 1506 } 1508 container multi-tenancy { 1509 description 1510 "The multi-tenant environment information 1511 in which the policy is applied. The Rules 1512 in the Policy can refer to sub-objects 1513 (e.g., domain, tenant, role, and user) of it."; 1515 list policy-domain { 1516 uses meta; 1517 key "name"; 1518 leaf address { 1519 type string; 1520 description 1521 "The address details of the organization 1522 or customer."; 1523 } 1524 leaf contact { 1525 type string; 1526 description 1527 "contact information of the organization 1528 or customer."; 1529 } 1530 list policy-tenant { 1531 uses meta; 1532 key "name"; 1533 description 1534 "This represents the list of tenants"; 1535 leaf domain { 1536 type leafref { 1537 path "/policy/multi-tenancy/policy-domain/name"; 1538 } 1539 description 1540 "This field identifies the domain to which this 1541 tenant belongs. This should be reference to a 1542 'Policy-Domain' object."; 1543 } 1544 } 1545 leaf authentication-method { 1546 type leafref { 1547 path "/policy/multi-tenancy/policy-mgnt-auth-method/ipsec/ipsec-method"; 1548 } 1549 description 1550 "Authentication method to be used for this domain. 1551 It should be a reference to a 'policy-mgmt-auth-method' 1552 object."; 1553 } 1554 description 1555 "This represents the list of policy domains."; 1556 } 1557 container policy-role { 1558 uses meta; 1559 description 1560 "This represents the list of policy roles."; 1561 list access-profile { 1562 uses meta; 1563 key "name"; 1564 description 1565 "This field identifies the access profile for the 1566 role. The profile grants or denies access to policy 1567 objects."; 1568 leaf permission-type { 1569 type identityref { 1570 base permission-type; 1571 } 1572 default read-only; 1573 description 1574 "Permission type for access-profile: read-only 1575 or read-and-write."; 1576 } 1577 } 1578 } 1579 list policy-user { 1580 uses meta; 1581 key "name"; 1582 description 1583 "This represents the policy users."; 1584 leaf password { 1585 type string; 1586 description 1587 "User password for basic authentication"; 1588 } 1589 leaf email { 1590 type string; 1591 description 1592 "The email account of a user"; 1593 } 1594 leaf scope-type { 1595 type identityref { 1596 base scope-type; 1598 } 1599 default tenant-wide; 1600 description 1601 "identifies whether a user has domain-wide 1602 or tenant-wide privileges"; 1603 } 1604 leaf role { 1605 type leafref { 1606 path "/policy/multi-tenancy/policy-role/access-profile/name"; 1607 } 1608 description 1609 "This represents the reference to the 1610 access-profiles."; 1611 } 1612 } 1613 container policy-mgnt-auth-method { 1614 description 1615 "This represents the list of authentication methods."; 1616 leaf auth-method { 1617 type string; 1618 description 1619 "This represents the authentication method name."; 1620 } 1621 leaf mutual-authentication { 1622 type boolean; 1623 description 1624 "To identify whether the authentication 1625 is mutual."; 1626 } 1627 list password-based { 1628 key "password"; 1629 leaf password { 1630 type string; 1631 description 1632 "This should be defined using the 1633 regular expression."; 1634 } 1635 description 1636 "This represents the password-based method."; 1637 } 1638 list token-based { 1639 key "token"; 1640 leaf token { 1641 type string; 1642 description 1643 "This should be defined according to 1644 the token scheme."; 1645 } 1646 leaf token-server { 1647 type inet:ipv4-address; 1648 description 1649 "This represents the token-server 1650 information if the authentication method 1651 is token-based."; 1652 } 1653 description 1654 "This represents the token-based method."; 1655 } 1656 list certificate-based { 1657 key "certificate"; 1658 leaf certificate { 1659 type certificate-type; 1660 description 1661 "This represents the certificate-type."; 1662 } 1663 leaf certificate-server { 1664 type inet:ipv4-address; 1665 description 1666 "The certificate-server information if 1667 the authentication method is 1668 certificate-based"; 1669 } 1670 description 1671 "This describes the certificate-based authentication list."; 1672 } 1673 list ipsec { 1674 key "ipsec-method"; 1675 leaf ipsec-method { 1676 type identityref { 1677 base ipsec-type; 1678 } 1679 description 1680 "This represents the IPsec-IKE or IPsec-IKEless cases."; 1681 } 1682 description 1683 "This represents the list of IPsec-method."; 1684 } 1685 list single-sign-on { 1686 key "credential"; 1687 leaf credential { 1688 type certificate-type; 1689 description 1690 "This represents the authentication 1691 using user credentials."; 1692 } 1693 leaf certificate-server { 1694 type inet:ipv4-address; 1695 description 1696 "The certificate-server information if 1697 the authentication method is 1698 certificate-based"; 1699 } 1700 description 1701 "This represents the authentication method 1702 for single-sing-on."; 1703 } 1704 } 1705 } 1706 container endpoint-group { 1707 description 1708 "A logical entity in their business 1709 environment, where a security policy 1710 is to be applied."; 1711 list user-group { 1712 uses user-group; 1713 key "name"; 1714 description 1715 "This represents the user group."; 1716 } 1717 list device-group { 1718 uses device-group; 1719 key "name"; 1720 description 1721 "This represents the device group."; 1722 } 1723 list location-group{ 1724 uses location-group; 1725 key "name"; 1726 description 1727 "This represents the location group."; 1728 } 1729 } 1730 container threat-prevention { 1731 description 1732 "this describes the list of threat-prevention."; 1733 list threat-feed-list { 1734 uses meta; 1735 key "name"; 1736 description 1737 "This represents the threat feed list."; 1738 container threat-feed-server { 1739 uses ip-address; 1740 description 1741 "This describes the threat-feed server."; 1743 leaf threat-feed-description { 1744 type string; 1745 description 1746 "This object containes threat-feed 1747 description."; 1748 } 1749 } 1750 leaf-list threat-file-types { 1751 type identityref { 1752 base malware-file-type; 1753 } 1754 default executable-file; 1755 description 1756 "This contains a list of file types needed to 1757 be scanned for the virus."; 1758 } 1759 leaf-list signatures { 1760 type string; 1761 description 1762 "This contains a list of signatures or hash 1763 of the threats."; 1764 } 1765 } 1766 list payload-content { 1767 uses payload-string; 1768 key "name"; 1769 description 1770 "This represents the payload-string group."; 1771 } 1772 } 1773 } 1774 } 1775 1777 Figure 23: YANG for Consumer-Facing Interface 1779 10. Example XML Output for Various Scenarios 1781 This section describes the XML instances for different policies 1782 examples that are delivered through Consumer-Facing Interface. The 1783 considered use cases are: VoIP/VoLTE security service, DDoS-attack 1784 mitigation, time-based firewall as a web-filter. 1786 10.1. DB Registration: Information of Positions and Devices (Endpoint 1787 Group) 1789 In order to create a rule of a security policy, it is essential to 1790 first register data (those which are used to form such rule) to the 1791 database. For example, The endpoint group consists of three 1792 different groups: user-group, device-group, and payload-group. Each 1793 of these groups have separate group members with information other 1794 than meta ("name" or "date"), such as ip-addresses or protocols used 1795 by devices. Figure 24 shows an example XML representation of the 1796 registered information for the user-group and device-group. 1798 1799 1800 1801 employees 1802 1803 221.159.112.1 1804 221.159.112.90 1805 1806 1807 1808 webservers 1809 1810 221.159.112.91 1811 221.159.112.97 1812 1813 http 1814 https 1815 1816 1818 Figure 24: Registering User-group and Device-group Information 1820 10.2. Scenario 1: Block SNS Access during Business Hours 1822 The first example scenario is to "block SNS access during business 1823 hours" using a time-based firewall policy. In this scenario, all 1824 users registered as "employee" in the user-group list are unable to 1825 access Social Networking Services (SNS) during the office hours. The 1826 XML instance is described below: 1828 1829 1830 security_policy_for_blocking_sns 1831 1832 block_access_to_sns_during_office_hours 1833 1834 1835 09:00 1836 18:00 1837 1838 1839 1840 1841 1842 employees 1843 1844 1845 1846 1847 sns-websites 1848 1849 1850 1851 1852 drop 1853 1854 1855 ikeless 1856 1857 1858 1860 Figure 25: An XML Example for Time-based Firewall 1862 Time-based-condition Firewall 1864 1. The policy name is "security_policy_for_blocking_sns". 1866 2. The rule name is "block_access_to_sns_during_office_hours". 1868 3. The Source-target is "employees". 1870 4. The destination target is "sns-websites". "sns-websites" is the 1871 key which represents the list containing the information, such as 1872 URL, about sns-websites. 1874 5. The action required is to "drop" any attempt to connect to 1875 websites related to Social networking. 1877 6. The IPsec-method is set to "ikeless". 1879 10.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a 1880 Company 1882 The second example scenario is to "block malicious VoIP/VoLTE packets 1883 coming to a company" using a VoIP policy. In this scenario, the 1884 calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that 1885 are classified as malicious are dropped. The IP addresses of the 1886 employees and malicious VOIP IDs should be blocked are stored in the 1887 database or datastore of the enterprise. Here and the rest of the 1888 cases assume that the security administrators or someone responsible 1889 for the existing and newly generated policies, are not aware of which 1890 and/or how many NSFs are needed to meet the security requirements. 1891 Figure 26 represents the XML document generated from YANG discussed 1892 in previous sections. Once a high-level seucurity policy is created 1893 by a security admin, it is delivered by the Consumer-Facing 1894 Interface, through RESTCONF server, to the security controller. The 1895 XML instance is described below: 1897 1898 1899 security_policy_for_blocking_malicious_voip_packets 1900 1901 Block_malicious_voip_and_volte_packets 1902 1903 1904 1905 malicious-id 1906 1907 1908 1909 1910 employees 1911 1912 1913 1914 1915 drop 1916 1917 1918 ikeless 1919 1920 1921 1923 Figure 26: An XML Example for VoIP Security Service 1925 Custom-condition Firewall 1927 1. The policy name is 1928 "security_policy_for_blocking_malicious_voip_packets". 1930 2. The rule name is "Block_malicious_voip_and_volte_packets". 1932 3. The Source-target is "malicious-id". This can be a single ID or 1933 a list of IDs, depending on how the ID are stored in the 1934 database. The "malicious-id" is the key so that the security 1935 admin can read every stored malicious VOIP IDs that are named as 1936 "malicious-id". 1938 4. The destination target is "employees". "employees" is the key 1939 which represents the list containing information about employees, 1940 such as IP addresses. 1942 5. The action required is "drop" when any incoming packets are from 1943 "malicious-id". 1945 6. The IPsec-method is set to "ikeless". 1947 10.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company 1948 Web Server 1950 The third example scenario is to "Mitigate HTTP and HTTPS flood 1951 attacks on a company web server" using a DDoS-attack mitigation 1952 policy. Here, the time information is not set because the service 1953 provided by the network should be maintained at all times. If the 1954 packets sent by any sources are more than the set threshold, then the 1955 admin can set the percentage of the packets to be dropped to safely 1956 maintain the service. In this scenario, the source is set as "any" 1957 to block any sources which send abnormal amount of packets. The 1958 destination is set as "web_server01". Once the rule is set and 1959 delivered and enforced to the nsfs by the securiy controller, the 1960 NSFs will monitor the incoming packet amounts and the destination to 1961 act according to the rule set. The XML instance is described below: 1963 1964 1965 security_policy_for_ddos_attacks 1966 1967 100_packets_per_second 1968 1969 1970 1971 webservers 1972 1973 1974 100 1975 1976 1977 1978 1979 drop 1980 1981 1982 ikeless 1983 1984 1985 1987 Figure 27: An XML Example for DDoS-attack Mitigation 1989 DDoS-condition Firewall 1991 1. The policy name is "security_policy_for_ddos_attacks". 1993 2. The rule name is "100_packets_per_second". 1995 3. The destination target is "webservers". "webservers" is the key 1996 which represents the list containing information, such as IP 1997 addresses and ports, about web-servers. 1999 4. The rate limit exists to limit the incoming amount of packets per 2000 second. In this case the rate limit is "100" packets per second. 2001 This amount depends on the packet receiving capacity of the 2002 server devices. 2004 5. The Source-target is all sources which send abnormal amount of 2005 packets. 2007 6. The action required is to "drop" packet reception is more than 2008 100 packets per second. 2010 7. The IPsec-method is set to "ikeless". 2012 11. Security Considerations 2014 The data model for the I2NSF Consumer-Facing Interface is based on 2015 the I2NSF framework [RFC8329], so the same security considerations 2016 with the I2NSF framework should be included in this document. The 2017 data model needs a secure communication channel to protect the 2018 Consumer-Facing Interface between the I2NSF User and Security 2019 Controller. 2021 12. IANA Considerations 2023 This document requests IANA to register the following URI in the 2024 "IETF XML Registry" [RFC3688]: 2026 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2027 Registrant Contact: The I2NSF. 2028 XML: N/A; the requested URI is an XML namespace. 2030 This document requests IANA to register the following YANG module in 2031 the "YANG Module Names" registry [RFC7950]. 2033 name: ietf-i2nsf-cfi-policy 2034 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2035 prefix: cfi-policy 2036 reference: RFC 7950 2038 13. References 2040 13.1. Normative References 2042 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2043 Information Models and Data Models", RFC 3444, 2044 DOI 10.17487/RFC3444, January 2003, 2045 . 2047 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2048 DOI 10.17487/RFC3688, January 2004, 2049 . 2051 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2052 the Network Configuration Protocol (NETCONF)", RFC 6020, 2053 DOI 10.17487/RFC6020, October 2010, 2054 . 2056 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2057 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 2058 January 2011, . 2060 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2061 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2062 . 2064 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2065 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2066 . 2068 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2069 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2070 May 2017, . 2072 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2073 and J. Jeong, "Interface to Network Security Functions 2074 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2075 DOI 10.17487/RFC8192, July 2017, 2076 . 2078 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2079 Kumar, "Framework for Interface to Network Security 2080 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2081 . 2083 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2084 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2085 . 2087 13.2. Informative References 2089 [client-facing-inf-req] 2090 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 2091 S., and L. Xia, "Requirements for Client-Facing Interface 2092 to Security Controller", draft-ietf-i2nsf-client-facing- 2093 interface-req-05 (work in progress), May 2018. 2095 [i2nsf-capability-im] 2096 Xia, L., Strassner, J., Basile, C., and D. Lopez, 2097 "Information Model of NSFs Capabilities", draft-ietf- 2098 i2nsf-capability-04 (work in progress), October 2018. 2100 [i2nsf-ipsec] 2101 Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 2102 Garcia, "Software-Defined Networking (SDN)-based IPsec 2103 Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow- 2104 protection-04 (work in progress), March 2019. 2106 [i2nsf-terminology] 2107 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 2108 Birkholz, "Interface to Network Security Functions (I2NSF) 2109 Terminology", draft-ietf-i2nsf-terminology-07 (work in 2110 progress), January 2019. 2112 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- 2113 dm-03 2115 The following changes have been made from draft-ietf-i2nsf-consumer- 2116 facing-interface-dm-03: 2118 o This version added an I2NSF IPsec field for configuration and 2119 state data for IPsec management (i.e., IPsec method such as IKE 2120 and IKEless [i2nsf-ipsec]) in the I2NSF framework. 2122 Appendix B. Acknowledgments 2124 This work was supported by Institute for Information & communications 2125 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 2126 (No.R-20160222-002755, Cloud based Security Intelligence Technology 2127 Development for the Customized Security Service Provisioning). 2129 Appendix C. Contributors 2131 This document is made by the group effort of I2NSF working group. 2132 Many people actively contributed to this document, such as Mahdi F. 2133 Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their 2134 contributions. 2136 The following are co-authors of this document: 2138 Hyoungshick Kim 2139 Department of Software 2140 2066 Seo-ro Jangan-gu 2141 Suwon, Gyeonggi-do 16419 2142 Republic of Korea 2144 EMail: hyoung@skku.edu 2146 Seungjin Lee 2147 Department of Electrical and Computer Engineering 2148 2066 Seo-ro Jangan-gu 2149 Suwon, Gyeonggi-do 16419 2150 Republic of Korea 2152 EMail: jine33@skku.edu 2154 Jinyong Tim Kim 2155 Department of Electrical and Computer Engineering 2156 2066 Seo-ro Jangan-gu 2157 Suwon, Gyeonggi-do 16419 2158 Republic of Korea 2160 EMail: timkim@skku.edu 2162 Anil Lohiya 2163 Juniper Networks 2164 1133 Innovation Way 2165 Sunnyvale, CA 94089 2166 US 2168 EMail: alohiya@juniper.net 2170 Dave Qi 2171 Bloomberg 2172 731 Lexington Avenue 2173 New York, NY 10022 2174 US 2176 EMail: DQI@bloomberg.net 2178 Nabil Bitar 2179 Nokia 2180 755 Ravendale Drive 2181 Mountain View, CA 94043 2182 US 2184 EMail: nabil.bitar@nokia.com 2186 Senad Palislamovic 2187 Nokia 2188 755 Ravendale Drive 2189 Mountain View, CA 94043 2190 US 2192 EMail: senad.palislamovic@nokia.com 2194 Liang Xia 2195 Huawei 2196 101 Software Avenue 2197 Nanjing, Jiangsu 210012 2198 China 2200 EMail: Frank.Xialiang@huawei.com 2202 Authors' Addresses 2204 Jaehoon Paul Jeong 2205 Department of Software 2206 Sungkyunkwan University 2207 2066 Seobu-Ro, Jangan-Gu 2208 Suwon, Gyeonggi-Do 16419 2209 Republic of Korea 2211 Phone: +82 31 299 4957 2212 Fax: +82 31 290 7996 2213 EMail: pauljeong@skku.edu 2214 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2216 Eunsoo Kim 2217 Department of Electrical and Computer Engineering 2218 Sungkyunkwan University 2219 2066 Seobu-Ro, Jangan-Gu 2220 Suwon, Gyeonggi-Do 16419 2221 Republic of Korea 2223 Phone: +82 31 299 4104 2224 EMail: eskim86@skku.edu 2225 URI: http://seclab.skku.edu/people/eunsoo-kim/ 2227 Tae-Jin Ahn 2228 Korea Telecom 2229 70 Yuseong-Ro, Yuseong-Gu 2230 Daejeon 305-811 2231 Republic of Korea 2233 Phone: +82 42 870 8409 2234 EMail: taejin.ahn@kt.com 2236 Rakesh Kumar 2237 Juniper Networks 2238 1133 Innovation Way 2239 Sunnyvale, CA 94089 2240 USA 2242 EMail: rkkumar@juniper.net 2243 Susan Hares 2244 Huawei 2245 7453 Hickory Hill 2246 Saline, MI 48176 2247 USA 2249 Phone: +1-734-604-0332 2250 EMail: shares@ndzh.com