idnits 2.17.1 draft-ietf-i2nsf-consumer-facing-interface-dm-10.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 39 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-i2nsf-capability]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 269 has weird spacing: '...le-name strin...' == Line 489 has weird spacing: '...address ine...' == Line 531 has weird spacing: '...address ine...' == Line 535 has weird spacing: '...address ine...' == Line 663 has weird spacing: '...ription strin...' -- The document date (August 28, 2020) is 1337 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: 'RFC0913' is defined on line 2372, but no explicit reference was found in the text == Unused Reference: 'RFC5321' is defined on line 2422, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 2431, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 2457, but no explicit reference was found in the text == Unused Reference: 'STIX' is defined on line 2508, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-netmod-rfc6991-bis-04 ** Downref: Normative reference to an Historic RFC: RFC 913 ** Obsolete normative reference: RFC 1081 (Obsoleted by RFC 1225) ** Obsolete normative reference: RFC 1631 (Obsoleted by RFC 3022) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 3444 ** Downref: Normative reference to an Informational RFC: RFC 3849 ** Downref: Normative reference to an Informational RFC: RFC 5737 ** Downref: Normative reference to an Informational RFC: RFC 8192 ** Downref: Normative reference to an Informational RFC: RFC 8329 ** Downref: Normative reference to an Informational RFC: RFC 8805 == Outdated reference: A later version (-14) exists of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 Summary: 13 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group J. Jeong, Ed. 3 Internet-Draft C. Chung 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: March 1, 2021 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 August 28, 2020 13 I2NSF Consumer-Facing Interface YANG Data Model 14 draft-ietf-i2nsf-consumer-facing-interface-dm-10 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 based on the "Event-Condition-Action" (ECA) 25 policy model defined by a capability information model for I2NSF 26 [I-D.ietf-i2nsf-capability], 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 March 1, 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 . . . . . . . . 10 73 5.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 12 75 5.3. Location Group . . . . . . . . . . . . . . . . . . . . . 13 76 6. Information Model for Threat Prevention . . . . . . . . . . . 14 77 6.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 14 78 6.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 15 79 7. Network Configuration Access Control Model (NACM) for I2NSF 80 Consumer-Facing Interface . . . . . . . . . . . . . . . . . . 16 81 8. YANG Data Model of Consumer-Facing Interface . . . . . . . . 18 82 8.1. YANG Module of Consumer-Facing Interface . . . . . . . . 18 83 9. XML Configuration Examples of High-Level Security Policy 84 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 85 9.1. Database Registration: Information of Positions and 86 Devices (Endpoint Group) . . . . . . . . . . . . . . . . 41 87 9.2. Scenario 1: Block SNS Access during Business Hours . . . 43 88 9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to 89 a Company . . . . . . . . . . . . . . . . . . . . . . . . 45 90 9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a 91 Company Web Server . . . . . . . . . . . . . . . . . . . 47 92 10. XML Configuration Example of a User Group's Access Control 93 for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 48 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 95 12. Security Considerations . . . . . . . . . . . . . . . . . . . 50 96 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 97 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 98 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 99 15.1. Normative References . . . . . . . . . . . . . . . . . . 53 100 15.2. Informative References . . . . . . . . . . . . . . . . . 56 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 103 1. Introduction 105 In a framework of Interface to Network Security Functions (I2NSF) 106 [RFC8329], each vendor can register their NSFs using a Developer's 107 Management System (DMS). Assuming that vendors also provide the 108 front-end web applications registered with an I2NSF User, the 109 Consumer-Facing Interface is required because the web applications 110 developed by each vendor need to have a standard interface specifying 111 the data types used when the I2NSF User and Security Controller 112 communicate using this interface. Therefore, this document specifies 113 the required information, their data types, and encoding schemes so 114 that high-level security policies (or configuration information for 115 security policies) can be transferred to the Security Controller 116 through the Consumer-Facing Interface. These policies can easily be 117 translated by the Security Controller into low-level security 118 policies. The Security Controller delivers the translated policies 119 to Network Security Functions (NSFs) according to their respective 120 security capabilities for the required securiy enforcement. 122 The Consumer-Facing Interface would be built using a set of objects, 123 with each object capturing a unique set of information from Security 124 Administrator (i.e., I2NSF User [RFC8329]) needed to express a 125 Security Policy. An object may have relationship with various other 126 objects to express a complete set of requirements. An information 127 model captures the managed objects and relationship among these 128 objects. The information model proposed in this document is 129 structured in accordance with the "Event-Condition-Action" (ECA) 130 policy model. 132 An NSF Capability model is proposed in [I-D.ietf-i2nsf-capability] as 133 the basic model for both the NSF-Facing interface and Consumer-Facing 134 Interface security policy model of this document. 136 [RFC3444] explains differences between an information and data model. 137 This document uses the guidelines in [RFC3444] to define both the 138 information and data model for Consumer-Facing Interface. Figure 1 139 shows a high-level abstraction of Consumer-Facing Interface. A data 140 model, which represents an implementation of the information model in 141 a specific data representation language, is also defined in this 142 document. 144 +-----------------+ 145 | Consumer-Facing | 146 | Interface | 147 +--------+--------+ 148 ^ 149 | 150 +-------------+------------+ 151 | | | 152 +-----+----+ +-----+----+ +----+----+ 153 | Policy | | Endpoint | | Threat | 154 | | | groups | | feed | 155 +-----+----+ +----------+ +---------+ 156 ^ 157 | 158 +------+------+ 159 | Rule | 160 +------+------+ 161 ^ 162 | 163 +----------------+----------------+ 164 | | | 165 +------+------+ +------+------+ +------+------+ 166 | Event | | Condition | | Action | 167 +-------------+ +-------------+ +-------------+ 169 Figure 1: Diagram for High-level Abstraction of Consumer-Facing 170 Interface 172 Data models are defined at a lower level of abstraction and provide 173 many details. They provide details about the implementation of a 174 protocol's specification, e.g., rules that explain how to map managed 175 objects onto lower-level protocol constructs. Since conceptual 176 models can be implemented in different ways, multiple data models can 177 be derived from a single information model. 179 The efficient and flexible provisioning of network functions by a 180 Network Functions Virtualization (NFV) system leads to a rapid 181 advance in the network industry. As practical applications, Network 182 Security Functions (NSFs), such as firewall, Intrusion Detection 183 System (IDS)/Intrusion Prevention System (IPS), and attack 184 mitigation, can also be provided as Virtual Network Functions (VNF) 185 in the NFV system. By the efficient virtualization technology, these 186 VNFs might be automatically provisioned and dynamically migrated 187 based on real-time security requirements. This document presents a 188 YANG data model to implement security functions based on NFV. 190 2. Requirements Language 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119][RFC3444] 195 [RFC8174]. 197 3. Terminology 199 This document uses the terminology described in [RFC8329]. 201 This document follows the guidelines of [RFC8407], uses the common 202 YANG types defined in [I-D.ietf-netmod-rfc6991-bis], and adopts the 203 Network Management Datastore Architecture (NMDA). The meaning of the 204 symbols in tree 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 Rule: This field contains a list of rules. These rules are 217 defined for 1) communication between two Endpoint Groups, 218 2) for preventing communication with externally or 219 internally identified threats, and 3) for implementing 220 business requirement such as controlling access to internal 221 or external resources for meeting regulatory compliance or 222 business objectives. An organization may restrict certain 223 communication between a set of user and applications for 224 example. The threats may be from threat feeds obtained 225 from external sources or dynamically identified by using 226 specialty devices in the network. Rule conflict analysis 227 should be triggered by the monitoring service to perform an 228 exhaustive detection of anomalies among the configuration 229 rules installed into the security functions. 231 +--rw i2nsf-cfi-policy* [policy-name] 232 +--rw policy-name string 233 +--rw rules 234 +--rw endpoint-groups 235 +--rw threat-prevention 237 Figure 2: Policy YANG Data Tree 239 A policy is a container of Rule(s). In order to express a Rule, a 240 Rule must have complete information such as where and when a policy 241 needs to be applied. This is done by defining a set of managed 242 objects and relationship among them. A Policy Rule may be related 243 segmentation, threat mitigation or telemetry data collection from an 244 NSF in the network, which will be specified as the sub-model of the 245 policy model in the subsequent sections. Figure 3 shows the YANG 246 data tree of the Rule object. The rule object SHALL have the 247 following information: 249 Name: This field identifies the name of this object. 251 Event: This field includes the information to determine whether 252 the Rule Condition can be evaluated or not. See details in 253 Section 4.1. 255 Condition: This field contains all the checking conditions to 256 apply to the objective traffic. See details in 257 Section 4.2. 259 Action: This field identifies the action taken when a rule is 260 matched. There is always an implicit action to drop 261 traffic if no rule is matched for a traffic type. See 262 details in Section 4.3. 264 IPsec-method: This field contains the information about IPsec 265 method type. There are two types such as IPsec-IKE and 266 IPsec-IKEless [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 268 +--rw rules* [rule-name] 269 +--rw rule-name string 270 +--rw event 271 +--rw (condition)? 272 +--rw action 273 +--rw ipsec-method 275 Figure 3: Rule YANG Data Tree 277 Note that in the case of policy conflicts, the resolution of the 278 conflicted policies conforms to the guidelines of "Information Model 279 of NSFs Capabilities" [I-D.ietf-i2nsf-capability]. 281 4.1. Event Sub-model 283 The Event Object contains information related to scheduling a Rule. 284 The Rule could be activated based on a set time or security event. 285 Figure 4 shows the YANG tree of the Event object. Event object SHALL 286 have following information: 288 Security-event: This field identifies for which security event 289 the policy is enforced. The examples of security events 290 are: "DDOS", "spyware", "trojan", and "ransomware". 292 Time-information: This represents the security rule is enforced 293 based on the period information with the end time for the 294 event. 296 Period: This represents the period of time the rule event is 297 active. 299 End-time: This represents the end time of the event. If the 300 rule time has pass the end-time, the rule will stop 301 repeating" 303 Frequency: This represents how frequent the rule should be 304 enforced. There are four options: "only-once", "daily", 305 "weekly" and "monthly". 307 +--rw event 308 +--rw security-event identityref 309 +--rw time-information 310 | +--rw start-date-time? yang:date-and-time 311 | +--rw end-date-time? yang:date-and-time 312 | +--rw period 313 | | +--rw start-time? time 314 | | +--rw stop-time? time 315 | | +--rw day* identityref 316 | | +--rw date* int32 317 | | +--rw month* string 318 +--rw frequency? enumeration 320 Figure 4: Event Sub-model YANG Data Tree 322 4.2. Condition Sub-model 324 This object represents Conditions that Security Administrator wants 325 to apply the checking on the traffic in order to determine whether 326 the set of actions in the Rule can be executed or not. The Condition 327 Sub-model consists of three different types of containers each 328 representing different cases, such as general firewall and DDoS- 329 mitigation cases, and a case when the condition is based on the 330 payload strings of packets. Each containers have source and 331 destination-target to represent the source and destination for each 332 case. Figure 5 shows the YANG tree of the Condition object. The 333 Condition Sub-model SHALL have following information: 335 Case (Firewall-condition): This field represents the general 336 firewall case, where a security admin can set up firewall 337 conditions using the information present in this field. 338 The source and destination is represented as firewall- 339 source and firewall-destination, each referring to the IP- 340 address-based groups defined in the endpoint-groups. 342 Case (DDoS-condition): This field represents the condition for 343 DDoS mitigation, where a security admin can set up DDoS 344 mitigation conditions using the information present in this 345 field. The source and destination is represented as ddos- 346 source and ddos-destination, each referring to the device- 347 groups defined and registered in the endpoint-groups. 349 Case (Custom-condition): This field contains the payload string 350 information. This information is useful when security rule 351 condition is based on the string contents of incoming or 352 outgoing packets. The source and destination is 353 represented as custom-source and custom-destination, each 354 referring to the payload-groups defined and registered in 355 the endpoint-groups. 357 Case (Threat-feed-condition): This field contains the 358 information obtained from threat-feeds (e.g., Palo-Alto, or 359 RSA-netwitness). This information is useful when security 360 rule condition is based on the existing threat reports 361 gathered by other sources. The source and destination is 362 represented as threat-feed-source and threat-feed- 363 destination. For clarity, threat-feed-source/destination 364 represent the source/destination of a target security 365 threat, not the information source/destination of a threat- 366 feed. 368 +--rw condition 369 +--:firewall-condition 370 | +--rw source 371 | | -> /i2nsf-cfi-policy/endpoint-groups/user-group/name 372 | +--rw destination* 373 | | -> /i2nsf-cfi-policy/endpoint-groups/user-group/name 374 +--:ddos-condition 375 | +--rw source* 376 | | -> /i2nsf-cfi-policy/endpoint-groups/device-group/name 377 | +--rw destination* 378 | | -> /i2nsf-cfi-policy/endpoint-groups/device-group/name 379 | +--rw rate-limit 380 | | +--rw packet-threshold-per-second? uint32 381 +--:location-condition 382 | +--rw source* 383 | | -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 384 | +--rw destination 385 | | -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 386 +--:custom-condition 387 | +--rw source* 388 | | -> /i2nsf-cfi-policy/threat-preventions/payload-content/name 389 | +--rw destination? 390 | | -> /i2nsf-cfi-policy/threat-preventions/payload-content/name 391 +--:threat-feed-condition 392 +--rw source* 393 | -> /i2nsf-cfi-policy/threat-preventions/threat-feed-list/name 394 +--rw destination? 395 | -> /i2nsf-cfi-policy/threat-preventions/threat-feed-list/name 397 Figure 5: Condition Sub-model YANG Data Tree 399 4.3. Action Sub-model 401 This object represents actions that Security Admin wants to perform 402 based on certain traffic class. Figure 6 shows the YANG tree of the 403 Action object. The Action object SHALL have following information: 405 Primary-action: This field identifies the action when a rule is 406 matched by an NSF. The action could be one of "PASS", 407 "DROP", "ALERT", "RATE-LIMIT", and "MIRROR". 409 Secondary-action: This field identifies the action when a rule 410 is matched by an NSF. The action could be one of "log", 411 "syslog", "session-log". 413 +--rw action 414 +--rw primary-action identityref 415 +--rw secondary-action? identityref 417 Figure 6: Action Sub-model YANG Data Tree 419 5. Information Model for Policy Endpoint Groups 421 The Policy Endpoint Group is a very important part of building User- 422 Construct based policies. A Security Administrator would create and 423 use these objects to represent a logical entity in their business 424 environment, where a Security Policy is to be applied. There are 425 multiple managed objects that constitute a Policy's Endpoint Group, 426 as shown in Figure 7. Figure 8 shows the YANG tree of the Endpoint- 427 Groups object. This section lists these objects and relationship 428 among them. 430 It is assumed that the information of Endpoint Groups (e.g., User- 431 group, Device-group, and Location-group) such as the IP address(es) 432 of each member in a group are stored in the I2NSF database available 433 to the Security Controller, and that the IP address information of 434 each group in the I2NSF database is synchronized with other systems 435 in the networks under the same administration. 437 +-------------------+ 438 | Endpoint Groups | 439 +---------+---------+ 440 ^ 441 | 442 +--------------+----------------+ 443 0..n | 0..n | 0..n | 444 +-----+----+ +------+-----+ +-------+------+ 445 |User-group| |Device-group| |Location-group| 446 +----------+ +------------+ +--------------+ 448 Figure 7: Endpoint Group Diagram 450 +--rw endpoint-groups 451 | +--rw user-group* [name] 452 | ... 453 | +--rw device-group* [name] 454 | ... 455 | +--rw location-group* [name] 456 | ... 458 Figure 8: Endpoint Group YANG Data Tree 460 5.1. User Group 462 This object represents a User-Group. Figure 9 shows the YANG tree of 463 the User-Group object. The User-Group object SHALL have the 464 following information: 466 Name: This field identifies the name of this object. 468 IPv4: This represents the IPv4 address of a user in the user 469 group. 471 IPv6: This represents the IPv6 address of a user in the user 472 group. 474 Range-ipv4-address: This represents the IPv4 address range of a 475 user in the user group. 477 Range-ipv6-address: This represents the IPv6 address range of a 478 user in the user group. 480 +--rw user-group* [name] 481 +--rw name string 482 +--rw (match-type) 483 +--:(exact-match-ipv4) 484 | +--rw ipv4? inet:ipv4-address 485 +--:(exact-match-ipv6) 486 | +--rw ipv6? inet:ipv6-address 487 +--:(range-match-ipv4) 488 | +--rw range-ipv4-address 489 | +--rw start-ipv4-address inet:ipv4-address 490 | +--rw end-ipv4-address inet:ipv4-address 491 +--:(range-match-ipv6) 492 +--rw range-ipv6-address* 493 +--rw start-ipv6-address inet:ipv6-address 494 +--rw end-ipv6-address inet:ipv6-address 496 Figure 9: User Group YANG Data Tree 498 5.2. Device Group 500 This object represents a Device-Group. Figure 10 shows the YANG tree 501 of the Device-group object. The Device-Group object SHALL have the 502 following information: 504 Name: This field identifies the name of this object. 506 IPv4: This represents the IPv4 address of a device in the device 507 group. 509 IPv6: This represents the IPv6 address of a device in the device 510 group. 512 Range-ipv4-address: This represents the IPv4 address range of a 513 device in the device group. 515 Range-ipv6-address: This represents the IPv6 address range of a 516 device in the device group. 518 Protocol: This represents the communication protocols used by 519 the devices. The protocols are "SSH", "FTP", "SMTP", 520 "HTTP", "HTTPS", and etc. 522 +--rw device-group* [name] 523 +--rw name string 524 +--rw (match-type) 525 | +--:(exact-match-ipv4) 526 | | +--rw ipv4? inet:ipv4-address 527 | +--:(exact-match-ipv6) 528 | | +--rw ipv6? inet:ipv6-address 529 | +--:(range-match-ipv4) 530 | | +--rw range-ipv4-address* 531 | | | +--rw start-ipv4-address inet:ipv4-address 532 | | | +--rw end-ipv4-address inet:ipv4-address 533 | +--:(range-match-ipv6) 534 | | +--rw range-ipv6-address* 535 | | | +--rw start-ipv6-address inet:ipv6-address 536 | | | +--rw end-ipv6-address inet:ipv6-address 537 +--rw protocol identityref 539 Figure 10: Device Group YANG Data Tree 541 5.3. Location Group 543 This object represents a location group based on either tag or other 544 information. Figure 11 shows the YANG tree of the Location-Group 545 object. The Location-Group object SHALL have the following 546 information: 548 Name: This field identifies the name of this object. 550 Geo-ip-ipv4: This field represents the IPv4 Geo-ip address of a 551 location [RFC8805]. 553 Geo-ip-ipv6: This field represents the IPv6 Geo-ip address of a 554 location [RFC8805]. 556 Continent: This field represents the continent where the 557 location group member is located. 559 +--rw location-group* [name] 560 +--rw name string 561 +--rw geo-ip-ipv4 inet:ipv4-address 562 +--rw geo-ip-ipv6 inet:ipv6-address 563 +--rw continent? identityref 565 Figure 11: Location Group YANG Data Tree 567 6. Information Model for Threat Prevention 569 The threat prevention plays an important part in the overall security 570 posture by reducing the attack surfaces. This information could come 571 from various threat feeds (i.e., sources for obtaining the threat 572 information). There are multiple managed objects that constitute 573 this category. This section lists these objects and relationship 574 among them. Figure 13 shows the YANG tree of a Threat-Prevention 575 object. 577 +-------------------+ 578 | Threat Prevention | 579 +---------+---------+ 580 ^ 581 | 582 +---------+---------+ 583 0..n | 0..n | 584 +------+------+ +--------+--------+ 585 | Threat-feed | | payload-content | 586 +-------------+ +-----------------+ 588 Figure 12: Threat Prevention Diagram 590 +--rw threat-prevention 591 +--rw threat-feed-list* [name] 592 ... 593 +--rw payload-content* [name] 594 ... 596 Figure 13: Threat Prevention YANG Data Tree 598 6.1. Threat Feed 600 This object represents a threat feed which provides the signatures of 601 malicious activities. Figure 14 shows the YANG tree of a Threat- 602 feed-list. The Threat-Feed object SHALL have the following 603 information: 605 Name: This field identifies the name of this object. 607 Server-ipv4: This represents the IPv4 server address of the feed 608 provider, which may be either an external or local server. 610 Server-ipv6: This represents the IPv6 server address of the feed 611 provider, which may be either an external or local server. 613 Description: This is the description of the threat feed. The 614 description should have the clear indication of the 615 security attack such as attack type (e.g., APT) and file 616 types used (e.g., executable malware). 618 Threat-file-types: This field identifies the information about 619 the file types identified and reported by the threat-feed. 621 Signatures: This field contains the threat signatures of 622 malicious programs or activities provided by the threat- 623 feed. The examples of signature types are "YARA", 624 "SURICATA", and "SNORT" [YARA][SURICATA][SNORT]. 626 It is assumed that the I2NSF User obtains the threat signatures 627 (i.e., threat content patterns) from a threat-feed server (i.e., feed 628 provider), which is a server providing threat signatures. With the 629 obtained threat signatures, the I2NSF User can deliver them to the 630 Security Controller. The retrieval of the threat signatures by the 631 I2NSF User is out of scope in this document. 633 +--rw threat-prevention 634 +--rw threat-feed-list* [name] 635 +--rw name identityref 636 +--rw server-ipv4? inet:ipv4-address 637 +--rw server-ipv6? inet:ipv6-address 638 +--rw description? string 639 +--rw threat-file-types* identityref 640 +--rw signatures* identityref 642 Figure 14: Threat Feed YANG Data Tree 644 6.2. Payload Content 646 This object represents a custom list created for the purpose of 647 defining an exception to threat feeds. Figure 15 shows the YANG tree 648 of a Payload-content list. The Payload-Content object SHALL have the 649 following information: 651 Name: This field identifies the name of this object. For 652 example, the name "backdoor" indicates the payload content 653 is related to a backdoor attack. 655 Description: This represents the description of how the payload 656 content is related to a security attack. 658 Content: This contains the payload contents, which are involed 659 in a security attack, such as strings. 661 +--rw payload-content* [name] 662 +--rw name string 663 +--rw description string 664 +--rw content* string 666 Figure 15: Payload Content in YANG Data Tree 668 7. Network Configuration Access Control Model (NACM) for I2NSF 669 Consumer-Facing Interface 671 Network Configuration Access Control Model (NACM) provides a user 672 group with an access control with the following features [RFC8341]: 674 o Independent control of action, data, and notification access is 675 provided. 677 o A simple and familiar set of datastore permissions is used. 679 o Support for YANG security tagging allows default security modes to 680 automatically exclude sensitive data. 682 o Separate default access modes for read, write, and execute 683 permissions are provided. 685 o Access control rules are applied to configurable groups of users. 687 The data model of the I2NSF Consumer-Facing Interface utilizes the 688 NACM's mechanisms to manage the access control on the I2NSF Consumer- 689 Facing Interface. The NACM with the above features can be used to 690 set up the access control rules of a user group in the I2NSF 691 Consumer-Facing Interface. 693 Figure 16 shows part of the NACM module to enable the access control 694 of a user group for the I2NSF Consumer-Facing Interface. To use the 695 NACM, a user needs to configure either a NETCONF server [RFC6241] or 696 a RESTCONF server [RFC8040] to enable the NACM module. Then, the 697 user can simply use an account of root or admin user for the access 698 control for the module of the I2NSF Consumer-Facing Interface (i.e., 699 ietf-i2nsf-cfi-policy). An XML example to configure the access 700 control a user group for the I2NSF Consumer-Facing Interface can be 701 seen in Section 10. 703 list rule { 704 key "name"; 705 ordered-by user; 706 leaf name { 707 type string { 708 length "1..max"; 709 } 710 description 711 "Arbitrary name assigned to the rule."; 712 } 714 leaf module-name { 715 type union { 716 type matchall-string-type; 717 type string; 718 } 719 default "*"; 720 description 721 "Name of the module associated with this rule." 722 } 724 leaf access-operations { 725 type union { 726 type matchall-string-type; 727 type access-operations-type; 728 } 729 default "*"; 730 description 731 "Access operations associated with this rule." 732 } 734 leaf action { 735 type action-type; 736 mandatory true; 737 description 738 "The access control action associated with the 739 rule. If a rule is determined to match a 740 particular request, then this object is used 741 to determine whether to permit or deny the 742 request."; 743 } 745 Figure 16: A Part of the NACM YANG Data Model 747 8. YANG Data Model of Consumer-Facing Interface 749 The main objective of this data model is to provide both an 750 information model and the corresponding YANG data model of I2NSF 751 Consumer-Facing Interface. This interface can be used to deliver 752 control and management messages between an I2NSF User and Security 753 Controller for the I2NSF User's high-level security policies. 755 The semantics of the data model must be aligned with the information 756 model of the Consumer-Facing Interface. The transformation of the 757 information model is performed so that this YANG data model can 758 facilitate the efficient delivery of the control or management 759 messages. 761 This data model is designed to support the I2NSF framework that can 762 be extended according to the security needs. In other words, the 763 model design is independent of the content and meaning of specific 764 policies as well as the implementation approach. 766 With the YANG data model of I2NSF Consumer-Facing Interface, this 767 document suggests use cases for security policy rules such as time- 768 based firewall, VoIP/VoLTE security service, and DDoS-attack 769 mitigation in Section 9. 771 8.1. YANG Module of Consumer-Facing Interface 773 This section describes a YANG module of Consumer-Facing Interface. 774 This YANG module imports from [RFC6991] and uses the typedef of time 775 in [I-D.ietf-netmod-rfc6991-bis]. It makes references to [RFC0854][R 776 FC0913][RFC0959][RFC1081][RFC1631][RFC2616][RFC2818][RFC4250][RFC5321 777 ]. 779 file "ietf-i2nsf-cfi-policy@2020-08-28.yang" 780 module ietf-i2nsf-cfi-policy { 781 yang-version 1.1; 782 namespace 783 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; 784 prefix cfi-policy; 786 import ietf-inet-types{ 787 prefix inet; 788 } 790 import ietf-yang-types{ 791 prefix yang; 792 } 794 import ietf-netconf-acm { 795 prefix nacm; 796 } 798 organization 799 "IETF I2NSF (Interface to Network Security Functions) 800 Working Group"; 802 contact 803 "WG Web: 804 WG List: 806 Editor: Jaehoon Paul Jeong 807 809 Editor: Patrick Lingga 810 "; 812 description 813 "This module is a YANG module for Consumer-Facing Interface. 815 Copyright (c) 2020 IETF Trust and the persons identified as 816 authors of the code. All rights reserved. 818 Redistribution and use in source and binary forms, with or 819 without modification, is permitted pursuant to, and subject 820 to the license terms contained in, the Simplified BSD License 821 set forth in Section 4.c of the IETF Trust's Legal Provisions 822 Relating to IETF Documents 823 http://trustee.ietf.org/license-info). 825 This version of this YANG module is part of RFC XXXX; see 826 the RFC itself for full legal notices."; 828 revision "2020-08-28"{ 829 description "Initial revision."; 830 reference 831 "RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model"; 832 } 834 identity malware-file-type { 835 description 836 "Base identity for malware file types."; 837 } 839 identity executable-file { 840 base malware-file-type; 841 description 842 "Identity for executable file types."; 844 } 846 identity doc-file { 847 base malware-file-type; 848 description 849 "Identity for Microsoft document file types."; 850 } 852 identity html-app-file { 853 base malware-file-type; 854 description 855 "Identity for html application file types."; 856 } 858 identity javascript-file { 859 base malware-file-type; 860 description 861 "Identity for Javascript file types."; 862 } 864 identity pdf-file { 865 base malware-file-type; 866 description 867 "Identity for pdf file types."; 868 } 870 identity dll-file { 871 base malware-file-type; 872 description 873 "Identity for dll file types."; 874 } 876 identity msi-file { 877 base malware-file-type; 878 description 879 "Identity for Microsoft installer file types."; 880 } 882 identity security-event-type { 883 description 884 "Base identity for security event types."; 885 } 887 identity ddos { 888 base security-event-type; 889 description 890 "Identity for DDoS event types."; 891 } 892 identity spyware { 893 base security-event-type; 894 description 895 "Identity for spyware event types."; 896 } 898 identity trojan { 899 base security-event-type; 900 description 901 "Identity for Trojan infection event types."; 902 } 904 identity ransomware { 905 base security-event-type; 906 description 907 "Identity for ransomware infection event types."; 908 } 910 identity i2nsf-ipsec { 911 description 912 "Base identity for IPsec method types."; 913 reference 914 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined 915 Networking (SDN)-based IPsec Flow Protection - IPsec method 916 types can be selected."; 917 } 919 identity ipsec-ike { 920 base i2nsf-ipsec; 921 description 922 "Identity for ipsec-ike."; 923 reference 924 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined 925 Networking (SDN)-based IPsec Flow Protection - IPsec method 926 type with IKE is selected."; 927 } 929 identity ipsec-ikeless { 930 base i2nsf-ipsec; 931 description 932 "Identity for ipsec-ikeless."; 933 reference 934 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined 935 Networking (SDN)-based IPsec Flow Protection - IPsec method 936 type without IKE is selected."; 937 } 939 identity continent { 940 description 941 "Base Identity for continent types."; 942 } 944 identity africa { 945 base continent; 946 description 947 "Identity for Africa."; 948 } 950 identity asia { 951 base continent; 952 description 953 "Identity for Asia."; 954 } 956 identity europe { 957 base continent; 958 description 959 "Identity for Europe."; 960 } 962 identity north-america { 963 base continent; 964 description 965 "Identity for North America."; 966 } 968 identity south-america { 969 base continent; 970 description 971 "Identity for South America."; 972 } 974 identity oceania { 975 base continent; 976 description 977 "Identity for Oceania"; 978 } 980 identity protocol-type { 981 description 982 "This identity represents the protocol types."; 983 } 985 identity ftp { 986 base protocol-type; 987 description 988 "The identity for ftp protocol."; 989 reference 990 "RFC 959: File Transfer Protocol (FTP)"; 991 } 993 identity ssh { 994 base protocol-type; 995 description 996 "The identity for ssh protocol."; 997 reference 998 "RFC 4250: The Secure Shell (SSH) Protocol"; 999 } 1001 identity telnet { 1002 base protocol-type; 1003 description 1004 "The identity for telnet."; 1005 reference 1006 "RFC 854: Telnet Protocol"; 1007 } 1009 identity smtp { 1010 base protocol-type; 1011 description 1012 "The identity for smtp."; 1013 reference 1014 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1015 } 1017 identity sftp { 1018 base protocol-type; 1019 description 1020 "The identity for sftp."; 1021 reference 1022 "RFC 913: Simple File Transfer Protocol (SFTP)"; 1023 } 1025 identity http { 1026 base protocol-type; 1027 description 1028 "The identity for http."; 1029 reference 1030 "RFC 2616: Hypertext Transfer Protocol (HTTP)"; 1031 } 1033 identity https { 1034 base protocol-type; 1035 description 1036 "The identity for https."; 1037 reference 1038 "RFC 2818: HTTP over TLS (HTTPS)"; 1039 } 1041 identity pop3 { 1042 base protocol-type; 1043 description 1044 "The identity for pop3."; 1045 reference 1046 "RFC 1081: Post Office Protocol -Version 3 (POP3)"; 1047 } 1049 identity nat { 1050 base protocol-type; 1051 description 1052 "The identity for nat."; 1053 reference 1054 "RFC 1631: The IP Network Address Translator (NAT)"; 1055 } 1057 identity primary-action { 1058 description 1059 "This identity represents the primary actions, such as 1060 PASS, DROP, ALERT, RATE-LIMIT, and MIRROR."; 1061 } 1063 identity pass { 1064 base primary-action; 1065 description 1066 "The identity for pass."; 1067 } 1069 identity drop { 1070 base primary-action; 1071 description 1072 "The identity for drop."; 1073 } 1075 identity alert { 1076 base primary-action; 1077 description 1078 "The identity for alert."; 1079 } 1081 identity rate-limit { 1082 base primary-action; 1083 description 1084 "The identity for rate-limit."; 1085 } 1087 identity mirror { 1088 base primary-action; 1089 description 1090 "The identity for mirroring."; 1091 } 1093 identity secondary-action { 1094 description 1095 "This field identifies additional actions if a rule is 1096 matched. This could be one of 'LOG', 'SYSLOG', 1097 'SESSION-LOG', etc."; 1098 } 1100 identity log { 1101 base secondary-action; 1102 description 1103 "The identity for logging."; 1104 } 1106 identity syslog { 1107 base secondary-action; 1108 description 1109 "The identity for system logging."; 1110 } 1112 identity session-log { 1113 base secondary-action; 1114 description 1115 "The identity for session logging."; 1116 } 1118 identity signature-type { 1119 description 1120 "This represents the base identity for signature types."; 1121 } 1123 identity signature-yara { 1124 base signature-type; 1125 description 1126 "This represents the YARA signatures."; 1127 reference 1128 "YARA: YARA signatures are explained."; 1129 } 1131 identity signature-snort { 1132 base signature-type; 1133 description 1134 "This represents the SNORT signatures."; 1135 reference 1136 "SNORT: SNORT signatures are explained."; 1137 } 1139 identity signature-suricata { 1140 base signature-type; 1141 description 1142 "This represents the SURICATA signatures."; 1143 reference 1144 "SURICATA: SURICATA signatures are explained."; 1145 } 1147 identity threat-feed-type { 1148 description 1149 "This represents the base identity for threat-feed."; 1150 } 1152 identity day { 1153 description 1154 "This represents the base for days."; 1155 } 1157 identity monday { 1158 base day; 1159 description 1160 "This represents Monday."; 1161 } 1163 identity tuesday { 1164 base day; 1165 description 1166 "This represents Tuesday."; 1167 } 1169 identity wednesday { 1170 base day; 1171 description 1172 "This represents Wednesday."; 1173 } 1175 identity thursday { 1176 base day; 1177 description 1178 "This represents Thursday."; 1179 } 1180 identity friday { 1181 base day; 1182 description 1183 "This represents Friday."; 1184 } 1186 identity saturday { 1187 base day; 1188 description 1189 "This represents Saturday."; 1190 } 1192 identity sunday { 1193 base day; 1194 description 1195 "This represents Sunday."; 1196 } 1198 /* 1199 * Typedefs 1200 */ 1201 typedef time { 1202 type string { 1203 pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' 1204 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 1205 } 1206 description 1207 "The time type represents an instance of time of zero-duration 1208 that recurs every day."; 1209 reference 1210 "draft-ietf-netmod-rfc6991-bis-04: Common YANG Data Types - 1211 typedef time is used."; 1212 } 1214 /* 1215 * Groupings 1216 */ 1218 grouping ipv4-list { 1219 description 1220 "Grouping for an IPv4 address list."; 1221 leaf-list ipv4 { 1222 type inet:ipv4-address; 1223 description 1224 "This is the entry for an IPv4 address list."; 1225 } 1226 } 1227 grouping ipv6-list { 1228 description 1229 "Grouping for an IPv6 address list."; 1230 leaf-list ipv6 { 1231 type inet:ipv6-address; 1232 description 1233 "This is the entry for an IPv6 address list."; 1234 } 1235 } 1237 grouping ipv4 { 1238 description 1239 "Grouping for an IPv4 address."; 1240 leaf ipv4 { 1241 type inet:ipv4-address; 1242 description 1243 "This is the entry for an IPv4 address."; 1244 } 1245 } 1247 grouping ipv6 { 1248 description 1249 "Grouping for an IPv6 address."; 1250 leaf ipv6 { 1251 type inet:ipv6-address; 1252 description 1253 "This is the entry for an IPv6 address."; 1254 } 1255 } 1257 grouping ip-address-info { 1258 description 1259 "There are two types to configure a security policy 1260 for an IPv4 address, such as exact match and range match."; 1261 choice match-type { 1262 description 1263 "User can choose between 'exact match' and 'range match'."; 1264 case exact-match-ipv4 { 1265 uses ipv4; 1266 description 1267 "Exact ip-address match for IPv4 addresses"; 1268 } 1269 case exact-match-ipv6 { 1270 uses ipv6; 1271 description 1272 "Exact ip-address match for IPv6 addresses"; 1273 } 1274 case range-match-ipv4 { 1275 container range-ipv4-address { 1276 leaf start-ipv4-address { 1277 type inet:ipv4-address; 1278 mandatory true; 1279 description 1280 "A start IPv4 address for a range match."; 1281 } 1282 leaf end-ipv4-address { 1283 type inet:ipv4-address; 1284 mandatory true; 1285 description 1286 "An end IPv4 address for a range match."; 1287 } 1288 description 1289 "A range match for IPv4 addresses is provided. Note that the 1290 start IPv4 address must be lower than the end IPv4 address."; 1291 } 1292 } 1293 case range-match-ipv6 { 1294 container range-ipv6-address { 1295 leaf start-ipv6-address { 1296 type inet:ipv6-address; 1297 mandatory true; 1298 description 1299 "A start IPv6 address for a range match."; 1300 } 1301 leaf end-ipv6-address { 1302 type inet:ipv6-address; 1303 mandatory true; 1304 description 1305 "An end IPv6 address for a range match."; 1306 } 1307 description 1308 "A range match for IPv6 addresses is provided. Note that the 1309 start IPv6 address must be lower than the end IPv4 address."; 1310 } 1311 } 1312 } 1313 } 1315 grouping ipsec-based-method { 1316 description 1317 "This represents the ipsec-based method."; 1318 list ipsec-method { 1319 key "method"; 1320 description 1321 "This represents the list of IPsec method types."; 1322 leaf method { 1323 type identityref { 1324 base i2nsf-ipsec; 1325 } 1326 description 1327 "This represents IPsec IKE and IPsec IKEless cases. If this 1328 is not set, it cannot support IPsec IKE or IPsec IKEless."; 1329 reference 1330 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: 1331 Software-Defined Networking (SDN)-based IPsec Flow Protection 1332 - IPsec method types can be selected."; 1333 } 1334 } 1335 } 1337 grouping user-group { 1338 description 1339 "The grouping for user-group entities, and contains information 1340 such as name & ip-address."; 1341 leaf name { 1342 type string; 1343 description 1344 "This represents the name of a user-group. A user-group name 1345 is used to map a user-group's name (e.g., employees) to an IP 1346 address. It is dependent on implementation."; 1347 } 1348 uses ip-address-info{ 1349 refine match-type{ 1350 mandatory true; 1351 } 1352 description 1353 "This represent the IP addresses of a user-group."; 1354 } 1355 } 1357 grouping device-group { 1358 description 1359 "This group represents device group information such as ip-address 1360 protocol."; 1361 leaf name { 1362 type string; 1363 description 1364 "This represents the name of a device-group."; 1365 } 1366 uses ip-address-info{ 1367 refine match-type{ 1368 mandatory true; 1369 } 1370 } 1371 leaf-list protocol { 1372 type identityref { 1373 base protocol-type; 1374 } 1375 description 1376 "This represents the communication protocols of devices. If this 1377 is not set, it cannot support the appropriate protocol"; 1378 } 1379 } 1381 grouping location-group { 1382 description 1383 "This group represents location-group information such as geo-ip 1384 and continent."; 1385 leaf name { 1386 type string; 1387 description 1388 "This represents the name of a location."; 1389 } 1390 list geo-ip-ipv4 { 1391 key "ipv4-address"; 1392 description 1393 "This represents the list of IPv4 addresses based on a location."; 1394 leaf ipv4-address{ 1395 type inet:ipv4-address; 1396 description 1397 "This represents an IPv4 geo-ip address of a location."; 1398 } 1399 leaf ipv4-prefix{ 1400 type inet:ipv4-prefix; 1401 description 1402 "This represents the prefix for the IPv4 addresses."; 1403 } 1404 } 1405 list geo-ip-ipv6 { 1406 key "ipv6-address"; 1407 description 1408 "This represents the list of IPv6 addresses based on a location."; 1409 leaf ipv6-address{ 1410 type inet:ipv6-address; 1411 description 1412 "This represents an IPv6 geo-ip address of a location."; 1413 } 1414 leaf ipv6-prefix{ 1415 type inet:ipv6-prefix; 1416 description 1417 "This represents the prefix for the IPv6 addresses."; 1418 } 1420 } 1421 leaf continent { 1422 type identityref { 1423 base continent; 1424 } 1425 default asia; 1426 description 1427 "location-group has geo-ip addresses of the corresponding 1428 continent."; 1429 } 1430 } 1432 grouping threat-feed-info { 1433 description 1434 "This is the grouping for the threat-feed-list"; 1435 leaf threat-type { 1436 type identityref { 1437 base threat-feed-type; 1438 } 1439 description 1440 "This represents the type of the threat-feed."; 1441 } 1442 leaf server-ipv4 { 1443 type inet:ipv4-address; 1444 description 1445 "The IPv4 address for the threat-feed server."; 1446 } 1447 leaf server-ipv6 { 1448 type inet:ipv6-address; 1449 description 1450 "The IPv6 address for the threat-feed server."; 1451 } 1452 leaf description { 1453 type string; 1454 description 1455 "This represents the descriptions of a threat-feed. The 1456 description should include information, such as type, threat, 1457 method, and file type. Structured Threat Information Expression 1458 (STIX) can be used for description of a threat [STIX]."; 1459 } 1460 } 1462 grouping payload-string { 1463 description 1464 "The grouping for payload-string content. It contains information 1465 such as name and string content."; 1466 leaf description { 1467 type string; 1468 description 1469 "This represents the description of a payload. If this is not 1470 set, it cannot support the description of how the payload content 1471 is related to a security attack."; 1472 } 1473 leaf-list content { 1474 type string; 1475 description 1476 "This represents the string of the payload contents. This content 1477 leaf-list contains the payload of a packet to analyze a threat. 1478 Due to the types of threats, the type of the content is defined 1479 as a string to accommodate any kind of a payload type such as 1480 HTTP, HTTPS, and SIP. If this is not set, it cannot support the 1481 payload contents involved in a security attack as a string."; 1482 } 1483 } 1485 list i2nsf-cfi-policy { 1486 key "policy-name"; 1487 description 1488 "This is a security policy list. Each policy in the list contains 1489 a list of security policy rules, and is a policy instance to have 1490 the information of where and when a policy needs to be applied."; 1491 leaf policy-name { 1492 type string; 1493 description 1494 "The name which identifies the policy."; 1495 } 1496 container rules{ 1497 description 1498 "This container has rules."; 1499 nacm:default-deny-write; 1500 list rule { 1501 key "rule-name"; 1502 ordered-by user; 1503 leaf rule-name { 1504 type string; 1505 description 1506 "This represents the name for a rule."; 1507 } 1508 description 1509 "There can be a single or multiple number of rules."; 1511 container event { 1512 description 1513 "This represents an event (i.e., a security event), for which 1514 a security rule is made."; 1515 leaf security-event { 1516 type identityref { 1517 base security-event-type; 1518 } 1519 description 1520 "This contains the description of a security event. If this 1521 is not set, it cannot support what security event will be 1522 enforced."; 1523 } 1525 container time-information { 1526 description 1527 "The time information when a security policy rule should be 1528 applied."; 1529 leaf start-date-time { 1530 type yang:date-and-time; 1531 description 1532 "This is the start date and time for a security policy 1533 rule."; 1534 } 1535 leaf end-date-time { 1536 type yang:date-and-time; 1537 description 1538 "This is the end date and time for a policy rule. The 1539 policy rule will stop working after the specified 1540 end-date-time."; 1541 } 1542 container period{ 1543 when 1544 "../../frequency!='only-once'"; 1545 description 1546 "This represents the repetition time. In the case where 1547 the frequency is weekly, the days can be set."; 1548 leaf start-time { 1549 type time; 1550 description 1551 "This is a period's start time for an event."; 1552 reference 1553 "RFC 6991-bis: Common YANG Data Types - The time type 1554 represents an instance of time of zero-duration that 1555 recurs every day. When RFC 6991-bis becomes an RFC, 1556 time must be replaced with yang:time."; 1557 } 1558 leaf end-time { 1559 type time; 1560 description 1561 "This is a period's end time for an event."; 1562 reference 1563 "RFC 6991-bis: Common YANG Data Types - The time type 1564 represents an instance of time of zero-duration that 1565 recurs every day. When RFC 6991-bis becomes an RFC, 1566 time must be replaced with yang:time."; 1567 } 1568 leaf-list day { 1569 when 1570 "../../../frequency='weekly'"; 1571 type identityref{ 1572 base day; 1573 } 1574 min-elements 1; 1575 description 1576 "This represents the repeated day of every week (e.g., 1577 Monday and Tuesday). More than one day can be 1578 specified."; 1579 } 1580 leaf-list date { 1581 when 1582 "../../../frequency='monthly'"; 1583 type int32{ 1584 range "1..31"; 1585 } 1586 min-elements 1; 1587 description 1588 "This represents the repeated date of every month. More 1589 than one date can be specified."; 1590 } 1591 leaf-list month { 1592 when 1593 "../../../frequency='yearly'"; 1594 type string{ 1595 pattern '\d{2}-\d{2}'; 1596 } 1597 min-elements 1; 1598 description 1599 "This represents the repeated date and month of every 1600 year. More than one can be specified. A pattern used 1601 here is Month and Date (MM-DD)."; 1602 } 1603 } 1604 } 1606 leaf frequency { 1607 type enumeration { 1608 enum only-once { 1609 description 1610 "This represents that the rule is immediately enforced 1611 only once and not repeated. The policy will 1612 continuously be active from the start-time to the 1613 end-time."; 1614 } 1615 enum daily { 1616 description 1617 "This represents that the rule is enforced on a daily 1618 basis. The policy will be repeated daily until the 1619 end-date."; 1620 } 1621 enum weekly { 1622 description 1623 "This represents that the rule is enforced on a weekly 1624 basis. The policy will be repeated weekly until the 1625 end-date. The repeated days can be specified."; 1626 } 1627 enum monthly { 1628 description 1629 "This represents that the rule is enforced on a monthly 1630 basis. The policy will be repeated monthly until the 1631 end-date."; 1632 } 1633 enum yearly { 1634 description 1635 "This represents that the rule is enforced on a yearly 1636 basis. The policy will be repeated yearly until the 1637 end-date."; 1638 } 1639 } 1640 default only-once; 1641 description 1642 "This represents how frequently the rule should be enforced."; 1643 } 1644 } 1646 container condition { 1647 description 1648 "Conditions for general security policies."; 1649 container firewall-condition { 1650 description 1651 "A general firewall condition."; 1652 leaf source { 1653 type leafref { 1654 path 1655 "/i2nsf-cfi-policy/endpoint-groups/user-group/name"; 1656 } 1657 description 1658 "This describes the path to the source."; 1659 } 1660 leaf-list destination { 1661 type leafref { 1662 path 1663 "/i2nsf-cfi-policy/endpoint-groups/user-group/name"; 1664 } 1665 description 1666 "This describes the paths to the destinations."; 1667 } 1668 } 1670 container ddos-condition { 1671 description 1672 "A condition for a DDoS attack."; 1673 leaf-list source { 1674 type leafref { 1675 path 1676 "/i2nsf-cfi-policy/endpoint-groups/device-group/name"; 1677 } 1678 description 1679 "This describes the paths to the sources."; 1680 } 1681 leaf-list destination { 1682 type leafref { 1683 path 1684 "/i2nsf-cfi-policy/endpoint-groups/device-group/name"; 1685 } 1686 description 1687 "This describes the paths to the destinations."; 1688 } 1689 container rate-limit { 1690 description 1691 "This describes the rate-limit."; 1692 leaf packet-threshold-per-second { 1693 type uint32; 1694 description 1695 "This is a trigger value for a rate limit for a 1696 DDoS-attack mitigation."; 1697 } 1698 } 1699 } 1701 container location-condition { 1702 description 1703 "A condition for a location-based connection"; 1704 leaf-list source { 1705 type leafref { 1706 path 1707 "/i2nsf-cfi-policy/endpoint-groups/location-group/name"; 1709 } 1710 description 1711 "This describes the paths to a location's sources."; 1712 } 1713 leaf-list destination { 1714 type leafref { 1715 path 1716 "/i2nsf-cfi-policy/endpoint-groups/location-group/name"; 1717 } 1718 description 1719 "This describes the paths to a location's destinations."; 1720 } 1721 } 1723 container custom-condition { 1724 description 1725 "A condition based on a packet's content."; 1726 leaf-list source { 1727 type leafref { 1728 path 1729 "/i2nsf-cfi-policy/threat-preventions/payload-content/name"; 1730 } 1731 description 1732 "This describes the paths to a packet content's sources."; 1733 } 1734 leaf destination { 1735 type leafref { 1736 path 1737 "/i2nsf-cfi-policy/threat-preventions/payload-content/name"; 1738 } 1739 description 1740 "This describes the path to a packet content's 1741 destination."; 1742 } 1743 } 1745 container threat-feed-condition { 1746 description 1747 "A condition based on the threat-feed information."; 1748 leaf-list source { 1749 type leafref { 1750 path 1751 "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name"; 1752 } 1753 description 1754 "This describes the paths to a threat-feed's sources."; 1755 } 1756 leaf destination { 1757 type leafref { 1758 path 1759 "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name"; 1760 } 1761 description 1762 "This describes the path to a threat-feed's destination."; 1763 } 1764 } 1765 } 1767 container actions { 1768 description 1769 "This is the action container."; 1770 leaf primary-action { 1771 type identityref { 1772 base primary-action; 1773 } 1774 description 1775 "This represent primary actions (e.g., PASS, DROP, ALERT, 1776 and MIRROR) to be applied to a condition. If this is not 1777 set, it cannot support the primary actions."; 1778 } 1779 leaf secondary-action { 1780 type identityref { 1781 base secondary-action; 1782 } 1783 description 1784 "This represents secondary actions (e.g., log and syslog) 1785 to be applied if they are needed. If this is not set, it 1786 cannot support the secondary actions."; 1787 } 1788 } 1790 container ipsec-method { 1791 description 1792 "This container represents the IPsec method such as IKE case 1793 and IKEless case."; 1794 leaf method { 1795 type identityref { 1796 base i2nsf-ipsec; 1797 } 1798 description 1799 "This represents the IPsec method type such as IKE case and 1800 IKEless case. If this is not set, it cannot support 1801 either IPsec IKE or IPsec IKEless."; 1802 reference 1803 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: 1804 Software-Defined Networking (SDN)-based IPsec Flow 1805 Protection - IPsec method types can be selected."; 1806 } 1807 } 1808 } 1809 } 1810 container endpoint-groups { 1811 description 1812 "A logical entity in a business environment, where a security 1813 policy is to be applied."; 1814 list user-group{ 1815 uses user-group; 1816 key "name"; 1817 description 1818 "This represents a user group."; 1819 } 1820 list device-group { 1821 key "name"; 1822 uses device-group; 1823 description 1824 "This represents a device group."; 1825 } 1826 list location-group{ 1827 key "name"; 1828 uses location-group; 1829 description 1830 "This represents a location group."; 1831 } 1832 } 1834 container threat-preventions { 1835 description 1836 "This describes the list of threat-preventions."; 1837 list threat-feed-list { 1838 key "name"; 1839 description 1840 "There can be a single or multiple number of threat-feeds."; 1841 leaf name { 1842 type string; 1843 description 1844 "This represents the name of the threat-feed."; 1845 } 1846 uses threat-feed-info; 1847 leaf-list threat-file-types { 1848 type identityref { 1849 base malware-file-type; 1850 } 1851 description 1852 "This contains a list of file types needed to be scanned for 1853 a security threat (e.g., virus)."; 1854 } 1855 leaf-list signatures { 1856 type identityref { 1857 base signature-type; 1858 } 1859 description 1860 "This contains a list of signatures or hashes of the threats."; 1861 } 1862 } 1863 list payload-content { 1864 key "name"; 1865 leaf name { 1866 type string; 1867 description 1868 "This represents the name of a packet's payload-content. It 1869 should give an idea of why a specific payload content is 1870 marked as a threat. For example, the name 'backdoor' 1871 indicates the payload content is related to a backdoor 1872 attack."; 1873 } 1874 description 1875 "This represents a payload-string group."; 1876 uses payload-string; 1877 } 1878 } 1879 } 1880 } 1881 1883 Figure 17: YANG for Consumer-Facing Interface 1885 9. XML Configuration Examples of High-Level Security Policy Rules 1887 This section shows XML configuration examples of high-level security 1888 policy rules that are delivered from the I2NSF User to the Security 1889 Controller over the Consumer-Facing Interface. The considered use 1890 cases are: Database registration, time-based firewall for web 1891 filtering, VoIP/VoLTE security service, and DDoS-attack mitigation. 1893 9.1. Database Registration: Information of Positions and Devices 1894 (Endpoint Group) 1896 If new endpoints are introduced to the network, it is necessary to 1897 first register their data to the database. For example, if new 1898 members are newly introduced in either of three different groups 1899 (i.e., user-group, device-group, and payload-group), each of them 1900 should be registered with information such as ip-addresses or 1901 protocols used by devices. 1903 Figure 18 shows an example XML representation of the registered 1904 information for the user-group and device-group with IPv4 addresses 1905 [RFC5737]. 1907 1908 1909 1910 1911 employees 1912 1913 192.0.2.11 1914 192.0.2.90 1915 1916 1917 1918 webservers 1919 1920 198.51.100.11 1921 198.51.100.20 1922 1923 cfi-policy:http 1924 cfi-policy:https 1925 1926 1927 1929 Figure 18: Registering User-group and Device-group Information with 1930 IPv4 Addresses 1932 Also, Figure 19 shows an example XML representation of the registered 1933 information for the user-group and device-group with IPv6 addresses 1934 [RFC3849]. 1936 1937 1938 1939 1940 employees 1941 1942 2001:DB8:0:1::11 1943 2001:DB8:0:1::90 1944 1945 1946 1947 webservers 1948 1949 2001:DB8:0:2::11 1950 2001:DB8:0:2::20 1951 1952 cfi-policy:http 1953 cfi-policy:https 1954 1955 1956 1958 Figure 19: Registering User-group and Device-group Information with 1959 IPv6 Addresses 1961 9.2. Scenario 1: Block SNS Access during Business Hours 1963 The first example scenario is to "block SNS access during office 1964 hours" using a time-based firewall policy. In this scenario, all 1965 users registered as "employees" in the user-group list are unable to 1966 access Social Networking Services (SNS) during the office hours 1967 (weekdays). The XML instance is described below: 1969 1970 1971 security_policy_for_blocking_sns123 1972 1973 1974 block_access_to_sns_during_office_hours 1975 1976 1977 2020-03-11T09:00:00.00Z 1978 2020-12-31T18:00:00.00Z 1979 1980 09:00:00Z 1981 18:00:00Z 1982 cfi-policy:monday 1983 cfi-policy:tuesday 1984 cfi-policy:wednesday 1985 cfi-policy:thursday 1986 cfi-policy:friday 1987 1988 1989 weekly 1990 1991 1992 1993 employees 1994 1995 1996 sns-websites 1997 1998 1999 2000 cfi-policy:drop 2001 2002 2003 2004 2006 Figure 20: An XML Example for Time-based Firewall 2008 Time-based-condition Firewall 2010 1. The policy name is "security_policy_for_blocking_sns". 2012 2. The rule name is "block_access_to_sns_during_office_hours". 2014 3. The Source is "employees". 2016 4. The destination target is "sns-websites". "sns-websites" is the 2017 key which represents the list containing the information, such as 2018 URL, about sns-websites. 2020 5. The action required is to "drop" any attempt to connect to 2021 websites related to Social networking. 2023 6. The IPsec method type used for nsf traffic steering is set to 2024 "ipsec-ike". 2026 9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a Company 2028 The second example scenario is to "block malicious VoIP/VoLTE packets 2029 coming to a company" using a VoIP policy. In this scenario, the 2030 calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that 2031 are classified as malicious are dropped. The IP addresses of the 2032 employees and malicious VOIP IDs should be blocked are stored in the 2033 database or datastore of the enterprise. Here and the rest of the 2034 cases assume that the security administrators or someone responsible 2035 for the existing and newly generated policies, are not aware of which 2036 and/or how many NSFs are needed to meet the security requirements. 2037 Figure 21 represents the XML document generated from YANG discussed 2038 in previous sections. Once a high-level seucurity policy is created 2039 by a security admin, it is delivered by the Consumer-Facing 2040 Interface, through RESTCONF server, to the security controller. The 2041 XML instance is described below: 2043 2044 2045 2046 security_policy_for_blocking_malicious_voip_packets 2047 2048 2049 2050 Block_malicious_voip_and_volte_packets 2051 2052 2053 malicious-id 2054 2055 2056 employees 2057 2058 2059 2060 cfi-policy:drop 2061 2062 2063 cfi-policy:ipsec-ikeless 2064 2065 2066 2067 2069 Figure 21: An XML Example for VoIP Security Service 2071 Custom-condition Firewall 2073 1. The policy name is 2074 "security_policy_for_blocking_malicious_voip_packets". 2076 2. The rule name is "Block_malicious_voip_and_volte_packets". 2078 3. The Source is "malicious-id". This can be a single ID or a list 2079 of IDs, depending on how the ID are stored in the database. The 2080 "malicious-id" is the key so that the security admin can read 2081 every stored malicious VOIP IDs that are named as "malicious-id". 2083 4. The destination target is "employees". "employees" is the key 2084 which represents the list containing information about employees, 2085 such as IP addresses. 2087 5. The action required is "drop" when any incoming packets are from 2088 "malicious-id". 2090 6. The IPsec method used for nsf traffic steering is set to "ipsec- 2091 ikeless". 2093 9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web 2094 Server 2096 The third example scenario is to "Mitigate HTTP and HTTPS flood 2097 attacks on a company web server" using a DDoS-attack mitigation 2098 policy. Here, the time information is not set because the service 2099 provided by the network should be maintained at all times. If the 2100 packets sent by any sources are more than the set threshold, then the 2101 admin can set the percentage of the packets to be dropped to safely 2102 maintain the service. In this scenario, the source is set as "any" 2103 to block any sources which send abnormal amount of packets. The 2104 destination is set as "web_server01". Once the rule is set and 2105 delivered and enforced to the nsfs by the securiy controller, the 2106 NSFs will monitor the incoming packet amounts and the destination to 2107 act according to the rule set. The XML instance is described below: 2109 2110 2111 security_policy_for_ddos_attacks 2112 2113 2114 100_packets_per_second 2115 2116 2117 webservers 2118 2119 100 2120 2121 2122 2123 2124 cfi-policy:drop 2125 2126 2127 cfi-policy:ipsec-ikeless 2128 2129 2130 2131 2133 Figure 22: An XML Example for DDoS-attack Mitigation 2135 DDoS-condition Firewall 2136 1. The policy name is "security_policy_for_ddos_attacks". 2138 2. The rule name is "100_packets_per_second". 2140 3. The destination target is "webservers". "webservers" is the key 2141 which represents the list containing information, such as IP 2142 addresses and ports, about web-servers. 2144 4. The rate limit exists to limit the incoming amount of packets per 2145 second. In this case the rate limit is "100" packets per second. 2146 This amount depends on the packet receiving capacity of the 2147 server devices. 2149 5. The Source is all sources which send abnormal amount of packets. 2151 6. The action required is to "drop" packet reception is more than 2152 100 packets per second. 2154 7. The IPsec method used for nsf traffic steering is set to "ipsec- 2155 ike". 2157 10. XML Configuration Example of a User Group's Access Control for 2158 I2NSF Consumer-Facing Interface 2160 This is an example for creating privileges for a group of users 2161 (i.e., a user group) to access and use the I2NSF Consumer-Facing 2162 Interface to create security policies via the interface. For the 2163 access control of the Consumer-Facing Interface, the NACM module can 2164 be used. Figure 23 shows an XML example the access control of a user 2165 group (named Example-Group) for I2NSF Consumer-Facing Interface A 2166 group called Example-Group can be created and configured with NACM 2167 for the Consumer-Facing Interface. For Example-Group, a rule list 2168 can created with the name of Example-Group-Rules. Example-Group- 2169 Rules has two rules of Example-Group-Rule1 and Example-Group-Rule2 as 2170 follows. For Example-Group-Rule1, the privilege of "Read" is allowed 2171 to Example-Group for the Consumer-Facing Interface. On the other 2172 hand, for Example-Group-Rule2, the privileges of "Create", "Update", 2173 and "Delete" are denied against Example-Group for the Consumer-Facing 2174 Interface. 2176 2177 2178 true 2179 2180 2181 Example-Group 2182 Alice 2183 Bob 2184 Eve 2185 2186 2187 2188 Example-Group-Rules 2189 Example-Group 2190 2191 Example-Group-Rule1 2192 read 2193 ietf-i2nsf-cfi-policy 2194 permit 2195 2196 2197 Example-Group-Rule2 2198 create update delete 2199 ietf-i2nsf-cfi-policy 2200 deny 2201 2202 2203 2205 Figure 23: An XML Example of a User Group's Access Control for I2NSF 2206 Consumer-Facing Interface 2208 The access control for the I2NSF Consumer-Facing Interface is as 2209 follows. 2211 1. The NACM is enabled. 2213 2. As a group name, Example-Group is specified. 2215 3. As members of the group, Alice, Bob, and Eve are specified. 2217 4. As a rule list name, Example-Group-Rules is specified for 2218 managing privileges of Example-Group's members. 2220 5. As the first rule name, Example-Group-Rule1 is specified. This 2221 rule is used to give read privilege to Example-Group's members 2222 for the module of the I2NSF Consumer-Facing Interface. 2224 6. As the second rule name, Example-Group-Rule2 is specified. This 2225 rule is used to deny create, update, and delete privileges 2226 against Example-Group's members for the module of the I2NSF 2227 Consumer-Facing Interface. 2229 11. IANA Considerations 2231 This document requests IANA to register the following URI in the 2232 "IETF XML Registry" [RFC3688]: 2234 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2235 Registrant Contact: The IESG. 2236 XML: N/A; the requested URI is an XML namespace. 2238 This document requests IANA to register the following YANG module in 2239 the "YANG Module Names" registry [RFC7950][RFC8525]. 2241 name: ietf-i2nsf-cfi-policy 2242 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2243 prefix: cfi-policy 2244 reference: RFC XXXX 2246 12. Security Considerations 2248 The data model for the I2NSF Consumer-Facing Interface is based on 2249 the I2NSF framework [RFC8329], so the same security considerations 2250 with the I2NSF framework should be included in this document. The 2251 data model needs a secure communication channel to protect the 2252 Consumer-Facing Interface between the I2NSF User and Security 2253 Controller. Also, the data model's management access control is 2254 based on Network Configuration Access Control Model(NACM) mechanisms 2255 [RFC8341]. 2257 13. Acknowledgments 2259 This work was supported by Institute of Information & Communications 2260 Technology Planning & Evaluation (IITP) grant funded by the Korea 2261 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 2262 Security Intelligence Technology Development for the Customized 2263 Security Service Provisioning). This work was supported in part by 2264 the IITP (2020-0-00395, Standard Development of Blockchain based 2265 Network Management Automation Technology). 2267 14. Contributors 2269 This document is made by the group effort of I2NSF working group. 2270 Many people actively contributed to this document, such as Mahdi F. 2271 Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their 2272 contributions. 2274 The following are co-authors of this document: 2276 Patrick Lingga 2277 Department of Electronic, Electrical and Computer Engineering 2278 Sungkyunkwan University 2279 2066 Seo-ro Jangan-gu 2280 Suwon, Gyeonggi-do 16419 2281 Republic of Korea 2283 EMail: patricklink@skku.edu 2285 Hyoungshick Kim 2286 Department of Computer Science and Engineering 2287 Sungkyunkwan University 2288 2066 Seo-ro Jangan-gu 2289 Suwon, Gyeonggi-do 16419 2290 Republic of Korea 2292 EMail: hyoung@skku.edu 2294 Eunsoo Kim 2295 Department of Electronic, Electrical and Computer Engineering 2296 Sungkyunkwan University 2297 2066 Seo-ro Jangan-gu 2298 Suwon, Gyeonggi-do 16419 2299 Republic of Korea 2301 EMail: eskim86@skku.edu 2303 Seungjin Lee 2304 Department of Electronic, Electrical and Computer Engineering 2305 Sungkyunkwan University 2306 2066 Seo-ro Jangan-gu 2307 Suwon, Gyeonggi-do 16419 2308 Republic of Korea 2310 EMail: jine33@skku.edu 2311 Jinyong Tim Kim 2312 Department of Electronic, Electrical and Computer Engineering 2313 Sungkyunkwan University 2314 2066 Seo-ro Jangan-gu 2315 Suwon, Gyeonggi-do 16419 2316 Republic of Korea 2318 EMail: timkim@skku.edu 2320 Anil Lohiya 2321 Juniper Networks 2322 1133 Innovation Way 2323 Sunnyvale, CA 94089 2324 US 2326 EMail: alohiya@juniper.net 2328 Dave Qi 2329 Bloomberg 2330 731 Lexington Avenue 2331 New York, NY 10022 2332 US 2334 EMail: DQI@bloomberg.net 2336 Nabil Bitar 2337 Nokia 2338 755 Ravendale Drive 2339 Mountain View, CA 94043 2340 US 2342 EMail: nabil.bitar@nokia.com 2344 Senad Palislamovic 2345 Nokia 2346 755 Ravendale Drive 2347 Mountain View, CA 94043 2348 US 2350 EMail: senad.palislamovic@nokia.com 2352 Liang Xia 2353 Huawei 2354 101 Software Avenue 2355 Nanjing, Jiangsu 210012 2356 China 2358 EMail: Frank.Xialiang@huawei.com 2360 15. References 2362 15.1. Normative References 2364 [I-D.ietf-netmod-rfc6991-bis] 2365 Schoenwaelder, J., "Common YANG Data Types", draft-ietf- 2366 netmod-rfc6991-bis-04 (work in progress), July 2020. 2368 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 2369 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 2370 1983, . 2372 [RFC0913] Lottor, M., "Simple File Transfer Protocol", RFC 913, 2373 DOI 10.17487/RFC0913, September 1984, 2374 . 2376 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2377 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 2378 . 2380 [RFC1081] Rose, M., "Post Office Protocol: Version 3", RFC 1081, 2381 DOI 10.17487/RFC1081, November 1988, 2382 . 2384 [RFC1631] Egevang, K. and P. Francis, "The IP Network Address 2385 Translator (NAT)", RFC 1631, DOI 10.17487/RFC1631, May 2386 1994, . 2388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2389 Requirement Levels", BCP 14, RFC 2119, 2390 DOI 10.17487/RFC2119, March 1997, 2391 . 2393 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2394 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2395 Transfer Protocol -- HTTP/1.1", RFC 2616, 2396 DOI 10.17487/RFC2616, June 1999, 2397 . 2399 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2400 DOI 10.17487/RFC2818, May 2000, 2401 . 2403 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2404 Information Models and Data Models", RFC 3444, 2405 DOI 10.17487/RFC3444, January 2003, 2406 . 2408 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2409 DOI 10.17487/RFC3688, January 2004, 2410 . 2412 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 2413 Reserved for Documentation", RFC 3849, 2414 DOI 10.17487/RFC3849, July 2004, 2415 . 2417 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 2418 Protocol Assigned Numbers", RFC 4250, 2419 DOI 10.17487/RFC4250, January 2006, 2420 . 2422 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2423 DOI 10.17487/RFC5321, October 2008, 2424 . 2426 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 2427 Reserved for Documentation", RFC 5737, 2428 DOI 10.17487/RFC5737, January 2010, 2429 . 2431 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2432 the Network Configuration Protocol (NETCONF)", RFC 6020, 2433 DOI 10.17487/RFC6020, October 2010, 2434 . 2436 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2437 and A. Bierman, Ed., "Network Configuration Protocol 2438 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2439 . 2441 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2442 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2443 . 2445 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2446 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2447 . 2449 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2450 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2451 . 2453 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2454 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2455 May 2017, . 2457 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2458 and J. Jeong, "Interface to Network Security Functions 2459 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2460 DOI 10.17487/RFC8192, July 2017, 2461 . 2463 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2464 Kumar, "Framework for Interface to Network Security 2465 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2466 . 2468 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2469 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2470 . 2472 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2473 Access Control Model", STD 91, RFC 8341, 2474 DOI 10.17487/RFC8341, March 2018, 2475 . 2477 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2478 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2479 DOI 10.17487/RFC8407, October 2018, 2480 . 2482 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 2483 and R. Wilton, "YANG Library", RFC 8525, 2484 DOI 10.17487/RFC8525, March 2019, 2485 . 2487 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 2488 Kumari, "A Format for Self-Published IP Geolocation 2489 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 2490 . 2492 15.2. Informative References 2494 [I-D.ietf-i2nsf-capability] 2495 Xia, L., Strassner, J., Basile, C., and D. Lopez, 2496 "Information Model of NSFs Capabilities", draft-ietf- 2497 i2nsf-capability-05 (work in progress), April 2019. 2499 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] 2500 Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia, 2501 "Software-Defined Networking (SDN)-based IPsec Flow 2502 Protection", draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 2503 (work in progress), June 2020. 2505 [SNORT] Roesch, M., Green, C., and B. Caswell, "SNORT", SNORT 2506 Documents https://www.snort.org/#documents, August 2020. 2508 [STIX] Jordan, B., Piazza, R., and T. Darley, "Structured Threat 2509 Information Expression (STIX)", STIX Version 2.1: 2510 Committee Specification 01 https://docs.oasis- 2511 open.org/cti/stix/v2.1/stix-v2.1.pdf, March 2020. 2513 [SURICATA] 2514 Julien, V. and , "SURICATA", SURICATA Documents 2515 https://suricata-ids.org/docs/, August 2020. 2517 [YARA] Alvarez, V., Bengen, H., Metz, J., Buehlmann, S., and W. 2518 Shields, "YARA", YARA 2519 Documents https://yara.readthedocs.io/en/v3.5.0/, August 2520 2020. 2522 Authors' Addresses 2524 Jaehoon Paul Jeong (editor) 2525 Department of Computer Science and Engineering 2526 Sungkyunkwan University 2527 2066 Seobu-Ro, Jangan-Gu 2528 Suwon, Gyeonggi-Do 16419 2529 Republic of Korea 2531 Phone: +82 31 299 4957 2532 Fax: +82 31 290 7996 2533 EMail: pauljeong@skku.edu 2534 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2535 Chaehong Chung 2536 Department of Electronic, Electrical and Computer Engineering 2537 Sungkyunkwan University 2538 2066 Seobu-Ro, Jangan-Gu 2539 Suwon, Gyeonggi-Do 16419 2540 Republic of Korea 2542 Phone: +82 31 299 4957 2543 EMail: darkhong@skku.edu 2545 Tae-Jin Ahn 2546 Korea Telecom 2547 70 Yuseong-Ro, Yuseong-Gu 2548 Daejeon 305-811 2549 Republic of Korea 2551 Phone: +82 42 870 8409 2552 EMail: taejin.ahn@kt.com 2554 Rakesh Kumar 2555 Juniper Networks 2556 1133 Innovation Way 2557 Sunnyvale, CA 94089 2558 USA 2560 EMail: rkkumar@juniper.net 2562 Susan Hares 2563 Huawei 2564 7453 Hickory Hill 2565 Saline, MI 48176 2566 USA 2568 Phone: +1-734-604-0332 2569 EMail: shares@ndzh.com