idnits 2.17.1 draft-ietf-i2nsf-consumer-facing-interface-dm-19.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 (18 May 2022) is 680 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-30 == 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: 19 November 2022 T. Ahn 6 Korea Telecom 7 R. Kumar 8 Juniper Networks 9 S. Hares 10 Huawei 11 18 May 2022 13 I2NSF Consumer-Facing Interface YANG Data Model 14 draft-ietf-i2nsf-consumer-facing-interface-dm-19 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 19 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-18 . . . . 72 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 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-cfi-policy 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-cfi-policy). An XML example to configure the access 748 control a user group for the I2NSF Consumer-Facing Interface can be 749 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-cfi-policy@2022-05-18.yang" 837 module ietf-i2nsf-cfi-policy { 838 yang-version 1.1; 839 namespace 840 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; 841 prefix nsfcfi; 842 import ietf-inet-types{ 843 prefix inet; 844 reference "RFC 6991"; 845 } 847 import ietf-yang-types{ 848 prefix yang; 849 reference "RFC 6991"; 850 } 852 organization 853 "IETF I2NSF (Interface to Network Security Functions) 854 Working Group"; 856 contact 857 "WG Web: 858 WG List: 860 Editor: Jaehoon Paul Jeong 861 863 Editor: Patrick Lingga 864 "; 866 description 867 "This module is a YANG module for Consumer-Facing Interface. 869 Copyright (c) 2022 IETF Trust and the persons identified as 870 authors of the code. All rights reserved. 872 Redistribution and use in source and binary forms, with or 873 without modification, is permitted pursuant to, and subject to 874 the license terms contained in, the Revised BSD License set 875 forth in Section 4.c of the IETF Trust's Legal Provisions 876 Relating to IETF Documents 877 (https://trustee.ietf.org/license-info). 879 This version of this YANG module is part of RFC XXXX 880 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 881 for full legal notices."; 883 // RFC Ed.: replace XXXX with an actual RFC number and remove 884 // this note. 886 revision "2022-05-18" { 887 description "Initial revision."; 888 reference 889 "RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model"; 891 // RFC Ed.: replace XXXX with an actual RFC number and remove 892 // this note. 893 } 895 identity resolution-strategy { 896 description 897 "Base identity for resolution strategy"; 898 reference 899 "draft-ietf-i2nsf-capability-data-model-31: 900 I2NSF Capability YANG Data Model - Resolution Strategy"; 901 } 903 identity fmr { 904 base resolution-strategy; 905 description 906 "Conflict resolution with First Matching Rule (FMR)."; 907 reference 908 "draft-ietf-i2nsf-capability-data-model-31: 909 I2NSF Capability YANG Data Model - Resolution Strategy"; 910 } 912 identity lmr { 913 base resolution-strategy; 914 description 915 "Conflict resolution with Last Matching Rule (LMR)"; 916 reference 917 "draft-ietf-i2nsf-capability-data-model-31: 918 I2NSF Capability YANG Data Model - Resolution Strategy"; 919 } 921 identity pmre { 922 base resolution-strategy; 923 description 924 "Conflict resolution with Prioritized Matching Rule with 925 Errors (PMRE)"; 926 reference 927 "draft-ietf-i2nsf-capability-data-model-31: 928 I2NSF Capability YANG Data Model - Resolution Strategy"; 929 } 931 identity pmrn { 932 base resolution-strategy; 933 description 934 "Conflict resolution with Prioritized Matching Rule with 935 No Errors (PMRN)"; 936 reference 937 "draft-ietf-i2nsf-capability-data-model-31: 938 I2NSF Capability YANG Data Model - Resolution Strategy"; 940 } 942 identity event { 943 description 944 "Base identity for policy events."; 945 reference 946 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 947 Monitoring Interface YANG Data Model - Event"; 948 } 950 identity system-event { 951 base event; 952 description 953 "Base Identity for system events. System event (also called 954 alert) is defined as a warning about any changes of 955 configuration, any access violation, the information of 956 sessions and traffic flows."; 957 reference 958 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 959 Monitoring Interface YANG Data Model - System event"; 960 } 962 identity system-alarm { 963 base event; 964 description 965 "Base identity for system alarms. System alarm is defined as a 966 warning related to service degradation in system hardware."; 967 reference 968 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 969 Monitoring Interface YANG Data Model - System alarm"; 970 } 972 identity access-violation { 973 base system-event; 974 description 975 "Access-violation system event is an event when a user tries 976 to access (read, write, create, or delete) any information or 977 execute commands above their privilege (i.e., not-conformant 978 with the access profile)."; 979 reference 980 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 981 Monitoring Interface YANG Data Model - System event for access 982 violation"; 983 } 985 identity configuration-change { 986 base system-event; 987 description 988 "The configuration-change system event is an event when a user 989 adds a new configuration or modify an existing configuration 990 (write configuration)."; 991 reference 992 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 993 Monitoring Interface YANG Data Model - System event for 994 configuration change"; 995 } 997 identity memory-alarm { 998 base system-alarm; 999 description 1000 "Memory is the hardware to store information temporarily or for 1001 a short period, i.e., Random Access Memory (RAM). A 1002 memory-alarm is emitted when the memory usage is exceeding 1003 the threshold."; 1004 reference 1005 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 1006 Monitoring Interface YANG Data Model - System alarm for 1007 memory"; 1008 } 1010 identity cpu-alarm { 1011 base system-alarm; 1012 description 1013 "CPU is the Central Processing Unit that executes basic 1014 operations of the system. A cpu-alarm is emitted when the CPU 1015 usage is exceeding a threshold."; 1016 reference 1017 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 1018 Monitoring Interface YANG Data Model - System alarm for CPU"; 1019 } 1021 identity disk-alarm { 1022 base system-alarm; 1023 description 1024 "Disk or storage is the hardware to store information for a 1025 long period, i.e., Hard Disk and Solid-State Drive. A 1026 disk-alarm is emitted when the disk usage is exceeding a 1027 threshold."; 1028 reference 1029 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 1030 Monitoring Interface YANG Data Model - System alarm for disk"; 1031 } 1033 identity hardware-alarm { 1034 base system-alarm; 1035 description 1036 "A hardware alarm is emitted when a hardware failure (e.g., 1037 CPU, memory, disk, or interface) is detected. A hardware 1038 failure is a malfunction within the electronic circuits or 1039 electromechanical components of the hardware that makes it 1040 unusable."; 1041 reference 1042 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 1043 Monitoring Interface YANG Data Model - System alarm for 1044 hardware"; 1045 } 1047 identity interface-alarm { 1048 base system-alarm; 1049 description 1050 "Interface is the network interface for connecting a device 1051 with the network. The interface-alarm is emitted when the 1052 state of the interface is changed."; 1053 reference 1054 "draft-ietf-i2nsf-nsf-monitoring-data-model-18: I2NSF NSF 1055 Monitoring Interface YANG Data Model - System alarm for 1056 interface"; 1057 } 1059 identity protocol { 1060 description 1061 "This identity represents the protocol types."; 1062 } 1064 identity transport-protocol { 1065 base protocol; 1066 description 1067 "Base identity for the Layer 4 (i.e., Transport Layer) 1068 Protocols"; 1069 } 1071 identity tcp { 1072 base transport-protocol; 1073 description 1074 "Base identity for TCP condition capabilities"; 1075 reference 1076 "RFC 793: Transmission Control Protocol 1077 draft-ietf-tcpm-rfc793bis-28: Transmission Control Protocol 1078 (TCP) Specification"; 1079 } 1081 identity udp { 1082 base transport-protocol; 1083 description 1084 "Base identity for UDP condition capabilities"; 1085 reference 1086 "RFC 768: User Datagram Protocol"; 1087 } 1089 identity sctp { 1090 base transport-protocol; 1091 description 1092 "Identity for SCTP condition capabilities"; 1093 reference 1094 "draft-ietf-tsvwg-rfc4960-bis-19: Stream Control Transmission 1095 Protocol"; 1096 } 1098 identity dccp { 1099 base transport-protocol; 1100 description 1101 "Identity for DCCP condition capabilities"; 1102 reference 1103 "RFC 4340: Datagram Congestion Control Protocol"; 1104 } 1106 identity application-protocol { 1107 description 1108 "Base identity for Application protocol. Note that a subset of 1109 application protocols (e.g., HTTP, HTTPS, FTP, POP3, and 1110 IMAP) are handled in this YANG module, rather than all 1111 the existing application protocols."; 1112 } 1114 identity http { 1115 base application-protocol; 1116 description 1117 "The identity for Hypertext Transfer Protocol version 1.1 1118 (HTTP/1.1)."; 1119 reference 1120 "draft-ietf-httpbis-semantics-19: HTTP Semantics 1121 draft-ietf-httpbis-messaging-19: HTTP/1.1"; 1122 } 1124 identity https { 1125 base application-protocol; 1126 description 1127 "The identity for Hypertext Transfer Protocol version 1.1 1128 (HTTP/1.1) over TLS."; 1129 reference 1130 "draft-ietf-httpbis-semantics-19: HTTP Semantics 1131 draft-ietf-httpbis-messaging-19: HTTP/1.1"; 1133 } 1135 identity http2 { 1136 base application-protocol; 1137 description 1138 "The identity for Hypertext Transfer Protocol version 2 1139 (HTTP/2)."; 1140 reference 1141 "draft-ietf-httpbis-http2bis-07: HTTP/2"; 1142 } 1144 identity https2 { 1145 base application-protocol; 1146 description 1147 "The identity for Hypertext Transfer Protocol version 2 1148 (HTTP/2) over TLS."; 1149 reference 1150 "draft-ietf-httpbis-http2bis-07: HTTP/2"; 1151 } 1153 identity ftp { 1154 base application-protocol; 1155 description 1156 "The identity for File Transfer Protocol."; 1157 reference 1158 "RFC 959: File Transfer Protocol (FTP)"; 1159 } 1161 identity ssh { 1162 base application-protocol; 1163 description 1164 "The identity for Secure Shell (SSH) protocol."; 1165 reference 1166 "RFC 4250: The Secure Shell (SSH) Protocol"; 1167 } 1169 identity telnet { 1170 base application-protocol; 1171 description 1172 "The identity for telnet."; 1173 reference 1174 "RFC 854: Telnet Protocol"; 1175 } 1177 identity smtp { 1178 base application-protocol; 1179 description 1180 "The identity for Simple Mail Transfer Protocol."; 1182 reference 1183 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1184 } 1186 identity pop3 { 1187 base application-protocol; 1188 description 1189 "The identity for Post Office Protocol 3 (POP3)."; 1190 reference 1191 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1192 } 1194 identity pop3s { 1195 base application-protocol; 1196 description 1197 "The identity for Post Office Protocol 3 (POP3) over TLS"; 1198 reference 1199 "RFC 1939: Post Office Protocol - Version 3 (POP3) 1200 RFC 2595: Using TLS with IMAP, POP3 and ACAP"; 1201 } 1203 identity imap { 1204 base application-protocol; 1205 description 1206 "The identity for Internet Message Access Protocol (IMAP)."; 1207 reference 1208 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 1209 4rev2"; 1210 } 1212 identity imaps { 1213 base application-protocol; 1214 description 1215 "The identity for Internet Message Access Protocol (IMAP) over 1216 TLS"; 1217 reference 1218 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 1219 4rev2"; 1220 } 1222 identity action { 1223 description 1224 "Base identity for action"; 1225 } 1227 identity primary-action { 1228 base action; 1229 description 1230 "Base identity for primary action. Primary action is an action 1231 that handle the forwarding of the packets or flows in an 1232 NSF."; 1233 } 1235 identity secondary-action { 1236 base action; 1237 description 1238 "Base identity for secondary action. Secondary action is an 1239 action in the background that does not affect the network, 1240 such as logging."; 1241 } 1243 identity ingress-action { 1244 base action; 1245 description 1246 "Base identity for ingress action. The action to handle the 1247 network traffic that is entering the secured network."; 1248 reference 1249 "draft-ietf-i2nsf-capability-data-model-31: 1250 I2NSF Capability YANG Data Model - Ingress Action"; 1251 } 1253 identity egress-action { 1254 base action; 1255 description 1256 "Base identity for egress action. The action to handle the 1257 network traffic that is exiting the secured network."; 1258 reference 1259 "draft-ietf-i2nsf-capability-data-model-31: 1260 I2NSF Capability YANG Data Model - Egress Action"; 1261 } 1263 identity pass { 1264 base ingress-action; 1265 base egress-action; 1266 description 1267 "The pass action allows traffic that matches 1268 the rule to proceed through the NSF to reach the 1269 destination."; 1270 reference 1271 "draft-ietf-i2nsf-capability-data-model-31: 1272 I2NSF Capability YANG Data Model - Actions and 1273 Default Action"; 1274 } 1276 identity drop { 1277 base ingress-action; 1278 base egress-action; 1279 description 1280 "The drop action denies the traffic that 1281 matches the rule. The drop action should do a silent drop, 1282 which does not give any response to the source."; 1283 reference 1284 "draft-ietf-i2nsf-capability-data-model-31: 1285 I2NSF Capability YANG Data Model - Actions and 1286 Default Action"; 1287 } 1289 identity reject { 1290 base ingress-action; 1291 base egress-action; 1292 description 1293 "The reject action denies a packet to go through the NSF 1294 entering or exiting the internal network and sends a response 1295 back to the source. The response depends on the packet and 1296 implementation. For example, a TCP packet is rejected with 1297 TCP RST response or a UDP packet may be rejected with an 1298 ICMPv4 response message with Type 3 Code 3 or ICMPv6 response 1299 message Type 1 Code 4 (i.e., Destination Unreachable: 1300 Destination port unreachable)."; 1301 } 1303 identity mirror { 1304 base ingress-action; 1305 base egress-action; 1306 description 1307 "The mirror action copies a packet and sends the packet's copy 1308 to the monitoring entity while still allowing the packet or 1309 flow to go through the NSF."; 1310 reference 1311 "draft-ietf-i2nsf-capability-data-model-31: 1312 I2NSF Capability YANG Data Model - Actions and 1313 Default Action"; 1314 } 1316 identity rate-limit { 1317 base ingress-action; 1318 base egress-action; 1319 description 1320 "The rate limit action limits the number of packets or flows 1321 that can go through the NSF by dropping packets or flows 1322 (randomly or systematically). The drop mechanism, e.g., silent 1323 drop and unreachable drop (i.e., reject), is up to the 1324 implementation"; 1325 reference 1326 "draft-ietf-i2nsf-capability-data-model-31: 1327 I2NSF Capability YANG Data Model - Actions and 1328 Default Action"; 1329 } 1331 identity invoke-signaling { 1332 base egress-action; 1333 description 1334 "The invoke-signaling action is used to convey information of 1335 the event triggering this action to a monitoring entity."; 1336 } 1338 identity tunnel-encapsulation { 1339 base egress-action; 1340 description 1341 "The tunnel encapsulation action is used to encapsulate the 1342 packet to be tunneled across the network to enable a secure 1343 connection."; 1344 } 1346 identity forwarding { 1347 base egress-action; 1348 description 1349 "The forwarding action is used to relay the packet from one 1350 network segment to another node in the network."; 1351 } 1353 identity transformation { 1354 base egress-action; 1355 description 1356 "The transformation action is used to transform a packet by 1357 modifying it (e.g., HTTP-to-CoAP packet translation). 1358 Note that a subset of transformation (e.g., HTTP-to-CoAP) is 1359 handled in this YANG module, rather than all the existing 1360 transformations. Specific algorithmic transformations can be 1361 executed by a middlebox (e.g., NSF) for a given transformation 1362 name."; 1363 reference 1364 "RFC 8075: Guidelines for Mapping Implementations: HTTP to the 1365 Constrained Application Protocol (CoAP) - Translation between 1366 HTTP and CoAP."; 1367 } 1369 identity log-action { 1370 base action; 1371 description 1372 "Base identity for log action"; 1373 } 1374 identity rule-log { 1375 base log-action; 1376 description 1377 "Log the policy rule that has been triggered by a packet or 1378 flow."; 1379 } 1381 identity session-log { 1382 base log-action; 1383 description 1384 "A session is a connection (i.e., traffic flow) of a data plane 1385 that includes source and destination information of IP 1386 addresses and transport port numbers with the protocol used. 1387 Log the session that triggered a policy rule."; 1388 } 1390 identity icmp-message { 1391 description 1392 "Base identity for ICMP Message types. Note that this YANG 1393 module only provide ICMP messages that is shared between 1394 ICMPv4 and ICMPv6 (e.g., Destination Unreachable: Port 1395 Unreachable which is ICMPv4 type 3 code 3 or ICMPv6 type 1 1396 code 4)."; 1397 reference 1398 "RFC 792: Internet Control Message Protocol 1399 RFC 8335: PROBE: A Utility for Probing Interfaces 1400 IANA: Internet Control Message Protocol (ICMP) 1401 Parameters 1402 IANA: Internet Control Message Protocol version 6 1403 (ICMPv6) Parameters"; 1404 } 1406 identity echo-reply { 1407 base icmp-message; 1408 description 1409 "Identity for 'Echo Reply' ICMP message type 0 in ICMPv4 or 1410 type 129 in ICMPv6"; 1411 } 1413 identity destination-unreachable { 1414 base icmp-message; 1415 description 1416 "Identity for 'Destination Unreachable' ICMP message type 3 in 1417 ICMPv4 or type 1 in ICMPv6"; 1418 } 1420 identity redirect { 1421 base icmp-message; 1422 description 1423 "Identity for 'Redirect' ICMP message type 5 in ICMPv4 1424 or type 137 in ICMPv6"; 1425 } 1427 identity echo { 1428 base icmp-message; 1429 description 1430 "Identity for 'Echo' ICMP message type 8 in ICMPv4 or type 128 1431 in ICMPv6"; 1432 } 1434 identity router-advertisement { 1435 base icmp-message; 1436 description 1437 "Identity for 'Router Advertisement' ICMP message type 9 in 1438 ICMPv4 or type 134 in ICMPv6"; 1439 } 1441 identity router-solicitation { 1442 base icmp-message; 1443 description 1444 "Identity for 'Router Solicitation' ICMP message type 10 in 1445 ICMPv4 or type 135 in ICMPv6"; 1446 } 1448 identity time-exceeded { 1449 base icmp-message; 1450 description 1451 "Identity for 'Time exceeded' ICMP message type 11 in ICMPv4 1452 or type 3 in ICMPv6"; 1453 } 1455 identity parameter-problem { 1456 base icmp-message; 1457 description 1458 "Identity for 'Parameter Problem' ICMP message type 12 in 1459 ICMPv4 or type 4 in ICMPv6"; 1460 } 1462 identity experimental-mobility-protocols { 1463 base icmp-message; 1464 description 1465 "Identity for 'Experimental Mobility Protocols' ICMP message 1466 type 41 in ICMPv4 or type 150 in ICMPv6"; 1467 } 1469 identity extended-echo-request { 1470 base icmp-message; 1471 description 1472 "Identity for 'Extended Echo Request' ICMP message type 42 1473 in ICMPv4 or type 160 in ICMPv6"; 1474 } 1476 identity extended-echo-reply { 1477 base icmp-message; 1478 description 1479 "Identity for 'Extended Echo Reply' ICMP message type 43 in 1480 ICMPv4 or type 161 in ICMPv6"; 1481 } 1483 identity port-unreachable { 1484 base destination-unreachable; 1485 description 1486 "Identity for port unreachable in destination unreachable 1487 message (i.e., ICMPv4 type 3 code 3 or ICMPv6 type 1 code 4)"; 1488 } 1490 identity request-no-error { 1491 base extended-echo-request; 1492 description 1493 "Identity for request with no error in extended echo request 1494 message (i.e., ICMPv4 type 42 code 0 or ICMPv6 type 160 1495 code 0)"; 1496 } 1498 identity reply-no-error { 1499 base extended-echo-reply; 1500 description 1501 "Identity for reply with no error in extended echo reply 1502 message (i.e., ICMPv4 type 43 code 0 or ICMPv6 type 161 1503 code 0)"; 1504 } 1506 identity malformed-query { 1507 base extended-echo-reply; 1508 description 1509 "Identity for malformed query in extended echo reply message 1510 (i.e., ICMPv4 type 43 code 1 or ICMPv6 type 161 code 1)"; 1511 } 1513 identity no-such-interface { 1514 base extended-echo-reply; 1515 description 1516 "Identity for no such interface in extended echo reply message 1517 (i.e., ICMPv4 type 43 code 2 or ICMPv6 type 161 code 2)"; 1519 } 1521 identity no-such-table-entry { 1522 base extended-echo-reply; 1523 description 1524 "Identity for no such table entry in extended echo reply 1525 message (i.e., ICMPv4 type 43 code 3 or ICMPv6 type 161 1526 code 3)"; 1527 } 1529 identity multiple-interfaces-satisfy-query { 1530 base extended-echo-reply; 1531 description 1532 "Identity for multiple interfaces satisfy query in extended 1533 echo reply message (i.e., ICMPv4 type 43 code 4 or ICMPv6 1534 type 161 code 4) "; 1535 reference 1536 "RFC 792: Internet Control Message Protocol 1537 RFC 8335: PROBE: A Utility for Probing Interfaces"; 1538 } 1540 identity signature-type { 1541 description 1542 "This represents the base identity for signature types."; 1543 } 1545 identity signature-yara { 1546 base signature-type; 1547 description 1548 "This represents the YARA signatures."; 1549 reference 1550 "YARA: YARA signatures are explained."; 1551 } 1553 identity signature-snort { 1554 base signature-type; 1555 description 1556 "This represents the SNORT signatures."; 1557 reference 1558 "SNORT: SNORT signatures are explained."; 1559 } 1561 identity signature-suricata { 1562 base signature-type; 1563 description 1564 "This represents the SURICATA signatures."; 1565 reference 1566 "SURICATA: SURICATA signatures are explained."; 1568 } 1570 identity threat-feed-type { 1571 description 1572 "This represents the base identity for threat-feed."; 1573 } 1575 identity continent { 1576 description 1577 "Base identity for continent types. The continents are based 1578 on Encyclopedia Britannica"; 1579 reference 1580 "Encyclopedia Britannica: Continent"; 1581 } 1583 identity africa { 1584 base continent; 1585 description 1586 "Identity for Africa."; 1587 reference 1588 "Encyclopedia Britannica: Continent"; 1589 } 1591 identity asia { 1592 base continent; 1593 description 1594 "Identity for Asia."; 1595 reference 1596 "Encyclopedia Britannica: Continent"; 1597 } 1599 identity antarctica { 1600 base continent; 1601 description 1602 "Identity for Antarctica."; 1603 reference 1604 "Encyclopedia Britannica: Continent"; 1605 } 1607 identity europe { 1608 base continent; 1609 description 1610 "Identity for Europe."; 1611 reference 1612 "Encyclopedia Britannica: Continent"; 1613 } 1615 identity north-america { 1616 base continent; 1617 description 1618 "Identity for North America."; 1619 reference 1620 "Encyclopedia Britannica: Continent"; 1621 } 1623 identity south-america { 1624 base continent; 1625 description 1626 "Identity for South America."; 1627 reference 1628 "Encyclopedia Britannica: Continent"; 1629 } 1631 identity australia { 1632 base continent; 1633 description 1634 "Identity for Australia"; 1635 reference 1636 "Encyclopedia Britannica: Continent"; 1637 } 1639 identity device-type { 1640 description 1641 "Base identity for types of device. This identity is used for 1642 type of the device for the source or destination of a packet 1643 or traffic flow. Note that the device type of either a source 1644 or destination can be known with the help of DHCP 1645 Fingerprinting and the interaction between an NSF and a DHCP 1646 server."; 1647 } 1649 identity computer { 1650 base device-type; 1651 description 1652 "Identity for computer such as personal computer (PC) 1653 and server."; 1654 } 1656 identity mobile-phone { 1657 base device-type; 1658 description 1659 "Identity for mobile-phone such as smartphone and 1660 cellphone"; 1661 } 1663 identity voip-vocn-phone { 1664 base device-type; 1665 description 1666 "Identity for VoIP (Voice over Internet Protocol) or VoCN 1667 (Voice over Cellular Network, such as Voice over LTE or 5G) 1668 phone"; 1669 } 1671 identity tablet { 1672 base device-type; 1673 description 1674 "Identity for tablet devices"; 1675 } 1677 identity network-infrastructure-device { 1678 base device-type; 1679 description 1680 "Identity for network infrastructure devices 1681 such as switch, router, and access point"; 1682 } 1684 identity iot-device { 1685 base device-type; 1686 description 1687 "Identity for Internet of Things (IoT) devices 1688 such as sensors, actuators, and low-power 1689 low-capacity computing devices"; 1690 } 1692 identity ot { 1693 base device-type; 1694 description 1695 "Identity for Operational Technology (OT) devices (also 1696 known as industrial control systems) that interact 1697 with the physical environment and detect or cause direct 1698 change through the monitoring and control of devices, 1699 processes, and events such as programmable logic 1700 controllers (PLCs), digital oscilloscopes, building 1701 management systems (BMS), and fire control systems"; 1702 } 1704 identity vehicle { 1705 base device-type; 1706 description 1707 "Identity for transportation vehicles that connect to and 1708 share data through the Internet over Vehicle-to-Everything 1709 (V2X) communications."; 1710 } 1712 /* 1713 * Typedefs 1714 */ 1716 typedef time { 1717 type string { 1718 pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' 1719 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 1720 } 1721 description 1722 "The time type represents an instance of time of zero-duration 1723 in the specified timezone that recurs every day."; 1724 } 1726 typedef day { 1727 type enumeration { 1728 enum monday { 1729 description 1730 "This represents Monday."; 1731 } 1732 enum tuesday { 1733 description 1734 "This represents Tuesday."; 1735 } 1736 enum wednesday { 1737 description 1738 "This represents Wednesday"; 1739 } 1740 enum thursday { 1741 description 1742 "This represents Thursday."; 1743 } 1744 enum friday { 1745 description 1746 "This represents Friday."; 1747 } 1748 enum saturday { 1749 description 1750 "This represents Saturday."; 1751 } 1752 enum sunday { 1753 description 1754 "This represents Sunday."; 1755 } 1756 } 1757 description 1758 "The type for representing the day of the week."; 1759 } 1761 /* 1762 * Groupings 1763 */ 1765 grouping ip-address-info { 1766 description 1767 "There are two types to configure a security policy 1768 for an IP address, such as IPv4 adress and IPv6 address."; 1769 choice match-type { 1770 description 1771 "User can choose between IPv4 and IPv6."; 1772 case range-match-ipv4 { 1773 container range-ipv4-address { 1774 leaf start-ipv4-address { 1775 type inet:ipv4-address-no-zone; 1776 mandatory true; 1777 description 1778 "A start IPv4 address for a range match."; 1779 } 1780 leaf end-ipv4-address { 1781 type inet:ipv4-address-no-zone; 1782 mandatory true; 1783 description 1784 "An end IPv4 address for a range match."; 1785 } 1786 description 1787 "A range match for IPv4 addresses is provided. 1788 Note that the start IPv4 address must be lower than 1789 the end IPv4 address."; 1790 } 1791 } 1792 case range-match-ipv6 { 1793 container range-ipv6-address { 1794 leaf start-ipv6-address { 1795 type inet:ipv6-address-no-zone; 1796 mandatory true; 1797 description 1798 "A start IPv6 address for a range match."; 1799 } 1800 leaf end-ipv6-address { 1801 type inet:ipv6-address-no-zone; 1802 mandatory true; 1803 description 1804 "An end IPv6 address for a range match."; 1805 } 1806 description 1807 "A range match for IPv6 addresses is provided. 1808 Note that the start IPv6 address must be lower than 1809 the end IPv6 address."; 1810 } 1811 } 1812 } 1813 } 1815 grouping user-group { 1816 description 1817 "This group represents user group information such as name and 1818 ip-address."; 1819 leaf name { 1820 type string; 1821 description 1822 "This represents the name of a user-group. A user-group name 1823 is used to map a user-group's name (e.g., employees) to IP 1824 address(es), MAC address(es). 1825 It is dependent on implementation."; 1826 } 1827 leaf-list mac-address { 1828 type yang:mac-address; 1829 description 1830 "Represent the MAC Address of a user-group. A user-group 1831 can have multiple MAC Addresses."; 1832 } 1833 uses ip-address-info{ 1834 description 1835 "This represents the IP addresses of a user-group."; 1836 refine match-type{ 1837 mandatory true; 1838 } 1839 } 1840 } 1842 grouping device-group { 1843 description 1844 "This group represents device group information such as 1845 ip-address protocol."; 1846 leaf name { 1847 type string; 1848 description 1849 "This represents the name of a device-group."; 1850 } 1851 uses ip-address-info{ 1852 refine match-type{ 1853 mandatory true; 1854 } 1855 } 1856 leaf-list application-protocol { 1857 type identityref { 1858 base application-protocol; 1859 } 1860 description 1861 "This represents the application layer protocols of devices. 1862 If this is not set, it cannot support the appropriate 1863 protocol"; 1864 } 1865 } 1867 grouping location-group { 1868 description 1869 "This group represents location-group information such as 1870 geo-ip and continent."; 1871 leaf name { 1872 type string; 1873 description 1874 "This represents the name of a location."; 1875 } 1876 list geo-ip-ipv4 { 1877 key "ipv4-address"; 1878 description 1879 "This represents the list of IPv4 addresses based on a 1880 location."; 1881 leaf ipv4-address{ 1882 type inet:ipv4-address-no-zone; 1883 description 1884 "This represents an IPv4 geo-ip address of a location."; 1885 } 1886 leaf ipv4-prefix{ 1887 type inet:ipv4-prefix; 1888 description 1889 "This represents the prefix for the IPv4 addresses."; 1890 } 1891 } 1892 list geo-ip-ipv6 { 1893 key "ipv6-address"; 1894 description 1895 "This represents the list of IPv6 addresses based on a 1896 location."; 1897 leaf ipv6-address{ 1898 type inet:ipv6-address-no-zone; 1899 description 1900 "This represents an IPv6 geo-ip address of a location."; 1901 } 1902 leaf ipv6-prefix{ 1903 type inet:ipv6-prefix; 1904 description 1905 "This represents the prefix for the IPv6 addresses."; 1906 } 1907 } 1908 leaf continent { 1909 type identityref { 1910 base continent; 1911 } 1912 default asia; 1913 description 1914 "location-group has geo-ip addresses of the corresponding 1915 continent."; 1916 } 1917 reference 1918 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1919 An access control for a geographical location (i.e., 1920 geolocation) that has the corresponding IP prefix."; 1921 } 1923 grouping payload-string { 1924 description 1925 "The grouping for payload-string content. It contains 1926 information such as name and string content."; 1927 } 1929 list i2nsf-cfi-policy { 1930 key "name"; 1931 description 1932 "This is a security policy list. Each policy in the list 1933 contains a list of security policy rules, and is a policy 1934 instance to have the information of where and when a policy 1935 needs to be applied."; 1936 leaf name { 1937 type string; 1938 description 1939 "The name which identifies the policy."; 1940 } 1941 leaf language { 1942 type string { 1943 pattern '(([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})' 1944 + '{0,2})?|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?' 1945 + '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}' 1946 + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za-wy-z]' 1947 + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]' 1948 + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|' 1949 + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-' 1950 + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-' 1951 + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-' 1952 + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]' 1953 + '|[Ii]-[Hh][Aa][Kk]|' 1954 + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|' 1955 + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|' 1956 + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|' 1957 + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|' 1958 + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|' 1959 + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-' 1960 + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-' 1961 + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-' 1962 + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|' 1963 + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-' 1964 + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|' 1965 + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-' 1966 + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-' 1967 + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))'; 1968 } 1969 default "en-US"; 1970 description 1971 "The value in this field indicates the language tag 1972 used for all of the 'leaf description' described in the 1973 'i2nsf-cfi-policy'. 1975 The attribute is encoded following the rules in Section 2.1 1976 in RFC 5646. The default language tag is 'en-US'"; 1977 reference 1978 "RFC 5646: Tags for Identifying Languages"; 1979 } 1980 leaf resolution-strategy { 1981 type identityref { 1982 base resolution-strategy; 1983 } 1984 default fmr; 1985 description 1986 "The resolution strategies that can be used to 1987 specify how to resolve conflicts that occur between 1988 actions of the same or different policy rules that 1989 are matched and contained in this particular NSF"; 1991 reference 1992 "draft-ietf-i2nsf-capability-data-model-31: 1993 I2NSF Capability YANG Data Model - Resolution strategy"; 1994 } 1995 list rules { 1996 key "name"; 1998 description 1999 "There can be a single or multiple number of rules."; 2000 leaf name { 2001 type string; 2002 description 2003 "This represents the name for a rule."; 2004 } 2006 leaf priority { 2007 type uint8 { 2008 range "1..255"; 2009 } 2010 description 2011 "The priority keyword comes with a mandatory 2012 numeric value which can range from 1 through 255. 2013 Note that a higher number means a higher priority"; 2014 } 2016 container event { 2017 description 2018 "This represents an event (i.e., a security event), for 2019 which a security rule is made."; 2020 leaf-list system-event { 2021 type identityref { 2022 base system-event; 2023 } 2024 description 2025 "The security policy rule according to 2026 system events."; 2027 } 2029 leaf-list system-alarm { 2030 type identityref { 2031 base system-alarm; 2032 } 2033 description 2034 "The security policy rule according to 2035 system alarms."; 2036 } 2037 } 2039 container condition { 2040 description 2041 "Conditions for general security policies."; 2042 container firewall { 2043 description 2044 "A general firewall condition based on the packet 2045 header."; 2046 leaf-list source { 2047 type union { 2048 type leafref { 2049 path "/i2nsf-cfi-policy/endpoint-groups/" 2050 + "user-group/name"; 2051 } 2052 type leafref { 2053 path "/i2nsf-cfi-policy/endpoint-groups/" 2054 + "device-group/name"; 2055 } 2056 } 2057 description 2058 "This describes the path of the source."; 2059 } 2061 leaf-list destination { 2062 type union { 2063 type leafref { 2064 path "/i2nsf-cfi-policy/endpoint-groups/" 2065 + "user-group/name"; 2066 } 2067 type leafref { 2068 path "/i2nsf-cfi-policy/endpoint-groups/" 2069 + "device-group/name"; 2070 } 2071 } 2072 description 2073 "This describes the path to the destinations."; 2074 } 2076 leaf transport-layer-protocol { 2077 type identityref { 2078 base transport-protocol; 2079 } 2080 description 2081 "The transport-layer protocol to be matched."; 2082 } 2084 container range-port-number { 2085 leaf start-port-number { 2086 type inet:port-number; 2087 description 2088 "A start port number for range match."; 2089 } 2090 leaf end-port-number { 2091 type inet:port-number; 2092 description 2093 "An end port number for range match."; 2094 } 2095 description 2096 "A range match for transport-layer port number. Note 2097 that the start port number value must be lower than 2098 the end port number value"; 2099 } 2101 container icmp { 2102 description 2103 "Represents the ICMPv4 and ICMPv6 packet header 2104 information to determine if the set of policy 2105 actions in this ECA policy rule should be executed 2106 or not."; 2107 reference 2108 "RFC 792: Internet Control Message Protocol 2109 RFC 8335: PROBE: A Utility for Probing Interfaces"; 2111 leaf-list message { 2112 type identityref { 2113 base icmp-message; 2114 } 2115 description 2116 "The security policy rule according to 2117 ICMP message. The type is representing the 2118 ICMP message corresponds to the ICMP type and 2119 code."; 2120 reference 2121 "RFC 792: Internet Control Message Protocol 2122 RFC 8335: PROBE: A Utility for Probing Interfaces 2123 IANA: Internet Control Message Protocol (ICMP) 2124 Parameters 2125 IANA: Internet Control Message Protocol version 6 2126 (ICMPv6) Parameters"; 2127 } 2128 } 2129 } 2131 container ddos { 2132 description 2133 "A condition for a DDoS attack."; 2134 container rate-limit { 2135 description 2136 "This describes the rate-limit."; 2137 leaf packet-rate-threshold { 2138 type uint64; 2139 description 2140 "This is a trigger value for a rate limit of packet 2141 rate for a DDoS-attack mitigation."; 2142 } 2143 leaf byte-rate-threshold { 2144 type uint64; 2145 description 2146 "This is a trigger value for a rate limit of byte 2147 rate for a DDoS-attack mitigation."; 2148 } 2149 leaf flow-rate-threshold { 2150 type uint64; 2151 description 2152 "This is a trigger value for a rate limit of flow 2153 rate for a DDoS-attack mitigation."; 2154 } 2155 } 2156 } 2158 container anti-virus { 2159 description 2160 "A condition for anti-virus"; 2162 leaf-list exception-files { 2163 type string; 2164 description 2165 "The type or name of the files to be excluded by the 2166 antivirus. This can be used to keep the known 2167 harmless files. 2168 If the value starts with a regular expression (e.g., 2169 '*.exe'), the antivirus should interpret it as a 2170 file pattern/type to be excluded. 2171 If the value does not start with a dot (e.g., 2172 'example.exe'), the antivirus should interpret it as 2173 a file name/path to be excluded."; 2174 } 2175 } 2177 container payload { 2178 description 2179 "A condition based on a packet's content."; 2180 leaf-list content { 2181 type leafref { 2182 path "/i2nsf-cfi-policy/threat-prevention/" 2183 + "payload-content/name"; 2184 } 2185 description 2186 "This describes the paths to a packet content's"; 2187 } 2188 } 2190 container url-category { 2191 description 2192 "Condition for url category"; 2194 leaf url-name { 2195 type leafref { 2196 path "/i2nsf-cfi-policy/endpoint-groups/" 2197 + "url-group/name"; 2198 } 2199 description 2200 "This is description for the condition of a URL's 2201 category such as SNS sites, game sites, ecommerce 2202 sites, company sites, and university sites."; 2203 } 2204 } 2206 container voice { 2207 description 2208 "For the VoIP/VoCN security system, a VoIP/ 2209 VoCN security system can monitor each 2210 VoIP/VoCN flow and manage VoIP/VoCN 2211 security rules controlled by a centralized 2212 server for VoIP/VoCN security service 2213 (called VoIP IPS). The VoIP/VoCN security 2214 system controls each switch for the 2215 VoIP/VoCN call flow management by 2216 manipulating the rules that can be added, 2217 deleted, or modified dynamically. 2218 Note that VoIP is Voice over Internet Protocol 2219 and VoCN is Voice over Cellular Network such as 2220 Voice over LTE or 5G"; 2221 reference 2222 "RFC 3261: SIP: Session Initiation Protocol"; 2224 leaf-list source-id { 2225 type string; 2226 description 2227 "The security policy rule according to 2228 a source voice ID for VoIP and VoCN."; 2229 } 2231 leaf-list destination-id { 2232 type string; 2233 description 2234 "The security policy rule according to 2235 a destination voice ID for VoIP and VoCN."; 2236 } 2238 leaf-list user-agent { 2239 type string; 2240 description 2241 "The security policy rule according to 2242 an user agent for VoIP and VoCN."; 2243 } 2244 } 2246 container context { 2247 description 2248 "Condition for matching the context of the packet, such 2249 as geographic location, time, packet direction"; 2250 container time { 2251 description 2252 "The time when a security policy rule should be 2253 applied."; 2254 leaf start-date-time { 2255 type yang:date-and-time; 2256 description 2257 "This is the start date and time for a security 2258 policy rule."; 2259 } 2260 leaf end-date-time { 2261 type yang:date-and-time; 2262 description 2263 "This is the end date and time for a security policy 2264 rule. The policy rule will stop working after the 2265 specified end date and time."; 2266 } 2267 container period { 2268 when 2269 "../frequency!='only-once'"; 2270 description 2271 "This represents the repetition time. In the case 2272 where the frequency is weekly, the days can be 2273 set."; 2274 leaf start-time { 2275 type time; 2276 description 2277 "This is a period's start time for an event."; 2278 } 2279 leaf end-time { 2280 type time; 2281 description 2282 "This is a period's end time for an event."; 2283 } 2284 leaf-list day { 2285 when 2286 "../../frequency='weekly'"; 2287 type day; 2288 min-elements 1; 2289 description 2290 "This represents the repeated day of every week 2291 (e.g., Monday and Tuesday). More than one day can 2292 be specified."; 2293 } 2294 leaf-list date { 2295 when 2296 "../../frequency='monthly'"; 2297 type int8 { 2298 range "1..31"; 2299 } 2300 min-elements 1; 2301 description 2302 "This represents the repeated date of every month. 2303 More than one date can be specified."; 2304 } 2305 leaf-list month { 2306 when 2307 "../../frequency='yearly'"; 2308 type string{ 2309 pattern '\d{2}-\d{2}'; 2310 } 2311 min-elements 1; 2312 description 2313 "This represents the repeated date and month of 2314 every year. More than one can be specified. 2315 A pattern used here is Month and Date (MM-DD)."; 2316 } 2317 } 2319 leaf frequency { 2320 type enumeration { 2321 enum only-once { 2322 description 2323 "This represents that the rule is immediately 2324 enforced only once and not repeated. The policy 2325 will continuously be active from the 2326 start-date-time to the end-date-time."; 2327 } 2328 enum daily { 2329 description 2330 "This represents that the rule is enforced on a 2331 daily basis. The policy will be repeated daily 2332 until the end-date-time."; 2333 } 2334 enum weekly { 2335 description 2336 "This represents that the rule is enforced on a 2337 weekly basis. The policy will be repeated weekly 2338 until the end-date-time. The repeated days can 2339 be specified."; 2340 } 2341 enum monthly { 2342 description 2343 "This represents that the rule is enforced on a 2344 monthly basis. The policy will be repeated 2345 monthly until the end-date-time."; 2346 } 2347 enum yearly { 2348 description 2349 "This represents that the rule is enforced on a 2350 yearly basis. The policy will be repeated 2351 yearly until the end-date-time."; 2352 } 2353 } 2354 default only-once; 2355 description 2356 "This represents how frequently the rule should be 2357 enforced."; 2358 } 2359 } 2361 container application { 2362 description 2363 "Condition for application"; 2364 leaf-list protocol { 2365 type identityref { 2366 base application-protocol; 2367 } 2368 description 2369 "The condition based on the application layer 2370 protocol"; 2371 } 2372 } 2374 container device-type { 2375 description 2376 "Condition for type of the destination device"; 2377 leaf-list device { 2378 type identityref { 2379 base device-type; 2380 } 2381 description 2382 "The device attribute that can identify a device, 2383 including the device type (i.e., router, switch, 2384 pc, ios, or android) and the device's owner as 2385 well."; 2387 } 2388 } 2390 container users { 2391 description 2392 "Condition for users"; 2393 list user { 2394 key "id"; 2395 description 2396 "The user with which the traffic flow is associated 2397 can be identified by either a user ID or username. 2398 The user-to-IP address mapping is assumed to be 2399 provided by the unified user management system via 2400 network."; 2401 leaf id { 2402 type uint32; 2403 description 2404 "The ID of the user."; 2405 } 2406 leaf name { 2407 type string; 2408 description 2409 "The name of the user."; 2410 } 2411 } 2412 list group { 2413 key "id"; 2414 description 2415 "The user group with which the traffic flow is 2416 associated can be identified by either a group ID 2417 or group name. The group-to-IP address and 2418 user-to-group mappings are assumed to be provided by 2419 the unified user management system via network."; 2420 leaf id { 2421 type uint32; 2422 description 2423 "The ID of the group."; 2424 } 2425 leaf name { 2426 type string; 2427 description 2428 "The name of the group."; 2429 } 2430 } 2431 } 2433 container geographic-location { 2434 description 2435 "A condition for a location-based connection"; 2436 leaf-list source { 2437 type leafref { 2438 path "/i2nsf-cfi-policy/endpoint-groups/" 2439 + "location-group/name"; 2440 } 2441 description 2442 "This describes the paths to a location's sources."; 2443 } 2444 leaf-list destination { 2445 type leafref { 2446 path "/i2nsf-cfi-policy/endpoint-groups/" 2447 + "location-group/name"; 2448 } 2449 description 2450 "This describes the paths to a location's 2451 destinations."; 2452 } 2453 } 2454 } 2456 container threat-feed { 2457 description 2458 "A condition based on the threat-feed information."; 2459 leaf-list name { 2460 type leafref { 2461 path "/i2nsf-cfi-policy/threat-prevention/" 2462 + "threat-feed-list/name"; 2463 } 2464 description 2465 "This describes the paths to a threat-feed's sources."; 2466 } 2467 } 2468 } 2470 container action { 2471 description 2472 "This is the action container."; 2473 container primary-action { 2474 description 2475 "This represents primary actions (e.g., ingress and 2476 egress actions) to be applied to a condition. 2477 If this is not set, it cannot support the primary 2478 actions."; 2479 leaf action { 2480 type identityref { 2481 base primary-action; 2482 } 2483 description 2484 "Ingress actions: pass, drop, reject, rate-limit, 2485 and mirror. 2486 Egress actions: pass, drop, reject, rate-limit, 2487 mirror, invoke-signaling, tunnel-encapsulation, 2488 forwarding, and transformation.."; 2489 } 2490 } 2491 container secondary-action { 2492 description 2493 "This represents secondary actions (e.g., log and syslog) 2494 to be applied if they are needed. If this is not set, 2495 it cannot support the secondary actions."; 2496 leaf log-action { 2497 type identityref { 2498 base secondary-action; 2499 } 2500 description 2501 "Log action: rule log and session log"; 2502 } 2503 } 2504 } 2505 } 2507 container endpoint-groups { 2508 description 2509 "A logical entity in a business environment, where a security 2510 policy is to be applied."; 2511 list user-group{ 2512 uses user-group; 2513 key "name"; 2514 description 2515 "This represents a user group."; 2516 } 2517 list device-group { 2518 key "name"; 2519 uses device-group; 2520 description 2521 "This represents a device group."; 2522 } 2523 list location-group{ 2524 key "name"; 2525 uses location-group; 2526 description 2527 "This represents a location group."; 2528 } 2529 list url-group { 2530 key "name"; 2531 description 2532 "This describes the list of URL."; 2533 leaf name { 2534 type string; 2535 description 2536 "This is the name of URL group, e.g., SNS sites, 2537 gaming sites, ecommerce sites"; 2538 } 2539 leaf-list url { 2540 type string; 2541 description 2542 "Specifies the URL to be added into the group."; 2543 reference 2544 "RFC 3986: Uniform Resource Identifier (URI): Generic 2545 Syntax"; 2546 } 2547 } 2548 } 2550 container threat-prevention { 2551 description 2552 "The container for threat-prevention."; 2553 list threat-feed-list { 2554 key "name"; 2555 description 2556 "There can be a single or multiple number of 2557 threat-feeds."; 2558 leaf name { 2559 type string; 2560 description 2561 "This represents the name of the threat-feed."; 2562 } 2563 leaf description { 2564 type string; 2565 description 2566 "This represents the descriptions of a threat-feed. The 2567 description should include information, such as type, 2568 threat, method, and file type. Structured Threat 2569 Information Expression (STIX) can be used for 2570 description of a threat [STIX]."; 2571 } 2572 leaf-list signatures { 2573 type identityref { 2574 base signature-type; 2575 } 2576 description 2577 "This contains a list of signatures or hashes of the 2578 threats."; 2580 } 2581 } 2582 list payload-content { 2583 key "name"; 2584 leaf name { 2585 type string; 2586 description 2587 "This represents the name of a packet's payload-content. 2588 It should give an idea of why a specific payload content 2589 is marked as a threat. For example, the name 'backdoor' 2590 indicates the payload content is related to a backdoor 2591 attack."; 2592 } 2593 leaf description { 2594 type string; 2595 description 2596 "This represents the description of a payload. Desecribe 2597 how the payload content is related to a security 2598 attack."; 2599 } 2600 leaf-list content { 2601 type binary; 2602 description 2603 "This represents the string of the payload contents. 2604 This content leaf-list contains the payload of a packet 2605 to analyze a threat. Due to the types of threats, the 2606 type of the content is defined as a binary to 2607 accommodate any kind of a payload type such as HTTP, 2608 HTTPS, and SIP."; 2609 } 2610 description 2611 "This represents a payload-string group."; 2612 } 2613 } 2614 } 2615 } 2616 2618 Figure 18: YANG for Consumer-Facing Interface 2620 8. XML Configuration Examples of High-Level Security Policy Rules 2622 This section shows XML configuration examples of high-level security 2623 policy rules that are delivered from the I2NSF User to the Security 2624 Controller over the Consumer-Facing Interface. The considered use 2625 cases are: Database registration, time-based firewall for web 2626 filtering, VoIP/VoCN security service, and DDoS-attack mitigation. 2628 8.1. Database Registration: Information of Positions and Devices 2629 (Endpoint Group) 2631 If new endpoints are introduced to the network, it is necessary to 2632 first register their data to the database. For example, if new 2633 members are newly introduced in either of three different groups 2634 (i.e., user-group, device-group, and url-group), each of them should 2635 be registered with information such as ip-addresses or protocols used 2636 by devices. 2638 Figure 19 shows an example XML representation of the registered 2639 information for the user-group and device-group with IPv4 addresses 2640 [RFC5737]. 2642 2643 2645 security_policy_for_blocking_sns 2646 2647 2648 employees 2649 2650 192.0.2.11 2651 192.0.2.90 2652 2653 2654 2655 webservers 2656 2657 198.51.100.11 2658 198.51.100.20 2659 2660 http 2661 https 2662 2663 2664 sns-websites 2665 example1.com 2666 example2.com 2667 2668 2669 2671 Figure 19: Registering User-group and Device-group Information 2672 with IPv4 Addresses 2674 Also, Figure 20 shows an example XML representation of the registered 2675 information for the user-group and device-group with IPv6 addresses 2676 [RFC3849]. 2678 2679 2681 security_policy_for_blocking_sns 2682 2683 2684 employees 2685 2686 2001:db8:0:1::11 2687 2001:db8:0:1::90 2688 2689 2690 2691 webservers 2692 2693 2001:db8:0:2::11 2694 2001:db8:0:2::20 2695 2696 http 2697 https 2698 2699 2700 sns-websites 2701 SNS_1 2702 SNS_2 2703 2704 2705 2707 Figure 20: Registering User-group and Device-group Information 2708 with IPv6 Addresses 2710 8.2. Scenario 1: Block SNS Access during Business Hours 2712 The first example scenario is to "block SNS access during office 2713 hours" using a time-based firewall policy. In this scenario, all 2714 users registered as "employees" in the user-group list are unable to 2715 access Social Networking Services (SNS) during the office hours 2716 (weekdays). The XML instance is described below: 2718 2719 2721 security_policy_for_blocking_sns 2722 2723 block_access_to_sns_during_office_hours 2724 2725 2726 employees 2727 2728 2729 sns-websites 2730 2731 2732 2746 2747 2748 2749 2750 drop 2751 2752 2753 2754 2756 Figure 21: An XML Example for Time-based Firewall 2758 Time-based-condition Firewall 2760 1. The policy name is "security_policy_for_blocking_sns". 2762 2. The rule name is "block_access_to_sns_during_office_hours". 2764 3. The Source is "employees". 2766 4. The destination target is "sns-websites". "sns-websites" is the 2767 key which represents the list containing the information, such as 2768 URL, about sns-websites. 2770 5. The action required is to "drop" any attempt to connect to 2771 websites related to Social networking. 2773 8.3. Scenario 2: Block Malicious VoIP/VoCN Packets Coming to a Company 2775 The second example scenario is to "block malicious VoIP/VoCN packets 2776 coming to a company" using a VoIP policy. In this scenario, the 2777 calls comming from from VOIP and/or VoCN sources with VoCN IDs that 2778 are classified as malicious are dropped. The IP addresses of the 2779 employees and malicious VOIP IDs should be blocked are stored in the 2780 database or datastore of the enterprise. Here and the rest of the 2781 cases assume that the security administrators or someone responsible 2782 for the existing and newly generated policies, are not aware of which 2783 and/or how many NSFs are needed to meet the security requirements. 2784 Figure 22 represents the XML document generated from YANG discussed 2785 in previous sections. Once a high-level seucurity policy is created 2786 by a security admin, it is delivered by the Consumer-Facing 2787 Interface, through RESTCONF server, to the security controller. The 2788 XML instance is described below: 2790 2791 2793 2794 security_policy_for_blocking_malicious_voip_packets 2795 2796 2797 Block_malicious_voip_and_vocn_packets 2798 2799 2800 malicious-id 2801 2802 2803 employees 2804 2805 2806 2807 2808 drop 2809 2810 2811 2812 2813 Figure 22: An XML Example for VoIP Security Service 2815 Custom-condition Firewall 2817 1. The policy name is 2818 "security_policy_for_blocking_malicious_voip_packets". 2820 2. The rule name is "Block_malicious_voip_and_vocn_packets". 2822 3. The Source is "malicious-id". This can be a single ID or a list 2823 of IDs, depending on how the ID are stored in the database. The 2824 "malicious-id" is the key so that the security admin can read 2825 every stored malicious VOIP IDs that are named as "malicious-id". 2827 4. The destination target is "employees". "employees" is the key 2828 which represents the list containing information about employees, 2829 such as IP addresses. 2831 5. The action required is "drop" when any incoming packets are from 2832 "malicious-id". 2834 8.4. Scenario 3: Mitigate Flood Attacks on a Company Web Server 2836 The third example scenario is to "Mitigate flood attacks on a company 2837 web server" using a DDoS-attack mitigation policy. Here, the time 2838 information is not set because the service provided by the network 2839 should be maintained at all times. If the packets sent by any 2840 sources are more than the set threshold, then the admin can set the 2841 percentage of the packets to be dropped to safely maintain the 2842 service. In this scenario, the source is set as "any" to block any 2843 sources which send abnormal amount of packets. The destination is 2844 set as "web_server01". Once the rule is set and delivered and 2845 enforced to the nsfs by the securiy controller, the NSFs will monitor 2846 the incoming packet amounts and the destination to act according to 2847 the rule set. The XML instance is described below: 2849 2850 2852 security_policy_for_ddos_attacks 2853 2854 1000_packets_per_second 2855 2856 2857 2858 1000 2859 2860 2861 2862 2863 2864 drop 2865 2866 2867 2868 2870 Figure 23: An XML Example for DDoS-attack Mitigation 2872 DDoS-condition Firewall 2874 1. The policy name is "security_policy_for_ddos_attacks". 2876 2. The rule name is "1000_packets_per_second". 2878 3. The rate limit exists to limit the incoming amount of packets per 2879 second. In this case the rate limit is "1000" packets per 2880 second. This amount depends on the packet receiving capacity of 2881 the server devices. 2883 4. The Source is all sources which send abnormal amount of packets. 2885 5. The action required is to "drop" packet reception is more than 2886 1000 packets per second. 2888 9. XML Configuration Example of a User Group's Access Control for I2NSF 2889 Consumer-Facing Interface 2891 This is an example for creating privileges for a group of users 2892 (i.e., a user group) to access and use the I2NSF Consumer-Facing 2893 Interface to create security policies via the interface. For the 2894 access control of the Consumer-Facing Interface, the NACM module can 2895 be used. Figure 24 shows an XML example the access control of a user 2896 group (named Example-Group) for I2NSF Consumer-Facing Interface A 2897 group called Example-Group can be created and configured with NACM 2898 for the Consumer-Facing Interface. For Example-Group, a rule list 2899 can created with the name of Example-Group-Rules. Example-Group- 2900 Rules has two rules of Example-Group-Rule1 and Example-Group-Rule2 as 2901 follows. For Example-Group-Rule1, the privilege of "Read" is allowed 2902 to Example-Group for the Consumer-Facing Interface. On the other 2903 hand, for Example-Group-Rule2, the privileges of "Create", "Update", 2904 and "Delete" are denied against Example-Group for the Consumer-Facing 2905 Interface. 2907 2908 2909 true 2910 2911 2912 Example-Group 2913 Alice 2914 Bob 2915 Eve 2916 2917 2918 2919 Example-Group-Rules 2920 Example-Group 2921 2922 Example-Group-Rule1 2923 read 2924 ietf-i2nsf-cfi-policy 2925 permit 2926 2927 2928 Example-Group-Rule2 2929 create update delete 2930 ietf-i2nsf-cfi-policy 2931 deny 2932 2933 2934 2935 Figure 24: An XML Example of a User Group's Access Control for 2936 I2NSF Consumer- Facing Interface 2938 The access control for the I2NSF Consumer-Facing Interface is as 2939 follows. 2941 1. The NACM is enabled. 2943 2. As a group name, Example-Group is specified. 2945 3. As members of the group, Alice, Bob, and Eve are specified. 2947 4. As a rule list name, Example-Group-Rules is specified for 2948 managing privileges of Example-Group's members. 2950 5. As the first rule name, Example-Group-Rule1 is specified. This 2951 rule is used to give read privilege to Example-Group's members 2952 for the module of the I2NSF Consumer-Facing Interface. 2954 6. As the second rule name, Example-Group-Rule2 is specified. This 2955 rule is used to deny create, update, and delete privileges 2956 against Example-Group's members for the module of the I2NSF 2957 Consumer-Facing Interface. 2959 10. IANA Considerations 2961 This document requests IANA to register the following URI in the 2962 "IETF XML Registry" [RFC3688]: 2964 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2965 Registrant Contact: The IESG. 2966 XML: N/A; the requested URI is an XML namespace. 2968 This document requests IANA to register the following YANG module in 2969 the "YANG Module Names" registry [RFC7950][RFC8525]: 2971 name: ietf-i2nsf-cfi-policy 2972 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy 2973 prefix: nsfcfi 2974 reference: RFC XXXX 2976 // RFC Ed.: replace XXXX with an actual RFC number and remove 2977 // this note. 2979 11. Security Considerations 2981 The YANG module specified in this document defines a data schema 2982 designed to be accessed through network management protocols such as 2983 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 2984 the secure transport layer, and the required secure transport is 2985 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 2986 and the required secure transport is TLS [RFC8446]. 2988 The Network Configuration Access Control Model (NACM) [RFC8341] 2989 provides a means of restricting access to specific NETCONF or 2990 RESTCONF users to a preconfigured subset of all available NETCONF or 2991 RESTCONF protocol operations and contents. Thus, NACM SHOULD be used 2992 to restrict the NSF registration from unauthorized users. 2994 There are a number of data nodes defined in this YANG module that are 2995 writable, creatable, and deletable (i.e., config true, which is the 2996 default). These data nodes may be considered sensitive or vulnerable 2997 in some network environments. Write operations to these data nodes 2998 could have a negative effect on network and security operations. 2999 These data nodes are collected into a single list node with the 3000 following sensitivity/vulnerability: 3002 * list i2nsf-cfi-policy: Writing to almost any element of this YANG 3003 module would directly impact on the configuration of NSFs, e.g., 3004 completely turning off security monitoring and mitigation 3005 capabilities; altering the scope of this monitoring and 3006 mitigation; creating an overwhelming logging volume to overwhelm 3007 downstream analytics or storage capacity; creating logging 3008 patterns which are confusing; or rendering useless trained 3009 statistics or artificial intelligence models. 3011 Some of the readable data nodes in this YANG module may be considered 3012 sensitive or vulnerable in some network environments. It is thus 3013 important to control read access (e.g., via get, get-config, or 3014 notification) to these data nodes. These are the subtrees and data 3015 nodes with their sensitivity/vulnerability: 3017 * list i2nsf-cfi-policy: The leak of this node to an attacker could 3018 reveal the specific configuration of security controls to an 3019 attacker. An attacker can craft an attack path that avoids 3020 observation or mitigations; one may reveal topology information to 3021 inform additional targets or enable lateral movement; one enables 3022 the construction of an attack path that avoids observation or 3023 mitigations; one provides an indication that the operator has 3024 discovered the attack. This node also holds a list of endpoint 3025 data that is considered private to the users. 3027 12. References 3029 12.1. Normative References 3031 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3032 DOI 10.17487/RFC0768, August 1980, 3033 . 3035 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3036 RFC 792, DOI 10.17487/RFC0792, September 1981, 3037 . 3039 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 3040 RFC 793, DOI 10.17487/RFC0793, September 1981, 3041 . 3043 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 3044 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 3045 1983, . 3047 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 3048 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 3049 . 3051 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 3052 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 3053 . 3055 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3056 Requirement Levels", BCP 14, RFC 2119, 3057 DOI 10.17487/RFC2119, March 1997, 3058 . 3060 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 3061 RFC 2595, DOI 10.17487/RFC2595, June 1999, 3062 . 3064 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3065 A., Peterson, J., Sparks, R., Handley, M., and E. 3066 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3067 DOI 10.17487/RFC3261, June 2002, 3068 . 3070 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3071 DOI 10.17487/RFC3688, January 2004, 3072 . 3074 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3075 Resource Identifier (URI): Generic Syntax", STD 66, 3076 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3077 . 3079 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 3080 Protocol Assigned Numbers", RFC 4250, 3081 DOI 10.17487/RFC4250, January 2006, 3082 . 3084 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3085 Congestion Control Protocol (DCCP)", RFC 4340, 3086 DOI 10.17487/RFC4340, March 2006, 3087 . 3089 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3090 Control Message Protocol (ICMPv6) for the Internet 3091 Protocol Version 6 (IPv6) Specification", STD 89, 3092 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3093 . 3095 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3096 DOI 10.17487/RFC5321, October 2008, 3097 . 3099 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 3100 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 3101 September 2009, . 3103 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3104 and A. Bierman, Ed., "Network Configuration Protocol 3105 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3106 . 3108 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3109 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 3110 . 3112 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3113 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3114 . 3116 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3117 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3118 . 3120 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3121 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3122 . 3124 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3125 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3126 May 2017, . 3128 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 3129 Kumar, "Framework for Interface to Network Security 3130 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 3131 . 3133 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 3134 Boucadair, "PROBE: A Utility for Probing Interfaces", 3135 RFC 8335, DOI 10.17487/RFC8335, February 2018, 3136 . 3138 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3139 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3140 . 3142 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 3143 Access Control Model", STD 91, RFC 8341, 3144 DOI 10.17487/RFC8341, March 2018, 3145 . 3147 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 3148 and R. Wilton, "Network Management Datastore Architecture 3149 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 3150 . 3152 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 3153 Documents Containing YANG Data Models", BCP 216, RFC 8407, 3154 DOI 10.17487/RFC8407, October 2018, 3155 . 3157 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3158 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3159 . 3161 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 3162 and R. Wilton, "YANG Library", RFC 8525, 3163 DOI 10.17487/RFC8525, March 2019, 3164 . 3166 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 3167 Kumari, "A Format for Self-Published IP Geolocation 3168 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 3169 . 3171 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message 3172 Access Protocol (IMAP) - Version 4rev2", RFC 9051, 3173 DOI 10.17487/RFC9051, August 2021, 3174 . 3176 [I-D.ietf-httpbis-http2bis] 3177 Thomson, M. and C. Benfield, "HTTP/2", Work in Progress, 3178 Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January 3179 2022, . 3182 [I-D.ietf-httpbis-messaging] 3183 Fielding, R. T., Nottingham, M., and J. Reschke, 3184 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 3185 httpbis-messaging-19, 12 September 2021, 3186 . 3189 [I-D.ietf-httpbis-semantics] 3190 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 3191 Semantics", Work in Progress, Internet-Draft, draft-ietf- 3192 httpbis-semantics-19, 12 September 2021, 3193 . 3196 [I-D.ietf-i2nsf-capability-data-model] 3197 Hares, S., Jeong, J. (., Kim, J. (., Moskowitz, R., and Q. 3198 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 3199 Internet-Draft, draft-ietf-i2nsf-capability-data-model-30, 3200 13 April 2022, . 3203 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 3204 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 3205 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 3206 Model", Work in Progress, Internet-Draft, draft-ietf- 3207 i2nsf-nsf-monitoring-data-model-18, 19 April 2022, 3208 . 3211 [I-D.ietf-tcpm-rfc793bis] 3212 Eddy, W. M., "Transmission Control Protocol (TCP) 3213 Specification", Work in Progress, Internet-Draft, draft- 3214 ietf-tcpm-rfc793bis-28, 7 March 2022, 3215 . 3218 [I-D.ietf-tsvwg-rfc4960-bis] 3219 Stewart, R. R., Tüxen, M., and K. E. E. Nielsen, "Stream 3220 Control Transmission Protocol", Work in Progress, 3221 Internet-Draft, draft-ietf-tsvwg-rfc4960-bis-19, 5 3222 February 2022, . 3225 12.2. Informative References 3227 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 3228 Address Translator (Traditional NAT)", RFC 3022, 3229 DOI 10.17487/RFC3022, January 2001, 3230 . 3232 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 3233 Information Models and Data Models", RFC 3444, 3234 DOI 10.17487/RFC3444, January 2003, 3235 . 3237 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 3238 Reserved for Documentation", RFC 3849, 3239 DOI 10.17487/RFC3849, July 2004, 3240 . 3242 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 3243 Reserved for Documentation", RFC 5737, 3244 DOI 10.17487/RFC5737, January 2010, 3245 . 3247 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 3248 Multiplexed and Secure Transport", RFC 9000, 3249 DOI 10.17487/RFC9000, May 2021, 3250 . 3252 [IANA-ICMP-Parameters] 3253 Internet Assigned Numbers Authority (IANA), "Assigned 3254 Internet Protocol Numbers", February 2021, 3255 . 3258 [IANA-ICMPv6-Parameters] 3259 Internet Assigned Numbers Authority (IANA), "Internet 3260 Control Message Procotol version 6 (ICMPv6) Parameters", 3261 February 2021, . 3264 [Encyclopedia-Britannica] 3265 Britannica, "Continent", September 2020, 3266 . 3268 [YARA] Alvarez, V., Bengen, H., Metz, J., Buehlmann, S., and W. 3269 Shields, "YARA", YARA 3270 Documents https://yara.readthedocs.io/en/v3.5.0/, August 3271 2020. 3273 [SURICATA] Julien, V. and ., "SURICATA", SURICATA Documents 3274 https://suricata-ids.org/docs/, August 2020. 3276 [SNORT] Roesch, M., Green, C., and B. Caswell, "SNORT", SNORT 3277 Documents https://www.snort.org/#documents, August 2020. 3279 [STIX] Jordan, B., Piazza, R., and T. Darley, "Structured Threat 3280 Information Expression (STIX)", STIX Version 2.1: 3281 Committee Specification 01 https://docs.oasis- 3282 open.org/cti/stix/v2.1/stix-v2.1.pdf, March 2020. 3284 Appendix A. Acknowledgments 3286 This document is a product by the I2NSF Working Group (WG) including 3287 WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This 3288 document took advantage of the review and comments from the following 3289 people: Roman Danyliw, Mahdi F. Dachmehchi, Daeyoung Hyun, Jan 3290 Lindblad (YANG doctor), and Tom Petch. The authors sincerely 3291 appreciate their sincere efforts and kind help. 3293 This work was supported by Institute of Information & Communications 3294 Technology Planning & Evaluation (IITP) grant funded by the Korea 3295 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 3296 Security Intelligence Technology Development for the Customized 3297 Security Service Provisioning). This work was supported in part by 3298 the IITP (2020-0-00395, Standard Development of Blockchain based 3299 Network Management Automation Technology). 3301 Appendix B. Contributors 3303 The following are co-authors of this document: 3305 Patrick Lingga - Department of Electrical and Computer Engineering, 3306 Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, Gyeonggi-do 3307 16419, Republic of Korea, EMail: patricklink@skku.edu 3309 Jinyong Tim Kim - Department of Electronic, Electrical and Computer 3310 Engineering, Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, 3311 Gyeonggi-do 16419, Republic of Korea, EMail: timkim@skku.edu 3313 Hyoungshick Kim - Department of Computer Science and Engineering, 3314 Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, Gyeonggi-do 3315 16419, Republic of Korea, EMail: hyoung@skku.edu 3317 Eunsoo Kim - Department of Electronic, Electrical and Computer 3318 Engineering, Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, 3319 Gyeonggi-do 16419, Republic of Korea, EMail: eskim86@skku.edu 3321 Seungjin Lee - Department of Electronic, Electrical and Computer 3322 Engineering, Sungkyunkwan University, 2066 Seo-ro Jangan-gu, Suwon, 3323 Gyeonggi-do 16419, Republic of Korea, EMail: jine33@skku.edu 3325 Anil Lohiya - Juniper Networks, 1133 Innovation Way, Sunnyvale, CA 3326 94089, US, EMail: alohiya@juniper.net 3328 Dave Qi - Bloomberg, 731 Lexington Avenue, New York, NY 10022, US, 3329 EMail: DQI@bloomberg.net 3331 Nabil Bitar - Nokia, 755 Ravendale Drive, Mountain View, CA 94043, 3332 US, EMail: nabil.bitar@nokia.com 3334 Senad Palislamovic - Nokia, 755 Ravendale Drive, Mountain View, CA 3335 94043, US, EMail: senad.palislamovic@nokia.com 3337 Liang Xia - Huawei, 101 Software Avenue, Nanjing, Jiangsu 210012, 3338 China, EMail: Frank.Xialiang@huawei.com 3340 Appendix C. Changes from draft-ietf-i2nsf-consumer-facing-interface- 3341 dm-18 3343 The following changes are made from draft-ietf-i2nsf-consumer-facing- 3344 interface-dm-18: 3346 * The Abstract is augmented to clarify the role of the Information 3347 Model of the Consumer-Facing Interface. 3349 * This version has been updated to synchronize its contents with the 3350 contents in other I2NSF YANG data model documents. 3352 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 3392 Susan Hares 3393 Huawei 3394 7453 Hickory Hill 3395 Saline, MI 48176 3396 United States of America 3397 Phone: +1-734-604-0332 3398 Email: shares@ndzh.com