idnits 2.17.1 draft-ietf-i2nsf-consumer-facing-interface-dm-06.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 53 instances of too long lines in the document, the longest one being 31 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 555 has weird spacing: '...on-type ide...' == Line 598 has weird spacing: '...assword ian...' == Line 605 has weird spacing: '...er-name str...' == Line 609 has weird spacing: '...rt-type ide...' == Line 612 has weird spacing: '... method ide...' == (5 more instances...) -- The document date (July 24, 2019) is 1737 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 2561, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 2578, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3444 ** Downref: Normative reference to an Informational RFC: RFC 8192 ** Downref: Normative reference to an Informational RFC: RFC 8329 Summary: 4 errors (**), 0 flaws (~~), 9 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: January 25, 2020 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 July 24, 2019 13 I2NSF Consumer-Facing Interface YANG Data Model 14 draft-ietf-i2nsf-consumer-facing-interface-dm-06 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 January 25, 2020. 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 . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . 11 76 5.4. Policy User . . . . . . . . . . . . . . . . . . . . . . . 12 77 5.5. Policy Management Authentication Method . . . . . . . . . 13 78 6. Information Model for Policy Endpoint Groups . . . . . . . . 14 79 6.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 15 80 6.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 16 81 6.3. Location Group . . . . . . . . . . . . . . . . . . . . . 16 82 7. Information Model for Threat Prevention . . . . . . . . . . . 17 83 7.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 18 84 7.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . 49 89 10.1. DB Registration: Information of Positions and Devices 90 (Endpoint Group) . . . . . . . . . . . . . . . . . . . . 49 91 10.2. Scenario 1: Block SNS Access during Business Hours . . . 50 92 10.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to 93 a Company . . . . . . . . . . . . . . . . . . . . . . . 52 94 10.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a 95 Company Web Server . . . . . . . . . . . . . . . . . . . 53 97 11. Security Considerations . . . . . . . . . . . . . . . . . . . 55 98 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 100 13.1. Normative References . . . . . . . . . . . . . . . . . . 55 101 13.2. Informative References . . . . . . . . . . . . . . . . . 56 102 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing- 103 interface-dm-05 . . . . . . . . . . . . . . . . . . 58 104 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 58 105 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 59 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 108 1. Introduction 110 In a framework of Interface to Network Security Functions (I2NSF), 111 each vendor can register their NSFs using a Developer's Management 112 System (DMS). Assuming that vendors also provide the front-end web 113 applications registered with an I2NSF User, the Consumer-Facing 114 Interface is required because the web applications developed by each 115 vendor need to have a standard interface specifying the data types 116 used when the I2NSF User and Security Controller communicate using 117 this interface. Therefore, this document specifies the required 118 information, their data types, and encoding schemes so that high- 119 level security policies (or configuration information for security 120 policies) can be transferred to the Security Controller through the 121 Consumer-Facing Interface. These policies can easily be translated 122 by the Security Controller into low-level security policies. The 123 Security Controller delivers the translated policies to Network 124 Security Functions (NSFs) according to their respective security 125 capabilities for the required 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 [RFC8407], 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 YANG tree 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. These rules are 226 defined for 1) communication between two Endpoint Groups, 227 2) for preventing communication with externally or 228 internally identified threats, and 3) for implementing 229 business requirement such as controlling access to internal 230 or external resources for meeting regulatory compliance or 231 business objectives. An organization may restrict certain 232 communication between a set of user and applications for 233 example. The threats may be from threat feeds obtained 234 from external sources or dynamically identified by using 235 specialty devices in the network. Rule conflict analysis 236 should be triggered by the monitoring service to perform an 237 exhaustive detection of anomalies among the configuration 238 rules installed into the security functions. 240 +--rw i2nsf-cfi-policy* [policy-name] 241 +--rw policy-name string 242 +--rw rule* [rule-name] 243 +--rw multi-tenancy 244 +--rw endpoint-group 245 +--rw threat-prevention 247 Figure 2: Policy YANG Data Tree 249 A policy is a container of Rules. In order to express a Rule, a Rule 250 must have complete information such as where and when a policy needs 251 to be applied. This is done by defining a set of managed objects and 252 relationship among them. A Policy Rule may be related segmentation, 253 threat mitigation or telemetry data collection from an NSF in the 254 network, which will be specified as the sub-model of the policy model 255 in the subsequent sections. Figure 3 shows the YANG tree of the Rule 256 object. The rule object SHALL have the following information: 258 Name: This field identifies the name of this object. 260 Event: This field includes the information to determine whether 261 the Rule Condition can be evaluated or not. See details in 262 Section 3.1. 264 Condition: This field contains all the checking conditions to 265 apply to the objective traffic. See details in 266 Section 4.2. 268 Action: This field identifies the action taken when a rule is 269 matched. There is always an implicit action to drop 270 traffic if no rule is matched for a traffic type. See 271 details in Section 4.3. 273 IPsec-Method: This field contains the information about IPsec 274 method type. There are two types such as IPsec-IKE and 275 IPsec-IKEless [i2nsf-ipsec]. 277 Owner: This field contains the onwer of the rule. For example, 278 the person who created it, and eligible for modifying it. 280 +--rw rule* [rule-name] 281 +--rw rule-name string 282 +--rw event 283 +--rw (condition)? 284 +--rw action 285 +--rw ipsec-method 286 +--rw owner identityref 288 Figure 3: YANG Data Tree for Rule 290 4.1. Event Sub-model 292 The Event Object contains information related to scheduling a Rule. 293 The Rule could be activated based on a set time or security event. 294 Figure 4 shows the YANG tree of the Event object. Event object SHALL 295 have following information: 297 Security-event: This field identifies for which security event 298 the policy is enforced. The examples of security events 299 are: "DDOS", "spyware", "trojan", and "ransomware". 301 Enforce-type: This field identifies whether the event of 302 triggering policy enforcement is "Admin" or "Time". 304 Admin: This represents the enforcement type based on admin's 305 decision. 307 Time: This represents the security rule is enforced based on 308 begin-time and end-time information. 310 Frequency: This represents how frequent the rule should be 311 enforced. There are four options: "only-once", "daily", 312 "weekly" and "monthly". 314 +--rw event 315 +--rw security-event identityref 316 +--rw (enforce-type)? 317 | +--:(admin) 318 | | +--rw admin? identityref 319 | +--:(time) 320 | +--rw time-information 321 | +--rw begin-time? yang:date-and-time 322 | +--rw end-time? yang:date-and-time 323 +--rw frequency? enumeration 325 Figure 4: Event Sub-model YANG Data Tree 327 4.2. Condition Sub-model 329 This object represents Conditions that Security Administrator wants 330 to apply the checking on the traffic in order to determine whether 331 the set of actions in the Rule can be executed or not. The Condition 332 Sub-model consists of three different types of containers each 333 representing different cases, such as general firewall and DDoS- 334 mitigation cases, and a case when the condition is based on the 335 payload strings of packets. Each containers have source-target and 336 destination-target to represent the source and destination for each 337 case. Figure 5 shows the YANG tree of the Condition object. The 338 Condition Sub-model SHALL have following information: 340 Case (Firewall-condition): This field represents the general 341 firewall case, where a security admin can set up firewall 342 conditions using the information present in this field. 343 The source and destination is represented as firewall- 344 source and firewall-destination, each referring to the IP- 345 address-based groups defined in the endpoint-group. 347 DDoS-condition: This field represents the condition for DDoS 348 mitigation, where a security admin can set up DDoS 349 mitigation conditions using the information present in this 350 field. The source and destination is represented as ddos- 351 source and ddos-destination, each referring to the device- 352 groups defined and registered in the endpoint-group. 354 Custom-condition: This field contains the payload string 355 information. This information is useful when security rule 356 condition is based on the string contents of incoming or 357 outgoing packets. The source and destination is 358 represented as custon-source and custom-destination, each 359 referring to the payload-groups defined and registered in 360 the endpoint-group. 362 Threat-feed-condition: This field contains the information 363 obtained from threat-feeds (e.g., Palo-Alto, or RSA- 364 netwitness). This information is useful when security rule 365 condition is based on the existing threat reports gathered 366 by other sources. The source and destination is 367 represented as threat-feed-source and threat-feed- 368 destination. For clarity, threat-feed-source/destination 369 represent the source/destination of a target security 370 threat, not the information source/destination of a threat- 371 feed. 373 +--rw (condition)? 374 +--:(firewall-condition) 375 | +--rw firewall-source 376 | | +--rw src-target -> /../../user-group/name 377 | +--rw firewall-destination 378 | +--rw dest-target* -> /../../user-group/name 379 +--:(ddos-condition) 380 | +--rw ddos-source 381 | | +--rw src-target* -> /../../device-group/name 382 | +--rw ddos-destination 383 | | +--rw dest-target* -> /../../device-group/name 384 | +--rw rate-limit 385 | +--rw packet-per-second? uint16 386 +--:(custom-condition) 387 | +--rw custon-source 388 | | +--rw src-target* -> /../../payload-content/name 389 | +--rw custom-destination 390 | +--rw dest-target -> /../../payload-content/name 391 +--:(threat-feed-condition) 392 +--rw threat-feed-source 393 | +--rw src-target* -> /../../threat-feed-list/feed-name 394 +--rw threat-feed-destination 395 +--rw dest-target -> /../../threat-feed-list/feed-name 397 Figure 5: Condition Sub-model YANG Data Tree 399 4.3. Action Sub-model 401 This object represents actions that Security Admin wants to perform 402 based on certain traffic class. Figure 6 shows the YANG tree of the 403 Action object. The Action object SHALL have following information: 405 Primary-action: This field identifies the action when a rule is 406 matched by an NSF. The action could be one of "PASS", 407 "DROP", "ALERT", "RATE-LIMIT", and "MIRROR". 409 Secondary-action: This field identifies the action when a rule is 410 matched by an NSF. The action could be one of "log", 411 "syslog", "session-log". 413 +--rw action 414 +--rw primary-action identityref 415 +--rw secondary-action? identityref 417 Figure 6: Action Sub-model YANG Data Tree 419 5. Information Model for Multi-Tenancy 421 Multi-tenancy is an important aspect of any application that enables 422 multiple administrative domains in order to manage application 423 resources. An Enterprise organization may have multiple tenants or 424 departments such as Human Resources (HR), Finance, and Legal, with 425 each tenant having a need to manage their own Security Policies. In 426 a Service Provider, a tenant could represent a Customer that wants to 427 manage its own Security Policies. There are multiple managed objects 428 that constitute multi-tenancy aspects as shown in Figure 7. This 429 section lists these objects and the relationship among these objects. 430 Below diagram shows an example of multi-tenancy in an Enterprise 431 domain. 433 +-------------------+ 434 (Multi-Tenancy) | Domain | 435 |(e.g., Enterprise) | 436 +---------+---------+ 437 ^ 438 | 439 +--------------------+--------------------+ 440 | | | 441 +--------+-------+ +---------+--------+ +--------+--------+ 442 | Department 1 | | Department 2 | | Department n | 443 +--------+-------+ +---------+--------+ +--------+--------+ 444 ^ ^ ^ 445 | | | 446 +--------+--------+ +-----------------+ +--------+--------+ 447 | Sub-domain 1..n | | Sub-domain 1..n | | Sub-domain 1..n | 448 +--------+--------+ +--------+--------+ +--------+--------+ 449 ^ ^ ^ 450 | | | 451 +--------+--------+ +--------+--------+ +--------+--------+ 452 | Tenant 1..n | | Tenant 1..n | | Tenant 1..n | 453 +-----------------+ +-----------------+ +-----------------+ 455 Figure 7: Multi-tenancy Diagram 457 5.1. Policy Domain 459 This object defines a boundary for the purpose of policy management 460 within a Security Controller. This may vary based on how the 461 Security Controller is deployed and hosted. For example, if an 462 Enterprise hosts a Security Controller in their network; the domain 463 in this case could just be the one that represents that Enterprise. 464 But if a Cloud Service Provider hosts managed services, then a domain 465 could represent a single customer of that Provider. Figure 8 shows 466 the YANG tree of the Policy-Domain object. Multi-tenancy model 467 should be able to work in all such environments. The Policy-Domain 468 object SHALL have the following information: 470 Domain-name: Name of the domain of an organization or enterprise. 472 Address: Address information of the organization or enterprise. 474 Contact: Contact information of the organization or enterprise. 476 +--rw policy-domain* [domain-name] 477 +--rw domain-name identityref 478 +--rw address? string 479 +--rw contact? string 481 Figure 8: Policy Domain YANG Data Tree 483 5.2. Policy Tenant 485 This object defines an entity within an organization. The entity 486 could be a department or business unit within an Enterprise 487 organization that would like to manage its own Policies due to 488 regulatory compliance or business reasons. Figure 9 shows the YANG 489 tree of the Policy-Tenant object. The Policy-Tenant object SHALL 490 have the following information: 492 Tenant-type: This field represents the type of tenant within a 493 domain. In an enterprise, the examples of tenants could be 494 the departments or divisions, such as HR department and 495 Finance department. 497 +--rw policy-tenant* [tenant-name] 498 +--rw tenant-type identityref 500 Figure 9: Policy Tenant YANG Data Tree 502 5.3. Policy Role 504 This object defines a set of permissions assigned to a user in an 505 organization that wants to manage its own Security Policies. It 506 provides a convenient way to assign policy users to a job function or 507 a set of permissions within the organization. Figure 10 shows the 508 YANG tree of the Policy-Role object. The Policy-Role object SHALL 509 have the following information: 511 Role-type: "This represent the roles within the tenants, in order 512 to distinguish who may or may not have access to policies. 513 The role types include "user", "group", "other", and "all". 514 "user" "represents an individual where as group represents 515 a group of users. "All" means both the individual and the 516 group members, whereas "other" denotes anyone who is not a 517 specific individual or a member of a specific group. 519 +--rw policy-role* [role-name] 520 +--rw role-type identityref 522 Figure 10: Policy Role YANG Data Tree 524 5.4. Policy User 526 This object represents a unique identity of a user within an 527 organization. The identity authenticates with Security Controller 528 using credentials such as a password or token in order to perform 529 policy management. A user may be an individual, system, or 530 application requiring access to Security Controller. Figure 11 shows 531 the YANG tree of the Policy-User object. The Policy-User object 532 SHALL have the following information: 534 Name: Name of a user. 536 Password: User password for basic authentication. The crypto- 537 hash mechanism for this entry is ianach:crypt-hash. 539 Email: E-mail address of the user. 541 Access-profile: This represents the access profile for the user. 542 The access-profile is based on the permission-type and the 543 scope type defined. The permission-types include "no- 544 permission", read", "write", "execute", "read-and-write", 545 "read-and-execute", and "write-and-execute" 547 Scope-Type: This field identifies whether the user has domain- 548 wide or tenant-wide privileges. 550 +--rw policy-user* [name] 551 +--rw name string 552 +--rw password? ianach:crypt-hash 553 +--rw email? string 554 +--rw access-profile* [permission-type scope-type] 555 +--rw permission-type identityref 556 +--rw scope-type identityref 558 Figure 11: Policy User YANG Data Tree 560 5.5. Policy Management Authentication Method 562 This object represents authentication schemes supported by Security 563 Controller. Figure 12 shows the YANG tree of the Policy Management 564 Authentication Method onject. This Policy-Management-Authentication- 565 Method object SHALL have the following information: 567 Policy-mgmt-auth-method-instance: This field represent the 568 authentication instances. Each instance is based on either 569 client authentication, server authentication or both 570 (mutual) authentication. 572 Policy-mgmt-auth-method: This represents the choices of 573 authentication methods. Each instance of authentication 574 consists of authentication methods chosen by an entity, 575 such as a security admin. There are "Password-based", 576 "token-based". "certificate-based", and "IPsec" 577 authentication methods. 579 Password-list: This list contains the passwords that are 580 encrypted using crypto-has algorithm (ianach:crypt-hash). 582 Token-list: This list contains the information such as the access 583 tokens and a token server. 585 Cert-server-list: This list contains the certification server 586 information such as server address (IPv4 and IPv6) and 587 certificate types. 589 IPsec: This list has IPsec method types based on the identities 590 defined. There are two types such as IPsec-IKE and IPsec- 591 IKEless. 593 +--rw policy-mgmt-auth-method-instance* [auth-instance-type] 594 +--rw auth-instance-type identityref 595 +--rw (policy-mgmt-auth-method)? 596 +--:(password-based) 597 | +--rw password-list* [password] 598 | +--rw password ianach:crypt-hash 599 +--:(token-based) 600 | +--rw token-list* [token] 601 | +--rw token string 602 | +--rw token-server? inet:ipv4-address 603 +--:(certificate-based) 604 | +--rw cert-server-list* [cert-server-name] 605 | +--rw cert-server-name string 606 | +--rw cert-server-ipv4? inet:ipv4-address 607 | +--rw cert-server-ipv6? inet:ipv6-address 608 | +--rw certificate* [cert-type] 609 | +--rw cert-type identityref 610 +--:(ipsec) 611 +--rw ipsec-method* [method] 612 +--rw method identityref 614 Figure 12: Policy Management Authentication Method YANG Data Tree 616 6. Information Model for Policy Endpoint Groups 618 The Policy Endpoint Group is a very important part of building User- 619 Construct based policies. A Security Administrator would create and 620 use these objects to represent a logical entity in their business 621 environment, where a Security Policy is to be applied. There are 622 multiple managed objects that constitute a Policy's Endpoint Group as 623 shown in Figure 13. Figure 14 shows the YANG tree of the Endpoint- 624 Group object. This section lists these objects and relationship 625 among them. 627 +-------------------+ 628 | Endpoint Group | 629 +---------+---------+ 630 ^ 631 | 632 +--------------+----------------+ 633 1..n | 1..n | 1..n | 634 +-----+----+ +------+-----+ +-------+------+ 635 |User-group| |Device-group| |Location-group| 636 +----------+ +------------+ +--------------+ 638 Figure 13: Endpoint Group Diagram 640 +--rw endpoint-group 641 +--rw user-group* [name] 642 ... 643 +--rw device-group* [name] 644 ... 645 +--rw location-group* [name] 646 ... 648 Figure 14: Endpoint Group YANG Data Tree 650 6.1. User Group 652 This object represents a User-Group. Figure 15 shows the YANG tree 653 of the User-Group object. The User-Group object SHALL have the 654 following information: 656 Name: This field identifies the name of this object. 658 IP-address: This represents the IPv4 address of a user in the 659 user group. 661 range-ipv4-address: This represents the IPv4 address of a user in 662 the user gorup. 664 range-ipv6-address: This represents the IPv6 address of a user in 665 the user gorup. 667 +--rw user-group* [name] 668 +--rw name string 669 +--rw (match-type)? 670 +--:(exact-match-ipv4) 671 | +--rw ip-address* inet:ipv4-address 672 +--:(exact-match-ipv6) 673 | +--rw ip-address* inet:ipv4-address 674 +--:(range-match-ipv4) 675 | +--rw range-ipv4-address* [start-ipv4-address end-ipv4-address] 676 | +--rw start-ipv4-address inet:ipv4-address 677 | +--rw end-ipv4-address inet:ipv4-address 678 +--:(range-match-ipv6) 679 +--rw range-ipv6-address* [start-ipv6-vaddress end-ipv6-address] 680 +--rw start-ipv6-address inet:ipv6-address 681 +--rw end-ipv6-address inet:ipv6-address 683 Figure 15: User Group YANG Data Tree 685 6.2. Device Group 687 This object represents a Device-Group. Figure 16 shows the YANG tree 688 of the Device-group object.The Device-Group object SHALL have the 689 following information: 691 Name: This field identifies the name of this object. 693 IP-address: This represents the IPv4 address of a device in the 694 device group. 696 range-ipv4-address: This represents the IPv4 address of a device 697 in the device gorup. 699 range-ipv6-address: This represents the IPv6 address of a device 700 in the device gorup. 702 Protorol: This represents the communication protocols used by the 703 devices. The protocols are "SSH", "FTP", "SMTP", "HTTP", 704 "HTTPS", and etc. 706 +--rw device-group* [name] 707 +--rw name string 708 +--rw (match-type)? 709 +--:(exact-match-ipv4) 710 | +--rw ip-address* inet:ipv4-address 711 +--:(exact-match-ipv6) 712 | +--rw ip-address* inet:ipv4-address 713 +--:(range-match-ipv4) 714 | +--rw range-ipv4-address* [start-ipv4-address end-ipv4-address] 715 | +--rw start-ipv4-address inet:ipv4-address 716 | +--rw end-ipv4-address inet:ipv4-address 717 +--:(range-match-ipv6) 718 +--rw range-ipv6-address* [start-ipv6-vaddress end-ipv6-address] 719 +--rw start-ipv6-address inet:ipv6-address 720 +--rw end-ipv6-address inet:ipv6-address 722 Figure 16: Device Group YANG Data Tree 724 6.3. Location Group 726 This object represents a location group based on either tag or other 727 information. Figure 17 shows the YANG tree of the Location-Group 728 object. The Location-Group object SHALL have the following 729 information: 731 Name: This field identifies the name of this object. 733 geo-ip-ipv4: This field represents the IPv4 Geo-ip of a location. 735 geo-ip-ipv6: This field represents the IPv6 Geo-ip of a location. 737 continent: This field represents the continent where the location 738 group member is at. 740 +--rw location-group* [name] 741 +--rw name string 742 +--rw geo-ip-ipv4 inet:ipv4-address 743 +--rw geo-ip-ipv6 inet:ipv6-address 744 +--rw continent? identityref 746 Figure 17: Location Group YANG Data Tree 748 7. Information Model for Threat Prevention 750 The threat prevention plays an important part in the overall security 751 posture by reducing the attack surfaces. This information could come 752 from various threat feeds (i.e., sources for obtaining the threat 753 information), such as EmergingThreats.com or AlienVault.com. There 754 are multiple managed objects that constitute this category. This 755 section lists these objects and relationship among them. Figure 19 756 shows the YANG tree of a Threat-Prevention object. 758 +-------------------+ 759 | Threat Prevention | 760 +---------+---------+ 761 ^ 762 | 763 +---------+---------+ 764 1..n | 1..n | 765 +------+------+ +--------+--------+ 766 | Threat-feed | | payload-content | 767 +-------------+ +-----------------+ 769 Figure 18: Threat Prevention Diagram 771 +--rw threat-prevention 772 +--rw threat-feed-list* [name] 773 ... 774 +--rw payload-content* [name] 775 ... 777 Figure 19: Threat Prevention YANG Data Tree 779 7.1. Threat Feed 781 This object represents a threat feed which provides signatures of 782 malicious activities. Figure 20 shows the YANG tree of a Threat- 783 feed-list. The Threat-Feed object SHALL have the following 784 information: 786 Feed-name: This field identifies the name of this object. 788 Feed-Server-ipv4: This represents the IPv4 server address of the 789 feed provider, it may be external or local servers. 791 Feed-Server-ipv6: This represents the IPv6 server address of the 792 feed provider, it may be external or local servers. 794 Feed-description: This is the description of the threat feed. 795 The descriptions should have clear indication of the 796 security attack such as attack type (e.g., APT) and file 797 types used (e.g., executable malware). 799 Threat-file-types: This field identifies the information about 800 the file types identified and reported by the threat-feed. 802 signatures: This field contains the signatures of malicious 803 programs or activities provided by the threat-feed. The 804 examples of signature types are "YARA", "SURICATA", and 805 "SNORT". 807 +--rw threat-prevention 808 +--rw threat-feed-list* [feed-name] 809 +--rw feed-name identityref 810 +--rw feed-server-ipv4? inet:ipv4-address 811 +--rw feed-server-ipv6? inet:ipv6-address 812 +--rw feed-description? string 813 +--rw threat-file-types* identityref 814 +--rw signatures* identityref 816 Figure 20: Threat Feed YANG Data Tree 818 7.2. Payload Content 820 This object represents a custom list created for the purpose of 821 defining exception to threat feeds. Figure 21 shows the YANG tree of 822 a Payload-content list. The Payload-Content object SHALL have the 823 following information: 825 Name: This field identifies the name of this object. For 826 example, the name "backdoor" indicates the payload content 827 is related to backdoor attack. 829 payload-description: This represents the description of how the 830 payload content is related to a security attack. 832 Content: This contains the payload contents, which are involed in 833 a security attack, as strings. 835 +--rw payload-content* [name] 836 +--rw name string 837 +--rw payload-description string 838 +--rw content* string 840 Figure 21: Payload Content in YANG Data Tree 842 8. Role-based Acess Control (RBAC) 844 Role-Based Access Control (RBAC) provides a powerful and centralized 845 control within a network. It is a policy neutral access control 846 mechanism defined around roles and privileges. The components of 847 RBAC, such as role-permissions, user-role and role-role 848 relationships, make it simple to perform user assignments. 850 +--------------+ 851 | | 852 | User 1 + (has many) 853 | |\ 854 +--------------+ \ +---------------+ +-------------+ 855 . \ | | (has many) | | 856 . --->+ List of roles +----------->+ Permissions | 857 +--------------+ / | | | | 858 | | / +---------------+ +-------------+ 859 | User n +/ 860 | | (has many) 861 +--------------+ 863 Figure 22: Role-based Acess Control Diagram 865 As shown in Figure 22, a role represents a collection of permissions 866 (e.g., accessing a file server or other particular resources). A 867 role may be assigned to one or multiple users. Both roles and 868 permissions can be organized in a hirarchy. A role may consists of 869 other roles and permissions. 871 Following are the steps required to build RBAC: 873 1. Defining roles and permissions. 875 2. Establishing relations among roles and permissions. 877 3. Defining users. 879 4. Associating rules with roles and permissions. 881 5. assigning roles to users. 883 9. YANG Data Model for Security Policies for Consumer-Facing Interface 885 The main objective of this data model is to provide both an 886 information model and the corresponding YANG data model of I2NSF 887 Consumer-Facing Interface. This interface can be used to deliver 888 control and management messages between an I2NSF User and Security 889 Controller for the I2NSF User's high-level security policies. 891 The semantics of the data model must be aligned with the information 892 model of the Consumer-Facing Interface. The transformation of the 893 information model was performed so that this YANG data model can 894 facilitate the efficient delivery of the control or management 895 messages. 897 This data model is designed to support the I2NSF framework that can 898 be extended according to the security needs. In other words, the 899 model design is independent of the content and meaning of specific 900 policies as well as the implementation approach. This document 901 suggests a VoIP/VoLTE security service as a use case for policy rule 902 generation. 904 This section describes a YANG data model for Consumer-Facing 905 Interface, based on the information model of Consumer-Facing 906 Interface to Security Controller. 908 file "ietf-cfi-policy.yang" 909 module ietf-i2nsf-cfi-policy { 910 yang-version 1.1; 911 namespace 912 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; 913 prefix 914 cfi-policy; 916 import ietf-yang-types{ 917 prefix yang; 918 reference 919 "Section 3 of RFC 6991"; 920 } 922 import ietf-inet-types{ 923 prefix inet; 924 reference 925 "Section 4 of RFC 6991"; 926 } 928 import iana-crypt-hash { 929 prefix ianach; 930 } 932 organization 933 "IETF I2NSF (Interface to Network Security Functions) 934 Working Group"; 936 contact 937 "WG Web: 938 WG List: 940 WG Chair: Adrian Farrel 941 943 WG Chair: Linda Dunbar 944 946 Editor: Jaehoon Paul Jeong 947 "; 949 description 950 "This module is a YANG module for Consumer-Facing Interface. 951 Copyright (c) 2018 IETF Trust and the persons identified as 952 authors of the code. All rights reserved. 953 Redistribution and use in source and binary forms, with or 954 without modification, is permitted pursuant to, and subject 955 to the license terms contained in, the Simplified BSD License 956 set forth in Section 4.c of the IETF Trust's Legal Provisions 957 Relating to IETF Documents 958 (http://trustee.ietf.org/license-info). 959 This version of this YANG module is part of RFC XXXX; see 960 the RFC itself for full legal notices."; 962 revision "2019-07-21"{ 963 description "latest revision"; 964 reference 965 "draft-ietf-consumer-facing-interface-dm-03"; 967 } 969 identity permission-type { 970 description 971 "Base identity for the permission types."; 972 } 973 identity no-permission { 974 base permission-type; 975 description 976 "Identity for no-permission."; 977 } 978 identity read { 979 base permission-type; 980 description 981 "Identity for read permission."; 982 } 983 identity write { 984 base permission-type; 985 description 986 "Identity for write permission."; 987 } 988 identity execute { 989 base permission-type; 990 description 991 "Identity for execute permission."; 992 } 993 identity write-and-execute { 994 base permission-type; 995 description 996 "Identity for write & execute permission."; 997 } 998 identity read-and-execute { 999 base permission-type; 1000 description 1001 "Identity for read & execute permission."; 1002 } 1003 identity read-and-write { 1004 base permission-type; 1005 description 1006 "Identity for read & write permission."; 1007 } 1009 identity scope-type { 1010 description 1011 "Base Identity for scope-type."; 1012 } 1013 identity tenant-wide { 1014 base scope-type; 1015 description 1016 "Base Identity for tenant-wide scope type."; 1017 } 1018 identity domain-wide { 1019 base scope-type; 1020 description 1021 "Base Identity for domain-wide scope type."; 1022 } 1024 identity malware-file-type { 1025 description 1026 "Base identity for malware file types."; 1027 } 1028 identity executable-file { 1029 base malware-file-type; 1030 description 1031 "Identity for executable file types."; 1032 } 1033 identity doc-file { 1034 base malware-file-type; 1035 description 1036 "Identity for Microsoft document file types."; 1037 } 1038 identity html-app-file { 1039 base malware-file-type; 1040 description 1041 "Identity for html application file types."; 1042 } 1043 identity javascript-file { 1044 base malware-file-type; 1045 description 1046 "Identity for Javascript file types."; 1047 } 1048 identity pdf-file { 1049 base malware-file-type; 1050 description 1051 "Identity for pdf file types."; 1052 } 1053 identity dll-file { 1054 base malware-file-type; 1055 description 1056 "Identity for dll file types."; 1057 } 1058 identity msi-file { 1059 base malware-file-type; 1060 description 1061 "Identity for Microsoft installer file types."; 1062 } 1063 identity security-event-type { 1064 description 1065 "Base identity for security event types."; 1066 } 1067 identity ddos { 1068 base malware-file-type; 1069 description 1070 "Identity for DDoS event types."; 1071 } 1072 identity spyware { 1073 base malware-file-type; 1074 description 1075 "Identity for spyware event types."; 1076 } 1077 identity trojan { 1078 base malware-file-type; 1079 description 1080 "Identity for Trojan infection event types."; 1081 } 1082 identity ransomware { 1083 base malware-file-type; 1084 description 1085 "Identity for ransomware infection event types."; 1086 } 1088 identity i2nsf-ipsec { 1089 description 1090 "Base identity for IPsec method types."; 1091 } 1092 identity ipsec-ike { 1093 base i2nsf-ipsec; 1094 description 1095 "Identity for ipsec-ike."; 1096 } 1098 identity ipsec-ikeless { 1099 base i2nsf-ipsec; 1100 description 1101 "Identity for ipsec-ikeless."; 1102 } 1104 identity continent { 1105 description 1106 "Base Identity for continent types."; 1107 } 1109 identity africa { 1110 base continent; 1111 description 1112 "Identity for africa."; 1113 } 1114 identity asia { 1115 base continent; 1116 description 1117 "Identity for asia."; 1118 } 1119 identity europe { 1120 base continent; 1121 description 1122 "Identity for europe."; 1123 } 1124 identity north-america { 1125 base continent; 1126 description 1127 "Identity for north-america."; 1128 } 1129 identity south-america { 1130 base continent; 1131 description 1132 "Identity for south-america."; 1133 } 1134 identity oceania { 1135 base continent; 1136 description 1137 "Identity for Oceania"; 1138 } 1140 identity certificate-type { 1141 description 1142 "Base Identity for certificate-type. 1143 CRT certificate extension, which is used for certificates. 1144 The certificates may be encoded as binary DER or as ASCII PEM. 1145 The CER and CRT extensions are nearly synonymous. Most common 1146 among *nix systems. CER certificate extension, which is an 1147 alternate form of .crt (Microsoft Convention) You can use MS to 1148 convert .crt to .cer (.both DER encoded .cer, or base64[PEM] 1149 encoded .cer). The KEY extension is used both for public and 1150 private PKCS#8 keys. The keys may be encoded as binary DER or 1151 as ASCII PEM."; 1152 } 1153 identity cer { 1154 base certificate-type; 1155 description 1156 "Identity for '.cer' certificates."; 1157 } 1158 identity crt { 1159 base certificate-type; 1160 description 1161 "Identity for '.crt' certificates."; 1162 } 1163 identity key { 1164 base certificate-type; 1165 description 1166 "Identity for '.key' certificates."; 1167 } 1169 identity enforce-type { 1170 description 1171 "This identity represents the event of 1172 policy enforcement trigger type."; 1173 } 1174 identity admin { 1175 base enforce-type; 1176 description 1177 "The identity for policy enforcement by admin."; 1178 } 1179 identity time { 1180 base enforce-type; 1181 description 1182 "The identity for policy enforcement based on time."; 1183 } 1185 identity protocol-type { 1186 description 1187 "This identity represents the protocol types."; 1188 } 1189 identity ftp { 1190 base protocol-type; 1191 description 1192 "The identity for ftp protocol."; 1193 } 1194 identity ssh { 1195 base protocol-type; 1196 description 1197 "The identity for ssh protocol."; 1198 } 1199 identity telnet { 1200 base protocol-type; 1201 description 1202 "The identity for telnet."; 1203 } 1204 identity smtp { 1205 base protocol-type; 1206 description 1207 "The identity for smtp."; 1208 } 1209 identity sftp { 1210 base protocol-type; 1211 description 1212 "The identity for sftp."; 1213 } 1214 identity http { 1215 base protocol-type; 1216 description 1217 "The identity for http."; 1218 } 1219 identity https { 1220 base protocol-type; 1221 description 1222 "The identity for https."; 1223 } 1224 identity pop3 { 1225 base protocol-type; 1226 description 1227 "The identity for pop3."; 1228 } 1229 identity nat { 1230 base protocol-type; 1231 description 1232 "The identity for nat."; 1233 } 1235 identity primary-action { 1236 description 1237 "This identity represents the primary actions, such as 1238 PASS, DROP, ALERT, RATE-LIMIT, and MIRROR."; 1239 } 1240 identity pass { 1241 base primary-action; 1242 description 1243 "The identity for pass."; 1244 } 1245 identity drop { 1246 base primary-action; 1247 description 1248 "The identity for drop."; 1249 } 1250 identity alert { 1251 base primary-action; 1252 description 1253 "The identity for alert."; 1254 } 1255 identity rate-limit { 1256 base primary-action; 1257 description 1258 "The identity for rate-limit."; 1259 } 1260 identity mirror { 1261 base primary-action; 1262 description 1263 "The identity for mirroring."; 1264 } 1266 identity secondary-action { 1267 description 1268 "This field identifies additional actions if a rule is 1269 matched. This could be one of 'LOG', 'SYSLOG', 1270 'SESSION-LOG', etc."; 1271 } 1272 identity log { 1273 base secondary-action; 1274 description 1275 "The identity for logging."; 1276 } 1277 identity syslog { 1278 base secondary-action; 1279 description 1280 "The identity for system logging."; 1281 } 1282 identity session-log { 1283 base secondary-action; 1284 description 1285 "The identity for session logging."; 1286 } 1288 identity role-type { 1289 description 1290 "This is the base identity for the roles."; 1291 } 1292 identity user { 1293 base role-type; 1294 description 1295 "This represents the identity of the user role."; 1296 } 1297 identity group { 1298 base role-type; 1299 description 1300 "This represents the identity of any member of the 1301 security policy's defined group."; 1302 } 1303 identity other { 1304 base role-type; 1305 description 1306 "This represents the identity of anyone else."; 1307 } 1308 identity all { 1309 base role-type; 1310 description 1311 "This represents the identity of everyone 1312 (i.e., user, group, and other)."; 1313 } 1315 identity owner { 1316 description 1317 "This is the base identity for the owner"; 1318 } 1319 identity dept-head { 1320 base owner; 1321 description 1322 "This represents the identity of the head of department."; 1323 } 1324 identity manager { 1325 base owner; 1326 description 1327 "This represents the identity of the manager of the department."; 1328 } 1329 identity employee { 1330 base owner; 1331 description 1332 "This represents the identity of department employees."; 1333 } 1334 identity sec-head { 1335 base owner; 1336 description 1337 "This represents the identity of the head of security."; 1338 } 1339 identity sec-admin { 1340 base owner; 1341 description 1342 "This represents the identity of security admin."; 1343 } 1345 identity tenant-type { 1346 description 1347 "This is the base identity for the tenants 1348 to represent the ownership of the security policies."; 1349 } 1350 identity human-resources { 1351 base tenant-type; 1352 description 1353 "This represents the identity of the human resources 1354 department or division."; 1355 } 1356 identity marketing { 1357 base tenant-type; 1358 description 1359 "This represents the identity of the marketing 1360 department or division."; 1361 } 1362 identity customer-service { 1363 base tenant-type; 1364 description 1365 "This represents the identity of customer service 1366 department or division."; 1367 } 1368 identity research { 1369 base tenant-type; 1370 description 1371 "This represents the identity of research 1372 department or division."; 1373 } 1374 identity finance { 1375 base tenant-type; 1376 description 1377 "This represents the identity of finance 1378 department or division."; 1379 } 1381 identity domain { 1382 description 1383 "This represents the base identity of different domains."; 1384 } 1385 identity enterprise { 1386 base domain; 1387 description 1388 "This represents the identity of an enterprise domain."; 1389 } 1391 identity signature-type { 1392 description 1393 "This represents the base identity for signature types."; 1394 } 1395 identity signature-yara { 1396 base signature-type; 1397 description 1398 "This represents the YARA signatures."; 1400 } 1401 identity signature-snort { 1402 base signature-type; 1403 description 1404 "This represents the SNORT signatures."; 1405 } 1406 identity signature-suricata { 1407 base signature-type; 1408 description 1409 "This represents the SURICATA signatures."; 1410 } 1412 identity threat-feed-type { 1413 description 1414 "This represents the base identity for threat-feed."; 1415 } 1416 identity palo-alto { 1417 base threat-feed-type; 1418 description 1419 "This represents Palo-Alto threat-feed."; 1420 } 1421 identity rsa-netwitness { 1422 base threat-feed-type; 1423 description 1424 "This represents RSA-netwitness threat-feed."; 1425 } 1426 identity fireeye { 1427 base threat-feed-type; 1428 description 1429 "This represents FireEye threat-feed."; 1430 } 1431 identity alienvault { 1432 base threat-feed-type; 1433 description 1434 "This represents Alienvault threat-feed."; 1435 } 1436 identity auth-type { 1437 description 1438 "The base identity for authentication type."; 1439 } 1440 identity auth-type-server { 1441 base auth-type; 1442 description 1443 "This represents the server authentication."; 1444 } 1445 identity auth-type-client { 1446 base auth-type; 1447 description 1448 "This represents the client authentication."; 1449 } 1450 identity auth-type-mutual { 1451 base auth-type; 1452 description 1453 "This represents the both server and client 1454 authentication."; 1455 } 1457 identity auth-method-type { 1458 description 1459 "Base idendity for authentication-methods"; 1460 } 1462 identity password-based { 1463 base auth-method-type; 1464 description 1465 "This is the identity for the password-based authetication type."; 1466 } 1467 identity token-based { 1468 base auth-method-type; 1469 description 1470 "This is the identity for the token-based authetication type."; 1471 } 1472 identity certificate-based { 1473 base auth-method-type; 1474 description 1475 "This is the identity for the certificate-based authetication type."; 1476 } 1478 /* 1479 * Groupings 1480 */ 1482 grouping ipv4-list { 1483 description 1484 "Grouping for ipv4 based ip-addresses."; 1485 leaf-list ipv4 { 1486 type inet:ipv4-address; 1487 description 1488 "This is the entry for the ipv4 ip-addresses."; 1489 } 1490 } 1492 grouping ipv6-list { 1493 description 1494 "Grouping for ipv6 based ip-addresses."; 1495 leaf-list ipv6 { 1496 type inet:ipv6-address; 1497 description 1498 "This is the entry for the ipv6 ip-addresses."; 1499 } 1500 } 1502 grouping ipv4 { 1503 description 1504 "Grouping for ipv4 based ip-address."; 1505 leaf ipv4 { 1506 type inet:ipv4-address; 1507 description 1508 "This is the entry for the ipv4 ip-address."; 1509 } 1510 } 1512 grouping ipv6 { 1513 description 1514 "Grouping for ipv6 based ip-address."; 1515 leaf ipv6 { 1516 type inet:ipv6-address; 1517 description 1518 "This is the entry for the ipv6 ip-address."; 1519 } 1520 } 1521 grouping ip-address-info { 1522 description 1523 "There are two types to configure a security policy 1524 for IPv4 address, such as exact match and range match."; 1525 choice match-type { 1526 description 1527 "User can choose between 'exact match' and 'range match'."; 1528 case exact-match-ipv4 { 1529 uses ipv4; 1530 description 1531 "Exact ip-address match for ipv4 type addresses"; 1532 } 1533 case exact-match-ipv6 { 1534 uses ipv6; 1535 description 1536 "Exact ip-address match for ipv6 type addresses"; 1537 } 1538 case range-match-ipv4 { 1539 list range-ipv4-address { 1540 key "start-ipv4-address end-ipv4-address"; 1541 leaf start-ipv4-address { 1542 type inet:ipv4-address; 1543 description 1544 "Start IPv4 address for a range match."; 1545 } 1546 leaf end-ipv4-address { 1547 type inet:ipv4-address; 1548 description 1549 "End IPv4 address for a range match."; 1550 } 1551 description 1552 "Range match for an IP-address."; 1553 } 1554 } 1555 case range-match-ipv6 { 1556 list range-ipv6-address { 1557 key "start-ipv6-address end-ipv6-address"; 1558 leaf start-ipv6-address { 1559 type inet:ipv6-address; 1560 description 1561 "Start IPv6 address for a range match."; 1562 } 1563 leaf end-ipv6-address { 1564 type inet:ipv6-address; 1565 description 1566 "End IPv6 address for a range match."; 1567 } 1568 description 1569 "Range match for an IP-address."; 1570 } 1571 } 1572 } 1573 } 1575 grouping password-based-method { 1576 list password-list { 1577 key "auth-method"; 1578 leaf auth-method { 1579 type identityref { 1580 base auth-method-type; 1581 } 1582 description 1583 "This represents the authentication method is password-based."; 1584 } 1585 leaf password { 1586 type ianach:crypt-hash; 1587 description 1588 "The password for this entry."; 1589 } 1590 description 1591 "This represents the list of 1592 encrypted passwords."; 1593 } 1594 } 1596 grouping certificate-based-method { 1597 list cert-server-list { 1598 key "auth-method"; 1599 description 1600 "This describes the certificate-based authentication list."; 1602 leaf auth-mthod { 1603 type identityref { 1604 base auth-method-type; 1605 } 1606 description 1607 "This represents the authentication method is 1608 certificate based method."; 1609 } 1610 leaf cert-server-name { 1611 type string; 1612 description 1613 "This field represents the name of the certificate- 1614 server name."; 1615 } 1616 leaf cert-server-ipv4 { 1617 type inet:ipv4-address; 1618 description 1619 "This represents ipv4 address of a 1620 certificate server."; 1621 } 1622 leaf cert-server-ipv6 { 1623 type inet:ipv6-address; 1624 description 1625 "This represents the ipv6 address of a 1626 certificate server."; 1627 } 1628 list certificate { 1629 key "cert-type"; 1630 description 1631 "This represents the certificate-types."; 1633 leaf cert-type { 1634 type identityref { 1635 base certificate-type; 1636 } 1637 description 1638 "This represents a certificate type."; 1639 } 1641 } 1642 } 1643 } 1645 grouping token-based-method { 1646 list token-list { 1647 key "auth-method"; 1648 description 1649 "This represents the list of tokens."; 1651 leaf auth-method { 1652 type identityref { 1653 base auth-method-type; 1654 } 1655 description 1656 "This represents the authentication type is 1657 token-based method."; 1658 } 1659 leaf token { 1660 type string; 1661 description 1662 "This object contains a string of a token."; 1663 } 1664 leaf token-server { 1665 type inet:ipv4-address; 1666 description 1667 "This represents the token-server information."; 1668 } 1669 } 1670 } 1671 grouping ipsec-based-method { 1672 list ipsec-method { 1673 key "method"; 1674 description 1675 "This represents the list of IPsec method types."; 1677 leaf method { 1678 type identityref { 1679 base i2nsf-ipsec; 1680 } 1681 description 1682 "This represents IPsec IKE and IPsec IKEless cases."; 1683 } 1684 } 1685 } 1687 grouping user-group { 1688 description 1689 "The grouping for user-group entities, and 1690 contains information such as name & ip-address."; 1691 leaf name { 1692 type string; 1693 description 1694 "This represents the name of a user."; 1695 } 1696 uses ip-address-info; 1697 } 1699 grouping device-group { 1700 description 1701 "This group represents device group information 1702 such as ip-address protocol."; 1703 leaf name { 1704 type string; 1705 description 1706 "This represents the name of a device."; 1707 } 1708 uses ip-address-info; 1709 leaf-list protocol { 1710 type identityref { 1711 base protocol-type; 1712 } 1713 description 1714 "This represents the communication protocols of devices."; 1715 } 1716 } 1718 grouping location-group { 1719 description 1720 "This group represents location-group information 1721 such as geo-ip and continent."; 1722 leaf name { 1723 type string; 1724 description 1725 "This represents the name of a location."; 1726 } 1727 leaf geo-ip-ipv4 { 1728 type inet:ipv4-address; 1729 description 1730 "This represents the IPv4 geo-ip of a location."; 1731 } 1732 leaf geo-ip-ipv6 { 1733 type inet:ipv6-address; 1734 description 1735 "This represents the IPv6 geo-ip of a location."; 1736 } 1737 leaf continent { 1738 type identityref { 1739 base continent; 1740 } 1741 description 1742 "location-group-based on geo-ip of 1743 respective continent."; 1744 } 1745 } 1747 grouping threat-feed-info { 1748 description 1749 "This is the grouping for the threat-feed-list"; 1751 leaf feed-name { 1752 type identityref { 1753 base threat-feed-type; 1754 } 1755 description 1756 "This represents the name of the a threat-feed."; 1757 } 1758 leaf feed-server-ipv4 { 1759 type inet:ipv4-address; 1760 description 1761 "The IPv4 ip-address for the threat-feed server."; 1762 } 1763 leaf feed-server-ipv6 { 1764 type inet:ipv6-address; 1765 description 1766 "The IPv6 ip-address for the threat-feed server."; 1767 } 1768 leaf feed-description { 1769 type string; 1770 description 1771 "This represents the descriptions of a threat-feed. 1772 The description should include information, such as 1773 the type, related threat, method, and file type."; 1774 } 1775 } 1777 grouping payload-string { 1778 description 1779 "The grouping for payload-string content. 1780 It contains information such as name and string content."; 1781 leaf payload-description { 1782 type string; 1783 description 1784 "This represents the description of a payload."; 1786 } 1787 leaf-list content { 1788 type string; 1789 description 1790 "This represents the payload string content."; 1791 } 1792 } 1794 list i2nsf-cfi-policy { 1795 key "policy-name"; 1796 description 1797 "This is the security policy list. Each policy in the list 1798 contains a list of security rules, and is a policy instance 1799 to have complete information such as where and when a 1800 policy needs to be applied."; 1801 leaf policy-name { 1802 type string; 1803 mandatory true; 1804 description 1805 "The name which identifies the policy."; 1806 } 1807 list rule { 1808 leaf rule-name { 1809 type string; 1810 mandatory true; 1811 description 1812 "This represents the name for rules."; 1813 } 1814 key "rule-name"; 1815 description 1816 "There can be a single or multiple number of rules."; 1818 container event { 1819 description 1820 "This represents the event (e.g., a security event, which a security rule is made for."; 1821 leaf security-event { 1822 type identityref { 1823 base security-event-type; 1824 } 1825 mandatory true; 1826 description 1827 "This contains the description of security events."; 1828 } 1829 choice enforce-type { 1830 description 1831 "There are three different enforcement types; 1832 admin, and time."; 1833 case enforce-admin { 1834 leaf admin { 1835 type identityref { 1836 base enforce-type; 1837 } 1838 description 1839 "This represents the enforcement type based on admin's decision."; 1840 } 1841 } 1842 case time { 1843 container time-information { 1844 description 1845 "The begin-time and end-time information 1846 when the security rule should be applied."; 1847 leaf enforce-time { 1848 type identityref { 1849 base enforce-type; 1850 } 1851 description 1852 "The enforcement type is time-enforced."; 1853 } 1854 leaf begin-time { 1855 type yang:date-and-time; 1856 description 1857 "This is start time for time zone"; 1858 } 1859 leaf end-time { 1860 type yang:date-and-time; 1861 description 1862 "This is end time for time zone"; 1863 } 1864 } 1865 } 1866 } 1867 leaf frequency { 1868 type enumeration { 1869 enum only-once { 1870 description 1871 "This represents the rule is enforced only once."; 1872 } 1873 enum daily { 1874 description 1875 "This represents the rule is enforced on a daily basis."; 1876 } 1877 enum weekly { 1878 description 1879 "This represents the rule is enforced on a weekly basis."; 1880 } 1881 enum monthly { 1882 description 1883 "This represents the rule is enforced on a monthly basis."; 1884 } 1885 } 1886 default only-once; 1887 description 1888 "This represents how frequent the rule should be enforced."; 1889 } 1890 } 1891 container condition { 1892 choice condition { 1893 description 1894 "The conditions for general security policies."; 1895 case firewall-condition { 1896 description 1897 "The general firewall condition."; 1898 container firewall-source { 1899 description 1900 "This represents the source."; 1901 leaf src-target { 1902 type leafref { 1903 path "/i2nsf-cfi-policy/endpoint-group/user-group/name"; 1904 } 1905 mandatory true; 1906 description 1907 "This describes the paths to 1908 the source reference."; 1909 } 1910 } 1911 container firewall-destination { 1912 description 1913 "This represents the destination."; 1914 leaf-list dest-target { 1915 type leafref { 1916 path "/i2nsf-cfi-policy/endpoint-group/user-group/name"; 1917 } 1918 description 1919 "This describes the paths to the 1920 destination target reference."; 1921 } 1922 } 1923 } 1924 case ddos-condition { 1925 description 1926 "The condition for DDoS mitigation."; 1927 container ddos-source { 1928 description 1929 "This represents the source."; 1931 leaf-list src-target { 1932 type leafref { 1933 path "/i2nsf-cfi-policy/endpoint-group/device-group/name"; 1934 } 1935 description 1936 "This describes the path to the 1937 source target references."; 1938 } 1939 } 1940 container ddos-destination { 1941 description 1942 "This represents the target."; 1943 leaf-list dest-target { 1944 type leafref { 1945 path "/i2nsf-cfi-policy/endpoint-group/device-group/name"; 1946 } 1947 description 1948 "This describes the path to the 1949 destination target references."; 1950 } 1951 } 1952 container rate-limit { 1953 description "This describes the rate-limit."; 1954 leaf packet-per-second { 1955 type uint16; 1956 description 1957 "The rate-limit limits the amount of incoming packets."; 1958 } 1959 } 1960 } 1961 case custom-condition { 1962 description 1963 "The condition based on packet contents."; 1964 container custon-source { 1965 description 1966 "This represents the source."; 1967 leaf-list src-target { 1968 type leafref { 1969 path "/i2nsf-cfi-policy/threat-prevention/payload-content/name"; 1970 } 1971 description 1972 "Describes the payload string 1973 content condition source."; 1974 } 1975 } 1976 container custom-destination { 1977 description 1978 "This represents the destination."; 1980 leaf dest-target { 1981 type leafref { 1982 path "/i2nsf-cfi-policy/threat-prevention/payload-content/name"; 1983 } 1984 mandatory true; 1985 description 1986 "Describes the payload string 1987 content condition destination."; 1988 } 1989 } 1990 } 1991 case threat-feed-condition { 1992 description 1993 "The condition based on the threat-feed information."; 1994 container threat-feed-source { 1995 description 1996 "This represents the source."; 1997 leaf-list src-target { 1998 type leafref { 1999 path "/i2nsf-cfi-policy/threat-prevention/threat-feed-list/feed-name"; 2000 } 2001 description "Describes the threat-feed 2002 condition source."; 2003 } 2004 } 2005 container threat-feed-destination { 2006 description 2007 "This represents the destination."; 2008 leaf dest-target { 2009 type leafref { 2010 path "/i2nsf-cfi-policy/threat-prevention/threat-feed-list/feed-name"; 2011 } 2012 mandatory true; 2013 description "Describes the threat-feed 2014 condition destination."; 2015 } 2016 } 2017 } 2018 } 2019 } 2020 container action { 2021 description 2022 "This is the action container."; 2023 leaf primary-action { 2024 type identityref { 2025 base primary-action; 2026 } 2027 mandatory true; 2028 description 2029 "This represent the primary actions (e.g., PASS, DROP, 2030 ALERT, and MIRROR) to be applied a condition."; 2031 } 2032 leaf secondary-action { 2033 type identityref { 2034 base secondary-action; 2035 } 2036 description 2037 "This represents the secondary actions (e.g., log 2038 and syslog) to be applied if needed."; 2039 } 2040 } 2041 container ipsec-method { 2042 description 2043 "This container represents the IPsec IKE and IKEless cases."; 2044 leaf method { 2045 type leafref { 2046 path "/i2nsf-cfi-policy/multi-tenancy/policy-mgmt-auth-method-instance/ipsec-method/method"; 2047 } 2048 description 2049 "This references the IPsec method types, 2050 which includes IPsec IKE and IPsec IKEless cases."; 2051 } 2052 } 2053 leaf owner { 2054 type identityref { 2055 base owner; 2056 } 2057 mandatory true; 2058 description 2059 "This field defines the owner of this 2060 rule. Only the owner is authorized to 2061 modify the contents of the rule."; 2062 } 2063 } 2065 container multi-tenancy { 2066 description 2067 "The multi-tenant environment information 2068 in which the policy is applied. The Rules 2069 in the Policy can refer to sub-objects 2070 (e.g., domain, tenant, role, and user) of it."; 2072 list policy-domain { 2073 key "domain-name"; 2074 description 2075 "This represents the list of policy domains."; 2076 leaf domain-name { 2077 type identityref { 2078 base domain; 2079 } 2080 description 2081 "This represents the name of a domain."; 2082 } 2083 leaf address { 2084 type string; 2085 description 2086 "The address details of the organization 2087 or customer."; 2088 } 2089 leaf contact { 2090 type string; 2091 description 2092 "contact information of the organization 2093 or customer."; 2094 } 2095 list policy-tenant { 2096 key "tenant-type"; 2097 description 2098 "This field identifies the domain to which this 2099 tenant belongs. This should be reference to a 2100 'Policy-Domain' object."; 2102 leaf tenant-type{ 2103 type identityref { 2104 base tenant-type; 2105 } 2106 description 2107 "The name of the tenant, such as HR or Finance department."; 2108 } 2109 list policy-role { 2110 key "role-type"; 2111 description 2112 "This represent the roles within the tenants, 2113 in order to distinguish who may or may not 2114 have access to policies."; 2116 leaf role-type { 2117 type identityref { 2118 base role-type; 2119 } 2120 description 2121 "This represents the name of the role"; 2122 } 2123 list policy-user { 2124 key "name"; 2125 description 2126 "This represents the list of policy users."; 2128 leaf name { 2129 type string; 2130 description 2131 "This represents the name of the user"; 2132 } 2133 leaf password { 2134 type ianach:crypt-hash; 2135 description 2136 "User password for basic authentication"; 2137 } 2138 leaf email { 2139 type string; 2140 description 2141 "The email account of a user"; 2142 } 2143 list access-profile { 2144 key "permission-type scope-type"; 2145 description 2146 "This field identifies the access profile for the 2147 role. The profile grants or denies access to policy 2148 objects."; 2149 leaf permission-type { 2150 type identityref { 2151 base permission-type; 2152 } 2153 description 2154 "This represents the permission types, such as 2155 read, write, execute, read-and-write, and etc."; 2156 } 2157 leaf scope-type { 2158 type identityref { 2159 base scope-type; 2160 } 2161 description 2162 "identifies whether a user has domain-wide 2163 or tenant-wide privileges"; 2164 } 2165 } 2166 } 2167 } 2168 } 2169 } 2170 list policy-mgmt-auth-method-instance { 2171 key "auth-instance-type"; 2172 description 2173 "This represents the list of instances for 2174 policy management authentication methods."; 2176 leaf auth-instance-type { 2177 type identityref { 2178 base auth-type; 2179 } 2180 description 2181 "This identifies whether the authentication type 2182 is server authentication, client authentication, 2183 or both."; 2184 } 2185 choice policy-mgmt-auth-method { 2186 description 2187 "This represents the choices for which 2188 authentication method is used."; 2189 case password-based { 2190 uses password-based-method; 2191 } 2192 case token-based { 2193 description 2194 "This represents the token-based method."; 2195 uses token-based-method; 2196 } 2197 case certificate-based { 2198 description 2199 "This represents the certificate-based-method."; 2200 uses certificate-based-method; 2201 } 2202 case ipsec { 2203 description 2204 "This repreents authentication method based on IPSEC."; 2205 uses ipsec-based-method; 2206 } 2207 } 2208 } 2209 } 2210 container endpoint-group { 2211 description 2212 "A logical entity in their business 2213 environment, where a security policy 2214 is to be applied."; 2215 list user-group { 2216 key "name"; 2217 uses user-group; 2218 description 2219 "This represents the user group."; 2221 } 2222 list device-group { 2223 key "name"; 2224 uses device-group; 2225 description 2226 "This represents the device group."; 2227 } 2228 list location-group{ 2229 key "name"; 2230 uses location-group; 2231 description 2232 "This represents the location group."; 2233 } 2234 } 2235 container threat-prevention { 2236 description 2237 "this describes the list of threat-prevention."; 2239 list threat-feed-list { 2240 key "feed-name"; 2241 description 2242 "This represents the threat feed list."; 2243 uses threat-feed-info; 2245 leaf-list threat-file-types { 2246 type identityref { 2247 base malware-file-type; 2248 } 2249 default executable-file; 2250 description 2251 "This contains a list of file types needed to 2252 be scanned for the virus."; 2253 } 2254 leaf-list signatures { 2255 type identityref { 2256 base signature-type; 2257 } 2258 default signature-suricata; 2259 description 2260 "This contains a list of signatures or hash 2261 of the threats."; 2262 } 2263 } 2264 list payload-content { 2265 key "name"; 2266 leaf name { 2267 type string; 2268 decription 2269 "This represents the name of payload-content". 2270 It should give an idea of why specific payload 2271 content is marked as threat. For example, the name 2272 "backdoor" indicates the payload content is related 2273 to backdoor attack."; 2274 } 2275 description 2276 "This represents the payload-string group."; 2277 uses payload-string; 2278 } 2279 } 2280 } 2281 } 2282 2284 Figure 23: YANG for Consumer-Facing Interface 2286 10. Example XML Output for Various Scenarios 2288 This section describes the XML instances for different policies 2289 examples that are delivered through Consumer-Facing Interface. The 2290 considered use cases are: VoIP/VoLTE security service, DDoS-attack 2291 mitigation, time-based firewall as a web-filter. 2293 10.1. DB Registration: Information of Positions and Devices (Endpoint 2294 Group) 2296 If new endpoints are introduced to the network, it is necessary to 2297 first register their data to the database. For example, if new 2298 members are newly introduced in either of three different groups 2299 (i.e., user-group, device-group, and payload-group), each of them 2300 should be registered with information such as ip-addresses or 2301 protocols used by devices. Figure 24 shows an example XML 2302 representation of the registered information for the user-group and 2303 device-group. 2305 2306 2307 2308 employees 2309 2310 221.159.112.1 2311 221.159.112.90 2312 2313 2314 2315 webservers 2316 2317 221.159.112.91 2318 221.159.112.97 2319 2320 http 2321 https 2322 2323 2325 Figure 24: Registering User-group and Device-group Information 2327 10.2. Scenario 1: Block SNS Access during Business Hours 2329 The first example scenario is to "block SNS access during business 2330 hours" using a time-based firewall policy. In this scenario, all 2331 users registered as "employee" in the user-group list are unable to 2332 access Social Networking Services (SNS) during the office hours. The 2333 XML instance is described below: 2335 2336 2337 security_policy_for_blocking_sns 2338 2339 block_access_to_sns_during_office_hours 2340 2341 2342 09:00 2343 18:00 2344 2345 2346 2347 2348 2349 employees 2350 2351 2352 2353 2354 sns-websites 2355 2356 2357 2358 2359 drop 2360 2361 2362 ipsec-ike 2363 2364 2365 2367 Figure 25: An XML Example for Time-based Firewall 2369 Time-based-condition Firewall 2371 1. The policy name is "security_policy_for_blocking_sns". 2373 2. The rule name is "block_access_to_sns_during_office_hours". 2375 3. The Source-target is "employees". 2377 4. The destination target is "sns-websites". "sns-websites" is the 2378 key which represents the list containing the information, such as 2379 URL, about sns-websites. 2381 5. The action required is to "drop" any attempt to connect to 2382 websites related to Social networking. 2384 6. The IPsec method type used for nsf traffic steering is set to 2385 "ipsec-ike". 2387 10.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a 2388 Company 2390 The second example scenario is to "block malicious VoIP/VoLTE packets 2391 coming to a company" using a VoIP policy. In this scenario, the 2392 calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that 2393 are classified as malicious are dropped. The IP addresses of the 2394 employees and malicious VOIP IDs should be blocked are stored in the 2395 database or datastore of the enterprise. Here and the rest of the 2396 cases assume that the security administrators or someone responsible 2397 for the existing and newly generated policies, are not aware of which 2398 and/or how many NSFs are needed to meet the security requirements. 2399 Figure 26 represents the XML document generated from YANG discussed 2400 in previous sections. Once a high-level seucurity policy is created 2401 by a security admin, it is delivered by the Consumer-Facing 2402 Interface, through RESTCONF server, to the security controller. The 2403 XML instance is described below: 2405 2406 2407 security_policy_for_blocking_malicious_voip_packets 2408 2409 Block_malicious_voip_and_volte_packets 2410 2411 2412 2413 malicious-id 2414 2415 2416 2417 2418 employees 2419 2420 2421 2422 2423 drop 2424 2425 2426 ipsec-ikeless 2427 2428 2429 2431 Figure 26: An XML Example for VoIP Security Service 2433 Custom-condition Firewall 2435 1. The policy name is 2436 "security_policy_for_blocking_malicious_voip_packets". 2438 2. The rule name is "Block_malicious_voip_and_volte_packets". 2440 3. The Source-target is "malicious-id". This can be a single ID or 2441 a list of IDs, depending on how the ID are stored in the 2442 database. The "malicious-id" is the key so that the security 2443 admin can read every stored malicious VOIP IDs that are named as 2444 "malicious-id". 2446 4. The destination target is "employees". "employees" is the key 2447 which represents the list containing information about employees, 2448 such as IP addresses. 2450 5. The action required is "drop" when any incoming packets are from 2451 "malicious-id". 2453 6. The IPsec method used for nsf traffic steering is set to "ipsec- 2454 ikeless". 2456 10.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company 2457 Web Server 2459 The third example scenario is to "Mitigate HTTP and HTTPS flood 2460 attacks on a company web server" using a DDoS-attack mitigation 2461 policy. Here, the time information is not set because the service 2462 provided by the network should be maintained at all times. If the 2463 packets sent by any sources are more than the set threshold, then the 2464 admin can set the percentage of the packets to be dropped to safely 2465 maintain the service. In this scenario, the source is set as "any" 2466 to block any sources which send abnormal amount of packets. The 2467 destination is set as "web_server01". Once the rule is set and 2468 delivered and enforced to the nsfs by the securiy controller, the 2469 NSFs will monitor the incoming packet amounts and the destination to 2470 act according to the rule set. The XML instance is described below: 2472 2473 2474 security_policy_for_ddos_attacks 2475 2476 100_packets_per_second 2477 2478 2479 2480 webservers 2481 2482 2483 100 2484 2485 2486 2487 2488 drop 2489 2490 2491 ipsec-ikeless 2492 2493 2494 2496 Figure 27: An XML Example for DDoS-attack Mitigation 2498 DDoS-condition Firewall 2500 1. The policy name is "security_policy_for_ddos_attacks". 2502 2. The rule name is "100_packets_per_second". 2504 3. The destination target is "webservers". "webservers" is the key 2505 which represents the list containing information, such as IP 2506 addresses and ports, about web-servers. 2508 4. The rate limit exists to limit the incoming amount of packets per 2509 second. In this case the rate limit is "100" packets per second. 2510 This amount depends on the packet receiving capacity of the 2511 server devices. 2513 5. The Source-target is all sources which send abnormal amount of 2514 packets. 2516 6. The action required is to "drop" packet reception is more than 2517 100 packets per second. 2519 7. The IPsec method used for nsf traffic steering is set to "ipsec- 2520 ike". 2522 11. Security Considerations 2524 The data model for the I2NSF Consumer-Facing Interface is based on 2525 the I2NSF framework [RFC8329], so the same security considerations 2526 with the I2NSF framework should be included in this document. The 2527 data model needs a secure communication channel to protect the 2528 Consumer-Facing Interface between the I2NSF User and Security 2529 Controller. 2531 12. IANA Considerations 2533 This document requests IANA to register the following URI in the 2534 "IETF XML Registry" [RFC3688]: 2536 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2537 Registrant Contact: The I2NSF. 2538 XML: N/A; the requested URI is an XML namespace. 2540 This document requests IANA to register the following YANG module in 2541 the "YANG Module Names" registry [RFC7950]. 2543 name: ietf-i2nsf-cfi-policy 2544 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2545 prefix: cfi-policy 2546 reference: RFC 7950 2548 13. References 2550 13.1. Normative References 2552 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2553 Information Models and Data Models", RFC 3444, 2554 DOI 10.17487/RFC3444, January 2003, 2555 . 2557 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2558 DOI 10.17487/RFC3688, January 2004, 2559 . 2561 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2562 the Network Configuration Protocol (NETCONF)", RFC 6020, 2563 DOI 10.17487/RFC6020, October 2010, 2564 . 2566 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2567 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2568 . 2570 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2571 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2572 . 2574 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2575 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2576 May 2017, . 2578 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2579 and J. Jeong, "Interface to Network Security Functions 2580 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2581 DOI 10.17487/RFC8192, July 2017, 2582 . 2584 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2585 Kumar, "Framework for Interface to Network Security 2586 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2587 . 2589 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2590 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2591 . 2593 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2594 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2595 DOI 10.17487/RFC8407, October 2018, 2596 . 2598 13.2. Informative References 2600 [client-facing-inf-req] 2601 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 2602 S., and L. Xia, "Requirements for Client-Facing Interface 2603 to Security Controller", draft-ietf-i2nsf-client-facing- 2604 interface-req-05 (work in progress), May 2018. 2606 [i2nsf-capability-im] 2607 Xia, L., Strassner, J., Basile, C., and D. Lopez, 2608 "Information Model of NSFs Capabilities", draft-ietf- 2609 i2nsf-capability-05 (work in progress), April 2019. 2611 [i2nsf-ipsec] 2612 Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 2613 Garcia, "Software-Defined Networking (SDN)-based IPsec 2614 Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow- 2615 protection-05 (work in progress), July 2019. 2617 [i2nsf-terminology] 2618 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 2619 Birkholz, "Interface to Network Security Functions (I2NSF) 2620 Terminology", draft-ietf-i2nsf-terminology-08 (work in 2621 progress), July 2019. 2623 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- 2624 dm-05 2626 The following are major changes made from draft-ietf-i2nsf-consumer- 2627 facing-interface-dm-05: 2629 o The container policy-mgnt-auth-method uses a list, and the policy- 2630 mgmt-auth-method consists of choice-cases. 2632 o Policy-role is changed from container to list. The access-profile 2633 in the policy-role is not removed. Instead, it is placed inside 2634 policy-user. 2636 o Container Condition consists of choice-cases to show that it is 2637 capable of configuring different triggering conditions. 2639 o The enforce-type in Event container use a choice-case statement. 2640 This change shows the clarity that the enforce-type is relevant to 2641 each case (i.e., enforce-type == admin or time). 2643 o The name for container "recursive" is changed to "frequency". 2644 This container represents how frequently the rule is enforced, so 2645 the name "frequency" is more appropriate. 2647 o The certificate based authentication method is modified so that a 2648 certificate server can handle more than one (list) of certificate 2649 types. 2651 The minor changes are as follows: 2653 o Typos are corrected. 2655 o IPv6 as well as IPv4 are included. 2657 o Some misused types are corrected (e.g., enum -> identity) 2659 o Some descriptions that are unclear, mistaken, or shortly explained 2660 are rewritten. 2662 Appendix B. Acknowledgments 2664 This work was supported by Institute of Information & Communications 2665 Technology Planning & Evaluation (IITP) grant funded by the Korea 2666 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 2667 Security Intelligence Technology Development for the Customized 2668 Security Service Provisioning). 2670 Appendix C. Contributors 2672 This document is made by the group effort of I2NSF working group. 2673 Many people actively contributed to this document, such as Mahdi F. 2674 Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their 2675 contributions. 2677 The following are co-authors of this document: 2679 Hyoungshick Kim 2680 Department of Computer Science and Engineering 2681 Sungkyunkwan University 2682 2066 Seo-ro Jangan-gu 2683 Suwon, Gyeonggi-do 16419 2684 Republic of Korea 2686 EMail: hyoung@skku.edu 2688 Seungjin Lee 2689 Department of Electronic, Electrical and Computer Engineering 2690 Sungkyunkwan University 2691 2066 Seo-ro Jangan-gu 2692 Suwon, Gyeonggi-do 16419 2693 Republic of Korea 2695 EMail: jine33@skku.edu 2697 Jinyong Tim Kim 2698 Department of Electronic, Electrical and Computer Engineering 2699 Sungkyunkwan University 2700 2066 Seo-ro Jangan-gu 2701 Suwon, Gyeonggi-do 16419 2702 Republic of Korea 2704 EMail: timkim@skku.edu 2706 Anil Lohiya 2707 Juniper Networks 2708 1133 Innovation Way 2709 Sunnyvale, CA 94089 2710 US 2712 EMail: alohiya@juniper.net 2713 Dave Qi 2714 Bloomberg 2715 731 Lexington Avenue 2716 New York, NY 10022 2717 US 2719 EMail: DQI@bloomberg.net 2721 Nabil Bitar 2722 Nokia 2723 755 Ravendale Drive 2724 Mountain View, CA 94043 2725 US 2727 EMail: nabil.bitar@nokia.com 2729 Senad Palislamovic 2730 Nokia 2731 755 Ravendale Drive 2732 Mountain View, CA 94043 2733 US 2735 EMail: senad.palislamovic@nokia.com 2737 Liang Xia 2738 Huawei 2739 101 Software Avenue 2740 Nanjing, Jiangsu 210012 2741 China 2743 EMail: Frank.Xialiang@huawei.com 2745 Authors' Addresses 2746 Jaehoon Paul Jeong 2747 Department of Computer Science and Engineering 2748 Sungkyunkwan University 2749 2066 Seobu-Ro, Jangan-Gu 2750 Suwon, Gyeonggi-Do 16419 2751 Republic of Korea 2753 Phone: +82 31 299 4957 2754 Fax: +82 31 290 7996 2755 EMail: pauljeong@skku.edu 2756 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2758 Eunsoo Kim 2759 Department of Electronic, Electrical and Computer Engineering 2760 Sungkyunkwan University 2761 2066 Seobu-Ro, Jangan-Gu 2762 Suwon, Gyeonggi-Do 16419 2763 Republic of Korea 2765 Phone: +82 31 299 4104 2766 EMail: eskim86@skku.edu 2767 URI: http://seclab.skku.edu/people/eunsoo-kim/ 2769 Tae-Jin Ahn 2770 Korea Telecom 2771 70 Yuseong-Ro, Yuseong-Gu 2772 Daejeon 305-811 2773 Republic of Korea 2775 Phone: +82 42 870 8409 2776 EMail: taejin.ahn@kt.com 2778 Rakesh Kumar 2779 Juniper Networks 2780 1133 Innovation Way 2781 Sunnyvale, CA 94089 2782 USA 2784 EMail: rkkumar@juniper.net 2785 Susan Hares 2786 Huawei 2787 7453 Hickory Hill 2788 Saline, MI 48176 2789 USA 2791 Phone: +1-734-604-0332 2792 EMail: shares@ndzh.com