idnits 2.17.1 draft-ietf-i2nsf-consumer-facing-interface-dm-16.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 403 has weird spacing: '...version enu...' == Line 524 has weird spacing: '...address ine...' == Line 528 has weird spacing: '...address ine...' == Line 562 has weird spacing: '...address ine...' == Line 566 has weird spacing: '...address ine...' == (4 more instances...) -- The document date (28 January 2022) is 819 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) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 8329 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-rfc793bis-25 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-tcpm-rfc793bis' -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). 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: 1 August 2022 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 28 January 2022 13 I2NSF Consumer-Facing Interface YANG Data Model 14 draft-ietf-i2nsf-consumer-facing-interface-dm-16 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, and 26 the data model is defined for enabling different users of a given 27 I2NSF system to define, manage, and monitor security policies for 28 specific flows within an administrative domain. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 1 August 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Information Model for Policy . . . . . . . . . . . . . . . . 5 66 3.1. Event Sub-model . . . . . . . . . . . . . . . . . . . . . 7 67 3.2. Condition Sub-model . . . . . . . . . . . . . . . . . . . 8 68 3.3. Action Sub-model . . . . . . . . . . . . . . . . . . . . 10 69 4. Information Model for Policy Endpoint Groups . . . . . . . . 11 70 4.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 13 72 4.3. Location Group . . . . . . . . . . . . . . . . . . . . . 13 73 4.4. URL Group . . . . . . . . . . . . . . . . . . . . . . . . 14 74 5. Information Model for Threat Prevention . . . . . . . . . . . 15 75 5.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 15 76 5.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 16 77 6. Network Configuration Access Control Model (NACM) for I2NSF 78 Consumer-Facing Interface . . . . . . . . . . . . . . . . 17 79 7. YANG Data Model of Consumer-Facing Interface . . . . . . . . 19 80 7.1. YANG Module of Consumer-Facing Interface . . . . . . . . 19 81 8. XML Configuration Examples of High-Level Security Policy 82 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 49 83 8.1. Database Registration: Information of Positions and Devices 84 (Endpoint Group) . . . . . . . . . . . . . . . . . . . . 49 85 8.2. Scenario 1: Block SNS Access during Business Hours . . . 51 86 8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a 87 Company . . . . . . . . . . . . . . . . . . . . . . . . . 53 88 8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a 89 Company Web Server . . . . . . . . . . . . . . . . . . . 54 90 9. XML Configuration Example of a User Group's Access Control for 91 I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 56 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 58 94 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 95 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 59 96 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 97 14.1. Normative References . . . . . . . . . . . . . . . . . . 60 98 14.2. Informative References . . . . . . . . . . . . . . . . . 63 99 Appendix A. Changes from 100 draft-ietf-i2nsf-consumer-facing-interface-dm-15 . . . . 64 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 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. Terminology 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 194 "OPTIONAL" in this document are to be interpreted as described in BCP 195 14 [RFC2119] [RFC8174] when, and only when, they appear in all 196 capitals, as shown here. 198 This document uses the terminology described in [RFC8329]. 200 This document follows the guidelines of [RFC8407], uses the common 201 YANG types defined in [RFC6991], and adopts the Network Management 202 Datastore Architecture (NMDA). The meaning of the symbols in tree 203 diagrams is defined in [RFC8340]. 205 3. Information Model for Policy 207 A Policy object represents a mechanism to express a Security Policy 208 by Security Administrator (i.e., I2NSF User) using Consumer-Facing 209 Interface toward Security Controller; the policy would be enforced on 210 an NSF. Figure 2 shows the YANG tree of the Policy object. The 211 Policy object SHALL have the following information: 213 Name: This field identifies the name of this object. 215 Resolution-strategy: This field represent how to resolve conflicts 216 that occur between actions of the same or different policy 217 rules that are matched and contained in this particular 218 NSF. 220 Rules: This field contains a list of rules. These rules are 221 defined for 1) communication between two Endpoint Groups, 222 2) for preventing communication with externally or 223 internally identified threats, and 3) for implementing 224 business requirement such as controlling access to internal 225 or external resources for meeting regulatory compliance or 226 business objectives. An organization may restrict certain 227 communication between a set of user and applications for 228 example. The threats may be from threat feeds obtained 229 from external sources or dynamically identified by using 230 specialty devices in the network. Rule conflict analysis 231 should be triggered by the monitoring service to perform an 232 exhaustive detection of anomalies among the configuration 233 rules installed into the security functions. 235 +--rw i2nsf-cfi-policy* [name] 236 +--rw name string 237 +--rw resolution-strategy? identityref 238 +--rw rules* [name] 239 | ... 240 +--rw endpoint-groups 241 | ... 242 +--rw threat-preventions 243 | ... 244 +--rw url-group* [name] 245 | ... 247 Figure 2: Policy YANG Data Tree 249 A policy is a list of rules. In order to express a Rule, a Rule must 250 have complete information such as where and when a policy needs to be 251 applied. This is done by defining a set of managed objects and 252 relationship among them. A Policy Rule may be related segmentation, 253 threat mitigation or telemetry data collection from an NSF in the 254 network, which will be specified as the sub-model of the policy model 255 in the subsequent sections. Figure 3 shows the YANG data tree of the 256 Rule object. The rule object SHALL have the following information: 258 Name: This field identifies the name of this object. 260 Priority: This field identifies the priority of the rule. 262 Event: This field includes the information to determine whether 263 the Rule Condition can be evaluated or not. See details in 264 Section 4.1. 266 Condition: This field contains all the checking conditions to apply 267 to the objective traffic. See details in Section 4.2. 269 Action: This field identifies the action taken when a rule is 270 matched. There is always an implicit action to drop 271 traffic if no rule is matched for a traffic type. See 272 details in Section 4.3. 274 +--rw rules* [name] 275 | +--rw name string 276 | +--rw priority? uint8 277 | +--rw event 278 | ... 279 | +--rw condition 280 | ... 281 | +--rw actions 282 ... 284 Figure 3: Rule YANG Data Tree 286 Note that in the case of policy conflicts, the resolution of the 287 conflicted policies conforms to the guidelines of "Information Model 288 of NSFs Capabilities" [I-D.ietf-i2nsf-capability]. 290 3.1. Event Sub-model 292 The Event Object contains information related to scheduling a Rule. 293 The Rule could be activated based on a set time or security event. 294 Figure 4 shows the YANG tree of the Event object. Event object SHALL 295 have following information: 297 Security-event: This field identifies for which security event the 298 policy is enforced. The examples of security events are: 299 "DDOS", "spyware", "trojan", and "ransomware". 301 Time-information: This represents the security rule is enforced 302 based on the period information with the end time for the 303 event. 305 Start-date-time: This represents the start date and time of the 306 event. The rule will start repeating from the specified 307 start date and time. 309 End-date-time: This represents the end date and time of the event. 310 If the rule's time has passed the specified end date and 311 time, the rule will stop repeating. 313 Period: This represents the period of time the rule event is 314 active. It can be configured by the start-time, stop-time, 315 day, date, and month. 317 Frequency: This represents how frequently the rule should be 318 enforced. There are four options: "only-once", "daily", 319 "weekly", "monthly" or "yearly". 321 +--rw event 322 | +--rw security-event? identityref 323 | +--rw time 324 | +--rw start-date-time? yang:date-and-time 325 | +--rw end-date-time? yang:date-and-time 326 | +--rw period 327 | | +--rw start-time? time 328 | | +--rw end-time? time 329 | | +--rw day* day 330 | | +--rw date* int32 331 | | +--rw month* string 332 | +--rw frequency? enumeration 334 Figure 4: Event Sub-model YANG Data Tree 336 3.2. Condition Sub-model 338 This object represents Conditions that Security Administrator wants 339 to apply the checking on the traffic in order to determine whether 340 the set of actions in the Rule can be executed or not. The Condition 341 Sub-model consists of three different types of containers each 342 representing different cases, such as general firewall and DDoS- 343 mitigation cases, and a case when the condition is based on the 344 payload strings of packets. Each containers have source and 345 destination-target to represent the source and destination for each 346 case. Figure 5 shows the YANG tree of the Condition object. The 347 Condition Sub-model SHALL have following information: 349 Case (firewall-condition): This field represents the general 350 firewall case, where a security admin can set up firewall 351 conditions using the information present in this field. 352 The source and destination is represented as source, 353 destination, transport layer protocol, port numbers, and 354 ICMP parameters. 356 Case (ddos-condition): This field represents the condition for DDoS 357 mitigation, where a security admin can set up DDoS 358 mitigation conditions using the information present in this 359 field. The rate of packet, byte, or flow threshold can be 360 configured to mitigate the DDoS. 362 Case (anti-virus-condition): This field represents the condition for 363 Antivirus, where a security admin can set up Antivirus 364 conditions using the information present in this field. 365 The file names or types can be configured to be allowed 366 without the Antivirus interuption. 368 Case (payload-condition): This field contains the payload string 369 information. This information is useful when security rule 370 condition is based on the string contents of incoming or 371 outgoing packets. The name referring to the payload-groups 372 defined and registered in the endpoint-groups. 374 Case (url-condition): This field represents the URL to be filtered. 375 This information can be used to block or allow a certain 376 URL or website. The url-name is a group of URL or websites 377 to be matched. 379 Case (voice-condition): This field contains the call source-id, call 380 destination-id, and user-agent. This information can be 381 used to filter a caller id or receiver id to prevent any 382 VoIP or VoLTE exploits or attack. 384 Case (context-condition): This field represents a context of a 385 packet or flow. The context can be extended. This module 386 provides a context of geographic location. 388 Case (Threat-feed-condition): This field contains the information 389 obtained from threat-feeds (e.g., Palo-Alto, or RSA- 390 netwitness). This information is useful when security rule 391 condition is based on the existing threat reports gathered 392 by other sources. 394 +--rw condition 395 | +--rw firewall-condition 396 | | +--rw source* union 397 | | +--rw destination* union 398 | | +--rw transport-layer-protocol? identityref 399 | | +--rw range-port-number 400 | | | +--rw start-port-number? inet:port-number 401 | | | +--rw end-port-number? inet:port-number 402 | | +--rw icmp* [version] 403 | | +--rw version enumeration 404 | | +--rw type* uint8 405 | | +--rw code* uint8 406 | +--rw ddos-condition 407 | | +--rw rate-limit 408 | | +--rw packet-rate-threshold? uint32 409 | | +--rw byte-rate-threshold? uint64 410 | | +--rw flow-rate-threshold? uint32 411 | +--rw anti-virus-condition 412 | | +--rw exception-files* string 413 | +--rw payload-condition 414 | | +--rw content* 415 -> /i2nsf-cfi-policy/threat-preventions/payload-content/name 416 | +--rw url-condition 417 | | +--rw url-name? 418 -> /i2nsf-cfi-policy/endpoint-groups/url-group/name 419 | +--rw voice-condition 420 | | +--rw source-id* string 421 | | +--rw destination-id* string 422 | | +--rw user-agent* string 423 | +--rw context-condition 424 | +--rw geographic-location 425 | +--rw source* 426 -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 427 | +--rw destination* 428 -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 429 | | +--rw threat-feed-condition 430 | | +--rw name* 431 -> /i2nsf-cfi-policy/threat-preventions/threat-feed-list/name 433 Figure 5: Condition Sub-model YANG Data Tree 435 3.3. Action Sub-model 437 This object represents actions that Security Admin wants to perform 438 based on certain traffic class. Figure 6 shows the YANG tree of the 439 Action object. The Action object SHALL have following information: 441 Primary-action: This field identifies the action when a rule is 442 matched by an NSF. The action could be one of "pass", 443 "drop", "reject", "rate-limit", "mirror", "invoke- 444 signaling", "tunnel-encapsulation", "forwarding", and 445 "transformation". 447 Secondary-action: This field identifies the action when a rule is 448 matched by an NSF. The action could be one of "rule-log" 449 and "session-log". 451 +--rw actions 452 | +--rw primary-action 453 | | +--rw action? identityref 454 | +--rw secondary-action 455 | +--rw log-action? identityref 457 Figure 6: Action Sub-model YANG Data Tree 459 4. Information Model for Policy Endpoint Groups 461 The Policy Endpoint Group is a very important part of building User- 462 Construct based policies. A Security Administrator would create and 463 use these objects to represent a logical entity in their business 464 environment, where a Security Policy is to be applied. There are 465 multiple managed objects that constitute a Policy's Endpoint Group, 466 as shown in Figure 7. Figure 8 shows the YANG tree of the Endpoint- 467 Groups object. This section lists these objects and relationship 468 among them. 470 It is assumed that the information of Endpoint Groups (e.g., User- 471 group, Device-group, and Location-group) such as the IP address(es) 472 of each member in a group are stored in the I2NSF database available 473 to the Security Controller, and that the IP address information of 474 each group in the I2NSF database is synchronized with other systems 475 in the networks under the same administration. 477 +-------------------+ 478 | Endpoint Groups | 479 +---------+---------+ 480 ^ 481 | 482 +--------------+-------+--------+---------------+ 483 0..n | 0..n | 0..n | 0..n | 484 +-----+----+ +------+-----+ +-------+------+ +-----+---+ 485 |User-group| |Device-group| |Location-group| |Url-group| 486 +----------+ +------------+ +--------------+ +---------+ 487 Figure 7: Endpoint Group Diagram 489 +--rw endpoint-groups 490 | +--rw user-group* [name] 491 | ... 492 | +--rw device-group* [name] 493 | ... 494 | +--rw location-group* [name] 495 | ... 496 | +--rw url-group* [name] 497 | ... 499 Figure 8: Endpoint Group YANG Data Tree 501 4.1. User Group 503 This object represents a User-Group. Figure 9 shows the YANG tree of 504 the User-Group object. The User-Group object SHALL have the 505 following information: 507 Name: This field identifies the name of this object. 509 mac-address: This represents the MAC address of a user in the user 510 group. 512 Range-ipv4-address: This represents the IPv4 address range of a user 513 in the user group. 515 Range-ipv6-address: This represents the IPv6 address range of a user 516 in the user group. 518 +--rw user-group* [name] 519 | +--rw name string 520 | +--rw mac-address* yang:mac-address 521 | +--rw (match-type) 522 | | +--:(range-match-ipv4) 523 | | | +--rw range-ipv4-address 524 | | | +--rw start-ipv4-address inet:ipv4-address-no-zone 525 | | | +--rw end-ipv4-address inet:ipv4-address-no-zone 526 | | +--:(range-match-ipv6) 527 | | +--rw range-ipv6-address 528 | | +--rw start-ipv6-address inet:ipv6-address-no-zone 529 | | +--rw end-ipv6-address inet:ipv6-address-no-zone 531 Figure 9: User Group YANG Data Tree 533 4.2. Device Group 535 This object represents a Device-Group. Figure 10 shows the YANG tree 536 of the Device-group object. The Device-Group object SHALL have the 537 following information: 539 Name: This field identifies the name of this object. 541 IPv4: This represents the IPv4 address of a device in the device 542 group. 544 IPv6: This represents the IPv6 address of a device in the device 545 group. 547 Range-ipv4-address: This represents the IPv4 address range of a 548 device in the device group. 550 Range-ipv6-address: This represents the IPv6 address range of a 551 device in the device group. 553 Application-protocol: This represents the application layer 554 protocols of devices. If this is not set, it cannot 555 support the appropriate protocol 557 +--rw device-group* [name] 558 | +--rw name string 559 | +--rw (match-type) 560 | | +--:(range-match-ipv4) 561 | | | +--rw range-ipv4-address 562 | | | +--rw start-ipv4-address inet:ipv4-address-no-zone 563 | | | +--rw end-ipv4-address inet:ipv4-address-no-zone 564 | | +--:(range-match-ipv6) 565 | | +--rw range-ipv6-address 566 | | +--rw start-ipv6-address inet:ipv6-address-no-zone 567 | | +--rw end-ipv6-address inet:ipv6-address-no-zone 568 | +--rw application-protocol* identityref 570 Figure 10: Device Group YANG Data Tree 572 4.3. Location Group 574 This object represents a location group based on either tag or other 575 information. Figure 11 shows the YANG tree of the Location-Group 576 object. The Location-Group object SHALL have the following 577 information: 579 Name: This field identifies the name of this object. 581 Geo-ip-ipv4: This field represents the IPv4 Geo-ip address of a 582 location [RFC8805]. 584 Geo-ip-ipv6: This field represents the IPv6 Geo-ip address of a 585 location [RFC8805]. 587 Continent: This field represents the continent where the location 588 group member is located. 590 +--rw location-group* [name] 591 | +--rw name string 592 | +--rw geo-ip-ipv4* [ipv4-address] 593 | | +--rw ipv4-address inet:ipv4-address-no-zone 594 | | +--rw ipv4-prefix? inet:ipv4-prefix 595 | +--rw geo-ip-ipv6* [ipv6-address] 596 | | +--rw ipv6-address inet:ipv6-address-no-zone 597 | | +--rw ipv6-prefix? inet:ipv6-prefix 598 | +--rw continent? identityref 600 Figure 11: Location Group YANG Data Tree 602 4.4. URL Group 604 This object represents a URL group based on a Uniform Resource 605 Locator (URL) or web address. Figure 12 shows the YANG tree of the 606 URL-Group object. The URLn-Group object SHALL have the following 607 information: 609 Name: This field identifies the name of this object. 611 url: This field represents the new URL added by a user to the 612 URL database. 614 +--rw url-group* [name] 615 +--rw name string 616 +--rw url* string 618 Figure 12: URL Group YANG Data Tree 620 5. Information Model for Threat Prevention 622 The threat prevention plays an important part in the overall security 623 posture by reducing the attack surfaces. This information could come 624 from various threat feeds (i.e., sources for obtaining the threat 625 information). There are multiple managed objects that constitute 626 this category. This section lists these objects and relationship 627 among them. Figure 14 shows the YANG tree of a Threat-Prevention 628 object. 630 +-------------------+ 631 | Threat Prevention | 632 +---------+---------+ 633 ^ 634 | 635 +---------+---------+ 636 0..n | 0..n | 637 +------+------+ +--------+--------+ 638 | Threat-feed | | payload-content | 639 +-------------+ +-----------------+ 641 Figure 13: Threat Prevention Diagram 643 +--rw threat-prevention 644 +--rw threat-feed-list* [name] 645 ... 646 +--rw payload-content* [name] 647 ... 649 Figure 14: Threat Prevention YANG Data Tree 651 5.1. Threat Feed 653 This object represents a threat feed which provides the signatures of 654 malicious activities. Figure 15 shows the YANG tree of a Threat- 655 feed-list. The Threat-Feed object SHALL have the following 656 information: 658 Name: This field identifies the name of this object. 660 Description: This is the description of the threat feed. The 661 description should have the clear indication of the 662 security attack such as attack type (e.g., APT) and file 663 types used (e.g., executable malware). 665 Signatures: This field contains the threat signatures of malicious 666 programs or activities provided by the threat-feed. The 667 examples of signature types are "YARA", "SURICATA", and 668 "SNORT" [YARA][SURICATA][SNORT]. 670 It is assumed that the I2NSF User obtains the threat signatures 671 (i.e., threat content patterns) from a threat-feed server (i.e., feed 672 provider), which is a server providing threat signatures. With the 673 obtained threat signatures, the I2NSF User can deliver them to the 674 Security Controller. The retrieval of the threat signatures by the 675 I2NSF User is out of scope in this document. 677 +--rw threat-prevention 678 +--rw threat-feed-list* [name] 679 +--rw name identityref 680 +--rw description? string 681 +--rw signatures* identityref 683 Figure 15: Threat Feed YANG Data Tree 685 5.2. Payload Content 687 This object represents a custom list created for the purpose of 688 defining an exception to threat feeds. Figure 16 shows the YANG tree 689 of a Payload-content list. The Payload-Content object SHALL have the 690 following information: 692 Name: This field identifies the name of this object. For 693 example, the name "backdoor" indicates the payload content 694 is related to a backdoor attack. 696 Description: This represents the description of how the payload 697 content is related to a security attack. 699 Content: This contains the payload contents, which are involed in a 700 security attack, such as strings. 702 +--rw payload-content* [name] 703 +--rw name string 704 +--rw description string 705 +--rw content* string 707 Figure 16: Payload Content in YANG Data Tree 709 6. Network Configuration Access Control Model (NACM) for I2NSF 710 Consumer-Facing Interface 712 Network Configuration Access Control Model (NACM) provides a user 713 group with an access control with the following features [RFC8341]: 715 * Independent control of action, data, and notification access is 716 provided. 718 * A simple and familiar set of datastore permissions is used. 720 * Support for YANG security tagging allows default security modes to 721 automatically exclude sensitive data. 723 * Separate default access modes for read, write, and execute 724 permissions are provided. 726 * Access control rules are applied to configurable groups of users. 728 The data model of the I2NSF Consumer-Facing Interface utilizes the 729 NACM's mechanisms to manage the access control on the I2NSF Consumer- 730 Facing Interface. The NACM with the above features can be used to 731 set up the access control rules of a user group in the I2NSF 732 Consumer-Facing Interface. 734 Figure 17 shows part of the NACM module to enable the access control 735 of a user group for the I2NSF Consumer-Facing Interface. To use the 736 NACM, a user needs to configure either a NETCONF server [RFC6241] or 737 a RESTCONF server [RFC8040] to enable the NACM module. Then, the 738 user can simply use an account of root or admin user for the access 739 control for the module of the I2NSF Consumer-Facing Interface (i.e., 740 ietf-i2nsf-cfi-policy). An XML example to configure the access 741 control a user group for the I2NSF Consumer-Facing Interface can be 742 seen in Section 9. 744 list rule { 745 key "name"; 746 ordered-by user; 747 leaf name { 748 type string { 749 length "1..max"; 750 } 751 description 752 "Arbitrary name assigned to the rule."; 753 } 755 leaf module-name { 756 type union { 757 type matchall-string-type; 758 type string; 759 } 760 default "*"; 761 description 762 "Name of the module associated with this rule." 763 } 765 leaf access-operations { 766 type union { 767 type matchall-string-type; 768 type access-operations-type; 769 } 770 default "*"; 771 description 772 "Access operations associated with this rule." 773 } 775 leaf action { 776 type action-type; 777 mandatory true; 778 description 779 "The access control action associated with the 780 rule. If a rule is determined to match a 781 particular request, then this object is used 782 to determine whether to permit or deny the 783 request."; 784 } 786 Figure 17: A Part of the NACM YANG Data Model 788 7. YANG Data Model of Consumer-Facing Interface 790 The main objective of this document is to provide both an information 791 model and the corresponding YANG data model of I2NSF Consumer-Facing 792 Interface. This interface can be used to deliver control and 793 management messages between an I2NSF User and Security Controller for 794 the I2NSF User's high-level security policies. 796 The semantics of the data model must be aligned with the information 797 model of the Consumer-Facing Interface. The transformation of the 798 information model is performed so that this YANG data model can 799 facilitate the efficient delivery of the control or management 800 messages. 802 This data model is designed to support the I2NSF framework that can 803 be extended according to the security needs. In other words, the 804 model design is independent of the content and meaning of specific 805 policies as well as the implementation approach. 807 With the YANG data model of I2NSF Consumer-Facing Interface, this 808 document suggests use cases for security policy rules such as time- 809 based firewall, VoIP/VoLTE security service, and DDoS-attack 810 mitigation in Section 8. 812 7.1. YANG Module of Consumer-Facing Interface 814 This section describes a YANG module of Consumer-Facing Interface. 815 This document provides identities in the data model to be used for 816 configuration of an NSF. Each identity is used for a different type 817 of configuration. The details are explained in the description of 818 each identity. This YANG module imports from [RFC6991]. It makes 819 references to [RFC0768][RFC0792][RFC0793] [RFC0854][RFC0959][RFC1939] 820 [RFC2818][RFC3022][RFC3261] [RFC3501][RFC4250][RFC4340] 821 [RFC4443][RFC4960][RFC5321] [RFC7230][RFC7231][RFC8335] 822 [RFC8805][I-D.ietf-i2nsf-capability] 823 [I-D.ietf-tcpm-rfc793bis][IANA-ICMP-Parameters] 824 [IANA-ICMPv6-Parameters][Encyclopedia-Britannica] [STIX]. 826 file "ietf-i2nsf-cfi-policy@2022-01-28.yang" 827 module ietf-i2nsf-cfi-policy { 828 yang-version 1.1; 829 namespace 830 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; 831 prefix nsfcfi; 833 import ietf-inet-types{ 834 prefix inet; 835 reference "RFC 6991"; 837 } 839 import ietf-yang-types{ 840 prefix yang; 841 reference "RFC 6991"; 842 } 844 organization 845 "IETF I2NSF (Interface to Network Security Functions) 846 Working Group"; 848 contact 849 "WG Web: 850 WG List: 852 Editor: Jaehoon Paul Jeong 853 855 Editor: Patrick Lingga 856 "; 858 description 859 "This module is a YANG module for Consumer-Facing Interface. 861 Copyright (c) 2022 IETF Trust and the persons identified as 862 authors of the code. All rights reserved. 864 Redistribution and use in source and binary forms, with or 865 without modification, is permitted pursuant to, and subject to 866 the license terms contained in, the Simplified BSD License set 867 forth in Section 4.c of the IETF Trust's Legal Provisions 868 Relating to IETF Documents 869 (https://trustee.ietf.org/license-info). 871 This version of this YANG module is part of RFC XXXX 872 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 873 for full legal notices."; 875 // RFC Ed.: replace XXXX with an actual RFC number and remove 876 // this note. 878 revision "2022-01-28" { 879 description "Initial revision."; 880 reference 881 "RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model"; 883 // RFC Ed.: replace XXXX with an actual RFC number and remove 884 // this note. 886 } 888 identity resolution-strategy { 889 description 890 "Base identity for resolution strategy"; 891 reference 892 "draft-ietf-i2nsf-capability-data-model-22: 893 I2NSF Capability YANG Data Model - Resolution Strategy"; 894 } 896 identity fmr { 897 base resolution-strategy; 898 description 899 "Identity for First Matching Rule (FMR)"; 900 reference 901 "draft-ietf-i2nsf-capability-data-model-22: 902 I2NSF Capability YANG Data Model - Resolution Strategy"; 903 } 905 identity lmr { 906 base resolution-strategy; 907 description 908 "Identity for Last Matching Rule (LMR)"; 909 reference 910 "draft-ietf-i2nsf-capability-data-model-22: 911 I2NSF Capability YANG Data Model - Resolution Strategy"; 912 } 914 identity pmr { 915 base resolution-strategy; 916 description 917 "Identity for Prioritized Matching Rule (PMR)"; 918 reference 919 "draft-ietf-i2nsf-capability-data-model-22: 920 I2NSF Capability YANG Data Model - Resolution Strategy"; 921 } 923 identity pmre { 924 base resolution-strategy; 925 description 926 "Identity for Prioritized Matching Rule 927 with Errors (PMRE)"; 928 reference 929 "draft-ietf-i2nsf-capability-data-model-22: 930 I2NSF Capability YANG Data Model - Resolution Strategy"; 931 } 933 identity pmrn { 934 base resolution-strategy; 935 description 936 "Identity for Prioritized Matching Rule 937 with No Errors (PMRN)"; 938 reference 939 "draft-ietf-i2nsf-capability-data-model-22: 940 I2NSF Capability YANG Data Model - Resolution Strategy"; 941 } 943 identity security-event { 944 description 945 "Base identity for security event types."; 946 } 948 identity anti-ddos { 949 base security-event; 950 description 951 "Identity for Anti-DDoS event types."; 952 } 954 identity ips { 955 base security-event; 956 description 957 "Identity for Intrusion Prevention System event types."; 958 } 960 identity url-filtering { 961 base security-event; 962 description 963 "Identity for url-filtering event types."; 964 } 966 identity anti-virus { 967 base security-event; 968 description 969 "Identity for Antivirus types."; 970 } 972 identity voip-volte-filtering { 973 base security-event; 974 description 975 "Identity for VoIP/VoLTE Filtering event types."; 976 } 978 identity protocol { 979 description 980 "This identity represents the protocol types."; 981 } 982 identity transport-protocol { 983 base protocol; 984 description 985 "Base identity for the Layer 4 (i.e., Transport Layer) 986 Protocols"; 987 } 989 identity tcp { 990 base transport-protocol; 991 description 992 "Base identity for TCP condition capabilities"; 993 reference 994 "RFC 793: Transmission Control Protocol 995 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 996 (TCP) Specification"; 997 } 999 identity udp { 1000 base transport-protocol; 1001 description 1002 "Base identity for UDP condition capabilities"; 1003 reference 1004 "RFC 768: User Datagram Protocol"; 1005 } 1007 identity sctp { 1008 base transport-protocol; 1009 description 1010 "Identity for SCTP condition capabilities"; 1011 reference 1012 "RFC 4960: Stream Control Transmission Protocol"; 1013 } 1015 identity dccp { 1016 base transport-protocol; 1017 description 1018 "Identity for DCCP condition capabilities"; 1019 reference 1020 "RFC 4340: Datagram Congestion Control Protocol"; 1021 } 1023 identity application-protocol { 1024 base protocol; 1025 description 1026 "Base identity for the Layer 7 (i.e., Application Layer) 1027 Protocols"; 1028 } 1029 identity ftp { 1030 base application-protocol; 1031 description 1032 "The identity for ftp protocol."; 1033 reference 1034 "RFC 959: File Transfer Protocol (FTP)"; 1035 } 1037 identity ssh { 1038 base application-protocol; 1039 description 1040 "The identity for ssh protocol."; 1041 reference 1042 "RFC 4250: The Secure Shell (SSH) Protocol"; 1043 } 1045 identity telnet { 1046 base application-protocol; 1047 description 1048 "The identity for telnet."; 1049 reference 1050 "RFC 854: Telnet Protocol"; 1051 } 1053 identity smtp { 1054 base application-protocol; 1055 description 1056 "The identity for smtp."; 1057 reference 1058 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1059 } 1061 identity http { 1062 base application-protocol; 1063 description 1064 "The identity for http."; 1065 reference 1066 "RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1067 Syntax and Routing 1068 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1069 and Content"; 1070 } 1072 identity https { 1073 base application-protocol; 1074 description 1075 "The identity for https."; 1076 reference 1077 "RFC 2818: HTTP over TLS (HTTPS)"; 1078 } 1080 identity pop3 { 1081 base application-protocol; 1082 description 1083 "The identity for pop3."; 1084 reference 1085 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1086 } 1088 identity imap { 1089 base application-protocol; 1090 description 1091 "The identity for Internet Message Access Protocol (IMAP)."; 1092 reference 1093 "RFC 3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"; 1094 } 1096 identity action { 1097 description 1098 "Base identity for action"; 1099 } 1101 identity primary-action { 1102 base action; 1103 description 1104 "Base identity for primary action. Primary action is an action 1105 that handle the forwarding of the packets or flows in an 1106 NSF."; 1107 } 1109 identity secondary-action { 1110 base action; 1111 description 1112 "Base identity for secondary action. Secondary action is an 1113 action in the background that does not affect the network, 1114 such as logging."; 1115 } 1117 identity ingress-action { 1118 base primary-action; 1119 description 1120 "Base identity to represents the ingress actions, such as 1121 pass, drop, reject, rate-limit, and mirror."; 1122 } 1124 identity egress-action { 1125 base primary-action; 1126 description 1127 "Base identity represents the egress actions, such as 1128 pass, drop, reject, rate-limit, mirror, invoke-signaling, 1129 tunnel-encapsulation, forwarding, and transformation."; 1130 } 1132 identity pass { 1133 base ingress-action; 1134 base egress-action; 1135 description 1136 "Identity for pass. The pass action allows traffic that matches 1137 the rule to proceed through the NSF to reach the 1138 destination."; 1139 reference 1140 "draft-ietf-i2nsf-capability-data-model-22: 1141 I2NSF Capability YANG Data Model - Actions and 1142 Default Action"; 1143 } 1145 identity drop { 1146 base ingress-action; 1147 base egress-action; 1148 description 1149 "Identity for drop. The drop action denies the traffic that 1150 matches the rule. The drop action should do a silent drop, 1151 which does not give any response to the source."; 1152 reference 1153 "draft-ietf-i2nsf-capability-data-model-22: 1154 I2NSF Capability YANG Data Model - Actions and 1155 Default Action"; 1156 } 1158 identity reject { 1159 base ingress-action; 1160 base egress-action; 1161 description 1162 "Identity for reject action. The reject action 1163 denies packet to go through the NSF entering or exiting the 1164 internal network and send a response back to the source. 1165 The response depends on the packet and implementation. 1166 For example, a TCP packet is rejected with TCP RST response 1167 or a UDP packet may be rejected with an ICMP response message 1168 with Type 3 Code 3, i.e., Destination Unreachable: Destination 1169 port unreachable."; 1170 reference 1171 "draft-ietf-i2nsf-capability-data-model-22: 1172 I2NSF Capability YANG Data Model - Actions and 1173 Default Action"; 1174 } 1176 identity mirror { 1177 base ingress-action; 1178 base egress-action; 1179 description 1180 "Identity for mirror. The mirror action copies a packet and 1181 sends the packet's copy to the monitoring entity while still 1182 allowing the packet or flow to go through the NSF."; 1183 reference 1184 "draft-ietf-i2nsf-capability-data-model-22: 1185 I2NSF Capability YANG Data Model - Actions and 1186 Default Action"; 1187 } 1189 identity rate-limit { 1190 base ingress-action; 1191 base egress-action; 1192 description 1193 "Identity for rate limiting action. The rate limit action 1194 limits the number of packets or flows that can go through the 1195 NSF by dropping packets or flows (randomly or 1196 systematically). The drop mechanism, e.g., silent drop and 1197 unreachable drop (i.e., reject), is up to the implementation"; 1198 reference 1199 "draft-ietf-i2nsf-capability-data-model-22: 1200 I2NSF Capability YANG Data Model - Actions and 1201 Default Action"; 1202 } 1204 identity invoke-signaling { 1205 base egress-action; 1206 description 1207 "Identity for invoke signaling action capability. The invoke 1208 signaling action is used to convey information of the event 1209 triggering this action to a monitoring entity"; 1210 reference 1211 "RFC 8329: Framework for Interface to Network Security 1212 Functions - Invoke-signaling action"; 1213 } 1215 identity tunnel-encapsulation { 1216 base egress-action; 1217 description 1218 "Identity for tunnel encapsulation action capability. The 1219 tunnel encapsulation action is used to encapsulate the packet 1220 to be tunneled across the network to enable a secure 1221 connection."; 1222 reference 1223 "RFC 8329: Framework for Interface to Network Security 1224 Functions - Tunnel Encapsulation"; 1225 } 1227 identity forwarding { 1228 base egress-action; 1229 description 1230 "Identity for forwarding action capability. The forwarding 1231 action is used to relay the packet from one network segment 1232 to another node in the network."; 1233 reference 1234 "RFC 8329: Framework for Interface to Network Security 1235 Functions - Forwarding action"; 1236 } 1238 identity transformation { 1239 base egress-action; 1240 description 1241 "Identity for transformation action capability. The 1242 transformation action is used to transform the packet by 1243 modifying its protocol header such as HTTP-to-CoAP 1244 translation."; 1245 reference 1246 "RFC 8329: Framework for Interface to Network Security 1247 Functions - Redirection action"; 1248 } 1250 identity log-action { 1251 base secondary-action; 1252 description 1253 "Base identity for representing log actions, such as rule-log 1254 and session-log action."; 1255 } 1257 identity rule-log { 1258 base log-action; 1259 description 1260 "Identity for rule log-action capability. 1261 Log the received packet based on the rule"; 1262 } 1264 identity session-log { 1265 base log-action; 1266 description 1267 "Identity for session log-action capability. 1268 Log the received packet based on the session."; 1270 } 1272 identity signature-type { 1273 description 1274 "This represents the base identity for signature types."; 1275 } 1277 identity signature-yara { 1278 base signature-type; 1279 description 1280 "This represents the YARA signatures."; 1281 reference 1282 "YARA: YARA signatures are explained."; 1283 } 1285 identity signature-snort { 1286 base signature-type; 1287 description 1288 "This represents the SNORT signatures."; 1289 reference 1290 "SNORT: SNORT signatures are explained."; 1291 } 1293 identity signature-suricata { 1294 base signature-type; 1295 description 1296 "This represents the SURICATA signatures."; 1297 reference 1298 "SURICATA: SURICATA signatures are explained."; 1299 } 1301 identity threat-feed-type { 1302 description 1303 "This represents the base identity for threat-feed."; 1304 } 1306 identity continent { 1307 description 1308 "Base identity for continent types. The continents are based 1309 on Encyclopedia Britannica"; 1310 reference 1311 "Encyclopedia Britannica: Continent"; 1312 } 1314 identity africa { 1315 base continent; 1316 description 1317 "Identity for Africa."; 1319 reference 1320 "Encyclopedia Britannica: Continent"; 1321 } 1323 identity asia { 1324 base continent; 1325 description 1326 "Identity for Asia."; 1327 reference 1328 "Encyclopedia Britannica: Continent"; 1329 } 1331 identity antarctica { 1332 base continent; 1333 description 1334 "Identity for Antarctica."; 1335 reference 1336 "Encyclopedia Britannica: Continent"; 1337 } 1339 identity europe { 1340 base continent; 1341 description 1342 "Identity for Europe."; 1343 reference 1344 "Encyclopedia Britannica: Continent"; 1345 } 1347 identity north-america { 1348 base continent; 1349 description 1350 "Identity for North America."; 1351 reference 1352 "Encyclopedia Britannica: Continent"; 1353 } 1355 identity south-america { 1356 base continent; 1357 description 1358 "Identity for South America."; 1359 reference 1360 "Encyclopedia Britannica: Continent"; 1361 } 1363 identity australia { 1364 base continent; 1365 description 1366 "Identity for Australia"; 1368 reference 1369 "Encyclopedia Britannica: Continent"; 1370 } 1372 /* 1373 * Typedefs 1374 */ 1375 typedef time { 1376 type string { 1377 pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' 1378 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 1379 } 1380 description 1381 "The time type represents an instance of time of zero-duration 1382 that recurs every day."; 1383 } 1385 typedef day { 1386 type enumeration { 1387 enum monday { 1388 description 1389 "This represents Monday."; 1390 } 1391 enum tuesday { 1392 description 1393 "This represents Tuesday."; 1394 } 1395 enum wednesday { 1396 description 1397 "This represents Wednesday"; 1398 } 1399 enum thursday { 1400 description 1401 "This represents Thursday."; 1402 } 1403 enum friday { 1404 description 1405 "This represents Friday."; 1406 } 1407 enum saturday { 1408 description 1409 "This represents Saturday."; 1410 } 1411 enum sunday { 1412 description 1413 "This represents Sunday."; 1414 } 1415 } 1416 description 1417 "The type for representing the day of the week."; 1418 } 1420 /* 1421 * Groupings 1422 */ 1424 grouping ipv4-list { 1425 description 1426 "Grouping for an IPv4 address list."; 1427 leaf-list ipv4 { 1428 type inet:ipv4-address-no-zone; 1429 description 1430 "This is the entry for an IPv4 address list."; 1431 } 1432 } 1434 grouping ipv6-list { 1435 description 1436 "Grouping for an IPv6 address list."; 1437 leaf-list ipv6 { 1438 type inet:ipv6-address-no-zone; 1439 description 1440 "This is the entry for an IPv6 address list."; 1441 } 1442 } 1444 grouping ipv4 { 1445 description 1446 "Grouping for an IPv4 address."; 1447 leaf ipv4 { 1448 type inet:ipv4-address-no-zone; 1449 description 1450 "This is the entry for an IPv4 address."; 1451 } 1452 } 1454 grouping ipv6 { 1455 description 1456 "Grouping for an IPv6 address."; 1457 leaf ipv6 { 1458 type inet:ipv6-address-no-zone; 1459 description 1460 "This is the entry for an IPv6 address."; 1461 } 1462 } 1463 grouping ip-address-info { 1464 description 1465 "There are two types to configure a security policy 1466 for an IP address, such as IPv4 adress and IPv6 address."; 1467 choice match-type { 1468 description 1469 "User can choose between IPv4 and IPv6."; 1470 case range-match-ipv4 { 1471 container range-ipv4-address { 1472 leaf start-ipv4-address { 1473 type inet:ipv4-address-no-zone; 1474 mandatory true; 1475 description 1476 "A start IPv4 address for a range match."; 1477 } 1478 leaf end-ipv4-address { 1479 type inet:ipv4-address-no-zone; 1480 mandatory true; 1481 description 1482 "An end IPv4 address for a range match."; 1483 } 1484 description 1485 "A range match for IPv4 addresses is provided. 1486 Note that the start IPv4 address must be lower than 1487 the end IPv4 address."; 1488 } 1489 } 1490 case range-match-ipv6 { 1491 container range-ipv6-address { 1492 leaf start-ipv6-address { 1493 type inet:ipv6-address-no-zone; 1494 mandatory true; 1495 description 1496 "A start IPv6 address for a range match."; 1497 } 1498 leaf end-ipv6-address { 1499 type inet:ipv6-address-no-zone; 1500 mandatory true; 1501 description 1502 "An end IPv6 address for a range match."; 1503 } 1504 description 1505 "A range match for IPv6 addresses is provided. 1506 Note that the start IPv6 address must be lower than 1507 the end IPv6 address."; 1508 } 1509 } 1510 } 1512 } 1514 grouping user-group { 1515 description 1516 "This group represents user group information such as name and 1517 ip-address."; 1518 leaf name { 1519 type string; 1520 description 1521 "This represents the name of a user-group. A user-group name 1522 is used to map a user-group's name (e.g., employees) to IP 1523 address(es), MAC address(es). 1524 It is dependent on implementation."; 1525 } 1526 leaf-list mac-address { 1527 type yang:mac-address; 1528 description 1529 "Represent the MAC Address of a user-group. A user-group 1530 can have multiple MAC Addresses."; 1531 } 1532 uses ip-address-info{ 1533 description 1534 "This represents the IP addresses of a user-group."; 1535 refine match-type{ 1536 mandatory true; 1537 } 1538 } 1539 } 1541 grouping device-group { 1542 description 1543 "This group represents device group information such as 1544 ip-address protocol."; 1545 leaf name { 1546 type string; 1547 description 1548 "This represents the name of a device-group."; 1549 } 1550 uses ip-address-info{ 1551 refine match-type{ 1552 mandatory true; 1553 } 1554 } 1555 leaf-list application-protocol { 1556 type identityref { 1557 base application-protocol; 1558 } 1559 description 1560 "This represents the application layer protocols of devices. 1561 If this is not set, it cannot support the appropriate 1562 protocol"; 1563 } 1564 } 1566 grouping location-group { 1567 description 1568 "This group represents location-group information such as 1569 geo-ip and continent."; 1570 leaf name { 1571 type string; 1572 description 1573 "This represents the name of a location."; 1574 } 1575 list geo-ip-ipv4 { 1576 key "ipv4-address"; 1577 description 1578 "This represents the list of IPv4 addresses based on a 1579 location."; 1580 leaf ipv4-address{ 1581 type inet:ipv4-address-no-zone; 1582 description 1583 "This represents an IPv4 geo-ip address of a location."; 1584 } 1585 leaf ipv4-prefix{ 1586 type inet:ipv4-prefix; 1587 description 1588 "This represents the prefix for the IPv4 addresses."; 1589 } 1590 } 1591 list geo-ip-ipv6 { 1592 key "ipv6-address"; 1593 description 1594 "This represents the list of IPv6 addresses based on a 1595 location."; 1596 leaf ipv6-address{ 1597 type inet:ipv6-address-no-zone; 1598 description 1599 "This represents an IPv6 geo-ip address of a location."; 1600 } 1601 leaf ipv6-prefix{ 1602 type inet:ipv6-prefix; 1603 description 1604 "This represents the prefix for the IPv6 addresses."; 1605 } 1606 } 1607 leaf continent { 1608 type identityref { 1609 base continent; 1610 } 1611 default asia; 1612 description 1613 "location-group has geo-ip addresses of the corresponding 1614 continent."; 1615 } 1616 reference 1617 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1618 An access control for a geographical location (i.e., 1619 geolocation) that has the corresponding IP prefix."; 1620 } 1622 grouping payload-string { 1623 description 1624 "The grouping for payload-string content. It contains 1625 information such as name and string content."; 1626 leaf description { 1627 type string; 1628 description 1629 "This represents the description of a payload. If this is 1630 not set, it cannot support the description of how the 1631 payload content is related to a security attack."; 1632 } 1633 leaf-list content { 1634 type string; 1635 description 1636 "This represents the string of the payload contents. 1637 This content leaf-list contains the payload of a packet to 1638 analyze a threat. Due to the types of threats, the type of 1639 the content is defined as a string to accommodate any kind 1640 of a payload type such as HTTP, HTTPS, and SIP. If this is 1641 not set, it cannot support the payload contents involved in 1642 a security attack as a string."; 1643 } 1644 } 1646 list i2nsf-cfi-policy { 1647 key "name"; 1648 description 1649 "This is a security policy list. Each policy in the list 1650 contains a list of security policy rules, and is a policy 1651 instance to have the information of where and when a policy 1652 needs to be applied."; 1653 leaf name { 1654 type string; 1655 description 1656 "The name which identifies the policy."; 1657 } 1658 leaf resolution-strategy { 1659 type identityref { 1660 base resolution-strategy; 1661 } 1662 default fmr; 1663 description 1664 "The resolution strategies that can be used to 1665 specify how to resolve conflicts that occur between 1666 actions of the same or different policy rules that 1667 are matched and contained in this particular NSF"; 1669 reference 1670 "draft-ietf-i2nsf-capability-data-model-22: 1671 I2NSF Capability YANG Data Model - Resolution strategy"; 1672 } 1673 list rules { 1674 key "name"; 1676 description 1677 "There can be a single or multiple number of rules."; 1678 leaf name { 1679 type string; 1680 description 1681 "This represents the name for a rule."; 1682 } 1684 leaf priority { 1685 type uint8 { 1686 range "1..255"; 1687 } 1688 description 1689 "The priority keyword comes with a mandatory 1690 numeric value which can range from 1 through 255. 1691 Note that a higher number means a higher priority"; 1692 } 1694 container event { 1695 description 1696 "This represents an event (i.e., a security event), for 1697 which a security rule is made."; 1698 leaf security-event { 1699 type identityref { 1700 base security-event; 1701 } 1702 description 1703 "This contains the description of a security event. If 1704 this is not set, it cannot support what security event 1705 will be enforced."; 1706 } 1708 container time { 1709 description 1710 "The time when a security policy rule should be 1711 applied."; 1712 leaf start-date-time { 1713 type yang:date-and-time; 1714 description 1715 "This is the start date and time for a security policy 1716 rule."; 1717 } 1718 leaf end-date-time { 1719 type yang:date-and-time; 1720 description 1721 "This is the end date and time for a security policy 1722 rule. The policy rule will stop working after the 1723 specified end date and time."; 1724 } 1725 container period { 1726 when 1727 "../frequency!='only-once'"; 1728 description 1729 "This represents the repetition time. In the case 1730 where the frequency is weekly, the days can be set."; 1731 leaf start-time { 1732 type time; 1733 description 1734 "This is a period's start time for an event."; 1735 } 1736 leaf end-time { 1737 type time; 1738 description 1739 "This is a period's end time for an event."; 1740 } 1741 leaf-list day { 1742 when 1743 "../../frequency='weekly'"; 1744 type day; 1745 min-elements 1; 1746 description 1747 "This represents the repeated day of every week 1748 (e.g., Monday and Tuesday). More than one day can be 1749 specified."; 1750 } 1751 leaf-list date { 1752 when 1753 "../../frequency='monthly'"; 1754 type int32{ 1755 range "1..31"; 1756 } 1757 min-elements 1; 1758 description 1759 "This represents the repeated date of every month. 1760 More than one date can be specified."; 1761 } 1762 leaf-list month { 1763 when 1764 "../../frequency='yearly'"; 1765 type string{ 1766 pattern '\d{2}-\d{2}'; 1767 } 1768 min-elements 1; 1769 description 1770 "This represents the repeated date and month of every 1771 year. More than one can be specified. A pattern 1772 used here is Month and Date (MM-DD)."; 1773 } 1774 } 1776 leaf frequency { 1777 type enumeration { 1778 enum only-once { 1779 description 1780 "This represents that the rule is immediately 1781 enforced only once and not repeated. The policy 1782 will continuously be active from the 1783 start-date-time to the end-date-time."; 1784 } 1785 enum daily { 1786 description 1787 "This represents that the rule is enforced on a 1788 daily basis. The policy will be repeated daily 1789 until the end-date-time."; 1790 } 1791 enum weekly { 1792 description 1793 "This represents that the rule is enforced on a 1794 weekly basis. The policy will be repeated weekly 1795 until the end-date-time. The repeated days can be 1796 specified."; 1797 } 1798 enum monthly { 1799 description 1800 "This represents that the rule is enforced on a 1801 monthly basis. The policy will be repeated monthly 1802 until the end-date-time."; 1803 } 1804 enum yearly { 1805 description 1806 "This represents that the rule is enforced on a 1807 yearly basis. The policy will be repeated yearly 1808 until the end-date-time."; 1809 } 1810 } 1811 default only-once; 1812 description 1813 "This represents how frequently the rule should be 1814 enforced."; 1815 } 1816 } 1817 } 1819 container condition { 1820 description 1821 "Conditions for general security policies."; 1822 container firewall-condition { 1823 description 1824 "A general firewall condition based on the packet 1825 header."; 1826 leaf-list source { 1827 type union { 1828 type leafref { 1829 path 1830 "/i2nsf-cfi-policy/endpoint-groups/" 1831 +"user-group/name"; 1832 } 1833 type leafref { 1834 path 1835 "/i2nsf-cfi-policy/endpoint-groups/" 1836 +"device-group/name"; 1837 } 1838 } 1839 description 1840 "This describes the path of the source."; 1841 } 1843 leaf-list destination { 1844 type union { 1845 type leafref { 1846 path 1847 "/i2nsf-cfi-policy/endpoint-groups/" 1849 +"user-group/name"; 1850 } 1851 type leafref { 1852 path 1853 "/i2nsf-cfi-policy/endpoint-groups/" 1854 +"device-group/name"; 1855 } 1856 } 1857 description 1858 "This describes the path to the destinations."; 1859 } 1861 leaf transport-layer-protocol { 1862 type identityref { 1863 base transport-protocol; 1864 } 1865 description 1866 "The transport-layer protocol to be matched."; 1867 } 1869 container range-port-number { 1870 leaf start-port-number { 1871 type inet:port-number; 1872 description 1873 "A start port number for range match."; 1874 } 1875 leaf end-port-number { 1876 type inet:port-number; 1877 description 1878 "An end port number for range match."; 1879 } 1880 description 1881 "A range match for transport-layer port number. Note 1882 that the start port number value must be lower than 1883 the end port number value"; 1884 } 1886 list icmp { 1887 key "version"; 1888 description 1889 "Represents the ICMP packet header information to 1890 determine if the set of policy actions in this ECA 1891 policy rule should be executed or not."; 1892 reference 1893 "RFC 792: Internet Control Message Protocol 1894 RFC 8335: PROBE: A Utility for Probing Interfaces"; 1896 leaf version { 1897 type enumeration { 1898 enum icmpv4 { 1899 value "1"; 1900 description 1901 "The ICMPv4 Protocol as defined in RFC 792"; 1902 } 1903 enum icmpv6 { 1904 value "2"; 1905 description 1906 "The ICMPv6 Protocol as defined in RFC 4443"; 1907 } 1908 } 1909 description 1910 "The ICMP version to be matched. This value 1911 affected the type and code values."; 1912 reference 1913 "RFC 792: Internet Control Message Protocol 1914 RFC 4443: Internet Control Message Protocol (ICMPv6) 1915 for the Internet Protocol Version 6 (IPv6) 1916 Specification"; 1917 } 1919 leaf-list type { 1920 type uint8; 1921 description 1922 "The security policy rule according to 1923 ICMP type parameter."; 1924 reference 1925 "RFC 792: Internet Control Message Protocol 1926 RFC 8335: PROBE: A Utility for Probing Interfaces 1927 IANA: Internet Control Message Protocol (ICMP) 1928 Parameters 1929 IANA: Internet Control Message Protocol version 6 1930 (ICMPv6) Parameters"; 1931 } 1933 leaf-list code { 1934 type uint8; 1935 description 1936 "The security policy rule according to 1937 ICMP code parameter."; 1938 reference 1939 "RFC 792: Internet Control Message Protocol 1940 RFC 8335: PROBE: A Utility for Probing Interfaces 1941 IANA: Internet Control Message Protocol (ICMP) 1942 Parameters 1943 IANA: Internet Control Message Protocol version 6 1944 (ICMPv6) Parameters"; 1946 } 1947 } 1948 } 1950 container ddos-condition { 1951 description 1952 "A condition for a DDoS attack."; 1953 container rate-limit { 1954 description 1955 "This describes the rate-limit."; 1956 leaf packet-rate-threshold { 1957 type uint32; 1958 description 1959 "This is a trigger value for a rate limit of packet 1960 rate for a DDoS-attack mitigation."; 1961 } 1962 leaf byte-rate-threshold { 1963 type uint64; 1964 description 1965 "This is a trigger value for a rate limit of byte 1966 rate for a DDoS-attack mitigation."; 1967 } 1968 leaf flow-rate-threshold { 1969 type uint32; 1970 description 1971 "This is a trigger value for a rate limit of flow 1972 rate for a DDoS-attack mitigation."; 1973 } 1974 } 1975 } 1977 container anti-virus-condition { 1978 description 1979 "A condition for anti-virus"; 1981 leaf-list exception-files { 1982 type string; 1983 description 1984 "The type or name of the files to be excluded by the 1985 anti-virus. This can be used to keep the known 1986 harmless files."; 1987 } 1988 } 1990 container payload-condition { 1991 description 1992 "A condition based on a packet's content."; 1993 leaf-list content { 1994 type leafref { 1995 path "/i2nsf-cfi-policy/threat-preventions/" 1996 + "payload-content/name"; 1997 } 1998 description 1999 "This describes the paths to a packet content's"; 2000 } 2001 } 2003 container url-condition { 2004 description 2005 "Condition for url category"; 2006 leaf url-name { 2007 type leafref { 2008 path 2009 "/i2nsf-cfi-policy/endpoint-groups/" 2010 +"url-group/name"; 2011 } 2012 description 2013 "This is description for the condition of a URL's 2014 category such as SNS sites, game sites, ecommerce 2015 sites, company sites, and university sites."; 2016 } 2017 } 2019 container voice-condition { 2020 description 2021 "For the VoIP/VoLTE security system, a VoIP/ 2022 VoLTE security system can monitor each 2023 VoIP/VoLTE flow and manage VoIP/VoLTE 2024 security rules controlled by a centralized 2025 server for VoIP/VoLTE security service 2026 (called VoIP IPS). The VoIP/VoLTE security 2027 system controls each switch for the 2028 VoIP/VoLTE call flow management by 2029 manipulating the rules that can be added, 2030 deleted, or modified dynamically."; 2031 reference 2032 "RFC 3261: SIP: Session Initiation Protocol"; 2034 leaf-list source-id { 2035 type string; 2036 description 2037 "The security policy rule according to 2038 a source voice ID for VoIP and VoLTE."; 2039 } 2041 leaf-list destination-id { 2042 type string; 2043 description 2044 "The security policy rule according to 2045 a destination voice ID for VoIP and VoLTE."; 2046 } 2048 leaf-list user-agent { 2049 type string; 2050 description 2051 "The security policy rule according to 2052 an user agent for VoIP and VoLTE."; 2053 } 2054 } 2056 container context-condition { 2057 description 2058 "Condition for matching the context of the packet, such 2059 as geographic location, time, packet direction"; 2060 container geographic-location { 2061 description 2062 "A condition for a location-based connection"; 2063 leaf-list source { 2064 type leafref { 2065 path 2066 "/i2nsf-cfi-policy/endpoint-groups/" 2067 +"location-group/name"; 2068 } 2069 description 2070 "This describes the paths to a location's sources."; 2071 } 2072 leaf-list destination { 2073 type leafref { 2074 path 2075 "/i2nsf-cfi-policy/endpoint-groups/" 2076 +"location-group/name"; 2077 } 2078 description 2079 "This describes the paths to a location's 2080 destinations."; 2081 } 2082 } 2083 } 2085 container threat-feed-condition { 2086 description 2087 "A condition based on the threat-feed information."; 2088 leaf-list name { 2089 type leafref { 2090 path 2091 "/i2nsf-cfi-policy/threat-preventions/" 2092 +"threat-feed-list/name"; 2093 } 2094 description 2095 "This describes the paths to a threat-feed's sources."; 2096 } 2097 } 2098 } 2100 container actions { 2101 description 2102 "This is the action container."; 2103 container primary-action { 2104 description 2105 "This represents primary actions (e.g., ingress and 2106 egress actions) to be applied to a condition. 2107 If this is not set, it cannot support the primary 2108 actions."; 2109 leaf action { 2110 type identityref { 2111 base primary-action; 2112 } 2113 description 2114 "Ingress actions: pass, drop, reject, rate-limit, 2115 and mirror. 2116 Egress actions: mirror, invoke-signaling, 2117 tunnel-encapsulation, forwarding, and redirection."; 2118 } 2119 } 2120 container secondary-action { 2121 description 2122 "This represents secondary actions (e.g., log and syslog) 2123 to be applied if they are needed. If this is not set, 2124 it cannot support the secondary actions."; 2125 leaf log-action { 2126 type identityref { 2127 base secondary-action; 2128 } 2129 description 2130 "Log action: rule log and session log"; 2131 } 2132 } 2133 } 2134 } 2136 container endpoint-groups { 2137 description 2138 "A logical entity in a business environment, where a security 2139 policy is to be applied."; 2140 list user-group{ 2141 uses user-group; 2142 key "name"; 2143 description 2144 "This represents a user group."; 2145 } 2146 list device-group { 2147 key "name"; 2148 uses device-group; 2149 description 2150 "This represents a device group."; 2151 } 2152 list location-group{ 2153 key "name"; 2154 uses location-group; 2155 description 2156 "This represents a location group."; 2157 } 2158 list url-group { 2159 key "name"; 2160 description 2161 "This describes the list of URL."; 2162 leaf name { 2163 type string; 2164 description 2165 "This is the name of URL group, e.g., SNS sites, 2166 gaming sites, ecommerce sites"; 2167 } 2168 leaf-list url { 2169 type string; 2170 description 2171 "Specifies the URL to be added into the group."; 2172 } 2173 } 2174 } 2176 container threat-preventions { 2177 description 2178 "This describes the list of threat-preventions."; 2179 list threat-feed-list { 2180 key "name"; 2181 description 2182 "There can be a single or multiple number of 2183 threat-feeds."; 2184 leaf name { 2185 type string; 2186 description 2187 "This represents the name of the threat-feed."; 2188 } 2189 leaf description { 2190 type string; 2191 description 2192 "This represents the descriptions of a threat-feed. The 2193 description should include information, such as type, 2194 threat, method, and file type. Structured Threat 2195 Information Expression (STIX) can be used for 2196 description of a threat [STIX]."; 2197 } 2198 leaf-list signatures { 2199 type identityref { 2200 base signature-type; 2201 } 2202 description 2203 "This contains a list of signatures or hashes of the 2204 threats."; 2205 } 2206 } 2207 list payload-content { 2208 key "name"; 2209 leaf name { 2210 type string; 2211 description 2212 "This represents the name of a packet's payload-content. 2213 It should give an idea of why a specific payload content 2214 is marked as a threat. For example, the name 'backdoor' 2215 indicates the payload content is related to a backdoor 2216 attack."; 2217 } 2218 description 2219 "This represents a payload-string group."; 2220 uses payload-string; 2221 } 2222 } 2223 } 2224 } 2225 2227 Figure 18: YANG for Consumer-Facing Interface 2229 8. XML Configuration Examples of High-Level Security Policy Rules 2231 This section shows XML configuration examples of high-level security 2232 policy rules that are delivered from the I2NSF User to the Security 2233 Controller over the Consumer-Facing Interface. The considered use 2234 cases are: Database registration, time-based firewall for web 2235 filtering, VoIP/VoLTE security service, and DDoS-attack mitigation. 2237 8.1. Database Registration: Information of Positions and Devices 2238 (Endpoint Group) 2240 If new endpoints are introduced to the network, it is necessary to 2241 first register their data to the database. For example, if new 2242 members are newly introduced in either of three different groups 2243 (i.e., user-group, device-group, and url-group), each of them should 2244 be registered with information such as ip-addresses or protocols used 2245 by devices. 2247 Figure 19 shows an example XML representation of the registered 2248 information for the user-group and device-group with IPv4 addresses 2249 [RFC5737]. 2251 2252 2254 security_policy_for_blocking_sns 2255 2256 2257 employees 2258 2259 192.0.2.11 2260 192.0.2.90 2261 2262 2263 2264 webservers 2265 2266 198.51.100.11 2267 198.51.100.20 2268 2269 nsfcfi:http 2270 nsfcfi:https 2271 2272 2273 sns-websites 2274 SNS_1 2275 SNS_2 2276 2277 2278 2280 Figure 19: Registering User-group and Device-group Information 2281 with IPv4 Addresses 2283 Also, Figure 20 shows an example XML representation of the registered 2284 information for the user-group and device-group with IPv6 addresses 2285 [RFC3849]. 2287 2288 2290 security_policy_for_blocking_sns 2291 2292 2293 employees 2294 2295 2001:db8:0:1::11 2296 2001:db8:0:1::90 2297 2298 2299 2300 webservers 2301 2302 2001:db8:0:2::11 2303 2001:db8:0:2::20 2304 2305 nsfcfi:http 2306 nsfcfi:https 2307 2308 2309 sns-websites 2310 SNS_1 2311 SNS_2 2312 2313 2314 2316 Figure 20: Registering User-group and Device-group Information 2317 with IPv6 Addresses 2319 8.2. Scenario 1: Block SNS Access during Business Hours 2321 The first example scenario is to "block SNS access during office 2322 hours" using a time-based firewall policy. In this scenario, all 2323 users registered as "employees" in the user-group list are unable to 2324 access Social Networking Services (SNS) during the office hours 2325 (weekdays). The XML instance is described below: 2327 2328 2330 security_policy_for_blocking_sns 2331 2332 block_access_to_sns_during_office_hours 2333 2334 2348 2349 2350 2351 employees 2352 2353 2354 sns-websites 2355 2356 2357 2358 2359 nsfcfi:drop 2360 2361 2362 2363 2365 Figure 21: An XML Example for Time-based Firewall 2367 Time-based-condition Firewall 2369 1. The policy name is "security_policy_for_blocking_sns". 2371 2. The rule name is "block_access_to_sns_during_office_hours". 2373 3. The Source is "employees". 2375 4. The destination target is "sns-websites". "sns-websites" is the 2376 key which represents the list containing the information, such as 2377 URL, about sns-websites. 2379 5. The action required is to "drop" any attempt to connect to 2380 websites related to Social networking. 2382 8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a Company 2384 The second example scenario is to "block malicious VoIP/VoLTE packets 2385 coming to a company" using a VoIP policy. In this scenario, the 2386 calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that 2387 are classified as malicious are dropped. The IP addresses of the 2388 employees and malicious VOIP IDs should be blocked are stored in the 2389 database or datastore of the enterprise. Here and the rest of the 2390 cases assume that the security administrators or someone responsible 2391 for the existing and newly generated policies, are not aware of which 2392 and/or how many NSFs are needed to meet the security requirements. 2393 Figure 22 represents the XML document generated from YANG discussed 2394 in previous sections. Once a high-level seucurity policy is created 2395 by a security admin, it is delivered by the Consumer-Facing 2396 Interface, through RESTCONF server, to the security controller. The 2397 XML instance is described below: 2399 2400 2402 2403 security_policy_for_blocking_malicious_voip_packets 2404 2405 2406 Block_malicious_voip_and_volte_packets 2407 2408 2409 malicious-id 2410 2411 2412 employees 2413 2414 2415 2416 2417 nsfcfi:drop 2418 2419 2420 2421 2422 Figure 22: An XML Example for VoIP Security Service 2424 Custom-condition Firewall 2426 1. The policy name is 2427 "security_policy_for_blocking_malicious_voip_packets". 2429 2. The rule name is "Block_malicious_voip_and_volte_packets". 2431 3. The Source is "malicious-id". This can be a single ID or a list 2432 of IDs, depending on how the ID are stored in the database. The 2433 "malicious-id" is the key so that the security admin can read 2434 every stored malicious VOIP IDs that are named as "malicious-id". 2436 4. The destination target is "employees". "employees" is the key 2437 which represents the list containing information about employees, 2438 such as IP addresses. 2440 5. The action required is "drop" when any incoming packets are from 2441 "malicious-id". 2443 8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web 2444 Server 2446 The third example scenario is to "Mitigate HTTP and HTTPS flood 2447 attacks on a company web server" using a DDoS-attack mitigation 2448 policy. Here, the time information is not set because the service 2449 provided by the network should be maintained at all times. If the 2450 packets sent by any sources are more than the set threshold, then the 2451 admin can set the percentage of the packets to be dropped to safely 2452 maintain the service. In this scenario, the source is set as "any" 2453 to block any sources which send abnormal amount of packets. The 2454 destination is set as "web_server01". Once the rule is set and 2455 delivered and enforced to the nsfs by the securiy controller, the 2456 NSFs will monitor the incoming packet amounts and the destination to 2457 act according to the rule set. The XML instance is described below: 2459 2460 2462 security_policy_for_ddos_attacks 2463 2464 1000_packets_per_second 2465 2466 2467 2468 1000 2469 2470 2471 2472 2473 2474 drop 2475 2476 2477 2478 2480 Figure 23: An XML Example for DDoS-attack Mitigation 2482 DDoS-condition Firewall 2484 1. The policy name is "security_policy_for_ddos_attacks". 2486 2. The rule name is "1000_packets_per_second". 2488 3. The rate limit exists to limit the incoming amount of packets per 2489 second. In this case the rate limit is "1000" packets per 2490 second. This amount depends on the packet receiving capacity of 2491 the server devices. 2493 4. The Source is all sources which send abnormal amount of packets. 2495 5. The action required is to "drop" packet reception is more than 2496 1000 packets per second. 2498 9. XML Configuration Example of a User Group's Access Control for I2NSF 2499 Consumer-Facing Interface 2501 This is an example for creating privileges for a group of users 2502 (i.e., a user group) to access and use the I2NSF Consumer-Facing 2503 Interface to create security policies via the interface. For the 2504 access control of the Consumer-Facing Interface, the NACM module can 2505 be used. Figure 24 shows an XML example the access control of a user 2506 group (named Example-Group) for I2NSF Consumer-Facing Interface A 2507 group called Example-Group can be created and configured with NACM 2508 for the Consumer-Facing Interface. For Example-Group, a rule list 2509 can created with the name of Example-Group-Rules. Example-Group- 2510 Rules has two rules of Example-Group-Rule1 and Example-Group-Rule2 as 2511 follows. For Example-Group-Rule1, the privilege of "Read" is allowed 2512 to Example-Group for the Consumer-Facing Interface. On the other 2513 hand, for Example-Group-Rule2, the privileges of "Create", "Update", 2514 and "Delete" are denied against Example-Group for the Consumer-Facing 2515 Interface. 2517 2518 2519 true 2520 2521 2522 Example-Group 2523 Alice 2524 Bob 2525 Eve 2526 2527 2528 2529 Example-Group-Rules 2530 Example-Group 2531 2532 Example-Group-Rule1 2533 read 2534 ietf-i2nsf-cfi-policy 2535 permit 2536 2537 2538 Example-Group-Rule2 2539 create update delete 2540 ietf-i2nsf-cfi-policy 2541 deny 2542 2543 2544 2545 Figure 24: An XML Example of a User Group's Access Control for 2546 I2NSF Consumer- Facing Interface 2548 The access control for the I2NSF Consumer-Facing Interface is as 2549 follows. 2551 1. The NACM is enabled. 2553 2. As a group name, Example-Group is specified. 2555 3. As members of the group, Alice, Bob, and Eve are specified. 2557 4. As a rule list name, Example-Group-Rules is specified for 2558 managing privileges of Example-Group's members. 2560 5. As the first rule name, Example-Group-Rule1 is specified. This 2561 rule is used to give read privilege to Example-Group's members 2562 for the module of the I2NSF Consumer-Facing Interface. 2564 6. As the second rule name, Example-Group-Rule2 is specified. This 2565 rule is used to deny create, update, and delete privileges 2566 against Example-Group's members for the module of the I2NSF 2567 Consumer-Facing Interface. 2569 10. IANA Considerations 2571 This document requests IANA to register the following URI in the 2572 "IETF XML Registry" [RFC3688]: 2574 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2575 Registrant Contact: The IESG. 2576 XML: N/A; the requested URI is an XML namespace. 2578 This document requests IANA to register the following YANG module in 2579 the "YANG Module Names" registry [RFC7950][RFC8525]: 2581 name: ietf-i2nsf-cfi-policy 2582 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2583 prefix: nsfcfi 2584 reference: RFC XXXX 2586 // RFC Ed.: replace XXXX with an actual RFC number and remove 2587 // this note. 2589 11. Security Considerations 2591 The YANG module specified in this document defines a data schema 2592 designed to be accessed through network management protocols such as 2593 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 2594 the secure transport layer, and the required secure transport is 2595 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 2596 and the required secure transport is TLS [RFC8446]. 2598 The Network Configuration Access Control Model (NACM) [RFC8341] 2599 provides a means of restricting access to specific NETCONF or 2600 RESTCONF users to a preconfigured subset of all available NETCONF or 2601 RESTCONF protocol operations and contents. Thus, NACM SHOULD be used 2602 to restrict the NSF registration from unauthorized users. 2604 There are a number of data nodes defined in this YANG module that are 2605 writable, creatable, and deletable (i.e., config true, which is the 2606 default). These data nodes may be considered sensitive or vulnerable 2607 in some network environments. Write operations to these data nodes 2608 could have a negative effect on network and security operations. 2609 These data nodes are collected into a single list node with the 2610 following sensitivity/vulnerability: 2612 * list i2nsf-cfi-policy: Writing to almost any element of this YANG 2613 module would directly impact on the configuration of NSFs, e.g., 2614 completely turning off security monitoring and mitigation 2615 capabilities; altering the scope of this monitoring and 2616 mitigation; creating an overwhelming logging volume to overwhelm 2617 downstream analytics or storage capacity; creating logging 2618 patterns which are confusing; or rendering useless trained 2619 statistics or artificial intelligence models. 2621 Some of the readable data nodes in this YANG module may be considered 2622 sensitive or vulnerable in some network environments. It is thus 2623 important to control read access (e.g., via get, get-config, or 2624 notification) to these data nodes. These are the subtrees and data 2625 nodes with their sensitivity/vulnerability: 2627 * list i2nsf-cfi-policy: The leak of this node to an attacker could 2628 reveal the specific configuration of security controls to an 2629 attacker. An attacker can craft an attack path that avoids 2630 observation or mitigations; one may reveal topology information to 2631 inform additional targets or enable lateral movement; one enables 2632 the construction of an attack path that avoids observation or 2633 mitigations; one provides an indication that the operator has 2634 discovered the attack. This node also holds a list of endpoint 2635 data that is considered private to the users. 2637 12. Acknowledgments 2639 This document is a product by the I2NSF Working Group (WG) including 2640 WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This 2641 document took advantage of the review and comments from the following 2642 people: Roman Danyliw, Mahdi F. Dachmehchi, Daeyoung Hyun, Jan 2643 Lindblad (YANG doctor), and Tom Petch. We authors sincerely 2644 appreciate their sincere efforts and kind help. 2646 This work was supported by Institute of Information & Communications 2647 Technology Planning & Evaluation (IITP) grant funded by the Korea 2648 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 2649 Security Intelligence Technology Development for the Customized 2650 Security Service Provisioning). This work was supported in part by 2651 the IITP (2020-0-00395, Standard Development of Blockchain based 2652 Network Management Automation Technology). 2654 13. Contributors 2656 The following are co-authors of this document: 2658 Patrick Lingga - Department of Electrical and Computer Engineering, 2659 Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, Gyeonggi-do 2660 16419, Republic of Korea, EMail: patricklink@skku.edu 2662 Hyoungshick Kim - Department of Computer Science and Engineering, 2663 Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, Gyeonggi-do 2664 16419, Republic of Korea, EMail: hyoung@skku.edu 2666 Eunsoo Kim - Department of Electronic, Electrical and Computer 2667 Engineering, Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, 2668 Gyeonggi-do 16419, Republic of Korea, EMail: eskim86@skku.edu 2670 Seungjin Lee - Department of Electronic, Electrical and Computer 2671 Engineering, Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, 2672 Gyeonggi-do 16419, Republic of Korea, EMail: jine33@skku.edu 2674 Jinyong (Tim) Kim - Department of Electronic, Electrical and Computer 2675 Engineering, Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, 2676 Gyeonggi-do 16419, Republic of Korea, EMail: timkim@skku.edu 2678 Anil Lohiya - Juniper Networks, 1133 Innovation Way, Sunnyvale, CA 2679 94089, US, EMail: alohiya@juniper.net 2681 Dave Qi - Bloomberg, 731 Lexington Avenue, New York, NY 10022, US, 2682 EMail: DQI@bloomberg.net 2683 Nabil Bitar - Nokia, 755 Ravendale Drive, Mountain View, CA 94043, 2684 US, EMail: nabil.bitar@nokia.com 2686 Senad Palislamovic - Nokia, 755 Ravendale Drive, Mountain View, CA 2687 94043, US, EMail: senad.palislamovic@nokia.com 2689 Liang Xia - Huawei, 101 Software Avenue, Nanjing, Jiangsu 210012, 2690 China, EMail: Frank.Xialiang@huawei.com 2692 14. References 2694 14.1. Normative References 2696 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2697 DOI 10.17487/RFC0768, August 1980, 2698 . 2700 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2701 RFC 792, DOI 10.17487/RFC0792, September 1981, 2702 . 2704 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2705 RFC 793, DOI 10.17487/RFC0793, September 1981, 2706 . 2708 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 2709 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 2710 1983, . 2712 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2713 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 2714 . 2716 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2717 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 2718 . 2720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2721 Requirement Levels", BCP 14, RFC 2119, 2722 DOI 10.17487/RFC2119, March 1997, 2723 . 2725 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2726 A., Peterson, J., Sparks, R., Handley, M., and E. 2727 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2728 DOI 10.17487/RFC3261, June 2002, 2729 . 2731 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 2732 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 2733 . 2735 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2736 DOI 10.17487/RFC3688, January 2004, 2737 . 2739 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 2740 Protocol Assigned Numbers", RFC 4250, 2741 DOI 10.17487/RFC4250, January 2006, 2742 . 2744 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2745 Congestion Control Protocol (DCCP)", RFC 4340, 2746 DOI 10.17487/RFC4340, March 2006, 2747 . 2749 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2750 Control Message Protocol (ICMPv6) for the Internet 2751 Protocol Version 6 (IPv6) Specification", STD 89, 2752 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2753 . 2755 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2756 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2757 . 2759 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2760 DOI 10.17487/RFC5321, October 2008, 2761 . 2763 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2764 and A. Bierman, Ed., "Network Configuration Protocol 2765 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2766 . 2768 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2769 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2770 . 2772 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2773 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2774 . 2776 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2777 Protocol (HTTP/1.1): Message Syntax and Routing", 2778 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2779 . 2781 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2782 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2783 DOI 10.17487/RFC7231, June 2014, 2784 . 2786 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2787 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2788 . 2790 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2791 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2792 . 2794 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2795 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2796 May 2017, . 2798 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2799 Kumar, "Framework for Interface to Network Security 2800 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2801 . 2803 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 2804 Boucadair, "PROBE: A Utility for Probing Interfaces", 2805 RFC 8335, DOI 10.17487/RFC8335, February 2018, 2806 . 2808 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2809 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2810 . 2812 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2813 Access Control Model", STD 91, RFC 8341, 2814 DOI 10.17487/RFC8341, March 2018, 2815 . 2817 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2818 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2819 DOI 10.17487/RFC8407, October 2018, 2820 . 2822 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2823 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2824 . 2826 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 2827 and R. Wilton, "YANG Library", RFC 8525, 2828 DOI 10.17487/RFC8525, March 2019, 2829 . 2831 [I-D.ietf-i2nsf-capability] 2832 Xia, L., Strassner, J., Basile, C., and D. R. Lopez, 2833 "Information Model of NSFs Capabilities", Work in 2834 Progress, Internet-Draft, draft-ietf-i2nsf-capability-05, 2835 24 April 2019, . 2838 [I-D.ietf-tcpm-rfc793bis] 2839 Eddy, W. M., "Transmission Control Protocol (TCP) 2840 Specification", Work in Progress, Internet-Draft, draft- 2841 ietf-tcpm-rfc793bis-25, 7 September 2021, 2842 . 2845 14.2. Informative References 2847 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2848 DOI 10.17487/RFC2818, May 2000, 2849 . 2851 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2852 Address Translator (Traditional NAT)", RFC 3022, 2853 DOI 10.17487/RFC3022, January 2001, 2854 . 2856 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2857 Information Models and Data Models", RFC 3444, 2858 DOI 10.17487/RFC3444, January 2003, 2859 . 2861 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 2862 Reserved for Documentation", RFC 3849, 2863 DOI 10.17487/RFC3849, July 2004, 2864 . 2866 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 2867 Reserved for Documentation", RFC 5737, 2868 DOI 10.17487/RFC5737, January 2010, 2869 . 2871 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 2872 Kumari, "A Format for Self-Published IP Geolocation 2873 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 2874 . 2876 [IANA-ICMP-Parameters] 2877 Internet Assigned Numbers Authority (IANA), "Assigned 2878 Internet Protocol Numbers", February 2021, 2879 . 2882 [IANA-ICMPv6-Parameters] 2883 Internet Assigned Numbers Authority (IANA), "Internet 2884 Control Message Procotol version 6 (ICMPv6) Parameters", 2885 February 2021, . 2888 [Encyclopedia-Britannica] 2889 Britannica, "Continent", September 2020, 2890 . 2892 [YARA] Alvarez, V., Bengen, H., Metz, J., Buehlmann, S., and W. 2893 Shields, "YARA", YARA 2894 Documents https://yara.readthedocs.io/en/v3.5.0/, August 2895 2020. 2897 [SURICATA] Julien, V. and , "SURICATA", SURICATA Documents 2898 https://suricata-ids.org/docs/, August 2020. 2900 [SNORT] Roesch, M., Green, C., and B. Caswell, "SNORT", SNORT 2901 Documents https://www.snort.org/#documents, August 2020. 2903 [STIX] Jordan, B., Piazza, R., and T. Darley, "Structured Threat 2904 Information Expression (STIX)", STIX Version 2.1: 2905 Committee Specification 01 https://docs.oasis- 2906 open.org/cti/stix/v2.1/stix-v2.1.pdf, March 2020. 2908 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- 2909 dm-15 2911 The following changes are made from draft-ietf-i2nsf-consumer-facing- 2912 interface-dm-15: 2914 * This version has been updated to synchronize its contents with the 2915 contents in the other I2NSF YANG data model documents. 2917 Authors' Addresses 2918 Jaehoon (Paul) Jeong (editor) 2919 Department of Computer Science and Engineering 2920 Sungkyunkwan University 2921 2066 Seobu-Ro, Jangan-Gu 2922 Suwon 2923 Gyeonggi-Do 2924 16419 2925 Republic of Korea 2927 Phone: +82 31 299 4957 2928 Email: pauljeong@skku.edu 2929 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2931 Chaehong Chung 2932 Department of Electronic, Electrical and Computer Engineering 2933 Sungkyunkwan University 2934 2066 Seobu-Ro, Jangan-Gu 2935 Suwon 2936 Gyeonggi-Do 2937 16419 2938 Republic of Korea 2940 Phone: +82 31 299 4957 2941 Email: darkhong@skku.edu 2943 Tae-Jin Ahn 2944 Korea Telecom 2945 70 Yuseong-Ro, Yuseong-Gu 2946 Daejeon 2947 305-811 2948 Republic of Korea 2950 Phone: +82 42 870 8409 2951 Email: taejin.ahn@kt.com 2953 Rakesh Kumar 2954 Juniper Networks 2955 1133 Innovation Way 2956 Sunnyvale, CA 94089 2957 United States of America 2959 Email: rkkumar@juniper.net 2960 Susan Hares 2961 Huawei 2962 7453 Hickory Hill 2963 Saline, MI 48176 2964 United States of America 2966 Phone: +1-734-604-0332 2967 Email: shares@ndzh.com