idnits 2.17.1 draft-ietf-i2nsf-consumer-facing-interface-dm-12.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 261 has weird spacing: '...le-name strin...' == Line 481 has weird spacing: '...address ine...' == Line 523 has weird spacing: '...address ine...' == Line 527 has weird spacing: '...address ine...' == Line 655 has weird spacing: '...ription strin...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 8, 2020) is 1297 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: 'RFC0854' is defined on line 2360, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 2380, but no explicit reference was found in the text == Unused Reference: 'RFC5321' is defined on line 2414, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 2423, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 2445, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 2449, but no explicit reference was found in the text == Unused Reference: 'STIX' is defined on line 2500, but no explicit reference was found in the text ** 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 (~~), 15 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 12, 2021 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 September 8, 2020 13 I2NSF Consumer-Facing Interface YANG Data Model 14 draft-ietf-i2nsf-consumer-facing-interface-dm-12 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 12, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Information Model for Policy . . . . . . . . . . . . . . . . 5 68 3.1. Event Sub-model . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. Condition Sub-model . . . . . . . . . . . . . . . . . . . 7 70 3.3. Action Sub-model . . . . . . . . . . . . . . . . . . . . 9 71 4. Information Model for Policy Endpoint Groups . . . . . . . . 10 72 4.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 12 74 4.3. Location Group . . . . . . . . . . . . . . . . . . . . . 13 75 5. Information Model for Threat Prevention . . . . . . . . . . . 14 76 5.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 14 77 5.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 15 78 6. Network Configuration Access Control Model (NACM) for I2NSF 79 Consumer-Facing Interface . . . . . . . . . . . . . . . . . . 16 80 7. YANG Data Model of Consumer-Facing Interface . . . . . . . . 18 81 7.1. YANG Module of Consumer-Facing Interface . . . . . . . . 18 82 8. XML Configuration Examples of High-Level Security Policy 83 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 84 8.1. Database Registration: Information of Positions and 85 Devices (Endpoint Group) . . . . . . . . . . . . . . . . 41 86 8.2. Scenario 1: Block SNS Access during Business Hours . . . 43 87 8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to 88 a Company . . . . . . . . . . . . . . . . . . . . . . . . 45 89 8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a 90 Company Web Server . . . . . . . . . . . . . . . . . . . 47 91 9. XML Configuration Example of a User Group's Access Control 92 for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 48 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 50 95 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 96 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 98 14.1. Normative References . . . . . . . . . . . . . . . . . . 53 99 14.2. Informative References . . . . . . . . . . . . . . . . . 55 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 102 1. Introduction 104 In a framework of Interface to Network Security Functions (I2NSF) 105 [RFC8329], each vendor can register their NSFs using a Developer's 106 Management System (DMS). Assuming that vendors also provide the 107 front-end web applications registered with an I2NSF User, the 108 Consumer-Facing Interface is required because the web applications 109 developed by each vendor need to have a standard interface specifying 110 the data types used when the I2NSF User and Security Controller 111 communicate using this interface. Therefore, this document specifies 112 the required information, their data types, and encoding schemes so 113 that high-level security policies (or configuration information for 114 security policies) can be transferred to the Security Controller 115 through the Consumer-Facing Interface. These policies can easily be 116 translated by the Security Controller into low-level security 117 policies. The Security Controller delivers the translated policies 118 to Network Security Functions (NSFs) according to their respective 119 security capabilities for the required securiy enforcement. 121 The Consumer-Facing Interface would be built using a set of objects, 122 with each object capturing a unique set of information from Security 123 Administrator (i.e., I2NSF User [RFC8329]) needed to express a 124 Security Policy. An object may have relationship with various other 125 objects to express a complete set of requirements. An information 126 model captures the managed objects and relationship among these 127 objects. The information model proposed in this document is 128 structured in accordance with the "Event-Condition-Action" (ECA) 129 policy model. 131 An NSF Capability model is proposed in [I-D.ietf-i2nsf-capability] as 132 the basic model for both the NSF-Facing interface and Consumer-Facing 133 Interface security policy model of this document. 135 [RFC3444] explains differences between an information and data model. 136 This document uses the guidelines in [RFC3444] to define both the 137 information and data model for Consumer-Facing Interface. Figure 1 138 shows a high-level abstraction of Consumer-Facing Interface. A data 139 model, which represents an implementation of the information model in 140 a specific data representation language, is also defined in this 141 document. 143 +-----------------+ 144 | Consumer-Facing | 145 | Interface | 146 +--------+--------+ 147 ^ 148 | 149 +-------------+------------+ 150 | | | 151 +-----+----+ +-----+----+ +----+----+ 152 | Policy | | Endpoint | | Threat | 153 | | | groups | | feed | 154 +-----+----+ +----------+ +---------+ 155 ^ 156 | 157 +------+------+ 158 | Rule | 159 +------+------+ 160 ^ 161 | 162 +----------------+----------------+ 163 | | | 164 +------+------+ +------+------+ +------+------+ 165 | Event | | Condition | | Action | 166 +-------------+ +-------------+ +-------------+ 168 Figure 1: Diagram for High-level Abstraction of Consumer-Facing 169 Interface 171 Data models are defined at a lower level of abstraction and provide 172 many details. They provide details about the implementation of a 173 protocol's specification, e.g., rules that explain how to map managed 174 objects onto lower-level protocol constructs. Since conceptual 175 models can be implemented in different ways, multiple data models can 176 be derived from a single information model. 178 The efficient and flexible provisioning of network functions by a 179 Network Functions Virtualization (NFV) system leads to a rapid 180 advance in the network industry. As practical applications, Network 181 Security Functions (NSFs), such as firewall, Intrusion Detection 182 System (IDS)/Intrusion Prevention System (IPS), and attack 183 mitigation, can also be provided as Virtual Network Functions (VNF) 184 in the NFV system. By the efficient virtualization technology, these 185 VNFs might be automatically provisioned and dynamically migrated 186 based on real-time security requirements. This document presents a 187 YANG data model to implement security functions based on NFV. 189 2. Terminology 191 This document uses the terminology described in [RFC8329]. 193 This document follows the guidelines of [RFC8407], uses the common 194 YANG types defined in [RFC6991], and adopts the Network Management 195 Datastore Architecture (NMDA). The meaning of the symbols in tree 196 diagrams is defined in [RFC8340]. 198 3. Information Model for Policy 200 A Policy object represents a mechanism to express a Security Policy 201 by Security Administrator (i.e., I2NSF User) using Consumer-Facing 202 Interface toward Security Controller; the policy would be enforced on 203 an NSF. Figure 2 shows the YANG tree of the Policy object. The 204 Policy object SHALL have the following information: 206 Name: This field identifies the name of this object. 208 Rule: This field contains a list of rules. These rules are 209 defined for 1) communication between two Endpoint Groups, 210 2) for preventing communication with externally or 211 internally identified threats, and 3) for implementing 212 business requirement such as controlling access to internal 213 or external resources for meeting regulatory compliance or 214 business objectives. An organization may restrict certain 215 communication between a set of user and applications for 216 example. The threats may be from threat feeds obtained 217 from external sources or dynamically identified by using 218 specialty devices in the network. Rule conflict analysis 219 should be triggered by the monitoring service to perform an 220 exhaustive detection of anomalies among the configuration 221 rules installed into the security functions. 223 +--rw i2nsf-cfi-policy* [policy-name] 224 +--rw policy-name string 225 +--rw rules 226 +--rw endpoint-groups 227 +--rw threat-prevention 229 Figure 2: Policy YANG Data Tree 231 A policy is a container of Rule(s). In order to express a Rule, a 232 Rule must have complete information such as where and when a policy 233 needs to be applied. This is done by defining a set of managed 234 objects and relationship among them. A Policy Rule may be related 235 segmentation, threat mitigation or telemetry data collection from an 236 NSF in the network, which will be specified as the sub-model of the 237 policy model in the subsequent sections. Figure 3 shows the YANG 238 data tree of the Rule object. The rule object SHALL have the 239 following information: 241 Name: This field identifies the name of this object. 243 Event: This field includes the information to determine whether 244 the Rule Condition can be evaluated or not. See details in 245 Section 4.1. 247 Condition: This field contains all the checking conditions to 248 apply to the objective traffic. See details in 249 Section 4.2. 251 Action: This field identifies the action taken when a rule is 252 matched. There is always an implicit action to drop 253 traffic if no rule is matched for a traffic type. See 254 details in Section 4.3. 256 IPsec-method: This field contains the information about IPsec 257 method type. There are two types such as IPsec-IKE and 258 IPsec-IKEless [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 260 +--rw rules* [rule-name] 261 +--rw rule-name string 262 +--rw event 263 +--rw (condition)? 264 +--rw action 265 +--rw ipsec-method 267 Figure 3: Rule YANG Data Tree 269 Note that in the case of policy conflicts, the resolution of the 270 conflicted policies conforms to the guidelines of "Information Model 271 of NSFs Capabilities" [I-D.ietf-i2nsf-capability]. 273 3.1. Event Sub-model 275 The Event Object contains information related to scheduling a Rule. 276 The Rule could be activated based on a set time or security event. 277 Figure 4 shows the YANG tree of the Event object. Event object SHALL 278 have following information: 280 Security-event: This field identifies for which security event 281 the policy is enforced. The examples of security events 282 are: "DDOS", "spyware", "trojan", and "ransomware". 284 Time-information: This represents the security rule is enforced 285 based on the period information with the end time for the 286 event. 288 Period: This represents the period of time the rule event is 289 active. 291 End-time: This represents the end time of the event. If the 292 rule time has pass the end-time, the rule will stop 293 repeating" 295 Frequency: This represents how frequent the rule should be 296 enforced. There are four options: "only-once", "daily", 297 "weekly" and "monthly". 299 +--rw event 300 +--rw security-event identityref 301 +--rw time-information 302 | +--rw start-date-time? yang:date-and-time 303 | +--rw end-date-time? yang:date-and-time 304 | +--rw period 305 | | +--rw start-time? time 306 | | +--rw stop-time? time 307 | | +--rw day* identityref 308 | | +--rw date* int32 309 | | +--rw month* string 310 +--rw frequency? enumeration 312 Figure 4: Event Sub-model YANG Data Tree 314 3.2. Condition Sub-model 316 This object represents Conditions that Security Administrator wants 317 to apply the checking on the traffic in order to determine whether 318 the set of actions in the Rule can be executed or not. The Condition 319 Sub-model consists of three different types of containers each 320 representing different cases, such as general firewall and DDoS- 321 mitigation cases, and a case when the condition is based on the 322 payload strings of packets. Each containers have source and 323 destination-target to represent the source and destination for each 324 case. Figure 5 shows the YANG tree of the Condition object. The 325 Condition Sub-model SHALL have following information: 327 Case (Firewall-condition): This field represents the general 328 firewall case, where a security admin can set up firewall 329 conditions using the information present in this field. 330 The source and destination is represented as firewall- 331 source and firewall-destination, each referring to the IP- 332 address-based groups defined in the endpoint-groups. 334 Case (DDoS-condition): This field represents the condition for 335 DDoS mitigation, where a security admin can set up DDoS 336 mitigation conditions using the information present in this 337 field. The source and destination is represented as ddos- 338 source and ddos-destination, each referring to the device- 339 groups defined and registered in the endpoint-groups. 341 Case (Custom-condition): This field contains the payload string 342 information. This information is useful when security rule 343 condition is based on the string contents of incoming or 344 outgoing packets. The source and destination is 345 represented as custom-source and custom-destination, each 346 referring to the payload-groups defined and registered in 347 the endpoint-groups. 349 Case (Threat-feed-condition): This field contains the 350 information obtained from threat-feeds (e.g., Palo-Alto, or 351 RSA-netwitness). This information is useful when security 352 rule condition is based on the existing threat reports 353 gathered by other sources. The source and destination is 354 represented as threat-feed-source and threat-feed- 355 destination. For clarity, threat-feed-source/destination 356 represent the source/destination of a target security 357 threat, not the information source/destination of a threat- 358 feed. 360 +--rw condition 361 +--:firewall-condition 362 | +--rw source 363 | | -> /i2nsf-cfi-policy/endpoint-groups/user-group/name 364 | +--rw destination* 365 | | -> /i2nsf-cfi-policy/endpoint-groups/user-group/name 366 +--:ddos-condition 367 | +--rw source* 368 | | -> /i2nsf-cfi-policy/endpoint-groups/device-group/name 369 | +--rw destination* 370 | | -> /i2nsf-cfi-policy/endpoint-groups/device-group/name 371 | +--rw rate-limit 372 | | +--rw packet-threshold-per-second? uint32 373 +--:location-condition 374 | +--rw source* 375 | | -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 376 | +--rw destination 377 | | -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 378 +--:custom-condition 379 | +--rw source* 380 | | -> /i2nsf-cfi-policy/threat-preventions/payload-content/name 381 | +--rw destination? 382 | | -> /i2nsf-cfi-policy/threat-preventions/payload-content/name 383 +--:threat-feed-condition 384 +--rw source* 385 | -> /i2nsf-cfi-policy/threat-preventions/threat-feed-list/name 386 +--rw destination? 387 | -> /i2nsf-cfi-policy/threat-preventions/threat-feed-list/name 389 Figure 5: Condition Sub-model YANG Data Tree 391 3.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 402 is 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 4. 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, 418 as 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 It is assumed that the information of Endpoint Groups (e.g., User- 423 group, Device-group, and Location-group) such as the IP address(es) 424 of each member in a group are stored in the I2NSF database available 425 to the Security Controller, and that the IP address information of 426 each group in the I2NSF database is synchronized with other systems 427 in the networks under the same administration. 429 +-------------------+ 430 | Endpoint Groups | 431 +---------+---------+ 432 ^ 433 | 434 +--------------+----------------+ 435 0..n | 0..n | 0..n | 436 +-----+----+ +------+-----+ +-------+------+ 437 |User-group| |Device-group| |Location-group| 438 +----------+ +------------+ +--------------+ 440 Figure 7: Endpoint Group Diagram 442 +--rw endpoint-groups 443 | +--rw user-group* [name] 444 | ... 445 | +--rw device-group* [name] 446 | ... 447 | +--rw location-group* [name] 448 | ... 450 Figure 8: Endpoint Group YANG Data Tree 452 4.1. User Group 454 This object represents a User-Group. Figure 9 shows the YANG tree of 455 the User-Group object. The User-Group object SHALL have the 456 following information: 458 Name: This field identifies the name of this object. 460 IPv4: This represents the IPv4 address of a user in the user 461 group. 463 IPv6: This represents the IPv6 address of a user in the user 464 group. 466 Range-ipv4-address: This represents the IPv4 address range of a 467 user in the user group. 469 Range-ipv6-address: This represents the IPv6 address range of a 470 user in the user group. 472 +--rw user-group* [name] 473 +--rw name string 474 +--rw (match-type) 475 +--:(exact-match-ipv4) 476 | +--rw ipv4? inet:ipv4-address 477 +--:(exact-match-ipv6) 478 | +--rw ipv6? inet:ipv6-address 479 +--:(range-match-ipv4) 480 | +--rw range-ipv4-address 481 | +--rw start-ipv4-address inet:ipv4-address 482 | +--rw end-ipv4-address inet:ipv4-address 483 +--:(range-match-ipv6) 484 +--rw range-ipv6-address* 485 +--rw start-ipv6-address inet:ipv6-address 486 +--rw end-ipv6-address inet:ipv6-address 488 Figure 9: User Group YANG Data Tree 490 4.2. Device Group 492 This object represents a Device-Group. Figure 10 shows the YANG tree 493 of the Device-group object. The Device-Group object SHALL have the 494 following information: 496 Name: This field identifies the name of this object. 498 IPv4: This represents the IPv4 address of a device in the device 499 group. 501 IPv6: This represents the IPv6 address of a device in the device 502 group. 504 Range-ipv4-address: This represents the IPv4 address range of a 505 device in the device group. 507 Range-ipv6-address: This represents the IPv6 address range of a 508 device in the device group. 510 Protocol: This represents the communication protocols used by 511 the devices. The protocols are "SSH", "FTP", "SMTP", 512 "HTTP", "HTTPS", and etc. 514 +--rw device-group* [name] 515 +--rw name string 516 +--rw (match-type) 517 | +--:(exact-match-ipv4) 518 | | +--rw ipv4? inet:ipv4-address 519 | +--:(exact-match-ipv6) 520 | | +--rw ipv6? inet:ipv6-address 521 | +--:(range-match-ipv4) 522 | | +--rw range-ipv4-address* 523 | | | +--rw start-ipv4-address inet:ipv4-address 524 | | | +--rw end-ipv4-address inet:ipv4-address 525 | +--:(range-match-ipv6) 526 | | +--rw range-ipv6-address* 527 | | | +--rw start-ipv6-address inet:ipv6-address 528 | | | +--rw end-ipv6-address inet:ipv6-address 529 +--rw protocol identityref 531 Figure 10: Device Group YANG Data Tree 533 4.3. Location Group 535 This object represents a location group based on either tag or other 536 information. Figure 11 shows the YANG tree of the Location-Group 537 object. The Location-Group object SHALL have the following 538 information: 540 Name: This field identifies the name of this object. 542 Geo-ip-ipv4: This field represents the IPv4 Geo-ip address of a 543 location [RFC8805]. 545 Geo-ip-ipv6: This field represents the IPv6 Geo-ip address of a 546 location [RFC8805]. 548 Continent: This field represents the continent where the 549 location group member is located. 551 +--rw location-group* [name] 552 +--rw name string 553 +--rw geo-ip-ipv4 inet:ipv4-address 554 +--rw geo-ip-ipv6 inet:ipv6-address 555 +--rw continent? identityref 557 Figure 11: Location Group YANG Data Tree 559 5. Information Model for Threat Prevention 561 The threat prevention plays an important part in the overall security 562 posture by reducing the attack surfaces. This information could come 563 from various threat feeds (i.e., sources for obtaining the threat 564 information). There are multiple managed objects that constitute 565 this category. This section lists these objects and relationship 566 among them. Figure 13 shows the YANG tree of a Threat-Prevention 567 object. 569 +-------------------+ 570 | Threat Prevention | 571 +---------+---------+ 572 ^ 573 | 574 +---------+---------+ 575 0..n | 0..n | 576 +------+------+ +--------+--------+ 577 | Threat-feed | | payload-content | 578 +-------------+ +-----------------+ 580 Figure 12: Threat Prevention Diagram 582 +--rw threat-prevention 583 +--rw threat-feed-list* [name] 584 ... 585 +--rw payload-content* [name] 586 ... 588 Figure 13: Threat Prevention YANG Data Tree 590 5.1. Threat Feed 592 This object represents a threat feed which provides the signatures of 593 malicious activities. Figure 14 shows the YANG tree of a Threat- 594 feed-list. The Threat-Feed object SHALL have the following 595 information: 597 Name: This field identifies the name of this object. 599 Server-ipv4: This represents the IPv4 server address of the feed 600 provider, which may be either an external or local server. 602 Server-ipv6: This represents the IPv6 server address of the feed 603 provider, which may be either an external or local server. 605 Description: This is the description of the threat feed. The 606 description should have the clear indication of the 607 security attack such as attack type (e.g., APT) and file 608 types used (e.g., executable malware). 610 Threat-file-types: This field identifies the information about 611 the file types identified and reported by the threat-feed. 613 Signatures: This field contains the threat signatures of 614 malicious programs or activities provided by the threat- 615 feed. The examples of signature types are "YARA", 616 "SURICATA", and "SNORT" [YARA][SURICATA][SNORT]. 618 It is assumed that the I2NSF User obtains the threat signatures 619 (i.e., threat content patterns) from a threat-feed server (i.e., feed 620 provider), which is a server providing threat signatures. With the 621 obtained threat signatures, the I2NSF User can deliver them to the 622 Security Controller. The retrieval of the threat signatures by the 623 I2NSF User is out of scope in this document. 625 +--rw threat-prevention 626 +--rw threat-feed-list* [name] 627 +--rw name identityref 628 +--rw server-ipv4? inet:ipv4-address 629 +--rw server-ipv6? inet:ipv6-address 630 +--rw description? string 631 +--rw threat-file-types* identityref 632 +--rw signatures* identityref 634 Figure 14: Threat Feed YANG Data Tree 636 5.2. Payload Content 638 This object represents a custom list created for the purpose of 639 defining an exception to threat feeds. Figure 15 shows the YANG tree 640 of a Payload-content list. The Payload-Content object SHALL have the 641 following information: 643 Name: This field identifies the name of this object. For 644 example, the name "backdoor" indicates the payload content 645 is related to a backdoor attack. 647 Description: This represents the description of how the payload 648 content is related to a security attack. 650 Content: This contains the payload contents, which are involed 651 in a security attack, such as strings. 653 +--rw payload-content* [name] 654 +--rw name string 655 +--rw description string 656 +--rw content* string 658 Figure 15: Payload Content in YANG Data Tree 660 6. Network Configuration Access Control Model (NACM) for I2NSF 661 Consumer-Facing Interface 663 Network Configuration Access Control Model (NACM) provides a user 664 group with an access control with the following features [RFC8341]: 666 o Independent control of action, data, and notification access is 667 provided. 669 o A simple and familiar set of datastore permissions is used. 671 o Support for YANG security tagging allows default security modes to 672 automatically exclude sensitive data. 674 o Separate default access modes for read, write, and execute 675 permissions are provided. 677 o Access control rules are applied to configurable groups of users. 679 The data model of the I2NSF Consumer-Facing Interface utilizes the 680 NACM's mechanisms to manage the access control on the I2NSF Consumer- 681 Facing Interface. The NACM with the above features can be used to 682 set up the access control rules of a user group in the I2NSF 683 Consumer-Facing Interface. 685 Figure 16 shows part of the NACM module to enable the access control 686 of a user group for the I2NSF Consumer-Facing Interface. To use the 687 NACM, a user needs to configure either a NETCONF server [RFC6241] or 688 a RESTCONF server [RFC8040] to enable the NACM module. Then, the 689 user can simply use an account of root or admin user for the access 690 control for the module of the I2NSF Consumer-Facing Interface (i.e., 691 ietf-i2nsf-cfi-policy). An XML example to configure the access 692 control a user group for the I2NSF Consumer-Facing Interface can be 693 seen in Section 9. 695 list rule { 696 key "name"; 697 ordered-by user; 698 leaf name { 699 type string { 700 length "1..max"; 701 } 702 description 703 "Arbitrary name assigned to the rule."; 704 } 706 leaf module-name { 707 type union { 708 type matchall-string-type; 709 type string; 710 } 711 default "*"; 712 description 713 "Name of the module associated with this rule." 714 } 716 leaf access-operations { 717 type union { 718 type matchall-string-type; 719 type access-operations-type; 720 } 721 default "*"; 722 description 723 "Access operations associated with this rule." 724 } 726 leaf action { 727 type action-type; 728 mandatory true; 729 description 730 "The access control action associated with the 731 rule. If a rule is determined to match a 732 particular request, then this object is used 733 to determine whether to permit or deny the 734 request."; 735 } 737 Figure 16: A Part of the NACM YANG Data Model 739 7. YANG Data Model of Consumer-Facing Interface 741 The main objective of this data model is to provide both an 742 information model and the corresponding YANG data model of I2NSF 743 Consumer-Facing Interface. This interface can be used to deliver 744 control and management messages between an I2NSF User and Security 745 Controller for the I2NSF User's high-level security policies. 747 The semantics of the data model must be aligned with the information 748 model of the Consumer-Facing Interface. The transformation of the 749 information model is performed so that this YANG data model can 750 facilitate the efficient delivery of the control or management 751 messages. 753 This data model is designed to support the I2NSF framework that can 754 be extended according to the security needs. In other words, the 755 model design is independent of the content and meaning of specific 756 policies as well as the implementation approach. 758 With the YANG data model of I2NSF Consumer-Facing Interface, this 759 document suggests use cases for security policy rules such as time- 760 based firewall, VoIP/VoLTE security service, and DDoS-attack 761 mitigation in Section 8. 763 7.1. YANG Module of Consumer-Facing Interface 765 This section describes a YANG module of Consumer-Facing Interface. 766 This YANG module imports from [RFC6991]. It makes references to [RFC 767 0854][RFC0913][RFC0959][RFC1081][RFC1631][RFC2616][RFC2818][RFC4250][ 768 RFC5321]. 770 file "ietf-i2nsf-cfi-policy@2020-09-08.yang" 771 module ietf-i2nsf-cfi-policy { 772 yang-version 1.1; 773 namespace 774 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; 775 prefix nsfcfi; 777 import ietf-inet-types{ 778 prefix inet; 779 } 781 import ietf-yang-types{ 782 prefix yang; 783 } 785 import ietf-netconf-acm { 786 prefix nacm; 788 } 790 organization 791 "IETF I2NSF (Interface to Network Security Functions) 792 Working Group"; 794 contact 795 "WG Web: 796 WG List: 798 Editor: Jaehoon Paul Jeong 799 801 Editor: Patrick Lingga 802 "; 804 description 805 "This module is a YANG module for Consumer-Facing Interface. 807 Copyright (c) 2020 IETF Trust and the persons identified as 808 authors of the code. All rights reserved. 810 Redistribution and use in source and binary forms, with or 811 without modification, is permitted pursuant to, and subject 812 to the license terms contained in, the Simplified BSD License 813 set forth in Section 4.c of the IETF Trust's Legal Provisions 814 Relating to IETF Documents 815 http://trustee.ietf.org/license-info). 817 This version of this YANG module is part of RFC XXXX; see 818 the RFC itself for full legal notices."; 820 // RFC Ed.: replace XXXX with an actual RFC number and remove 821 // this note. 823 revision "2020-09-08"{ 824 description "Initial revision."; 825 reference 826 "RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model"; 828 // RFC Ed.: replace XXXX with an actual RFC number and remove 829 // this note. 830 } 832 identity malware-file-type { 833 description 834 "Base identity for malware file types."; 835 } 836 identity executable-file { 837 base malware-file-type; 838 description 839 "Identity for executable file types."; 840 } 842 identity doc-file { 843 base malware-file-type; 844 description 845 "Identity for Microsoft document file types."; 846 } 848 identity html-app-file { 849 base malware-file-type; 850 description 851 "Identity for html application file types."; 852 } 854 identity javascript-file { 855 base malware-file-type; 856 description 857 "Identity for Javascript file types."; 858 } 860 identity pdf-file { 861 base malware-file-type; 862 description 863 "Identity for pdf file types."; 864 } 866 identity dll-file { 867 base malware-file-type; 868 description 869 "Identity for dll file types."; 870 } 872 identity msi-file { 873 base malware-file-type; 874 description 875 "Identity for Microsoft installer file types."; 876 } 878 identity security-event-type { 879 description 880 "Base identity for security event types."; 881 } 883 identity ddos { 884 base security-event-type; 885 description 886 "Identity for DDoS event types."; 887 } 889 identity spyware { 890 base security-event-type; 891 description 892 "Identity for spyware event types."; 893 } 895 identity trojan { 896 base security-event-type; 897 description 898 "Identity for Trojan infection event types."; 899 } 901 identity ransomware { 902 base security-event-type; 903 description 904 "Identity for ransomware infection event types."; 905 } 907 identity i2nsf-ipsec { 908 description 909 "Base identity for IPsec method types."; 910 reference 911 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined 912 Networking (SDN)-based IPsec Flow Protection - IPsec method 913 types can be selected."; 914 } 916 identity ipsec-ike { 917 base i2nsf-ipsec; 918 description 919 "Identity for ipsec-ike."; 920 reference 921 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined 922 Networking (SDN)-based IPsec Flow Protection - IPsec method 923 type with IKE is selected."; 924 } 926 identity ipsec-ikeless { 927 base i2nsf-ipsec; 928 description 929 "Identity for ipsec-ikeless."; 930 reference 931 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined 932 Networking (SDN)-based IPsec Flow Protection - IPsec method 933 type without IKE is selected."; 934 } 936 identity continent { 937 description 938 "Base Identity for continent types."; 939 } 941 identity africa { 942 base continent; 943 description 944 "Identity for Africa."; 945 } 947 identity asia { 948 base continent; 949 description 950 "Identity for Asia."; 951 } 953 identity europe { 954 base continent; 955 description 956 "Identity for Europe."; 957 } 959 identity north-america { 960 base continent; 961 description 962 "Identity for North America."; 963 } 965 identity south-america { 966 base continent; 967 description 968 "Identity for South America."; 969 } 971 identity oceania { 972 base continent; 973 description 974 "Identity for Oceania"; 975 } 977 identity protocol-type { 978 description 979 "This identity represents the protocol types."; 981 } 983 identity ftp { 984 base protocol-type; 985 description 986 "The identity for ftp protocol."; 987 reference 988 "RFC 959: File Transfer Protocol (FTP)"; 989 } 991 identity ssh { 992 base protocol-type; 993 description 994 "The identity for ssh protocol."; 995 reference 996 "RFC 4250: The Secure Shell (SSH) Protocol"; 997 } 999 identity telnet { 1000 base protocol-type; 1001 description 1002 "The identity for telnet."; 1003 reference 1004 "RFC 854: Telnet Protocol"; 1005 } 1007 identity smtp { 1008 base protocol-type; 1009 description 1010 "The identity for smtp."; 1011 reference 1012 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1013 } 1015 identity sftp { 1016 base protocol-type; 1017 description 1018 "The identity for sftp."; 1019 reference 1020 "RFC 913: Simple File Transfer Protocol (SFTP)"; 1021 } 1023 identity http { 1024 base protocol-type; 1025 description 1026 "The identity for http."; 1027 reference 1028 "RFC 2616: Hypertext Transfer Protocol (HTTP)"; 1030 } 1032 identity https { 1033 base protocol-type; 1034 description 1035 "The identity for https."; 1036 reference 1037 "RFC 2818: HTTP over TLS (HTTPS)"; 1038 } 1040 identity pop3 { 1041 base protocol-type; 1042 description 1043 "The identity for pop3."; 1044 reference 1045 "RFC 1081: Post Office Protocol -Version 3 (POP3)"; 1046 } 1048 identity nat { 1049 base protocol-type; 1050 description 1051 "The identity for nat."; 1052 reference 1053 "RFC 1631: The IP Network Address Translator (NAT)"; 1054 } 1056 identity primary-action { 1057 description 1058 "This identity represents the primary actions, such as 1059 PASS, DROP, ALERT, RATE-LIMIT, and MIRROR."; 1060 } 1062 identity pass { 1063 base primary-action; 1064 description 1065 "The identity for pass."; 1066 } 1068 identity drop { 1069 base primary-action; 1070 description 1071 "The identity for drop."; 1072 } 1074 identity alert { 1075 base primary-action; 1076 description 1077 "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."; 1128 reference 1129 "YARA: YARA signatures are explained."; 1130 } 1132 identity signature-snort { 1133 base signature-type; 1134 description 1135 "This represents the SNORT signatures."; 1136 reference 1137 "SNORT: SNORT signatures are explained."; 1138 } 1140 identity signature-suricata { 1141 base signature-type; 1142 description 1143 "This represents the SURICATA signatures."; 1144 reference 1145 "SURICATA: SURICATA signatures are explained."; 1146 } 1148 identity threat-feed-type { 1149 description 1150 "This represents the base identity for threat-feed."; 1151 } 1153 identity day { 1154 description 1155 "This represents the base for days."; 1156 } 1158 identity monday { 1159 base day; 1160 description 1161 "This represents Monday."; 1162 } 1164 identity tuesday { 1165 base day; 1166 description 1167 "This represents Tuesday."; 1168 } 1170 identity wednesday { 1171 base day; 1172 description 1173 "This represents Wednesday."; 1174 } 1175 identity thursday { 1176 base day; 1177 description 1178 "This represents Thursday."; 1179 } 1181 identity friday { 1182 base day; 1183 description 1184 "This represents Friday."; 1185 } 1187 identity saturday { 1188 base day; 1189 description 1190 "This represents Saturday."; 1191 } 1193 identity sunday { 1194 base day; 1195 description 1196 "This represents Sunday."; 1197 } 1199 /* 1200 * Typedefs 1201 */ 1202 typedef time { 1203 type string { 1204 pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' 1205 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 1206 } 1207 description 1208 "The time type represents an instance of time of zero-duration 1209 that recurs every day."; 1210 } 1212 /* 1213 * Groupings 1214 */ 1216 grouping ipv4-list { 1217 description 1218 "Grouping for an IPv4 address list."; 1219 leaf-list ipv4 { 1220 type inet:ipv4-address; 1221 description 1222 "This is the entry for an IPv4 address list."; 1224 } 1225 } 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 } 1419 } 1420 leaf continent { 1421 type identityref { 1422 base continent; 1423 } 1424 default asia; 1425 description 1426 "location-group has geo-ip addresses of the corresponding 1427 continent."; 1428 } 1429 } 1431 grouping threat-feed-info { 1432 description 1433 "This is the grouping for the threat-feed-list"; 1434 leaf threat-type { 1435 type identityref { 1436 base threat-feed-type; 1437 } 1438 description 1439 "This represents the type of the threat-feed."; 1440 } 1441 leaf server-ipv4 { 1442 type inet:ipv4-address; 1443 description 1444 "The IPv4 address for the threat-feed server."; 1445 } 1446 leaf server-ipv6 { 1447 type inet:ipv6-address; 1448 description 1449 "The IPv6 address for the threat-feed server."; 1450 } 1451 leaf description { 1452 type string; 1453 description 1454 "This represents the descriptions of a threat-feed. The 1455 description should include information, such as type, threat, 1456 method, and file type. Structured Threat Information Expression 1457 (STIX) can be used for description of a threat [STIX]."; 1458 } 1459 } 1461 grouping payload-string { 1462 description 1463 "The grouping for payload-string content. It contains information 1464 such as name and string content."; 1465 leaf description { 1466 type string; 1467 description 1468 "This represents the description of a payload. If this is not 1469 set, it cannot support the description of how the payload content 1470 is related to a security attack."; 1471 } 1472 leaf-list content { 1473 type string; 1474 description 1475 "This represents the string of the payload contents. This content 1476 leaf-list contains the payload of a packet to analyze a threat. 1477 Due to the types of threats, the type of the content is defined 1478 as a string to accommodate any kind of a payload type such as 1479 HTTP, HTTPS, and SIP. If this is not set, it cannot support the 1480 payload contents involved in a security attack as a string."; 1481 } 1482 } 1484 list i2nsf-cfi-policy { 1485 key "policy-name"; 1486 description 1487 "This is a security policy list. Each policy in the list contains 1488 a list of security policy rules, and is a policy instance to have 1489 the information of where and when a policy needs to be applied."; 1490 leaf policy-name { 1491 type string; 1492 description 1493 "The name which identifies the policy."; 1494 } 1495 container rules{ 1496 description 1497 "This container has rules."; 1498 nacm:default-deny-write; 1499 list rule { 1500 key "rule-name"; 1501 ordered-by user; 1502 leaf rule-name { 1503 type string; 1504 description 1505 "This represents the name for a rule."; 1506 } 1507 description 1508 "There can be a single or multiple number of rules."; 1510 container event { 1511 description 1512 "This represents an event (i.e., a security event), for which 1513 a security rule is made."; 1514 leaf security-event { 1515 type identityref { 1516 base security-event-type; 1517 } 1518 description 1519 "This contains the description of a security event. If this 1520 is not set, it cannot support what security event will be 1521 enforced."; 1522 } 1524 container time-information { 1525 description 1526 "The time information when a security policy rule should be 1527 applied."; 1528 leaf start-date-time { 1529 type yang:date-and-time; 1530 description 1531 "This is the start date and time for a security policy 1532 rule."; 1533 } 1534 leaf end-date-time { 1535 type yang:date-and-time; 1536 description 1537 "This is the end date and time for a policy rule. The 1538 policy rule will stop working after the specified 1539 end-date-time."; 1540 } 1541 container period{ 1542 when 1543 "../../frequency!='only-once'"; 1544 description 1545 "This represents the repetition time. In the case where 1546 the frequency is weekly, the days can be set."; 1547 leaf start-time { 1548 type time; 1550 description 1551 "This is a period's start time for an event."; 1552 } 1553 leaf end-time { 1554 type time; 1556 description 1557 "This is a period's end time for an event."; 1558 } 1559 leaf-list day { 1560 when 1561 "../../../frequency='weekly'"; 1562 type identityref{ 1563 base day; 1564 } 1565 min-elements 1; 1566 description 1567 "This represents the repeated day of every week (e.g., 1568 Monday and Tuesday). More than one day can be 1569 specified."; 1570 } 1571 leaf-list date { 1572 when 1573 "../../../frequency='monthly'"; 1574 type int32{ 1575 range "1..31"; 1576 } 1577 min-elements 1; 1578 description 1579 "This represents the repeated date of every month. More 1580 than one date can be specified."; 1581 } 1582 leaf-list month { 1583 when 1584 "../../../frequency='yearly'"; 1585 type string{ 1586 pattern '\d{2}-\d{2}'; 1587 } 1588 min-elements 1; 1589 description 1590 "This represents the repeated date and month of every 1591 year. More than one can be specified. A pattern used 1592 here is Month and Date (MM-DD)."; 1593 } 1594 } 1595 } 1597 leaf frequency { 1598 type enumeration { 1599 enum only-once { 1600 description 1601 "This represents that the rule is immediately enforced 1602 only once and not repeated. The policy will 1603 continuously be active from the start-time to the 1604 end-time."; 1605 } 1606 enum daily { 1607 description 1608 "This represents that the rule is enforced on a daily 1609 basis. The policy will be repeated daily until the 1610 end-date."; 1611 } 1612 enum weekly { 1613 description 1614 "This represents that the rule is enforced on a weekly 1615 basis. The policy will be repeated weekly until the 1616 end-date. The repeated days can be specified."; 1617 } 1618 enum monthly { 1619 description 1620 "This represents that the rule is enforced on a monthly 1621 basis. The policy will be repeated monthly until the 1622 end-date."; 1623 } 1624 enum yearly { 1625 description 1626 "This represents that the rule is enforced on a yearly 1627 basis. The policy will be repeated yearly until the 1628 end-date."; 1629 } 1630 } 1631 default only-once; 1632 description 1633 "This represents how frequently the rule should be enforced."; 1634 } 1635 } 1637 container condition { 1638 description 1639 "Conditions for general security policies."; 1640 container firewall-condition { 1641 description 1642 "A general firewall condition."; 1643 leaf source { 1644 type leafref { 1645 path 1646 "/i2nsf-cfi-policy/endpoint-groups/user-group/name"; 1647 } 1648 description 1649 "This describes the path to the source."; 1650 } 1652 leaf-list destination { 1653 type leafref { 1654 path 1655 "/i2nsf-cfi-policy/endpoint-groups/user-group/name"; 1657 } 1658 description 1659 "This describes the paths to the destinations."; 1660 } 1661 } 1663 container ddos-condition { 1664 description 1665 "A condition for a DDoS attack."; 1666 leaf-list source { 1667 type leafref { 1668 path 1669 "/i2nsf-cfi-policy/endpoint-groups/device-group/name"; 1670 } 1671 description 1672 "This describes the paths to the sources."; 1673 } 1674 leaf-list destination { 1675 type leafref { 1676 path 1677 "/i2nsf-cfi-policy/endpoint-groups/device-group/name"; 1678 } 1679 description 1680 "This describes the paths to the destinations."; 1681 } 1682 container rate-limit { 1683 description 1684 "This describes the rate-limit."; 1685 leaf packet-threshold-per-second { 1686 type uint32; 1687 description 1688 "This is a trigger value for a rate limit for a 1689 DDoS-attack mitigation."; 1690 } 1691 } 1692 } 1694 container location-condition { 1695 description 1696 "A condition for a location-based connection"; 1697 leaf-list source { 1698 type leafref { 1699 path 1700 "/i2nsf-cfi-policy/endpoint-groups/location-group/name"; 1701 } 1702 description 1703 "This describes the paths to a location's sources."; 1704 } 1705 leaf-list destination { 1706 type leafref { 1707 path 1708 "/i2nsf-cfi-policy/endpoint-groups/location-group/name"; 1709 } 1710 description 1711 "This describes the paths to a location's destinations."; 1712 } 1713 } 1715 container custom-condition { 1716 description 1717 "A condition based on a packet's content."; 1718 leaf-list source { 1719 type leafref { 1720 path 1721 "/i2nsf-cfi-policy/threat-preventions/payload-content/name"; 1722 } 1723 description 1724 "This describes the paths to a packet content's sources."; 1725 } 1726 leaf destination { 1727 type leafref { 1728 path 1729 "/i2nsf-cfi-policy/threat-preventions/payload-content/name"; 1730 } 1731 description 1732 "This describes the path to a packet content's 1733 destination."; 1734 } 1735 } 1737 container threat-feed-condition { 1738 description 1739 "A condition based on the threat-feed information."; 1740 leaf-list source { 1741 type leafref { 1742 path 1743 "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name"; 1744 } 1745 description 1746 "This describes the paths to a threat-feed's sources."; 1747 } 1748 leaf destination { 1749 type leafref { 1750 path 1751 "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name"; 1752 } 1753 description 1754 "This describes the path to a threat-feed's destination."; 1755 } 1756 } 1757 } 1759 container actions { 1760 description 1761 "This is the action container."; 1762 leaf primary-action { 1763 type identityref { 1764 base primary-action; 1765 } 1766 description 1767 "This represent primary actions (e.g., PASS, DROP, ALERT, 1768 and MIRROR) to be applied to a condition. If this is not 1769 set, it cannot support the primary actions."; 1770 } 1771 leaf secondary-action { 1772 type identityref { 1773 base secondary-action; 1774 } 1775 description 1776 "This represents secondary actions (e.g., log and syslog) 1777 to be applied if they are needed. If this is not set, it 1778 cannot support the secondary actions."; 1779 } 1780 } 1782 container ipsec-method { 1783 description 1784 "This container represents the IPsec method such as IKE case 1785 and IKEless case."; 1786 leaf method { 1787 type identityref { 1788 base i2nsf-ipsec; 1789 } 1790 description 1791 "This represents the IPsec method type such as IKE case and 1792 IKEless case. If this is not set, it cannot support 1793 either IPsec IKE or IPsec IKEless."; 1794 reference 1795 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: 1796 Software-Defined Networking (SDN)-based IPsec Flow 1797 Protection - IPsec method types can be selected."; 1798 } 1799 } 1800 } 1802 } 1803 container endpoint-groups { 1804 description 1805 "A logical entity in a business environment, where a security 1806 policy is to be applied."; 1807 list user-group{ 1808 uses user-group; 1809 key "name"; 1810 description 1811 "This represents a user group."; 1812 } 1813 list device-group { 1814 key "name"; 1815 uses device-group; 1816 description 1817 "This represents a device group."; 1818 } 1819 list location-group{ 1820 key "name"; 1821 uses location-group; 1822 description 1823 "This represents a location group."; 1824 } 1825 } 1827 container threat-preventions { 1828 description 1829 "This describes the list of threat-preventions."; 1830 list threat-feed-list { 1831 key "name"; 1832 description 1833 "There can be a single or multiple number of threat-feeds."; 1834 leaf name { 1835 type string; 1836 description 1837 "This represents the name of the threat-feed."; 1838 } 1839 uses threat-feed-info; 1840 leaf-list threat-file-types { 1841 type identityref { 1842 base malware-file-type; 1843 } 1844 description 1845 "This contains a list of file types needed to be scanned for 1846 a security threat (e.g., virus)."; 1847 } 1848 leaf-list signatures { 1849 type identityref { 1850 base signature-type; 1851 } 1852 description 1853 "This contains a list of signatures or hashes of the threats."; 1854 } 1855 } 1856 list payload-content { 1857 key "name"; 1858 leaf name { 1859 type string; 1860 description 1861 "This represents the name of a packet's payload-content. It 1862 should give an idea of why a specific payload content is 1863 marked as a threat. For example, the name 'backdoor' 1864 indicates the payload content is related to a backdoor 1865 attack."; 1866 } 1867 description 1868 "This represents a payload-string group."; 1869 uses payload-string; 1870 } 1871 } 1872 } 1873 } 1874 1876 Figure 17: YANG for Consumer-Facing Interface 1878 8. XML Configuration Examples of High-Level Security Policy Rules 1880 This section shows XML configuration examples of high-level security 1881 policy rules that are delivered from the I2NSF User to the Security 1882 Controller over the Consumer-Facing Interface. The considered use 1883 cases are: Database registration, time-based firewall for web 1884 filtering, VoIP/VoLTE security service, and DDoS-attack mitigation. 1886 8.1. Database Registration: Information of Positions and Devices 1887 (Endpoint Group) 1889 If new endpoints are introduced to the network, it is necessary to 1890 first register their data to the database. For example, if new 1891 members are newly introduced in either of three different groups 1892 (i.e., user-group, device-group, and payload-group), each of them 1893 should be registered with information such as ip-addresses or 1894 protocols used by devices. 1896 Figure 18 shows an example XML representation of the registered 1897 information for the user-group and device-group with IPv4 addresses 1898 [RFC5737]. 1900 1901 1902 1903 1904 employees 1905 1906 192.0.2.11 1907 192.0.2.90 1908 1909 1910 1911 webservers 1912 1913 198.51.100.11 1914 198.51.100.20 1915 1916 nsfcfi:http 1917 nsfcfi:https 1918 1919 1920 1922 Figure 18: Registering User-group and Device-group Information with 1923 IPv4 Addresses 1925 Also, Figure 19 shows an example XML representation of the registered 1926 information for the user-group and device-group with IPv6 addresses 1927 [RFC3849]. 1929 1930 1931 1932 1933 employees 1934 1935 2001:DB8:0:1::11 1936 2001:DB8:0:1::90 1937 1938 1939 1940 webservers 1941 1942 2001:DB8:0:2::11 1943 2001:DB8:0:2::20 1944 1945 nsfcfi:http 1946 nsfcfi:https 1947 1948 1949 1951 Figure 19: Registering User-group and Device-group Information with 1952 IPv6 Addresses 1954 8.2. Scenario 1: Block SNS Access during Business Hours 1956 The first example scenario is to "block SNS access during office 1957 hours" using a time-based firewall policy. In this scenario, all 1958 users registered as "employees" in the user-group list are unable to 1959 access Social Networking Services (SNS) during the office hours 1960 (weekdays). The XML instance is described below: 1962 1963 1964 security_policy_for_blocking_sns123 1965 1966 1967 block_access_to_sns_during_office_hours 1968 1969 1970 2020-03-11T09:00:00.00Z 1971 2020-12-31T18:00:00.00Z 1972 1973 09:00:00Z 1974 18:00:00Z 1975 nsfcfi:monday 1976 nsfcfi:tuesday 1977 nsfcfi:wednesday 1978 nsfcfi:thursday 1979 nsfcfi:friday 1980 1981 1982 weekly 1983 1984 1985 1986 employees 1987 1988 1989 sns-websites 1990 1991 1992 1993 nsfcfi:drop 1994 1995 1996 1997 1999 Figure 20: An XML Example for Time-based Firewall 2001 Time-based-condition Firewall 2003 1. The policy name is "security_policy_for_blocking_sns". 2005 2. The rule name is "block_access_to_sns_during_office_hours". 2007 3. The Source is "employees". 2009 4. The destination target is "sns-websites". "sns-websites" is the 2010 key which represents the list containing the information, such as 2011 URL, about sns-websites. 2013 5. The action required is to "drop" any attempt to connect to 2014 websites related to Social networking. 2016 6. The IPsec method type used for nsf traffic steering is set to 2017 "ipsec-ike". 2019 8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a Company 2021 The second example scenario is to "block malicious VoIP/VoLTE packets 2022 coming to a company" using a VoIP policy. In this scenario, the 2023 calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that 2024 are classified as malicious are dropped. The IP addresses of the 2025 employees and malicious VOIP IDs should be blocked are stored in the 2026 database or datastore of the enterprise. Here and the rest of the 2027 cases assume that the security administrators or someone responsible 2028 for the existing and newly generated policies, are not aware of which 2029 and/or how many NSFs are needed to meet the security requirements. 2030 Figure 21 represents the XML document generated from YANG discussed 2031 in previous sections. Once a high-level seucurity policy is created 2032 by a security admin, it is delivered by the Consumer-Facing 2033 Interface, through RESTCONF server, to the security controller. The 2034 XML instance is described below: 2036 2037 2038 2039 security_policy_for_blocking_malicious_voip_packets 2040 2041 2042 2043 Block_malicious_voip_and_volte_packets 2044 2045 2046 malicious-id 2047 2048 2049 employees 2050 2051 2052 2053 nsfcfi:drop 2054 2055 2056 nsfcfi:ipsec-ikeless 2057 2058 2059 2060 2062 Figure 21: An XML Example for VoIP Security Service 2064 Custom-condition Firewall 2066 1. The policy name is 2067 "security_policy_for_blocking_malicious_voip_packets". 2069 2. The rule name is "Block_malicious_voip_and_volte_packets". 2071 3. The Source is "malicious-id". This can be a single ID or a list 2072 of IDs, depending on how the ID are stored in the database. The 2073 "malicious-id" is the key so that the security admin can read 2074 every stored malicious VOIP IDs that are named as "malicious-id". 2076 4. The destination target is "employees". "employees" is the key 2077 which represents the list containing information about employees, 2078 such as IP addresses. 2080 5. The action required is "drop" when any incoming packets are from 2081 "malicious-id". 2083 6. The IPsec method used for nsf traffic steering is set to "ipsec- 2084 ikeless". 2086 8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web 2087 Server 2089 The third example scenario is to "Mitigate HTTP and HTTPS flood 2090 attacks on a company web server" using a DDoS-attack mitigation 2091 policy. Here, the time information is not set because the service 2092 provided by the network should be maintained at all times. If the 2093 packets sent by any sources are more than the set threshold, then the 2094 admin can set the percentage of the packets to be dropped to safely 2095 maintain the service. In this scenario, the source is set as "any" 2096 to block any sources which send abnormal amount of packets. The 2097 destination is set as "web_server01". Once the rule is set and 2098 delivered and enforced to the nsfs by the securiy controller, the 2099 NSFs will monitor the incoming packet amounts and the destination to 2100 act according to the rule set. The XML instance is described below: 2102 2103 2104 security_policy_for_ddos_attacks 2105 2106 2107 100_packets_per_second 2108 2109 2110 webservers 2111 2112 100 2113 2114 2115 2116 2117 nsfcfi:drop 2118 2119 2120 nsfcfi:ipsec-ikeless 2121 2122 2123 2124 2126 Figure 22: An XML Example for DDoS-attack Mitigation 2128 DDoS-condition Firewall 2129 1. The policy name is "security_policy_for_ddos_attacks". 2131 2. The rule name is "100_packets_per_second". 2133 3. The destination target is "webservers". "webservers" is the key 2134 which represents the list containing information, such as IP 2135 addresses and ports, about web-servers. 2137 4. The rate limit exists to limit the incoming amount of packets per 2138 second. In this case the rate limit is "100" packets per second. 2139 This amount depends on the packet receiving capacity of the 2140 server devices. 2142 5. The Source is all sources which send abnormal amount of packets. 2144 6. The action required is to "drop" packet reception is more than 2145 100 packets per second. 2147 7. The IPsec method used for nsf traffic steering is set to "ipsec- 2148 ike". 2150 9. XML Configuration Example of a User Group's Access Control for I2NSF 2151 Consumer-Facing Interface 2153 This is an example for creating privileges for a group of users 2154 (i.e., a user group) to access and use the I2NSF Consumer-Facing 2155 Interface to create security policies via the interface. For the 2156 access control of the Consumer-Facing Interface, the NACM module can 2157 be used. Figure 23 shows an XML example the access control of a user 2158 group (named Example-Group) for I2NSF Consumer-Facing Interface A 2159 group called Example-Group can be created and configured with NACM 2160 for the Consumer-Facing Interface. For Example-Group, a rule list 2161 can created with the name of Example-Group-Rules. Example-Group- 2162 Rules has two rules of Example-Group-Rule1 and Example-Group-Rule2 as 2163 follows. For Example-Group-Rule1, the privilege of "Read" is allowed 2164 to Example-Group for the Consumer-Facing Interface. On the other 2165 hand, for Example-Group-Rule2, the privileges of "Create", "Update", 2166 and "Delete" are denied against Example-Group for the Consumer-Facing 2167 Interface. 2169 2170 2171 true 2172 2173 2174 Example-Group 2175 Alice 2176 Bob 2177 Eve 2178 2179 2180 2181 Example-Group-Rules 2182 Example-Group 2183 2184 Example-Group-Rule1 2185 read 2186 ietf-i2nsf-cfi-policy 2187 permit 2188 2189 2190 Example-Group-Rule2 2191 create update delete 2192 ietf-i2nsf-cfi-policy 2193 deny 2194 2195 2196 2198 Figure 23: An XML Example of a User Group's Access Control for I2NSF 2199 Consumer-Facing Interface 2201 The access control for the I2NSF Consumer-Facing Interface is as 2202 follows. 2204 1. The NACM is enabled. 2206 2. As a group name, Example-Group is specified. 2208 3. As members of the group, Alice, Bob, and Eve are specified. 2210 4. As a rule list name, Example-Group-Rules is specified for 2211 managing privileges of Example-Group's members. 2213 5. As the first rule name, Example-Group-Rule1 is specified. This 2214 rule is used to give read privilege to Example-Group's members 2215 for the module of the I2NSF Consumer-Facing Interface. 2217 6. As the second rule name, Example-Group-Rule2 is specified. This 2218 rule is used to deny create, update, and delete privileges 2219 against Example-Group's members for the module of the I2NSF 2220 Consumer-Facing Interface. 2222 10. IANA Considerations 2224 This document requests IANA to register the following URI in the 2225 "IETF XML Registry" [RFC3688]: 2227 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2228 Registrant Contact: The IESG. 2229 XML: N/A; the requested URI is an XML namespace. 2231 This document requests IANA to register the following YANG module in 2232 the "YANG Module Names" registry [RFC7950][RFC8525]: 2234 name: ietf-i2nsf-cfi-policy 2235 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2236 prefix: nsfcfi 2237 reference: RFC XXXX 2239 // RFC Ed.: replace XXXX with an actual RFC number and remove 2240 // this note. 2242 11. Security Considerations 2244 The data model for the I2NSF Consumer-Facing Interface is based on 2245 the I2NSF framework [RFC8329], so the same security considerations 2246 with the I2NSF framework should be included in this document. The 2247 data model needs a secure communication channel to protect the 2248 Consumer-Facing Interface between the I2NSF User and Security 2249 Controller. Also, the data model's management access control is 2250 based on Network Configuration Access Control Model(NACM) mechanisms 2251 [RFC8341]. 2253 12. Acknowledgments 2255 This work was supported by Institute of Information & Communications 2256 Technology Planning & Evaluation (IITP) grant funded by the Korea 2257 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 2258 Security Intelligence Technology Development for the Customized 2259 Security Service Provisioning). This work was supported in part by 2260 the IITP (2020-0-00395, Standard Development of Blockchain based 2261 Network Management Automation Technology). 2263 13. Contributors 2265 This document is made by the group effort of I2NSF working group. 2266 Many people actively contributed to this document, such as Mahdi F. 2267 Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their 2268 contributions. 2270 The following are co-authors of this document: 2272 Patrick Lingga 2273 Department of Electronic, Electrical and Computer Engineering 2274 Sungkyunkwan University 2275 2066 Seo-ro Jangan-gu 2276 Suwon, Gyeonggi-do 16419 2277 Republic of Korea 2279 EMail: patricklink@skku.edu 2281 Hyoungshick Kim 2282 Department of Computer Science and Engineering 2283 Sungkyunkwan University 2284 2066 Seo-ro Jangan-gu 2285 Suwon, Gyeonggi-do 16419 2286 Republic of Korea 2288 EMail: hyoung@skku.edu 2290 Eunsoo Kim 2291 Department of Electronic, Electrical and Computer Engineering 2292 Sungkyunkwan University 2293 2066 Seo-ro Jangan-gu 2294 Suwon, Gyeonggi-do 16419 2295 Republic of Korea 2297 EMail: eskim86@skku.edu 2299 Seungjin Lee 2300 Department of Electronic, Electrical and Computer Engineering 2301 Sungkyunkwan University 2302 2066 Seo-ro Jangan-gu 2303 Suwon, Gyeonggi-do 16419 2304 Republic of Korea 2306 EMail: jine33@skku.edu 2307 Jinyong Tim Kim 2308 Department of Electronic, Electrical and Computer Engineering 2309 Sungkyunkwan University 2310 2066 Seo-ro Jangan-gu 2311 Suwon, Gyeonggi-do 16419 2312 Republic of Korea 2314 EMail: timkim@skku.edu 2316 Anil Lohiya 2317 Juniper Networks 2318 1133 Innovation Way 2319 Sunnyvale, CA 94089 2320 US 2322 EMail: alohiya@juniper.net 2324 Dave Qi 2325 Bloomberg 2326 731 Lexington Avenue 2327 New York, NY 10022 2328 US 2330 EMail: DQI@bloomberg.net 2332 Nabil Bitar 2333 Nokia 2334 755 Ravendale Drive 2335 Mountain View, CA 94043 2336 US 2338 EMail: nabil.bitar@nokia.com 2340 Senad Palislamovic 2341 Nokia 2342 755 Ravendale Drive 2343 Mountain View, CA 94043 2344 US 2346 EMail: senad.palislamovic@nokia.com 2348 Liang Xia 2349 Huawei 2350 101 Software Avenue 2351 Nanjing, Jiangsu 210012 2352 China 2354 EMail: Frank.Xialiang@huawei.com 2356 14. References 2358 14.1. Normative References 2360 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 2361 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 2362 1983, . 2364 [RFC0913] Lottor, M., "Simple File Transfer Protocol", RFC 913, 2365 DOI 10.17487/RFC0913, September 1984, 2366 . 2368 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2369 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 2370 . 2372 [RFC1081] Rose, M., "Post Office Protocol: Version 3", RFC 1081, 2373 DOI 10.17487/RFC1081, November 1988, 2374 . 2376 [RFC1631] Egevang, K. and P. Francis, "The IP Network Address 2377 Translator (NAT)", RFC 1631, DOI 10.17487/RFC1631, May 2378 1994, . 2380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2381 Requirement Levels", BCP 14, RFC 2119, 2382 DOI 10.17487/RFC2119, March 1997, 2383 . 2385 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2386 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2387 Transfer Protocol -- HTTP/1.1", RFC 2616, 2388 DOI 10.17487/RFC2616, June 1999, 2389 . 2391 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2392 DOI 10.17487/RFC2818, May 2000, 2393 . 2395 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2396 Information Models and Data Models", RFC 3444, 2397 DOI 10.17487/RFC3444, January 2003, 2398 . 2400 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2401 DOI 10.17487/RFC3688, January 2004, 2402 . 2404 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 2405 Reserved for Documentation", RFC 3849, 2406 DOI 10.17487/RFC3849, July 2004, 2407 . 2409 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 2410 Protocol Assigned Numbers", RFC 4250, 2411 DOI 10.17487/RFC4250, January 2006, 2412 . 2414 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2415 DOI 10.17487/RFC5321, October 2008, 2416 . 2418 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 2419 Reserved for Documentation", RFC 5737, 2420 DOI 10.17487/RFC5737, January 2010, 2421 . 2423 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2424 the Network Configuration Protocol (NETCONF)", RFC 6020, 2425 DOI 10.17487/RFC6020, October 2010, 2426 . 2428 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2429 and A. Bierman, Ed., "Network Configuration Protocol 2430 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2431 . 2433 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2434 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2435 . 2437 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2438 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2439 . 2441 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2442 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2443 . 2445 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2446 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2447 May 2017, . 2449 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2450 and J. Jeong, "Interface to Network Security Functions 2451 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2452 DOI 10.17487/RFC8192, July 2017, 2453 . 2455 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2456 Kumar, "Framework for Interface to Network Security 2457 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2458 . 2460 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2461 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2462 . 2464 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2465 Access Control Model", STD 91, RFC 8341, 2466 DOI 10.17487/RFC8341, March 2018, 2467 . 2469 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2470 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2471 DOI 10.17487/RFC8407, October 2018, 2472 . 2474 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 2475 and R. Wilton, "YANG Library", RFC 8525, 2476 DOI 10.17487/RFC8525, March 2019, 2477 . 2479 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 2480 Kumari, "A Format for Self-Published IP Geolocation 2481 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 2482 . 2484 14.2. Informative References 2486 [I-D.ietf-i2nsf-capability] 2487 Xia, L., Strassner, J., Basile, C., and D. Lopez, 2488 "Information Model of NSFs Capabilities", draft-ietf- 2489 i2nsf-capability-05 (work in progress), April 2019. 2491 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] 2492 Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia, 2493 "Software-Defined Networking (SDN)-based IPsec Flow 2494 Protection", draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 2495 (work in progress), June 2020. 2497 [SNORT] Roesch, M., Green, C., and B. Caswell, "SNORT", SNORT 2498 Documents https://www.snort.org/#documents, August 2020. 2500 [STIX] Jordan, B., Piazza, R., and T. Darley, "Structured Threat 2501 Information Expression (STIX)", STIX Version 2.1: 2502 Committee Specification 01 https://docs.oasis- 2503 open.org/cti/stix/v2.1/stix-v2.1.pdf, March 2020. 2505 [SURICATA] 2506 Julien, V. and , "SURICATA", SURICATA Documents 2507 https://suricata-ids.org/docs/, August 2020. 2509 [YARA] Alvarez, V., Bengen, H., Metz, J., Buehlmann, S., and W. 2510 Shields, "YARA", YARA 2511 Documents https://yara.readthedocs.io/en/v3.5.0/, August 2512 2020. 2514 Authors' Addresses 2516 Jaehoon Paul Jeong (editor) 2517 Department of Computer Science and Engineering 2518 Sungkyunkwan University 2519 2066 Seobu-Ro, Jangan-Gu 2520 Suwon, Gyeonggi-Do 16419 2521 Republic of Korea 2523 Phone: +82 31 299 4957 2524 Fax: +82 31 290 7996 2525 EMail: pauljeong@skku.edu 2526 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2527 Chaehong Chung 2528 Department of Electronic, Electrical and Computer Engineering 2529 Sungkyunkwan University 2530 2066 Seobu-Ro, Jangan-Gu 2531 Suwon, Gyeonggi-Do 16419 2532 Republic of Korea 2534 Phone: +82 31 299 4957 2535 EMail: darkhong@skku.edu 2537 Tae-Jin Ahn 2538 Korea Telecom 2539 70 Yuseong-Ro, Yuseong-Gu 2540 Daejeon 305-811 2541 Republic of Korea 2543 Phone: +82 42 870 8409 2544 EMail: taejin.ahn@kt.com 2546 Rakesh Kumar 2547 Juniper Networks 2548 1133 Innovation Way 2549 Sunnyvale, CA 94089 2550 USA 2552 EMail: rkkumar@juniper.net 2554 Susan Hares 2555 Huawei 2556 7453 Hickory Hill 2557 Saline, MI 48176 2558 USA 2560 Phone: +1-734-604-0332 2561 EMail: shares@ndzh.com