idnits 2.17.1 draft-ietf-i2nsf-consumer-facing-interface-dm-15.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 275 has weird spacing: '...le-name str...' == Line 402 has weird spacing: '...version enu...' == Line 522 has weird spacing: '...address ine...' == Line 526 has weird spacing: '...address ine...' == Line 560 has weird spacing: '...address ine...' == (5 more instances...) -- The document date (15 September 2021) is 953 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 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == 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: 4 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: 19 March 2022 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 15 September 2021 13 I2NSF Consumer-Facing Interface YANG Data Model 14 draft-ietf-i2nsf-consumer-facing-interface-dm-15 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 19 March 2022. 47 Copyright Notice 49 Copyright (c) 2021 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 Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 47 83 8.1. Database Registration: Information of Positions and Devices 84 (Endpoint Group) . . . . . . . . . . . . . . . . . . . . 47 85 8.2. Scenario 1: Block SNS Access during Business Hours . . . 49 86 8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a 87 Company . . . . . . . . . . . . . . . . . . . . . . . . . 51 88 8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a 89 Company Web Server . . . . . . . . . . . . . . . . . . . 52 90 9. XML Configuration Example of a User Group's Access Control for 91 I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 53 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 55 94 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 95 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 57 96 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 97 14.1. Normative References . . . . . . . . . . . . . . . . . . 57 98 14.2. Informative References . . . . . . . . . . . . . . . . . 60 99 Appendix A. Changes from 100 draft-ietf-i2nsf-consumer-facing-interface-dm-14 . . . . 62 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 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* [policy-name] 236 +--rw policy-name string 237 +--rw resolution-strategy? identityref 238 +--rw rules* [rule-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 Rule-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* [rule-name] 275 | +--rw rule-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 time of the event. The 306 rule will start repeating from the specified time" 308 End-date-time: This represents the end time of the event. If the 309 rule time has pass the end-time, the rule will stop 310 repeating" 312 Period: This represents the period of time the rule event is 313 active. It can be configured by the start-time, stop-time, 314 day, date, and month. 316 Frequency: This represents how frequent the rule should be enforced. 317 There are four options: "only-once", "daily", "weekly", 318 "monthly" or "yearly". 320 +--rw event 321 | +--rw security-event? identityref 322 | +--rw time 323 | +--rw start-date-time? yang:date-and-time 324 | +--rw end-date-time? yang:date-and-time 325 | +--rw period 326 | | +--rw start-time? time 327 | | +--rw end-time? time 328 | | +--rw day* identityref 329 | | +--rw date* int32 330 | | +--rw month* string 331 | +--rw frequency? enumeration 333 Figure 4: Event Sub-model YANG Data Tree 335 3.2. Condition Sub-model 337 This object represents Conditions that Security Administrator wants 338 to apply the checking on the traffic in order to determine whether 339 the set of actions in the Rule can be executed or not. The Condition 340 Sub-model consists of three different types of containers each 341 representing different cases, such as general firewall and DDoS- 342 mitigation cases, and a case when the condition is based on the 343 payload strings of packets. Each containers have source and 344 destination-target to represent the source and destination for each 345 case. Figure 5 shows the YANG tree of the Condition object. The 346 Condition Sub-model SHALL have following information: 348 Case (firewall-condition): This field represents the general 349 firewall case, where a security admin can set up firewall 350 conditions using the information present in this field. 351 The source and destination is represented as source, 352 destination, transport layer protocol, port numbers, and 353 ICMP parameters. 355 Case (ddos-condition): This field represents the condition for DDoS 356 mitigation, where a security admin can set up DDoS 357 mitigation conditions using the information present in this 358 field. The rate of packet, byte, or flow threshold can be 359 configured to mitigate the DDoS. 361 Case (anti-virus-condition): This field represents the condition for 362 Antivirus, where a security admin can set up Antivirus 363 conditions using the information present in this field. 364 The file names or types can be configured to be allowed 365 without the Antivirus interuption. 367 Case (payload-condition): This field contains the payload string 368 information. This information is useful when security rule 369 condition is based on the string contents of incoming or 370 outgoing packets. The name referring to the payload-groups 371 defined and registered in the endpoint-groups. 373 Case (url-condition): This field represents the URL to be filtered. 374 This information can be used to block or allow a certain 375 URL or website. The url-name is a group of URL or websites 376 to be matched. 378 Case (voice-condition): This field contains the call source-id, call 379 destination-id, and user-agent. This information can be 380 used to filter a caller id or receiver id to prevent any 381 VoIP or VoLTE exploits or attack. 383 Case (context-condition): This field represents a context of a 384 packet or flow. The context can be extended. This module 385 provides a context of geography location. 387 Case (Threat-feed-condition): This field contains the information 388 obtained from threat-feeds (e.g., Palo-Alto, or RSA- 389 netwitness). This information is useful when security rule 390 condition is based on the existing threat reports gathered 391 by other sources. 393 +--rw condition 394 | +--rw firewall-condition 395 | | +--rw source* union 396 | | +--rw destination* union 397 | | +--rw transport-layer-protocol? identityref 398 | | +--rw range-port-number 399 | | | +--rw start-port-number? inet:port-number 400 | | | +--rw end-port-number? inet:port-number 401 | | +--rw icmp* [version] 402 | | +--rw version enumeration 403 | | +--rw type* uint8 404 | | +--rw code* uint8 405 | +--rw ddos-condition 406 | | +--rw rate-limit 407 | | +--rw packet-rate-threshold? uint32 408 | | +--rw byte-rate-threshold? uint32 409 | | +--rw flow-rate-threshold? uint32 410 | +--rw anti-virus-condition 411 | | +--rw exception-files* string 412 | +--rw payload-condition 413 | | +--rw content* 414 -> /i2nsf-cfi-policy/threat-preventions/payload-content/name 415 | +--rw url-condition 416 | | +--rw url-name? 417 -> /i2nsf-cfi-policy/endpoint-groups/url-group/name 418 | +--rw voice-condition 419 | | +--rw source-id* string 420 | | +--rw destination-id* string 421 | | +--rw user-agent* string 422 | +--rw context-condition 423 | +--rw geography-location-condition 424 | +--rw source* 425 -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 426 | +--rw destination* 427 -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 428 | | +--rw threat-feed-condition 429 | | +--rw name* 430 -> /i2nsf-cfi-policy/threat-preventions/threat-feed-list/name 432 Figure 5: Condition Sub-model YANG Data Tree 434 3.3. Action Sub-model 436 This object represents actions that Security Admin wants to perform 437 based on certain traffic class. Figure 6 shows the YANG tree of the 438 Action object. The Action object SHALL have following information: 440 Primary-action: This field identifies the action when a rule is 441 matched by an NSF. The action could be one of "pass", 442 "drop", "rate-limit", "mirror", "invoke-signaling", 443 "tunnel-encapsulation", "forwarding", and "transformation". 445 Secondary-action: This field identifies the action when a rule is 446 matched by an NSF. The action could be one of "rule-log" 447 and "session-log". 449 +--rw actions 450 | +--rw primary-action 451 | | +--rw action? identityref 452 | +--rw secondary-action 453 | +--rw log-action? identityref 455 Figure 6: Action Sub-model YANG Data Tree 457 4. Information Model for Policy Endpoint Groups 459 The Policy Endpoint Group is a very important part of building User- 460 Construct based policies. A Security Administrator would create and 461 use these objects to represent a logical entity in their business 462 environment, where a Security Policy is to be applied. There are 463 multiple managed objects that constitute a Policy's Endpoint Group, 464 as shown in Figure 7. Figure 8 shows the YANG tree of the Endpoint- 465 Groups object. This section lists these objects and relationship 466 among them. 468 It is assumed that the information of Endpoint Groups (e.g., User- 469 group, Device-group, and Location-group) such as the IP address(es) 470 of each member in a group are stored in the I2NSF database available 471 to the Security Controller, and that the IP address information of 472 each group in the I2NSF database is synchronized with other systems 473 in the networks under the same administration. 475 +-------------------+ 476 | Endpoint Groups | 477 +---------+---------+ 478 ^ 479 | 480 +--------------+-------+--------+---------------+ 481 0..n | 0..n | 0..n | 0..n | 482 +-----+----+ +------+-----+ +-------+------+ +-----+---+ 483 |User-group| |Device-group| |Location-group| |Url-group| 484 +----------+ +------------+ +--------------+ +---------+ 485 Figure 7: Endpoint Group Diagram 487 +--rw endpoint-groups 488 | +--rw user-group* [name] 489 | ... 490 | +--rw device-group* [name] 491 | ... 492 | +--rw location-group* [name] 493 | ... 494 | +--rw url-group* [name] 495 | ... 497 Figure 8: Endpoint Group YANG Data Tree 499 4.1. User Group 501 This object represents a User-Group. Figure 9 shows the YANG tree of 502 the User-Group object. The User-Group object SHALL have the 503 following information: 505 Name: This field identifies the name of this object. 507 mac-address: This represents the MAC address of a user in the user 508 group. 510 Range-ipv4-address: This represents the IPv4 address range of a user 511 in the user group. 513 Range-ipv6-address: This represents the IPv6 address range of a user 514 in the user group. 516 +--rw user-group* [name] 517 | +--rw name string 518 | +--rw mac-address* yang:mac-address 519 | +--rw (match-type) 520 | | +--:(range-match-ipv4) 521 | | | +--rw range-ipv4-address 522 | | | +--rw start-ipv4-address inet:ipv4-address-no-zone 523 | | | +--rw end-ipv4-address inet:ipv4-address-no-zone 524 | | +--:(range-match-ipv6) 525 | | +--rw range-ipv6-address 526 | | +--rw start-ipv6-address inet:ipv6-address-no-zone 527 | | +--rw end-ipv6-address inet:ipv6-address-no-zone 529 Figure 9: User Group YANG Data Tree 531 4.2. Device Group 533 This object represents a Device-Group. Figure 10 shows the YANG tree 534 of the Device-group object. The Device-Group object SHALL have the 535 following information: 537 Name: This field identifies the name of this object. 539 IPv4: This represents the IPv4 address of a device in the device 540 group. 542 IPv6: This represents the IPv6 address of a device in the device 543 group. 545 Range-ipv4-address: This represents the IPv4 address range of a 546 device in the device group. 548 Range-ipv6-address: This represents the IPv6 address range of a 549 device in the device group. 551 Application-protocol: This represents the application layer 552 protocols of devices. If this is not set, it cannot 553 support the appropriate protocol 555 +--rw device-group* [name] 556 | +--rw name string 557 | +--rw (match-type) 558 | | +--:(range-match-ipv4) 559 | | | +--rw range-ipv4-address 560 | | | +--rw start-ipv4-address inet:ipv4-address-no-zone 561 | | | +--rw end-ipv4-address inet:ipv4-address-no-zone 562 | | +--:(range-match-ipv6) 563 | | +--rw range-ipv6-address 564 | | +--rw start-ipv6-address inet:ipv6-address-no-zone 565 | | +--rw end-ipv6-address inet:ipv6-address-no-zone 566 | +--rw application-protocol* identityref 568 Figure 10: Device Group YANG Data Tree 570 4.3. Location Group 572 This object represents a location group based on either tag or other 573 information. Figure 11 shows the YANG tree of the Location-Group 574 object. The Location-Group object SHALL have the following 575 information: 577 Name: This field identifies the name of this object. 579 Geo-ip-ipv4: This field represents the IPv4 Geo-ip address of a 580 location [RFC8805]. 582 Geo-ip-ipv6: This field represents the IPv6 Geo-ip address of a 583 location [RFC8805]. 585 Continent: This field represents the continent where the location 586 group member is located. 588 +--rw location-group* [name] 589 | +--rw name string 590 | +--rw geo-ip-ipv4* [ipv4-address] 591 | | +--rw ipv4-address inet:ipv4-address-no-zone 592 | | +--rw ipv4-prefix? inet:ipv4-prefix 593 | +--rw geo-ip-ipv6* [ipv6-address] 594 | | +--rw ipv6-address inet:ipv6-address-no-zone 595 | | +--rw ipv6-prefix? inet:ipv6-prefix 596 | +--rw continent? identityref 598 Figure 11: Location Group YANG Data Tree 600 4.4. URL Group 602 This object represents a URL group based on a Uniform Resource 603 Locator (URL) or web address. Figure 12 shows the YANG tree of the 604 URL-Group object. The URLn-Group object SHALL have the following 605 information: 607 Name: This field identifies the name of this object. 609 url: This field represents the new URL added by a user to the 610 URL database. 612 +--rw url-group* [name] 613 +--rw name string 614 +--rw url* string 616 Figure 12: URL Group YANG Data Tree 618 5. Information Model for Threat Prevention 620 The threat prevention plays an important part in the overall security 621 posture by reducing the attack surfaces. This information could come 622 from various threat feeds (i.e., sources for obtaining the threat 623 information). There are multiple managed objects that constitute 624 this category. This section lists these objects and relationship 625 among them. Figure 14 shows the YANG tree of a Threat-Prevention 626 object. 628 +-------------------+ 629 | Threat Prevention | 630 +---------+---------+ 631 ^ 632 | 633 +---------+---------+ 634 0..n | 0..n | 635 +------+------+ +--------+--------+ 636 | Threat-feed | | payload-content | 637 +-------------+ +-----------------+ 639 Figure 13: Threat Prevention Diagram 641 +--rw threat-prevention 642 +--rw threat-feed-list* [name] 643 ... 644 +--rw payload-content* [name] 645 ... 647 Figure 14: Threat Prevention YANG Data Tree 649 5.1. Threat Feed 651 This object represents a threat feed which provides the signatures of 652 malicious activities. Figure 15 shows the YANG tree of a Threat- 653 feed-list. The Threat-Feed object SHALL have the following 654 information: 656 Name: This field identifies the name of this object. 658 Description: This is the description of the threat feed. The 659 description should have the clear indication of the 660 security attack such as attack type (e.g., APT) and file 661 types used (e.g., executable malware). 663 Signatures: This field contains the threat signatures of malicious 664 programs or activities provided by the threat-feed. The 665 examples of signature types are "YARA", "SURICATA", and 666 "SNORT" [YARA][SURICATA][SNORT]. 668 It is assumed that the I2NSF User obtains the threat signatures 669 (i.e., threat content patterns) from a threat-feed server (i.e., feed 670 provider), which is a server providing threat signatures. With the 671 obtained threat signatures, the I2NSF User can deliver them to the 672 Security Controller. The retrieval of the threat signatures by the 673 I2NSF User is out of scope in this document. 675 +--rw threat-prevention 676 +--rw threat-feed-list* [name] 677 +--rw name identityref 678 +--rw description? string 679 +--rw signatures* identityref 681 Figure 15: Threat Feed YANG Data Tree 683 5.2. Payload Content 685 This object represents a custom list created for the purpose of 686 defining an exception to threat feeds. Figure 16 shows the YANG tree 687 of a Payload-content list. The Payload-Content object SHALL have the 688 following information: 690 Name: This field identifies the name of this object. For 691 example, the name "backdoor" indicates the payload content 692 is related to a backdoor attack. 694 Description: This represents the description of how the payload 695 content is related to a security attack. 697 Content: This contains the payload contents, which are involed in a 698 security attack, such as strings. 700 +--rw payload-content* [name] 701 +--rw name string 702 +--rw description string 703 +--rw content* string 705 Figure 16: Payload Content in YANG Data Tree 707 6. Network Configuration Access Control Model (NACM) for I2NSF 708 Consumer-Facing Interface 710 Network Configuration Access Control Model (NACM) provides a user 711 group with an access control with the following features [RFC8341]: 713 * Independent control of action, data, and notification access is 714 provided. 716 * A simple and familiar set of datastore permissions is used. 718 * Support for YANG security tagging allows default security modes to 719 automatically exclude sensitive data. 721 * Separate default access modes for read, write, and execute 722 permissions are provided. 724 * Access control rules are applied to configurable groups of users. 726 The data model of the I2NSF Consumer-Facing Interface utilizes the 727 NACM's mechanisms to manage the access control on the I2NSF Consumer- 728 Facing Interface. The NACM with the above features can be used to 729 set up the access control rules of a user group in the I2NSF 730 Consumer-Facing Interface. 732 Figure 17 shows part of the NACM module to enable the access control 733 of a user group for the I2NSF Consumer-Facing Interface. To use the 734 NACM, a user needs to configure either a NETCONF server [RFC6241] or 735 a RESTCONF server [RFC8040] to enable the NACM module. Then, the 736 user can simply use an account of root or admin user for the access 737 control for the module of the I2NSF Consumer-Facing Interface (i.e., 738 ietf-i2nsf-cfi-policy). An XML example to configure the access 739 control a user group for the I2NSF Consumer-Facing Interface can be 740 seen in Section 9. 742 list rule { 743 key "name"; 744 ordered-by user; 745 leaf name { 746 type string { 747 length "1..max"; 748 } 749 description 750 "Arbitrary name assigned to the rule."; 751 } 753 leaf module-name { 754 type union { 755 type matchall-string-type; 756 type string; 757 } 758 default "*"; 759 description 760 "Name of the module associated with this rule." 761 } 763 leaf access-operations { 764 type union { 765 type matchall-string-type; 766 type access-operations-type; 767 } 768 default "*"; 769 description 770 "Access operations associated with this rule." 771 } 773 leaf action { 774 type action-type; 775 mandatory true; 776 description 777 "The access control action associated with the 778 rule. If a rule is determined to match a 779 particular request, then this object is used 780 to determine whether to permit or deny the 781 request."; 782 } 784 Figure 17: A Part of the NACM YANG Data Model 786 7. YANG Data Model of Consumer-Facing Interface 788 The main objective of this document is to provide both an information 789 model and the corresponding YANG data model of I2NSF Consumer-Facing 790 Interface. This interface can be used to deliver control and 791 management messages between an I2NSF User and Security Controller for 792 the I2NSF User's high-level security policies. 794 The semantics of the data model must be aligned with the information 795 model of the Consumer-Facing Interface. The transformation of the 796 information model is performed so that this YANG data model can 797 facilitate the efficient delivery of the control or management 798 messages. 800 This data model is designed to support the I2NSF framework that can 801 be extended according to the security needs. In other words, the 802 model design is independent of the content and meaning of specific 803 policies as well as the implementation approach. 805 With the YANG data model of I2NSF Consumer-Facing Interface, this 806 document suggests use cases for security policy rules such as time- 807 based firewall, VoIP/VoLTE security service, and DDoS-attack 808 mitigation in Section 8. 810 7.1. YANG Module of Consumer-Facing Interface 812 This section describes a YANG module of Consumer-Facing Interface. 813 This document provides identities in the data model to be used for 814 configuration of an NSF. Each identity is used for a different type 815 of configuration. The details are explained in the description of 816 each identity. This YANG module imports from [RFC6991]. It makes 817 references to [RFC0768][RFC0792][RFC0793] [RFC0854][RFC0959][RFC1939] 818 [RFC2818][RFC3022][RFC3261] [RFC3501][RFC4250][RFC4340] 819 [RFC4443][RFC5321][RFC7230] [RFC7231][I-D.ietf-i2nsf-capability] 820 [I-D.ietf-tcpm-rfc793bis][IANA-ICMP-Parameters] 821 [IANA-ICMPv6-Parameters][Encyclopedia-Britannica] [STIX]. 823 file "ietf-i2nsf-cfi-policy@2021-09-15.yang" 824 module ietf-i2nsf-cfi-policy { 825 yang-version 1.1; 826 namespace 827 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; 828 prefix nsfcfi; 830 import ietf-inet-types{ 831 prefix inet; 832 reference "RFC 6991"; 833 } 834 import ietf-yang-types{ 835 prefix yang; 836 reference "RFC 6991"; 837 } 839 organization 840 "IETF I2NSF (Interface to Network Security Functions) 841 Working Group"; 843 contact 844 "WG Web: 845 WG List: 847 Editor: Jaehoon Paul Jeong 848 850 Editor: Patrick Lingga 851 "; 853 description 854 "This module is a YANG module for Consumer-Facing Interface. 856 Copyright (c) 2021 IETF Trust and the persons identified as 857 authors of the code. All rights reserved. 859 Redistribution and use in source and binary forms, with or 860 without modification, is permitted pursuant to, and subject to 861 the license terms contained in, the Simplified BSD License set 862 forth in Section 4.c of the IETF Trust's Legal Provisions 863 Relating to IETF Documents 864 (https://trustee.ietf.org/license-info). 866 This version of this YANG module is part of RFC XXXX 867 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 868 for full legal notices."; 870 // RFC Ed.: replace XXXX with an actual RFC number and remove 871 // this note. 873 revision "2021-09-15" { 874 description "Initial revision."; 875 reference 876 "RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model"; 878 // RFC Ed.: replace XXXX with an actual RFC number and remove 879 // this note. 880 } 881 identity resolution-strategy { 882 description 883 "Base identity for resolution strategy"; 884 reference 885 "draft-ietf-i2nsf-capability-data-model-17: 886 I2NSF Capability YANG Data Model - Resolution Strategy"; 887 } 889 identity fmr { 890 base resolution-strategy; 891 description 892 "Identity for First Matching Rule (FMR)"; 893 reference 894 "draft-ietf-i2nsf-capability-data-model-17: 895 I2NSF Capability YANG Data Model - Resolution Strategy"; 896 } 898 identity lmr { 899 base resolution-strategy; 900 description 901 "Identity for Last Matching Rule (LMR)"; 902 reference 903 "draft-ietf-i2nsf-capability-data-model-17: 904 I2NSF Capability YANG Data Model - Resolution Strategy"; 905 } 907 identity pmr { 908 base resolution-strategy; 909 description 910 "Identity for Prioritized Matching Rule (PMR)"; 911 reference 912 "draft-ietf-i2nsf-capability-data-model-17: 913 I2NSF Capability YANG Data Model - Resolution Strategy"; 914 } 916 identity pmre { 917 base resolution-strategy; 918 description 919 "Identity for Prioritized Matching Rule 920 with Errors (PMRE)"; 921 reference 922 "draft-ietf-i2nsf-capability-data-model-17: 923 I2NSF Capability YANG Data Model - Resolution Strategy"; 924 } 926 identity pmrn { 927 base resolution-strategy; 928 description 929 "Identity for Prioritized Matching Rule 930 with No Errors (PMRN)"; 931 reference 932 "draft-ietf-i2nsf-capability-data-model-17: 933 I2NSF Capability YANG Data Model - Resolution Strategy"; 934 } 936 identity security-event { 937 description 938 "Base identity for security event types."; 939 } 941 identity anti-ddos { 942 base security-event; 943 description 944 "Identity for Anti-DDoS event types."; 945 } 947 identity ips { 948 base security-event; 949 description 950 "Identity for Intrusion Prevention System event types."; 951 } 953 identity url-filtering { 954 base security-event; 955 description 956 "Identity for url-filtering event types."; 957 } 959 identity anti-virus { 960 base security-event; 961 description 962 "Identity for Antivirus types."; 963 } 965 identity voip-volte-filtering { 966 base security-event; 967 description 968 "Identity for VoIP/VoLTE Filtering event types."; 969 } 971 identity protocol { 972 description 973 "This identity represents the protocol types."; 974 } 976 identity transport-protocol { 977 base protocol; 978 description 979 "Base identity for the Layer 4 (i.e., Transport Layer) 980 Protocols"; 981 } 983 identity tcp { 984 base transport-protocol; 985 description 986 "Base identity for TCP condition capabilities"; 987 reference 988 "RFC 793: Transmission Control Protocol 989 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 990 (TCP) Specification"; 991 } 993 identity udp { 994 base transport-protocol; 995 description 996 "Base identity for UDP condition capabilities"; 997 reference 998 "RFC 768: User Datagram Protocol"; 999 } 1001 identity sctp { 1002 base transport-protocol; 1003 description 1004 "Identity for SCTP condition capabilities"; 1005 reference 1006 "RFC 4960: Stream Control Transmission Protocol"; 1007 } 1009 identity dccp { 1010 base transport-protocol; 1011 description 1012 "Identity for DCCP condition capabilities"; 1013 reference 1014 "RFC 4340: Datagram Congestion Control Protocol"; 1015 } 1017 identity application-protocol { 1018 base protocol; 1019 description 1020 "Base identity for the Layer 7 (i.e., Application Layer) 1021 Protocols"; 1022 } 1024 identity ftp { 1025 base application-protocol; 1026 description 1027 "The identity for ftp protocol."; 1028 reference 1029 "RFC 959: File Transfer Protocol (FTP)"; 1030 } 1032 identity ssh { 1033 base application-protocol; 1034 description 1035 "The identity for ssh protocol."; 1036 reference 1037 "RFC 4250: The Secure Shell (SSH) Protocol"; 1038 } 1040 identity telnet { 1041 base application-protocol; 1042 description 1043 "The identity for telnet."; 1044 reference 1045 "RFC 854: Telnet Protocol"; 1046 } 1048 identity smtp { 1049 base application-protocol; 1050 description 1051 "The identity for smtp."; 1052 reference 1053 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1054 } 1056 identity http { 1057 base application-protocol; 1058 description 1059 "The identity for http."; 1060 reference 1061 "RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1062 Syntax and Routing 1063 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1064 and Content"; 1065 } 1067 identity https { 1068 base application-protocol; 1069 description 1070 "The identity for https."; 1071 reference 1072 "RFC 2818: HTTP over TLS (HTTPS)"; 1074 } 1076 identity pop3 { 1077 base application-protocol; 1078 description 1079 "The identity for pop3."; 1080 reference 1081 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1082 } 1084 identity imap { 1085 base application-protocol; 1086 description 1087 "The identity for Internet Message Access Protocol (IMAP)."; 1088 reference 1089 "RFC 3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"; 1090 } 1092 identity action { 1093 description 1094 "Base identity for action"; 1095 } 1097 identity ingress-action { 1098 base action; 1099 description 1100 "Base identity to represents the ingress actions, such as 1101 pass, drop, rate-limit, and mirror."; 1102 } 1104 identity egress-action { 1105 base action; 1106 description 1107 "Base identity represents the egress actions, such as 1108 pass, drop, rate-limit, mirror, invoke-signaling, 1109 tunnel-encapsulation, forwarding, and transformation."; 1110 } 1112 identity pass { 1113 base ingress-action; 1114 description 1115 "The identity for pass."; 1116 } 1118 identity drop { 1119 base ingress-action; 1120 description 1121 "The identity for drop."; 1123 } 1125 identity rate-limit { 1126 base ingress-action; 1127 description 1128 "The identity for rate-limit."; 1129 } 1131 identity mirror { 1132 base ingress-action; 1133 description 1134 "The identity for mirroring."; 1135 } 1137 identity invoke-signaling { 1138 base egress-action; 1139 description 1140 "Identity for invoke signaling action capability"; 1141 reference 1142 "RFC 8329: Framework for Interface to Network Security 1143 Functions - Invoke-signaling action"; 1144 } 1146 identity tunnel-encapsulation { 1147 base egress-action; 1148 description 1149 "Identity for tunnel encapsulation action capability"; 1150 reference 1151 "RFC 8329: Framework for Interface to Network Security 1152 Functions - Tunnel Encapsulation"; 1153 } 1155 identity forwarding { 1156 base egress-action; 1157 description 1158 "Identity for forwarding action capability"; 1159 reference 1160 "RFC 8329: Framework for Interface to Network Security 1161 Functions - Forwarding action"; 1162 } 1164 identity transformation { 1165 base egress-action; 1166 description 1167 "Identity for transformation action capability"; 1168 reference 1169 "RFC 8329: Framework for Interface to Network Security 1170 Functions - Redirection action"; 1172 } 1174 identity log-action { 1175 description 1176 "Base identity for representing log actions, such as rule-log 1177 and session-log action."; 1178 } 1180 identity rule-log { 1181 base log-action; 1182 description 1183 "Identity for rule log-action capability. 1184 Log the received packet based on the rule"; 1185 } 1187 identity session-log { 1188 base log-action; 1189 description 1190 "Identity for session log-action capability. 1191 Log the received packet based on the session."; 1192 } 1194 identity signature-type { 1195 description 1196 "This represents the base identity for signature types."; 1197 } 1199 identity signature-yara { 1200 base signature-type; 1201 description 1202 "This represents the YARA signatures."; 1203 reference 1204 "YARA: YARA signatures are explained."; 1205 } 1207 identity signature-snort { 1208 base signature-type; 1209 description 1210 "This represents the SNORT signatures."; 1211 reference 1212 "SNORT: SNORT signatures are explained."; 1213 } 1215 identity signature-suricata { 1216 base signature-type; 1217 description 1218 "This represents the SURICATA signatures."; 1219 reference 1220 "SURICATA: SURICATA signatures are explained."; 1221 } 1223 identity threat-feed-type { 1224 description 1225 "This represents the base identity for threat-feed."; 1226 } 1228 identity day { 1229 description 1230 "This represents the base for days."; 1231 } 1233 identity monday { 1234 base day; 1235 description 1236 "This represents Monday."; 1237 } 1239 identity tuesday { 1240 base day; 1241 description 1242 "This represents Tuesday."; 1243 } 1245 identity wednesday { 1246 base day; 1247 description 1248 "This represents Wednesday."; 1249 } 1251 identity thursday { 1252 base day; 1253 description 1254 "This represents Thursday."; 1255 } 1257 identity friday { 1258 base day; 1259 description 1260 "This represents Friday."; 1261 } 1263 identity saturday { 1264 base day; 1265 description 1266 "This represents Saturday."; 1267 } 1268 identity sunday { 1269 base day; 1270 description 1271 "This represents Sunday."; 1272 } 1274 identity continent { 1275 description 1276 "Base identity for continent types. The continents are based 1277 on Encyclopedia Britannica"; 1278 reference 1279 "Encyclopedia Britannica: Continent"; 1280 } 1282 identity africa { 1283 base continent; 1284 description 1285 "Identity for Africa."; 1286 reference 1287 "Encyclopedia Britannica: Continent"; 1288 } 1290 identity asia { 1291 base continent; 1292 description 1293 "Identity for Asia."; 1294 reference 1295 "Encyclopedia Britannica: Continent"; 1296 } 1298 identity antarctica { 1299 base continent; 1300 description 1301 "Identity for Antarctica."; 1302 reference 1303 "Encyclopedia Britannica: Continent"; 1304 } 1306 identity europe { 1307 base continent; 1308 description 1309 "Identity for Europe."; 1310 reference 1311 "Encyclopedia Britannica: Continent"; 1312 } 1314 identity north-america { 1315 base continent; 1316 description 1317 "Identity for North America."; 1318 reference 1319 "Encyclopedia Britannica: Continent"; 1320 } 1322 identity south-america { 1323 base continent; 1324 description 1325 "Identity for South America."; 1326 reference 1327 "Encyclopedia Britannica: Continent"; 1328 } 1330 identity australia { 1331 base continent; 1332 description 1333 "Identity for Australia"; 1334 reference 1335 "Encyclopedia Britannica: Continent"; 1336 } 1338 /* 1339 * Typedefs 1340 */ 1341 typedef time { 1342 type string { 1343 pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' 1344 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 1345 } 1346 description 1347 "The time type represents an instance of time of zero-duration 1348 that recurs every day."; 1349 } 1351 /* 1352 * Groupings 1353 */ 1355 grouping ipv4-list { 1356 description 1357 "Grouping for an IPv4 address list."; 1358 leaf-list ipv4 { 1359 type inet:ipv4-address-no-zone; 1360 description 1361 "This is the entry for an IPv4 address list."; 1362 } 1363 } 1364 grouping ipv6-list { 1365 description 1366 "Grouping for an IPv6 address list."; 1367 leaf-list ipv6 { 1368 type inet:ipv6-address-no-zone; 1369 description 1370 "This is the entry for an IPv6 address list."; 1371 } 1372 } 1374 grouping ipv4 { 1375 description 1376 "Grouping for an IPv4 address."; 1377 leaf ipv4 { 1378 type inet:ipv4-address-no-zone; 1379 description 1380 "This is the entry for an IPv4 address."; 1381 } 1382 } 1384 grouping ipv6 { 1385 description 1386 "Grouping for an IPv6 address."; 1387 leaf ipv6 { 1388 type inet:ipv6-address-no-zone; 1389 description 1390 "This is the entry for an IPv6 address."; 1391 } 1392 } 1394 grouping ip-address-info { 1395 description 1396 "There are two types to configure a security policy 1397 for an IP address, such as IPv4 adress and IPv6 address."; 1398 choice match-type { 1399 description 1400 "User can choose between IPv4 and IPv6."; 1401 case range-match-ipv4 { 1402 container range-ipv4-address { 1403 leaf start-ipv4-address { 1404 type inet:ipv4-address-no-zone; 1405 mandatory true; 1406 description 1407 "A start IPv4 address for a range match."; 1408 } 1409 leaf end-ipv4-address { 1410 type inet:ipv4-address-no-zone; 1411 mandatory true; 1412 description 1413 "An end IPv4 address for a range match."; 1414 } 1415 description 1416 "A range match for IPv4 addresses is provided. 1417 Note that the start IPv4 address must be lower than 1418 the end IPv4 address."; 1419 } 1420 } 1421 case range-match-ipv6 { 1422 container range-ipv6-address { 1423 leaf start-ipv6-address { 1424 type inet:ipv6-address-no-zone; 1425 mandatory true; 1426 description 1427 "A start IPv6 address for a range match."; 1428 } 1429 leaf end-ipv6-address { 1430 type inet:ipv6-address-no-zone; 1431 mandatory true; 1432 description 1433 "An end IPv6 address for a range match."; 1434 } 1435 description 1436 "A range match for IPv6 addresses is provided. 1437 Note that the start IPv6 address must be lower than 1438 the end IPv6 address."; 1439 } 1440 } 1441 } 1442 } 1444 grouping user-group { 1445 description 1446 "This group represents user group information such as name and 1447 ip-address."; 1448 leaf name { 1449 type string; 1450 description 1451 "This represents the name of a user-group. A user-group name 1452 is used to map a user-group's name (e.g., employees) to IP 1453 address(es), MAC address(es). 1454 It is dependent on implementation."; 1455 } 1456 leaf-list mac-address { 1457 type yang:mac-address; 1458 description 1459 "Represent the MAC Address of a user-group. A user-group 1460 can have multiple MAC Addresses."; 1461 } 1462 uses ip-address-info{ 1463 description 1464 "This represents the IP addresses of a user-group."; 1465 refine match-type{ 1466 mandatory true; 1467 } 1468 } 1469 } 1471 grouping device-group { 1472 description 1473 "This group represents device group information such as 1474 ip-address protocol."; 1475 leaf name { 1476 type string; 1477 description 1478 "This represents the name of a device-group."; 1479 } 1480 uses ip-address-info{ 1481 refine match-type{ 1482 mandatory true; 1483 } 1484 } 1485 leaf-list application-protocol { 1486 type identityref { 1487 base application-protocol; 1488 } 1489 description 1490 "This represents the application layer protocols of devices. 1491 If this is not set, it cannot support the appropriate 1492 protocol"; 1493 } 1494 } 1496 grouping location-group { 1497 description 1498 "This group represents location-group information such as 1499 geo-ip and continent."; 1500 leaf name { 1501 type string; 1502 description 1503 "This represents the name of a location."; 1504 } 1505 list geo-ip-ipv4 { 1506 key "ipv4-address"; 1507 description 1508 "This represents the list of IPv4 addresses based on a 1509 location."; 1510 leaf ipv4-address{ 1511 type inet:ipv4-address-no-zone; 1512 description 1513 "This represents an IPv4 geo-ip address of a location."; 1514 } 1515 leaf ipv4-prefix{ 1516 type inet:ipv4-prefix; 1517 description 1518 "This represents the prefix for the IPv4 addresses."; 1519 } 1520 } 1521 list geo-ip-ipv6 { 1522 key "ipv6-address"; 1523 description 1524 "This represents the list of IPv6 addresses based on a 1525 location."; 1526 leaf ipv6-address{ 1527 type inet:ipv6-address-no-zone; 1528 description 1529 "This represents an IPv6 geo-ip address of a location."; 1530 } 1531 leaf ipv6-prefix{ 1532 type inet:ipv6-prefix; 1533 description 1534 "This represents the prefix for the IPv6 addresses."; 1535 } 1536 } 1537 leaf continent { 1538 type identityref { 1539 base continent; 1540 } 1541 default asia; 1542 description 1543 "location-group has geo-ip addresses of the corresponding 1544 continent."; 1545 } 1546 } 1548 grouping payload-string { 1549 description 1550 "The grouping for payload-string content. It contains 1551 information such as name and string content."; 1552 leaf description { 1553 type string; 1554 description 1555 "This represents the description of a payload. If this is 1556 not set, it cannot support the description of how the 1557 payload content is related to a security attack."; 1558 } 1559 leaf-list content { 1560 type string; 1561 description 1562 "This represents the string of the payload contents. 1563 This content leaf-list contains the payload of a packet to 1564 analyze a threat. Due to the types of threats, the type of 1565 the content is defined as a string to accommodate any kind 1566 of a payload type such as HTTP, HTTPS, and SIP. If this is 1567 not set, it cannot support the payload contents involved in 1568 a security attack as a string."; 1569 } 1570 } 1572 list i2nsf-cfi-policy { 1573 key "policy-name"; 1574 description 1575 "This is a security policy list. Each policy in the list 1576 contains a list of security policy rules, and is a policy 1577 instance to have the information of where and when a policy 1578 needs to be applied."; 1579 leaf policy-name { 1580 type string; 1581 description 1582 "The name which identifies the policy."; 1583 } 1584 leaf resolution-strategy { 1585 type identityref { 1586 base resolution-strategy; 1587 } 1588 default fmr; 1589 description 1590 "The resolution strategies that can be used to 1591 specify how to resolve conflicts that occur between 1592 actions of the same or different policy rules that 1593 are matched and contained in this particular NSF"; 1595 reference 1596 "draft-ietf-i2nsf-capability-data-model-17: 1597 I2NSF Capability YANG Data Model - Resolution strategy"; 1598 } 1599 list rules { 1600 key "rule-name"; 1602 description 1603 "There can be a single or multiple number of rules."; 1605 leaf rule-name { 1606 type string; 1607 description 1608 "This represents the name for a rule."; 1609 } 1611 leaf priority { 1612 type uint8 { 1613 range "1..255"; 1614 } 1615 description 1616 "The priority keyword comes with a mandatory 1617 numeric value which can range from 1 through 255. 1618 Note that a higher number means a higher priority"; 1619 } 1621 container event { 1622 description 1623 "This represents an event (i.e., a security event), for 1624 which a security rule is made."; 1625 leaf security-event { 1626 type identityref { 1627 base security-event; 1628 } 1629 description 1630 "This contains the description of a security event. If 1631 this is not set, it cannot support what security event 1632 will be enforced."; 1633 } 1635 container time { 1636 description 1637 "The time when a security policy rule should be 1638 applied."; 1639 leaf start-date-time { 1640 type yang:date-and-time; 1641 description 1642 "This is the start date and time for a security policy 1643 rule."; 1644 } 1645 leaf end-date-time { 1646 type yang:date-and-time; 1647 description 1648 "This is the end date and time for a policy rule. The 1649 policy rule will stop working after the specified 1650 end-date-time."; 1651 } 1652 container period { 1653 when 1654 "../frequency!='only-once'"; 1655 description 1656 "This represents the repetition time. In the case 1657 where the frequency is weekly, the days can be set."; 1658 leaf start-time { 1659 type time; 1660 description 1661 "This is a period's start time for an event."; 1662 } 1663 leaf end-time { 1664 type time; 1665 description 1666 "This is a period's end time for an event."; 1667 } 1668 leaf-list day { 1669 when 1670 "../../frequency='weekly'"; 1671 type identityref{ 1672 base day; 1673 } 1674 min-elements 1; 1675 description 1676 "This represents the repeated day of every week 1677 (e.g., Monday and Tuesday). More than one day can be 1678 specified."; 1679 } 1680 leaf-list date { 1681 when 1682 "../../frequency='monthly'"; 1683 type int32{ 1684 range "1..31"; 1685 } 1686 min-elements 1; 1687 description 1688 "This represents the repeated date of every month. 1689 More than one date can be specified."; 1690 } 1691 leaf-list month { 1692 when 1693 "../../frequency='yearly'"; 1694 type string{ 1695 pattern '\d{2}-\d{2}'; 1696 } 1697 min-elements 1; 1698 description 1699 "This represents the repeated date and month of every 1700 year. More than one can be specified. A pattern 1701 used here is Month and Date (MM-DD)."; 1702 } 1703 } 1705 leaf frequency { 1706 type enumeration { 1707 enum only-once { 1708 description 1709 "This represents that the rule is immediately 1710 enforced only once and not repeated. The policy 1711 will continuously be active from the start-time 1712 to the end-time."; 1713 } 1714 enum daily { 1715 description 1716 "This represents that the rule is enforced on a 1717 daily basis. The policy will be repeated daily 1718 until the end-date."; 1719 } 1720 enum weekly { 1721 description 1722 "This represents that the rule is enforced on a 1723 weekly basis. The policy will be repeated weekly 1724 until the end-date. The repeated days can be 1725 specified."; 1726 } 1727 enum monthly { 1728 description 1729 "This represents that the rule is enforced on a 1730 monthly basis. The policy will be repeated monthly 1731 until the end-date."; 1732 } 1733 enum yearly { 1734 description 1735 "This represents that the rule is enforced on a 1736 yearly basis. The policy will be repeated yearly 1737 until the end-date."; 1738 } 1739 } 1740 default only-once; 1741 description 1742 "This represents how frequently the rule should be 1743 enforced."; 1744 } 1745 } 1746 } 1748 container condition { 1749 description 1750 "Conditions for general security policies."; 1751 container firewall-condition { 1752 description 1753 "A general firewall condition based on the packet 1754 header."; 1755 leaf-list source { 1756 type union { 1757 type leafref { 1758 path 1759 "/i2nsf-cfi-policy/endpoint-groups/" 1760 +"user-group/name"; 1761 } 1762 type leafref { 1763 path 1764 "/i2nsf-cfi-policy/endpoint-groups/" 1765 +"device-group/name"; 1766 } 1767 } 1768 description 1769 "This describes the path of the source."; 1770 } 1772 leaf-list destination { 1773 type union { 1774 type leafref { 1775 path 1776 "/i2nsf-cfi-policy/endpoint-groups/" 1777 +"user-group/name"; 1778 } 1779 type leafref { 1780 path 1781 "/i2nsf-cfi-policy/endpoint-groups/" 1782 +"device-group/name"; 1783 } 1784 } 1785 description 1786 "This describes the path to the destinations."; 1787 } 1789 leaf transport-layer-protocol { 1790 type identityref { 1791 base transport-protocol; 1792 } 1793 description 1794 "The transport-layer protocol to be matched."; 1795 } 1796 container range-port-number { 1797 leaf start-port-number { 1798 type inet:port-number; 1799 description 1800 "A start port number for range match."; 1801 } 1802 leaf end-port-number { 1803 type inet:port-number; 1804 description 1805 "An end port number for range match."; 1806 } 1807 description 1808 "A range match for transport-layer port number. Note 1809 that the start port number value must be lower than 1810 the end port number value"; 1811 } 1813 list icmp { 1814 key "version"; 1815 description 1816 "Represents the ICMP packet header information to 1817 determine if the set of policy actions in this ECA 1818 policy rule should be executed or not."; 1819 reference 1820 "RFC 792: Internet Control Message Protocol 1821 RFC 8335: PROBE: A Utility for Probing Interfaces"; 1823 leaf version { 1824 type enumeration { 1825 enum icmpv4 { 1826 value "1"; 1827 description 1828 "The ICMPv4 Protocol as defined in RFC 792"; 1829 } 1830 enum icmpv6 { 1831 value "2"; 1832 description 1833 "The ICMPv6 Protocol as defined in RFC 4443"; 1834 } 1835 } 1836 description 1837 "The ICMP version to be matched. This value 1838 affected the type and code values."; 1839 reference 1840 "RFC 792: Internet Control Message Protocol 1841 RFC 4443: Internet Control Message Protocol (ICMPv6) 1842 for the Internet Protocol Version 6 (IPv6) 1843 Specification"; 1845 } 1847 leaf-list type { 1848 type uint8; 1849 description 1850 "The security policy rule according to 1851 ICMP type parameter."; 1852 reference 1853 "RFC 792: Internet Control Message Protocol 1854 RFC 8335: PROBE: A Utility for Probing Interfaces 1855 IANA: Internet Control Message Protocol (ICMP) 1856 Parameters 1857 IANA: Internet Control Message Protocol version 6 1858 (ICMPv6) Parameters"; 1859 } 1861 leaf-list code { 1862 type uint8; 1863 description 1864 "The security policy rule according to 1865 ICMP code parameter."; 1866 reference 1867 "RFC 792: Internet Control Message Protocol 1868 RFC 8335: PROBE: A Utility for Probing Interfaces 1869 IANA: Internet Control Message Protocol (ICMP) 1870 Parameters 1871 IANA: Internet Control Message Protocol version 6 1872 (ICMPv6) Parameters"; 1873 } 1874 } 1875 } 1877 container ddos-condition { 1878 description 1879 "A condition for a DDoS attack."; 1880 container rate-limit { 1881 description 1882 "This describes the rate-limit."; 1883 leaf packet-rate-threshold { 1884 type uint32; 1886 description 1887 "This is a trigger value for a rate limit of packet 1888 rate for a DDoS-attack mitigation."; 1889 } 1890 leaf byte-rate-threshold { 1891 type uint32; 1892 description 1893 "This is a trigger value for a rate limit of byte 1894 rate for a DDoS-attack mitigation."; 1895 } 1896 leaf flow-rate-threshold { 1897 type uint32; 1898 description 1899 "This is a trigger value for a rate limit of flow 1900 rate for a DDoS-attack mitigation."; 1901 } 1902 } 1903 } 1905 container anti-virus-condition { 1906 description 1907 "A condition for anti-virus"; 1909 leaf-list exception-files { 1910 type string; 1911 description 1912 "The type or name of the files to be excluded by the 1913 anti-virus. This can be used to keep the known 1914 harmless files."; 1915 } 1916 } 1918 container payload-condition { 1919 description 1920 "A condition based on a packet's content."; 1921 leaf-list content { 1922 type leafref { 1923 path "/i2nsf-cfi-policy/threat-preventions/" 1924 + "payload-content/name"; 1925 } 1926 description 1927 "This describes the paths to a packet content's"; 1928 } 1929 } 1931 container url-condition { 1932 description 1933 "Condition for url category"; 1934 leaf url-name { 1935 type leafref { 1936 path 1937 "/i2nsf-cfi-policy/endpoint-groups/" 1938 +"url-group/name"; 1939 } 1940 description 1941 "This is description for the condition of a URL's 1942 category such as SNS sites, game sites, ecommerce 1943 sites, company sites, and university sites."; 1944 } 1945 } 1947 container voice-condition { 1948 description 1949 "For the VoIP/VoLTE security system, a VoIP/ 1950 VoLTE security system can monitor each 1951 VoIP/VoLTE flow and manage VoIP/VoLTE 1952 security rules controlled by a centralized 1953 server for VoIP/VoLTE security service 1954 (called VoIP IPS). The VoIP/VoLTE security 1955 system controls each switch for the 1956 VoIP/VoLTE call flow management by 1957 manipulating the rules that can be added, 1958 deleted, or modified dynamically."; 1959 reference 1960 "RFC 3261: SIP: Session Initiation Protocol"; 1962 leaf-list source-id { 1963 type string; 1964 description 1965 "The security policy rule according to 1966 a source voice ID for VoIP and VoLTE."; 1967 } 1969 leaf-list destination-id { 1970 type string; 1971 description 1972 "The security policy rule according to 1973 a destination voice ID for VoIP and VoLTE."; 1974 } 1976 leaf-list user-agent { 1977 type string; 1978 description 1979 "The security policy rule according to 1980 an user agent for VoIP and VoLTE."; 1981 } 1982 } 1984 container context-condition { 1985 description 1986 "Condition for matching the context of the packet, such 1987 as geographic location, time, packet direction"; 1988 container geography-location-condition { 1989 description 1990 "A condition for a location-based connection"; 1991 leaf-list source { 1992 type leafref { 1993 path 1994 "/i2nsf-cfi-policy/endpoint-groups/" 1995 +"location-group/name"; 1996 } 1997 description 1998 "This describes the paths to a location's sources."; 1999 } 2000 leaf-list destination { 2001 type leafref { 2002 path 2003 "/i2nsf-cfi-policy/endpoint-groups/" 2004 +"location-group/name"; 2005 } 2006 description 2007 "This describes the paths to a location's 2008 destinations."; 2009 } 2010 } 2011 } 2013 container threat-feed-condition { 2014 description 2015 "A condition based on the threat-feed information."; 2016 leaf-list name { 2017 type leafref { 2018 path 2019 "/i2nsf-cfi-policy/threat-preventions/" 2020 +"threat-feed-list/name"; 2021 } 2022 description 2023 "This describes the paths to a threat-feed's sources."; 2024 } 2025 } 2026 } 2028 container actions { 2029 description 2030 "This is the action container."; 2031 container primary-action { 2032 description 2033 "This represent primary actions (e.g., ingress and egress 2034 action) to be applied to a condition. 2035 If this is not set, it cannot support the primary 2036 actions."; 2038 leaf action { 2039 type identityref { 2040 base action; 2041 } 2042 description 2043 "Ingress Action: pass, drop, reject, rate-limit, 2044 and mirror. 2045 Egress action: mirror, invoke-signaling, 2046 tunnel-encapsulation, forwarding, and redirection."; 2047 } 2048 } 2049 container secondary-action { 2050 description 2051 "This represents secondary actions (e.g., log and syslog) 2052 to be applied if they are needed. If this is not set, 2053 it cannot support the secondary actions."; 2054 leaf log-action { 2055 type identityref { 2056 base log-action; 2057 } 2058 description 2059 "Log action: rule log and session log"; 2060 } 2061 } 2062 } 2063 } 2065 container endpoint-groups { 2066 description 2067 "A logical entity in a business environment, where a security 2068 policy is to be applied."; 2069 list user-group{ 2070 uses user-group; 2071 key "name"; 2072 description 2073 "This represents a user group."; 2074 } 2075 list device-group { 2076 key "name"; 2077 uses device-group; 2078 description 2079 "This represents a device group."; 2080 } 2081 list location-group{ 2082 key "name"; 2083 uses location-group; 2084 description 2085 "This represents a location group."; 2087 } 2088 list url-group { 2089 key "name"; 2090 description 2091 "This describes the list of URL."; 2092 leaf name { 2093 type string; 2094 description 2095 "This is the name of URL group, e.g., SNS sites, 2096 gaming sites, ecommerce sites"; 2097 } 2098 leaf-list url { 2099 type string; 2100 description 2101 "Specifies the URL to be added into the group."; 2102 } 2103 } 2104 } 2106 container threat-preventions { 2107 description 2108 "This describes the list of threat-preventions."; 2109 list threat-feed-list { 2110 key "name"; 2111 description 2112 "There can be a single or multiple number of 2113 threat-feeds."; 2114 leaf name { 2115 type string; 2116 description 2117 "This represents the name of the threat-feed."; 2118 } 2119 leaf description { 2120 type string; 2121 description 2122 "This represents the descriptions of a threat-feed. The 2123 description should include information, such as type, 2124 threat, method, and file type. Structured Threat 2125 Information Expression (STIX) can be used for 2126 description of a threat [STIX]."; 2127 } 2128 leaf-list signatures { 2129 type identityref { 2130 base signature-type; 2131 } 2132 description 2133 "This contains a list of signatures or hashes of the 2134 threats."; 2136 } 2137 } 2138 list payload-content { 2139 key "name"; 2140 leaf name { 2141 type string; 2142 description 2143 "This represents the name of a packet's payload-content. 2144 It should give an idea of why a specific payload content 2145 is marked as a threat. For example, the name 'backdoor' 2146 indicates the payload content is related to a backdoor 2147 attack."; 2148 } 2149 description 2150 "This represents a payload-string group."; 2151 uses payload-string; 2152 } 2153 } 2154 } 2155 } 2156 2158 Figure 18: YANG for Consumer-Facing Interface 2160 8. XML Configuration Examples of High-Level Security Policy Rules 2162 This section shows XML configuration examples of high-level security 2163 policy rules that are delivered from the I2NSF User to the Security 2164 Controller over the Consumer-Facing Interface. The considered use 2165 cases are: Database registration, time-based firewall for web 2166 filtering, VoIP/VoLTE security service, and DDoS-attack mitigation. 2168 8.1. Database Registration: Information of Positions and Devices 2169 (Endpoint Group) 2171 If new endpoints are introduced to the network, it is necessary to 2172 first register their data to the database. For example, if new 2173 members are newly introduced in either of three different groups 2174 (i.e., user-group, device-group, and url-group), each of them should 2175 be registered with information such as ip-addresses or protocols used 2176 by devices. 2178 Figure 19 shows an example XML representation of the registered 2179 information for the user-group and device-group with IPv4 addresses 2180 [RFC5737]. 2182 2183 2185 2186 2187 employees 2188 2189 192.0.2.11 2190 192.0.2.90 2191 2192 2193 2194 webservers 2195 2196 198.51.100.11 2197 198.51.100.20 2198 2199 nsfcfi:http 2200 nsfcfi:https 2201 2202 2203 sns-websites 2204 SNS_1 2205 SNS_2 2206 2207 2208 2210 Figure 19: Registering User-group and Device-group Information 2211 with IPv4 Addresses 2213 Also, Figure 20 shows an example XML representation of the registered 2214 information for the user-group and device-group with IPv6 addresses 2215 [RFC3849]. 2217 2218 2220 2221 2222 employees 2223 2224 2001:DB8:0:1::11 2225 2001:DB8:0:1::90 2226 2227 2228 2229 webservers 2230 2231 2001:DB8:0:2::11 2232 2001:DB8:0:2::20 2233 2234 nsfcfi:http 2235 nsfcfi:https 2236 2237 2238 sns-websites 2239 SNS_1 2240 SNS_2 2241 2242 2243 2245 Figure 20: Registering User-group and Device-group Information 2246 with IPv6 Addresses 2248 8.2. Scenario 1: Block SNS Access during Business Hours 2250 The first example scenario is to "block SNS access during office 2251 hours" using a time-based firewall policy. In this scenario, all 2252 users registered as "employees" in the user-group list are unable to 2253 access Social Networking Services (SNS) during the office hours 2254 (weekdays). The XML instance is described below: 2256 2257 2259 security_policy_for_blocking_sns123 2260 2261 block_access_to_sns_during_office_hours 2262 2263 2264 2021-03-11T09:00:00.00Z 2265 2021-12-31T18:00:00.00Z 2266 2267 09:00:00Z 2268 18:00:00Z 2269 nsfcfi:monday 2270 nsfcfi:tuesday 2271 nsfcfi:wednesday 2272 nsfcfi:thursday 2273 nsfcfi:friday 2274 2275 2276 weekly 2277 2278 2279 2280 employees 2281 2282 2283 sns-websites 2284 2285 2286 2287 nsfcfi:drop 2288 2289 2290 2292 Figure 21: An XML Example for Time-based Firewall 2294 Time-based-condition Firewall 2296 1. The policy name is "security_policy_for_blocking_sns". 2298 2. The rule name is "block_access_to_sns_during_office_hours". 2300 3. The Source is "employees". 2302 4. The destination target is "sns-websites". "sns-websites" is the 2303 key which represents the list containing the information, such as 2304 URL, about sns-websites. 2306 5. The action required is to "drop" any attempt to connect to 2307 websites related to Social networking. 2309 8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a Company 2311 The second example scenario is to "block malicious VoIP/VoLTE packets 2312 coming to a company" using a VoIP policy. In this scenario, the 2313 calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that 2314 are classified as malicious are dropped. The IP addresses of the 2315 employees and malicious VOIP IDs should be blocked are stored in the 2316 database or datastore of the enterprise. Here and the rest of the 2317 cases assume that the security administrators or someone responsible 2318 for the existing and newly generated policies, are not aware of which 2319 and/or how many NSFs are needed to meet the security requirements. 2320 Figure 22 represents the XML document generated from YANG discussed 2321 in previous sections. Once a high-level seucurity policy is created 2322 by a security admin, it is delivered by the Consumer-Facing 2323 Interface, through RESTCONF server, to the security controller. The 2324 XML instance is described below: 2326 2327 2329 2330 security_policy_for_blocking_malicious_voip_packets 2331 2332 2333 Block_malicious_voip_and_volte_packets 2334 2335 2336 malicious-id 2337 2338 2339 employees 2340 2341 2342 2343 nsfcfi:drop 2344 2345 2346 2348 Figure 22: An XML Example for VoIP Security Service 2350 Custom-condition Firewall 2352 1. The policy name is 2353 "security_policy_for_blocking_malicious_voip_packets". 2355 2. The rule name is "Block_malicious_voip_and_volte_packets". 2357 3. The Source is "malicious-id". This can be a single ID or a list 2358 of IDs, depending on how the ID are stored in the database. The 2359 "malicious-id" is the key so that the security admin can read 2360 every stored malicious VOIP IDs that are named as "malicious-id". 2362 4. The destination target is "employees". "employees" is the key 2363 which represents the list containing information about employees, 2364 such as IP addresses. 2366 5. The action required is "drop" when any incoming packets are from 2367 "malicious-id". 2369 8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web 2370 Server 2372 The third example scenario is to "Mitigate HTTP and HTTPS flood 2373 attacks on a company web server" using a DDoS-attack mitigation 2374 policy. Here, the time information is not set because the service 2375 provided by the network should be maintained at all times. If the 2376 packets sent by any sources are more than the set threshold, then the 2377 admin can set the percentage of the packets to be dropped to safely 2378 maintain the service. In this scenario, the source is set as "any" 2379 to block any sources which send abnormal amount of packets. The 2380 destination is set as "web_server01". Once the rule is set and 2381 delivered and enforced to the nsfs by the securiy controller, the 2382 NSFs will monitor the incoming packet amounts and the destination to 2383 act according to the rule set. The XML instance is described below: 2385 2386 2388 security_policy_for_ddos_attacks 2389 2390 1000_packets_per_second 2391 2392 2393 2394 1000 2395 2396 2397 2398 2399 nsfcfi:drop 2400 2401 2402 2404 Figure 23: An XML Example for DDoS-attack Mitigation 2406 DDoS-condition Firewall 2408 1. The policy name is "security_policy_for_ddos_attacks". 2410 2. The rule name is "100_packets_per_second". 2412 3. The rate limit exists to limit the incoming amount of packets per 2413 second. In this case the rate limit is "1000" packets per 2414 second. This amount depends on the packet receiving capacity of 2415 the server devices. 2417 4. The Source is all sources which send abnormal amount of packets. 2419 5. The action required is to "drop" packet reception is more than 2420 1000 packets per second. 2422 9. XML Configuration Example of a User Group's Access Control for I2NSF 2423 Consumer-Facing Interface 2425 This is an example for creating privileges for a group of users 2426 (i.e., a user group) to access and use the I2NSF Consumer-Facing 2427 Interface to create security policies via the interface. For the 2428 access control of the Consumer-Facing Interface, the NACM module can 2429 be used. Figure 24 shows an XML example the access control of a user 2430 group (named Example-Group) for I2NSF Consumer-Facing Interface A 2431 group called Example-Group can be created and configured with NACM 2432 for the Consumer-Facing Interface. For Example-Group, a rule list 2433 can created with the name of Example-Group-Rules. Example-Group- 2434 Rules has two rules of Example-Group-Rule1 and Example-Group-Rule2 as 2435 follows. For Example-Group-Rule1, the privilege of "Read" is allowed 2436 to Example-Group for the Consumer-Facing Interface. On the other 2437 hand, for Example-Group-Rule2, the privileges of "Create", "Update", 2438 and "Delete" are denied against Example-Group for the Consumer-Facing 2439 Interface. 2441 2442 2443 true 2444 2445 2446 Example-Group 2447 Alice 2448 Bob 2449 Eve 2450 2451 2452 2453 Example-Group-Rules 2454 Example-Group 2455 2456 Example-Group-Rule1 2457 read 2458 ietf-i2nsf-cfi-policy 2459 permit 2460 2461 2462 Example-Group-Rule2 2463 create update delete 2464 ietf-i2nsf-cfi-policy 2465 deny 2466 2467 2468 2470 Figure 24: An XML Example of a User Group's Access Control for 2471 I2NSF Consumer- Facing Interface 2473 The access control for the I2NSF Consumer-Facing Interface is as 2474 follows. 2476 1. The NACM is enabled. 2478 2. As a group name, Example-Group is specified. 2480 3. As members of the group, Alice, Bob, and Eve are specified. 2482 4. As a rule list name, Example-Group-Rules is specified for 2483 managing privileges of Example-Group's members. 2485 5. As the first rule name, Example-Group-Rule1 is specified. This 2486 rule is used to give read privilege to Example-Group's members 2487 for the module of the I2NSF Consumer-Facing Interface. 2489 6. As the second rule name, Example-Group-Rule2 is specified. This 2490 rule is used to deny create, update, and delete privileges 2491 against Example-Group's members for the module of the I2NSF 2492 Consumer-Facing Interface. 2494 10. IANA Considerations 2496 This document requests IANA to register the following URI in the 2497 "IETF XML Registry" [RFC3688]: 2499 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2500 Registrant Contact: The IESG. 2501 XML: N/A; the requested URI is an XML namespace. 2503 This document requests IANA to register the following YANG module in 2504 the "YANG Module Names" registry [RFC7950][RFC8525]: 2506 name: ietf-i2nsf-cfi-policy 2507 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2508 prefix: nsfcfi 2509 reference: RFC XXXX 2511 // RFC Ed.: replace XXXX with an actual RFC number and remove 2512 // this note. 2514 11. Security Considerations 2516 The YANG module specified in this document defines a data schema 2517 designed to be accessed through network management protocols such as 2518 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 2519 the secure transport layer, and the required secure transport is 2520 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 2521 and the required secure transport is TLS [RFC8446]. 2523 The Network Configuration Access Control Model (NACM) [RFC8341] 2524 provides a means of restricting access to specific NETCONF or 2525 RESTCONF users to a preconfigured subset of all available NETCONF or 2526 RESTCONF protocol operations and contents. Thus, NACM SHOULD be used 2527 to restrict the NSF registration from unauthorized users. 2529 There are a number of data nodes defined in this YANG module that are 2530 writable, creatable, and deletable (i.e., config true, which is the 2531 default). These data nodes may be considered sensitive or vulnerable 2532 in some network environments. Write operations to these data nodes 2533 could have a negative effect on network and security operations. 2534 These data nodes are collected into a single list node with the 2535 following sensitivity/vulnerability: 2537 * list i2nsf-cfi-policy: Writing to almost any element of this YANG 2538 module would directly impact on the configuration of NSFs, e.g., 2539 completely turning off security monitoring and mitigation 2540 capabilities; altering the scope of this monitoring and 2541 mitigation; creating an overwhelming logging volume to overwhelm 2542 downstream analytics or storage capacity; creating logging 2543 patterns which are confusing; or rendering useless trained 2544 statistics or artificial intelligence models. 2546 Some of the readable data nodes in this YANG module may be considered 2547 sensitive or vulnerable in some network environments. It is thus 2548 important to control read access (e.g., via get, get-config, or 2549 notification) to these data nodes. These are the subtrees and data 2550 nodes with their sensitivity/vulnerability: 2552 * list i2nsf-cfi-policy: The leak of this node to an attacker could 2553 reveal the specific configuration of security controls to an 2554 attacker. An attacker can craft an attack path that avoids 2555 observation or mitigations; one may reveal topology information to 2556 inform additional targets or enable lateral movement; one enables 2557 the construction of an attack path that avoids observation or 2558 mitigations; one provides an indication that the operator has 2559 discovered the attack. This node also holds a list of endpoint 2560 data that is considered private to the users. 2562 12. Acknowledgments 2564 This work was supported by Institute of Information & Communications 2565 Technology Planning & Evaluation (IITP) grant funded by the Korea 2566 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 2567 Security Intelligence Technology Development for the Customized 2568 Security Service Provisioning). This work was supported in part by 2569 the IITP (2020-0-00395, Standard Development of Blockchain based 2570 Network Management Automation Technology). 2572 13. Contributors 2574 This document is made by the group effort of I2NSF working group. 2575 Many people actively contributed to this document, such as Mahdi F. 2576 Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their 2577 contributions. 2579 The following are co-authors of this document: 2581 Patrick Lingga Department of Electrical and Computer Engineering 2582 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 2583 16419 Republic of Korea EMail: patricklink@skku.edu 2585 Hyoungshick Kim Department of Computer Science and Engineering 2586 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 2587 16419 Republic of Korea EMail: hyoung@skku.edu 2589 Eunsoo Kim Department of Electronic, Electrical and Computer 2590 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 2591 Gyeonggi-do 16419 Republic of Korea EMail: eskim86@skku.edu 2593 Seungjin Lee Department of Electronic, Electrical and Computer 2594 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 2595 Gyeonggi-do 16419 Republic of Korea EMail: jine33@skku.edu 2597 Jinyong Tim Kim Department of Electronic, Electrical and Computer 2598 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 2599 Gyeonggi-do 16419 Republic of Korea EMail: timkim@skku.edu 2601 Anil Lohiya Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 2602 US EMail: alohiya@juniper.net 2604 Dave Qi Bloomberg 731 Lexington Avenue New York, NY 10022 US EMail: 2605 DQI@bloomberg.net 2607 Nabil Bitar Nokia 755 Ravendale Drive Mountain View, CA 94043 US 2608 EMail: nabil.bitar@nokia.com 2610 Senad Palislamovic Nokia 755 Ravendale Drive Mountain View, CA 94043 2611 US EMail: senad.palislamovic@nokia.com 2613 Liang Xia Huawei 101 Software Avenue Nanjing, Jiangsu 210012 China 2614 EMail: Frank.Xialiang@huawei.com 2616 14. References 2618 14.1. Normative References 2620 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2621 DOI 10.17487/RFC0768, August 1980, 2622 . 2624 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2625 RFC 792, DOI 10.17487/RFC0792, September 1981, 2626 . 2628 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2629 RFC 793, DOI 10.17487/RFC0793, September 1981, 2630 . 2632 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 2633 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 2634 1983, . 2636 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2637 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 2638 . 2640 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2641 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 2642 . 2644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2645 Requirement Levels", BCP 14, RFC 2119, 2646 DOI 10.17487/RFC2119, March 1997, 2647 . 2649 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2650 A., Peterson, J., Sparks, R., Handley, M., and E. 2651 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2652 DOI 10.17487/RFC3261, June 2002, 2653 . 2655 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 2656 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 2657 . 2659 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2660 DOI 10.17487/RFC3688, January 2004, 2661 . 2663 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 2664 Protocol Assigned Numbers", RFC 4250, 2665 DOI 10.17487/RFC4250, January 2006, 2666 . 2668 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2669 Congestion Control Protocol (DCCP)", RFC 4340, 2670 DOI 10.17487/RFC4340, March 2006, 2671 . 2673 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2674 Control Message Protocol (ICMPv6) for the Internet 2675 Protocol Version 6 (IPv6) Specification", STD 89, 2676 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2677 . 2679 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2680 DOI 10.17487/RFC5321, October 2008, 2681 . 2683 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2684 and A. Bierman, Ed., "Network Configuration Protocol 2685 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2686 . 2688 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2689 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2690 . 2692 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2693 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2694 . 2696 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2697 Protocol (HTTP/1.1): Message Syntax and Routing", 2698 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2699 . 2701 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2702 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2703 DOI 10.17487/RFC7231, June 2014, 2704 . 2706 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2707 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2708 . 2710 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2711 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2712 . 2714 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2715 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2716 May 2017, . 2718 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2719 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2720 . 2722 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2723 Access Control Model", STD 91, RFC 8341, 2724 DOI 10.17487/RFC8341, March 2018, 2725 . 2727 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2728 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2729 DOI 10.17487/RFC8407, October 2018, 2730 . 2732 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2733 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2734 . 2736 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 2737 and R. Wilton, "YANG Library", RFC 8525, 2738 DOI 10.17487/RFC8525, March 2019, 2739 . 2741 [I-D.ietf-tcpm-rfc793bis] 2742 Eddy, W. M., "Transmission Control Protocol (TCP) 2743 Specification", Work in Progress, Internet-Draft, draft- 2744 ietf-tcpm-rfc793bis-25, 7 September 2021, 2745 . 2748 14.2. Informative References 2750 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2751 DOI 10.17487/RFC2818, May 2000, 2752 . 2754 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2755 Address Translator (Traditional NAT)", RFC 3022, 2756 DOI 10.17487/RFC3022, January 2001, 2757 . 2759 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2760 Information Models and Data Models", RFC 3444, 2761 DOI 10.17487/RFC3444, January 2003, 2762 . 2764 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 2765 Reserved for Documentation", RFC 3849, 2766 DOI 10.17487/RFC3849, July 2004, 2767 . 2769 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 2770 Reserved for Documentation", RFC 5737, 2771 DOI 10.17487/RFC5737, January 2010, 2772 . 2774 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2775 Kumar, "Framework for Interface to Network Security 2776 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2777 . 2779 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 2780 Kumari, "A Format for Self-Published IP Geolocation 2781 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 2782 . 2784 [I-D.ietf-i2nsf-capability] 2785 Xia, L., Strassner, J., Basile, C., and D. R. Lopez, 2786 "Information Model of NSFs Capabilities", Work in 2787 Progress, Internet-Draft, draft-ietf-i2nsf-capability-05, 2788 24 April 2019, . 2791 [IANA-ICMP-Parameters] 2792 Internet Assigned Numbers Authority (IANA), "Assigned 2793 Internet Protocol Numbers", February 2021, 2794 . 2797 [IANA-ICMPv6-Parameters] 2798 Internet Assigned Numbers Authority (IANA), "Internet 2799 Control Message Procotol version 6 (ICMPv6) Parameters", 2800 February 2021, . 2803 [Encyclopedia-Britannica] 2804 Britannica, "Continent", September 2020, 2805 . 2807 [YARA] Alvarez, V., Bengen, H., Metz, J., Buehlmann, S., and W. 2808 Shields, "YARA", YARA 2809 Documents https://yara.readthedocs.io/en/v3.5.0/, August 2810 2020. 2812 [SURICATA] Julien, V. and , "SURICATA", SURICATA Documents 2813 https://suricata-ids.org/docs/, August 2020. 2815 [SNORT] Roesch, M., Green, C., and B. Caswell, "SNORT", SNORT 2816 Documents https://www.snort.org/#documents, August 2020. 2818 [STIX] Jordan, B., Piazza, R., and T. Darley, "Structured Threat 2819 Information Expression (STIX)", STIX Version 2.1: 2820 Committee Specification 01 https://docs.oasis- 2821 open.org/cti/stix/v2.1/stix-v2.1.pdf, March 2020. 2823 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- 2824 dm-14 2826 The following changes are made from draft-ietf-i2nsf-consumer-facing- 2827 interface-dm-14: 2829 * This version has been updated following Tom Petch's comments. 2831 Authors' Addresses 2833 Jaehoon (Paul) Jeong (editor) 2834 Department of Computer Science and Engineering 2835 Sungkyunkwan University 2836 2066 Seobu-Ro, Jangan-Gu 2837 Suwon 2838 Gyeonggi-Do 2839 16419 2840 Republic of Korea 2842 Phone: +82 31 299 4957 2843 Email: pauljeong@skku.edu 2844 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2845 Chaehong Chung 2846 Department of Electronic, Electrical and Computer Engineering 2847 Sungkyunkwan University 2848 2066 Seobu-Ro, Jangan-Gu 2849 Suwon 2850 Gyeonggi-Do 2851 16419 2852 Republic of Korea 2854 Phone: +82 31 299 4957 2855 Email: darkhong@skku.edu 2857 Tae-Jin Ahn 2858 Korea Telecom 2859 70 Yuseong-Ro, Yuseong-Gu 2860 Daejeon 2861 305-811 2862 Republic of Korea 2864 Phone: +82 42 870 8409 2865 Email: taejin.ahn@kt.com 2867 Rakesh Kumar 2868 Juniper Networks 2869 1133 Innovation Way 2870 Sunnyvale, CA 94089 2871 United States of America 2873 Email: rkkumar@juniper.net 2875 Susan Hares 2876 Huawei 2877 7453 Hickory Hill 2878 Saline, MI 48176 2879 United States of America 2881 Phone: +1-734-604-0332 2882 Email: shares@ndzh.com