idnits 2.17.1 draft-ietf-i2nsf-consumer-facing-interface-dm-07.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 29 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 472 has weird spacing: '...address ine...' == Line 477 has weird spacing: '...address ine...' == Line 513 has weird spacing: '...address ine...' == Line 518 has weird spacing: '...address ine...' == Line 637 has weird spacing: '...ription str...' -- The document date (November 4, 2019) is 1634 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 2022, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 2039, 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: May 7, 2020 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 November 4, 2019 13 I2NSF Consumer-Facing Interface YANG Data Model 14 draft-ietf-i2nsf-consumer-facing-interface-dm-07 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 May 7, 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 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-06 . . . . . . . . . . . . . . . . . . 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 Date: Date when this object was created or last modified. 218 Rule: This field contains a list of rules. These rules are 219 defined for 1) communication between two Endpoint Groups, 220 2) for preventing communication with externally or 221 internally identified threats, and 3) for implementing 222 business requirement such as controlling access to internal 223 or external resources for meeting regulatory compliance or 224 business objectives. An organization may restrict certain 225 communication between a set of user and applications for 226 example. The threats may be from threat feeds obtained 227 from external sources or dynamically identified by using 228 specialty devices in the network. Rule conflict analysis 229 should be triggered by the monitoring service to perform an 230 exhaustive detection of anomalies among the configuration 231 rules installed into the security functions. 233 +--rw i2nsf-cfi-policy* [policy-name] 234 +--rw policy-name string 235 | +--rw rule* [rule-name] 236 +--rw endpoint-group 237 +--rw threat-prevention 239 Figure 2: Policy YANG Data Tree 241 A policy is a container of Rule. In order to express a Rule, a Rule 242 must have complete information such as where and when a policy needs 243 to be applied. This is done by defining a set of managed objects and 244 relationship among them. A Policy Rule may be related segmentation, 245 threat mitigation or telemetry data collection from an NSF in the 246 network, which will be specified as the sub-model of the policy model 247 in the subsequent sections. Figure 3 shows the YANG data tree of the 248 Rule object. The rule object SHALL have the following information: 250 Name: This field identifies the name of this object. 252 Event: This field includes the information to determine whether 253 the Rule Condition can be evaluated or not. See details in 254 Section 4.1. 256 Condition: This field contains all the checking conditions to 257 apply to the objective traffic. See details in 258 Section 4.2. 260 Action: This field identifies the action taken when a rule is 261 matched. There is always an implicit action to drop 262 traffic if no rule is matched for a traffic type. See 263 details in Section 4.3. 265 IPsec-Method: This field contains the information about IPsec 266 method type. There are two types such as IPsec-IKE and 267 IPsec-IKEless [i2nsf-ipsec]. 269 Owner: This field contains the onwer of the rule. For example, 270 the person who created it, and eligible for modifying it. 272 +--rw rule* [rule-name] 273 +--rw rule-name string 274 +--rw event 275 +--rw (condition)? 276 +--rw action 277 +--rw ipsec-method 278 +--rw owner identityref 280 Figure 3: Rule YANG Data Tree 282 4.1. Event Sub-model 284 The Event Object contains information related to scheduling a Rule. 285 The Rule could be activated based on a set time or security event. 286 Figure 4 shows the YANG tree of the Event object. Event object SHALL 287 have following information: 289 Security-event: This field identifies for which security event 290 the policy is enforced. The examples of security events 291 are: "DDOS", "spyware", "trojan", and "ransomware". 293 Enforce-type: This field identifies whether the event of 294 triggering policy enforcement is "Admin" or "Time". 296 Admin: This represents the enforcement type based on admin's 297 decision. 299 Time: This represents the security rule is enforced based on 300 begin-time and end-time information. 302 Frequency: This represents how frequent the rule should be 303 enforced. There are four options: "only-once", "daily", 304 "weekly" and "monthly". 306 +--rw event 307 +--rw security-event identityref 308 +--rw (enforce-type)? 309 | +--:(admin) 310 | | +--rw admin? identityref 311 | +--:(time) 312 | +--rw time-information 313 | +--rw begin-time? yang:date-and-time 314 | +--rw end-time? yang:date-and-time 315 +--rw frequency? enumeration 317 Figure 4: Event Sub-model YANG Data Tree 319 4.2. Condition Sub-model 321 This object represents Conditions that Security Administrator wants 322 to apply the checking on the traffic in order to determine whether 323 the set of actions in the Rule can be executed or not. The Condition 324 Sub-model consists of three different types of containers each 325 representing different cases, such as general firewall and DDoS- 326 mitigation cases, and a case when the condition is based on the 327 payload strings of packets. Each containers have source-target and 328 destination-target to represent the source and destination for each 329 case. Figure 5 shows the YANG tree of the Condition object. The 330 Condition Sub-model SHALL have following information: 332 Case (Firewall-condition): This field represents the general 333 firewall case, where a security admin can set up firewall 334 conditions using the information present in this field. 335 The source and destination is represented as firewall- 336 source and firewall-destination, each referring to the IP- 337 address-based groups defined in the endpoint-group. 339 Case (DDoS-condition): This field represents the condition for 340 DDoS mitigation, where a security admin can set up DDoS 341 mitigation conditions using the information present in this 342 field. The source and destination is represented as ddos- 343 source and ddos-destination, each referring to the device- 344 groups defined and registered in the endpoint-group. 346 Case (Custom-condition): This field contains the payload string 347 information. This information is useful when security rule 348 condition is based on the string contents of incoming or 349 outgoing packets. The source and destination is 350 represented as custom-source and custom-destination, each 351 referring to the payload-groups defined and registered in 352 the endpoint-group. 354 Case (Threat-feed-condition): This field contains the information 355 obtained from threat-feeds (e.g., Palo-Alto, or RSA- 356 netwitness). This information is useful when security rule 357 condition is based on the existing threat reports gathered 358 by other sources. The source and destination is 359 represented as threat-feed-source and threat-feed- 360 destination. For clarity, threat-feed-source/destination 361 represent the source/destination of a target security 362 threat, not the information source/destination of a threat- 363 feed. 365 +--rw (condition)? 366 +--:(firewall-condition) 367 | +--rw firewall-source 368 | | +--rw src-target -> /../../nacm:group/nacm:user-name 369 | +--rw firewall-destination 370 | +--rw dest-target* -> /../../nacm:group/nacm:user-name 371 +--:(ddos-condition) 372 | +--rw ddos-source 373 | | +--rw src-target* -> /../../device-group/name 374 | +--rw ddos-destination 375 | | +--rw dest-target* -> /../../device-group/name 376 | +--rw rate-limit 377 | +--rw packet-per-second? uint16 378 +--:(custom-condition) 379 | +--rw custon-source 380 | | +--rw src-target* -> /../../payload-content/name 381 | +--rw custom-destination 382 | +--rw dest-target -> /../../payload-content/name 383 +--:(threat-feed-condition) 384 +--rw threat-feed-source 385 | +--rw src-target* -> /../../threat-feed-list/feed-name 386 +--rw threat-feed-destination 387 +--rw dest-target -> /../../threat-feed-list/feed-name 389 Figure 5: Condition Sub-model YANG Data Tree 391 4.3. Action Sub-model 393 This object represents actions that Security Admin wants to perform 394 based on certain traffic class. Figure 6 shows the YANG tree of the 395 Action object. The Action object SHALL have following information: 397 Primary-action: This field identifies the action when a rule is 398 matched by an NSF. The action could be one of "PASS", 399 "DROP", "ALERT", "RATE-LIMIT", and "MIRROR". 401 Secondary-action: This field identifies the action when a rule is 402 matched by an NSF. The action could be one of "log", 403 "syslog", "session-log". 405 +--rw action 406 +--rw primary-action identityref 407 +--rw secondary-action? identityref 409 Figure 6: Action Sub-model YANG Data Tree 411 5. Information Model for Policy Endpoint Groups 413 The Policy Endpoint Group is a very important part of building User- 414 Construct based policies. A Security Administrator would create and 415 use these objects to represent a logical entity in their business 416 environment, where a Security Policy is to be applied. There are 417 multiple managed objects that constitute a Policy's Endpoint Group as 418 shown in Figure 7. Figure 8 shows the YANG tree of the Endpoint- 419 Group object. This section lists these objects and relationship 420 among them. 422 +-------------------+ 423 | Endpoint Group | 424 +---------+---------+ 425 ^ 426 | 427 +--------------+----------------+ 428 1..n | 1..n | 1..n | 429 +-----+----+ +------+-----+ +-------+------+ 430 |User-group| |Device-group| |Location-group| 431 +----------+ +------------+ +--------------+ 433 Figure 7: Endpoint Group Diagram 435 +--rw endpoint-group 436 +--rw user-group* [name] 437 ... 438 +--rw device-group* [name] 439 ... 440 +--rw location-group* [name] 441 ... 443 Figure 8: Endpoint Group YANG Data Tree 445 5.1. User Group 447 This object represents a User-Group. Figure 9 shows the YANG tree of 448 the User-Group object. The User-Group object SHALL have the 449 following information: 451 Name: This field identifies the name of this object. 453 IP-address: This represents the IPv4 address of a user in the 454 user group. 456 range-ipv4-address: This represents the IPv4 address of a user in 457 the user gorup. 459 range-ipv6-address: This represents the IPv6 address of a user in 460 the user gorup. 462 +--rw user-group* [name] 463 +--rw name -> /../../nacm:group/nacm:user-name 464 +--rw (match-type)? 465 +--:(exact-match-ipv4) 466 | +--rw ip-address* inet:ipv4-address 467 +--:(exact-match-ipv6) 468 | +--rw ip-address* inet:ipv4-address 469 +--:(range-match-ipv4) 470 | +--rw range-ipv4-address* 471 [start-ipv4-address end-ipv4-address] 472 | +--rw start-ipv4-address inet:ipv4-address 473 | +--rw end-ipv4-address inet:ipv4-address 474 +--:(range-match-ipv6) 475 +--rw range-ipv6-address* 476 [start-ipv6-vaddress end-ipv6-address] 477 +--rw start-ipv6-address inet:ipv6-address 478 +--rw end-ipv6-address inet:ipv6-address 480 Figure 9: User Group YANG Data Tree 482 5.2. Device Group 484 This object represents a Device-Group. Figure 10 shows the YANG tree 485 of the Device-group object. The Device-Group object SHALL have the 486 following information: 488 Name: This field identifies the name of this object. 490 IP-address: This represents the IPv4 address of a device in the 491 device group. 493 range-ipv4-address: This represents the IPv4 address of a device 494 in the device gorup. 496 range-ipv6-address: This represents the IPv6 address of a device 497 in the device gorup. 499 Protocol: This represents the communication protocols used by the 500 devices. The protocols are "SSH", "FTP", "SMTP", "HTTP", 501 "HTTPS", and etc. 503 +--rw device-group* [name] 504 +--rw name string 505 +--rw (match-type)? 506 | +--:(exact-match-ipv4) 507 | | +--rw ip-address* inet:ipv4-address 508 | +--:(exact-match-ipv6) 509 | | +--rw ip-address* inet:ipv4-address 510 | +--:(range-match-ipv4) 511 | | +--rw range-ipv4-address* 512 [start-ipv4-address end-ipv4-address] 513 | | +--rw start-ipv4-address inet:ipv4-address 514 | | +--rw end-ipv4-address inet:ipv4-address 515 | +--:(range-match-ipv6) 516 | +--rw range-ipv6-address* 517 [start-ipv6-vaddress end-ipv6-address] 518 | +--rw start-ipv6-address inet:ipv6-address 519 | +--rw end-ipv6-address inet:ipv6-address 520 +--rw protocol identityref 522 Figure 10: Device Group YANG Data Tree 524 5.3. Location Group 526 This object represents a location group based on either tag or other 527 information. Figure 11 shows the YANG tree of the Location-Group 528 object. The Location-Group object SHALL have the following 529 information: 531 Name: This field identifies the name of this object. 533 geo-ip-ipv4: This field represents the IPv4 Geo-ip of a location. 535 geo-ip-ipv6: This field represents the IPv6 Geo-ip of a location. 537 continent: This field represents the continent where the location 538 group member is at. 540 +--rw location-group* [name] 541 +--rw name string 542 +--rw geo-ip-ipv4 inet:ipv4-address 543 +--rw geo-ip-ipv6 inet:ipv6-address 544 +--rw continent? identityref 546 Figure 11: Location Group YANG Data Tree 548 6. Information Model for Threat Prevention 550 The threat prevention plays an important part in the overall security 551 posture by reducing the attack surfaces. This information could come 552 from various threat feeds (i.e., sources for obtaining the threat 553 information). There are multiple managed objects that constitute 554 this category. This section lists these objects and relationship 555 among them. Figure 13 shows the YANG tree of a Threat-Prevention 556 object. 558 +-------------------+ 559 | Threat Prevention | 560 +---------+---------+ 561 ^ 562 | 563 +---------+---------+ 564 1..n | 1..n | 565 +------+------+ +--------+--------+ 566 | Threat-feed | | payload-content | 567 +-------------+ +-----------------+ 569 Figure 12: Threat Prevention Diagram 571 +--rw threat-prevention 572 +--rw threat-feed-list* [name] 573 ... 574 +--rw payload-content* [name] 575 ... 577 Figure 13: Threat Prevention YANG Data Tree 579 6.1. Threat Feed 581 This object represents a threat feed which provides signatures of 582 malicious activities. Figure 14 shows the YANG tree of a Threat- 583 feed-list. The Threat-Feed object SHALL have the following 584 information: 586 Feed-name: This field identifies the name of this object. 588 Feed-Server-ipv4: This represents the IPv4 server address of the 589 feed provider, it may be external or local servers. 591 Feed-Server-ipv6: This represents the IPv6 server address of the 592 feed provider, it may be external or local servers. 594 Feed-description: This is the description of the threat feed. 595 The descriptions should have clear indication of the 596 security attack such as attack type (e.g., APT) and file 597 types used (e.g., executable malware). 599 Threat-file-types: This field identifies the information about 600 the file types identified and reported by the threat-feed. 602 signatures: This field contains the signatures of malicious 603 programs or activities provided by the threat-feed. The 604 examples of signature types are "YARA", "SURICATA", and 605 "SNORT". 607 +--rw threat-prevention 608 +--rw threat-feed-list* [feed-name] 609 +--rw feed-name identityref 610 +--rw feed-server-ipv4? inet:ipv4-address 611 +--rw feed-server-ipv6? inet:ipv6-address 612 +--rw feed-description? string 613 +--rw threat-file-types* identityref 614 +--rw signatures* identityref 616 Figure 14: Threat Feed YANG Data Tree 618 6.2. Payload Content 620 This object represents a custom list created for the purpose of 621 defining exception to threat feeds. Figure 15 shows the YANG tree of 622 a Payload-content list. The Payload-Content object SHALL have the 623 following information: 625 Name: This field identifies the name of this object. For 626 example, the name "backdoor" indicates the payload content 627 is related to backdoor attack. 629 payload-description: This represents the description of how the 630 payload content is related to a security attack. 632 Content: This contains the payload contents, which are involed in 633 a security attack, as strings. 635 +--rw payload-content* [name] 636 +--rw name string 637 +--rw payload-description string 638 +--rw content* string 640 Figure 15: Payload Content in YANG Data Tree 642 7. Network Configuration Access Control Model (NACM) 644 Network Configuration Access Control Model (NACM) provides a high- 645 level overview of the access control with the following features 646 [RFC8341]: 648 o Independent control of action, data, and notification access is 649 provided. 651 o A simple and familiar set of datastore permissions is used. 653 o Support for YANG security tagging allows default security modes to 654 automatically exclude sensitive data. 656 o Separate default access modes for read, write, and execute 657 permissions are provided. 659 o Access control rules are applied to configurable groups of users. 661 The data model for the I2NSF Consumer-Facing Interface provides NACM 662 mechanisms and concepts to user-group and owners permissions. The 663 NACM with the above features can be used to set up all the management 664 access controls in the I2NSF high-level authorization view, and it 665 may have a high impact on the optimization and performance. 667 8. YANG Data Model of Consumer-Facing Interface 669 The main objective of this data model is to provide both an 670 information model and the corresponding YANG data model of I2NSF 671 Consumer-Facing Interface. This interface can be used to deliver 672 control and management messages between an I2NSF User and Security 673 Controller for the I2NSF User's high-level security policies. 675 The semantics of the data model must be aligned with the information 676 model of the Consumer-Facing Interface. The transformation of the 677 information model was performed so that this YANG data model can 678 facilitate the efficient delivery of the control or management 679 messages. 681 This data model is designed to support the I2NSF framework that can 682 be extended according to the security needs. In other words, the 683 model design is independent of the content and meaning of specific 684 policies as well as the implementation approach. This document 685 suggests a VoIP/VoLTE security service as a use case for policy rule 686 generation. 688 This section describes a YANG data model for Consumer-Facing 689 Interface, based on the information model of Consumer-Facing 690 Interface to Security Controller. 692 file "ietf-i2nsf-cfi-policy@2019-11-04.yang" 693 module ietf-i2nsf-cfi-policy { 694 yang-version 1.1; 695 namespace 696 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; 697 prefix 698 cfi-policy; 700 import ietf-yang-types{ 701 prefix yang; 702 reference 703 "Section 3 of RFC 6991"; 704 } 706 import ietf-inet-types{ 707 prefix inet; 708 reference 709 "Section 4 of RFC 6991"; 710 } 712 import ietf-netconf-acm { 713 prefix nacm; 714 } 716 organization 717 "IETF I2NSF (Interface to Network Security Functions) 718 Working Group"; 720 contact 721 "WG Web: 722 WG List: 724 WG Chair: Linda Dunbar 725 727 WG Chair: Yoav Nir 728 730 Editor: Jaehoon Paul Jeong 731 733 Editor: Chaehong Chung 734 "; 736 description 737 "This module is a YANG module for Consumer-Facing Interface. 738 Copyright (c) 2018 IETF Trust and the persons identified as 739 authors of the code. All rights reserved. 740 Redistribution and use in source and binary forms, with or 741 without modification, is permitted pursuant to, and subject 742 to the license terms contained in, the Simplified BSD License 743 set forth in Section 4.c of the IETF Trust's Legal Provisions 744 Relating to IETF Documents 745 (http://trustee.ietf.org/license-info). 746 This version of this YANG module is part of RFC XXXX; see 747 the RFC itself for full legal notices."; 749 revision "2019-11-04"{ 750 description "The latest revision"; 751 reference 752 "draft-ietf-consumer-facing-interface-dm-07"; 753 } 755 identity malware-file-type { 756 description 757 "Base identity for malware file types."; 758 } 759 identity executable-file { 760 base malware-file-type; 761 description 762 "Identity for executable file types."; 763 } 764 identity doc-file { 765 base malware-file-type; 766 description 767 "Identity for Microsoft document file types."; 768 } 769 identity html-app-file { 770 base malware-file-type; 771 description 772 "Identity for html application file types."; 773 } 774 identity javascript-file { 775 base malware-file-type; 776 description 777 "Identity for Javascript file types."; 778 } 779 identity pdf-file { 780 base malware-file-type; 781 description 782 "Identity for pdf file types."; 783 } 784 identity dll-file { 785 base malware-file-type; 786 description 787 "Identity for dll file types."; 788 } 789 identity msi-file { 790 base malware-file-type; 791 description 792 "Identity for Microsoft installer file types."; 793 } 795 identity security-event-type { 796 description 797 "Base identity for security event types."; 798 } 799 identity ddos { 800 base malware-file-type; 801 description 802 "Identity for DDoS event types."; 803 } 804 identity spyware { 805 base malware-file-type; 806 description 807 "Identity for spyware event types."; 808 } 809 identity trojan { 810 base malware-file-type; 811 description 812 "Identity for Trojan infection event types."; 813 } 814 identity ransomware { 815 base malware-file-type; 816 description 817 "Identity for ransomware infection event types."; 818 } 820 identity i2nsf-ipsec { 821 description 822 "Base identity for IPsec method types."; 824 } 825 identity ipsec-ike { 826 base i2nsf-ipsec; 827 description 828 "Identity for ipsec-ike."; 829 } 831 identity ipsec-ikeless { 832 base i2nsf-ipsec; 833 description 834 "Identity for ipsec-ikeless."; 835 } 837 identity continent { 838 description 839 "Base Identity for continent types."; 840 } 842 identity africa { 843 base continent; 844 description 845 "Identity for africa."; 846 } 847 identity asia { 848 base continent; 849 description 850 "Identity for asia."; 851 } 852 identity europe { 853 base continent; 854 description 855 "Identity for europe."; 856 } 857 identity north-america { 858 base continent; 859 description 860 "Identity for north-america."; 861 } 862 identity south-america { 863 base continent; 864 description 865 "Identity for south-america."; 866 } 867 identity oceania { 868 base continent; 869 description 870 "Identity for Oceania"; 871 } 872 identity enforce-type { 873 description 874 "This identity represents the event of 875 policy enforcement trigger type."; 876 } 877 identity admin { 878 base enforce-type; 879 description 880 "The identity for policy enforcement by admin."; 881 } 882 identity time { 883 base enforce-type; 884 description 885 "The identity for policy enforcement based on time."; 886 } 888 identity protocol-type { 889 description 890 "This identity represents the protocol types."; 891 } 892 identity ftp { 893 base protocol-type; 894 description 895 "The identity for ftp protocol."; 896 } 897 identity ssh { 898 base protocol-type; 899 description 900 "The identity for ssh protocol."; 901 } 902 identity telnet { 903 base protocol-type; 904 description 905 "The identity for telnet."; 906 } 907 identity smtp { 908 base protocol-type; 909 description 910 "The identity for smtp."; 911 } 912 identity sftp { 913 base protocol-type; 914 description 915 "The identity for sftp."; 916 } 917 identity http { 918 base protocol-type; 919 description 920 "The identity for http."; 921 } 922 identity https { 923 base protocol-type; 924 description 925 "The identity for https."; 926 } 927 identity pop3 { 928 base protocol-type; 929 description 930 "The identity for pop3."; 931 } 932 identity nat { 933 base protocol-type; 934 description 935 "The identity for nat."; 936 } 938 identity primary-action { 939 description 940 "This identity represents the primary actions, such as 941 PASS, DROP, ALERT, RATE-LIMIT, and MIRROR."; 942 } 943 identity pass { 944 base primary-action; 945 description 946 "The identity for pass."; 947 } 948 identity drop { 949 base primary-action; 950 description 951 "The identity for drop."; 952 } 953 identity alert { 954 base primary-action; 955 description 956 "The identity for alert."; 957 } 958 identity rate-limit { 959 base primary-action; 960 description 961 "The identity for rate-limit."; 962 } 963 identity mirror { 964 base primary-action; 965 description 966 "The identity for mirroring."; 967 } 968 identity secondary-action { 969 description 970 "This field identifies additional actions if a rule is 971 matched. This could be one of 'LOG', 'SYSLOG', 972 'SESSION-LOG', etc."; 973 } 974 identity log { 975 base secondary-action; 976 description 977 "The identity for logging."; 978 } 979 identity syslog { 980 base secondary-action; 981 description 982 "The identity for system logging."; 983 } 984 identity session-log { 985 base secondary-action; 986 description 987 "The identity for session logging."; 988 } 990 identity owner { 991 description 992 "This is the base identity for the owner"; 993 } 994 identity dept-head { 995 base owner; 996 description 997 "This represents the identity of the head of department."; 998 } 999 identity manager { 1000 base owner; 1001 description 1002 "This represents the identity of the manager of the department."; 1003 } 1004 identity employee { 1005 base owner; 1006 description 1007 "This represents the identity of department employees."; 1008 } 1009 identity sec-head { 1010 base owner; 1011 description 1012 "This represents the identity of the head of security."; 1013 } 1014 identity sec-admin { 1015 base owner; 1016 description 1017 "This represents the identity of security admin."; 1018 } 1020 identity signature-type { 1021 description 1022 "This represents the base identity for signature types."; 1023 } 1024 identity signature-yara { 1025 base signature-type; 1026 description 1027 "This represents the YARA signatures."; 1028 } 1029 identity signature-snort { 1030 base signature-type; 1031 description 1032 "This represents the SNORT signatures."; 1033 } 1034 identity signature-suricata { 1035 base signature-type; 1036 description 1037 "This represents the SURICATA signatures."; 1038 } 1040 identity threat-feed-type { 1041 description 1042 "This represents the base identity for threat-feed."; 1043 } 1044 identity palo-alto { 1045 base threat-feed-type; 1046 description 1047 "This represents Palo-Alto threat-feed."; 1048 } 1049 identity rsa-netwitness { 1050 base threat-feed-type; 1051 description 1052 "This represents RSA-netwitness threat-feed."; 1053 } 1054 identity fireeye { 1055 base threat-feed-type; 1056 description 1057 "This represents FireEye threat-feed."; 1058 } 1059 identity alienvault { 1060 base threat-feed-type; 1061 description 1062 "This represents Alienvault threat-feed."; 1063 } 1065 /* 1066 * Groupings 1067 */ 1069 grouping ipv4-list { 1070 description 1071 "Grouping for ipv4 based ip-addresses."; 1072 leaf-list ipv4 { 1073 type inet:ipv4-address; 1074 description 1075 "This is the entry for the ipv4 ip-addresses."; 1076 } 1077 } 1079 grouping ipv6-list { 1080 description 1081 "Grouping for ipv6 based ip-addresses."; 1082 leaf-list ipv6 { 1083 type inet:ipv6-address; 1084 description 1085 "This is the entry for the ipv6 ip-addresses."; 1086 } 1087 } 1089 grouping ipv4 { 1090 description 1091 "Grouping for ipv4 based ip-address."; 1092 leaf ipv4 { 1093 type inet:ipv4-address; 1094 description 1095 "This is the entry for the ipv4 ip-address."; 1096 } 1097 } 1099 grouping ipv6 { 1100 description 1101 "Grouping for ipv6 based ip-address."; 1102 leaf ipv6 { 1103 type inet:ipv6-address; 1104 description 1105 "This is the entry for the ipv6 ip-address."; 1106 } 1107 } 1109 grouping ip-address-info { 1110 description 1111 "There are two types to configure a security policy 1112 for IPv4 address, such as exact match and range match."; 1114 choice match-type { 1115 description 1116 "User can choose between 'exact match' and 'range match'."; 1117 case exact-match-ipv4 { 1118 uses ipv4; 1119 description 1120 "Exact ip-address match for ipv4 type addresses"; 1121 } 1122 case exact-match-ipv6 { 1123 uses ipv6; 1124 description 1125 "Exact ip-address match for ipv6 type addresses"; 1126 } 1127 case range-match-ipv4 { 1128 list range-ipv4-address { 1129 key "start-ipv4-address end-ipv4-address"; 1130 leaf start-ipv4-address { 1131 type inet:ipv4-address; 1132 description 1133 "Start IPv4 address for a range match."; 1134 } 1135 leaf end-ipv4-address { 1136 type inet:ipv4-address; 1137 description 1138 "End IPv4 address for a range match."; 1139 } 1140 description 1141 "Range match for an IP-address."; 1142 } 1143 } 1144 case range-match-ipv6 { 1145 list range-ipv6-address { 1146 key "start-ipv6-address end-ipv6-address"; 1147 leaf start-ipv6-address { 1148 type inet:ipv6-address; 1149 description 1150 "Start IPv6 address for a range match."; 1151 } 1152 leaf end-ipv6-address { 1153 type inet:ipv6-address; 1154 description 1155 "End IPv6 address for a range match."; 1156 } 1157 description 1158 "Range match for an IP-address."; 1159 } 1160 } 1161 } 1163 } 1165 grouping ipsec-based-method { 1166 description 1167 "This represents the ipsec-based method."; 1168 list ipsec-method { 1169 key "method"; 1170 description 1171 "This represents the list of IPsec method types."; 1173 leaf method { 1174 type identityref { 1175 base i2nsf-ipsec; 1176 } 1177 description 1178 "This represents IPsec IKE and IPsec IKEless cases."; 1179 } 1180 } 1181 } 1183 grouping user-group { 1184 description 1185 "The grouping for user-group entities, and 1186 contains information such as name & ip-address."; 1187 leaf-list name { 1188 type leafref { 1189 path /nacm:nacm/nacm:groups/nacm:group/nacm:user-name; 1190 } 1191 description 1192 "This represents the name of a user."; 1193 } 1194 uses ip-address-info; 1195 } 1197 grouping device-group { 1198 description 1199 "This group represents device group information 1200 such as ip-address protocol."; 1201 leaf name { 1202 type string; 1203 description 1204 "This represents the name of a device."; 1205 } 1206 uses ip-address-info; 1207 leaf-list protocol { 1208 type identityref { 1209 base protocol-type; 1210 } 1211 description 1212 "This represents the communication protocols of devices."; 1213 } 1214 } 1216 grouping location-group { 1217 description 1218 "This group represents location-group information 1219 such as geo-ip and continent."; 1220 leaf name { 1221 type string; 1222 description 1223 "This represents the name of a location."; 1224 } 1225 leaf geo-ip-ipv4 { 1226 type inet:ipv4-address; 1227 description 1228 "This represents the IPv4 geo-ip of a location."; 1229 } 1230 leaf geo-ip-ipv6 { 1231 type inet:ipv6-address; 1232 description 1233 "This represents the IPv6 geo-ip of a location."; 1234 } 1235 leaf continent { 1236 type identityref { 1237 base continent; 1238 } 1239 description 1240 "location-group-based on geo-ip of 1241 respective continent."; 1242 } 1243 } 1245 grouping threat-feed-info { 1246 description 1247 "This is the grouping for the threat-feed-list"; 1249 leaf feed-name { 1250 type identityref { 1251 base threat-feed-type; 1252 } 1253 description 1254 "This represents the name of the a threat-feed."; 1255 } 1256 leaf feed-server-ipv4 { 1257 type inet:ipv4-address; 1258 description 1259 "The IPv4 ip-address for the threat-feed server."; 1260 } 1261 leaf feed-server-ipv6 { 1262 type inet:ipv6-address; 1263 description 1264 "The IPv6 ip-address for the threat-feed server."; 1265 } 1266 leaf feed-description { 1267 type string; 1268 description 1269 "This represents the descriptions of a threat-feed. 1270 The description should include information, such as 1271 the type, related threat, method, and file type."; 1272 } 1273 } 1275 grouping payload-string { 1276 description 1277 "The grouping for payload-string content. 1278 It contains information such as name and string content."; 1279 leaf payload-description { 1280 type string; 1281 description 1282 "This represents the description of a payload."; 1283 } 1284 leaf-list content { 1285 type string; 1286 description 1287 "This represents the payload string content."; 1288 } 1289 } 1291 grouping owners-ref { 1292 description 1293 "This grouping is for owners reference using Network configuration Access Control Model (NACM)."; 1294 leaf-list owners { 1295 type leafref { 1296 path /nacm:nacm/nacm:groups/nacm:group/nacm:name; 1297 } 1298 description 1299 "This leaf-list names the owner groups of the 1300 list instace it sits on. Only the owners and 1301 super users are authorized to modify the contents."; 1302 } 1303 } 1305 list i2nsf-cfi-policy { 1306 key "policy-name"; 1307 description 1308 "This is the security policy list. Each policy in the list 1309 contains a list of security rules, and is a policy instance 1310 to have complete information such as where and when a 1311 policy needs to be applied."; 1312 leaf policy-name { 1313 type string; 1314 mandatory true; 1315 description 1316 "The name which identifies the policy."; 1317 } 1318 uses owners-ref; 1320 container rule{ 1321 description 1322 "This container is for rules."; 1323 nacm:default-deny-write; 1324 list rule { 1325 leaf rule-name { 1326 type string; 1327 mandatory true; 1328 description 1329 "This represents the name for the rule."; 1330 } 1331 key "rule-name"; 1332 description 1333 "There can be a single or multiple number of rules."; 1334 uses owners-ref; 1336 container event { 1337 description 1338 "This represents the event (e.g., a security event, 1339 which a security rule is made for.)"; 1340 leaf security-event { 1341 type identityref { 1342 base security-event-type; 1343 } 1344 mandatory true; 1345 description 1346 "This contains the description of security events."; 1347 } 1348 choice enforce-type { 1349 description 1350 "There are three different enforcement types; admin, and time."; 1351 case enforce-admin { 1352 leaf admin { 1353 type identityref { 1354 base enforce-type; 1355 } 1356 description 1357 "This represents the enforcement type based on admin's 1358 decision."; 1359 } 1360 } 1361 case time { 1362 container time-information { 1363 description 1364 "The begin-time and end-time information 1365 when the security rule should be applied."; 1366 leaf enforce-time { 1367 type identityref { 1368 base enforce-type; 1369 } 1370 description 1371 "The enforcement type is time-enforced."; 1372 } 1373 leaf begin-time { 1374 type yang:date-and-time; 1375 description 1376 "This is start time for time zone"; 1377 } 1378 leaf end-time { 1379 type yang:date-and-time; 1380 description 1381 "This is end time for time zone"; 1382 } 1383 } 1384 } 1385 } 1386 leaf frequency { 1387 type enumeration { 1388 enum only-once { 1389 description 1390 "This represents the rule is enforced only once."; 1391 } 1392 enum daily { 1393 description 1394 "This represents the rule is enforced on a daily basis."; 1395 } 1396 enum weekly { 1397 description 1398 "This represents the rule is enforced on a weekly basis."; 1399 } 1400 enum monthly { 1401 description 1402 "This represents the rule is enforced on a monthly basis."; 1403 } 1404 } 1405 default only-once; 1406 description 1407 "This represents how frequent the rule should be enforced."; 1408 } 1409 } 1410 container condition { 1411 description 1412 "The conditions for general security policies."; 1413 choice condition { 1414 description 1415 "This choice condition is for general firewall."; 1416 case firewall-condition { 1417 description 1418 "The general firewall condition."; 1419 container firewall-source { 1420 description 1421 "This represents the source."; 1422 leaf src-target { 1423 type leafref { 1424 path /nacm:nacm/nacm:groups/nacm:group/nacm:user-name; 1425 } 1426 mandatory true; 1427 description 1428 "This describes the paths to 1429 the source reference."; 1430 } 1431 } 1432 container firewall-destination { 1433 description 1434 "This represents the destination."; 1435 leaf-list dest-target { 1436 type leafref { 1437 path /nacm:nacm/nacm:groups/nacm:group/nacm:user-name; 1438 } 1439 description 1440 "This describes the paths to the 1441 destination target reference."; 1442 } 1443 } 1444 } 1445 case ddos-condition { 1446 description 1447 "The condition for DDoS mitigation."; 1448 container ddos-source { 1449 description 1450 "This represents the source."; 1451 leaf-list src-target { 1452 type leafref { 1453 path "/i2nsf-cfi-policy/endpoint-group/device-group/name"; 1454 } 1455 description 1456 "This describes the path to the 1457 source target references."; 1458 } 1459 } 1460 container ddos-destination { 1461 description 1462 "This represents the target."; 1463 leaf-list dest-target { 1464 type leafref { 1465 path "/i2nsf-cfi-policy/endpoint-group/device-group/name"; 1466 } 1467 description 1468 "This describes the path to the 1469 destination target references."; 1470 } 1471 } 1472 container rate-limit { 1473 description "This describes the rate-limit."; 1474 leaf packet-per-second { 1475 type uint16; 1476 description 1477 "The rate-limit limits the amount of incoming packets."; 1478 } 1479 } 1480 } 1481 case custom-condition { 1482 description 1483 "The condition based on packet contents."; 1484 container custon-source { 1485 description 1486 "This represents the source."; 1487 leaf-list src-target { 1488 type leafref { 1489 path "/i2nsf-cfi-policy/threat-prevention/payload-content/name"; 1490 } 1491 description 1492 "Describes the payload string 1493 content condition source."; 1494 } 1495 } 1496 container custom-destination { 1497 description 1498 "This represents the destination."; 1499 leaf dest-target { 1500 type leafref { 1501 path "/i2nsf-cfi-policy/threat-prevention/payload-content/name"; 1502 } 1503 mandatory true; 1504 description 1505 "Describes the payload string 1506 content condition destination."; 1507 } 1508 } 1509 } 1510 case threat-feed-condition { 1511 description 1512 "The condition based on the threat-feed information."; 1513 container threat-feed-source { 1514 description 1515 "This represents the source."; 1516 leaf-list src-target { 1517 type leafref { 1518 path "/i2nsf-cfi-policy/threat-prevention/threat-feed-list/feed-name"; 1519 } 1520 description "Describes the threat-feed 1521 condition source."; 1522 } 1523 } 1524 container threat-feed-destination { 1525 description 1526 "This represents the destination."; 1527 leaf dest-target { 1528 type leafref { 1529 path "/i2nsf-cfi-policy/threat-prevention/threat-feed-list/feed-name"; 1530 } 1531 mandatory true; 1532 description "Describes the threat-feed 1533 condition destination."; 1534 } 1535 } 1536 } 1537 } 1538 } 1539 container action { 1540 description 1541 "This is the action container."; 1542 leaf primary-action { 1543 type identityref { 1544 base primary-action; 1545 } 1546 mandatory true; 1547 description 1548 "This represent the primary actions (e.g., PASS, DROP, 1549 ALERT, and MIRROR) to be applied a condition."; 1550 } 1551 leaf secondary-action { 1552 type identityref { 1553 base secondary-action; 1554 } 1555 description 1556 "This represents the secondary actions (e.g., log 1557 and syslog) to be applied if needed."; 1558 } 1559 } 1560 container ipsec-method { 1561 description 1562 "This container represents the IPsec IKE and IKEless cases."; 1563 leaf method { 1564 type identityref { 1565 base i2nsf-ipsec; 1566 } 1567 description 1568 "This references the IPsec method types, 1569 which includes IPsec IKE and IPsec IKEless cases."; 1570 } 1571 } 1572 leaf owner { 1573 type identityref { 1574 base owner; 1575 } 1576 mandatory true; 1577 description 1578 "This field defines the owner of this 1579 rule. Only the owner is authorized to 1580 modify the contents of the rule."; 1581 } 1582 } 1583 } 1584 container endpoint-group { 1585 description 1586 "A logical entity in their business 1587 environment, where a security policy 1588 is to be applied."; 1589 uses user-group; 1590 list device-group { 1591 key "name"; 1592 uses device-group; 1593 description 1594 "This represents the device group."; 1595 } 1596 list location-group{ 1597 key "name"; 1598 uses location-group; 1599 description 1600 "This represents the location group."; 1601 } 1602 } 1604 container threat-prevention { 1605 description 1606 "this describes the list of threat-prevention."; 1608 list threat-feed-list { 1609 key "feed-name"; 1610 description 1611 "This represents the threat feed list."; 1612 uses threat-feed-info; 1614 leaf-list threat-file-types { 1615 type identityref { 1616 base malware-file-type; 1617 } 1618 default executable-file; 1619 description 1620 "This contains a list of file types needed to 1621 be scanned for the virus."; 1622 } 1623 leaf-list signatures { 1624 type identityref { 1625 base signature-type; 1626 } 1627 default signature-suricata; 1628 description 1629 "This contains a list of signatures or hash 1630 of the threats."; 1631 } 1632 } 1633 list payload-content { 1634 key "name"; 1635 leaf name { 1636 type string; 1637 description 1638 "This represents the name of payload-content. 1639 It should give an idea of why specific payload 1640 content is marked as threat. For example, the name 1641 'backdoor' indicates the payload content is related 1642 to backdoor attack."; 1643 } 1644 description 1645 "This represents the payload-string group."; 1646 uses payload-string; 1647 } 1648 } 1649 } 1650 } 1651 1653 Figure 16: YANG for Consumer-Facing Interface 1655 9. XML Configuration Examples of High-Level Security Policy Rules 1657 This section shows XML configuration examples of high-level security 1658 policy rules that are delivered from the I2NSF User to the Security 1659 Controller over the Consumer-Facing Interface. The considered use 1660 cases are: Database registration, time-based firewall for web 1661 filtering, VoIP/VoLTE security service, and DDoS-attack mitigation. 1663 9.1. Database Registration: Information of Positions and Devices 1664 (Endpoint Group) 1666 If new endpoints are introduced to the network, it is necessary to 1667 first register their data to the database. For example, if new 1668 members are newly introduced in either of three different groups 1669 (i.e., user-group, device-group, and payload-group), each of them 1670 should be registered with information such as ip-addresses or 1671 protocols used by devices. Figure 17 shows an example XML 1672 representation of the registered information for the user-group and 1673 device-group. 1675 1676 1677 1678 employees 1679 1680 221.159.112.1 1681 221.159.112.90 1682 1683 1684 1685 webservers 1686 1687 221.159.112.91 1688 221.159.112.97 1689 1690 http 1691 https 1692 1693 1695 Figure 17: Registering User-group and Device-group Information 1697 9.2. Scenario 1: Block SNS Access during Business Hours 1699 The first example scenario is to "block SNS access during office 1700 hours" using a time-based firewall policy. In this scenario, all 1701 users registered as "employees" in the user-group list are unable to 1702 access Social Networking Services (SNS) during the office hours. The 1703 XML instance is described below: 1705 1706 1707 security_policy_for_blocking_sns 1708 1709 block_access_to_sns_during_office_hours 1710 1711 1712 09:00 1713 18:00 1714 1715 1716 1717 1718 1719 employees 1720 1721 1722 1723 1724 sns-websites 1725 1726 1727 1728 1729 drop 1730 1731 1732 ipsec-ike 1733 1734 1735 1737 Figure 18: An XML Example for Time-based Firewall 1739 Time-based-condition Firewall 1741 1. The policy name is "security_policy_for_blocking_sns". 1743 2. The rule name is "block_access_to_sns_during_office_hours". 1745 3. The Source-target is "employees". 1747 4. The destination target is "sns-websites". "sns-websites" is the 1748 key which represents the list containing the information, such as 1749 URL, about sns-websites. 1751 5. The action required is to "drop" any attempt to connect to 1752 websites related to Social networking. 1754 6. The IPsec method type used for nsf traffic steering is set to 1755 "ipsec-ike". 1757 9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a Company 1759 The second example scenario is to "block malicious VoIP/VoLTE packets 1760 coming to a company" using a VoIP policy. In this scenario, the 1761 calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that 1762 are classified as malicious are dropped. The IP addresses of the 1763 employees and malicious VOIP IDs should be blocked are stored in the 1764 database or datastore of the enterprise. Here and the rest of the 1765 cases assume that the security administrators or someone responsible 1766 for the existing and newly generated policies, are not aware of which 1767 and/or how many NSFs are needed to meet the security requirements. 1768 Figure 19 represents the XML document generated from YANG discussed 1769 in previous sections. Once a high-level seucurity policy is created 1770 by a security admin, it is delivered by the Consumer-Facing 1771 Interface, through RESTCONF server, to the security controller. The 1772 XML instance is described below: 1774 1775 1776 security_policy_for_blocking_malicious_voip_packets 1777 1778 Block_malicious_voip_and_volte_packets 1779 1780 1781 1782 malicious-id 1783 1784 1785 1786 1787 employees 1788 1789 1790 1791 1792 drop 1793 1794 1795 ipsec-ikeless 1796 1797 1798 1800 Figure 19: An XML Example for VoIP Security Service 1802 Custom-condition Firewall 1804 1. The policy name is 1805 "security_policy_for_blocking_malicious_voip_packets". 1807 2. The rule name is "Block_malicious_voip_and_volte_packets". 1809 3. The Source-target is "malicious-id". This can be a single ID or 1810 a list of IDs, depending on how the ID are stored in the 1811 database. The "malicious-id" is the key so that the security 1812 admin can read every stored malicious VOIP IDs that are named as 1813 "malicious-id". 1815 4. The destination target is "employees". "employees" is the key 1816 which represents the list containing information about employees, 1817 such as IP addresses. 1819 5. The action required is "drop" when any incoming packets are from 1820 "malicious-id". 1822 6. The IPsec method used for nsf traffic steering is set to "ipsec- 1823 ikeless". 1825 9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web 1826 Server 1828 The third example scenario is to "Mitigate HTTP and HTTPS flood 1829 attacks on a company web server" using a DDoS-attack mitigation 1830 policy. Here, the time information is not set because the service 1831 provided by the network should be maintained at all times. If the 1832 packets sent by any sources are more than the set threshold, then the 1833 admin can set the percentage of the packets to be dropped to safely 1834 maintain the service. In this scenario, the source is set as "any" 1835 to block any sources which send abnormal amount of packets. The 1836 destination is set as "web_server01". Once the rule is set and 1837 delivered and enforced to the nsfs by the securiy controller, the 1838 NSFs will monitor the incoming packet amounts and the destination to 1839 act according to the rule set. The XML instance is described below: 1841 1842 1843 security_policy_for_ddos_attacks 1844 1845 100_packets_per_second 1846 1847 1848 1849 webservers 1850 1851 1852 100 1853 1854 1855 1856 1857 drop 1858 1859 1860 ipsec-ikeless 1861 1862 1863 1865 Figure 20: An XML Example for DDoS-attack Mitigation 1867 DDoS-condition Firewall 1869 1. The policy name is "security_policy_for_ddos_attacks". 1871 2. The rule name is "100_packets_per_second". 1873 3. The destination target is "webservers". "webservers" is the key 1874 which represents the list containing information, such as IP 1875 addresses and ports, about web-servers. 1877 4. The rate limit exists to limit the incoming amount of packets per 1878 second. In this case the rate limit is "100" packets per second. 1879 This amount depends on the packet receiving capacity of the 1880 server devices. 1882 5. The Source-target is all sources which send abnormal amount of 1883 packets. 1885 6. The action required is to "drop" packet reception is more than 1886 100 packets per second. 1888 7. The IPsec method used for nsf traffic steering is set to "ipsec- 1889 ike". 1891 10. Security Considerations 1893 The data model for the I2NSF Consumer-Facing Interface is based on 1894 the I2NSF framework [RFC8329], so the same security considerations 1895 with the I2NSF framework should be included in this document. The 1896 data model needs a secure communication channel to protect the 1897 Consumer-Facing Interface between the I2NSF User and Security 1898 Controller. 1900 11. IANA Considerations 1902 This document requests IANA to register the following URI in the 1903 "IETF XML Registry" [RFC3688]: 1905 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 1906 Registrant Contact: The I2NSF. 1907 XML: N/A; the requested URI is an XML namespace. 1909 This document requests IANA to register the following YANG module in 1910 the "YANG Module Names" registry [RFC7950]. 1912 name: ietf-i2nsf-cfi-policy 1913 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 1914 prefix: cfi-policy 1915 reference: RFC 7950 1917 12. Acknowledgments 1919 This work was supported by Institute of Information & Communications 1920 Technology Planning & Evaluation (IITP) grant funded by the Korea 1921 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 1922 Security Intelligence Technology Development for the Customized 1923 Security Service Provisioning). 1925 13. Contributors 1927 This document is made by the group effort of I2NSF working group. 1928 Many people actively contributed to this document, such as Mahdi F. 1929 Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their 1930 contributions. 1932 The following are co-authors of this document: 1934 Hyoungshick Kim 1935 Department of Computer Science and Engineering 1936 Sungkyunkwan University 1937 2066 Seo-ro Jangan-gu 1938 Suwon, Gyeonggi-do 16419 1939 Republic of Korea 1941 EMail: hyoung@skku.edu 1943 Eunsoo Kim 1944 Department of Electronic, Electrical and Computer Engineering 1945 Sungkyunkwan University 1946 2066 Seo-ro Jangan-gu 1947 Suwon, Gyeonggi-do 16419 1948 Republic of Korea 1950 EMail: eskim86@skku.edu 1952 Seungjin Lee 1953 Department of Electronic, Electrical and Computer Engineering 1954 Sungkyunkwan University 1955 2066 Seo-ro Jangan-gu 1956 Suwon, Gyeonggi-do 16419 1957 Republic of Korea 1959 EMail: jine33@skku.edu 1961 Jinyong Tim Kim 1962 Department of Electronic, Electrical and Computer Engineering 1963 Sungkyunkwan University 1964 2066 Seo-ro Jangan-gu 1965 Suwon, Gyeonggi-do 16419 1966 Republic of Korea 1968 EMail: timkim@skku.edu 1970 Anil Lohiya 1971 Juniper Networks 1972 1133 Innovation Way 1973 Sunnyvale, CA 94089 1974 US 1976 EMail: alohiya@juniper.net 1977 Dave Qi 1978 Bloomberg 1979 731 Lexington Avenue 1980 New York, NY 10022 1981 US 1983 EMail: DQI@bloomberg.net 1985 Nabil Bitar 1986 Nokia 1987 755 Ravendale Drive 1988 Mountain View, CA 94043 1989 US 1991 EMail: nabil.bitar@nokia.com 1993 Senad Palislamovic 1994 Nokia 1995 755 Ravendale Drive 1996 Mountain View, CA 94043 1997 US 1999 EMail: senad.palislamovic@nokia.com 2001 Liang Xia 2002 Huawei 2003 101 Software Avenue 2004 Nanjing, Jiangsu 210012 2005 China 2007 EMail: Frank.Xialiang@huawei.com 2009 14. References 2011 14.1. Normative References 2013 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2014 Information Models and Data Models", RFC 3444, 2015 DOI 10.17487/RFC3444, January 2003, 2016 . 2018 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2019 DOI 10.17487/RFC3688, January 2004, 2020 . 2022 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2023 the Network Configuration Protocol (NETCONF)", RFC 6020, 2024 DOI 10.17487/RFC6020, October 2010, 2025 . 2027 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2028 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2029 . 2031 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2032 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2033 . 2035 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2036 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2037 May 2017, . 2039 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2040 and J. Jeong, "Interface to Network Security Functions 2041 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2042 DOI 10.17487/RFC8192, July 2017, 2043 . 2045 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2046 Kumar, "Framework for Interface to Network Security 2047 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2048 . 2050 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2051 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2052 . 2054 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2055 Access Control Model", STD 91, RFC 8341, 2056 DOI 10.17487/RFC8341, March 2018, 2057 . 2059 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2060 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2061 DOI 10.17487/RFC8407, October 2018, 2062 . 2064 14.2. Informative References 2066 [client-facing-inf-req] 2067 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 2068 S., and L. Xia, "Requirements for Client-Facing Interface 2069 to Security Controller", draft-ietf-i2nsf-client-facing- 2070 interface-req-05 (work in progress), May 2018. 2072 [i2nsf-capability-im] 2073 Xia, L., Strassner, J., Basile, C., and D. Lopez, 2074 "Information Model of NSFs Capabilities", draft-ietf- 2075 i2nsf-capability-05 (work in progress), April 2019. 2077 [i2nsf-ipsec] 2078 Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 2079 Garcia, "Software-Defined Networking (SDN)-based IPsec 2080 Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow- 2081 protection-07 (work in progress), August 2019. 2083 [i2nsf-terminology] 2084 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 2085 Birkholz, "Interface to Network Security Functions (I2NSF) 2086 Terminology", draft-ietf-i2nsf-terminology-08 (work in 2087 progress), July 2019. 2089 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- 2090 dm-06 2092 The following changes are made from draft-ietf-i2nsf-consumer-facing- 2093 interface-dm-06: 2095 o This version has reflected the comments from Jan Lindblad. 2097 o In Section 1, Figure 1 is modified such that "Multi-Tenancy" is 2098 deleted because "Multi-Tenancy" can be described by "Endpoint 2099 Groups" in a policy rule. 2101 o In Section 4, Figure 2 is modified such that the YANG data model 2102 of a policy having at least one rule has a hierarchical structure 2103 rather than a flat structure by deleing the "Multi-Tenancy" field. 2105 o The section named "Information Model for Multi-Tenancy" is 2106 deleted. The multi-tenancy can be specified by "Endpoint Groups" 2107 along with "Network Configuration Access Control Model (NACM)" 2108 mechanisms. 2110 o In Section 5.1, "NACM" is applied in "user-group" and for its 2111 access control. 2113 o In Section 5.2, Figure 10 is modified because the "protocol" field 2114 was missed in the previous version. 2116 o Section 7 is added as "Network Configuration Access Control Model 2117 (NACM)" in order to provide the Consumer-Facing Interface with the 2118 existing access control mechanisms. Also, the reference of 2119 [RFC8341] is added for NACM. 2121 o The section named "Role-based Access Control (RBAC)" is deleted 2122 since this access control can be replaced by "NACM". 2124 o In Section 8, the YANG data module is modified according to the 2125 above changes. 2127 Authors' Addresses 2128 Jaehoon Paul Jeong 2129 Department of Computer Science and Engineering 2130 Sungkyunkwan University 2131 2066 Seobu-Ro, Jangan-Gu 2132 Suwon, Gyeonggi-Do 16419 2133 Republic of Korea 2135 Phone: +82 31 299 4957 2136 Fax: +82 31 290 7996 2137 EMail: pauljeong@skku.edu 2138 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2140 Chaehong Chung 2141 Department of Electronic, Electrical and Computer Engineering 2142 Sungkyunkwan University 2143 2066 Seobu-Ro, Jangan-Gu 2144 Suwon, Gyeonggi-Do 16419 2145 Republic of Korea 2147 Phone: +82 31 299 4957 2148 EMail: darkhong@skku.edu 2150 Tae-Jin Ahn 2151 Korea Telecom 2152 70 Yuseong-Ro, Yuseong-Gu 2153 Daejeon 305-811 2154 Republic of Korea 2156 Phone: +82 42 870 8409 2157 EMail: taejin.ahn@kt.com 2159 Rakesh Kumar 2160 Juniper Networks 2161 1133 Innovation Way 2162 Sunnyvale, CA 94089 2163 USA 2165 EMail: rkkumar@juniper.net 2166 Susan Hares 2167 Huawei 2168 7453 Hickory Hill 2169 Saline, MI 48176 2170 USA 2172 Phone: +1-734-604-0332 2173 EMail: shares@ndzh.com