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