idnits 2.17.1 draft-ietf-i2nsf-consumer-facing-interface-dm-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 29 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 275 has weird spacing: '...le-name str...' == Line 398 has weird spacing: '...version enu...' == Line 518 has weird spacing: '...address ine...' == Line 522 has weird spacing: '...address ine...' == Line 560 has weird spacing: '...address ine...' == (5 more instances...) -- The document date (21 August 2021) is 979 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 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 2 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: 22 February 2022 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 21 August 2021 13 I2NSF Consumer-Facing Interface YANG Data Model 14 draft-ietf-i2nsf-consumer-facing-interface-dm-14 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 22 February 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 . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 46 83 8.1. Database Registration: Information of Positions and Devices 84 (Endpoint Group) . . . . . . . . . . . . . . . . . . . . 46 85 8.2. Scenario 1: Block SNS Access during Business Hours . . . 48 86 8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a 87 Company . . . . . . . . . . . . . . . . . . . . . . . . . 50 88 8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a 89 Company Web Server . . . . . . . . . . . . . . . . . . . 51 90 9. XML Configuration Example of a User Group's Access Control for 91 I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 52 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 54 94 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55 95 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55 96 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 97 14.1. Normative References . . . . . . . . . . . . . . . . . . 56 98 14.2. Informative References . . . . . . . . . . . . . . . . . 57 99 Appendix A. Changes from 100 draft-ietf-i2nsf-consumer-facing-interface-dm-13 . . . . 59 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 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 | +--rw condition 279 | +--rw actions 280 Figure 3: Rule YANG Data Tree 282 Note that in the case of policy conflicts, the resolution of the 283 conflicted policies conforms to the guidelines of "Information Model 284 of NSFs Capabilities" [I-D.ietf-i2nsf-capability]. 286 3.1. Event Sub-model 288 The Event Object contains information related to scheduling a Rule. 289 The Rule could be activated based on a set time or security event. 290 Figure 4 shows the YANG tree of the Event object. Event object SHALL 291 have following information: 293 Security-event: This field identifies for which security event the 294 policy is enforced. The examples of security events are: 295 "DDOS", "spyware", "trojan", and "ransomware". 297 Time-information: This represents the security rule is enforced 298 based on the period information with the end time for the 299 event. 301 Start-date-time: This represents the start time of the event. The 302 rule will start repeating from the specified time" 304 End-date-time: This represents the end time of the event. If the 305 rule time has pass the end-time, the rule will stop 306 repeating" 308 Period: This represents the period of time the rule event is 309 active. It can be configured by the start-time, stop-time, 310 day, date, and month. 312 Frequency: This represents how frequent the rule should be enforced. 313 There are four options: "only-once", "daily", "weekly", 314 "monthly" or "yearly". 316 +--rw event 317 +--rw security-event identityref 318 +--rw time-information 319 | +--rw start-date-time? yang:date-and-time 320 | +--rw end-date-time? yang:date-and-time 321 | +--rw period 322 | | +--rw start-time? time 323 | | +--rw stop-time? time 324 | | +--rw day* identityref 325 | | +--rw date* int32 326 | | +--rw month* string 327 +--rw frequency? enumeration 329 Figure 4: Event Sub-model YANG Data Tree 331 3.2. Condition Sub-model 333 This object represents Conditions that Security Administrator wants 334 to apply the checking on the traffic in order to determine whether 335 the set of actions in the Rule can be executed or not. The Condition 336 Sub-model consists of three different types of containers each 337 representing different cases, such as general firewall and DDoS- 338 mitigation cases, and a case when the condition is based on the 339 payload strings of packets. Each containers have source and 340 destination-target to represent the source and destination for each 341 case. Figure 5 shows the YANG tree of the Condition object. The 342 Condition Sub-model SHALL have following information: 344 Case (firewall-condition): This field represents the general 345 firewall case, where a security admin can set up firewall 346 conditions using the information present in this field. 347 The source and destination is represented as source, 348 destination, transport layer protocol, port numbers, and 349 ICMP parameters. 351 Case (ddos-condition): This field represents the condition for DDoS 352 mitigation, where a security admin can set up DDoS 353 mitigation conditions using the information present in this 354 field. The rate of packet, byte, or flow threshold can be 355 configured to mitigate the DDoS. 357 Case (anti-virus-condition): This field represents the condition for 358 Antivirus, where a security admin can set up Antivirus 359 conditions using the information present in this field. 360 The file names or types can be configured to be allowed 361 without the Antivirus interuption. 363 Case (payload-condition): This field contains the payload string 364 information. This information is useful when security rule 365 condition is based on the string contents of incoming or 366 outgoing packets. The name referring to the payload-groups 367 defined and registered in the endpoint-groups. 369 Case (url-condition): This field represents the URL to be filtered. 370 This information can be used to block or allow a certain 371 URL or website. The url-name is a group of URL or websites 372 to be matched. 374 Case (voice-condition): This field contains the call source-id, call 375 destination-id, and user-agent. This information can be 376 used to filter a caller id or receiver id to prevent any 377 VoIP or VoLTE exploits or attack. 379 Case (context-condition): This field represents a context of a 380 packet or flow. The context can be extended. This module 381 provides a context of geography location. 383 Case (Threat-feed-condition): This field contains the information 384 obtained from threat-feeds (e.g., Palo-Alto, or RSA- 385 netwitness). This information is useful when security rule 386 condition is based on the existing threat reports gathered 387 by other sources. 389 +--rw condition 390 | +--rw firewall-condition 391 | | +--rw source* union 392 | | +--rw destination* union 393 | | +--rw transport-layer-protocol? identityref 394 | | +--rw range-port-number 395 | | | +--rw start-port-number? inet:port-number 396 | | | +--rw end-port-number? inet:port-number 397 | | +--rw icmp* [version] 398 | | +--rw version enumeration 399 | | +--rw type* uint8 400 | | +--rw code* uint8 401 | +--rw ddos-condition 402 | | +--rw rate-limit 403 | | +--rw packet-rate-threshold? uint32 404 | | +--rw byte-rate-threshold? uint32 405 | | +--rw flow-rate-threshold? uint32 406 | +--rw anti-virus-condition 407 | | +--rw exception-files* string 408 | +--rw payload-condition 409 | | +--rw content* 410 -> /i2nsf-cfi-policy/threat-preventions/payload-content/name 411 | +--rw url-condition 412 | | +--rw url-name? 413 -> /i2nsf-cfi-policy/endpoint-groups/url-group/name 414 | +--rw voice-condition 415 | | +--rw source-id* string 416 | | +--rw destination-id* string 417 | | +--rw user-agent* string 418 | +--rw context-condition 419 | +--rw geography-location-condition 420 | +--rw source* 421 -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 422 | +--rw destination* 423 -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 424 | | +--rw threat-feed-condition 425 | | +--rw name* 426 -> /i2nsf-cfi-policy/threat-preventions/threat-feed-list/name 428 Figure 5: Condition Sub-model YANG Data Tree 430 3.3. Action Sub-model 432 This object represents actions that Security Admin wants to perform 433 based on certain traffic class. Figure 6 shows the YANG tree of the 434 Action object. The Action object SHALL have following information: 436 Primary-action: This field identifies the action when a rule is 437 matched by an NSF. The action could be one of "pass", 438 "drop", "rate-limit", "mirror", "invoke-signaling", 439 "tunnel-encapsulation", "forwarding", and "transformation". 441 Secondary-action: This field identifies the action when a rule is 442 matched by an NSF. The action could be one of "rule-log" 443 and "session-log". 445 +--rw actions 446 | +--rw primary-action 447 | | +--rw action? identityref 448 | +--rw secondary-action 449 | +--rw log-action? identityref 451 Figure 6: Action Sub-model YANG Data Tree 453 4. Information Model for Policy Endpoint Groups 455 The Policy Endpoint Group is a very important part of building User- 456 Construct based policies. A Security Administrator would create and 457 use these objects to represent a logical entity in their business 458 environment, where a Security Policy is to be applied. There are 459 multiple managed objects that constitute a Policy's Endpoint Group, 460 as shown in Figure 7. Figure 8 shows the YANG tree of the Endpoint- 461 Groups object. This section lists these objects and relationship 462 among them. 464 It is assumed that the information of Endpoint Groups (e.g., User- 465 group, Device-group, and Location-group) such as the IP address(es) 466 of each member in a group are stored in the I2NSF database available 467 to the Security Controller, and that the IP address information of 468 each group in the I2NSF database is synchronized with other systems 469 in the networks under the same administration. 471 +-------------------+ 472 | Endpoint Groups | 473 +---------+---------+ 474 ^ 475 | 476 +--------------+-------+--------+---------------+ 477 0..n | 0..n | 0..n | 0..n | 478 +-----+----+ +------+-----+ +-------+------+ +-----+---+ 479 |User-group| |Device-group| |Location-group| |Url-group| 480 +----------+ +------------+ +--------------+ +---------+ 481 Figure 7: Endpoint Group Diagram 483 +--rw endpoint-groups 484 | +--rw user-group* [name] 485 | ... 486 | +--rw device-group* [name] 487 | ... 488 | +--rw location-group* [name] 489 | ... 490 | +--rw url-group* [name] 491 | ... 493 Figure 8: Endpoint Group YANG Data Tree 495 4.1. User Group 497 This object represents a User-Group. Figure 9 shows the YANG tree of 498 the User-Group object. The User-Group object SHALL have the 499 following information: 501 Name: This field identifies the name of this object. 503 mac-address: This represents the MAC address of a user in the user 504 group. 506 Range-ipv4-address: This represents the IPv4 address range of a user 507 in the user group. 509 Range-ipv6-address: This represents the IPv6 address range of a user 510 in the user group. 512 +--rw user-group* [name] 513 | +--rw name string 514 | +--rw mac-address* yang:mac-address 515 | +--rw (match-type) 516 | | +--:(range-match-ipv4) 517 | | | +--rw range-ipv4-address 518 | | | +--rw start-ipv4-address inet:ipv4-address 519 | | | +--rw end-ipv4-address inet:ipv4-address 520 | | +--:(range-match-ipv6) 521 | | +--rw range-ipv6-address 522 | | +--rw start-ipv6-address inet:ipv6-address 523 | | +--rw end-ipv6-address inet:ipv6-address 525 Figure 9: User Group YANG Data Tree 527 4.2. Device Group 529 This object represents a Device-Group. Figure 10 shows the YANG tree 530 of the Device-group object. The Device-Group object SHALL have the 531 following information: 533 Name: This field identifies the name of this object. 535 IPv4: This represents the IPv4 address of a device in the device 536 group. 538 IPv6: This represents the IPv6 address of a device in the device 539 group. 541 Range-ipv4-address: This represents the IPv4 address range of a 542 device in the device group. 544 Range-ipv6-address: This represents the IPv6 address range of a 545 device in the device group. 547 Application-protocol: This represents the application layer 548 protocols of devices. If this is not set, it cannot 549 support the appropriate protocol 551 +--rw device-group* [name] 552 +--rw name string 553 +--rw (match-type) 554 | +--:(exact-match-ipv4) 555 | | +--rw ipv4? inet:ipv4-address 556 | +--:(exact-match-ipv6) 557 | | +--rw ipv6? inet:ipv6-address 558 | +--:(range-match-ipv4) 559 | | +--rw range-ipv4-address* 560 | | | +--rw start-ipv4-address inet:ipv4-address 561 | | | +--rw end-ipv4-address inet:ipv4-address 562 | +--:(range-match-ipv6) 563 | | +--rw range-ipv6-address* 564 | | | +--rw start-ipv6-address inet:ipv6-address 565 | | | +--rw end-ipv6-address inet:ipv6-address 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 592 | | +--rw ipv4-prefix? inet:ipv4-prefix 593 | +--rw geo-ip-ipv6* [ipv6-address] 594 | | +--rw ipv6-address inet:ipv6-address 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 615 Figure 12: URL Group YANG Data Tree 617 5. Information Model for Threat Prevention 619 The threat prevention plays an important part in the overall security 620 posture by reducing the attack surfaces. This information could come 621 from various threat feeds (i.e., sources for obtaining the threat 622 information). There are multiple managed objects that constitute 623 this category. This section lists these objects and relationship 624 among them. Figure 14 shows the YANG tree of a Threat-Prevention 625 object. 627 +-------------------+ 628 | Threat Prevention | 629 +---------+---------+ 630 ^ 631 | 632 +---------+---------+ 633 0..n | 0..n | 634 +------+------+ +--------+--------+ 635 | Threat-feed | | payload-content | 636 +-------------+ +-----------------+ 638 Figure 13: Threat Prevention Diagram 640 +--rw threat-prevention 641 +--rw threat-feed-list* [name] 642 ... 643 +--rw payload-content* [name] 644 ... 646 Figure 14: Threat Prevention YANG Data Tree 648 5.1. Threat Feed 650 This object represents a threat feed which provides the signatures of 651 malicious activities. Figure 15 shows the YANG tree of a Threat- 652 feed-list. The Threat-Feed object SHALL have the following 653 information: 655 Name: This field identifies the name of this object. 657 Description: This is the description of the threat feed. The 658 description should have the clear indication of the 659 security attack such as attack type (e.g., APT) and file 660 types used (e.g., executable malware). 662 Signatures: This field contains the threat signatures of malicious 663 programs or activities provided by the threat-feed. The 664 examples of signature types are "YARA", "SURICATA", and 665 "SNORT" [YARA][SURICATA][SNORT]. 667 It is assumed that the I2NSF User obtains the threat signatures 668 (i.e., threat content patterns) from a threat-feed server (i.e., feed 669 provider), which is a server providing threat signatures. With the 670 obtained threat signatures, the I2NSF User can deliver them to the 671 Security Controller. The retrieval of the threat signatures by the 672 I2NSF User is out of scope in this document. 674 +--rw threat-prevention 675 +--rw threat-feed-list* [name] 676 +--rw name identityref 677 +--rw description? string 678 +--rw signatures* identityref 680 Figure 15: Threat Feed YANG Data Tree 682 5.2. Payload Content 684 This object represents a custom list created for the purpose of 685 defining an exception to threat feeds. Figure 16 shows the YANG tree 686 of a Payload-content list. The Payload-Content object SHALL have the 687 following information: 689 Name: This field identifies the name of this object. For 690 example, the name "backdoor" indicates the payload content 691 is related to a backdoor attack. 693 Description: This represents the description of how the payload 694 content is related to a security attack. 696 Content: This contains the payload contents, which are involed in a 697 security attack, such as strings. 699 +--rw payload-content* [name] 700 +--rw name string 701 +--rw description string 702 +--rw content* string 704 Figure 16: Payload Content in YANG Data Tree 706 6. Network Configuration Access Control Model (NACM) for I2NSF 707 Consumer-Facing Interface 709 Network Configuration Access Control Model (NACM) provides a user 710 group with an access control with the following features [RFC8341]: 712 * Independent control of action, data, and notification access is 713 provided. 715 * A simple and familiar set of datastore permissions is used. 717 * Support for YANG security tagging allows default security modes to 718 automatically exclude sensitive data. 720 * Separate default access modes for read, write, and execute 721 permissions are provided. 723 * Access control rules are applied to configurable groups of users. 725 The data model of the I2NSF Consumer-Facing Interface utilizes the 726 NACM's mechanisms to manage the access control on the I2NSF Consumer- 727 Facing Interface. The NACM with the above features can be used to 728 set up the access control rules of a user group in the I2NSF 729 Consumer-Facing Interface. 731 Figure 17 shows part of the NACM module to enable the access control 732 of a user group for the I2NSF Consumer-Facing Interface. To use the 733 NACM, a user needs to configure either a NETCONF server [RFC6241] or 734 a RESTCONF server [RFC8040] to enable the NACM module. Then, the 735 user can simply use an account of root or admin user for the access 736 control for the module of the I2NSF Consumer-Facing Interface (i.e., 737 ietf-i2nsf-cfi-policy). An XML example to configure the access 738 control a user group for the I2NSF Consumer-Facing Interface can be 739 seen in Section 9. 741 list rule { 742 key "name"; 743 ordered-by user; 744 leaf name { 745 type string { 746 length "1..max"; 747 } 748 description 749 "Arbitrary name assigned to the rule."; 750 } 752 leaf module-name { 753 type union { 754 type matchall-string-type; 755 type string; 756 } 757 default "*"; 758 description 759 "Name of the module associated with this rule." 760 } 762 leaf access-operations { 763 type union { 764 type matchall-string-type; 765 type access-operations-type; 766 } 767 default "*"; 768 description 769 "Access operations associated with this rule." 770 } 772 leaf action { 773 type action-type; 774 mandatory true; 775 description 776 "The access control action associated with the 777 rule. If a rule is determined to match a 778 particular request, then this object is used 779 to determine whether to permit or deny the 780 request."; 781 } 783 Figure 17: A Part of the NACM YANG Data Model 785 7. YANG Data Model of Consumer-Facing Interface 787 The main objective of this document is to provide both an information 788 model and the corresponding YANG data model of I2NSF Consumer-Facing 789 Interface. This interface can be used to deliver control and 790 management messages between an I2NSF User and Security Controller for 791 the I2NSF User's high-level security policies. 793 The semantics of the data model must be aligned with the information 794 model of the Consumer-Facing Interface. The transformation of the 795 information model is performed so that this YANG data model can 796 facilitate the efficient delivery of the control or management 797 messages. 799 This data model is designed to support the I2NSF framework that can 800 be extended according to the security needs. In other words, the 801 model design is independent of the content and meaning of specific 802 policies as well as the implementation approach. 804 With the YANG data model of I2NSF Consumer-Facing Interface, this 805 document suggests use cases for security policy rules such as time- 806 based firewall, VoIP/VoLTE security service, and DDoS-attack 807 mitigation in Section 8. 809 7.1. YANG Module of Consumer-Facing Interface 811 This section describes a YANG module of Consumer-Facing Interface. 812 This document provides identities in the data model to be used for 813 configuration of an NSF. Each identity is used for a different type 814 of configuration. The details are explained in the description of 815 each identity. This YANG module imports from [RFC6991]. It makes 816 references to 817 [RFC0854][RFC0959][RFC1939][RFC3022][RFC2818][RFC4250][RFC5321] 818 [RFC7230][RFC7231][STIX]. 820 file "ietf-i2nsf-cfi-policy@2021-08-21.yang" 821 module ietf-i2nsf-cfi-policy { 822 yang-version 1.1; 823 namespace 824 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; 825 prefix nsfcfi; 827 import ietf-inet-types{ 828 prefix inet; 829 reference "RFC 6991"; 830 } 832 import ietf-yang-types{ 833 prefix yang; 834 reference "RFC 6991"; 835 } 837 organization 838 "IETF I2NSF (Interface to Network Security Functions) 839 Working Group"; 841 contact 842 "WG Web: 843 WG List: 845 Editor: Jaehoon Paul Jeong 846 848 Editor: Patrick Lingga 849 "; 851 description 852 "This module is a YANG module for Consumer-Facing Interface. 854 Copyright (c) 2021 IETF Trust and the persons identified as 855 authors of the code. All rights reserved. 857 Redistribution and use in source and binary forms, with or 858 without modification, is permitted pursuant to, and subject to 859 the license terms contained in, the Simplified BSD License set 860 forth in Section 4.c of the IETF Trust's Legal Provisions 861 Relating to IETF Documents 862 (https://trustee.ietf.org/license-info). 864 This version of this YANG module is part of RFC XXXX 865 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 866 for full legal notices."; 868 // RFC Ed.: replace XXXX with an actual RFC number and remove 869 // this note. 871 revision "2021-08-21"{ 872 description "Initial revision."; 873 reference 874 "RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model"; 876 // RFC Ed.: replace XXXX with an actual RFC number and remove 877 // this note. 878 } 880 identity resolution-strategy { 881 description 882 "Base identity for resolution strategy"; 883 reference 884 "draft-ietf-i2nsf-capability-data-model-17: 885 I2NSF Capability YANG Data Model - Resolution Strategy"; 886 } 888 identity fmr { 889 base resolution-strategy; 890 description 891 "Identity for First Matching Rule (FMR)"; 892 reference 893 "draft-ietf-i2nsf-capability-data-model-17: 894 I2NSF Capability YANG Data Model - Resolution Strategy"; 895 } 897 identity lmr { 898 base resolution-strategy; 899 description 900 "Identity for Last Matching Rule (LMR)"; 901 reference 902 "draft-ietf-i2nsf-capability-data-model-17: 903 I2NSF Capability YANG Data Model - Resolution Strategy"; 904 } 906 identity pmr { 907 base resolution-strategy; 908 description 909 "Identity for Prioritized Matching Rule (PMR)"; 910 reference 911 "draft-ietf-i2nsf-capability-data-model-17: 912 I2NSF Capability YANG Data Model - Resolution Strategy"; 913 } 915 identity pmre { 916 base resolution-strategy; 917 description 918 "Identity for Prioritized Matching Rule 919 with Errors (PMRE)"; 920 reference 921 "draft-ietf-i2nsf-capability-data-model-17: 922 I2NSF Capability YANG Data Model - Resolution Strategy"; 923 } 925 identity pmrn { 926 base resolution-strategy; 927 description 928 "Identity for Prioritized Matching Rule 929 with No Errors (PMRN)"; 930 reference 931 "draft-ietf-i2nsf-capability-data-model-17: 932 I2NSF Capability YANG Data Model - Resolution Strategy"; 933 } 935 identity security-event-type { 936 description 937 "Base identity for security event types."; 938 } 940 identity ddos { 941 base security-event-type; 942 description 943 "Identity for DDoS event types."; 944 } 946 identity intrusion { 947 base security-event-type; 948 description 949 "Identity for intrusion event types."; 950 } 952 identity web-attack { 953 base security-event-type; 954 description 955 "Identity for web-attack event types."; 956 } 958 identity voip-volte { 959 base security-event-type; 960 description 961 "Identity for VoIP/VoLTE event types."; 962 } 964 identity protocol { 965 description 966 "This identity represents the protocol types."; 967 } 969 identity layer-4-protocol { 970 base protocol; 971 description 972 "Base identity for the Layer 4 (i.e., Transport Layer) 973 Protocols"; 974 } 976 identity tcp { 977 base layer-4-protocol; 978 description 979 "Base identity for TCP condition capabilities"; 980 reference 981 "RFC 793: Transmission Control Protocol 982 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 983 (TCP) Specification"; 984 } 986 identity udp { 987 base layer-4-protocol; 988 description 989 "Base identity for UDP condition capabilities"; 990 reference 991 "RFC 768: User Datagram Protocol"; 992 } 994 identity sctp { 995 base layer-4-protocol; 996 description 997 "Identity for SCTP condition capabilities"; 998 reference 999 "RFC 4960: Stream Control Transmission Protocol"; 1000 } 1002 identity dccp { 1003 base layer-4-protocol; 1004 description 1005 "Identity for DCCP condition capabilities"; 1006 reference 1007 "RFC 4340: Datagram Congestion Control Protocol"; 1008 } 1010 identity layer-7-protocol { 1011 base protocol; 1012 description 1013 "Base identity for the Layer 7 (i.e., Application Layer) 1014 Protocols"; 1015 } 1017 identity ftp { 1018 base layer-7-protocol; 1019 description 1020 "The identity for ftp protocol."; 1021 reference 1022 "RFC 959: File Transfer Protocol (FTP)"; 1023 } 1024 identity ssh { 1025 base layer-7-protocol; 1026 description 1027 "The identity for ssh protocol."; 1028 reference 1029 "RFC 4250: The Secure Shell (SSH) Protocol"; 1030 } 1032 identity telnet { 1033 base layer-7-protocol; 1034 description 1035 "The identity for telnet."; 1036 reference 1037 "RFC 854: Telnet Protocol"; 1038 } 1040 identity smtp { 1041 base layer-7-protocol; 1042 description 1043 "The identity for smtp."; 1044 reference 1045 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1046 } 1048 identity http { 1049 base layer-7-protocol; 1050 description 1051 "The identity for http."; 1052 reference 1053 "RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1054 Syntax and Routing 1055 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1056 and Content"; 1057 } 1059 identity https { 1060 base layer-7-protocol; 1061 description 1062 "The identity for https."; 1063 reference 1064 "RFC 2818: HTTP over TLS (HTTPS)"; 1065 } 1067 identity pop3 { 1068 base layer-7-protocol; 1069 description 1070 "The identity for pop3."; 1071 reference 1072 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1073 } 1075 identity nat { 1076 base layer-7-protocol; 1077 description 1078 "The identity for nat."; 1079 reference 1080 "RFC 3022: Traditional IP Network Address Translator (Traditional 1081 NAT)"; 1082 } 1084 identity action { 1085 description 1086 "Base identity for action"; 1087 } 1089 identity ingress-action { 1090 base action; 1091 description 1092 "Base identity to represents the ingress actions, such as 1093 pass, drop, rate-limit, and mirror."; 1094 } 1096 identity egress-action { 1097 base action; 1098 description 1099 "Base identity represents the egress actions, such as 1100 pass, drop, rate-limit, mirror, invoke-signaling, 1101 tunnel-encapsulation, forwarding, and transformation."; 1102 } 1104 identity pass { 1105 base ingress-action; 1106 description 1107 "The identity for pass."; 1108 } 1110 identity drop { 1111 base ingress-action; 1112 description 1113 "The identity for drop."; 1114 } 1116 identity rate-limit { 1117 base ingress-action; 1118 description 1119 "The identity for rate-limit."; 1121 } 1123 identity mirror { 1124 base ingress-action; 1125 description 1126 "The identity for mirroring."; 1127 } 1129 identity invoke-signaling { 1130 base egress-action; 1131 description 1132 "Identity for invoke signaling action capability"; 1133 reference 1134 "RFC 8329: Framework for Interface to Network Security 1135 Functions - Invoke-signaling action"; 1136 } 1138 identity tunnel-encapsulation { 1139 base egress-action; 1140 description 1141 "Identity for tunnel encapsulation action capability"; 1142 reference 1143 "RFC 8329: Framework for Interface to Network Security 1144 Functions - Tunnel Encapsulation"; 1145 } 1147 identity forwarding { 1148 base egress-action; 1149 description 1150 "Identity for forwarding action capability"; 1151 reference 1152 "RFC 8329: Framework for Interface to Network Security 1153 Functions - Forwarding action"; 1154 } 1156 identity transformation { 1157 base egress-action; 1158 description 1159 "Identity for transformation action capability"; 1160 reference 1161 "RFC 8329: Framework for Interface to Network Security 1162 Functions - Redirection action"; 1163 } 1165 identity log-action { 1166 description 1167 "Base identity for representing log actions, such as rule-log and 1168 session-log action."; 1170 } 1172 identity rule-log { 1173 base log-action; 1174 description 1175 "Identity for rule log-action capability. 1176 Log the received packet based on the rule"; 1177 } 1179 identity session-log { 1180 base log-action; 1181 description 1182 "Identity for session log-action capability. 1183 Log the received packet based on the session."; 1184 } 1186 identity signature-type { 1187 description 1188 "This represents the base identity for signature types."; 1189 } 1191 identity signature-yara { 1192 base signature-type; 1193 description 1194 "This represents the YARA signatures."; 1195 reference 1196 "YARA: YARA signatures are explained."; 1197 } 1199 identity signature-snort { 1200 base signature-type; 1201 description 1202 "This represents the SNORT signatures."; 1203 reference 1204 "SNORT: SNORT signatures are explained."; 1205 } 1207 identity signature-suricata { 1208 base signature-type; 1209 description 1210 "This represents the SURICATA signatures."; 1211 reference 1212 "SURICATA: SURICATA signatures are explained."; 1213 } 1215 identity threat-feed-type { 1216 description 1217 "This represents the base identity for threat-feed."; 1219 } 1221 identity day { 1222 description 1223 "This represents the base for days."; 1224 } 1226 identity monday { 1227 base day; 1228 description 1229 "This represents Monday."; 1230 } 1232 identity tuesday { 1233 base day; 1234 description 1235 "This represents Tuesday."; 1236 } 1238 identity wednesday { 1239 base day; 1240 description 1241 "This represents Wednesday."; 1242 } 1244 identity thursday { 1245 base day; 1246 description 1247 "This represents Thursday."; 1248 } 1250 identity friday { 1251 base day; 1252 description 1253 "This represents Friday."; 1254 } 1256 identity saturday { 1257 base day; 1258 description 1259 "This represents Saturday."; 1260 } 1262 identity sunday { 1263 base day; 1264 description 1265 "This represents Sunday."; 1266 } 1267 identity continent { 1268 description 1269 "Base Identity for continent types."; 1270 } 1272 identity africa { 1273 base continent; 1274 description 1275 "Identity for Africa."; 1276 } 1278 identity asia { 1279 base continent; 1280 description 1281 "Identity for Asia."; 1282 } 1284 identity europe { 1285 base continent; 1286 description 1287 "Identity for Europe."; 1288 } 1290 identity north-america { 1291 base continent; 1292 description 1293 "Identity for North America."; 1294 } 1296 identity south-america { 1297 base continent; 1298 description 1299 "Identity for South America."; 1300 } 1302 identity oceania { 1303 base continent; 1304 description 1305 "Identity for Oceania"; 1306 } 1308 /* 1309 * Typedefs 1310 */ 1311 typedef time { 1312 type string { 1313 pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' 1314 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 1316 } 1317 description 1318 "The time type represents an instance of time of zero-duration 1319 that recurs every day."; 1320 } 1322 /* 1323 * Groupings 1324 */ 1326 grouping ipv4-list { 1327 description 1328 "Grouping for an IPv4 address list."; 1329 leaf-list ipv4 { 1330 type inet:ipv4-address; 1331 description 1332 "This is the entry for an IPv4 address list."; 1333 } 1334 } 1336 grouping ipv6-list { 1337 description 1338 "Grouping for an IPv6 address list."; 1339 leaf-list ipv6 { 1340 type inet:ipv6-address; 1341 description 1342 "This is the entry for an IPv6 address list."; 1343 } 1344 } 1346 grouping ipv4 { 1347 description 1348 "Grouping for an IPv4 address."; 1349 leaf ipv4 { 1350 type inet:ipv4-address; 1351 description 1352 "This is the entry for an IPv4 address."; 1353 } 1354 } 1356 grouping ipv6 { 1357 description 1358 "Grouping for an IPv6 address."; 1359 leaf ipv6 { 1360 type inet:ipv6-address; 1361 description 1362 "This is the entry for an IPv6 address."; 1363 } 1365 } 1367 grouping ip-address-info { 1368 description 1369 "There are two types to configure a security policy 1370 for an IP address, such as IPv4 adress and IPv6 address."; 1371 choice match-type { 1372 description 1373 "User can choose between IPv4 and IPv6."; 1374 case range-match-ipv4 { 1375 container range-ipv4-address { 1376 leaf start-ipv4-address { 1377 type inet:ipv4-address; 1378 mandatory true; 1379 description 1380 "A start IPv4 address for a range match."; 1381 } 1382 leaf end-ipv4-address { 1383 type inet:ipv4-address; 1384 mandatory true; 1385 description 1386 "An end IPv4 address for a range match."; 1387 } 1388 description 1389 "A range match for IPv4 addresses is provided. 1390 Note that the start IPv4 address must be lower than 1391 the end IPv4 address."; 1392 } 1393 } 1394 case range-match-ipv6 { 1395 container range-ipv6-address { 1396 leaf start-ipv6-address { 1397 type inet:ipv6-address; 1398 mandatory true; 1399 description 1400 "A start IPv6 address for a range match."; 1401 } 1402 leaf end-ipv6-address { 1403 type inet:ipv6-address; 1404 mandatory true; 1405 description 1406 "An end IPv6 address for a range match."; 1407 } 1408 description 1409 "A range match for IPv6 addresses is provided. 1410 Note that the start IPv6 address must be lower than 1411 the end IPv6 address."; 1412 } 1414 } 1415 } 1416 } 1418 grouping user-group { 1419 description 1420 "This group represents user group information such as name and 1421 ip-address."; 1422 leaf name { 1423 type string; 1424 description 1425 "This represents the name of a user-group. A user-group name 1426 is used to map a user-group's name (e.g., employees) to IP 1427 address(es), MAC address(es). 1428 It is dependent on implementation."; 1429 } 1430 leaf-list mac-address { 1431 type yang:mac-address; 1432 description 1433 "Represent the MAC Address of a user-group. A user-group 1434 can have multiple MAC Addresses."; 1435 } 1436 uses ip-address-info{ 1437 description 1438 "This represents the IP addresses of a user-group."; 1439 refine match-type{ 1440 mandatory true; 1441 } 1442 } 1443 } 1445 grouping device-group { 1446 description 1447 "This group represents device group information such as 1448 ip-address protocol."; 1449 leaf name { 1450 type string; 1451 description 1452 "This represents the name of a device-group."; 1453 } 1454 uses ip-address-info{ 1455 refine match-type{ 1456 mandatory true; 1457 } 1458 } 1459 leaf-list application-protocol { 1460 type identityref { 1461 base layer-7-protocol; 1463 } 1464 description 1465 "This represents the application layer protocols of devices. 1466 If this is not set, it cannot support the appropriate 1467 protocol"; 1468 } 1469 } 1471 grouping location-group { 1472 description 1473 "This group represents location-group information such as geo-ip 1474 and continent."; 1475 leaf name { 1476 type string; 1477 description 1478 "This represents the name of a location."; 1479 } 1480 list geo-ip-ipv4 { 1481 key "ipv4-address"; 1482 description 1483 "This represents the list of IPv4 addresses based on a 1484 location."; 1485 leaf ipv4-address{ 1486 type inet:ipv4-address; 1487 description 1488 "This represents an IPv4 geo-ip address of a location."; 1489 } 1490 leaf ipv4-prefix{ 1491 type inet:ipv4-prefix; 1492 description 1493 "This represents the prefix for the IPv4 addresses."; 1494 } 1495 } 1496 list geo-ip-ipv6 { 1497 key "ipv6-address"; 1498 description 1499 "This represents the list of IPv6 addresses based on a 1500 location."; 1501 leaf ipv6-address{ 1502 type inet:ipv6-address; 1503 description 1504 "This represents an IPv6 geo-ip address of a location."; 1505 } 1506 leaf ipv6-prefix{ 1507 type inet:ipv6-prefix; 1508 description 1509 "This represents the prefix for the IPv6 addresses."; 1510 } 1512 } 1513 leaf continent { 1514 type identityref { 1515 base continent; 1516 } 1517 default asia; 1518 description 1519 "location-group has geo-ip addresses of the corresponding 1520 continent."; 1521 } 1522 } 1524 grouping payload-string { 1525 description 1526 "The grouping for payload-string content. It contains information 1527 such as name and string content."; 1528 leaf description { 1529 type string; 1530 description 1531 "This represents the description of a payload. If this is not 1532 set, it cannot support the description of how the payload 1533 content is related to a security attack."; 1534 } 1535 leaf-list content { 1536 type string; 1537 description 1538 "This represents the string of the payload contents. 1539 This content leaf-list contains the payload of a packet to 1540 analyze a threat. Due to the types of threats, the type of 1541 the content is defined as a string to accommodate any kind 1542 of a payload type such as HTTP, HTTPS, and SIP. If this is 1543 not set, it cannot support the payload contents involved in 1544 a security attack as a string."; 1545 } 1546 } 1548 list i2nsf-cfi-policy { 1549 key "policy-name"; 1550 description 1551 "This is a security policy list. Each policy in the list contains 1552 a list of security policy rules, and is a policy instance to have 1553 the information of where and when a policy needs to be applied."; 1554 leaf policy-name { 1555 type string; 1556 description 1557 "The name which identifies the policy."; 1558 } 1559 leaf resolution-strategy { 1560 type identityref { 1561 base resolution-strategy; 1562 } 1563 default fmr; 1564 description 1565 "The resolution strategies that can be used to 1566 specify how to resolve conflicts that occur between 1567 actions of the same or different policy rules that 1568 are matched and contained in this particular NSF"; 1570 reference 1571 "draft-ietf-i2nsf-capability-data-model-17: 1572 I2NSF Capability YANG Data Model - Resolution strategy"; 1573 } 1574 list rules { 1575 key "rule-name"; 1577 description 1578 "There can be a single or multiple number of rules."; 1579 leaf rule-name { 1580 type string; 1581 description 1582 "This represents the name for a rule."; 1583 } 1585 leaf priority { 1586 type uint8 { 1587 range "1..255"; 1588 } 1589 description 1590 "The priority keyword comes with a mandatory 1591 numeric value which can range from 1 through 255. 1592 Note that a higher number means a higher priority"; 1593 } 1595 container event { 1596 description 1597 "This represents an event (i.e., a security event), for which 1598 a security rule is made."; 1599 leaf security-event { 1600 type identityref { 1601 base security-event-type; 1602 } 1603 description 1604 "This contains the description of a security event. If this 1605 is not set, it cannot support what security event will be 1606 enforced."; 1607 } 1608 container time { 1609 description 1610 "The time when a security policy rule should be applied."; 1611 leaf start-date-time { 1612 type yang:date-and-time; 1613 description 1614 "This is the start date and time for a security policy 1615 rule."; 1616 } 1617 leaf end-date-time { 1618 type yang:date-and-time; 1619 description 1620 "This is the end date and time for a policy rule. The 1621 policy rule will stop working after the specified 1622 end-date-time."; 1623 } 1624 container period{ 1625 when 1626 "../frequency!='only-once'"; 1627 description 1628 "This represents the repetition time. In the case where 1629 the frequency is weekly, the days can be set."; 1630 leaf start-time { 1631 type time; 1632 description 1633 "This is a period's start time for an event."; 1634 } 1635 leaf end-time { 1636 type time; 1637 description 1638 "This is a period's end time for an event."; 1639 } 1640 leaf-list day { 1641 when 1642 "../../frequency='weekly'"; 1643 type identityref{ 1644 base day; 1645 } 1646 min-elements 1; 1647 description 1648 "This represents the repeated day of every week (e.g., 1649 Monday and Tuesday). More than one day can be 1650 specified."; 1651 } 1652 leaf-list date { 1653 when 1654 "../../frequency='monthly'"; 1655 type int32{ 1656 range "1..31"; 1657 } 1658 min-elements 1; 1659 description 1660 "This represents the repeated date of every month. 1661 More than one date can be specified."; 1662 } 1663 leaf-list month { 1664 when 1665 "../../frequency='yearly'"; 1666 type string{ 1667 pattern '\d{2}-\d{2}'; 1668 } 1669 min-elements 1; 1670 description 1671 "This represents the repeated date and month of every 1672 year. More than one can be specified. A pattern 1673 used here is Month and Date (MM-DD)."; 1674 } 1675 } 1677 leaf frequency { 1678 type enumeration { 1679 enum only-once { 1680 description 1681 "This represents that the rule is immediately 1682 enforced only once and not repeated. The policy 1683 will continuously be active from the start-time 1684 to the end-time."; 1685 } 1686 enum daily { 1687 description 1688 "This represents that the rule is enforced on a 1689 daily basis. The policy will be repeated daily 1690 until the end-date."; 1691 } 1692 enum weekly { 1693 description 1694 "This represents that the rule is enforced on a 1695 weekly basis. The policy will be repeated weekly 1696 until the end-date. The repeated days can be 1697 specified."; 1698 } 1699 enum monthly { 1700 description 1701 "This represents that the rule is enforced on a 1702 monthly basis. The policy will be repeated monthly 1703 until the end-date."; 1705 } 1706 enum yearly { 1707 description 1708 "This represents that the rule is enforced on a 1709 yearly basis. The policy will be repeated yearly 1710 until the end-date."; 1711 } 1712 } 1713 default only-once; 1714 description 1715 "This represents how frequently the rule should be 1716 enforced."; 1717 } 1718 } 1719 } 1721 container condition { 1722 description 1723 "Conditions for general security policies."; 1724 container firewall-condition { 1725 description 1726 "A general firewall condition based on the packet header."; 1727 leaf-list source { 1728 type union { 1729 type leafref { 1730 path 1731 "/i2nsf-cfi-policy/endpoint-groups/user-group/name"; 1732 } 1733 type leafref { 1734 path 1735 "/i2nsf-cfi-policy/endpoint-groups/device-group/name"; 1736 } 1737 } 1738 description 1739 "This describes the path of the source."; 1740 } 1742 leaf-list destination { 1743 type union { 1744 type leafref { 1745 path 1746 "/i2nsf-cfi-policy/endpoint-groups/user-group/name"; 1747 } 1748 type leafref { 1749 path 1750 "/i2nsf-cfi-policy/endpoint-groups/device-group/name"; 1751 } 1752 } 1753 description 1754 "This describes the path to the destinations."; 1755 } 1757 leaf transport-layer-protocol { 1758 type identityref { 1759 base layer-4-protocol; 1760 } 1761 description 1762 "The transport-layer protocol to be matched."; 1763 } 1765 container range-port-number { 1766 leaf start-port-number { 1767 type inet:port-number; 1768 description 1769 "A start port number for range match."; 1770 } 1771 leaf end-port-number { 1772 type inet:port-number; 1773 description 1774 "An end port number for range match."; 1775 } 1776 description 1777 "A range match for transport-layer port number. Note that 1778 the start port number value must be lower than the end 1779 port number value"; 1780 } 1782 list icmp { 1783 key "version"; 1784 description 1785 "Represents the ICMP packet header information to 1786 determine if the set of policy actions in this ECA 1787 policy rule should be executed or not."; 1788 reference 1789 "RFC 792: Internet Control Message Protocol 1790 RFC 8335: PROBE: A Utility for Probing Interfaces"; 1792 leaf version { 1793 type enumeration { 1794 enum icmpv4 { 1795 value "1"; 1796 description 1797 "The ICMPv4 Protocol as defined in RFC 792"; 1798 } 1799 enum icmpv6 { 1800 value "2"; 1801 description 1802 "The ICMPv6 Protocol as defined in RFC 4443"; 1803 } 1804 } 1805 description 1806 "The ICMP version to be matched. This value 1807 affected the type and code values."; 1808 reference 1809 "RFC 792: Internet Control Message Protocol 1810 RFC 4443: Internet Control Message Protocol (ICMPv6) 1811 for the Internet Protocol Version 6 (IPv6) 1812 Specification"; 1813 } 1815 leaf-list type { 1816 type uint8; 1817 description 1818 "The security policy rule according to 1819 ICMP type parameter."; 1820 reference 1821 "RFC 792: Internet Control Message Protocol 1822 RFC 8335: PROBE: A Utility for Probing Interfaces 1823 IANA: Internet Control Message Protocol (ICMP) 1824 Parameters 1825 IANA: Internet Control Message Protocol version 6 1826 (ICMPv6) Parameters"; 1827 } 1829 leaf-list code { 1830 type uint8; 1831 description 1832 "The security policy rule according to 1833 ICMP code parameter."; 1834 reference 1835 "RFC 792: Internet Control Message Protocol 1836 RFC 8335: PROBE: A Utility for Probing Interfaces 1837 IANA: Internet Control Message Protocol (ICMP) 1838 Parameters 1839 IANA: Internet Control Message Protocol version 6 1840 (ICMPv6) Parameters"; 1841 } 1842 } 1843 } 1845 container ddos-condition { 1846 description 1847 "A condition for a DDoS attack."; 1848 container rate-limit { 1849 description 1850 "This describes the rate-limit."; 1851 leaf packet-rate-threshold { 1852 type uint32; 1854 description 1855 "This is a trigger value for a rate limit of packet rate 1856 for a DDoS-attack mitigation."; 1857 } 1858 leaf byte-rate-threshold { 1859 type uint32; 1860 description 1861 "This is a trigger value for a rate limit of byte rate 1862 for a DDoS-attack mitigation."; 1863 } 1864 leaf flow-rate-threshold { 1865 type uint32; 1866 description 1867 "This is a trigger value for a rate limit of flow rate 1868 for a DDoS-attack mitigation."; 1869 } 1870 } 1871 } 1873 container anti-virus-condition { 1874 description 1875 "A condition for anti-virus"; 1877 leaf-list exception-files { 1878 type string; 1879 description 1880 "The type or name of the files to be excluded by the 1881 anti-virus. This can be used to keep the known harmless 1882 files."; 1883 } 1884 } 1886 container payload-condition { 1887 description 1888 "A condition based on a packet's content."; 1889 leaf-list content { 1890 type leafref { 1891 path "/i2nsf-cfi-policy/threat-preventions/" 1892 + "payload-content/name"; 1893 } 1894 description 1895 "This describes the paths to a packet content's"; 1896 } 1898 } 1900 container url-condition { 1901 description 1902 "Condition for url category"; 1903 leaf url-name { 1904 type leafref { 1905 path "/i2nsf-cfi-policy/endpoint-groups/url-group/name"; 1906 } 1907 description 1908 "This is description for the condition of a URL's 1909 category such as SNS sites, game sites, ecommerce 1910 sites, company sites, and university sites."; 1911 } 1912 } 1914 container voice-condition { 1915 description 1916 "For the VoIP/VoLTE security system, a VoIP/ 1917 VoLTE security system can monitor each 1918 VoIP/VoLTE flow and manage VoIP/VoLTE 1919 security rules controlled by a centralized 1920 server for VoIP/VoLTE security service 1921 (called VoIP IPS). The VoIP/VoLTE security 1922 system controls each switch for the 1923 VoIP/VoLTE call flow management by 1924 manipulating the rules that can be added, 1925 deleted, or modified dynamically."; 1926 reference 1927 "RFC 3261: SIP: Session Initiation Protocol"; 1929 leaf-list source-id { 1930 type string; 1931 description 1932 "The security policy rule according to 1933 a source voice ID for VoIP and VoLTE."; 1934 } 1936 leaf-list destination-id { 1937 type string; 1938 description 1939 "The security policy rule according to 1940 a destination voice ID for VoIP and VoLTE."; 1941 } 1943 leaf-list user-agent { 1944 type string; 1945 description 1946 "The security policy rule according to 1947 an user agent for VoIP and VoLTE."; 1948 } 1949 } 1951 container context-condition { 1952 description 1953 "Condition for matching the context of the packet, such as 1954 geographic location, time, packet direction"; 1955 container geography-location-condition { 1956 description 1957 "A condition for a location-based connection"; 1958 leaf-list source { 1959 type leafref { 1960 path "/i2nsf-cfi-policy/endpoint-groups/" 1961 + "location-group/name"; 1962 } 1963 description 1964 "This describes the paths to a location's sources."; 1965 } 1966 leaf-list destination { 1967 type leafref { 1968 path "/i2nsf-cfi-policy/endpoint-groups/" 1969 + "location-group/name"; 1970 } 1971 description 1972 "This describes the paths to a location's 1973 destinations."; 1974 } 1975 } 1976 } 1978 container threat-feed-condition { 1979 description 1980 "A condition based on the threat-feed information."; 1981 leaf-list name { 1982 type leafref { 1983 path 1984 "/i2nsf-cfi-policy/threat-preventions/" 1985 +"threat-feed-list/name"; 1986 } 1987 description 1988 "This describes the paths to a threat-feed's sources."; 1989 } 1990 } 1991 } 1993 container actions { 1994 description 1995 "This is the action container."; 1996 container primary-action { 1997 description 1998 "This represent primary actions (e.g., ingress and egress 1999 action) to be applied to a condition. 2000 If this is not set, it cannot support the primary 2001 actions."; 2002 leaf action { 2003 type identityref { 2004 base action; 2005 } 2006 description 2007 "Ingress Action: pass, drop, reject, rate-limit, 2008 and mirror. 2009 Egress action: mirror, invoke-signaling, 2010 tunnel-encapsulation, forwarding, and redirection."; 2011 } 2012 } 2013 container secondary-action { 2014 description 2015 "This represents secondary actions (e.g., log and syslog) 2016 to be applied if they are needed. If this is not set, 2017 it cannot support the secondary actions."; 2018 leaf log-action { 2019 type identityref { 2020 base log-action; 2021 } 2022 description 2023 "Log action: rule log and session log"; 2024 } 2025 } 2026 } 2027 } 2029 container endpoint-groups { 2030 description 2031 "A logical entity in a business environment, where a security 2032 policy is to be applied."; 2033 list user-group{ 2034 uses user-group; 2035 key "name"; 2036 description 2037 "This represents a user group."; 2038 } 2039 list device-group { 2040 key "name"; 2041 uses device-group; 2042 description 2043 "This represents a device group."; 2044 } 2045 list location-group{ 2046 key "name"; 2047 uses location-group; 2048 description 2049 "This represents a location group."; 2050 } 2051 list url-group { 2052 key "name"; 2053 description 2054 "This describes the list of URL."; 2055 leaf name { 2056 type string; 2057 description 2058 "This is the name of URL group, e.g., SNS sites, 2059 gaming sites, ecommerce sites"; 2060 } 2061 leaf-list url { 2062 type string; 2063 description 2064 "Specifies the URL to be added into the group."; 2065 } 2066 } 2067 } 2069 container threat-preventions { 2070 description 2071 "This describes the list of threat-preventions."; 2072 list threat-feed-list { 2073 key "name"; 2074 description 2075 "There can be a single or multiple number of threat-feeds."; 2076 leaf name { 2077 type string; 2078 description 2079 "This represents the name of the threat-feed."; 2080 } 2081 leaf description { 2082 type string; 2083 description 2084 "This represents the descriptions of a threat-feed. The 2085 description should include information, such as type, 2086 threat, method, and file type. Structured Threat 2087 Information Expression (STIX) can be used for description 2088 of a threat [STIX]."; 2089 } 2090 leaf-list signatures { 2091 type identityref { 2092 base signature-type; 2093 } 2094 description 2095 "This contains a list of signatures or hashes of the 2096 threats."; 2097 } 2098 } 2099 list payload-content { 2100 key "name"; 2101 leaf name { 2102 type string; 2103 description 2104 "This represents the name of a packet's payload-content. It 2105 should give an idea of why a specific payload content is 2106 marked as a threat. For example, the name 'backdoor' 2107 indicates the payload content is related to a backdoor 2108 attack."; 2109 } 2110 description 2111 "This represents a payload-string group."; 2112 uses payload-string; 2113 } 2114 } 2115 } 2116 } 2117 2119 Figure 18: YANG for Consumer-Facing Interface 2121 8. XML Configuration Examples of High-Level Security Policy Rules 2123 This section shows XML configuration examples of high-level security 2124 policy rules that are delivered from the I2NSF User to the Security 2125 Controller over the Consumer-Facing Interface. The considered use 2126 cases are: Database registration, time-based firewall for web 2127 filtering, VoIP/VoLTE security service, and DDoS-attack mitigation. 2129 8.1. Database Registration: Information of Positions and Devices 2130 (Endpoint Group) 2132 If new endpoints are introduced to the network, it is necessary to 2133 first register their data to the database. For example, if new 2134 members are newly introduced in either of three different groups 2135 (i.e., user-group, device-group, and url-group), each of them should 2136 be registered with information such as ip-addresses or protocols used 2137 by devices. 2139 Figure 19 shows an example XML representation of the registered 2140 information for the user-group and device-group with IPv4 addresses 2141 [RFC5737]. 2143 2144 2146 2147 2148 employees 2149 2150 192.0.2.11 2151 192.0.2.90 2152 2153 2154 2155 webservers 2156 2157 198.51.100.11 2158 198.51.100.20 2159 2160 nsfcfi:http 2161 nsfcfi:https 2162 2163 2164 sns-websites 2165 SNS_1 2166 SNS_2 2167 2168 2169 2171 Figure 19: Registering User-group and Device-group Information 2172 with IPv4 Addresses 2174 Also, Figure 20 shows an example XML representation of the registered 2175 information for the user-group and device-group with IPv6 addresses 2176 [RFC3849]. 2178 2179 2181 2182 2183 employees 2184 2185 2001:DB8:0:1::11 2186 2001:DB8:0:1::90 2187 2188 2189 2190 webservers 2191 2192 2001:DB8:0:2::11 2193 2001:DB8:0:2::20 2194 2195 nsfcfi:http 2196 nsfcfi:https 2197 2198 2199 sns-websites 2200 SNS_1 2201 SNS_2 2202 2203 2204 2206 Figure 20: Registering User-group and Device-group Information 2207 with IPv6 Addresses 2209 8.2. Scenario 1: Block SNS Access during Business Hours 2211 The first example scenario is to "block SNS access during office 2212 hours" using a time-based firewall policy. In this scenario, all 2213 users registered as "employees" in the user-group list are unable to 2214 access Social Networking Services (SNS) during the office hours 2215 (weekdays). The XML instance is described below: 2217 2218 2220 security_policy_for_blocking_sns123 2221 2222 block_access_to_sns_during_office_hours 2223 2224 2225 2021-03-11T09:00:00.00Z 2226 2021-12-31T18:00:00.00Z 2227 2228 09:00:00Z 2229 18:00:00Z 2230 nsfcfi:monday 2231 nsfcfi:tuesday 2232 nsfcfi:wednesday 2233 nsfcfi:thursday 2234 nsfcfi:friday 2235 2236 2237 weekly 2238 2239 2240 2241 employees 2242 2243 2244 sns-websites 2245 2246 2247 2248 nsfcfi:drop 2249 2250 2251 2253 Figure 21: An XML Example for Time-based Firewall 2255 Time-based-condition Firewall 2257 1. The policy name is "security_policy_for_blocking_sns". 2259 2. The rule name is "block_access_to_sns_during_office_hours". 2261 3. The Source is "employees". 2263 4. The destination target is "sns-websites". "sns-websites" is the 2264 key which represents the list containing the information, such as 2265 URL, about sns-websites. 2267 5. The action required is to "drop" any attempt to connect to 2268 websites related to Social networking. 2270 8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a Company 2272 The second example scenario is to "block malicious VoIP/VoLTE packets 2273 coming to a company" using a VoIP policy. In this scenario, the 2274 calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that 2275 are classified as malicious are dropped. The IP addresses of the 2276 employees and malicious VOIP IDs should be blocked are stored in the 2277 database or datastore of the enterprise. Here and the rest of the 2278 cases assume that the security administrators or someone responsible 2279 for the existing and newly generated policies, are not aware of which 2280 and/or how many NSFs are needed to meet the security requirements. 2281 Figure 22 represents the XML document generated from YANG discussed 2282 in previous sections. Once a high-level seucurity policy is created 2283 by a security admin, it is delivered by the Consumer-Facing 2284 Interface, through RESTCONF server, to the security controller. The 2285 XML instance is described below: 2287 2288 2290 2291 security_policy_for_blocking_malicious_voip_packets 2292 2293 2294 Block_malicious_voip_and_volte_packets 2295 2296 2297 malicious-id 2298 2299 2300 employees 2301 2302 2303 2304 nsfcfi:drop 2305 2306 2307 2309 Figure 22: An XML Example for VoIP Security Service 2311 Custom-condition Firewall 2313 1. The policy name is 2314 "security_policy_for_blocking_malicious_voip_packets". 2316 2. The rule name is "Block_malicious_voip_and_volte_packets". 2318 3. The Source is "malicious-id". This can be a single ID or a list 2319 of IDs, depending on how the ID are stored in the database. The 2320 "malicious-id" is the key so that the security admin can read 2321 every stored malicious VOIP IDs that are named as "malicious-id". 2323 4. The destination target is "employees". "employees" is the key 2324 which represents the list containing information about employees, 2325 such as IP addresses. 2327 5. The action required is "drop" when any incoming packets are from 2328 "malicious-id". 2330 8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web 2331 Server 2333 The third example scenario is to "Mitigate HTTP and HTTPS flood 2334 attacks on a company web server" using a DDoS-attack mitigation 2335 policy. Here, the time information is not set because the service 2336 provided by the network should be maintained at all times. If the 2337 packets sent by any sources are more than the set threshold, then the 2338 admin can set the percentage of the packets to be dropped to safely 2339 maintain the service. In this scenario, the source is set as "any" 2340 to block any sources which send abnormal amount of packets. The 2341 destination is set as "web_server01". Once the rule is set and 2342 delivered and enforced to the nsfs by the securiy controller, the 2343 NSFs will monitor the incoming packet amounts and the destination to 2344 act according to the rule set. The XML instance is described below: 2346 2347 2349 security_policy_for_ddos_attacks 2350 2351 1000_packets_per_second 2352 2353 2354 2355 1000 2356 2357 2358 2359 2360 nsfcfi:drop 2361 2362 2363 2365 Figure 23: An XML Example for DDoS-attack Mitigation 2367 DDoS-condition Firewall 2369 1. The policy name is "security_policy_for_ddos_attacks". 2371 2. The rule name is "100_packets_per_second". 2373 3. The rate limit exists to limit the incoming amount of packets per 2374 second. In this case the rate limit is "1000" packets per 2375 second. This amount depends on the packet receiving capacity of 2376 the server devices. 2378 4. The Source is all sources which send abnormal amount of packets. 2380 5. The action required is to "drop" packet reception is more than 2381 1000 packets per second. 2383 9. XML Configuration Example of a User Group's Access Control for I2NSF 2384 Consumer-Facing Interface 2386 This is an example for creating privileges for a group of users 2387 (i.e., a user group) to access and use the I2NSF Consumer-Facing 2388 Interface to create security policies via the interface. For the 2389 access control of the Consumer-Facing Interface, the NACM module can 2390 be used. Figure 24 shows an XML example the access control of a user 2391 group (named Example-Group) for I2NSF Consumer-Facing Interface A 2392 group called Example-Group can be created and configured with NACM 2393 for the Consumer-Facing Interface. For Example-Group, a rule list 2394 can created with the name of Example-Group-Rules. Example-Group- 2395 Rules has two rules of Example-Group-Rule1 and Example-Group-Rule2 as 2396 follows. For Example-Group-Rule1, the privilege of "Read" is allowed 2397 to Example-Group for the Consumer-Facing Interface. On the other 2398 hand, for Example-Group-Rule2, the privileges of "Create", "Update", 2399 and "Delete" are denied against Example-Group for the Consumer-Facing 2400 Interface. 2402 2403 2404 true 2405 2406 2407 Example-Group 2408 Alice 2409 Bob 2410 Eve 2411 2412 2413 2414 Example-Group-Rules 2415 Example-Group 2416 2417 Example-Group-Rule1 2418 read 2419 ietf-i2nsf-cfi-policy 2420 permit 2421 2422 2423 Example-Group-Rule2 2424 create update delete 2425 ietf-i2nsf-cfi-policy 2426 deny 2427 2428 2429 2431 Figure 24: An XML Example of a User Group's Access Control for 2432 I2NSF Consumer- Facing Interface 2434 The access control for the I2NSF Consumer-Facing Interface is as 2435 follows. 2437 1. The NACM is enabled. 2439 2. As a group name, Example-Group is specified. 2441 3. As members of the group, Alice, Bob, and Eve are specified. 2443 4. As a rule list name, Example-Group-Rules is specified for 2444 managing privileges of Example-Group's members. 2446 5. As the first rule name, Example-Group-Rule1 is specified. This 2447 rule is used to give read privilege to Example-Group's members 2448 for the module of the I2NSF Consumer-Facing Interface. 2450 6. As the second rule name, Example-Group-Rule2 is specified. This 2451 rule is used to deny create, update, and delete privileges 2452 against Example-Group's members for the module of the I2NSF 2453 Consumer-Facing Interface. 2455 10. IANA Considerations 2457 This document requests IANA to register the following URI in the 2458 "IETF XML Registry" [RFC3688]: 2460 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2461 Registrant Contact: The IESG. 2462 XML: N/A; the requested URI is an XML namespace. 2464 This document requests IANA to register the following YANG module in 2465 the "YANG Module Names" registry [RFC7950][RFC8525]: 2467 name: ietf-i2nsf-cfi-policy 2468 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2469 prefix: nsfcfi 2470 reference: RFC XXXX 2472 // RFC Ed.: replace XXXX with an actual RFC number and remove 2473 // this note. 2475 11. Security Considerations 2477 The data model for the I2NSF Consumer-Facing Interface is based on 2478 the I2NSF framework [RFC8329], so the same security considerations 2479 with the I2NSF framework should be included in this document. The 2480 data model needs a secure communication channel to protect the 2481 Consumer-Facing Interface between the I2NSF User and Security 2482 Controller. Also, the data model's management access control is 2483 based on Network Configuration Access Control Model(NACM) mechanisms 2484 [RFC8341]. 2486 12. Acknowledgments 2488 This work was supported by Institute of Information & Communications 2489 Technology Planning & Evaluation (IITP) grant funded by the Korea 2490 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 2491 Security Intelligence Technology Development for the Customized 2492 Security Service Provisioning). This work was supported in part by 2493 the IITP (2020-0-00395, Standard Development of Blockchain based 2494 Network Management Automation Technology). 2496 13. Contributors 2498 This document is made by the group effort of I2NSF working group. 2499 Many people actively contributed to this document, such as Mahdi F. 2500 Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their 2501 contributions. 2503 The following are co-authors of this document: 2505 Patrick Lingga Department of Electrical and Computer Engineering 2506 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 2507 16419 Republic of Korea EMail: patricklink@skku.edu 2509 Hyoungshick Kim Department of Computer Science and Engineering 2510 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 2511 16419 Republic of Korea EMail: hyoung@skku.edu 2513 Eunsoo Kim Department of Electronic, Electrical and Computer 2514 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 2515 Gyeonggi-do 16419 Republic of Korea EMail: eskim86@skku.edu 2517 Seungjin Lee Department of Electronic, Electrical and Computer 2518 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 2519 Gyeonggi-do 16419 Republic of Korea EMail: jine33@skku.edu 2521 Jinyong Tim Kim Department of Electronic, Electrical and Computer 2522 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 2523 Gyeonggi-do 16419 Republic of Korea EMail: timkim@skku.edu 2525 Anil Lohiya Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 2526 US EMail: alohiya@juniper.net 2528 Dave Qi Bloomberg 731 Lexington Avenue New York, NY 10022 US EMail: 2529 DQI@bloomberg.net 2531 Nabil Bitar Nokia 755 Ravendale Drive Mountain View, CA 94043 US 2532 EMail: nabil.bitar@nokia.com 2533 Senad Palislamovic Nokia 755 Ravendale Drive Mountain View, CA 94043 2534 US EMail: senad.palislamovic@nokia.com 2536 Liang Xia Huawei 101 Software Avenue Nanjing, Jiangsu 210012 China 2537 EMail: Frank.Xialiang@huawei.com 2539 14. References 2541 14.1. Normative References 2543 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 2544 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 2545 1983, . 2547 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2548 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 2549 . 2551 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2552 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 2553 . 2555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2556 Requirement Levels", BCP 14, RFC 2119, 2557 DOI 10.17487/RFC2119, March 1997, 2558 . 2560 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2561 DOI 10.17487/RFC3688, January 2004, 2562 . 2564 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 2565 Protocol Assigned Numbers", RFC 4250, 2566 DOI 10.17487/RFC4250, January 2006, 2567 . 2569 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2570 DOI 10.17487/RFC5321, October 2008, 2571 . 2573 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2574 and A. Bierman, Ed., "Network Configuration Protocol 2575 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2576 . 2578 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2579 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2580 . 2582 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2583 Protocol (HTTP/1.1): Message Syntax and Routing", 2584 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2585 . 2587 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2588 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2589 DOI 10.17487/RFC7231, June 2014, 2590 . 2592 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2593 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2594 . 2596 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2597 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2598 . 2600 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2601 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2602 May 2017, . 2604 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2605 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2606 . 2608 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2609 Access Control Model", STD 91, RFC 8341, 2610 DOI 10.17487/RFC8341, March 2018, 2611 . 2613 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2614 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2615 DOI 10.17487/RFC8407, October 2018, 2616 . 2618 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 2619 and R. Wilton, "YANG Library", RFC 8525, 2620 DOI 10.17487/RFC8525, March 2019, 2621 . 2623 14.2. Informative References 2625 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2626 DOI 10.17487/RFC2818, May 2000, 2627 . 2629 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2630 Address Translator (Traditional NAT)", RFC 3022, 2631 DOI 10.17487/RFC3022, January 2001, 2632 . 2634 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2635 Information Models and Data Models", RFC 3444, 2636 DOI 10.17487/RFC3444, January 2003, 2637 . 2639 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 2640 Reserved for Documentation", RFC 3849, 2641 DOI 10.17487/RFC3849, July 2004, 2642 . 2644 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 2645 Reserved for Documentation", RFC 5737, 2646 DOI 10.17487/RFC5737, January 2010, 2647 . 2649 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2650 Kumar, "Framework for Interface to Network Security 2651 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2652 . 2654 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 2655 Kumari, "A Format for Self-Published IP Geolocation 2656 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 2657 . 2659 [I-D.ietf-i2nsf-capability] 2660 Xia, L., Strassner, J., Basile, C., and D. R. Lopez, 2661 "Information Model of NSFs Capabilities", Work in 2662 Progress, Internet-Draft, draft-ietf-i2nsf-capability-05, 2663 24 April 2019, . 2666 [YARA] Alvarez, V., Bengen, H., Metz, J., Buehlmann, S., and W. 2667 Shields, "YARA", YARA 2668 Documents https://yara.readthedocs.io/en/v3.5.0/, August 2669 2020. 2671 [SURICATA] Julien, V. and , "SURICATA", SURICATA Documents 2672 https://suricata-ids.org/docs/, August 2020. 2674 [SNORT] Roesch, M., Green, C., and B. Caswell, "SNORT", SNORT 2675 Documents https://www.snort.org/#documents, August 2020. 2677 [STIX] Jordan, B., Piazza, R., and T. Darley, "Structured Threat 2678 Information Expression (STIX)", STIX Version 2.1: 2679 Committee Specification 01 https://docs.oasis- 2680 open.org/cti/stix/v2.1/stix-v2.1.pdf, March 2020. 2682 Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- 2683 dm-13 2685 The following changes are made from draft-ietf-i2nsf-consumer-facing- 2686 interface-dm-13: 2688 * This version has been updated to synchronize with other I2NSF 2689 documents. 2691 Authors' Addresses 2693 Jaehoon (Paul) Jeong (editor) 2694 Department of Computer Science and Engineering 2695 Sungkyunkwan University 2696 2066 Seobu-Ro, Jangan-Gu 2697 Suwon 2698 Gyeonggi-Do 2699 16419 2700 Republic of Korea 2702 Phone: +82 31 299 4957 2703 Email: pauljeong@skku.edu 2704 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2706 Chaehong Chung 2707 Department of Electronic, Electrical and Computer Engineering 2708 Sungkyunkwan University 2709 2066 Seobu-Ro, Jangan-Gu 2710 Suwon 2711 Gyeonggi-Do 2712 16419 2713 Republic of Korea 2715 Phone: +82 31 299 4957 2716 Email: darkhong@skku.edu 2717 Tae-Jin Ahn 2718 Korea Telecom 2719 70 Yuseong-Ro, Yuseong-Gu 2720 Daejeon 2721 305-811 2722 Republic of Korea 2724 Phone: +82 42 870 8409 2725 Email: taejin.ahn@kt.com 2727 Rakesh Kumar 2728 Juniper Networks 2729 1133 Innovation Way 2730 Sunnyvale, CA 94089 2731 United States of America 2733 Email: rkkumar@juniper.net 2735 Susan Hares 2736 Huawei 2737 7453 Hickory Hill 2738 Saline, MI 48176 2739 United States of America 2741 Phone: +1-734-604-0332 2742 Email: shares@ndzh.com