idnits 2.17.1 draft-ietf-i2nsf-consumer-facing-interface-dm-20.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 531 has weird spacing: '...address ine...' == Line 535 has weird spacing: '...address ine...' == Line 569 has weird spacing: '...address ine...' == Line 573 has weird spacing: '...address ine...' == Line 600 has weird spacing: '...address ine...' == (4 more instances...) -- The document date (23 May 2022) is 705 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) ** Downref: Normative reference to an Informational RFC: RFC 8329 ** Downref: Normative reference to an Informational RFC: RFC 8805 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-messaging' -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-semantics' == Outdated reference: A later version (-32) exists of draft-ietf-i2nsf-capability-data-model-31 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-18 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-tcpm-rfc793bis' Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 4 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: 24 November 2022 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 23 May 2022 13 I2NSF Consumer-Facing Interface YANG Data Model 14 draft-ietf-i2nsf-consumer-facing-interface-dm-20 16 Abstract 18 This document describes an information model and the corresponding 19 YANG data model for the Consumer-Facing Interface of the Security 20 Controller in an Interface to Network Security Functions (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 flow policies from users' 24 perspective. This information model is based on the "Event- 25 Condition-Action" (ECA) policy model defined by a capability 26 information model for I2NSF, and the YANG data model is defined for 27 enabling different users of a given I2NSF system to define, manage, 28 and monitor flow policies 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 24 November 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Information Model for Policy . . . . . . . . . . . . . . . . 5 66 3.1. Event Sub-model . . . . . . . . . . . . . . . . . . . . . 7 67 3.2. Condition Sub-model . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . 12 72 4.3. Location Group . . . . . . . . . . . . . . . . . . . . . 13 73 4.4. URL Group . . . . . . . . . . . . . . . . . . . . . . . . 14 74 5. Information Model for Threat Prevention . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 56 83 8.1. Database Registration: Information of Positions and Devices 84 (Endpoint Group) . . . . . . . . . . . . . . . . . . . . 57 85 8.2. Scenario 1: Block SNS Access during Business Hours . . . 58 86 8.3. Scenario 2: Block Malicious VoIP/VoCN Packets Coming to a 87 Company . . . . . . . . . . . . . . . . . . . . . . . . . 60 88 8.4. Scenario 3: Mitigate Flood Attacks on a Company Web 89 Server . . . . . . . . . . . . . . . . . . . . . . . . . 61 90 9. XML Configuration Example of a User Group's Access Control for 91 I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 63 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 65 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 66 96 12.2. Informative References . . . . . . . . . . . . . . . . . 70 97 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 71 98 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 71 99 Appendix C. Changes from 100 draft-ietf-i2nsf-consumer-facing-interface-dm-19 . . . . 72 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 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 to an I2NSF User, the Consumer-Facing 109 Interface is required because the web applications developed by each 110 vendor need to have a standard interface specifying the data types 111 used when the I2NSF User and Security Controller communicate with 112 each other 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 security 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 133 [I-D.ietf-i2nsf-capability-data-model] as the basic model for both 134 the NSF-Facing interface and Consumer-Facing Interface security 135 policy model of this document. 137 [RFC3444] explains differences between an information and data model. 138 This document uses the guidelines in [RFC3444] to define both the 139 information and data model for Consumer-Facing Interface. Figure 1 140 shows a high-level abstraction of Consumer-Facing Interface. A data 141 model, which represents an implementation of the information model in 142 a specific data representation language, is also defined in this 143 document. 145 +-----------------+ 146 | Consumer-Facing | 147 | Interface | 148 +--------+--------+ 149 ^ 150 | 151 +-------------+------------+ 152 | | | 153 +-----+----+ +-----+----+ +----+---+ 154 | Policy | | Endpoint | | Threat | 155 | | | groups | | feed | 156 +-----+----+ +----------+ +--------+ 157 ^ 158 | 159 +------+------+ 160 | Rule | 161 +------+------+ 162 ^ 163 | 164 +----------------+----------------+ 165 | | | 166 +------+------+ +------+------+ +------+------+ 167 | Event | | Condition | | Action | 168 +-------------+ +-------------+ +-------------+ 170 Figure 1: Diagram for High-level Abstraction of Consumer-Facing 171 Interface 173 Data models are defined at a lower level of abstraction and provide 174 many details. They provide details about the implementation of a 175 protocol's specification, e.g., rules that explain how to map managed 176 objects onto lower-level protocol constructs. Since conceptual 177 models can be implemented in different ways, multiple data models can 178 be derived from a single information model. 180 The efficient and flexible provisioning of network functions by a 181 Network Functions Virtualization (NFV) system leads to a rapid 182 advance in the network industry. As practical applications, Network 183 Security Functions (NSFs), such as firewall, Intrusion Detection 184 System (IDS)/Intrusion Prevention System (IPS), and attack 185 mitigation, can also be provided as Virtual Network Functions (VNF) 186 in the NFV system. By the efficient virtualization technology, these 187 VNFs might be automatically provisioned and dynamically migrated 188 based on real-time security requirements. This document presents a 189 YANG data model to implement security functions based on NFV. 191 2. Terminology 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in BCP 196 14 [RFC2119] [RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 This document uses the terminology described in [RFC8329]. 201 This document follows the guidelines of [RFC8407], uses the common 202 YANG types defined in [RFC6991], and adopts the Network Management 203 Datastore Architecture (NMDA) [RFC8342]. The meaning of the symbols 204 in tree diagrams is defined in [RFC8340]. 206 3. Information Model for Policy 208 A Policy object represents a mechanism to express a Security Policy 209 by Security Administrator (i.e., I2NSF User) using Consumer-Facing 210 Interface toward Security Controller; the policy would be enforced on 211 an NSF. Figure 2 shows the YANG tree of the Policy object. The 212 Policy object SHALL have the following information: 214 Name: This field identifies the name of this object. 216 Language: The language field indicates the language tag that is used 217 for the natural language text that is included in all of 218 the 'description' attributes. The language field is 219 encoded following the rules in Section 2.1 of [RFC5646]. 220 The default language tag is "en-US". 222 Resolution-strategy: This field represents how to resolve conflicts 223 that occur between actions of the same or different policy 224 rules that are matched and contained in this particular 225 NSF. The resolution strategy is described in 226 [I-D.ietf-i2nsf-capability-data-model] in detail. 228 Rules: This field contains a list of rules. These rules are 229 defined for 1) communication between two Endpoint Groups, 230 2) for preventing communication with externally or 231 internally identified threats, and 3) for implementing 232 business requirement such as controlling access to internal 233 or external resources for meeting regulatory compliance or 234 business objectives. An organization may restrict certain 235 communication between a set of user and applications for 236 example. The threats may be from threat feeds obtained 237 from external sources or dynamically identified by using 238 specialty devices in the network. Rule conflict analysis 239 should be triggered by the monitoring service to perform an 240 exhaustive detection of anomalies among the configuration 241 rules installed into the security functions. 243 module: ietf-i2nsf-cons-facing-interface 244 +--rw i2nsf-cfi-policy* [name] 245 +--rw name string 246 +--rw language? string 247 +--rw resolution-strategy? identityref 248 +--rw rules* [name] 249 | ... 250 +--rw endpoint-groups 251 | ... 252 +--rw threat-prevention 253 ... 255 Figure 2: Policy YANG Data Tree 257 A policy is a list of rules. In order to express a Rule, a Rule must 258 have complete information such as where and when a policy needs to be 259 applied. This is done by defining a set of managed objects and 260 relationship among them. A Policy Rule may be related segmentation, 261 threat mitigation or telemetry data collection from an NSF in the 262 network, which will be specified as the sub-model of the policy model 263 in the subsequent sections. Figure 3 shows the YANG data tree of the 264 Rule object. The rule object SHALL have the following information: 266 Name: This field identifies the name of this object. 268 Priority: This field identifies the priority of the rule. 270 Event: This field includes the information to determine whether 271 the Rule Condition can be evaluated or not. See details in 272 Section 3.1. 274 Condition: This field contains all the checking conditions to apply 275 to the objective traffic. See details Section 3.2. 277 Action: This field identifies the action taken when a rule is 278 matched. There is always an implicit action to drop 279 traffic if no rule is matched for a traffic type. See 280 details in Section 3.3. 282 +--rw rules* [name] 283 | +--rw name string 284 | +--rw priority? uint8 285 | +--rw event 286 | | ... 287 | +--rw condition 288 | | ... 289 | +--rw action 290 | ... 292 Figure 3: Rule YANG Data Tree 294 3.1. Event Sub-model 296 The Event Object contains information related to scheduling a Rule. 297 The Rule could be activated based on a security event (i.e., system 298 event and system alarm). Figure 4 shows the YANG tree of the Event 299 object. Event object SHALL have following information: 301 System-event (also called alert): is defined as a warning about any 302 changes of configuration, any access violation, the 303 information of sessions and traffic flows. 305 System-alarm: is defined as a warning related to service degradation 306 in system hardware. 308 | +--rw event 309 | | +--rw system-event* identityref 310 | | +--rw system-alarm* identityref 312 Figure 4: Event Sub-model YANG Data Tree 314 3.2. Condition Sub-model 316 This object represents Conditions that Security Administrator wants 317 to apply the checking on the traffic in order to determine whether 318 the set of actions in the Rule can be executed or not. The Condition 319 Sub-model consists of three different types of containers each 320 representing different cases, such as general firewall and DDoS- 321 mitigation cases, and a case when the condition is based on the 322 payload strings of packets. Each containers have source and 323 destination-target to represent the source and destination for each 324 case. Figure 5 shows the YANG tree of the Condition object. The 325 Condition Sub-model SHALL have following information: 327 Case (firewall): This field represents the general firewall case, 328 where a security admin can set up firewall conditions using 329 the information present in this field. The firewall 330 attributes are represented by source, destination, 331 transport layer protocol, port numbers, and ICMP 332 parameters. Note that the YANG module only provide high- 333 level ICMP messages that is shared between ICMPv4 and 334 ICMPv6 (e.g., Destination Unreachable: Port Unreachable 335 which is ICMPv4 type 3 code 3 or ICMPv6 type 1 code 4). 336 Also note that QUIC protocol [RFC9000] is excluded in the 337 data model as it is not considered in the initial I2NSF 338 documents [RFC8329]. The QUIC traffic should not be 339 treated as UDP traffic and will be considered in the future 340 I2NSF documents. 342 Case (ddos): This field represents the condition for DDoS 343 mitigation, where a security admin can set up DDoS 344 mitigation conditions using the information present in this 345 field. The rate of packet, byte, or flow threshold can be 346 configured to mitigate the DDoS. 348 Case (anti-virus): This field represents the condition for 349 Antivirus, where a security admin can set up Antivirus 350 conditions using the information present in this field. 351 The file names or types can be configured to be allowed 352 without the Antivirus interuption. 354 Case (payload): This field contains the payload string information. 355 This information is useful when security rule condition is 356 based on the string contents of incoming or outgoing 357 packets. The name referring to the payload-groups defined 358 and registered in the endpoint-groups. 360 Case (url-category): This field represents the URL to be filtered. 361 This information can be used to block or allow a certain 362 URL or website. The url-name is a group of URL or websites 363 to be matched. 365 Case (voice): This field contains the call source-id, call 366 destination-id, and user-agent. This information can be 367 used to filter a caller id or receiver id to prevent any 368 VoIP or VoCN exploits or attack. 370 Case (context): This field provide extra information for the 371 condition for filtering the network traffic. The given 372 context conditions are application filter, device type, 373 user condition, and geographic location. 375 Case (Threat-feed): This field contains the information obtained 376 from threat-feeds (e.g., Palo-Alto, or RSA-netwitness). 377 This information is useful when security rule condition is 378 based on the existing threat reports gathered by other 379 sources. 381 | +--rw condition 382 | | +--rw firewall 383 | | | +--rw source* union 384 | | | +--rw destination* union 385 | | | +--rw transport-layer-protocol? identityref 386 | | | +--rw range-port-number 387 | | | | +--rw start-port-number? inet:port-number 388 | | | | +--rw end-port-number? inet:port-number 389 | | | +--rw icmp 390 | | | +--rw message* identityref 391 | | +--rw ddos 392 | | | +--rw rate-limit 393 | | | +--rw packet-rate-threshold? uint64 394 | | | +--rw byte-rate-threshold? uint64 395 | | | +--rw flow-rate-threshold? uint64 396 | | +--rw anti-virus 397 | | | +--rw exception-files* string 398 | | +--rw payload 399 | | | +--rw content* 400 -> /i2nsf-cfi-policy/threat-prevention/payload-content/name 401 | | +--rw url-category 402 | | | +--rw url-name? 403 -> /i2nsf-cfi-policy/endpoint-groups/url-group/name 404 | | +--rw voice 405 | | | +--rw source-id* string 406 | | | +--rw destination-id* string 407 | | | +--rw user-agent* string 408 | | +--rw context 409 | | | +--rw time 410 | | | | +--rw start-date-time? yang:date-and-time 411 | | | | +--rw end-date-time? yang:date-and-time 412 | | | | +--rw period 413 | | | | | +--rw start-time? time 414 | | | | | +--rw end-time? time 415 | | | | | +--rw day* day 416 | | | | | +--rw date* int32 417 | | | | | +--rw month* string 418 | | | | +--rw frequency? enumeration 419 | | | +--rw application 420 | | | | +--rw protocol* identityref 421 | | | +--rw device-type 422 | | | | +--rw device* identityref 423 | | | +--rw users 424 | | | | +--rw user* [id] 425 | | | | | +--rw id uint32 426 | | | | | +--rw name? string 427 | | | | +--rw group* [id] 428 | | | | +--rw id uint32 429 | | | | +--rw name? string 430 | | | +--rw geographic-location 431 | | | +--rw source* 432 -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 433 | | | +--rw destination* 434 -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 435 | | +--rw threat-feed 436 | | +--rw name* 437 -> /i2nsf-cfi-policy/threat-prevention/threat-feed-list/name 439 Figure 5: Condition Sub-model YANG Data Tree 441 3.3. Action Sub-model 443 This object represents actions that Security Admin wants to perform 444 based on certain traffic class. Figure 6 shows the YANG tree of the 445 Action object. The Action object SHALL have following information: 447 Primary-action: This field identifies the action when a rule is 448 matched by an NSF. The action could be one of "pass", 449 "drop", "reject", "rate-limit", "mirror", "invoke- 450 signaling", "tunnel-encapsulation", "forwarding", and 451 "transformation". 453 Secondary-action: This field identifies the action when a rule is 454 matched by an NSF. The action could be one of "rule-log" 455 and "session-log". 457 +--rw action 458 | +--rw primary-action 459 | | +--rw action? identityref 460 | +--rw secondary-action 461 | +--rw log-action? identityref 463 Figure 6: Action Sub-model YANG Data Tree 465 4. Information Model for Policy Endpoint Groups 467 The Policy Endpoint Group is a very important part of building User- 468 Construct based policies. A Security Administrator would create and 469 use these objects to represent a logical entity in their business 470 environment, where a Security Policy is to be applied. There are 471 multiple managed objects that constitute a Policy's Endpoint Group, 472 as shown in Figure 7. Figure 8 shows the YANG tree of the Endpoint- 473 Groups object. This section lists these objects and relationship 474 among them. 476 It is assumed that the information of Endpoint Groups (e.g., User- 477 group, Device-group, and Location-group) such as the IP address(es) 478 of each member in a group are stored in the I2NSF database available 479 to the Security Controller, and that the IP address information of 480 each group in the I2NSF database is synchronized with other systems 481 in the networks under the same administration. 483 +-------------------+ 484 | Endpoint Groups | 485 +---------+---------+ 486 ^ 487 | 488 +--------------+-------+--------+---------------+ 489 0..n | 0..n | 0..n | 0..n | 490 +-----+----+ +------+-----+ +-------+------+ +-----+---+ 491 |User-group| |Device-group| |Location-group| |Url-group| 492 +----------+ +------------+ +--------------+ +---------+ 494 Figure 7: Endpoint Group Diagram 496 +--rw endpoint-groups 497 | +--rw user-group* [name] 498 | ... 499 | +--rw device-group* [name] 500 | ... 501 | +--rw location-group* [name] 502 | ... 503 | +--rw url-group* [name] 504 | ... 506 Figure 8: Endpoint Group YANG Data Tree 508 4.1. User Group 510 This object represents a User-Group. Figure 9 shows the YANG tree of 511 the User-Group object. The User-Group object SHALL have the 512 following information: 514 Name: This field identifies the name of this object. 516 mac-address: This represents the MAC address of a user in the user 517 group. 519 Range-ipv4-address: This represents the IPv4 address range of a user 520 in the user group. 522 Range-ipv6-address: This represents the IPv6 address range of a user 523 in the user group. 525 +--rw user-group* [name] 526 | +--rw name string 527 | +--rw mac-address* yang:mac-address 528 | +--rw (match-type) 529 | +--:(range-match-ipv4) 530 | | +--rw range-ipv4-address 531 | | +--rw start-ipv4-address inet:ipv4-address-no-zone 532 | | +--rw end-ipv4-address inet:ipv4-address-no-zone 533 | +--:(range-match-ipv6) 534 | +--rw range-ipv6-address 535 | +--rw start-ipv6-address inet:ipv6-address-no-zone 536 | +--rw end-ipv6-address inet:ipv6-address-no-zone 538 Figure 9: User Group YANG Data Tree 540 4.2. Device Group 542 This object represents a Device-Group. Figure 10 shows the YANG tree 543 of the Device-group object. The Device-Group object SHALL have the 544 following information: 546 Name: This field identifies the name of this object. 548 IPv4: This represents the IPv4 address of a device in the device 549 group. 551 IPv6: This represents the IPv6 address of a device in the device 552 group. 554 Range-ipv4-address: This represents the IPv4 address range of a 555 device in the device group. 557 Range-ipv6-address: This represents the IPv6 address range of a 558 device in the device group. 560 Application-protocol: This represents the application layer 561 protocols of devices. If this is not set, it cannot 562 support the appropriate protocol 564 +--rw device-group* [name] 565 | +--rw name string 566 | +--rw (match-type) 567 | | +--:(range-match-ipv4) 568 | | | +--rw range-ipv4-address 569 | | | +--rw start-ipv4-address inet:ipv4-address-no-zone 570 | | | +--rw end-ipv4-address inet:ipv4-address-no-zone 571 | | +--:(range-match-ipv6) 572 | | +--rw range-ipv6-address 573 | | +--rw start-ipv6-address inet:ipv6-address-no-zone 574 | | +--rw end-ipv6-address inet:ipv6-address-no-zone 575 | +--rw application-protocol* identityref 577 Figure 10: Device Group YANG Data Tree 579 4.3. Location Group 581 This object represents a location group based on either tag or other 582 information. Figure 11 shows the YANG tree of the Location-Group 583 object. The Location-Group object SHALL have the following 584 information: 586 Name: This field identifies the name of this object. 588 Geo-ip-ipv4: This field represents the IPv4 Geo-ip address of a 589 location [RFC8805]. 591 Geo-ip-ipv6: This field represents the IPv6 Geo-ip address of a 592 location [RFC8805]. 594 Continent: This field represents the continent where the location 595 group member is located. 597 +--rw location-group* [name] 598 | +--rw name string 599 | +--rw geo-ip-ipv4* [ipv4-address] 600 | | +--rw ipv4-address inet:ipv4-address-no-zone 601 | | +--rw ipv4-prefix? inet:ipv4-prefix 602 | +--rw geo-ip-ipv6* [ipv6-address] 603 | | +--rw ipv6-address inet:ipv6-address-no-zone 604 | | +--rw ipv6-prefix? inet:ipv6-prefix 605 | +--rw continent? identityref 607 Figure 11: Location Group YANG Data Tree 609 4.4. URL Group 611 This object represents a URL group based on a Uniform Resource 612 Locator (URL) or web address. Figure 12 shows the YANG tree of the 613 URL-Group object. The URLn-Group object SHALL have the following 614 information: 616 Name: This field identifies the name of this object. 618 url: This field represents the new URL added by a user to the 619 URL database. 621 +--rw url-group* [name] 622 +--rw name string 623 +--rw url* string 625 Figure 12: URL Group YANG Data Tree 627 5. Information Model for Threat Prevention 629 The threat prevention plays an important part in the overall security 630 posture by reducing the attack surfaces. This information could come 631 from various threat feeds (i.e., sources for obtaining the threat 632 information). There are multiple managed objects that constitute 633 this category. This section lists these objects and relationship 634 among them. Figure 14 shows the YANG tree of a Threat-Prevention 635 object. 637 +-------------------+ 638 | Threat Prevention | 639 +---------+---------+ 640 ^ 641 | 642 +---------+---------+ 643 0..n | 0..n | 644 +------+------+ +--------+--------+ 645 | Threat-feed | | Payload-content | 646 +-------------+ +-----------------+ 648 Figure 13: Threat Prevention Diagram 650 +--rw threat-prevention 651 +--rw threat-feed-list* [name] 652 ... 653 +--rw payload-content* [name] 654 ... 656 Figure 14: Threat Prevention YANG Data Tree 658 5.1. Threat Feed 660 This object represents a threat feed which provides the signatures of 661 malicious activities. Figure 15 shows the YANG tree of a Threat- 662 feed-list. The Threat-Feed object SHALL have the following 663 information: 665 Name: This field identifies the name of this object. 667 Description: This is the description of the threat feed. The 668 description should have the clear indication of the 669 security attack such as attack type (e.g., APT) and file 670 types used (e.g., executable malware). 672 Signatures: This field contains the threat signatures of malicious 673 programs or activities provided by the threat-feed. The 674 examples of signature types are "YARA", "SURICATA", and 675 "SNORT" [YARA][SURICATA][SNORT]. 677 It is assumed that the I2NSF User obtains the threat signatures 678 (i.e., threat content patterns) from a threat-feed server (i.e., feed 679 provider), which is a server providing threat signatures. With the 680 obtained threat signatures, the I2NSF User can deliver them to the 681 Security Controller. The retrieval of the threat signatures by the 682 I2NSF User is out of scope in this document. 684 +--rw threat-prevention 685 +--rw threat-feed-list* [name] 686 +--rw name string 687 +--rw description? string 688 +--rw signatures* identityref 690 Figure 15: Threat Feed YANG Data Tree 692 5.2. Payload Content 694 This object represents a custom list created for the purpose of 695 defining an exception to threat feeds. Figure 16 shows the YANG tree 696 of a Payload-content list. The Payload-Content object SHALL have the 697 following information: 699 Name: This field identifies the name of this object. For 700 example, the name "backdoor" indicates the payload content 701 is related to a backdoor attack. 703 Description: This represents the description of how the payload 704 content is related to a security attack. 706 Content: This contains the payload contents, which are involed in a 707 security attack, such as strings. 709 +--rw payload-content* [name] 710 +--rw name string 711 +--rw description string 712 +--rw content* binary 714 Figure 16: Payload Content in YANG Data Tree 716 6. Network Configuration Access Control Model (NACM) for I2NSF 717 Consumer-Facing Interface 719 Network Configuration Access Control Model (NACM) provides a user 720 group with an access control with the following features [RFC8341]: 722 * Independent control of action, data, and notification access is 723 provided. 725 * A simple and familiar set of datastore permissions is used. 727 * Support for YANG security tagging allows default security modes to 728 automatically exclude sensitive data. 730 * Separate default access modes for read, write, and execute 731 permissions are provided. 733 * Access control rules are applied to configurable groups of users. 735 The data model of the I2NSF Consumer-Facing Interface utilizes the 736 NACM's mechanisms to manage the access control on the I2NSF Consumer- 737 Facing Interface. The NACM with the above features can be used to 738 set up the access control rules of a user group in the I2NSF 739 Consumer-Facing Interface. 741 Figure 17 shows part of the NACM module to enable the access control 742 of a user group for the I2NSF Consumer-Facing Interface. To use the 743 NACM, a user needs to configure either a NETCONF server [RFC6241] or 744 a RESTCONF server [RFC8040] to enable the NACM module. Then, the 745 user can simply use an account of root or admin user for the access 746 control for the module of the I2NSF Consumer-Facing Interface (i.e., 747 ietf-i2nsf-cons-facing-interface). An XML example to configure the 748 access control a user group for the I2NSF Consumer-Facing Interface 749 can be seen in Section 9. 751 list rule { 752 key "name"; 753 ordered-by user; 754 leaf name { 755 type string { 756 length "1..max"; 757 } 758 description 759 "Arbitrary name assigned to the rule."; 760 } 762 leaf module-name { 763 type union { 764 type matchall-string-type; 765 type string; 766 } 767 default "*"; 768 description 769 "Name of the module associated with this rule." 770 } 772 leaf access-operations { 773 type union { 774 type matchall-string-type; 775 type access-operations-type; 776 } 777 default "*"; 778 description 779 "Access operations associated with this rule." 780 } 782 leaf action { 783 type action-type; 784 mandatory true; 785 description 786 "The access control action associated with the 787 rule. If a rule is determined to match a 788 particular request, then this object is used 789 to determine whether to permit or deny the 790 request."; 791 } 793 Figure 17: A Part of the NACM YANG Data Model 795 7. YANG Data Model of Consumer-Facing Interface 797 The main objective of this document is to provide the YANG data model 798 of I2NSF Consumer-Facing Interface. This interface can be used to 799 deliver control and management messages between an I2NSF User and 800 Security Controller for the I2NSF User's high-level security 801 policies. 803 The semantics of the data model must be aligned with the information 804 model of the Consumer-Facing Interface. The transformation of the 805 information model is performed so that this YANG data model can 806 facilitate the efficient delivery of the control or management 807 messages. 809 This data model is designed to support the I2NSF framework that can 810 be extended according to the security needs. In other words, the 811 model design is independent of the content and meaning of specific 812 policies as well as the implementation approach. 814 With the YANG data model of I2NSF Consumer-Facing Interface, this 815 document suggests use cases for security policy rules such as time- 816 based firewall, VoIP/VoCN security service, and DDoS-attack 817 mitigation in Section 8. 819 7.1. YANG Module of Consumer-Facing Interface 821 This section describes a YANG module of Consumer-Facing Interface. 822 This document provides identities in the data model to be used for 823 configuration of an NSF. Each identity is used for a different type 824 of configuration. The details are explained in the description of 825 each identity. This YANG module imports from [RFC6991]. It makes 826 references to [RFC0768] [RFC0792] [RFC0793] [RFC0854] [RFC0959] 827 [RFC1939] [RFC2595] [RFC3022] [RFC3261] [RFC3986] [RFC4250] [RFC4340] 828 [RFC4443] [RFC5321] [RFC5646] [RFC8335] [RFC8805] [RFC9051] 829 [Encyclopedia-Britannica] [IANA-ICMP-Parameters] 830 [IANA-ICMPv6-Parameters] [I-D.ietf-httpbis-http2bis] 831 [I-D.ietf-httpbis-messaging] [I-D.ietf-httpbis-semantics] 832 [I-D.ietf-i2nsf-capability-data-model] 833 [I-D.ietf-i2nsf-nsf-monitoring-data-model] [I-D.ietf-tcpm-rfc793bis] 834 [I-D.ietf-tsvwg-rfc4960-bis] [SNORT] [STIX] [SURICATA] [YARA]. 836 file "ietf-i2nsf-cons-facing-interface@2022-05-23.yang" 837 module ietf-i2nsf-cons-facing-interface { 838 yang-version 1.1; 839 namespace 840 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cons-facing-interface"; 841 prefix 842 i2nsfcfi; 844 import ietf-inet-types{ 845 prefix inet; 846 reference "RFC 6991"; 847 } 849 import ietf-yang-types{ 850 prefix yang; 851 reference "RFC 6991"; 852 } 854 organization 855 "IETF I2NSF (Interface to Network Security Functions) 856 Working Group"; 858 contact 859 "WG Web: 860 WG List: 862 Editor: Jaehoon Paul Jeong 863 865 Editor: Patrick Lingga 866 "; 868 description 869 "This module is a YANG module for Consumer-Facing Interface. 871 Copyright (c) 2022 IETF Trust and the persons identified as 872 authors of the code. All rights reserved. 874 Redistribution and use in source and binary forms, with or 875 without modification, is permitted pursuant to, and subject to 876 the license terms contained in, the Revised BSD License set 877 forth in Section 4.c of the IETF Trust's Legal Provisions 878 Relating to IETF Documents 879 (https://trustee.ietf.org/license-info). 881 This version of this YANG module is part of RFC XXXX 882 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 883 for full legal notices."; 885 // RFC Ed.: replace XXXX with an actual RFC number and remove 886 // this note. 888 revision "2022-05-23" { 889 description "Initial revision."; 890 reference 891 "RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model"; 893 // RFC Ed.: replace XXXX with an actual RFC number and remove 894 // this note. 895 } 897 identity resolution-strategy { 898 description 899 "Base identity for resolution strategy"; 900 reference 901 "draft-ietf-i2nsf-capability-data-model-31: 902 I2NSF Capability YANG Data Model - Resolution Strategy"; 903 } 905 identity fmr { 906 base resolution-strategy; 907 description 908 "Conflict resolution with First Matching Rule (FMR)."; 909 reference 910 "draft-ietf-i2nsf-capability-data-model-31: 911 I2NSF Capability YANG Data Model - Resolution Strategy"; 912 } 914 identity lmr { 915 base resolution-strategy; 916 description 917 "Conflict resolution with Last Matching Rule (LMR)"; 918 reference 919 "draft-ietf-i2nsf-capability-data-model-31: 920 I2NSF Capability YANG Data Model - Resolution Strategy"; 921 } 923 identity pmre { 924 base resolution-strategy; 925 description 926 "Conflict resolution with Prioritized Matching Rule with 927 Errors (PMRE)"; 928 reference 929 "draft-ietf-i2nsf-capability-data-model-31: 930 I2NSF Capability YANG Data Model - Resolution Strategy"; 931 } 933 identity pmrn { 934 base resolution-strategy; 935 description 936 "Conflict resolution with Prioritized Matching Rule with 937 No Errors (PMRN)"; 938 reference 939 "draft-ietf-i2nsf-capability-data-model-31: 940 I2NSF Capability YANG Data Model - Resolution Strategy"; 942 } 944 identity event { 945 description 946 "Base identity for policy events."; 947 reference 948 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 949 Monitoring Interface YANG Data Model - Event"; 950 } 952 identity system-event { 953 base event; 954 description 955 "Base Identity for system events. System event (also called 956 alert) is defined as a warning about any changes of 957 configuration, any access violation, the information of 958 sessions and traffic flows."; 959 reference 960 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 961 Monitoring Interface YANG Data Model - System event"; 962 } 964 identity system-alarm { 965 base event; 966 description 967 "Base identity for system alarms. System alarm is defined as a 968 warning related to service degradation in system hardware."; 969 reference 970 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 971 Monitoring Interface YANG Data Model - System alarm"; 972 } 974 identity access-violation { 975 base system-event; 976 description 977 "Access-violation system event is an event when a user tries 978 to access (read, write, create, or delete) any information or 979 execute commands above their privilege (i.e., not-conformant 980 with the access profile)."; 981 reference 982 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 983 Monitoring Interface YANG Data Model - System event for access 984 violation"; 985 } 987 identity configuration-change { 988 base system-event; 989 description 990 "The configuration-change system event is an event when a user 991 adds a new configuration or modify an existing configuration 992 (write configuration)."; 993 reference 994 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 995 Monitoring Interface YANG Data Model - System event for 996 configuration change"; 997 } 999 identity memory-alarm { 1000 base system-alarm; 1001 description 1002 "Memory is the hardware to store information temporarily or for 1003 a short period, i.e., Random Access Memory (RAM). A 1004 memory-alarm is emitted when the memory usage is exceeding 1005 the threshold."; 1006 reference 1007 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 1008 Monitoring Interface YANG Data Model - System alarm for 1009 memory"; 1010 } 1012 identity cpu-alarm { 1013 base system-alarm; 1014 description 1015 "CPU is the Central Processing Unit that executes basic 1016 operations of the system. A cpu-alarm is emitted when the CPU 1017 usage is exceeding a threshold."; 1018 reference 1019 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 1020 Monitoring Interface YANG Data Model - System alarm for CPU"; 1021 } 1023 identity disk-alarm { 1024 base system-alarm; 1025 description 1026 "Disk or storage is the hardware to store information for a 1027 long period, i.e., Hard Disk and Solid-State Drive. A 1028 disk-alarm is emitted when the disk usage is exceeding a 1029 threshold."; 1030 reference 1031 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 1032 Monitoring Interface YANG Data Model - System alarm for disk"; 1033 } 1035 identity hardware-alarm { 1036 base system-alarm; 1037 description 1038 "A hardware alarm is emitted when a hardware failure (e.g., 1039 CPU, memory, disk, or interface) is detected. A hardware 1040 failure is a malfunction within the electronic circuits or 1041 electromechanical components of the hardware that makes it 1042 unusable."; 1043 reference 1044 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 1045 Monitoring Interface YANG Data Model - System alarm for 1046 hardware"; 1047 } 1049 identity interface-alarm { 1050 base system-alarm; 1051 description 1052 "Interface is the network interface for connecting a device 1053 with the network. The interface-alarm is emitted when the 1054 state of the interface is changed."; 1055 reference 1056 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 1057 Monitoring Interface YANG Data Model - System alarm for 1058 interface"; 1059 } 1061 identity protocol { 1062 description 1063 "This identity represents the protocol types."; 1064 } 1066 identity transport-protocol { 1067 base protocol; 1068 description 1069 "Base identity for the Layer 4 (i.e., Transport Layer) 1070 Protocols"; 1071 } 1073 identity tcp { 1074 base transport-protocol; 1075 description 1076 "Base identity for TCP condition capabilities"; 1077 reference 1078 "RFC 793: Transmission Control Protocol 1079 draft-ietf-tcpm-rfc793bis-28: Transmission Control Protocol 1080 (TCP) Specification"; 1081 } 1083 identity udp { 1084 base transport-protocol; 1085 description 1086 "Base identity for UDP condition capabilities"; 1087 reference 1088 "RFC 768: User Datagram Protocol"; 1089 } 1091 identity sctp { 1092 base transport-protocol; 1093 description 1094 "Identity for SCTP condition capabilities"; 1095 reference 1096 "draft-ietf-tsvwg-rfc4960-bis-19: Stream Control Transmission 1097 Protocol"; 1098 } 1100 identity dccp { 1101 base transport-protocol; 1102 description 1103 "Identity for DCCP condition capabilities"; 1104 reference 1105 "RFC 4340: Datagram Congestion Control Protocol"; 1106 } 1108 identity application-protocol { 1109 description 1110 "Base identity for Application protocol. Note that a subset of 1111 application protocols (e.g., HTTP, HTTPS, FTP, POP3, and 1112 IMAP) are handled in this YANG module, rather than all 1113 the existing application protocols."; 1114 } 1116 identity http { 1117 base application-protocol; 1118 description 1119 "The identity for Hypertext Transfer Protocol version 1.1 1120 (HTTP/1.1)."; 1121 reference 1122 "draft-ietf-httpbis-semantics-19: HTTP Semantics 1123 draft-ietf-httpbis-messaging-19: HTTP/1.1"; 1124 } 1126 identity https { 1127 base application-protocol; 1128 description 1129 "The identity for Hypertext Transfer Protocol version 1.1 1130 (HTTP/1.1) over TLS."; 1131 reference 1132 "draft-ietf-httpbis-semantics-19: HTTP Semantics 1133 draft-ietf-httpbis-messaging-19: HTTP/1.1"; 1135 } 1137 identity http2 { 1138 base application-protocol; 1139 description 1140 "The identity for Hypertext Transfer Protocol version 2 1141 (HTTP/2)."; 1142 reference 1143 "draft-ietf-httpbis-http2bis-07: HTTP/2"; 1144 } 1146 identity https2 { 1147 base application-protocol; 1148 description 1149 "The identity for Hypertext Transfer Protocol version 2 1150 (HTTP/2) over TLS."; 1151 reference 1152 "draft-ietf-httpbis-http2bis-07: HTTP/2"; 1153 } 1155 identity ftp { 1156 base application-protocol; 1157 description 1158 "The identity for File Transfer Protocol."; 1159 reference 1160 "RFC 959: File Transfer Protocol (FTP)"; 1161 } 1163 identity ssh { 1164 base application-protocol; 1165 description 1166 "The identity for Secure Shell (SSH) protocol."; 1167 reference 1168 "RFC 4250: The Secure Shell (SSH) Protocol"; 1169 } 1171 identity telnet { 1172 base application-protocol; 1173 description 1174 "The identity for telnet."; 1175 reference 1176 "RFC 854: Telnet Protocol"; 1177 } 1179 identity smtp { 1180 base application-protocol; 1181 description 1182 "The identity for Simple Mail Transfer Protocol."; 1184 reference 1185 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1186 } 1188 identity pop3 { 1189 base application-protocol; 1190 description 1191 "The identity for Post Office Protocol 3 (POP3)."; 1192 reference 1193 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1194 } 1196 identity pop3s { 1197 base application-protocol; 1198 description 1199 "The identity for Post Office Protocol 3 (POP3) over TLS"; 1200 reference 1201 "RFC 1939: Post Office Protocol - Version 3 (POP3) 1202 RFC 2595: Using TLS with IMAP, POP3 and ACAP"; 1203 } 1205 identity imap { 1206 base application-protocol; 1207 description 1208 "The identity for Internet Message Access Protocol (IMAP)."; 1209 reference 1210 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 1211 4rev2"; 1212 } 1214 identity imaps { 1215 base application-protocol; 1216 description 1217 "The identity for Internet Message Access Protocol (IMAP) over 1218 TLS"; 1219 reference 1220 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 1221 4rev2"; 1222 } 1224 identity action { 1225 description 1226 "Base identity for action"; 1227 } 1229 identity primary-action { 1230 base action; 1231 description 1232 "Base identity for primary action. Primary action is an action 1233 that handle the forwarding of the packets or flows in an 1234 NSF."; 1235 } 1237 identity secondary-action { 1238 base action; 1239 description 1240 "Base identity for secondary action. Secondary action is an 1241 action in the background that does not affect the network, 1242 such as logging."; 1243 } 1245 identity ingress-action { 1246 base action; 1247 description 1248 "Base identity for ingress action. The action to handle the 1249 network traffic that is entering the secured network."; 1250 reference 1251 "draft-ietf-i2nsf-capability-data-model-31: 1252 I2NSF Capability YANG Data Model - Ingress Action"; 1253 } 1255 identity egress-action { 1256 base action; 1257 description 1258 "Base identity for egress action. The action to handle the 1259 network traffic that is exiting the secured network."; 1260 reference 1261 "draft-ietf-i2nsf-capability-data-model-31: 1262 I2NSF Capability YANG Data Model - Egress Action"; 1263 } 1265 identity pass { 1266 base ingress-action; 1267 base egress-action; 1268 description 1269 "The pass action allows traffic that matches 1270 the rule to proceed through the NSF to reach the 1271 destination."; 1272 reference 1273 "draft-ietf-i2nsf-capability-data-model-31: 1274 I2NSF Capability YANG Data Model - Actions and 1275 Default Action"; 1276 } 1278 identity drop { 1279 base ingress-action; 1280 base egress-action; 1281 description 1282 "The drop action denies the traffic that 1283 matches the rule. The drop action should do a silent drop, 1284 which does not give any response to the source."; 1285 reference 1286 "draft-ietf-i2nsf-capability-data-model-31: 1287 I2NSF Capability YANG Data Model - Actions and 1288 Default Action"; 1289 } 1291 identity reject { 1292 base ingress-action; 1293 base egress-action; 1294 description 1295 "The reject action denies a packet to go through the NSF 1296 entering or exiting the internal network and sends a response 1297 back to the source. The response depends on the packet and 1298 implementation. For example, a TCP packet is rejected with 1299 TCP RST response or a UDP packet may be rejected with an 1300 ICMPv4 response message with Type 3 Code 3 or ICMPv6 response 1301 message Type 1 Code 4 (i.e., Destination Unreachable: 1302 Destination port unreachable)."; 1303 } 1305 identity mirror { 1306 base ingress-action; 1307 base egress-action; 1308 description 1309 "The mirror action copies a packet and sends the packet's copy 1310 to the monitoring entity while still allowing the packet or 1311 flow to go through the NSF."; 1312 reference 1313 "draft-ietf-i2nsf-capability-data-model-31: 1314 I2NSF Capability YANG Data Model - Actions and 1315 Default Action"; 1316 } 1318 identity rate-limit { 1319 base ingress-action; 1320 base egress-action; 1321 description 1322 "The rate limit action limits the number of packets or flows 1323 that can go through the NSF by dropping packets or flows 1324 (randomly or systematically). The drop mechanism, e.g., silent 1325 drop and unreachable drop (i.e., reject), is up to the 1326 implementation"; 1327 reference 1328 "draft-ietf-i2nsf-capability-data-model-31: 1329 I2NSF Capability YANG Data Model - Actions and 1330 Default Action"; 1331 } 1333 identity invoke-signaling { 1334 base egress-action; 1335 description 1336 "The invoke-signaling action is used to convey information of 1337 the event triggering this action to a monitoring entity."; 1338 } 1340 identity tunnel-encapsulation { 1341 base egress-action; 1342 description 1343 "The tunnel encapsulation action is used to encapsulate the 1344 packet to be tunneled across the network to enable a secure 1345 connection."; 1346 } 1348 identity forwarding { 1349 base egress-action; 1350 description 1351 "The forwarding action is used to relay the packet from one 1352 network segment to another node in the network."; 1353 } 1355 identity transformation { 1356 base egress-action; 1357 description 1358 "The transformation action is used to transform a packet by 1359 modifying it (e.g., HTTP-to-CoAP packet translation). 1360 Note that a subset of transformation (e.g., HTTP-to-CoAP) is 1361 handled in this YANG module, rather than all the existing 1362 transformations. Specific algorithmic transformations can be 1363 executed by a middlebox (e.g., NSF) for a given transformation 1364 name."; 1365 reference 1366 "RFC 8075: Guidelines for Mapping Implementations: HTTP to the 1367 Constrained Application Protocol (CoAP) - Translation between 1368 HTTP and CoAP."; 1369 } 1371 identity log-action { 1372 base action; 1373 description 1374 "Base identity for log action"; 1375 } 1376 identity rule-log { 1377 base log-action; 1378 description 1379 "Log the policy rule that has been triggered by a packet or 1380 flow."; 1381 } 1383 identity session-log { 1384 base log-action; 1385 description 1386 "A session is a connection (i.e., traffic flow) of a data plane 1387 that includes source and destination information of IP 1388 addresses and transport port numbers with the protocol used. 1389 Log the session that triggered a policy rule."; 1390 } 1392 identity icmp-message { 1393 description 1394 "Base identity for ICMP Message types. Note that this YANG 1395 module only provide ICMP messages that is shared between 1396 ICMPv4 and ICMPv6 (e.g., Destination Unreachable: Port 1397 Unreachable which is ICMPv4 type 3 code 3 or ICMPv6 type 1 1398 code 4)."; 1399 reference 1400 "RFC 792: Internet Control Message Protocol 1401 RFC 8335: PROBE: A Utility for Probing Interfaces 1402 IANA: Internet Control Message Protocol (ICMP) 1403 Parameters 1404 IANA: Internet Control Message Protocol version 6 1405 (ICMPv6) Parameters"; 1406 } 1408 identity echo-reply { 1409 base icmp-message; 1410 description 1411 "Identity for 'Echo Reply' ICMP message type 0 in ICMPv4 or 1412 type 129 in ICMPv6"; 1413 } 1415 identity destination-unreachable { 1416 base icmp-message; 1417 description 1418 "Identity for 'Destination Unreachable' ICMP message type 3 in 1419 ICMPv4 or type 1 in ICMPv6"; 1420 } 1422 identity redirect { 1423 base icmp-message; 1424 description 1425 "Identity for 'Redirect' ICMP message type 5 in ICMPv4 1426 or type 137 in ICMPv6"; 1427 } 1429 identity echo { 1430 base icmp-message; 1431 description 1432 "Identity for 'Echo' ICMP message type 8 in ICMPv4 or type 128 1433 in ICMPv6"; 1434 } 1436 identity router-advertisement { 1437 base icmp-message; 1438 description 1439 "Identity for 'Router Advertisement' ICMP message type 9 in 1440 ICMPv4 or type 134 in ICMPv6"; 1441 } 1443 identity router-solicitation { 1444 base icmp-message; 1445 description 1446 "Identity for 'Router Solicitation' ICMP message type 10 in 1447 ICMPv4 or type 135 in ICMPv6"; 1448 } 1450 identity time-exceeded { 1451 base icmp-message; 1452 description 1453 "Identity for 'Time exceeded' ICMP message type 11 in ICMPv4 1454 or type 3 in ICMPv6"; 1455 } 1457 identity parameter-problem { 1458 base icmp-message; 1459 description 1460 "Identity for 'Parameter Problem' ICMP message type 12 in 1461 ICMPv4 or type 4 in ICMPv6"; 1462 } 1464 identity experimental-mobility-protocols { 1465 base icmp-message; 1466 description 1467 "Identity for 'Experimental Mobility Protocols' ICMP message 1468 type 41 in ICMPv4 or type 150 in ICMPv6"; 1469 } 1471 identity extended-echo-request { 1472 base icmp-message; 1473 description 1474 "Identity for 'Extended Echo Request' ICMP message type 42 1475 in ICMPv4 or type 160 in ICMPv6"; 1476 } 1478 identity extended-echo-reply { 1479 base icmp-message; 1480 description 1481 "Identity for 'Extended Echo Reply' ICMP message type 43 in 1482 ICMPv4 or type 161 in ICMPv6"; 1483 } 1485 identity port-unreachable { 1486 base destination-unreachable; 1487 description 1488 "Identity for port unreachable in destination unreachable 1489 message (i.e., ICMPv4 type 3 code 3 or ICMPv6 type 1 code 4)"; 1490 } 1492 identity request-no-error { 1493 base extended-echo-request; 1494 description 1495 "Identity for request with no error in extended echo request 1496 message (i.e., ICMPv4 type 42 code 0 or ICMPv6 type 160 1497 code 0)"; 1498 } 1500 identity reply-no-error { 1501 base extended-echo-reply; 1502 description 1503 "Identity for reply with no error in extended echo reply 1504 message (i.e., ICMPv4 type 43 code 0 or ICMPv6 type 161 1505 code 0)"; 1506 } 1508 identity malformed-query { 1509 base extended-echo-reply; 1510 description 1511 "Identity for malformed query in extended echo reply message 1512 (i.e., ICMPv4 type 43 code 1 or ICMPv6 type 161 code 1)"; 1513 } 1515 identity no-such-interface { 1516 base extended-echo-reply; 1517 description 1518 "Identity for no such interface in extended echo reply message 1519 (i.e., ICMPv4 type 43 code 2 or ICMPv6 type 161 code 2)"; 1521 } 1523 identity no-such-table-entry { 1524 base extended-echo-reply; 1525 description 1526 "Identity for no such table entry in extended echo reply 1527 message (i.e., ICMPv4 type 43 code 3 or ICMPv6 type 161 1528 code 3)"; 1529 } 1531 identity multiple-interfaces-satisfy-query { 1532 base extended-echo-reply; 1533 description 1534 "Identity for multiple interfaces satisfy query in extended 1535 echo reply message (i.e., ICMPv4 type 43 code 4 or ICMPv6 1536 type 161 code 4) "; 1537 reference 1538 "RFC 792: Internet Control Message Protocol 1539 RFC 8335: PROBE: A Utility for Probing Interfaces"; 1540 } 1542 identity signature-type { 1543 description 1544 "This represents the base identity for signature types."; 1545 } 1547 identity signature-yara { 1548 base signature-type; 1549 description 1550 "This represents the YARA signatures."; 1551 reference 1552 "YARA: YARA signatures are explained."; 1553 } 1555 identity signature-snort { 1556 base signature-type; 1557 description 1558 "This represents the SNORT signatures."; 1559 reference 1560 "SNORT: SNORT signatures are explained."; 1561 } 1563 identity signature-suricata { 1564 base signature-type; 1565 description 1566 "This represents the SURICATA signatures."; 1567 reference 1568 "SURICATA: SURICATA signatures are explained."; 1570 } 1572 identity threat-feed-type { 1573 description 1574 "This represents the base identity for threat-feed."; 1575 } 1577 identity continent { 1578 description 1579 "Base identity for continent types. The continents are based 1580 on Encyclopedia Britannica"; 1581 reference 1582 "Encyclopedia Britannica: Continent"; 1583 } 1585 identity africa { 1586 base continent; 1587 description 1588 "Identity for Africa."; 1589 reference 1590 "Encyclopedia Britannica: Continent"; 1591 } 1593 identity asia { 1594 base continent; 1595 description 1596 "Identity for Asia."; 1597 reference 1598 "Encyclopedia Britannica: Continent"; 1599 } 1601 identity antarctica { 1602 base continent; 1603 description 1604 "Identity for Antarctica."; 1605 reference 1606 "Encyclopedia Britannica: Continent"; 1607 } 1609 identity europe { 1610 base continent; 1611 description 1612 "Identity for Europe."; 1613 reference 1614 "Encyclopedia Britannica: Continent"; 1615 } 1617 identity north-america { 1618 base continent; 1619 description 1620 "Identity for North America."; 1621 reference 1622 "Encyclopedia Britannica: Continent"; 1623 } 1625 identity south-america { 1626 base continent; 1627 description 1628 "Identity for South America."; 1629 reference 1630 "Encyclopedia Britannica: Continent"; 1631 } 1633 identity australia { 1634 base continent; 1635 description 1636 "Identity for Australia"; 1637 reference 1638 "Encyclopedia Britannica: Continent"; 1639 } 1641 identity device-type { 1642 description 1643 "Base identity for types of device. This identity is used for 1644 type of the device for the source or destination of a packet 1645 or traffic flow. Note that the device type of either a source 1646 or destination can be known with the help of DHCP 1647 Fingerprinting and the interaction between an NSF and a DHCP 1648 server."; 1649 } 1651 identity computer { 1652 base device-type; 1653 description 1654 "Identity for computer such as personal computer (PC) 1655 and server."; 1656 } 1658 identity mobile-phone { 1659 base device-type; 1660 description 1661 "Identity for mobile-phone such as smartphone and 1662 cellphone"; 1663 } 1665 identity voip-vocn-phone { 1666 base device-type; 1667 description 1668 "Identity for VoIP (Voice over Internet Protocol) or VoCN 1669 (Voice over Cellular Network, such as Voice over LTE or 5G) 1670 phone"; 1671 } 1673 identity tablet { 1674 base device-type; 1675 description 1676 "Identity for tablet devices"; 1677 } 1679 identity network-infrastructure-device { 1680 base device-type; 1681 description 1682 "Identity for network infrastructure devices 1683 such as switch, router, and access point"; 1684 } 1686 identity iot-device { 1687 base device-type; 1688 description 1689 "Identity for Internet of Things (IoT) devices 1690 such as sensors, actuators, and low-power 1691 low-capacity computing devices"; 1692 } 1694 identity ot { 1695 base device-type; 1696 description 1697 "Identity for Operational Technology (OT) devices (also 1698 known as industrial control systems) that interact 1699 with the physical environment and detect or cause direct 1700 change through the monitoring and control of devices, 1701 processes, and events such as programmable logic 1702 controllers (PLCs), digital oscilloscopes, building 1703 management systems (BMS), and fire control systems"; 1704 } 1706 identity vehicle { 1707 base device-type; 1708 description 1709 "Identity for transportation vehicles that connect to and 1710 share data through the Internet over Vehicle-to-Everything 1711 (V2X) communications."; 1712 } 1714 /* 1715 * Typedefs 1716 */ 1718 typedef time { 1719 type string { 1720 pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' 1721 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 1722 } 1723 description 1724 "The time type represents an instance of time of zero-duration 1725 in the specified timezone that recurs every day."; 1726 } 1728 typedef day { 1729 type enumeration { 1730 enum monday { 1731 description 1732 "This represents Monday."; 1733 } 1734 enum tuesday { 1735 description 1736 "This represents Tuesday."; 1737 } 1738 enum wednesday { 1739 description 1740 "This represents Wednesday"; 1741 } 1742 enum thursday { 1743 description 1744 "This represents Thursday."; 1745 } 1746 enum friday { 1747 description 1748 "This represents Friday."; 1749 } 1750 enum saturday { 1751 description 1752 "This represents Saturday."; 1753 } 1754 enum sunday { 1755 description 1756 "This represents Sunday."; 1757 } 1758 } 1759 description 1760 "The type for representing the day of the week."; 1761 } 1763 /* 1764 * Groupings 1765 */ 1767 grouping ip-address-info { 1768 description 1769 "There are two types to configure a security policy 1770 for an IP address, such as IPv4 adress and IPv6 address."; 1771 choice match-type { 1772 description 1773 "User can choose between IPv4 and IPv6."; 1774 case range-match-ipv4 { 1775 container range-ipv4-address { 1776 leaf start-ipv4-address { 1777 type inet:ipv4-address-no-zone; 1778 mandatory true; 1779 description 1780 "A start IPv4 address for a range match."; 1781 } 1782 leaf end-ipv4-address { 1783 type inet:ipv4-address-no-zone; 1784 mandatory true; 1785 description 1786 "An end IPv4 address for a range match."; 1787 } 1788 description 1789 "A range match for IPv4 addresses is provided. 1790 Note that the start IPv4 address must be lower than 1791 the end IPv4 address."; 1792 } 1793 } 1794 case range-match-ipv6 { 1795 container range-ipv6-address { 1796 leaf start-ipv6-address { 1797 type inet:ipv6-address-no-zone; 1798 mandatory true; 1799 description 1800 "A start IPv6 address for a range match."; 1801 } 1802 leaf end-ipv6-address { 1803 type inet:ipv6-address-no-zone; 1804 mandatory true; 1805 description 1806 "An end IPv6 address for a range match."; 1807 } 1808 description 1809 "A range match for IPv6 addresses is provided. 1810 Note that the start IPv6 address must be lower than 1811 the end IPv6 address."; 1812 } 1813 } 1814 } 1815 } 1817 grouping user-group { 1818 description 1819 "This group represents user group information such as name and 1820 ip-address."; 1821 leaf name { 1822 type string; 1823 description 1824 "This represents the name of a user-group. A user-group name 1825 is used to map a user-group's name (e.g., employees) to IP 1826 address(es), MAC address(es). 1827 It is dependent on implementation."; 1828 } 1829 leaf-list mac-address { 1830 type yang:mac-address; 1831 description 1832 "Represent the MAC Address of a user-group. A user-group 1833 can have multiple MAC Addresses."; 1834 } 1835 uses ip-address-info{ 1836 description 1837 "This represents the IP addresses of a user-group."; 1838 refine match-type{ 1839 mandatory true; 1840 } 1841 } 1842 } 1844 grouping device-group { 1845 description 1846 "This group represents device group information such as 1847 ip-address protocol."; 1848 leaf name { 1849 type string; 1850 description 1851 "This represents the name of a device-group."; 1852 } 1853 uses ip-address-info{ 1854 refine match-type{ 1855 mandatory true; 1856 } 1857 } 1858 leaf-list application-protocol { 1859 type identityref { 1860 base application-protocol; 1861 } 1862 description 1863 "This represents the application layer protocols of devices. 1864 If this is not set, it cannot support the appropriate 1865 protocol"; 1866 } 1867 } 1869 grouping location-group { 1870 description 1871 "This group represents location-group information such as 1872 geo-ip and continent."; 1873 leaf name { 1874 type string; 1875 description 1876 "This represents the name of a location."; 1877 } 1878 list geo-ip-ipv4 { 1879 key "ipv4-address"; 1880 description 1881 "This represents the list of IPv4 addresses based on a 1882 location."; 1883 leaf ipv4-address{ 1884 type inet:ipv4-address-no-zone; 1885 description 1886 "This represents an IPv4 geo-ip address of a location."; 1887 } 1888 leaf ipv4-prefix{ 1889 type inet:ipv4-prefix; 1890 description 1891 "This represents the prefix for the IPv4 addresses."; 1892 } 1893 } 1894 list geo-ip-ipv6 { 1895 key "ipv6-address"; 1896 description 1897 "This represents the list of IPv6 addresses based on a 1898 location."; 1899 leaf ipv6-address{ 1900 type inet:ipv6-address-no-zone; 1901 description 1902 "This represents an IPv6 geo-ip address of a location."; 1903 } 1904 leaf ipv6-prefix{ 1905 type inet:ipv6-prefix; 1906 description 1907 "This represents the prefix for the IPv6 addresses."; 1908 } 1909 } 1910 leaf continent { 1911 type identityref { 1912 base continent; 1913 } 1914 default asia; 1915 description 1916 "location-group has geo-ip addresses of the corresponding 1917 continent."; 1918 } 1919 reference 1920 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1921 An access control for a geographical location (i.e., 1922 geolocation) that has the corresponding IP prefix."; 1923 } 1925 grouping payload-string { 1926 description 1927 "The grouping for payload-string content. It contains 1928 information such as name and string content."; 1929 } 1931 list i2nsf-cfi-policy { 1932 key "name"; 1933 description 1934 "This is a security policy list. Each policy in the list 1935 contains a list of security policy rules, and is a policy 1936 instance to have the information of where and when a policy 1937 needs to be applied."; 1938 leaf name { 1939 type string; 1940 description 1941 "The name which identifies the policy."; 1942 } 1943 leaf language { 1944 type string { 1945 pattern '(([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})' 1946 + '{0,2})?|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?' 1947 + '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}' 1948 + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za-wy-z]' 1949 + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]' 1950 + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|' 1951 + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-' 1952 + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-' 1953 + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-' 1954 + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]' 1955 + '|[Ii]-[Hh][Aa][Kk]|' 1956 + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|' 1957 + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|' 1958 + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|' 1959 + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|' 1960 + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|' 1961 + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-' 1962 + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-' 1963 + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-' 1964 + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|' 1965 + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-' 1966 + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|' 1967 + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-' 1968 + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-' 1969 + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))'; 1970 } 1971 default "en-US"; 1972 description 1973 "The value in this field indicates the language tag 1974 used for all of the 'leaf description' described in the 1975 'i2nsf-cfi-policy'. 1977 The attribute is encoded following the rules in Section 2.1 1978 in RFC 5646. The default language tag is 'en-US'"; 1979 reference 1980 "RFC 5646: Tags for Identifying Languages"; 1981 } 1982 leaf resolution-strategy { 1983 type identityref { 1984 base resolution-strategy; 1985 } 1986 default fmr; 1987 description 1988 "The resolution strategies that can be used to 1989 specify how to resolve conflicts that occur between 1990 actions of the same or different policy rules that 1991 are matched and contained in this particular NSF"; 1993 reference 1994 "draft-ietf-i2nsf-capability-data-model-31: 1995 I2NSF Capability YANG Data Model - Resolution strategy"; 1996 } 1997 list rules { 1998 key "name"; 2000 description 2001 "There can be a single or multiple number of rules."; 2002 leaf name { 2003 type string; 2004 description 2005 "This represents the name for a rule."; 2006 } 2008 leaf priority { 2009 type uint8 { 2010 range "1..255"; 2011 } 2012 description 2013 "The priority keyword comes with a mandatory 2014 numeric value which can range from 1 through 255. 2015 Note that a higher number means a higher priority"; 2016 } 2018 container event { 2019 description 2020 "This represents an event (i.e., a security event), for 2021 which a security rule is made."; 2022 leaf-list system-event { 2023 type identityref { 2024 base system-event; 2025 } 2026 description 2027 "The security policy rule according to 2028 system events."; 2029 } 2031 leaf-list system-alarm { 2032 type identityref { 2033 base system-alarm; 2034 } 2035 description 2036 "The security policy rule according to 2037 system alarms."; 2038 } 2039 } 2041 container condition { 2042 description 2043 "Conditions for general security policies."; 2044 container firewall { 2045 description 2046 "A general firewall condition based on the packet 2047 header."; 2048 leaf-list source { 2049 type union { 2050 type leafref { 2051 path "/i2nsf-cfi-policy/endpoint-groups/" 2052 + "user-group/name"; 2053 } 2054 type leafref { 2055 path "/i2nsf-cfi-policy/endpoint-groups/" 2056 + "device-group/name"; 2057 } 2058 } 2059 description 2060 "This describes the path of the source."; 2061 } 2063 leaf-list destination { 2064 type union { 2065 type leafref { 2066 path "/i2nsf-cfi-policy/endpoint-groups/" 2067 + "user-group/name"; 2068 } 2069 type leafref { 2070 path "/i2nsf-cfi-policy/endpoint-groups/" 2071 + "device-group/name"; 2072 } 2073 } 2074 description 2075 "This describes the path to the destinations."; 2076 } 2078 leaf transport-layer-protocol { 2079 type identityref { 2080 base transport-protocol; 2081 } 2082 description 2083 "The transport-layer protocol to be matched."; 2084 } 2086 container range-port-number { 2087 leaf start-port-number { 2088 type inet:port-number; 2089 description 2090 "A start port number for range match."; 2091 } 2092 leaf end-port-number { 2093 type inet:port-number; 2094 description 2095 "An end port number for range match."; 2096 } 2097 description 2098 "A range match for transport-layer port number. Note 2099 that the start port number value must be lower than 2100 the end port number value"; 2101 } 2103 container icmp { 2104 description 2105 "Represents the ICMPv4 and ICMPv6 packet header 2106 information to determine if the set of policy 2107 actions in this ECA policy rule should be executed 2108 or not."; 2109 reference 2110 "RFC 792: Internet Control Message Protocol 2111 RFC 8335: PROBE: A Utility for Probing Interfaces"; 2113 leaf-list message { 2114 type identityref { 2115 base icmp-message; 2116 } 2117 description 2118 "The security policy rule according to 2119 ICMP message. The type is representing the 2120 ICMP message corresponds to the ICMP type and 2121 code."; 2122 reference 2123 "RFC 792: Internet Control Message Protocol 2124 RFC 8335: PROBE: A Utility for Probing Interfaces 2125 IANA: Internet Control Message Protocol (ICMP) 2126 Parameters 2127 IANA: Internet Control Message Protocol version 6 2128 (ICMPv6) Parameters"; 2129 } 2130 } 2131 } 2133 container ddos { 2134 description 2135 "A condition for a DDoS attack."; 2136 container rate-limit { 2137 description 2138 "This describes the rate-limit."; 2139 leaf packet-rate-threshold { 2140 type uint64; 2141 description 2142 "This is a trigger value for a rate limit of packet 2143 rate for a DDoS-attack mitigation."; 2144 } 2145 leaf byte-rate-threshold { 2146 type uint64; 2147 description 2148 "This is a trigger value for a rate limit of byte 2149 rate for a DDoS-attack mitigation."; 2150 } 2151 leaf flow-rate-threshold { 2152 type uint64; 2153 description 2154 "This is a trigger value for a rate limit of flow 2155 rate for a DDoS-attack mitigation."; 2156 } 2157 } 2158 } 2160 container anti-virus { 2161 description 2162 "A condition for anti-virus"; 2164 leaf-list exception-files { 2165 type string; 2166 description 2167 "The type or name of the files to be excluded by the 2168 antivirus. This can be used to keep the known 2169 harmless files. 2170 If the value starts with a regular expression (e.g., 2171 '*.exe'), the antivirus should interpret it as a 2172 file pattern/type to be excluded. 2173 If the value does not start with a dot (e.g., 2174 'example.exe'), the antivirus should interpret it as 2175 a file name/path to be excluded."; 2176 } 2177 } 2179 container payload { 2180 description 2181 "A condition based on a packet's content."; 2182 leaf-list content { 2183 type leafref { 2184 path "/i2nsf-cfi-policy/threat-prevention/" 2185 + "payload-content/name"; 2186 } 2187 description 2188 "This describes the paths to a packet content's"; 2189 } 2190 } 2192 container url-category { 2193 description 2194 "Condition for url category"; 2196 leaf url-name { 2197 type leafref { 2198 path "/i2nsf-cfi-policy/endpoint-groups/" 2199 + "url-group/name"; 2200 } 2201 description 2202 "This is description for the condition of a URL's 2203 category such as SNS sites, game sites, ecommerce 2204 sites, company sites, and university sites."; 2205 } 2206 } 2208 container voice { 2209 description 2210 "For the VoIP/VoCN security system, a VoIP/ 2211 VoCN security system can monitor each 2212 VoIP/VoCN flow and manage VoIP/VoCN 2213 security rules controlled by a centralized 2214 server for VoIP/VoCN security service 2215 (called VoIP IPS). The VoIP/VoCN security 2216 system controls each switch for the 2217 VoIP/VoCN call flow management by 2218 manipulating the rules that can be added, 2219 deleted, or modified dynamically. 2220 Note that VoIP is Voice over Internet Protocol 2221 and VoCN is Voice over Cellular Network such as 2222 Voice over LTE or 5G"; 2223 reference 2224 "RFC 3261: SIP: Session Initiation Protocol"; 2226 leaf-list source-id { 2227 type string; 2228 description 2229 "The security policy rule according to 2230 a source voice ID for VoIP and VoCN."; 2231 } 2233 leaf-list destination-id { 2234 type string; 2235 description 2236 "The security policy rule according to 2237 a destination voice ID for VoIP and VoCN."; 2238 } 2240 leaf-list user-agent { 2241 type string; 2242 description 2243 "The security policy rule according to 2244 an user agent for VoIP and VoCN."; 2245 } 2246 } 2248 container context { 2249 description 2250 "Condition for matching the context of the packet, such 2251 as geographic location, time, packet direction"; 2252 container time { 2253 description 2254 "The time when a security policy rule should be 2255 applied."; 2256 leaf start-date-time { 2257 type yang:date-and-time; 2258 description 2259 "This is the start date and time for a security 2260 policy rule."; 2261 } 2262 leaf end-date-time { 2263 type yang:date-and-time; 2264 description 2265 "This is the end date and time for a security policy 2266 rule. The policy rule will stop working after the 2267 specified end date and time."; 2268 } 2269 container period { 2270 when 2271 "../frequency!='only-once'"; 2272 description 2273 "This represents the repetition time. In the case 2274 where the frequency is weekly, the days can be 2275 set."; 2276 leaf start-time { 2277 type time; 2278 description 2279 "This is a period's start time for an event."; 2280 } 2281 leaf end-time { 2282 type time; 2283 description 2284 "This is a period's end time for an event."; 2285 } 2286 leaf-list day { 2287 when 2288 "../../frequency='weekly'"; 2289 type day; 2290 min-elements 1; 2291 description 2292 "This represents the repeated day of every week 2293 (e.g., Monday and Tuesday). More than one day can 2294 be specified."; 2295 } 2296 leaf-list date { 2297 when 2298 "../../frequency='monthly'"; 2299 type int8 { 2300 range "1..31"; 2301 } 2302 min-elements 1; 2303 description 2304 "This represents the repeated date of every month. 2305 More than one date can be specified."; 2306 } 2307 leaf-list month { 2308 when 2309 "../../frequency='yearly'"; 2310 type string{ 2311 pattern '\d{2}-\d{2}'; 2312 } 2313 min-elements 1; 2314 description 2315 "This represents the repeated date and month of 2316 every year. More than one can be specified. 2317 A pattern used here is Month and Date (MM-DD)."; 2318 } 2319 } 2321 leaf frequency { 2322 type enumeration { 2323 enum only-once { 2324 description 2325 "This represents that the rule is immediately 2326 enforced only once and not repeated. The policy 2327 will continuously be active from the 2328 start-date-time to the end-date-time."; 2329 } 2330 enum daily { 2331 description 2332 "This represents that the rule is enforced on a 2333 daily basis. The policy will be repeated daily 2334 until the end-date-time."; 2335 } 2336 enum weekly { 2337 description 2338 "This represents that the rule is enforced on a 2339 weekly basis. The policy will be repeated weekly 2340 until the end-date-time. The repeated days can 2341 be specified."; 2342 } 2343 enum monthly { 2344 description 2345 "This represents that the rule is enforced on a 2346 monthly basis. The policy will be repeated 2347 monthly until the end-date-time."; 2348 } 2349 enum yearly { 2350 description 2351 "This represents that the rule is enforced on a 2352 yearly basis. The policy will be repeated 2353 yearly until the end-date-time."; 2354 } 2355 } 2356 default only-once; 2357 description 2358 "This represents how frequently the rule should be 2359 enforced."; 2360 } 2361 } 2363 container application { 2364 description 2365 "Condition for application"; 2366 leaf-list protocol { 2367 type identityref { 2368 base application-protocol; 2369 } 2370 description 2371 "The condition based on the application layer 2372 protocol"; 2373 } 2374 } 2376 container device-type { 2377 description 2378 "Condition for type of the destination device"; 2379 leaf-list device { 2380 type identityref { 2381 base device-type; 2382 } 2383 description 2384 "The device attribute that can identify a device, 2385 including the device type (i.e., router, switch, 2386 pc, ios, or android) and the device's owner as 2387 well."; 2389 } 2390 } 2392 container users { 2393 description 2394 "Condition for users"; 2395 list user { 2396 key "id"; 2397 description 2398 "The user with which the traffic flow is associated 2399 can be identified by either a user ID or username. 2400 The user-to-IP address mapping is assumed to be 2401 provided by the unified user management system via 2402 network."; 2403 leaf id { 2404 type uint32; 2405 description 2406 "The ID of the user."; 2407 } 2408 leaf name { 2409 type string; 2410 description 2411 "The name of the user."; 2412 } 2413 } 2414 list group { 2415 key "id"; 2416 description 2417 "The user group with which the traffic flow is 2418 associated can be identified by either a group ID 2419 or group name. The group-to-IP address and 2420 user-to-group mappings are assumed to be provided by 2421 the unified user management system via network."; 2422 leaf id { 2423 type uint32; 2424 description 2425 "The ID of the group."; 2426 } 2427 leaf name { 2428 type string; 2429 description 2430 "The name of the group."; 2431 } 2432 } 2433 } 2435 container geographic-location { 2436 description 2437 "A condition for a location-based connection"; 2438 leaf-list source { 2439 type leafref { 2440 path "/i2nsf-cfi-policy/endpoint-groups/" 2441 + "location-group/name"; 2442 } 2443 description 2444 "This describes the paths to a location's sources."; 2445 } 2446 leaf-list destination { 2447 type leafref { 2448 path "/i2nsf-cfi-policy/endpoint-groups/" 2449 + "location-group/name"; 2450 } 2451 description 2452 "This describes the paths to a location's 2453 destinations."; 2454 } 2455 } 2456 } 2458 container threat-feed { 2459 description 2460 "A condition based on the threat-feed information."; 2461 leaf-list name { 2462 type leafref { 2463 path "/i2nsf-cfi-policy/threat-prevention/" 2464 + "threat-feed-list/name"; 2465 } 2466 description 2467 "This describes the paths to a threat-feed's sources."; 2468 } 2469 } 2470 } 2472 container action { 2473 description 2474 "This is the action container."; 2475 container primary-action { 2476 description 2477 "This represents primary actions (e.g., ingress and 2478 egress actions) to be applied to a condition. 2479 If this is not set, it cannot support the primary 2480 actions."; 2481 leaf action { 2482 type identityref { 2483 base primary-action; 2484 } 2485 description 2486 "Ingress actions: pass, drop, reject, rate-limit, 2487 and mirror. 2488 Egress actions: pass, drop, reject, rate-limit, 2489 mirror, invoke-signaling, tunnel-encapsulation, 2490 forwarding, and transformation.."; 2491 } 2492 } 2493 container secondary-action { 2494 description 2495 "This represents secondary actions (e.g., log and syslog) 2496 to be applied if they are needed. If this is not set, 2497 it cannot support the secondary actions."; 2498 leaf log-action { 2499 type identityref { 2500 base secondary-action; 2501 } 2502 description 2503 "Log action: rule log and session log"; 2504 } 2505 } 2506 } 2507 } 2509 container endpoint-groups { 2510 description 2511 "A logical entity in a business environment, where a security 2512 policy is to be applied."; 2513 list user-group{ 2514 uses user-group; 2515 key "name"; 2516 description 2517 "This represents a user group."; 2518 } 2519 list device-group { 2520 key "name"; 2521 uses device-group; 2522 description 2523 "This represents a device group."; 2524 } 2525 list location-group{ 2526 key "name"; 2527 uses location-group; 2528 description 2529 "This represents a location group."; 2530 } 2531 list url-group { 2532 key "name"; 2533 description 2534 "This describes the list of URL."; 2535 leaf name { 2536 type string; 2537 description 2538 "This is the name of URL group, e.g., SNS sites, 2539 gaming sites, ecommerce sites"; 2540 } 2541 leaf-list url { 2542 type string; 2543 description 2544 "Specifies the URL to be added into the group."; 2545 reference 2546 "RFC 3986: Uniform Resource Identifier (URI): Generic 2547 Syntax"; 2548 } 2549 } 2550 } 2552 container threat-prevention { 2553 description 2554 "The container for threat-prevention."; 2555 list threat-feed-list { 2556 key "name"; 2557 description 2558 "There can be a single or multiple number of 2559 threat-feeds."; 2560 leaf name { 2561 type string; 2562 description 2563 "This represents the name of the threat-feed."; 2564 } 2565 leaf description { 2566 type string; 2567 description 2568 "This represents the descriptions of a threat-feed. The 2569 description should include information, such as type, 2570 threat, method, and file type. Structured Threat 2571 Information Expression (STIX) can be used for 2572 description of a threat [STIX]."; 2573 } 2574 leaf-list signatures { 2575 type identityref { 2576 base signature-type; 2577 } 2578 description 2579 "This contains a list of signatures or hashes of the 2580 threats."; 2582 } 2583 } 2584 list payload-content { 2585 key "name"; 2586 leaf name { 2587 type string; 2588 description 2589 "This represents the name of a packet's payload-content. 2590 It should give an idea of why a specific payload content 2591 is marked as a threat. For example, the name 'backdoor' 2592 indicates the payload content is related to a backdoor 2593 attack."; 2594 } 2595 leaf description { 2596 type string; 2597 description 2598 "This represents the description of a payload. Desecribe 2599 how the payload content is related to a security 2600 attack."; 2601 } 2602 leaf-list content { 2603 type binary; 2604 description 2605 "This represents the string of the payload contents. 2606 This content leaf-list contains the payload of a packet 2607 to analyze a threat. Due to the types of threats, the 2608 type of the content is defined as a binary to 2609 accommodate any kind of a payload type such as HTTP, 2610 HTTPS, and SIP."; 2611 } 2612 description 2613 "This represents a payload-string group."; 2614 } 2615 } 2616 } 2617 } 2618 2620 Figure 18: YANG for Consumer-Facing Interface 2622 8. XML Configuration Examples of High-Level Security Policy Rules 2624 This section shows XML configuration examples of high-level security 2625 policy rules that are delivered from the I2NSF User to the Security 2626 Controller over the Consumer-Facing Interface. The considered use 2627 cases are: Database registration, time-based firewall for web 2628 filtering, VoIP/VoCN security service, and DDoS-attack mitigation. 2630 8.1. Database Registration: Information of Positions and Devices 2631 (Endpoint Group) 2633 If new endpoints are introduced to the network, it is necessary to 2634 first register their data to the database. For example, if new 2635 members are newly introduced in either of three different groups 2636 (i.e., user-group, device-group, and url-group), each of them should 2637 be registered with information such as ip-addresses or protocols used 2638 by devices. 2640 Figure 19 shows an example XML representation of the registered 2641 information for the user-group and device-group with IPv4 addresses 2642 [RFC5737]. 2644 2645 2647 security_policy_for_blocking_sns 2648 2649 2650 employees 2651 2652 192.0.2.11 2653 192.0.2.90 2654 2655 2656 2657 webservers 2658 2659 198.51.100.11 2660 198.51.100.20 2661 2662 http 2663 https 2664 2665 2666 sns-websites 2667 example1.com 2668 example2.com 2669 2670 2671 2673 Figure 19: Registering User-group and Device-group Information 2674 with IPv4 Addresses 2676 Also, Figure 20 shows an example XML representation of the registered 2677 information for the user-group and device-group with IPv6 addresses 2678 [RFC3849]. 2680 2681 2683 security_policy_for_blocking_sns 2684 2685 2686 employees 2687 2688 2001:db8:0:1::11 2689 2001:db8:0:1::90 2690 2691 2692 2693 webservers 2694 2695 2001:db8:0:2::11 2696 2001:db8:0:2::20 2697 2698 http 2699 https 2700 2701 2702 sns-websites 2703 SNS_1 2704 SNS_2 2705 2706 2707 2709 Figure 20: Registering User-group and Device-group Information 2710 with IPv6 Addresses 2712 8.2. Scenario 1: Block SNS Access during Business Hours 2714 The first example scenario is to "block SNS access during office 2715 hours" using a time-based firewall policy. In this scenario, all 2716 users registered as "employees" in the user-group list are unable to 2717 access Social Networking Services (SNS) during the office hours 2718 (weekdays). The XML instance is described below: 2720 2721 2723 security_policy_for_blocking_sns 2724 2725 block_access_to_sns_during_office_hours 2726 2727 2728 employees 2729 2730 2731 sns-websites 2732 2733 2734 2748 2749 2750 2751 2752 drop 2753 2754 2755 2756 2758 Figure 21: An XML Example for Time-based Firewall 2760 Time-based-condition Firewall 2762 1. The policy name is "security_policy_for_blocking_sns". 2764 2. The rule name is "block_access_to_sns_during_office_hours". 2766 3. The Source is "employees". 2768 4. The destination target is "sns-websites". "sns-websites" is the 2769 key which represents the list containing the information, such as 2770 URL, about sns-websites. 2772 5. The action required is to "drop" any attempt to connect to 2773 websites related to Social networking. 2775 8.3. Scenario 2: Block Malicious VoIP/VoCN Packets Coming to a Company 2777 The second example scenario is to "block malicious VoIP/VoCN packets 2778 coming to a company" using a VoIP policy. In this scenario, the 2779 calls comming from from VOIP and/or VoCN sources with VoCN IDs that 2780 are classified as malicious are dropped. The IP addresses of the 2781 employees and malicious VOIP IDs should be blocked are stored in the 2782 database or datastore of the enterprise. Here and the rest of the 2783 cases assume that the security administrators or someone responsible 2784 for the existing and newly generated policies, are not aware of which 2785 and/or how many NSFs are needed to meet the security requirements. 2786 Figure 22 represents the XML document generated from YANG discussed 2787 in previous sections. Once a high-level seucurity policy is created 2788 by a security admin, it is delivered by the Consumer-Facing 2789 Interface, through RESTCONF server, to the security controller. The 2790 XML instance is described below: 2792 2793 2795 2796 security_policy_for_blocking_malicious_voip_packets 2797 2798 2799 Block_malicious_voip_and_vocn_packets 2800 2801 2802 malicious-id 2803 2804 2805 employees 2806 2807 2808 2809 2810 drop 2811 2812 2813 2814 2815 Figure 22: An XML Example for VoIP Security Service 2817 Custom-condition Firewall 2819 1. The policy name is 2820 "security_policy_for_blocking_malicious_voip_packets". 2822 2. The rule name is "Block_malicious_voip_and_vocn_packets". 2824 3. The Source is "malicious-id". This can be a single ID or a list 2825 of IDs, depending on how the ID are stored in the database. The 2826 "malicious-id" is the key so that the security admin can read 2827 every stored malicious VOIP IDs that are named as "malicious-id". 2829 4. The destination target is "employees". "employees" is the key 2830 which represents the list containing information about employees, 2831 such as IP addresses. 2833 5. The action required is "drop" when any incoming packets are from 2834 "malicious-id". 2836 8.4. Scenario 3: Mitigate Flood Attacks on a Company Web Server 2838 The third example scenario is to "Mitigate flood attacks on a company 2839 web server" using a DDoS-attack mitigation policy. Here, the time 2840 information is not set because the service provided by the network 2841 should be maintained at all times. If the packets sent by any 2842 sources are more than the set threshold, then the admin can set the 2843 percentage of the packets to be dropped to safely maintain the 2844 service. In this scenario, the source is set as "any" to block any 2845 sources which send abnormal amount of packets. The destination is 2846 set as "web_server01". Once the rule is set and delivered and 2847 enforced to the nsfs by the securiy controller, the NSFs will monitor 2848 the incoming packet amounts and the destination to act according to 2849 the rule set. The XML instance is described below: 2851 2852 2854 security_policy_for_ddos_attacks 2855 2856 1000_packets_per_second 2857 2858 2859 2860 1000 2861 2862 2863 2864 2865 2866 drop 2867 2868 2869 2870 2872 Figure 23: An XML Example for DDoS-attack Mitigation 2874 DDoS-condition Firewall 2876 1. The policy name is "security_policy_for_ddos_attacks". 2878 2. The rule name is "1000_packets_per_second". 2880 3. The rate limit exists to limit the incoming amount of packets per 2881 second. In this case the rate limit is "1000" packets per 2882 second. This amount depends on the packet receiving capacity of 2883 the server devices. 2885 4. The Source is all sources which send abnormal amount of packets. 2887 5. The action required is to "drop" packet reception is more than 2888 1000 packets per second. 2890 9. XML Configuration Example of a User Group's Access Control for I2NSF 2891 Consumer-Facing Interface 2893 This is an example for creating privileges for a group of users 2894 (i.e., a user group) to access and use the I2NSF Consumer-Facing 2895 Interface to create security policies via the interface. For the 2896 access control of the Consumer-Facing Interface, the NACM module can 2897 be used. Figure 24 shows an XML example the access control of a user 2898 group (named Example-Group) for I2NSF Consumer-Facing Interface A 2899 group called Example-Group can be created and configured with NACM 2900 for the Consumer-Facing Interface. For Example-Group, a rule list 2901 can created with the name of Example-Group-Rules. Example-Group- 2902 Rules has two rules of Example-Group-Rule1 and Example-Group-Rule2 as 2903 follows. For Example-Group-Rule1, the privilege of "Read" is allowed 2904 to Example-Group for the Consumer-Facing Interface. On the other 2905 hand, for Example-Group-Rule2, the privileges of "Create", "Update", 2906 and "Delete" are denied against Example-Group for the Consumer-Facing 2907 Interface. 2909 2910 2911 true 2912 2913 2914 Example-Group 2915 Alice 2916 Bob 2917 Eve 2918 2919 2920 2921 Example-Group-Rules 2922 Example-Group 2923 2924 Example-Group-Rule1 2925 read 2926 ietf-i2nsf-cons-facing-interface 2927 permit 2928 2929 2930 Example-Group-Rule2 2931 create update delete 2932 ietf-i2nsf-cons-facing-interface 2933 deny 2934 2935 2936 2937 Figure 24: An XML Example of a User Group's Access Control for 2938 I2NSF Consumer- Facing Interface 2940 The access control for the I2NSF Consumer-Facing Interface is as 2941 follows. 2943 1. The NACM is enabled. 2945 2. As a group name, Example-Group is specified. 2947 3. As members of the group, Alice, Bob, and Eve are specified. 2949 4. As a rule list name, Example-Group-Rules is specified for 2950 managing privileges of Example-Group's members. 2952 5. As the first rule name, Example-Group-Rule1 is specified. This 2953 rule is used to give read privilege to Example-Group's members 2954 for the module of the I2NSF Consumer-Facing Interface. 2956 6. As the second rule name, Example-Group-Rule2 is specified. This 2957 rule is used to deny create, update, and delete privileges 2958 against Example-Group's members for the module of the I2NSF 2959 Consumer-Facing Interface. 2961 10. IANA Considerations 2963 This document requests IANA to register the following URI in the 2964 "IETF XML Registry" [RFC3688]: 2966 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cons-facing-interface 2967 Registrant Contact: The IESG. 2968 XML: N/A; the requested URI is an XML namespace. 2970 This document requests IANA to register the following YANG module in 2971 the "YANG Module Names" registry [RFC7950][RFC8525]: 2973 name: ietf-i2nsf-cons-facing-interface 2974 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cons-facing-interface 2975 prefix: i2nsfcfi 2976 reference: RFC XXXX 2978 // RFC Ed.: replace XXXX with an actual RFC number and remove 2979 // this note. 2981 11. Security Considerations 2983 The YANG module specified in this document defines a data schema 2984 designed to be accessed through network management protocols such as 2985 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 2986 the secure transport layer, and the required secure transport is 2987 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 2988 and the required secure transport is TLS [RFC8446]. 2990 The Network Configuration Access Control Model (NACM) [RFC8341] 2991 provides a means of restricting access to specific NETCONF or 2992 RESTCONF users to a preconfigured subset of all available NETCONF or 2993 RESTCONF protocol operations and contents. Thus, NACM SHOULD be used 2994 to restrict the NSF registration from unauthorized users. 2996 There are a number of data nodes defined in this YANG module that are 2997 writable, creatable, and deletable (i.e., config true, which is the 2998 default). These data nodes may be considered sensitive or vulnerable 2999 in some network environments. Write operations to these data nodes 3000 could have a negative effect on network and security operations. 3001 These data nodes are collected into a single list node with the 3002 following sensitivity/vulnerability: 3004 * list i2nsf-cfi-policy: Writing to almost any element of this YANG 3005 module would directly impact on the configuration of NSFs, e.g., 3006 completely turning off security monitoring and mitigation 3007 capabilities; altering the scope of this monitoring and 3008 mitigation; creating an overwhelming logging volume to overwhelm 3009 downstream analytics or storage capacity; creating logging 3010 patterns which are confusing; or rendering useless trained 3011 statistics or artificial intelligence models. 3013 Some of the readable data nodes in this YANG module may be considered 3014 sensitive or vulnerable in some network environments. It is thus 3015 important to control read access (e.g., via get, get-config, or 3016 notification) to these data nodes. These are the subtrees and data 3017 nodes with their sensitivity/vulnerability: 3019 * list i2nsf-cfi-policy: The leak of this node to an attacker could 3020 reveal the specific configuration of security controls to an 3021 attacker. An attacker can craft an attack path that avoids 3022 observation or mitigations; one may reveal topology information to 3023 inform additional targets or enable lateral movement; one enables 3024 the construction of an attack path that avoids observation or 3025 mitigations; one provides an indication that the operator has 3026 discovered the attack. This node also holds a list of endpoint 3027 data that is considered private to the users. 3029 12. References 3031 12.1. Normative References 3033 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3034 DOI 10.17487/RFC0768, August 1980, 3035 . 3037 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3038 RFC 792, DOI 10.17487/RFC0792, September 1981, 3039 . 3041 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 3042 RFC 793, DOI 10.17487/RFC0793, September 1981, 3043 . 3045 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 3046 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 3047 1983, . 3049 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 3050 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 3051 . 3053 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 3054 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 3055 . 3057 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3058 Requirement Levels", BCP 14, RFC 2119, 3059 DOI 10.17487/RFC2119, March 1997, 3060 . 3062 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 3063 RFC 2595, DOI 10.17487/RFC2595, June 1999, 3064 . 3066 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3067 A., Peterson, J., Sparks, R., Handley, M., and E. 3068 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3069 DOI 10.17487/RFC3261, June 2002, 3070 . 3072 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3073 DOI 10.17487/RFC3688, January 2004, 3074 . 3076 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3077 Resource Identifier (URI): Generic Syntax", STD 66, 3078 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3079 . 3081 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 3082 Protocol Assigned Numbers", RFC 4250, 3083 DOI 10.17487/RFC4250, January 2006, 3084 . 3086 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3087 Congestion Control Protocol (DCCP)", RFC 4340, 3088 DOI 10.17487/RFC4340, March 2006, 3089 . 3091 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3092 Control Message Protocol (ICMPv6) for the Internet 3093 Protocol Version 6 (IPv6) Specification", STD 89, 3094 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3095 . 3097 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3098 DOI 10.17487/RFC5321, October 2008, 3099 . 3101 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 3102 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 3103 September 2009, . 3105 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3106 and A. Bierman, Ed., "Network Configuration Protocol 3107 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3108 . 3110 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3111 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 3112 . 3114 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3115 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3116 . 3118 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3119 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3120 . 3122 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3123 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3124 . 3126 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3127 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3128 May 2017, . 3130 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 3131 Kumar, "Framework for Interface to Network Security 3132 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 3133 . 3135 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 3136 Boucadair, "PROBE: A Utility for Probing Interfaces", 3137 RFC 8335, DOI 10.17487/RFC8335, February 2018, 3138 . 3140 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3141 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3142 . 3144 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 3145 Access Control Model", STD 91, RFC 8341, 3146 DOI 10.17487/RFC8341, March 2018, 3147 . 3149 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 3150 and R. Wilton, "Network Management Datastore Architecture 3151 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 3152 . 3154 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 3155 Documents Containing YANG Data Models", BCP 216, RFC 8407, 3156 DOI 10.17487/RFC8407, October 2018, 3157 . 3159 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3160 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3161 . 3163 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 3164 and R. Wilton, "YANG Library", RFC 8525, 3165 DOI 10.17487/RFC8525, March 2019, 3166 . 3168 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 3169 Kumari, "A Format for Self-Published IP Geolocation 3170 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 3171 . 3173 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message 3174 Access Protocol (IMAP) - Version 4rev2", RFC 9051, 3175 DOI 10.17487/RFC9051, August 2021, 3176 . 3178 [I-D.ietf-httpbis-http2bis] 3179 Thomson, M. and C. Benfield, "HTTP/2", Work in Progress, 3180 Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January 3181 2022, . 3184 [I-D.ietf-httpbis-messaging] 3185 Fielding, R. T., Nottingham, M., and J. Reschke, 3186 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 3187 httpbis-messaging-19, 12 September 2021, 3188 . 3191 [I-D.ietf-httpbis-semantics] 3192 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 3193 Semantics", Work in Progress, Internet-Draft, draft-ietf- 3194 httpbis-semantics-19, 12 September 2021, 3195 . 3198 [I-D.ietf-i2nsf-capability-data-model] 3199 Hares, S., Jeong, J. P., Kim, J. T., Moskowitz, R., and Q. 3200 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 3201 Internet-Draft, draft-ietf-i2nsf-capability-data-model-31, 3202 14 May 2022, . 3205 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 3206 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 3207 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 3208 Model", Work in Progress, Internet-Draft, draft-ietf- 3209 i2nsf-nsf-monitoring-data-model-18, 19 April 2022, 3210 . 3213 [I-D.ietf-tcpm-rfc793bis] 3214 Eddy, W. M., "Transmission Control Protocol (TCP) 3215 Specification", Work in Progress, Internet-Draft, draft- 3216 ietf-tcpm-rfc793bis-28, 7 March 2022, 3217 . 3220 [I-D.ietf-tsvwg-rfc4960-bis] 3221 Stewart, R. R., Tüxen, M., and K. E. E. Nielsen, "Stream 3222 Control Transmission Protocol", Work in Progress, 3223 Internet-Draft, draft-ietf-tsvwg-rfc4960-bis-19, 5 3224 February 2022, . 3227 12.2. Informative References 3229 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 3230 Address Translator (Traditional NAT)", RFC 3022, 3231 DOI 10.17487/RFC3022, January 2001, 3232 . 3234 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 3235 Information Models and Data Models", RFC 3444, 3236 DOI 10.17487/RFC3444, January 2003, 3237 . 3239 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 3240 Reserved for Documentation", RFC 3849, 3241 DOI 10.17487/RFC3849, July 2004, 3242 . 3244 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 3245 Reserved for Documentation", RFC 5737, 3246 DOI 10.17487/RFC5737, January 2010, 3247 . 3249 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 3250 Multiplexed and Secure Transport", RFC 9000, 3251 DOI 10.17487/RFC9000, May 2021, 3252 . 3254 [IANA-ICMP-Parameters] 3255 Internet Assigned Numbers Authority (IANA), "Assigned 3256 Internet Protocol Numbers", February 2021, 3257 . 3260 [IANA-ICMPv6-Parameters] 3261 Internet Assigned Numbers Authority (IANA), "Internet 3262 Control Message Procotol version 6 (ICMPv6) Parameters", 3263 February 2021, . 3266 [Encyclopedia-Britannica] 3267 Britannica, "Continent", September 2020, 3268 . 3270 [YARA] Alvarez, V., Bengen, H., Metz, J., Buehlmann, S., and W. 3271 Shields, "YARA", YARA 3272 Documents https://yara.readthedocs.io/en/v3.5.0/, August 3273 2020. 3275 [SURICATA] Julien, V. and ., "SURICATA", SURICATA Documents 3276 https://suricata-ids.org/docs/, August 2020. 3278 [SNORT] Roesch, M., Green, C., and B. Caswell, "SNORT", SNORT 3279 Documents https://www.snort.org/#documents, August 2020. 3281 [STIX] Jordan, B., Piazza, R., and T. Darley, "Structured Threat 3282 Information Expression (STIX)", STIX Version 2.1: 3283 Committee Specification 01 https://docs.oasis- 3284 open.org/cti/stix/v2.1/stix-v2.1.pdf, March 2020. 3286 Appendix A. Acknowledgments 3288 This document is a product by the I2NSF Working Group (WG) including 3289 WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This 3290 document took advantage of the review and comments from the following 3291 people: Roman Danyliw, Mahdi F. Dachmehchi, Daeyoung Hyun, Jan 3292 Lindblad (YANG doctor), and Tom Petch. The authors sincerely 3293 appreciate their sincere efforts and kind help. 3295 This work was supported by Institute of Information & Communications 3296 Technology Planning & Evaluation (IITP) grant funded by the Korea 3297 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 3298 Security Intelligence Technology Development for the Customized 3299 Security Service Provisioning). This work was supported in part by 3300 the IITP (2020-0-00395, Standard Development of Blockchain based 3301 Network Management Automation Technology). 3303 Appendix B. Contributors 3305 The following are co-authors of this document: 3307 Patrick Lingga - Department of Electrical and Computer Engineering, 3308 Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, Gyeonggi-do 3309 16419, Republic of Korea, EMail: patricklink@skku.edu 3311 Jinyong Tim Kim - Department of Electronic, Electrical and Computer 3312 Engineering, Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, 3313 Gyeonggi-do 16419, Republic of Korea, EMail: timkim@skku.edu 3315 Hyoungshick Kim - Department of Computer Science and Engineering, 3316 Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, Gyeonggi-do 3317 16419, Republic of Korea, EMail: hyoung@skku.edu 3319 Eunsoo Kim - Department of Electronic, Electrical and Computer 3320 Engineering, Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, 3321 Gyeonggi-do 16419, Republic of Korea, EMail: eskim86@skku.edu 3323 Seungjin Lee - Department of Electronic, Electrical and Computer 3324 Engineering, Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, 3325 Gyeonggi-do 16419, Republic of Korea, EMail: jine33@skku.edu 3327 Anil Lohiya - Juniper Networks, 1133 Innovation Way, Sunnyvale, CA 3328 94089, US, EMail: alohiya@juniper.net 3330 Dave Qi - Bloomberg, 731 Lexington Avenue, New York, NY 10022, US, 3331 EMail: DQI@bloomberg.net 3333 Nabil Bitar - Nokia, 755 Ravendale Drive, Mountain View, CA 94043, 3334 US, EMail: nabil.bitar@nokia.com 3336 Senad Palislamovic - Nokia, 755 Ravendale Drive, Mountain View, CA 3337 94043, US, EMail: senad.palislamovic@nokia.com 3339 Liang Xia - Huawei, 101 Software Avenue, Nanjing, Jiangsu 210012, 3340 China, EMail: Frank.Xialiang@huawei.com 3342 Appendix C. Changes from draft-ietf-i2nsf-consumer-facing-interface- 3343 dm-19 3345 The following changes are made from draft-ietf-i2nsf-consumer-facing- 3346 interface-dm-19: 3348 * The YANG module's prefix is updated from 'nsfcfi' to 'i2nsfcfi'. 3350 * The YANG module's name is updated from 'ietf-i2nsf-cfi-policy' to 3351 'ietf-i2nsf-cons-facing-interface'. 3353 Authors' Addresses 3354 Jaehoon Paul Jeong (editor) 3355 Department of Computer Science and Engineering 3356 Sungkyunkwan University 3357 2066 Seobu-Ro, Jangan-Gu 3358 Suwon 3359 Gyeonggi-Do 3360 16419 3361 Republic of Korea 3362 Phone: +82 31 299 4957 3363 Email: pauljeong@skku.edu 3364 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3366 Chaehong Chung 3367 Department of Electronic, Electrical and Computer Engineering 3368 Sungkyunkwan University 3369 2066 Seobu-Ro, Jangan-Gu 3370 Suwon 3371 Gyeonggi-Do 3372 16419 3373 Republic of Korea 3374 Phone: +82 31 299 4957 3375 Email: darkhong@skku.edu 3377 Tae-Jin Ahn 3378 Korea Telecom 3379 70 Yuseong-Ro, Yuseong-Gu 3380 Daejeon 3381 305-811 3382 Republic of Korea 3383 Phone: +82 42 870 8409 3384 Email: taejin.ahn@kt.com 3386 Rakesh Kumar 3387 Juniper Networks 3388 1133 Innovation Way 3389 Sunnyvale, CA 94089 3390 United States of America 3391 Email: rkkumar@juniper.net 3393 Susan Hares 3394 Huawei 3395 7453 Hickory Hill 3396 Saline, MI 48176 3397 United States of America 3398 Phone: +1-734-604-0332 3399 Email: shares@ndzh.com