idnits 2.17.1 draft-ietf-i2nsf-consumer-facing-interface-dm-09.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 4 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 272 has weird spacing: '...le-name strin...' == Line 471 has weird spacing: '...address ine...' == Line 510 has weird spacing: '...address ine...' == Line 514 has weird spacing: '...address ine...' == Line 633 has weird spacing: '...ription strin...' -- The document date (July 13, 2020) is 1380 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 2313, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 2330, but no explicit reference was found in the text == Unused Reference: 'STIX' is defined on line 2374, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3444 ** Downref: Normative reference to an Informational RFC: RFC 8192 ** Downref: Normative reference to an Informational RFC: RFC 8329 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group J. Jeong 3 Internet-Draft C. Chung 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: January 14, 2021 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 July 13, 2020 13 I2NSF Consumer-Facing Interface YANG Data Model 14 draft-ietf-i2nsf-consumer-facing-interface-dm-09 16 Abstract 18 This document describes an information model and a YANG data model 19 for the Consumer-Facing Interface between an Interface to Network 20 Security Functions (I2NSF) User and Security Controller in an I2NSF 21 system in a Network Functions Virtualization (NFV) environment. The 22 information model defines various types of managed objects and the 23 relationship among them needed to build the interface. The 24 information model is organized based on the "Event-Condition-Action" 25 (ECA) policy model defined by a capability information model for 26 I2NSF [i2nsf-capability-im], and the data model is defined for 27 enabling different users of a given I2NSF system to define, manage, 28 and monitor security policies for specific flows within an 29 administrative domain. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 14, 2021. 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 . . . . . . . . 9 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) for I2NSF 80 Consumer-Facing Interface . . . . . . . . . . . . . . . . . . 15 81 8. YANG Data Model of Consumer-Facing Interface . . . . . . . . 17 82 9. XML Configuration Examples of High-Level Security Policy 83 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 84 9.1. Database Registration: Information of Positions and 85 Devices (Endpoint Group) . . . . . . . . . . . . . . . . 40 86 9.2. Scenario 1: Block SNS Access during Business Hours . . . 41 87 9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to 88 a Company . . . . . . . . . . . . . . . . . . . . . . . . 43 89 9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a 90 Company Web Server . . . . . . . . . . . . . . . . . . . 45 91 10. XML Configuration Example of a User Group's Access Control 92 for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 46 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 94 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 95 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 96 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 48 97 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 98 15.1. Normative References . . . . . . . . . . . . . . . . . . 51 99 15.2. Informative References . . . . . . . . . . . . . . . . . 52 100 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing- 101 interface-dm-08 . . . . . . . . . . . . . . . . . . 53 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 104 1. Introduction 106 In a framework of Interface to Network Security Functions (I2NSF), 107 each vendor can register their NSFs using a Developer's Management 108 System (DMS). Assuming that vendors also provide the front-end web 109 applications registered with an I2NSF User, the Consumer-Facing 110 Interface is required because the web applications developed by each 111 vendor need to have a standard interface specifying the data types 112 used when the I2NSF User and Security Controller communicate using 113 this interface. Therefore, this document specifies the required 114 information, their data types, and encoding schemes so that high- 115 level security policies (or configuration information for security 116 policies) can be transferred to the Security Controller through the 117 Consumer-Facing Interface. These policies can easily be translated 118 by the Security Controller into low-level security policies. The 119 Security Controller delivers the translated policies to Network 120 Security Functions (NSFs) according to their respective security 121 capabilities for the required securiy enforcement. 123 The Consumer-Facing Interface would be built using a set of objects, 124 with each object capturing a unique set of information from Security 125 Administrator (i.e., I2NSF User [RFC8329]) needed to express a 126 Security Policy. An object may have relationship with various other 127 objects to express a complete set of requirements. An information 128 model captures the managed objects and relationship among these 129 objects. The information model proposed in this document is 130 structured in accordance with the "Event-Condition-Action" (ECA) 131 policy model. 133 An NSF Capability model is proposed in [i2nsf-capability-im] as the 134 basic model for both the NSF-Facing interface and Consumer-Facing 135 Interface security policy model of this document. 137 [RFC3444] explains differences between an information and data model. 138 This document uses the guidelines in [RFC3444] to define both the 139 information and data model for Consumer-Facing Interface. Figure 1 140 shows a high-level abstraction of Consumer-Facing Interface. A data 141 model, which represents an implementation of the information model in 142 a specific data representation language, is also defined in this 143 document. 145 +-----------------+ +-----------------+ 146 | Consumer-Facing | | Consumer-Facing | 147 | Interface +--->+ Interface | 148 |Information Model| | Data Model | 149 +--------+--------+ +-----------------+ 150 ^ 151 | 152 +-------------+------------+ 153 | | | 154 +-----+----+ +-----+----+ +----+----+ 155 | Policy | | Endpoint | | Threat | 156 | | | groups | | feed | 157 +-----+----+ +----------+ +---------+ 158 ^ 159 | 160 +------+------+ 161 | Rule | 162 +------+------+ 163 ^ 164 | 165 +----------------+----------------+ 166 | | | 167 +------+------+ +------+------+ +------+------+ 168 | Event | | Condition | | Action | 169 +-------------+ +-------------+ +-------------+ 171 Figure 1: Diagram for High-level Abstraction of Consumer-Facing 172 Interface 174 Data models are defined at a lower level of abstraction and provide 175 many details. They provide details about the implementation of a 176 protocol's specification, e.g., rules that explain how to map managed 177 objects onto lower-level protocol constructs. Since conceptual 178 models can be implemented in different ways, multiple data models can 179 be derived from a single information model. 181 The efficient and flexible provisioning of network functions by a 182 Network Functions Virtualization (NFV) system leads to a rapid 183 advance in the network industry. As practical applications, Network 184 Security Functions (NSFs), such as firewall, Intrusion Detection 185 System (IDS)/Intrusion Prevention System (IPS), and attack 186 mitigation, can also be provided as Virtual Network Functions (VNF) 187 in the NFV system. By the efficient virtualization technology, these 188 VNFs might be automatically provisioned and dynamically migrated 189 based on real-time security requirements. This document presents a 190 YANG data model to implement security functions based on NFV. 192 2. Requirements Language 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in RFC 2119 [RFC3444] 197 RFC8174 [RFC8174]. 199 3. Terminology 201 This document uses the terminology described in [i2nsf-terminology] 202 [client-facing-inf-req]. 204 This document follows the guidelines of [RFC8407], uses the common 205 YANG types defined in [RFC6991], and adopts the Network Management 206 Datastore Architecture (NMDA). The meaning of the symbols in tree 207 diagrams is defined in [RFC8340]. 209 4. Information Model for Policy 211 A Policy object represents a mechanism to express a Security Policy 212 by Security Administrator (i.e., I2NSF User) using Consumer-Facing 213 Interface toward Security Controller; the policy would be enforced on 214 an NSF. Figure 2 shows the YANG tree of the Policy object. The 215 Policy object SHALL have the following information: 217 Name: This field identifies the name of this object. 219 Rule: This field contains a list of rules. These rules are 220 defined for 1) communication between two Endpoint Groups, 221 2) for preventing communication with externally or 222 internally identified threats, and 3) for implementing 223 business requirement such as controlling access to internal 224 or external resources for meeting regulatory compliance or 225 business objectives. An organization may restrict certain 226 communication between a set of user and applications for 227 example. The threats may be from threat feeds obtained 228 from external sources or dynamically identified by using 229 specialty devices in the network. Rule conflict analysis 230 should be triggered by the monitoring service to perform an 231 exhaustive detection of anomalies among the configuration 232 rules installed into the security functions. 234 +--rw i2nsf-cfi-policy* [policy-name] 235 +--rw policy-name string 236 +--rw rules 237 +--rw endpoint-groups 238 +--rw threat-prevention 240 Figure 2: Policy YANG Data Tree 242 A policy is a container of Rule(s). In order to express a Rule, a 243 Rule must have complete information such as where and when a policy 244 needs to be applied. This is done by defining a set of managed 245 objects and relationship among them. A Policy Rule may be related 246 segmentation, threat mitigation or telemetry data collection from an 247 NSF in the network, which will be specified as the sub-model of the 248 policy model in the subsequent sections. Figure 3 shows the YANG 249 data tree of the Rule object. The rule object SHALL have the 250 following information: 252 Name: This field identifies the name of this object. 254 Event: This field includes the information to determine whether 255 the Rule Condition can be evaluated or not. See details in 256 Section 4.1. 258 Condition: This field contains all the checking conditions to 259 apply to the objective traffic. See details in 260 Section 4.2. 262 Action: This field identifies the action taken when a rule is 263 matched. There is always an implicit action to drop 264 traffic if no rule is matched for a traffic type. See 265 details in Section 4.3. 267 IPsec-Method: This field contains the information about IPsec 268 method type. There are two types such as IPsec-IKE and 269 IPsec-IKEless [i2nsf-ipsec]. 271 +--rw rules* [rule-name] 272 +--rw rule-name string 273 +--rw event 274 +--rw (condition)? 275 +--rw action 276 +--rw ipsec-method 278 Figure 3: Rule YANG Data Tree 280 Note that in the case of policy conflicts, the resolution of the 281 conflicted policies conforms to the guidelines of "Information Model 282 of NSFs Capabilities" [i2nsf-capability-im]. 284 4.1. Event Sub-model 286 The Event Object contains information related to scheduling a Rule. 287 The Rule could be activated based on a set time or security event. 288 Figure 4 shows the YANG tree of the Event object. Event object SHALL 289 have following information: 291 Security-event: This field identifies for which security event 292 the policy is enforced. The examples of security events 293 are: "DDOS", "spyware", "trojan", and "ransomware". 295 Time-information: This represents the security rule is enforced 296 based on the period information with the end time for the 297 event. 299 Period: This represents the period of time the rule event is 300 active. 302 End-time: This represents the end time of the event. If the rule 303 time has pass the end-time, the rule will stop repeating" 305 Frequency: This represents how frequent the rule should be 306 enforced. There are four options: "only-once", "daily", 307 "weekly" and "monthly". 309 +--rw event 310 +--rw security-event identityref 311 +--rw time-information 312 | +--rw start-date-time? yang:date-and-time 313 | +--rw end-date-time? yang:date-and-time 314 | +--rw period 315 | | +--rw start-time? time 316 | | +--rw stop-time? time 317 | | +--rw day* identityref 318 | | +--rw date* int32 319 | | +--rw month* string 320 +--rw frequency? enumeration 322 Figure 4: Event Sub-model YANG Data Tree 324 4.2. Condition Sub-model 326 This object represents Conditions that Security Administrator wants 327 to apply the checking on the traffic in order to determine whether 328 the set of actions in the Rule can be executed or not. The Condition 329 Sub-model consists of three different types of containers each 330 representing different cases, such as general firewall and DDoS- 331 mitigation cases, and a case when the condition is based on the 332 payload strings of packets. Each containers have source and 333 destination-target to represent the source and destination for each 334 case. Figure 5 shows the YANG tree of the Condition object. The 335 Condition Sub-model SHALL have following information: 337 Case (Firewall-condition): This field represents the general 338 firewall case, where a security admin can set up firewall 339 conditions using the information present in this field. 340 The source and destination is represented as firewall- 341 source and firewall-destination, each referring to the IP- 342 address-based groups defined in the endpoint-groups. 344 Case (DDoS-condition): This field represents the condition for 345 DDoS mitigation, where a security admin can set up DDoS 346 mitigation conditions using the information present in this 347 field. The source and destination is represented as ddos- 348 source and ddos-destination, each referring to the device- 349 groups defined and registered in the endpoint-groups. 351 Case (Custom-condition): This field contains the payload string 352 information. This information is useful when security rule 353 condition is based on the string contents of incoming or 354 outgoing packets. The source and destination is 355 represented as custom-source and custom-destination, each 356 referring to the payload-groups defined and registered in 357 the endpoint-groups. 359 Case (Threat-feed-condition): This field contains the information 360 obtained from threat-feeds (e.g., Palo-Alto, or RSA- 361 netwitness). This information is useful when security rule 362 condition is based on the existing threat reports gathered 363 by other sources. The source and destination is 364 represented as threat-feed-source and threat-feed- 365 destination. For clarity, threat-feed-source/destination 366 represent the source/destination of a target security 367 threat, not the information source/destination of a threat- 368 feed. 370 +--rw condition 371 +--:firewall-condition 372 | +--rw source -> /../../user-group/name 373 | +--rw destination* -> /../../user-group/name 374 +--:ddos-condition 375 | +--rw source* -> /../../device-group/name 376 | +--rw destination* -> /../../device-group/name 377 | +--rw rate-limit 378 | +--rw packet-threshold-per-second? uint32 379 +--:location-condition 380 | +--rw source* -> /../../location-group/name 381 | +--rw destination -> /../../location-group/name 382 +--:custom-condition 383 | +--rw source* -> /../../payload-content/name 384 | +--rw destination -> /../../payload-content/name 385 +--:threat-feed-condition 386 +--rw source* -> /../../threat-feed-list/name 387 +--rw destination -> /../../threat-feed-list/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 Groups object. This section lists these objects and relationship 420 among them. 422 +-------------------+ 423 | Endpoint Groups | 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-groups 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 string 464 +--rw (match-type) 465 +--:(exact-match-ipv4) 466 | +--rw ipv4? inet:ipv4-address 467 +--:(exact-match-ipv6) 468 | +--rw ipv6? inet:ipv6-address 469 +--:(range-match-ipv4) 470 | +--rw range-ipv4-address 471 | +--rw start-ipv4-address inet:ipv4-address 472 | +--rw end-ipv4-address inet:ipv4-address 473 +--:(range-match-ipv6) 474 +--rw range-ipv6-address* 475 +--rw start-ipv6-address inet:ipv6-address 476 +--rw end-ipv6-address inet:ipv6-address 478 Figure 9: User Group YANG Data Tree 480 5.2. Device Group 482 This object represents a Device-Group. Figure 10 shows the YANG tree 483 of the Device-group object. The Device-Group object SHALL have the 484 following information: 486 Name: This field identifies the name of this object. 488 IP-address: This represents the IPv4 address of a device in the 489 device group. 491 range-ipv4-address: This represents the IPv4 address of a device 492 in the device gorup. 494 range-ipv6-address: This represents the IPv6 address of a device 495 in the device gorup. 497 Protocol: This represents the communication protocols used by the 498 devices. The protocols are "SSH", "FTP", "SMTP", "HTTP", 499 "HTTPS", and etc. 501 +--rw device-group* [name] 502 +--rw name string 503 +--rw (match-type) 504 | +--:(exact-match-ipv4) 505 | | +--rw ipv4? inet:ipv4-address 506 | +--:(exact-match-ipv6) 507 | | +--rw ipv6? inet:ipv6-address 508 | +--:(range-match-ipv4) 509 | | +--rw range-ipv4-address* 510 | | | +--rw start-ipv4-address inet:ipv4-address 511 | | | +--rw end-ipv4-address inet:ipv4-address 512 | +--:(range-match-ipv6) 513 | | +--rw range-ipv6-address* 514 | | | +--rw start-ipv6-address inet:ipv6-address 515 | | | +--rw end-ipv6-address inet:ipv6-address 516 +--rw protocol identityref 518 Figure 10: Device Group YANG Data Tree 520 5.3. Location Group 522 This object represents a location group based on either tag or other 523 information. Figure 11 shows the YANG tree of the Location-Group 524 object. The Location-Group object SHALL have the following 525 information: 527 Name: This field identifies the name of this object. 529 geo-ip-ipv4: This field represents the IPv4 Geo-ip of a location. 531 geo-ip-ipv6: This field represents the IPv6 Geo-ip of a location. 533 continent: This field represents the continent where the location 534 group member is at. 536 +--rw location-group* [name] 537 +--rw name string 538 +--rw geo-ip-ipv4 inet:ipv4-address 539 +--rw geo-ip-ipv6 inet:ipv6-address 540 +--rw continent? identityref 542 Figure 11: Location Group YANG Data Tree 544 6. Information Model for Threat Prevention 546 The threat prevention plays an important part in the overall security 547 posture by reducing the attack surfaces. This information could come 548 from various threat feeds (i.e., sources for obtaining the threat 549 information). There are multiple managed objects that constitute 550 this category. This section lists these objects and relationship 551 among them. Figure 13 shows the YANG tree of a Threat-Prevention 552 object. 554 +-------------------+ 555 | Threat Prevention | 556 +---------+---------+ 557 ^ 558 | 559 +---------+---------+ 560 1..n | 1..n | 561 +------+------+ +--------+--------+ 562 | Threat-feed | | payload-content | 563 +-------------+ +-----------------+ 565 Figure 12: Threat Prevention Diagram 567 +--rw threat-prevention 568 +--rw threat-feed-list* [name] 569 ... 570 +--rw payload-content* [name] 571 ... 573 Figure 13: Threat Prevention YANG Data Tree 575 6.1. Threat Feed 577 This object represents a threat feed which provides signatures of 578 malicious activities. Figure 14 shows the YANG tree of a Threat- 579 feed-list. The Threat-Feed object SHALL have the following 580 information: 582 name: This field identifies the name of this object. 584 Server-ipv4: This represents the IPv4 server address of the feed 585 provider, it may be external or local servers. 587 Server-ipv6: This represents the IPv6 server address of the feed 588 provider, it may be external or local servers. 590 description: This is the description of the threat feed. The 591 descriptions should have clear indication of the security 592 attack such as attack type (e.g., APT) and file types used 593 (e.g., executable malware). 595 Threat-file-types: This field identifies the information about 596 the file types identified and reported by the threat-feed. 598 signatures: This field contains the signatures of malicious 599 programs or activities provided by the threat-feed. The 600 examples of signature types are "YARA", "SURICATA", and 601 "SNORT". 603 +--rw threat-prevention 604 +--rw threat-feed-list* [name] 605 +--rw name identityref 606 +--rw server-ipv4? inet:ipv4-address 607 +--rw server-ipv6? inet:ipv6-address 608 +--rw description? string 609 +--rw threat-file-types* identityref 610 +--rw signatures* identityref 612 Figure 14: Threat Feed YANG Data Tree 614 6.2. Payload Content 616 This object represents a custom list created for the purpose of 617 defining exception to threat feeds. Figure 15 shows the YANG tree of 618 a Payload-content list. The Payload-Content object SHALL have the 619 following information: 621 Name: This field identifies the name of this object. For 622 example, the name "backdoor" indicates the payload content 623 is related to backdoor attack. 625 description: This represents the description of how the payload 626 content is related to a security attack. 628 Content: This contains the payload contents, which are involed in 629 a security attack, as strings. 631 +--rw payload-content* [name] 632 +--rw name string 633 +--rw description string 634 +--rw content* string 636 Figure 15: Payload Content in YANG Data Tree 638 7. Network Configuration Access Control Model (NACM) for I2NSF 639 Consumer-Facing Interface 641 Network Configuration Access Control Model (NACM) provides a user 642 group with an access control with the following features [RFC8341]: 644 o Independent control of action, data, and notification access is 645 provided. 647 o A simple and familiar set of datastore permissions is used. 649 o Support for YANG security tagging allows default security modes to 650 automatically exclude sensitive data. 652 o Separate default access modes for read, write, and execute 653 permissions are provided. 655 o Access control rules are applied to configurable groups of users. 657 The data model of the I2NSF Consumer-Facing Interface utilizes the 658 NACM's mechanisms to manage the access control on the I2NSF Consumer- 659 Facing Interface. The NACM with the above features can be used to 660 set up the access control rules of a user group in the I2NSF 661 Consumer-Facing Interface. Figure 16 shows part of the NACM module 662 to enable the access control of a user group for the I2NSF Consumer- 663 Facing Interface. To use the NACM, a user needs to configure a 664 NETCONF or RESTCONF server to enable the NACM module. Then, the user 665 can simply use an account of root or admin user for the access 666 control for the module of the I2NSF Consumer-Facing Interface (i.e., 667 ietf-i2nsf-cfi-policy). An XML example to configure the access 668 control a user group for the I2NSF Consumer-Facing Interface can be 669 seen in Section 10. 671 list rule { 672 key "name"; 673 ordered-by user; 674 leaf name { 675 type string { 676 length "1..max"; 677 } 678 description 679 "Arbitrary name assigned to the rule."; 680 } 682 leaf module-name { 683 type union { 684 type matchall-string-type; 685 type string; 686 } 687 default "*"; 688 description 689 "Name of the module associated with this rule." 690 } 692 leaf access-operations { 693 type union { 694 type matchall-string-type; 695 type access-operations-type; 696 } 697 default "*"; 698 description 699 "Access operations associated with this rule." 700 } 702 leaf action { 703 type action-type; 704 mandatory true; 705 description 706 "The access control action associated with the 707 rule. If a rule is determined to match a 708 particular request, then this object is used 709 to determine whether to permit or deny the 710 request."; 711 } 713 Figure 16: A Part of the NACM YANG Data Model 715 8. YANG Data Model of Consumer-Facing Interface 717 The main objective of this data model is to provide both an 718 information model and the corresponding YANG data model of I2NSF 719 Consumer-Facing Interface. This interface can be used to deliver 720 control and management messages between an I2NSF User and Security 721 Controller for the I2NSF User's high-level security policies. 723 The semantics of the data model must be aligned with the information 724 model of the Consumer-Facing Interface. The transformation of the 725 information model was performed so that this YANG data model can 726 facilitate the efficient delivery of the control or management 727 messages. 729 This data model is designed to support the I2NSF framework that can 730 be extended according to the security needs. In other words, the 731 model design is independent of the content and meaning of specific 732 policies as well as the implementation approach. This document 733 suggests a VoIP/VoLTE security service as a use case for policy rule 734 generation. 736 This section describes a YANG data model for Consumer-Facing 737 Interface, based on the information model of Consumer-Facing 738 Interface to Security Controller. 740 file "ietf-i2nsf-cfi-policy@2020-07-13.yang" 741 module ietf-i2nsf-cfi-policy { 742 yang-version 1.1; 743 namespace 744 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; 745 prefix 746 i2nsf-cfi; 748 import ietf-inet-types{ 749 prefix inet; 750 } 752 import ietf-yang-types{ 753 prefix yang; 754 } 756 import ietf-netconf-acm { 757 prefix nacm; 758 } 760 organization 761 "IETF I2NSF (Interface to Network Security Functions) 762 Working Group"; 764 contact 765 "WG Web: 766 WG List: 768 WG Chair: Linda Dunbar 769 771 WG Chair: Yoav Nir 772 774 Editor: Jaehoon Paul Jeong 775 777 Editor: Chaehong Chung 778 "; 780 description 781 "This module is a YANG module for Consumer-Facing Interface. 782 Copyright (c) 2020 IETF Trust and the persons 783 identified as authors of the code. All rights reserved. 784 Redistribution and use in source and binary forms, with or 785 without modification, is permitted pursuant to, and subject 786 to the license terms contained in, the Simplified BSD License 787 set forth in Section 4.c of the IETF Trust's Legal Provisions 788 Relating to IETF Documents 789 http://trustee.ietf.org/license-info). 790 This version of this YANG module is part of RFC XXXX; see 791 the RFC itself for full legal notices."; 793 revision "2020-07-13"{ 794 description "The latest revision"; 795 reference 796 "draft-ietf-consumer-facing-interface-dm-08"; 797 } 799 identity malware-file-type { 800 description 801 "Base identity for malware file types."; 802 } 804 identity executable-file { 805 base malware-file-type; 806 description 807 "Identity for executable file types."; 808 } 810 identity doc-file { 811 base malware-file-type; 812 description 813 "Identity for Microsoft document file types."; 814 } 816 identity html-app-file { 817 base malware-file-type; 818 description 819 "Identity for html application file types."; 820 } 822 identity javascript-file { 823 base malware-file-type; 824 description 825 "Identity for Javascript file types."; 826 } 828 identity pdf-file { 829 base malware-file-type; 830 description 831 "Identity for pdf file types."; 832 } 834 identity dll-file { 835 base malware-file-type; 836 description 837 "Identity for dll file types."; 838 } 840 identity msi-file { 841 base malware-file-type; 842 description 843 "Identity for Microsoft installer file types."; 844 } 846 identity security-event-type { 847 description 848 "Base identity for security event types."; 849 } 851 identity ddos { 852 base security-event-type; 853 description 854 "Identity for DDoS event types."; 855 } 857 identity spyware { 858 base security-event-type; 859 description 860 "Identity for spyware event types."; 861 } 863 identity trojan { 864 base security-event-type; 865 description 866 "Identity for Trojan infection event types."; 867 } 869 identity ransomware { 870 base security-event-type; 871 description 872 "Identity for ransomware infection event types."; 873 } 875 identity i2nsf-ipsec { 876 description 877 "Base identity for IPsec method types."; 878 reference 879 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; 880 } 882 identity ipsec-ike { 883 base i2nsf-ipsec; 884 description 885 "Identity for ipsec-ike."; 886 reference 887 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; 888 } 890 identity ipsec-ikeless { 891 base i2nsf-ipsec; 892 description 893 "Identity for ipsec-ikeless."; 894 reference 895 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; 896 } 898 identity continent { 899 description 900 "Base Identity for continent types."; 901 } 903 identity africa { 904 base continent; 905 description 906 "Identity for africa."; 907 } 908 identity asia { 909 base continent; 910 description 911 "Identity for asia."; 912 } 914 identity europe { 915 base continent; 916 description 917 "Identity for europe."; 918 } 920 identity north-america { 921 base continent; 922 description 923 "Identity for north-america."; 924 } 926 identity south-america { 927 base continent; 928 description 929 "Identity for south-america."; 930 } 932 identity oceania { 933 base continent; 934 description 935 "Identity for Oceania"; 936 } 938 identity protocol-type { 939 description 940 "This identity represents the protocol types."; 941 } 943 identity ftp { 944 base protocol-type; 945 description 946 "The identity for ftp protocol."; 947 reference 948 "RFC 959: File Transfer Protocol (FTP)"; 949 } 951 identity ssh { 952 base protocol-type; 953 description 954 "The identity for ssh protocol."; 955 reference 956 "RFC 4250: The Secure Shell (SSH) Protocol"; 957 } 959 identity telnet { 960 base protocol-type; 961 description 962 "The identity for telnet."; 963 reference 964 "RFC 854: Telnet Protocol"; 965 } 967 identity smtp { 968 base protocol-type; 969 description 970 "The identity for smtp."; 971 reference 972 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 973 } 975 identity sftp { 976 base protocol-type; 977 description 978 "The identity for sftp."; 979 reference 980 "RFC 913: Simple File Transfer Protocol (SFTP)"; 981 } 983 identity http { 984 base protocol-type; 985 description 986 "The identity for http."; 987 reference 988 "RFC 2616: Hypertext Transfer Protocol (HTTP)"; 989 } 991 identity https { 992 base protocol-type; 993 description 994 "The identity for https."; 995 reference 996 "RFC 2818: HTTP over TLS (HTTPS)"; 997 } 999 identity pop3 { 1000 base protocol-type; 1001 description 1002 "The identity for pop3."; 1003 reference 1004 "RFC 1081: Post Office Protocol -Version 3 (POP3)"; 1005 } 1007 identity nat { 1008 base protocol-type; 1009 description 1010 "The identity for nat."; 1011 reference 1012 "RFC 1631: The IP Network Address Translator (NAT)"; 1013 } 1015 identity primary-action { 1016 description 1017 "This identity represents the primary actions, such as 1018 PASS, DROP, ALERT, RATE-LIMIT, and MIRROR."; 1019 } 1021 identity pass { 1022 base primary-action; 1023 description 1024 "The identity for pass."; 1025 } 1027 identity drop { 1028 base primary-action; 1029 description 1030 "The identity for drop."; 1031 } 1033 identity alert { 1034 base primary-action; 1035 description 1036 "The identity for alert."; 1037 } 1039 identity rate-limit { 1040 base primary-action; 1041 description 1042 "The identity for rate-limit."; 1043 } 1045 identity mirror { 1046 base primary-action; 1047 description 1048 "The identity for mirroring."; 1049 } 1051 identity secondary-action { 1052 description 1053 "This field identifies additional actions if a rule is 1054 matched. This could be one of 'LOG', 'SYSLOG', 1055 'SESSION-LOG', etc."; 1056 } 1058 identity log { 1059 base secondary-action; 1060 description 1061 "The identity for logging."; 1062 } 1064 identity syslog { 1065 base secondary-action; 1066 description 1067 "The identity for system logging."; 1068 } 1070 identity session-log { 1071 base secondary-action; 1072 description 1073 "The identity for session logging."; 1074 } 1076 identity signature-type { 1077 description 1078 "This represents the base identity for signature types."; 1079 } 1081 identity signature-yara { 1082 base signature-type; 1083 description 1084 "This represents the YARA signatures."; 1085 } 1087 identity signature-snort { 1088 base signature-type; 1089 description 1090 "This represents the SNORT signatures."; 1091 } 1093 identity signature-suricata { 1094 base signature-type; 1095 description 1096 "This represents the SURICATA signatures."; 1097 } 1099 identity threat-feed-type { 1100 description 1101 "This represents the base identity for threat-feed."; 1102 } 1104 identity day { 1105 description 1106 "This represents the base for days."; 1107 } 1109 identity monday { 1110 base day; 1111 description 1112 "This represents monday."; 1113 } 1115 identity tuesday { 1116 base day; 1117 description 1118 "This represents tuesday."; 1119 } 1121 identity wednesday { 1122 base day; 1123 description 1124 "This represents wednesday."; 1125 } 1127 identity thursday { 1128 base day; 1129 description 1130 "This represents thursday."; 1131 } 1133 identity friday { 1134 base day; 1135 description 1136 "This represents friday."; 1137 } 1139 identity saturday { 1140 base day; 1141 description 1142 "This represents saturday."; 1143 } 1145 identity sunday { 1146 base day; 1147 description 1148 "This represents sunday."; 1149 } 1151 /* 1152 * Typedefs 1153 */ 1154 typedef time{ 1155 type string { 1156 pattern '\d{2}:\d{2}:\d{2}(\.\d+)?' 1157 + '(Z|[\+\-]\d{2}:\d{2})'; 1158 } 1159 description 1160 "This is the format of time."; 1161 } 1163 /* 1164 * Groupings 1165 */ 1167 grouping ipv4-list { 1168 description 1169 "Grouping for ipv4 based ip-addresses."; 1170 leaf-list ipv4 { 1171 type inet:ipv4-address; 1172 description 1173 "This is the entry for the ipv4 ip-addresses."; 1174 } 1175 } 1177 grouping ipv6-list { 1178 description 1179 "Grouping for ipv6 based ip-addresses."; 1180 leaf-list ipv6 { 1181 type inet:ipv6-address; 1182 description 1183 "This is the entry for the ipv6 ip-addresses."; 1184 } 1185 } 1187 grouping ipv4 { 1188 description 1189 "Grouping for ipv4 based ip-address."; 1190 leaf ipv4 { 1191 type inet:ipv4-address; 1192 description 1193 "This is the entry for the ipv4 ip-address."; 1194 } 1196 } 1198 grouping ipv6 { 1199 description 1200 "Grouping for ipv6 based ip-address."; 1201 leaf ipv6 { 1202 type inet:ipv6-address; 1203 description 1204 "This is the entry for the ipv6 ip-address."; 1205 } 1206 } 1208 grouping ip-address-info { 1209 description 1210 "There are two types to configure a security policy 1211 for IPv4 address, such as exact match and range match."; 1212 choice match-type { 1213 description 1214 "User can choose between 'exact match' and 'range match'."; 1215 case exact-match-ipv4 { 1216 uses ipv4; 1217 description 1218 "Exact ip-address match for ipv4 type addresses"; 1219 } 1220 case exact-match-ipv6 { 1221 uses ipv6; 1222 description 1223 "Exact ip-address match for ipv6 type addresses"; 1224 } 1225 case range-match-ipv4 { 1226 container range-ipv4-address { 1227 leaf start-ipv4-address { 1228 type inet:ipv4-address; 1229 description 1230 "Start IPv4 address for a range match."; 1231 } 1232 leaf end-ipv4-address { 1233 type inet:ipv4-address; 1234 description 1235 "End IPv4 address for a range match."; 1236 } 1237 description 1238 "Range match for an IP-address."; 1239 } 1240 } 1241 case range-match-ipv6 { 1242 container range-ipv6-address { 1243 leaf start-ipv6-address { 1244 type inet:ipv6-address; 1245 description 1246 "Start IPv6 address for a range match."; 1247 } 1248 leaf end-ipv6-address { 1249 type inet:ipv6-address; 1250 description 1251 "End IPv6 address for a range match."; 1252 } 1253 description 1254 "Range match for an IP-address."; 1255 } 1256 } 1257 } 1258 } 1260 grouping ipsec-based-method { 1261 description 1262 "This represents the ipsec-based method."; 1263 list ipsec-method { 1264 key "method"; 1265 description 1266 "This represents the list of IPsec method types."; 1267 leaf method { 1268 type identityref { 1269 base i2nsf-ipsec; 1270 } 1271 description 1272 "This represents IPsec IKE and IPsec IKEless cases. 1273 If this is not set, it cannot support IPsec IKE or 1274 IPsec IKEless."; 1275 reference 1276 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; 1277 } 1278 } 1279 } 1281 grouping user-group { 1282 description 1283 "The grouping for user-group entities, and contains 1284 information such as name & ip-address."; 1285 leaf name { 1286 type string; 1287 description 1288 "This represents the name of a user-group. 1289 A user-group name is used to map a user-group's 1290 name (e.g., employees) to an ip address. 1291 It is implementation dependent"; 1293 } 1294 uses ip-address-info{ 1295 refine match-type{ 1296 mandatory true; 1297 } 1298 description 1299 "This represent the IP address of a user-group."; 1300 } 1301 } 1303 grouping device-group { 1304 description 1305 "This group represents device group information 1306 such as ip-address protocol."; 1307 leaf name { 1308 type string; 1309 description 1310 "This represents the name of a device-group."; 1311 } 1312 uses ip-address-info{ 1313 refine match-type{ 1314 mandatory true; 1315 } 1316 } 1317 leaf-list protocol { 1318 type identityref { 1319 base protocol-type; 1320 } 1321 description 1322 "This represents the communication protocols of 1323 devices. 1324 If this is not set, it cannot support the 1325 appropriate protocol"; 1326 } 1327 } 1329 grouping location-group { 1330 description 1331 "This group represents location-group information 1332 such as geo-ip and continent."; 1333 leaf name { 1334 type string; 1335 description 1336 "This represents the name of a location."; 1337 } 1338 list geo-ip-ipv4 { 1339 key "ipv4-address"; 1340 description 1341 "This represents the list of IPv4 address based on 1342 a location."; 1343 leaf ipv4-address{ 1344 type inet:ipv4-address; 1345 description 1346 "This represents an IPv4 geo-ip of a location."; 1347 } 1348 leaf ipv4-prefix{ 1349 type inet:ipv4-prefix; 1350 description 1351 "This represents the prefix for the IPv4-address."; 1352 } 1353 } 1354 list geo-ip-ipv6 { 1355 key "ipv6-address"; 1356 description 1357 "This represents the list of IPv6 address based on 1358 a location."; 1359 leaf ipv6-address{ 1360 type inet:ipv6-address; 1361 description 1362 "This represents an IPv6 geo-ip of a location."; 1363 } 1364 leaf ipv6-prefix{ 1365 type inet:ipv6-prefix; 1366 description 1367 "This represents the prefix for the IPv6-address."; 1368 } 1369 } 1370 leaf continent { 1371 type identityref { 1372 base continent; 1373 } 1374 default asia; 1375 description 1376 "location-group-based on geo-ip of 1377 respective continent."; 1378 } 1379 } 1381 grouping threat-feed-info { 1382 description 1383 "This is the grouping for the threat-feed-list"; 1384 leaf threat-type { 1385 type identityref { 1386 base threat-feed-type; 1387 } 1388 description 1389 "This represents the type of the threat-feed."; 1390 } 1391 leaf server-ipv4 { 1392 type inet:ipv4-address; 1393 description 1394 "The IPv4 ip-address for the threat-feed server."; 1395 } 1396 leaf server-ipv6 { 1397 type inet:ipv6-address; 1398 description 1399 "The IPv6 ip-address for the threat-feed server."; 1400 } 1401 leaf description { 1402 type string; 1403 description 1404 "This represents the descriptions of a threat-feed. 1405 The description should include information, such as 1406 the type, related threat, method, and file type. 1407 Structured Threat Information Expression (STIX) can 1408 be used for description of a threat [STIX]."; 1409 } 1410 } 1412 grouping payload-string { 1413 description 1414 "The grouping for payload-string content. 1415 It contains information such as name and string 1416 content."; 1417 leaf description { 1418 type string; 1419 description 1420 "This represents the description of a payload. 1421 If this is not set, it cannot support the 1422 description of how the payload content is 1423 related to a security attack."; 1424 } 1425 leaf-list content { 1426 type string; 1427 description 1428 "This represents the string of the payload 1429 contents. This content leaf-list contains the 1430 payload of a packet to analyze a threat. 1431 Due to the types of threats, the type of the 1432 content is defined as string to accommodate 1433 any kind of a payload type such as HTTP, HTTPS, 1434 and SIP. 1435 If this is not set, it cannot support the 1436 payload contents involved in a security attack 1437 as strings"; 1438 } 1439 } 1441 list i2nsf-cfi-policy { 1442 key "policy-name"; 1443 description 1444 "This is the security policy list. Each policy in 1445 the list contains a list of security rules, and is 1446 a policy instance to have complete information 1447 such as where and when a policy needs to be 1448 applied."; 1449 leaf policy-name { 1450 type string; 1451 description 1452 "The name which identifies the policy."; } 1453 container rules{ 1454 description 1455 "This container is for rules."; 1456 nacm:default-deny-write; 1457 list rule { 1458 key "rule-name"; 1459 ordered-by user; 1460 leaf rule-name { 1461 type string; 1462 description 1463 "This represents the name for the rule."; 1464 } 1465 description 1466 "There can be a single or multiple number of 1467 rules."; 1469 container event { 1470 description 1471 "This represents the event (e.g., a security 1472 event, for which a security rule is made.)"; 1473 leaf security-event { 1474 type identityref { 1475 base security-event-type; 1476 } 1477 description 1478 "This contains the description of security 1479 events. If this is not set, it cannot 1480 support which security event is enforced"; 1481 } 1483 container time-information { 1484 description 1485 "The time information when the security 1486 rule should be applied."; 1487 leaf start-date-time { 1488 type yang:date-and-time; 1489 description 1490 "This is the start date and time 1491 for policy."; 1492 } 1493 leaf end-date-time { 1494 type yang:date-and-time; 1495 description 1496 "This is the end date and time 1497 for policy. The policy will stop 1498 working after the specified 1499 end-date-time"; 1500 } 1501 container period{ 1502 when 1503 "/i2nsf-cfi-policy/rules/rule/event/frequency!='only-once'"; 1504 description 1505 "This represents the repetition time. 1506 In case of frequency is weekly, the days 1507 can be set."; 1508 leaf start-time { 1509 type time; 1510 description 1511 "This is period start time for event."; 1512 } 1513 leaf end-time { 1514 type time; 1515 description 1516 "This is period end time for event."; 1517 } 1518 leaf-list day { 1519 when 1520 "/i2nsf-cfi-policy/rules/rule/event/frequency='weekly'"; 1521 type identityref{ 1522 base day; 1523 } 1524 description 1525 "This represents the repeated day of 1526 every week (e.g., monday and tuesday). 1527 More than one day can be specified"; 1528 } 1529 leaf-list date { 1530 when 1531 "/i2nsf-cfi-policy/rules/rule/event/frequency='monthly'"; 1532 type int32{ 1533 range "1..31"; 1534 } 1535 description 1536 "This represents the repeated date of 1537 every month. More than one date can be 1538 specified."; 1539 } 1540 leaf-list month { 1541 when 1542 "/i2nsf-cfi-policy/rules/rule/event/frequency='yearly'"; 1543 type string{ 1544 pattern '\d{2}-\d{2}'; 1545 } 1546 description 1547 "This represents the repeated date and month 1548 of every year. More than one can be specified. 1549 Pattern used is Month-Date (MM-DD)."; 1550 } 1551 } 1552 } 1554 leaf frequency { 1555 type enumeration { 1556 enum only-once { 1557 description 1558 "This represents the rule is enforced 1559 only once immediately and not repeated. 1560 The policy will continuously active from 1561 start time and terminated at end-time."; 1562 } 1563 enum daily { 1564 description 1565 "This represents the rule is enforced 1566 on a daily basis. The policy will be 1567 repeated daily until the end-date."; 1568 } 1569 enum weekly { 1570 description 1571 "This represents the rule is enforced 1572 on a weekly basis. The policy will be 1573 repeated weekly until the end-date. The 1574 repeated days can be specified."; 1575 } 1576 enum monthly { 1577 description 1578 "This represents the rule is enforced 1579 on a monthly basis. The policy will be 1580 repeated monthly until the end-date."; 1582 } 1583 enum yearly { 1584 description 1585 "This represents the rule is enforced 1586 on a yearly basis. The policy will be 1587 repeated yearly until the end-date."; 1588 } 1589 } 1590 default only-once; 1591 description 1592 "This represents how frequent the rule 1593 should be enforced."; 1594 } 1595 } 1597 container condition { 1598 description 1599 "The conditions for general security policies."; 1600 container firewall-condition { 1601 description 1602 "The general firewall condition."; 1603 leaf source { 1604 type leafref { 1605 path 1606 "/i2nsf-cfi-policy/endpoint-groups/user-group/name"; 1607 } 1608 description 1609 "This describes the paths to the source reference."; 1610 } 1612 leaf-list destination { 1613 type leafref { 1614 path 1615 "/i2nsf-cfi-policy/endpoint-groups/user-group/name"; 1616 } 1617 description 1618 "This describes the paths to the destination 1619 target reference."; 1620 } 1621 } 1623 container ddos-condition { 1624 description 1625 "The condition for DDoS mitigation."; 1626 leaf-list source { 1627 type leafref { 1628 path 1629 "/i2nsf-cfi-policy/endpoint-groups/device-group/name"; 1630 } 1631 description 1632 "This describes the path to the 1633 source target references."; 1634 } 1635 leaf-list destination { 1636 type leafref { 1637 path 1638 "/i2nsf-cfi-policy/endpoint-groups/device-group/name"; 1639 } 1640 description 1641 "This describes the path to the destination target 1642 references."; 1643 } 1644 container rate-limit { 1645 description 1646 "This describes the rate-limit."; 1647 leaf packet-threshold-per-second { 1648 type uint32; 1649 description 1650 "This is a trigger value for the condition."; 1651 } 1652 } 1653 } 1655 container location-condition { 1656 description 1657 "The condition for location based connection"; 1658 leaf-list source { 1659 type leafref { 1660 path 1661 "/i2nsf-cfi-policy/endpoint-groups/location-group/name"; 1662 } 1663 description 1664 "This describes the path to the location 1665 source reference."; 1666 } 1667 leaf-list destination { 1668 type leafref { 1669 path 1670 "/i2nsf-cfi-policy/endpoint-groups/location-group/name"; 1671 } 1672 description 1673 "This describes the path to the location 1674 destination reference."; 1675 } 1676 } 1677 container custom-condition { 1678 description 1679 "The condition based on packet contents."; 1680 leaf-list source { 1681 type leafref { 1682 path 1683 "/i2nsf-cfi-policy/threat-preventions/payload-content/name"; 1684 } 1685 description 1686 "Describes the payload string content condition 1687 source."; 1688 } 1689 leaf destination { 1690 type leafref { 1691 path 1692 "/i2nsf-cfi-policy/threat-preventions/payload-content/name"; 1693 } 1694 description 1695 "Describes the payload string content condition 1696 destination."; 1697 } 1698 } 1700 container threat-feed-condition { 1701 description 1702 "The condition based on the threat-feed information."; 1703 leaf-list source { 1704 type leafref { 1705 path 1706 "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name"; 1707 } 1708 description 1709 "Describes the threat-feed condition source."; 1710 } 1711 leaf destination { 1712 type leafref { 1713 path 1714 "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name"; 1715 } 1716 description 1717 "Describes the threat-feed condition destination."; 1718 } 1719 } 1720 } 1722 container actions { 1723 description 1724 "This is the action container."; 1726 leaf primary-action { 1727 type identityref { 1728 base primary-action; 1729 } 1730 description 1731 "This represent the primary actions (e.g., 1732 PASS, DROP, ALERT, and MIRROR) to be 1733 applied a condition. 1734 If this is not set, it cannot support 1735 the primary actions."; 1736 } 1737 leaf secondary-action { 1738 type identityref { 1739 base secondary-action; 1740 } 1741 description 1742 "This represents the secondary actions 1743 (e.g., log and syslog) to be applied 1744 if needed. 1745 If this is not set, it cannot support 1746 the secondary actions."; 1747 } 1748 } 1750 container ipsec-method { 1751 description 1752 "This container represents the IPsec IKE 1753 and IKEless cases."; 1754 leaf method { 1755 type identityref { 1756 base i2nsf-ipsec; 1757 } 1758 description 1759 "This references the IPsec method types, 1760 which includes IPsec IKE and IPsec IKEless 1761 cases. 1762 If this is not set, it cannot support 1763 IPsec IKE or IPsec IKEless."; 1764 reference 1765 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; 1766 } 1767 } 1768 } 1769 } 1770 container endpoint-groups { 1771 description 1772 "A logical entity in their business 1773 environment, where a security policy 1774 is to be applied."; 1775 list user-group{ 1776 uses user-group; 1777 key "name"; 1778 description 1779 "This represents the user group."; 1780 } 1781 list device-group { 1782 key "name"; 1783 uses device-group; 1784 description 1785 "This represents the device group."; 1786 } 1787 list location-group{ 1788 key "name"; 1789 uses location-group; 1790 description 1791 "This represents the location group."; 1792 } 1793 } 1795 container threat-preventions { 1796 description 1797 "this describes the list of threat-prevention."; 1798 list threat-feed-list { 1799 key "name"; 1800 description 1801 "There can be a single or multiple number of 1802 threat-feeds."; 1803 leaf name { 1804 type string; 1805 description 1806 "This represents the name of the threat-feed."; 1807 } 1808 uses threat-feed-info; 1809 leaf-list threat-file-types { 1810 type identityref { 1811 base malware-file-type; 1812 } 1813 default executable-file; 1814 description 1815 "This contains a list of file types needed to 1816 be scanned for the virus."; 1817 } 1818 leaf-list signatures { 1819 type identityref { 1820 base signature-type; 1821 } 1822 default signature-suricata; 1823 description 1824 "This contains a list of signatures or hashes 1825 of the threats."; 1826 } 1827 } 1828 list payload-content { 1829 key "name"; 1830 leaf name { 1831 type string; 1832 description 1833 "This represents the name of payload-content. 1834 It should give an idea of why specific payload 1835 content is marked as threat. For example, the 1836 name 'backdoor' indicates the payload content 1837 is related to backdoor attack."; 1838 } 1839 description 1840 "This represents the payload-string group."; 1841 uses payload-string; 1842 } 1843 } 1844 } 1845 } 1846 1848 Figure 17: YANG for Consumer-Facing Interface 1850 9. XML Configuration Examples of High-Level Security Policy Rules 1852 Note: This section is informative with XML configuration examples. 1854 This section is informative with XML configuration examples. This 1855 section shows XML configuration examples of high-level security 1856 policy rules that are delivered from the I2NSF User to the Security 1857 Controller over the Consumer-Facing Interface. The considered use 1858 cases are: Database registration, time-based firewall for web 1859 filtering, VoIP/VoLTE security service, and DDoS-attack mitigation. 1861 9.1. Database Registration: Information of Positions and Devices 1862 (Endpoint Group) 1864 If new endpoints are introduced to the network, it is necessary to 1865 first register their data to the database. For example, if new 1866 members are newly introduced in either of three different groups 1867 (i.e., user-group, device-group, and payload-group), each of them 1868 should be registered with information such as ip-addresses or 1869 protocols used by devices. Figure 18 shows an example XML 1870 representation of the registered information for the user-group and 1871 device-group. 1873 1874 1875 1876 1877 employees 1878 1879 221.159.112.1 1880 221.159.112.90 1881 1882 1883 1884 webservers 1885 1886 221.159.112.91 1887 221.159.112.97 1888 1889 http 1890 https 1891 1892 1893 1895 Figure 18: Registering User-group and Device-group Information 1897 9.2. Scenario 1: Block SNS Access during Business Hours 1899 The first example scenario is to "block SNS access during office 1900 hours" using a time-based firewall policy. In this scenario, all 1901 users registered as "employees" in the user-group list are unable to 1902 access Social Networking Services (SNS) during the office hours 1903 (weekdays). The XML instance is described below: 1905 1906 1907 security_policy_for_blocking_sns123 1908 1909 1910 block_access_to_sns_during_office_hours 1911 1912 1913 2020-03-11T09:00:00.00Z 1914 2020-12-31T18:00:00.00Z 1915 1916 09:00:00Z 1917 18:00:00Z 1918 monday 1919 tuesday 1920 wednesday 1921 thursday 1922 friday 1923 1924 1925 weekly 1926 1927 1928 1929 employees 1930 1931 1932 1933 drop 1934 1935 1936 1937 1939 Figure 19: An XML Example for Time-based Firewall 1941 Time-based-condition Firewall 1943 1. The policy name is "security_policy_for_blocking_sns". 1945 2. The rule name is "block_access_to_sns_during_office_hours". 1947 3. The Source is "employees". 1949 4. The destination target is "sns-websites". "sns-websites" is the 1950 key which represents the list containing the information, such as 1951 URL, about sns-websites. 1953 5. The action required is to "drop" any attempt to connect to 1954 websites related to Social networking. 1956 6. The IPsec method type used for nsf traffic steering is set to 1957 "ipsec-ike". 1959 9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a Company 1961 The second example scenario is to "block malicious VoIP/VoLTE packets 1962 coming to a company" using a VoIP policy. In this scenario, the 1963 calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that 1964 are classified as malicious are dropped. The IP addresses of the 1965 employees and malicious VOIP IDs should be blocked are stored in the 1966 database or datastore of the enterprise. Here and the rest of the 1967 cases assume that the security administrators or someone responsible 1968 for the existing and newly generated policies, are not aware of which 1969 and/or how many NSFs are needed to meet the security requirements. 1970 Figure 20 represents the XML document generated from YANG discussed 1971 in previous sections. Once a high-level seucurity policy is created 1972 by a security admin, it is delivered by the Consumer-Facing 1973 Interface, through RESTCONF server, to the security controller. The 1974 XML instance is described below: 1976 1977 1978 1979 security_policy_for_blocking_malicious_voip_packets 1980 1981 1982 1983 Block_malicious_voip_and_volte_packets 1984 1985 1986 malicious-id 1987 1988 1989 employees 1990 1991 1992 1993 drop 1994 1995 1996 ipsec-ikeless 1997 1998 1999 2000 2002 Figure 20: An XML Example for VoIP Security Service 2004 Custom-condition Firewall 2006 1. The policy name is 2007 "security_policy_for_blocking_malicious_voip_packets". 2009 2. The rule name is "Block_malicious_voip_and_volte_packets". 2011 3. The Source is "malicious-id". This can be a single ID or a list 2012 of IDs, depending on how the ID are stored in the database. The 2013 "malicious-id" is the key so that the security admin can read 2014 every stored malicious VOIP IDs that are named as "malicious-id". 2016 4. The destination target is "employees". "employees" is the key 2017 which represents the list containing information about employees, 2018 such as IP addresses. 2020 5. The action required is "drop" when any incoming packets are from 2021 "malicious-id". 2023 6. The IPsec method used for nsf traffic steering is set to "ipsec- 2024 ikeless". 2026 9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web 2027 Server 2029 The third example scenario is to "Mitigate HTTP and HTTPS flood 2030 attacks on a company web server" using a DDoS-attack mitigation 2031 policy. Here, the time information is not set because the service 2032 provided by the network should be maintained at all times. If the 2033 packets sent by any sources are more than the set threshold, then the 2034 admin can set the percentage of the packets to be dropped to safely 2035 maintain the service. In this scenario, the source is set as "any" 2036 to block any sources which send abnormal amount of packets. The 2037 destination is set as "web_server01". Once the rule is set and 2038 delivered and enforced to the nsfs by the securiy controller, the 2039 NSFs will monitor the incoming packet amounts and the destination to 2040 act according to the rule set. The XML instance is described below: 2042 2043 2044 security_policy_for_ddos_attacks 2045 2046 2047 100_packets_per_second 2048 2049 2050 webservers 2051 2052 100 2053 2054 2055 2056 2057 drop 2058 2059 2060 ipsec-ikeless 2061 2062 2063 2064 2066 Figure 21: An XML Example for DDoS-attack Mitigation 2068 DDoS-condition Firewall 2069 1. The policy name is "security_policy_for_ddos_attacks". 2071 2. The rule name is "100_packets_per_second". 2073 3. The destination target is "webservers". "webservers" is the key 2074 which represents the list containing information, such as IP 2075 addresses and ports, about web-servers. 2077 4. The rate limit exists to limit the incoming amount of packets per 2078 second. In this case the rate limit is "100" packets per second. 2079 This amount depends on the packet receiving capacity of the 2080 server devices. 2082 5. The Source is all sources which send abnormal amount of packets. 2084 6. The action required is to "drop" packet reception is more than 2085 100 packets per second. 2087 7. The IPsec method used for nsf traffic steering is set to "ipsec- 2088 ike". 2090 10. XML Configuration Example of a User Group's Access Control for 2091 I2NSF Consumer-Facing Interface 2093 Note: This section is informative with an XML configuration example. 2095 This is an example for creating privileges for a group of users 2096 (i.e., a user group) to access and use the I2NSF Consumer-Facing 2097 Interface to create security policies via the interface. For the 2098 access control of the Consumer-Facing Interface, the NACM module can 2099 be used. Figure 22 shows an XML example the access control of a user 2100 group (named Example-Group) for I2NSF Consumer-Facing Interface A 2101 group called Example-Group can be created and configured with NACM 2102 for the Consumer-Facing Interface. For Example-Group, a rule list 2103 can created with the name of Example-Group-Rules. Example-Group- 2104 Rules has two rules of Example-Group-Rule1 and Example-Group-Rule2 as 2105 follows. For Example-Group-Rule1, the privilege of "Read" is allowed 2106 to Example-Group for the Consumer-Facing Interface. On the other 2107 hand, for Example-Group-Rule2, the privileges of "Create", "Update", 2108 and "Delete" are denied against Example-Group for the Consumer-Facing 2109 Interface. 2111 2112 2113 true 2114 2115 2116 Example-Group 2117 Alice 2118 Bob 2119 Eve 2120 2121 2122 2123 Example-Group-Rules 2124 Example-Group 2125 2126 Example-Group-Rule1 2127 read 2128 ietf-i2nsf-cfi-policy 2129 permit 2130 2131 2132 Example-Group-Rule2 2133 create update delete 2134 ietf-i2nsf-cfi-policy 2135 deny 2136 2137 2138 2140 Figure 22: An XML Example of a User Group's Access Control for I2NSF 2141 Consumer-Facing Interface 2143 The access control for the I2NSF Consumer-Facing Interface is as 2144 follows. 2146 1. The NACM is enabled. 2148 2. As a group name, Example-Group is specified. 2150 3. As members of the group, Alice, Bob, and Eve are specified. 2152 4. As a rule list name, Example-Group-Rules is specified for 2153 managing privileges of Example-Group's members. 2155 5. As the first rule name, Example-Group-Rule1 is specified. This 2156 rule is used to give read privilege to Example-Group's members 2157 for the module of the I2NSF Consumer-Facing Interface. 2159 6. As the second rule name, Example-Group-Rule2 is specified. This 2160 rule is used to deny create, update, and delete privileges 2161 against Example-Group's members for the module of the I2NSF 2162 Consumer-Facing Interface. 2164 11. Security Considerations 2166 The data model for the I2NSF Consumer-Facing Interface is based on 2167 the I2NSF framework [RFC8329], so the same security considerations 2168 with the I2NSF framework should be included in this document. The 2169 data model needs a secure communication channel to protect the 2170 Consumer-Facing Interface between the I2NSF User and Security 2171 Controller. Also, the data model's management access control is 2172 based on Network Configuration Access Control Model(NACM) mechanisms 2173 [RFC8341]. 2175 12. IANA Considerations 2177 This document requests IANA to register the following URI in the 2178 "IETF XML Registry" [RFC3688]: 2180 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2181 Registrant Contact: The I2NSF. 2182 XML: N/A; the requested URI is an XML namespace. 2184 This document requests IANA to register the following YANG module in 2185 the "YANG Module Names" registry [RFC7950]. 2187 name: ietf-i2nsf-cfi-policy 2188 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2189 prefix: cfi-policy 2190 reference: RFC 7950 2192 13. Acknowledgments 2194 This work was supported by Institute of Information & Communications 2195 Technology Planning & Evaluation (IITP) grant funded by the Korea 2196 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 2197 Security Intelligence Technology Development for the Customized 2198 Security Service Provisioning). 2200 14. Contributors 2202 This document is made by the group effort of I2NSF working group. 2203 Many people actively contributed to this document, such as Mahdi F. 2205 Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their 2206 contributions. 2208 The following are co-authors of this document: 2210 Patrick Lingga 2211 Department of Electronic, Electrical and Computer Engineering 2212 Sungkyunkwan University 2213 2066 Seo-ro Jangan-gu 2214 Suwon, Gyeonggi-do 16419 2215 Republic of Korea 2217 EMail: patricklink@skku.edu 2219 Hyoungshick Kim 2220 Department of Computer Science and Engineering 2221 Sungkyunkwan University 2222 2066 Seo-ro Jangan-gu 2223 Suwon, Gyeonggi-do 16419 2224 Republic of Korea 2226 EMail: hyoung@skku.edu 2228 Eunsoo Kim 2229 Department of Electronic, Electrical and Computer Engineering 2230 Sungkyunkwan University 2231 2066 Seo-ro Jangan-gu 2232 Suwon, Gyeonggi-do 16419 2233 Republic of Korea 2235 EMail: eskim86@skku.edu 2237 Seungjin Lee 2238 Department of Electronic, Electrical and Computer Engineering 2239 Sungkyunkwan University 2240 2066 Seo-ro Jangan-gu 2241 Suwon, Gyeonggi-do 16419 2242 Republic of Korea 2244 EMail: jine33@skku.edu 2246 Jinyong Tim Kim 2247 Department of Electronic, Electrical and Computer Engineering 2248 Sungkyunkwan University 2249 2066 Seo-ro Jangan-gu 2250 Suwon, Gyeonggi-do 16419 2251 Republic of Korea 2253 EMail: timkim@skku.edu 2255 Anil Lohiya 2256 Juniper Networks 2257 1133 Innovation Way 2258 Sunnyvale, CA 94089 2259 US 2261 EMail: alohiya@juniper.net 2263 Dave Qi 2264 Bloomberg 2265 731 Lexington Avenue 2266 New York, NY 10022 2267 US 2269 EMail: DQI@bloomberg.net 2271 Nabil Bitar 2272 Nokia 2273 755 Ravendale Drive 2274 Mountain View, CA 94043 2275 US 2277 EMail: nabil.bitar@nokia.com 2279 Senad Palislamovic 2280 Nokia 2281 755 Ravendale Drive 2282 Mountain View, CA 94043 2283 US 2285 EMail: senad.palislamovic@nokia.com 2287 Liang Xia 2288 Huawei 2289 101 Software Avenue 2290 Nanjing, Jiangsu 210012 2291 China 2292 EMail: Frank.Xialiang@huawei.com 2294 15. References 2296 15.1. Normative References 2298 [i2nsf-ipsec] 2299 Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 2300 Garcia, "Software-Defined Networking (SDN)-based IPsec 2301 Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow- 2302 protection-08 (work in progress), June 2020. 2304 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2305 Information Models and Data Models", RFC 3444, 2306 DOI 10.17487/RFC3444, January 2003, 2307 . 2309 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2310 DOI 10.17487/RFC3688, January 2004, 2311 . 2313 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2314 the Network Configuration Protocol (NETCONF)", RFC 6020, 2315 DOI 10.17487/RFC6020, October 2010, 2316 . 2318 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2319 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2320 . 2322 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2323 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2324 . 2326 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2327 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2328 May 2017, . 2330 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2331 and J. Jeong, "Interface to Network Security Functions 2332 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2333 DOI 10.17487/RFC8192, July 2017, 2334 . 2336 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2337 Kumar, "Framework for Interface to Network Security 2338 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2339 . 2341 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2342 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2343 . 2345 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2346 Access Control Model", STD 91, RFC 8341, 2347 DOI 10.17487/RFC8341, March 2018, 2348 . 2350 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2351 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2352 DOI 10.17487/RFC8407, October 2018, 2353 . 2355 15.2. Informative References 2357 [client-facing-inf-req] 2358 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 2359 S., and L. Xia, "Requirements for Client-Facing Interface 2360 to Security Controller", draft-ietf-i2nsf-client-facing- 2361 interface-req-05 (work in progress), May 2018. 2363 [i2nsf-capability-im] 2364 Xia, L., Strassner, J., Basile, C., and D. Lopez, 2365 "Information Model of NSFs Capabilities", draft-ietf- 2366 i2nsf-capability-05 (work in progress), April 2019. 2368 [i2nsf-terminology] 2369 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 2370 Birkholz, "Interface to Network Security Functions (I2NSF) 2371 Terminology", draft-ietf-i2nsf-terminology-08 (work in 2372 progress), July 2019. 2374 [STIX] Jordan, B., Piazza, R., and T. Darley, "STIX Version 2.1", 2375 Committee Specification 01 https://docs.oasis- 2376 open.org/cti/stix/v2.1/stix-v2.1.pdf, March 2020. 2378 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- 2379 dm-08 2381 The following changes are made from draft-ietf-i2nsf-consumer-facing- 2382 interface-dm-08: 2384 o This version is revised according to the comments from Jan 2385 Lindblad who reviewed this document as a YANG doctor. 2387 Authors' Addresses 2389 Jaehoon Paul Jeong 2390 Department of Computer Science and Engineering 2391 Sungkyunkwan University 2392 2066 Seobu-Ro, Jangan-Gu 2393 Suwon, Gyeonggi-Do 16419 2394 Republic of Korea 2396 Phone: +82 31 299 4957 2397 Fax: +82 31 290 7996 2398 EMail: pauljeong@skku.edu 2399 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2401 Chaehong Chung 2402 Department of Electronic, Electrical and Computer Engineering 2403 Sungkyunkwan University 2404 2066 Seobu-Ro, Jangan-Gu 2405 Suwon, Gyeonggi-Do 16419 2406 Republic of Korea 2408 Phone: +82 31 299 4957 2409 EMail: darkhong@skku.edu 2411 Tae-Jin Ahn 2412 Korea Telecom 2413 70 Yuseong-Ro, Yuseong-Gu 2414 Daejeon 305-811 2415 Republic of Korea 2417 Phone: +82 42 870 8409 2418 EMail: taejin.ahn@kt.com 2419 Rakesh Kumar 2420 Juniper Networks 2421 1133 Innovation Way 2422 Sunnyvale, CA 94089 2423 USA 2425 EMail: rkkumar@juniper.net 2427 Susan Hares 2428 Huawei 2429 7453 Hickory Hill 2430 Saline, MI 48176 2431 USA 2433 Phone: +1-734-604-0332 2434 EMail: shares@ndzh.com