idnits 2.17.1 draft-ietf-i2nsf-consumer-facing-interface-dm-08.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 15 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 477 has weird spacing: '...address ine...' == Line 482 has weird spacing: '...address ine...' == Line 518 has weird spacing: '...address ine...' == Line 523 has weird spacing: '...address ine...' == Line 642 has weird spacing: '...ription str...' -- The document date (March 11, 2020) is 1505 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 2044, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 2061, 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 (~~), 8 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 C. Chung 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: September 12, 2020 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 March 11, 2020 13 I2NSF Consumer-Facing Interface YANG Data Model 14 draft-ietf-i2nsf-consumer-facing-interface-dm-08 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 September 12, 2020. 48 Copyright Notice 50 Copyright (c) 2020 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 Policy Endpoint Groups . . . . . . . . 10 73 5.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 10 74 5.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 11 75 5.3. Location Group . . . . . . . . . . . . . . . . . . . . . 12 76 6. Information Model for Threat Prevention . . . . . . . . . . . 13 77 6.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 14 79 7. Network Configuration Access Control Model (NACM) . . . . . . 15 80 8. YANG Data Model of Consumer-Facing Interface . . . . . . . . 15 81 9. XML Configuration Examples of High-Level Security Policy 82 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 83 9.1. Database Registration: Information of Positions and 84 Devices (Endpoint Group) . . . . . . . . . . . . . 36 85 9.2. Scenario 1: Block SNS Access during Business Hours . . . 37 86 9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to 87 a Company . . . . . . . . . . . . . . . . . . . . . . . . 39 88 9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a 89 Company Web Server . . . . . . . . . . . . . . . . . . . 40 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 92 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 93 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 94 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 95 14.1. Normative References . . . . . . . . . . . . . . . . . . 44 96 14.2. Informative References . . . . . . . . . . . . . . . . . 45 97 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing- 98 interface-dm-07 . . . . . . . . . . . . . . . . . . 47 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 101 1. Introduction 103 In a framework of Interface to Network Security Functions (I2NSF), 104 each vendor can register their NSFs using a Developer's Management 105 System (DMS). Assuming that vendors also provide the front-end web 106 applications registered with an I2NSF User, the Consumer-Facing 107 Interface is required because the web applications developed by each 108 vendor need to have a standard interface specifying the data types 109 used when the I2NSF User and Security Controller communicate using 110 this interface. Therefore, this document specifies the required 111 information, their data types, and encoding schemes so that high- 112 level security policies (or configuration information for security 113 policies) can be transferred to the Security Controller through the 114 Consumer-Facing Interface. These policies can easily be translated 115 by the Security Controller into low-level security policies. The 116 Security Controller delivers the translated policies to Network 117 Security Functions (NSFs) according to their respective security 118 capabilities for the required securiy enforcement. 120 The Consumer-Facing Interface would be built using a set of objects, 121 with each object capturing a unique set of information from Security 122 Administrator (i.e., I2NSF User [RFC8329]) needed to express a 123 Security Policy. An object may have relationship with various other 124 objects to express a complete set of requirements. An information 125 model captures the managed objects and relationship among these 126 objects. The information model proposed in this document is 127 structured in accordance with the "Event-Condition-Action" (ECA) 128 policy model. 130 An NSF Capability model is proposed in [i2nsf-capability-im] as the 131 basic model for both the NSF-Facing interface and Consumer-Facing 132 Interface security policy model of this document. 134 [RFC3444] explains differences between an information and data model. 135 This document uses the guidelines in [RFC3444] to define both the 136 information and data model for Consumer-Facing Interface. Figure 1 137 shows a high-level abstraction of Consumer-Facing Interface. A data 138 model, which represents an implementation of the information model in 139 a specific data representation language, is also defined in this 140 document. 142 +-----------------+ +-----------------+ 143 | Consumer-Facing | | Consumer-Facing | 144 | Interface +--->+ Interface | 145 |Information Model| | Data Model | 146 +--------+--------+ +-----------------+ 147 ^ 148 | 149 +-------------+------------+ 150 | | | 151 +-----+----+ +-----+----+ +----+----+ 152 | Policy | | Endpoint | | Threat | 153 | | | groups | | feed | 154 +-----+----+ +----------+ +---------+ 155 ^ 156 | 157 +------+------+ 158 | Rule | 159 +------+------+ 160 ^ 161 | 162 +----------------+----------------+ 163 | | | 164 +------+------+ +------+------+ +------+------+ 165 | Event | | Condition | | Action | 166 +-------------+ +-------------+ +-------------+ 168 Figure 1: Diagram for High-level Abstraction of Consumer-Facing 169 Interface 171 Data models are defined at a lower level of abstraction and provide 172 many details. They provide details about the implementation of a 173 protocol's specification, e.g., rules that explain how to map managed 174 objects onto lower-level protocol constructs. Since conceptual 175 models can be implemented in different ways, multiple data models can 176 be derived from a single information model. 178 The efficient and flexible provisioning of network functions by a 179 Network Functions Virtualization (NFV) system leads to a rapid 180 advance in the network industry. As practical applications, Network 181 Security Functions (NSFs), such as firewall, Intrusion Detection 182 System (IDS)/Intrusion Prevention System (IPS), and attack 183 mitigation, can also be provided as Virtual Network Functions (VNF) 184 in the NFV system. By the efficient virtualization technology, these 185 VNFs might be automatically provisioned and dynamically migrated 186 based on real-time security requirements. This document presents a 187 YANG data model to implement security functions based on NFV. 189 2. Requirements Language 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in RFC 2119 [RFC3444] 194 RFC8174 [RFC8174]. 196 3. Terminology 198 This document uses the terminology described in [i2nsf-terminology] 199 [client-facing-inf-req]. 201 This document follows the guidelines of [RFC8407], uses the common 202 YANG types defined in [RFC6991], and adopts the Network Management 203 Datastore Architecture (NMDA). The meaning of the symbols in tree 204 diagrams is defined in [RFC8340]. 206 4. Information Model for Policy 208 A Policy object represents a mechanism to express a Security Policy 209 by Security Administrator (i.e., I2NSF User) using Consumer-Facing 210 Interface toward Security Controller; the policy would be enforced on 211 an NSF. Figure 2 shows the YANG tree of the Policy object. The 212 Policy object SHALL have the following information: 214 Name: This field identifies the name of this object. 216 Owners: This field contains the owners of the policy. For 217 example, the owners who created it, and can modify it. 218 This field represents multiple groups owning as owners, 219 having full CRUD privileges by default. Note that it is 220 assumed that a factory-default owner (e.g., root) is 221 defined and preconfigured in Security Controller in order 222 to create new policy objects at first. 224 Rule: This field contains a list of rules. These rules are 225 defined for 1) communication between two Endpoint Groups, 226 2) for preventing communication with externally or 227 internally identified threats, and 3) for implementing 228 business requirement such as controlling access to internal 229 or external resources for meeting regulatory compliance or 230 business objectives. An organization may restrict certain 231 communication between a set of user and applications for 232 example. The threats may be from threat feeds obtained 233 from external sources or dynamically identified by using 234 specialty devices in the network. Rule conflict analysis 235 should be triggered by the monitoring service to perform an 236 exhaustive detection of anomalies among the configuration 237 rules installed into the security functions. 239 +--rw i2nsf-cfi-policy* [policy-name] 240 +--rw policy-name string 241 | uses owners-ref 242 | +--rw rules* [rule-name] 243 +--rw endpoint-groups 244 +--rw threat-prevention 246 Figure 2: Policy YANG Data Tree 248 A policy is a container of Rule(s). In order to express a Rule, a 249 Rule must have complete information such as where and when a policy 250 needs to be applied. This is done by defining a set of managed 251 objects and relationship among them. A Policy Rule may be related 252 segmentation, threat mitigation or telemetry data collection from an 253 NSF in the network, which will be specified as the sub-model of the 254 policy model in the subsequent sections. Figure 3 shows the YANG 255 data tree of the Rule object. The rule object SHALL have the 256 following information: 258 Name: This field identifies the name of this object. 260 Owners: This field contains the owners of the rule. For example, 261 the owners who created it, and can modify it. This field 262 represents multiple groups owning as owners, having full 263 CRUD privileges by default. 265 Event: This field includes the information to determine whether 266 the Rule Condition can be evaluated or not. See details in 267 Section 4.1. 269 Condition: This field contains all the checking conditions to 270 apply to the objective traffic. See details in 271 Section 4.2. 273 Action: This field identifies the action taken when a rule is 274 matched. There is always an implicit action to drop 275 traffic if no rule is matched for a traffic type. See 276 details in Section 4.3. 278 IPsec-Method: This field contains the information about IPsec 279 method type. There are two types such as IPsec-IKE and 280 IPsec-IKEless [i2nsf-ipsec]. 282 +--rw rules* [rule-name] 283 +--rw rule-name string 284 | uses owners-ref 285 +--rw event 286 +--rw (condition)? 287 +--rw action 288 +--rw ipsec-method 290 Figure 3: Rule YANG Data Tree 292 Note that in the case of policy conflicts, the resolution of the 293 conflicted policies conforms to the guidelines of "Information Model 294 of NSFs Capabilities" [i2nsf-capability-im]. 296 4.1. Event Sub-model 298 The Event Object contains information related to scheduling a Rule. 299 The Rule could be activated based on a set time or security event. 300 Figure 4 shows the YANG tree of the Event object. Event object SHALL 301 have following information: 303 Security-event: This field identifies for which security event 304 the policy is enforced. The examples of security events 305 are: "DDOS", "spyware", "trojan", and "ransomware". 307 Enforce-type: This field identifies whether the event of 308 triggering policy enforcement is "Admin" or "Time". 310 Admin: This represents the enforcement type based on admin's 311 decision. 313 Time: This represents the security rule is enforced based on 314 begin-time and end-time information. 316 Frequency: This represents how frequent the rule should be 317 enforced. There are four options: "only-once", "daily", 318 "weekly" and "monthly". 320 +--rw event 321 +--rw security-event identityref 322 +--rw (enforce-type)? 323 | +--:(admin) 324 | | +--rw admin? 325 | +--:(time) 326 | +--rw time-information 327 | +--rw begin-time? date-and-time 328 | +--rw end-time? date-and-time 329 +--rw frequency? enumeration 331 Figure 4: Event Sub-model YANG Data Tree 333 4.2. Condition Sub-model 335 This object represents Conditions that Security Administrator wants 336 to apply the checking on the traffic in order to determine whether 337 the set of actions in the Rule can be executed or not. The Condition 338 Sub-model consists of three different types of containers each 339 representing different cases, such as general firewall and DDoS- 340 mitigation cases, and a case when the condition is based on the 341 payload strings of packets. Each containers have source and 342 destination-target to represent the source and destination for each 343 case. Figure 5 shows the YANG tree of the Condition object. The 344 Condition Sub-model SHALL have following information: 346 Case (Firewall-condition): This field represents the general 347 firewall case, where a security admin can set up firewall 348 conditions using the information present in this field. 349 The source and destination is represented as firewall- 350 source and firewall-destination, each referring to the IP- 351 address-based groups defined in the endpoint-groups. 353 Case (DDoS-condition): This field represents the condition for 354 DDoS mitigation, where a security admin can set up DDoS 355 mitigation conditions using the information present in this 356 field. The source and destination is represented as ddos- 357 source and ddos-destination, each referring to the device- 358 groups defined and registered in the endpoint-groups. 360 Case (Custom-condition): This field contains the payload string 361 information. This information is useful when security rule 362 condition is based on the string contents of incoming or 363 outgoing packets. The source and destination is 364 represented as custom-source and custom-destination, each 365 referring to the payload-groups defined and registered in 366 the endpoint-groups. 368 Case (Threat-feed-condition): This field contains the information 369 obtained from threat-feeds (e.g., Palo-Alto, or RSA- 370 netwitness). This information is useful when security rule 371 condition is based on the existing threat reports gathered 372 by other sources. The source and destination is 373 represented as threat-feed-source and threat-feed- 374 destination. For clarity, threat-feed-source/destination 375 represent the source/destination of a target security 376 threat, not the information source/destination of a threat- 377 feed. 379 +--rw (condition)? 380 +--:(firewall-condition) 381 | +--rw source -> /../../nacm:group/nacm:user-name 382 | +--rw dest-target* -> /../../nacm:group/nacm:user-name 383 +--:(ddos-condition) 384 | +--rw source* -> /../../device-group/name 385 | +--rw dest-target* -> /../../device-group/name 386 | +--rw rate-limit 387 +--:(custom-condition) 388 | +--rw source* -> /../../payload-content/name 389 | +--rw dest-target -> /../../payload-content/name 390 +--:(threat-feed-condition) 391 +--rw source* -> /../../threat-feed-list/name 392 +--rw dest-target -> /../../threat-feed-list/name 394 Figure 5: Condition Sub-model YANG Data Tree 396 4.3. Action Sub-model 398 This object represents actions that Security Admin wants to perform 399 based on certain traffic class. Figure 6 shows the YANG tree of the 400 Action object. The Action object SHALL have following information: 402 Primary-action: This field identifies the action when a rule is 403 matched by an NSF. The action could be one of "PASS", 404 "DROP", "ALERT", "RATE-LIMIT", and "MIRROR". 406 Secondary-action: This field identifies the action when a rule is 407 matched by an NSF. The action could be one of "log", 408 "syslog", "session-log". 410 +--rw action 411 +--rw primary-action identityref 412 +--rw secondary-action? identityref 414 Figure 6: Action Sub-model YANG Data Tree 416 5. Information Model for Policy Endpoint Groups 418 The Policy Endpoint Group is a very important part of building User- 419 Construct based policies. A Security Administrator would create and 420 use these objects to represent a logical entity in their business 421 environment, where a Security Policy is to be applied. There are 422 multiple managed objects that constitute a Policy's Endpoint Group as 423 shown in Figure 7. Figure 8 shows the YANG tree of the Endpoint- 424 Groups object. This section lists these objects and relationship 425 among them. 427 +-------------------+ 428 | Endpoint Groups | 429 +---------+---------+ 430 ^ 431 | 432 +--------------+----------------+ 433 1..n | 1..n | 1..n | 434 +-----+----+ +------+-----+ +-------+------+ 435 |User-group| |Device-group| |Location-group| 436 +----------+ +------------+ +--------------+ 438 Figure 7: Endpoint Group Diagram 440 +--rw endpoint-groups 441 +--rw user-group* [name] 442 ... 443 +--rw device-group* [name] 444 ... 445 +--rw location-group* [name] 446 ... 448 Figure 8: Endpoint Group YANG Data Tree 450 5.1. User Group 452 This object represents a User-Group. Figure 9 shows the YANG tree of 453 the User-Group object. The User-Group object SHALL have the 454 following information: 456 Name: This field identifies the name of this object. 458 IP-address: This represents the IPv4 address of a user in the 459 user group. 461 range-ipv4-address: This represents the IPv4 address of a user in 462 the user gorup. 464 range-ipv6-address: This represents the IPv6 address of a user in 465 the user gorup. 467 +--rw user-group* [name] 468 +--rw name -> /../../nacm:group/nacm:user-name 469 +--rw (match-type)? 470 +--:(exact-match-ipv4) 471 | +--rw ipv4-address* inet:ipv4-address 472 +--:(exact-match-ipv6) 473 | +--rw ipv6-address* inet:ipv6-address 474 +--:(range-match-ipv4) 475 | +--rw range-ipv4-address* 476 [start-ipv4-address end-ipv4-address] 477 | +--rw start-ipv4-address inet:ipv4-address 478 | +--rw end-ipv4-address inet:ipv4-address 479 +--:(range-match-ipv6) 480 +--rw range-ipv6-address* 481 [start-ipv6-vaddress end-ipv6-address] 482 +--rw start-ipv6-address inet:ipv6-address 483 +--rw end-ipv6-address inet:ipv6-address 485 Figure 9: User Group YANG Data Tree 487 5.2. Device Group 489 This object represents a Device-Group. Figure 10 shows the YANG tree 490 of the Device-group object. The Device-Group object SHALL have the 491 following information: 493 Name: This field identifies the name of this object. 495 IP-address: This represents the IPv4 address of a device in the 496 device group. 498 range-ipv4-address: This represents the IPv4 address of a device 499 in the device gorup. 501 range-ipv6-address: This represents the IPv6 address of a device 502 in the device gorup. 504 Protocol: This represents the communication protocols used by the 505 devices. The protocols are "SSH", "FTP", "SMTP", "HTTP", 506 "HTTPS", and etc. 508 +--rw device-group* [name] 509 +--rw name string 510 +--rw (match-type)? 511 | +--:(exact-match-ipv4) 512 | | +--rw ipv4-address* inet:ipv4-address 513 | +--:(exact-match-ipv6) 514 | | +--rw ipv6-address* inet:ipv6-address 515 | +--:(range-match-ipv4) 516 | | +--rw range-ipv4-address* 517 [start-ipv4-address end-ipv4-address] 518 | | +--rw start-ipv4-address inet:ipv4-address 519 | | +--rw end-ipv4-address inet:ipv4-address 520 | +--:(range-match-ipv6) 521 | +--rw range-ipv6-address* 522 [start-ipv6-vaddress end-ipv6-address] 523 | +--rw start-ipv6-address inet:ipv6-address 524 | +--rw end-ipv6-address inet:ipv6-address 525 +--rw protocol identityref 527 Figure 10: Device Group YANG Data Tree 529 5.3. Location Group 531 This object represents a location group based on either tag or other 532 information. Figure 11 shows the YANG tree of the Location-Group 533 object. The Location-Group object SHALL have the following 534 information: 536 Name: This field identifies the name of this object. 538 geo-ip-ipv4: This field represents the IPv4 Geo-ip of a location. 540 geo-ip-ipv6: This field represents the IPv6 Geo-ip of a location. 542 continent: This field represents the continent where the location 543 group member is at. 545 +--rw location-group* [name] 546 +--rw name string 547 +--rw geo-ip-ipv4 inet:ipv4-address 548 +--rw geo-ip-ipv6 inet:ipv6-address 549 +--rw continent? identityref 551 Figure 11: Location Group YANG Data Tree 553 6. Information Model for Threat Prevention 555 The threat prevention plays an important part in the overall security 556 posture by reducing the attack surfaces. This information could come 557 from various threat feeds (i.e., sources for obtaining the threat 558 information). There are multiple managed objects that constitute 559 this category. This section lists these objects and relationship 560 among them. Figure 13 shows the YANG tree of a Threat-Prevention 561 object. 563 +-------------------+ 564 | Threat Prevention | 565 +---------+---------+ 566 ^ 567 | 568 +---------+---------+ 569 1..n | 1..n | 570 +------+------+ +--------+--------+ 571 | Threat-feed | | payload-content | 572 +-------------+ +-----------------+ 574 Figure 12: Threat Prevention Diagram 576 +--rw threat-prevention 577 +--rw threat-feed-list* [name] 578 ... 579 +--rw payload-content* [name] 580 ... 582 Figure 13: Threat Prevention YANG Data Tree 584 6.1. Threat Feed 586 This object represents a threat feed which provides signatures of 587 malicious activities. Figure 14 shows the YANG tree of a Threat- 588 feed-list. The Threat-Feed object SHALL have the following 589 information: 591 name: This field identifies the name of this object. 593 Server-ipv4: This represents the IPv4 server address of the feed 594 provider, it may be external or local servers. 596 Server-ipv6: This represents the IPv6 server address of the feed 597 provider, it may be external or local servers. 599 description: This is the description of the threat feed. The 600 descriptions should have clear indication of the security 601 attack such as attack type (e.g., APT) and file types used 602 (e.g., executable malware). 604 Threat-file-types: This field identifies the information about 605 the file types identified and reported by the threat-feed. 607 signatures: This field contains the signatures of malicious 608 programs or activities provided by the threat-feed. The 609 examples of signature types are "YARA", "SURICATA", and 610 "SNORT". 612 +--rw threat-prevention 613 +--rw threat-feed-list* [name] 614 +--rw name identityref 615 +--rw server-ipv4? inet:ipv4-address 616 +--rw server-ipv6? inet:ipv6-address 617 +--rw description? string 618 +--rw threat-file-types* identityref 619 +--rw signatures* identityref 621 Figure 14: Threat Feed YANG Data Tree 623 6.2. Payload Content 625 This object represents a custom list created for the purpose of 626 defining exception to threat feeds. Figure 15 shows the YANG tree of 627 a Payload-content list. The Payload-Content object SHALL have the 628 following information: 630 Name: This field identifies the name of this object. For 631 example, the name "backdoor" indicates the payload content 632 is related to backdoor attack. 634 description: This represents the description of how the payload 635 content is related to a security attack. 637 Content: This contains the payload contents, which are involed in 638 a security attack, as strings. 640 +--rw payload-content* [name] 641 +--rw name string 642 +--rw description string 643 +--rw content* string 645 Figure 15: Payload Content in YANG Data Tree 647 7. Network Configuration Access Control Model (NACM) 649 Network Configuration Access Control Model (NACM) provides a high- 650 level overview of the access control with the following features 651 [RFC8341]: 653 o Independent control of action, data, and notification access is 654 provided. 656 o A simple and familiar set of datastore permissions is used. 658 o Support for YANG security tagging allows default security modes to 659 automatically exclude sensitive data. 661 o Separate default access modes for read, write, and execute 662 permissions are provided. 664 o Access control rules are applied to configurable groups of users. 666 The data model for the I2NSF Consumer-Facing Interface provides NACM 667 mechanisms and concepts to user-group and owners permissions. The 668 NACM with the above features can be used to set up all the management 669 access controls in the I2NSF high-level authorization view, and it 670 may have a high impact on the optimization and performance. 672 8. YANG Data Model of Consumer-Facing Interface 674 The main objective of this data model is to provide both an 675 information model and the corresponding YANG data model of I2NSF 676 Consumer-Facing Interface. This interface can be used to deliver 677 control and management messages between an I2NSF User and Security 678 Controller for the I2NSF User's high-level security policies. 680 The semantics of the data model must be aligned with the information 681 model of the Consumer-Facing Interface. The transformation of the 682 information model was performed so that this YANG data model can 683 facilitate the efficient delivery of the control or management 684 messages. 686 This data model is designed to support the I2NSF framework that can 687 be extended according to the security needs. In other words, the 688 model design is independent of the content and meaning of specific 689 policies as well as the implementation approach. This document 690 suggests a VoIP/VoLTE security service as a use case for policy rule 691 generation. 693 This section describes a YANG data model for Consumer-Facing 694 Interface, based on the information model of Consumer-Facing 695 Interface to Security Controller. 697 file "ietf-i2nsf-cfi-policy@2020-03-11.yang" 699 module ietf-i2nsf-cfi-policy { 700 yang-version 1.1; 701 namespace 702 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; 703 prefix 704 cfi-policy; 706 import ietf-inet-types{ 707 prefix inet; 708 reference "Section 4 of RFC 6991"; 709 } 711 import ietf-netconf-acm { 712 prefix nacm; 713 } 715 organization 716 "IETF I2NSF (Interface to Network Security Functions) 717 Working Group"; 719 contact 720 "WG Web: 721 WG List: 723 WG Chair: Linda Dunbar 724 726 WG Chair: Yoav Nir 727 729 Editor: Jaehoon Paul Jeong 730 731 Editor: Chaehong Chung 732 "; 734 description 735 "This module is a YANG module for Consumer-Facing Interface. 736 Copyright (c) 2020 IETF Trust and the persons 737 identified as authors of the code. All rights reserved. 738 Redistribution and use in source and binary forms, with or 739 without modification, is permitted pursuant to, and subject 740 to the license terms contained in, the Simplified BSD License 741 set forth in Section 4.c of the IETF Trust's Legal Provisions 742 Relating to IETF Documents 743 (http://trustee.ietf.org/license-info). 744 This version of this YANG module is part of RFC XXXX; see 745 the RFC itself for full legal notices."; 747 revision "2020-03-11"{ 748 description "The latest revision"; 749 reference 750 "draft-ietf-consumer-facing-interface-dm-07"; 751 } 753 identity malware-file-type { 754 description 755 "Base identity for malware file types."; 756 } 758 identity executable-file { 759 base malware-file-type; 760 description 761 "Identity for executable file types."; 762 } 764 identity doc-file { 765 base malware-file-type; 766 description 767 "Identity for Microsoft document file types."; 768 } 770 identity html-app-file { 771 base malware-file-type; 772 description 773 "Identity for html application file types."; 774 } 776 identity javascript-file { 777 base malware-file-type; 778 description 779 "Identity for Javascript file types."; 780 } 782 identity pdf-file { 783 base malware-file-type; 784 description 785 "Identity for pdf file types."; 786 } 788 identity dll-file { 789 base malware-file-type; 790 description 791 "Identity for dll file types."; 792 } 794 identity msi-file { 795 base malware-file-type; 796 description 797 "Identity for Microsoft installer file types."; 798 } 800 identity security-event-type { 801 description 802 "Base identity for security event types."; 803 } 805 identity ddos { 806 description 807 "Identity for DDoS event types."; 808 } 810 identity spyware { 811 base malware-file-type; 812 description 813 "Identity for spyware event types."; 814 } 816 identity trojan { 817 base malware-file-type; 818 description 819 "Identity for Trojan infection event types."; 820 } 822 identity ransomware { 823 base malware-file-type; 824 description 825 "Identity for ransomware infection event types."; 826 } 827 identity i2nsf-ipsec { 828 description 829 "Base identity for IPsec method types."; 830 reference 831 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; 832 } 834 identity ipsec-ike { 835 base i2nsf-ipsec; 836 description 837 "Identity for ipsec-ike."; 838 reference 839 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; 840 } 842 identity ipsec-ikeless { 843 base i2nsf-ipsec; 844 description 845 "Identity for ipsec-ikeless."; 846 reference 847 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; 848 } 850 identity continent { 851 description 852 "Base Identity for continent types."; 853 } 855 identity africa { 856 base continent; 857 description 858 "Identity for africa."; 859 } 861 identity asia { 862 base continent; 863 description 864 "Identity for asia."; 865 } 867 identity europe { 868 base continent; 869 description 870 "Identity for europe."; 871 } 873 identity north-america { 874 base continent; 875 description 876 "Identity for north-america."; 877 } 879 identity south-america { 880 base continent; 881 description 882 "Identity for south-america."; 883 } 885 identity oceania { 886 base continent; 887 description 888 "Identity for Oceania"; 889 } 891 identity enforce-type { 892 description 893 "This identity represents the event of 894 policy enforcement trigger type."; 895 } 897 identity admin { 898 description 899 "The identity for policy enforcement by admin."; 900 } 902 identity time { 903 description 904 "The identity for policy enforcement based on time."; 905 } 907 identity protocol-type { 908 description 909 "This identity represents the protocol types."; 910 } 912 identity ftp { 913 base protocol-type; 914 description 915 "The identity for ftp protocol."; 916 reference 917 "RFC 959: File Transfer Protocol (FTP)"; 918 } 920 identity ssh { 921 base protocol-type; 922 description 923 "The identity for ssh protocol."; 924 reference 925 "RFC 4250: The Secure Shell (SSH) Protocol"; 926 } 928 identity telnet { 929 base protocol-type; 930 description 931 "The identity for telnet."; 932 reference 933 "RFC 854: Telnet Protocol"; 934 } 936 identity smtp { 937 base protocol-type; 938 description 939 "The identity for smtp."; 940 reference 941 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 942 } 944 identity sftp { 945 base protocol-type; 946 description 947 "The identity for sftp."; 948 reference 949 "RFC 913: Simple File Transfer Protocol (SFTP)"; 950 } 952 identity http { 953 base protocol-type; 954 description 955 "The identity for http."; 956 reference 957 "RFC 2616: Hypertext Transfer Protocol (HTTP)"; 958 } 960 identity https { 961 base protocol-type; 962 description 963 "The identity for https."; 964 reference 965 "RFC 2818: HTTP over TLS (HTTPS)"; 966 } 968 identity pop3 { 969 base protocol-type; 970 description 971 "The identity for pop3."; 972 reference 973 "RFC 1081: Post Office Protocol -Version 3 (POP3)"; 974 } 976 identity nat { 977 base protocol-type; 978 description 979 "The identity for nat."; 980 reference 981 "RFC 1631: The IP Network Address Translator (NAT)"; 982 } 984 identity primary-action { 985 description 986 "This identity represents the primary actions, such as 987 PASS, DROP, ALERT, RATE-LIMIT, and MIRROR."; 988 } 990 identity pass { 991 base primary-action; 992 description 993 "The identity for pass."; 994 } 996 identity drop { 997 base primary-action; 998 description 999 "The identity for drop."; 1000 } 1002 identity alert { 1003 base primary-action; 1004 description 1005 "The identity for alert."; 1006 } 1008 identity rate-limit { 1009 base primary-action; 1010 description 1011 "The identity for rate-limit."; 1012 } 1014 identity mirror { 1015 base primary-action; 1016 description 1017 "The identity for mirroring."; 1018 } 1019 identity secondary-action { 1020 description 1021 "This field identifies additional actions if a rule is 1022 matched. This could be one of 'LOG', 'SYSLOG', 1023 'SESSION-LOG', etc."; 1024 } 1026 identity log { 1027 base secondary-action; 1028 description 1029 "The identity for logging."; 1030 } 1032 identity syslog { 1033 base secondary-action; 1034 description 1035 "The identity for system logging."; 1036 } 1038 identity session-log { 1039 base secondary-action; 1040 description 1041 "The identity for session logging."; 1042 } 1044 identity signature-type { 1045 description 1046 "This represents the base identity for signature types."; 1047 } 1049 identity signature-yara { 1050 base signature-type; 1051 description 1052 "This represents the YARA signatures."; 1053 } 1055 identity signature-snort { 1056 base signature-type; 1057 description 1058 "This represents the SNORT signatures."; 1059 } 1061 identity signature-suricata { 1062 base signature-type; 1063 description 1064 "This represents the SURICATA signatures."; 1065 } 1066 identity threat-feed-type { 1067 description 1068 "This represents the base identity for threat-feed."; 1069 } 1071 /* 1072 * Typedefs 1073 */ 1074 typedef date-and-time { 1075 type string { 1076 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' 1077 + '(Z|[\+\-]\d{2}:\d{2})'; 1078 } 1079 description 1080 "This is the format of date-and-time."; 1081 reference 1082 "RFC 3339: Date and Time on the Internet: Timestamps 1083 RFC 2579: Textual Conventions for SMIv2 1084 XSD-TYPES: XML Schema Part 2: Datatypes Second Edition"; 1085 } 1087 /* 1088 * Groupings 1089 */ 1091 grouping ipv4-list { 1092 description 1093 "Grouping for ipv4 based ip-addresses."; 1094 leaf-list ipv4 { 1095 type inet:ipv4-address; 1096 description 1097 "This is the entry for the ipv4 ip-addresses."; 1098 } 1099 } 1101 grouping ipv6-list { 1102 description 1103 "Grouping for ipv6 based ip-addresses."; 1104 leaf-list ipv6 { 1105 type inet:ipv6-address; 1106 description 1107 "This is the entry for the ipv6 ip-addresses."; 1108 } 1109 } 1111 grouping ipv4 { 1112 description 1113 "Grouping for ipv4 based ip-address."; 1115 leaf ipv4 { 1116 type inet:ipv4-address; 1117 description 1118 "This is the entry for the ipv4 ip-address."; 1119 } 1120 } 1122 grouping ipv6 { 1123 description 1124 "Grouping for ipv6 based ip-address."; 1125 leaf ipv6 { 1126 type inet:ipv6-address; 1127 description 1128 "This is the entry for the ipv6 ip-address."; 1129 } 1130 } 1132 grouping ip-address-info { 1133 description 1134 "There are two types to configure a security policy 1135 for IPv4 address, such as exact match and range match."; 1136 choice match-type { 1137 description 1138 "User can choose between 'exact match' and 'range match'."; 1139 case exact-match-ipv4 { 1140 uses ipv4; 1141 description 1142 "Exact ip-address match for ipv4 type addresses"; 1143 } 1144 case exact-match-ipv6 { 1145 uses ipv6; 1146 description 1147 "Exact ip-address match for ipv6 type addresses"; 1148 } 1149 case range-match-ipv4 { 1150 list range-ipv4-address { 1151 key "start-ipv4-address end-ipv4-address"; 1152 leaf start-ipv4-address { 1153 type inet:ipv4-address; 1154 description 1155 "Start IPv4 address for a range match."; 1156 } 1157 leaf end-ipv4-address { 1158 type inet:ipv4-address; 1159 description 1160 "End IPv4 address for a range match."; 1161 } 1162 description 1163 "Range match for an IP-address."; 1164 } 1165 } 1166 case range-match-ipv6 { 1167 list range-ipv6-address { 1168 key "start-ipv6-address end-ipv6-address"; 1169 leaf start-ipv6-address { 1170 type inet:ipv6-address; 1171 description 1172 "Start IPv6 address for a range match."; 1173 } 1174 leaf end-ipv6-address { 1175 type inet:ipv6-address; 1176 description 1177 "End IPv6 address for a range match."; 1178 } 1179 description 1180 "Range match for an IP-address."; 1181 } 1182 } 1183 } 1184 } 1186 grouping ipsec-based-method { 1187 description 1188 "This represents the ipsec-based method."; 1189 list ipsec-method { 1190 key "method"; 1191 description 1192 "This represents the list of IPsec method types."; 1193 leaf method { 1194 type identityref { 1195 base i2nsf-ipsec; 1196 } 1197 description 1198 "This represents IPsec IKE and IPsec IKEless cases. 1199 If this is not set, it cannot support IPsec IKE or 1200 IPsec IKEless."; 1201 reference 1202 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; 1203 } 1204 } 1205 } 1207 grouping user-group { 1208 description 1209 "The grouping for user-group entities, and 1210 contains information such as name & ip-address."; 1212 leaf name { 1213 type string; 1214 description 1215 "This represents the name of a user."; 1216 } 1217 uses ip-address-info; 1218 } 1220 grouping device-group { 1221 description 1222 "This group represents device group information 1223 such as ip-address protocol."; 1224 leaf name { 1225 type string; 1226 description 1227 "This represents the name of a device."; 1228 } 1229 uses ip-address-info; 1230 leaf-list protocol { 1231 type identityref { 1232 base protocol-type; 1233 } 1234 description 1235 "This represents the communication protocols of 1236 devices. 1237 If this is not set, it cannot support the 1238 appropriate protocol"; 1239 } 1240 } 1242 grouping location-group { 1243 description 1244 "This group represents location-group information 1245 such as geo-ip and continent."; 1246 leaf name { 1247 type string; 1248 description 1249 "This represents the name of a location."; 1250 } 1251 leaf geo-ip-ipv4 { 1252 type inet:ipv4-address; 1253 description 1254 "This represents the IPv4 geo-ip of a location."; 1255 } 1256 leaf geo-ip-ipv6 { 1257 type inet:ipv6-address; 1258 description 1259 "This represents the IPv6 geo-ip of a location."; 1261 } 1262 leaf continent { 1263 type identityref { 1264 base continent; 1265 } 1266 default asia; 1267 description 1268 "location-group-based on geo-ip of 1269 respective continent."; 1270 } 1271 } 1273 grouping threat-feed-info { 1274 description 1275 "This is the grouping for the threat-feed-list"; 1276 leaf name { 1277 type identityref { 1278 base threat-feed-type; 1279 } 1280 description 1281 "This represents the name of the a threat-feed."; 1282 } 1283 leaf server-ipv4 { 1284 type inet:ipv4-address; 1285 description 1286 "The IPv4 ip-address for the threat-feed server."; 1287 } 1288 leaf server-ipv6 { 1289 type inet:ipv6-address; 1290 description 1291 "The IPv6 ip-address for the threat-feed server."; 1292 } 1293 leaf description { 1294 type string; 1295 description 1296 "This represents the descriptions of a threat-feed. 1297 The description should include information, such as 1298 the type, related threat, method, and file type."; 1299 } 1300 } 1302 grouping payload-string { 1303 description 1304 "The grouping for payload-string content. 1305 It contains information such as name and string 1306 content."; 1307 leaf description { 1308 type string; 1309 description 1310 "This represents the description of a payload. 1311 If this is not set, it cannot support the 1312 description of how the payload content is 1313 related to a security attack."; 1314 } 1315 leaf-list content { 1316 type string; 1317 description 1318 "This represents the string of the payload 1319 contents. This content leaf-list contains the 1320 payload of a packet to analyze a threat. 1321 Due to the types of threats, the type of the 1322 content is defined as string to accommodate 1323 any kind of a payload type such as HTTP, HTTPS, 1324 and SIP. 1325 If this is not set, it cannot support the 1326 payload contents involved in a security attack 1327 as strings"; 1328 } 1329 } 1331 grouping owners-ref { 1332 description 1333 "This grouping is for owners reference using 1334 Network Configuration Access Control Model 1335 (NACM)."; 1336 leaf-list owners { 1337 type leafref { 1338 path "/nacm:nacm/nacm:groups/nacm:group/nacm:name"; 1339 } 1340 description 1341 "This leaf-list names the owner groups of the 1342 list instance it sits on. Only the owners listed 1343 in a NACM group are authorized to get full CRUD 1344 privileges for the contents. 1345 If this is not set, it cannot support who has 1346 the prvilege of the contents"; 1347 } 1348 } 1350 list i2nsf-cfi-policy { 1351 key "policy-name"; 1352 description 1353 "This is the security policy list. Each policy in 1354 the list contains a list of security rules, and is 1355 a policy instance to have complete information 1356 such as where and when a policy needs to be 1357 applied."; 1358 leaf policy-name { 1359 type string; 1360 mandatory true; 1361 description 1362 "The name which identifies the policy."; 1363 } 1364 uses owners-ref; 1366 container rules{ 1367 description 1368 "This container is for rules."; 1369 nacm:default-deny-write; 1370 list rule { 1371 key "rule-name"; 1372 ordered-by user; 1373 leaf rule-name { 1374 type string; 1375 mandatory true; 1376 description 1377 "This represents the name for the rule."; 1378 } 1379 description 1380 "There can be a single or multiple number of 1381 rules."; 1382 uses owners-ref; 1384 container event { 1385 description 1386 "This represents the event (e.g., a security 1387 event, for which a security rule is made.)"; 1388 leaf security-event { 1389 type identityref { 1390 base security-event-type; 1391 } 1392 description 1393 "This contains the description of security 1394 events. If this is not set, it cannot 1395 support which security event is enforced"; 1396 } 1397 choice enforce-type { 1398 description 1399 "There are two different enforcement types; 1400 admin, and time. 1401 It cannot be allowed to configure 1402 admin=='time' or enforce-time=='admin'."; 1403 case enforce-admin { 1404 leaf admin { 1405 type string; 1406 description 1407 "This represents the enforcement type 1408 based on admin's decision."; 1409 } 1410 } 1411 case time { 1412 container time-information { 1413 description 1414 "The begin-time and end-time information 1415 when the security rule should be applied."; 1416 leaf enforce-time { 1417 type date-and-time; 1418 description 1419 "The enforcement type is time-enforced."; 1420 } 1421 leaf begin-time { 1422 type date-and-time; 1423 description 1424 "This is start time for time zone"; 1425 } 1426 leaf end-time { 1427 type date-and-time; 1428 description 1429 "This is end time for time zone"; 1430 } 1431 } 1432 } 1433 } 1434 leaf frequency { 1435 type enumeration { 1436 enum only-once { 1437 description 1438 "This represents the rule is enforced 1439 only once immediately and not 1440 repeated."; 1441 } 1442 enum daily { 1443 description 1444 "This represents the rule is enforced 1445 on a daily basis."; 1446 } 1447 enum weekly { 1448 description 1449 "This represents the rule is enforced 1450 on a weekly basis."; 1451 } 1452 enum monthly { 1453 description 1454 "This represents the rule is enforced 1455 on a monthly basis."; 1456 } 1457 } 1458 default only-once; 1459 description 1460 "This represents how frequent the rule 1461 should be enforced."; 1462 } 1463 } 1465 container condition { 1466 description 1467 "The conditions for general security policies."; 1468 container firewall-condition { 1469 description 1470 "The general firewall condition."; 1471 leaf source { 1472 type leafref { 1473 path "/i2nsf-cfi-policy/endpoint-groups/user-group/name"; 1474 } 1475 description 1476 "This describes the paths to the source reference."; 1477 } 1478 leaf-list dest-target { 1479 type leafref { 1480 path "/i2nsf-cfi-policy/endpoint-groups/user-group/name"; 1481 } 1482 description 1483 "This describes the paths to the destination 1484 target reference."; 1485 } 1486 } 1487 container ddos-condition { 1488 description 1489 "The condition for DDoS mitigation."; 1490 leaf-list source { 1491 type leafref { 1492 path "/i2nsf-cfi-policy/endpoint-groups/device-group/name"; 1493 } 1494 description 1495 "This describes the path to the 1496 source target references."; 1497 } 1498 leaf-list dest-target { 1499 type leafref { 1500 path "/i2nsf-cfi-policy/endpoint-groups/device-group/name"; 1502 } 1503 description 1504 "This describes the path to the destination target 1505 references."; 1506 } 1507 container rate-limit { 1508 description 1509 "This describes the rate-limit."; 1510 leaf packet-threshold-per-second{ 1511 type uint32; 1512 description 1513 "This is a trigger value for the condition."; 1514 } 1515 } 1516 } 1517 container custom-condition { 1518 description 1519 "The condition based on packet contents."; 1520 leaf-list source { 1521 type leafref { 1522 path "/i2nsf-cfi-policy/threat-preventions/payload-content/name"; 1523 } 1524 description 1525 "Describes the payload string content condition 1526 source."; 1527 } 1528 leaf dest-target { 1529 type leafref { 1530 path "/i2nsf-cfi-policy/threat-preventions/payload-content/name"; 1531 } 1532 description 1533 "Describes the payload string content condition destination."; 1534 } 1535 } 1536 container threat-feed-condition { 1537 description 1538 "The condition based on the threat-feed information."; 1539 leaf-list source { 1540 type leafref { 1541 path "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name"; 1542 } 1543 description 1544 "Describes the threat-feed condition source."; 1545 } 1546 leaf dest-target { 1547 type leafref { 1548 path "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name"; 1549 } 1551 description 1552 "Describes the threat-feed condition destination."; 1553 } 1554 } 1555 } 1557 container actions { 1558 description 1559 "This is the action container."; 1560 leaf primary-action { 1561 type identityref { 1562 base primary-action; 1563 } 1564 description 1565 "This represent the primary actions (e.g., 1566 PASS, DROP, ALERT, and MIRROR) to be 1567 applied a condition. 1568 If this is not set, it cannot support 1569 the primary actions."; 1570 } 1571 leaf secondary-action { 1572 type identityref { 1573 base secondary-action; 1574 } 1575 description 1576 "This represents the secondary actions 1577 (e.g., log and syslog) to be applied 1578 if needed. 1579 If this is not set, it cannot support 1580 the secondary actions."; 1581 } 1582 } 1584 container ipsec-method { 1585 description 1586 "This container represents the IPsec IKE 1587 and IKEless cases."; 1588 leaf method { 1589 type identityref { 1590 base i2nsf-ipsec; 1591 } 1592 description 1593 "This references the IPsec method types, 1594 which includes IPsec IKE and IPsec IKEless 1595 cases. 1596 If this is not set, it cannot support 1597 IPsec IKE or IPsec IKEless."; 1598 reference 1599 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; 1600 } 1601 } 1602 } 1603 } 1605 container endpoint-groups { 1606 description 1607 "A logical entity in their business 1608 environment, where a security policy 1609 is to be applied."; 1610 list user-group{ 1611 uses user-group; 1612 key "name"; 1613 description 1614 "This represents the user group."; 1615 } 1616 list device-group { 1617 key "name"; 1618 uses device-group; 1619 description 1620 "This represents the device group."; 1621 } 1622 list location-group{ 1623 key "name"; 1624 uses location-group; 1625 description 1626 "This represents the location group."; 1627 } 1628 } 1630 container threat-preventions { 1631 description 1632 "this describes the list of threat-prevention."; 1633 list threat-feed-list { 1634 key "name"; 1635 description 1636 "There can be a single or multiple number of 1637 threat-feeds."; 1638 uses threat-feed-info; 1639 leaf-list threat-file-types { 1640 type identityref { 1641 base malware-file-type; 1642 } 1643 default executable-file; 1644 description 1645 "This contains a list of file types needed to 1646 be scanned for the virus."; 1648 } 1649 leaf-list signatures { 1650 type identityref { 1651 base signature-type; 1652 } 1653 default signature-suricata; 1654 description 1655 "This contains a list of signatures or hash 1656 of the threats."; 1657 } 1658 } 1659 list payload-content { 1660 key "name"; 1661 leaf name { 1662 type string; 1663 description 1664 "This represents the name of payload-content. 1665 It should give an idea of why specific payload 1666 content is marked as threat. For example, the 1667 name 'backdoor' indicates the payload content 1668 is related to backdoor attack."; 1669 } 1670 description 1671 "This represents the payload-string group."; 1672 uses payload-string; 1673 } 1674 } 1675 } 1676 } 1677 1679 Figure 16: YANG for Consumer-Facing Interface 1681 9. XML Configuration Examples of High-Level Security Policy Rules 1683 This section shows XML configuration examples of high-level security 1684 policy rules that are delivered from the I2NSF User to the Security 1685 Controller over the Consumer-Facing Interface. The considered use 1686 cases are: Database registration, time-based firewall for web 1687 filtering, VoIP/VoLTE security service, and DDoS-attack mitigation. 1689 9.1. Database Registration: Information of Positions and Devices 1690 (Endpoint Group) 1692 If new endpoints are introduced to the network, it is necessary to 1693 first register their data to the database. For example, if new 1694 members are newly introduced in either of three different groups 1695 (i.e., user-group, device-group, and payload-group), each of them 1696 should be registered with information such as ip-addresses or 1697 protocols used by devices. Figure 17 shows an example XML 1698 representation of the registered information for the user-group and 1699 device-group. 1701 1702 1703 1704 employees 1705 1706 221.159.112.1 1707 221.159.112.90 1708 1709 1710 1711 webservers 1712 1713 221.159.112.91 1714 221.159.112.97 1715 1716 http 1717 https 1718 1719 1721 Figure 17: Registering User-group and Device-group Information 1723 9.2. Scenario 1: Block SNS Access during Business Hours 1725 The first example scenario is to "block SNS access during office 1726 hours" using a time-based firewall policy. In this scenario, all 1727 users registered as "employees" in the user-group list are unable to 1728 access Social Networking Services (SNS) during the office hours. The 1729 XML instance is described below: 1731 1732 1733 security_policy_for_blocking_sns 1734 1735 1736 block_access_to_sns_during_office_hours 1737 1738 1739 2020-03-11T09:00:00.00Z 1740 2020-03-11T18:00:00.00Z 1741 1742 only-once 1743 1744 1745 1746 employees 1747 1748 1749 sns-websites 1750 1751 1752 1753 drop 1754 1755 1756 ipsec-ike 1757 1758 1759 1760 1762 Figure 18: An XML Example for Time-based Firewall 1764 Time-based-condition Firewall 1766 1. The policy name is "security_policy_for_blocking_sns". 1768 2. The rule name is "block_access_to_sns_during_office_hours". 1770 3. The Source is "employees". 1772 4. The destination target is "sns-websites". "sns-websites" is the 1773 key which represents the list containing the information, such as 1774 URL, about sns-websites. 1776 5. The action required is to "drop" any attempt to connect to 1777 websites related to Social networking. 1779 6. The IPsec method type used for nsf traffic steering is set to 1780 "ipsec-ike". 1782 9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a Company 1784 The second example scenario is to "block malicious VoIP/VoLTE packets 1785 coming to a company" using a VoIP policy. In this scenario, the 1786 calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that 1787 are classified as malicious are dropped. The IP addresses of the 1788 employees and malicious VOIP IDs should be blocked are stored in the 1789 database or datastore of the enterprise. Here and the rest of the 1790 cases assume that the security administrators or someone responsible 1791 for the existing and newly generated policies, are not aware of which 1792 and/or how many NSFs are needed to meet the security requirements. 1793 Figure 19 represents the XML document generated from YANG discussed 1794 in previous sections. Once a high-level seucurity policy is created 1795 by a security admin, it is delivered by the Consumer-Facing 1796 Interface, through RESTCONF server, to the security controller. The 1797 XML instance is described below: 1799 1800 1801 security_policy_for_blocking_malicious_voip_packets 1802 1803 1804 Block_malicious_voip_and_volte_packets 1805 1806 1807 malicious-id 1808 1809 1810 employees 1811 1812 1813 1814 drop 1815 1816 1817 ipsec-ikeless 1818 1819 1820 1821 1823 Figure 19: An XML Example for VoIP Security Service 1825 Custom-condition Firewall 1826 1. The policy name is 1827 "security_policy_for_blocking_malicious_voip_packets". 1829 2. The rule name is "Block_malicious_voip_and_volte_packets". 1831 3. The Source is "malicious-id". This can be a single ID or a list 1832 of IDs, depending on how the ID are stored in the database. The 1833 "malicious-id" is the key so that the security admin can read 1834 every stored malicious VOIP IDs that are named as "malicious-id". 1836 4. The destination target is "employees". "employees" is the key 1837 which represents the list containing information about employees, 1838 such as IP addresses. 1840 5. The action required is "drop" when any incoming packets are from 1841 "malicious-id". 1843 6. The IPsec method used for nsf traffic steering is set to "ipsec- 1844 ikeless". 1846 9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web 1847 Server 1849 The third example scenario is to "Mitigate HTTP and HTTPS flood 1850 attacks on a company web server" using a DDoS-attack mitigation 1851 policy. Here, the time information is not set because the service 1852 provided by the network should be maintained at all times. If the 1853 packets sent by any sources are more than the set threshold, then the 1854 admin can set the percentage of the packets to be dropped to safely 1855 maintain the service. In this scenario, the source is set as "any" 1856 to block any sources which send abnormal amount of packets. The 1857 destination is set as "web_server01". Once the rule is set and 1858 delivered and enforced to the nsfs by the securiy controller, the 1859 NSFs will monitor the incoming packet amounts and the destination to 1860 act according to the rule set. The XML instance is described below: 1862 1863 1864 security_policy_for_ddos_attacks 1865 1866 1867 100_packets_per_second 1868 1869 1870 webservers 1871 1872 100 1873 1874 1875 1876 1877 drop 1878 1879 1880 ipsec-ikeless 1881 1882 1883 1884 1886 Figure 20: An XML Example for DDoS-attack Mitigation 1888 DDoS-condition Firewall 1890 1. The policy name is "security_policy_for_ddos_attacks". 1892 2. The rule name is "100_packets_per_second". 1894 3. The destination target is "webservers". "webservers" is the key 1895 which represents the list containing information, such as IP 1896 addresses and ports, about web-servers. 1898 4. The rate limit exists to limit the incoming amount of packets per 1899 second. In this case the rate limit is "100" packets per second. 1900 This amount depends on the packet receiving capacity of the 1901 server devices. 1903 5. The Source is all sources which send abnormal amount of packets. 1905 6. The action required is to "drop" packet reception is more than 1906 100 packets per second. 1908 7. The IPsec method used for nsf traffic steering is set to "ipsec- 1909 ike". 1911 10. Security Considerations 1913 The data model for the I2NSF Consumer-Facing Interface is based on 1914 the I2NSF framework [RFC8329], so the same security considerations 1915 with the I2NSF framework should be included in this document. The 1916 data model needs a secure communication channel to protect the 1917 Consumer-Facing Interface between the I2NSF User and Security 1918 Controller. Also, the data model's management access control is 1919 based on Network Configuration Access Control Model(NACM) mechanisms 1920 [RFC8341]. 1922 11. IANA Considerations 1924 This document requests IANA to register the following URI in the 1925 "IETF XML Registry" [RFC3688]: 1927 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 1928 Registrant Contact: The I2NSF. 1929 XML: N/A; the requested URI is an XML namespace. 1931 This document requests IANA to register the following YANG module in 1932 the "YANG Module Names" registry [RFC7950]. 1934 name: ietf-i2nsf-cfi-policy 1935 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 1936 prefix: cfi-policy 1937 reference: RFC 7950 1939 12. Acknowledgments 1941 This work was supported by Institute of Information & Communications 1942 Technology Planning & Evaluation (IITP) grant funded by the Korea 1943 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 1944 Security Intelligence Technology Development for the Customized 1945 Security Service Provisioning). 1947 13. Contributors 1949 This document is made by the group effort of I2NSF working group. 1950 Many people actively contributed to this document, such as Mahdi F. 1951 Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their 1952 contributions. 1954 The following are co-authors of this document: 1956 Hyoungshick Kim 1957 Department of Computer Science and Engineering 1958 Sungkyunkwan University 1959 2066 Seo-ro Jangan-gu 1960 Suwon, Gyeonggi-do 16419 1961 Republic of Korea 1963 EMail: hyoung@skku.edu 1965 Eunsoo Kim 1966 Department of Electronic, Electrical and Computer Engineering 1967 Sungkyunkwan University 1968 2066 Seo-ro Jangan-gu 1969 Suwon, Gyeonggi-do 16419 1970 Republic of Korea 1972 EMail: eskim86@skku.edu 1974 Seungjin Lee 1975 Department of Electronic, Electrical and Computer Engineering 1976 Sungkyunkwan University 1977 2066 Seo-ro Jangan-gu 1978 Suwon, Gyeonggi-do 16419 1979 Republic of Korea 1981 EMail: jine33@skku.edu 1983 Jinyong Tim Kim 1984 Department of Electronic, Electrical and Computer Engineering 1985 Sungkyunkwan University 1986 2066 Seo-ro Jangan-gu 1987 Suwon, Gyeonggi-do 16419 1988 Republic of Korea 1990 EMail: timkim@skku.edu 1992 Anil Lohiya 1993 Juniper Networks 1994 1133 Innovation Way 1995 Sunnyvale, CA 94089 1996 US 1998 EMail: alohiya@juniper.net 1999 Dave Qi 2000 Bloomberg 2001 731 Lexington Avenue 2002 New York, NY 10022 2003 US 2005 EMail: DQI@bloomberg.net 2007 Nabil Bitar 2008 Nokia 2009 755 Ravendale Drive 2010 Mountain View, CA 94043 2011 US 2013 EMail: nabil.bitar@nokia.com 2015 Senad Palislamovic 2016 Nokia 2017 755 Ravendale Drive 2018 Mountain View, CA 94043 2019 US 2021 EMail: senad.palislamovic@nokia.com 2023 Liang Xia 2024 Huawei 2025 101 Software Avenue 2026 Nanjing, Jiangsu 210012 2027 China 2029 EMail: Frank.Xialiang@huawei.com 2031 14. References 2033 14.1. Normative References 2035 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2036 Information Models and Data Models", RFC 3444, 2037 DOI 10.17487/RFC3444, January 2003, 2038 . 2040 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2041 DOI 10.17487/RFC3688, January 2004, 2042 . 2044 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2045 the Network Configuration Protocol (NETCONF)", RFC 6020, 2046 DOI 10.17487/RFC6020, October 2010, 2047 . 2049 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2050 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2051 . 2053 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2054 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2055 . 2057 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2058 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2059 May 2017, . 2061 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2062 and J. Jeong, "Interface to Network Security Functions 2063 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2064 DOI 10.17487/RFC8192, July 2017, 2065 . 2067 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2068 Kumar, "Framework for Interface to Network Security 2069 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2070 . 2072 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2073 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2074 . 2076 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2077 Access Control Model", STD 91, RFC 8341, 2078 DOI 10.17487/RFC8341, March 2018, 2079 . 2081 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2082 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2083 DOI 10.17487/RFC8407, October 2018, 2084 . 2086 14.2. Informative References 2088 [client-facing-inf-req] 2089 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 2090 S., and L. Xia, "Requirements for Client-Facing Interface 2091 to Security Controller", draft-ietf-i2nsf-client-facing- 2092 interface-req-05 (work in progress), May 2018. 2094 [i2nsf-capability-im] 2095 Xia, L., Strassner, J., Basile, C., and D. Lopez, 2096 "Information Model of NSFs Capabilities", draft-ietf- 2097 i2nsf-capability-05 (work in progress), April 2019. 2099 [i2nsf-ipsec] 2100 Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 2101 Garcia, "Software-Defined Networking (SDN)-based IPsec 2102 Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow- 2103 protection-07 (work in progress), August 2019. 2105 [i2nsf-terminology] 2106 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 2107 Birkholz, "Interface to Network Security Functions (I2NSF) 2108 Terminology", draft-ietf-i2nsf-terminology-08 (work in 2109 progress), July 2019. 2111 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- 2112 dm-07 2114 The following changes are made from draft-ietf-i2nsf-consumer-facing- 2115 interface-dm-07: 2117 o This version is revised according to the comments from Jan 2118 Lindblad who reviewed this document as a YANG doctor. 2120 Authors' Addresses 2122 Jaehoon Paul Jeong 2123 Department of Computer Science and Engineering 2124 Sungkyunkwan University 2125 2066 Seobu-Ro, Jangan-Gu 2126 Suwon, Gyeonggi-Do 16419 2127 Republic of Korea 2129 Phone: +82 31 299 4957 2130 Fax: +82 31 290 7996 2131 EMail: pauljeong@skku.edu 2132 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2134 Chaehong Chung 2135 Department of Electronic, Electrical and Computer Engineering 2136 Sungkyunkwan University 2137 2066 Seobu-Ro, Jangan-Gu 2138 Suwon, Gyeonggi-Do 16419 2139 Republic of Korea 2141 Phone: +82 31 299 4957 2142 EMail: darkhong@skku.edu 2144 Tae-Jin Ahn 2145 Korea Telecom 2146 70 Yuseong-Ro, Yuseong-Gu 2147 Daejeon 305-811 2148 Republic of Korea 2150 Phone: +82 42 870 8409 2151 EMail: taejin.ahn@kt.com 2152 Rakesh Kumar 2153 Juniper Networks 2154 1133 Innovation Way 2155 Sunnyvale, CA 94089 2156 USA 2158 EMail: rkkumar@juniper.net 2160 Susan Hares 2161 Huawei 2162 7453 Hickory Hill 2163 Saline, MI 48176 2164 USA 2166 Phone: +1-734-604-0332 2167 EMail: shares@ndzh.com