idnits 2.17.1 draft-ietf-i2nsf-capability-data-model-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 8, 2021) is 1135 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) == Unused Reference: 'RFC2119' is defined on line 2884, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-04 == Outdated reference: A later version (-14) exists of draft-ietf-i2nsf-sdn-ipsec-flow-protection-12 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-13 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-rfc793bis-20 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-tcpm-rfc793bis' == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-09 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6691 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 6973 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 8192 ** Downref: Normative reference to an Informational RFC: RFC 8329 Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group S. Hares, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track J. Jeong, Ed. 5 Expires: September 9, 2021 J. Kim 6 Sungkyunkwan University 7 R. Moskowitz 8 HTT Consulting 9 Q. Lin 10 Huawei 11 March 8, 2021 13 I2NSF Capability YANG Data Model 14 draft-ietf-i2nsf-capability-data-model-16 16 Abstract 18 This document defines an information model and the corresponding YANG 19 data model for the capabilities of various Network Security Functions 20 (NSFs) in the Interface to Network Security Functions (I2NSF) 21 framework to centrally manage the capabilities of the various NSFs. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 9, 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Capability Information Model Design . . . . . . . . . . . . . 4 60 3.1. Design Principles and ECA Policy Model Overview . . . . . 5 61 3.2. Matched Policy Rule . . . . . . . . . . . . . . . . . . . 8 62 3.3. Conflict, Resolution Strategy and Default Action . . . . 8 63 4. Overview of YANG Data Model . . . . . . . . . . . . . . . . . 9 64 5. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12 65 5.1. Network Security Function (NSF) Capabilities . . . . . . 12 66 6. YANG Data Model of I2NSF NSF Capability . . . . . . . . . . . 15 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 68 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 59 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 60 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 60 72 10.2. Informative References . . . . . . . . . . . . . . . . . 65 73 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 67 74 A.1. Example 1: Registration for the Capabilities of a General 75 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 67 76 A.2. Example 2: Registration for the Capabilities of a Time- 77 based Firewall . . . . . . . . . . . . . . . . . . . . . 70 78 A.3. Example 3: Registration for the Capabilities of a Web 79 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 72 80 A.4. Example 4: Registration for the Capabilities of a 81 VoIP/VoLTE Filter . . . . . . . . . . . . . . . . . . . . 72 82 A.5. Example 5: Registration for the Capabilities of a HTTP 83 and HTTPS Flood Mitigator . . . . . . . . . . . . . . . . 73 84 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 74 85 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 75 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 88 1. Introduction 90 As the industry becomes more sophisticated and network devices (e.g., 91 Internet-of-Things (IoT) devices, autonomous vehicles, and 92 smartphones using Voice over IP (VoIP) and Voice over LTE (VoLTE)) 93 require advanced security protection in various scenario, service 94 providers have a lot of problems described in [RFC8192]. To resolve 95 these problems, this document specifies the information and data 96 models of the capabilities of Network Security Functions (NSFs) in a 97 framework of the Interface to Network Security Functions (I2NSF) 98 [RFC8329]. 100 NSFs produced by multiple security vendors provide various security 101 capabilities to customers. Multiple NSFs can be combined together to 102 provide security services over the given network traffic, regardless 103 of whether the NSFs are implemented as physical or virtual functions. 104 Security Capabilities describe the functions that Network Security 105 Functions (NSFs) are available to provide for security policy 106 enforcement purposes. Security Capabilities are independent of the 107 actual security control mechanisms that will implement them. 109 Every NSF SHOULD be described with the set of capabilities it offers. 110 Security Capabilities enable security functionality to be described 111 in a vendor-neutral manner. That is, it is not needed to refer to a 112 specific product or technology when designing the network; rather, 113 the functions characterized by their capabilities are considered. 114 Security Capabilities are a market enabler, providing a way to define 115 customized security protection by unambiguously describing the 116 security features offered by a given NSF. Note that this YANG data 117 model outlines an NSF monitoring YANG data model 118 [I-D.ietf-i2nsf-nsf-monitoring-data-model] and a YANG data model for 119 Software-Defined Networking (SDN)-based IPsec flow protection 120 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 122 This document provides an information model and the corresponding 123 YANG data model [RFC6020][RFC7950] that defines the capabilities of 124 NSFs to centrally manage the capabilities of those security devices. 125 The security devices can register their own capabilities into a 126 Network Operator Management (Mgmt) System (i.e., Security Controller) 127 with this YANG data model through the registration interface 128 [RFC8329]. With the database of the capabilities of those security 129 devices that are maintained centrally, those security devices can be 130 more easily managed [RFC8329]. 132 This YANG data model uses an "Event-Condition-Action" (ECA) policy 133 model that is used as the basis for the design of I2NSF Policy as 134 described in [RFC8329] and Section 3.1. The "ietf-i2nsf-capability" 135 YANG module defined in this document provides the following features: 137 o Definition for time capabilities of network security functions. 139 o Definition for event capabilities of generic network security 140 functions. 142 o Definition for condition capabilities of generic network security 143 functions. 145 o Definition for condition capabilities of advanced network security 146 functions. 148 o Definition for action capabilities of generic network security 149 functions. 151 o Definition for resolution strategy capabilities of generic network 152 security functions. 154 o Definition for default action capabilities of generic network 155 security functions. 157 2. Terminology 159 This document uses the terminology described in [RFC8329]. 161 This document follows the guidelines of [RFC8407], uses the common 162 YANG types defined in [RFC6991], and adopts the Network Management 163 Datastore Architecture (NMDA). The meaning of the symbols in tree 164 diagrams is defined in [RFC8340]. 166 3. Capability Information Model Design 168 A Capability Information Model (CapIM) is a formalization of the 169 functionality that an NSF advertises. This enables the precise 170 specification of what an NSF can do in terms of security policy 171 enforcement, so that computer-based tasks can unambiguously refer to, 172 use, configure, and manage NSFs. Capabilities MUST be defined in a 173 vendor- and technology-independent manner (e.g., regardless of the 174 differences among vendors and individual products). 176 Humans can refer to categories of security controls and understand 177 each other. For instance, network security experts agree on what is 178 meant by the terms "NAT", "filtering", and "VPN concentrator". As a 179 further example, network security experts unequivocally refer to 180 "packet filters" as stateless devices that allow or deny packet 181 forwarding based on various conditions (e.g., source and destination 182 IP addresses, source and destination ports, and IP protocol type 183 fields) [Alshaer]. 185 However, more information is required in case of other devices, like 186 stateful firewalls or application layer filters. These devices 187 filter packets or communications, but there are differences in the 188 packets and communications that they can categorize and the states 189 they maintain. Humans deal with these differences by asking more 190 questions to determine the specific category and functionality of the 191 device. Machines can follow a similar approach, which is commonly 192 referred to as question-answering [Hirschman] [Galitsky]. In this 193 context, the CapIM and the derived data model can provide important 194 and rich information sources. 196 Analogous considerations can be applied for channel protection 197 protocols, where we all understand that they will protect packets by 198 means of symmetric algorithms whose keys could have been negotiated 199 with asymmetric cryptography, but they may work at different layers 200 and support different algorithms and protocols. To ensure 201 protection, these protocols apply integrity, optionally 202 confidentiality, anti-reply protections, and authentication. 204 The CapIM is intended to clarify these ambiguities by providing a 205 formal description of NSF functionality. The set of functions that 206 are advertised MAY be restricted according to the privileges of the 207 user or application that is viewing those functions. I2NSF 208 Capabilities enable unambiguous specification of the security 209 capabilities available in a (virtualized) networking environment, and 210 their automatic processing by means of computer-based techniques. 212 This CapIM includes enabling a security controller in an I2NSF 213 framework [RFC8329] to properly identify and manage NSFs, and allow 214 NSFs to properly declare their functionality through a Developer's 215 Management System (DMS) [RFC8329] , so that they can be used in the 216 correct way. 218 3.1. Design Principles and ECA Policy Model Overview 220 -po This document defines an information model for representing NSF 221 capabilities. Some basic design principles for security capabilities 222 and the systems that manage them are: 224 o Independence: Each security capability SHOULD be an independent 225 function, with minimum overlap or dependency on other 226 capabilities. This enables each security capability to be 227 utilized and assembled together freely. More importantly, changes 228 to one capability SHOULD NOT affect other capabilities. This 229 follows the Single Responsibility Principle [Martin] [OODSRP]. 231 o Abstraction: Each capability MUST be defined in a vendor- 232 independent manner. 234 o Advertisement: A dedicated, well-known interface MUST be used to 235 advertise and register the capabilities of each NSF. This same 236 interface MUST be used by other I2NSF Components to determine what 237 Capabilities are currently available to them. 239 o Execution: Dedicated, well-known interfaces MUST be used to 240 configure and monitor the use of a capability, resepectively. 242 These provide a standardized ability to describe its 243 functionality, and report its processing results, resepectively. 244 These facilitate multi-vendor interoperability. 246 o Automation: The system MUST have the ability to auto-discover, 247 auto-negotiate, and auto-update its security capabilities (i.e., 248 without human intervention). These features are especially useful 249 for the management of a large number of NSFs. They are essential 250 for adding smart services (e.g., refinement, analysis, capability 251 reasoning, and optimization) to the security scheme employed. 252 These features are supported by many design patterns, including 253 the Observer Pattern [OODOP], the Mediator Pattern [OODMP], and a 254 set of Message Exchange Patterns [Hohpe]. 256 o Scalability: The management system SHOULD have the capability to 257 scale up/down or scale in/out. Thus, it can meet various 258 performance requirements derived from changeable network traffic 259 or service requests. In addition, security capabilities that are 260 affected by scalability changes SHOULD support reporting 261 statistics to the security controller to assist its decision on 262 whether it needs to invoke scaling or not. 264 Based on the above principles, this document defines a capability 265 model that enables an NSF to register (and hence advertise) its set 266 of capabilities that other I2NSF Components can use. These 267 capabilities MAY have their access control restricted by a policy; 268 this is out of scope for this document. The set of capabilities 269 provided by a given set of NSFs unambiguously defines the security 270 services offered by the set of NSFs used. The security controller 271 can compare the requirements of users and applications with the set 272 of capabilities that are currently available in order to choose which 273 capabilities of which NSFs are needed to meet those requirements. 274 Note that this choice is independent of vendor, and instead relies 275 specifically on the capabilities (i.e., the description) of the 276 functions provided. 278 Furthermore, when an unknown threat (e.g., zero-day exploits and 279 unknown malware) is reported by an NSF, new capabilities may be 280 created, and/or existing capabilities may be updated (e.g., by 281 updating its signature and algorithm). This results in enhancing the 282 existing NSFs (and/or creating new NSFs) to address the new threats. 283 New capabilities may be sent to and stored in a centralized 284 repository, or stored separately in a vendor's local repository. In 285 either case, a standard interface facilitates this update process. 287 The "Event-Condition-Action" (ECA) policy model in [RFC8329] is used 288 as the basis for the design of the capability model; definitions of 289 all I2NSF policy-related terms are also defined in [RFC8329]. The 290 following three terms define the structure and behavior of an I2NSF 291 imperative policy rule: 293 o Event: An Event is defined as any important occurrence in time of 294 a change in the system being managed, and/or in the environment of 295 the system being managed. When used in the context of I2NSF 296 Policy Rules, it is used to determine whether the condition clause 297 of an I2NSF Policy Rule can be evaluated or not. Examples of an 298 I2NSF Event include time and user actions (e.g., logon, logoff, 299 and actions that violate an ACL). 301 o Condition: A condition is defined as a set of attributes, 302 features, and/or values that are to be compared with a set of 303 known attributes, features, and/or values in order to determine 304 whether or not the set of actions in that (imperative) I2NSF 305 Policy Rule can be executed or not. Examples of I2NSF conditions 306 include matching attributes of a packet or flow, and comparing the 307 internal state of an NSF with a desired state. 309 o Action: An action is used to control and monitor aspects of flow- 310 based NSFs when the event and condition clauses are satisfied. 311 NSFs provide security functions by executing various Actions. 312 Examples of I2NSF actions include providing intrusion detection 313 and/or protection, web and flow filtering, and deep packet 314 inspection for packets and flows. 316 An I2NSF Policy Rule is made up of three Boolean clauses: an Event 317 clause, a Condition clause, and an Action clause. This structure is 318 also called an ECA (Event-Condition-Action) Policy Rule. A Boolean 319 clause is a logical statement that evaluates to either TRUE or FALSE. 320 It may be made up of one or more terms; if more than one term is 321 present, then each term in the Boolean clause is combined using 322 logical connectives (i.e., AND, OR, and NOT). 324 An I2NSF ECA Policy Rule has the following semantics: 326 IF is TRUE 328 IF is TRUE 330 THEN execute [constrained by metadata] 332 END-IF 334 END-IF 336 Technically, the "Policy Rule" is really a container that aggregates 337 the above three clauses, as well as metadata, which describe the 338 characteristics and behaviors of a capability (or an NSF). 339 Aggregating metadata enables a business logic to be used to prescribe 340 a behavior. For example, suppose a particular ECA Policy Rule 341 contains three actions (A1, A2, and A3, in that order). Action A2 342 has a priority of 10; actions A1 and A3 have no priority specified. 343 Then, metadata may be used to restrict the set of actions that can be 344 executed when the event and condition clauses of this ECA Policy Rule 345 are evaluated to be TRUE; two examples are: (1) only the first action 346 (A1) is executed, and then the policy rule returns to its caller, or 347 (2) all actions are executed, starting with the highest priority. 349 The above ECA policy model is very general and easily extensible. 351 3.2. Matched Policy Rule 353 The concept of a "matched" policy rule is defined as one in which its 354 event and condition clauses both evaluate to true. To precisely 355 describe what an NSF can do in terms of security, that a policy rule 356 needs to describe the events that it can catch, the conditions it can 357 evaluate, and the actions that it can enforce. 359 Therefore, the properties to characterize the capabilities of an NSF 360 are as follows: 362 o Ac is the set of Actions currently available from the NSF; 364 o Ec is the set of Events that an NSF can catch. Note that for NSF 365 (e.g., a packet filter) that are not able to react to events, this 366 set will be empty; 368 o Cc is the set of Conditions currently available from the NSF; 370 o EVc defines the set of Condition Clause Evaluation Rules that can 371 be used by the NSF to decide when the Condition Clause is true 372 when the results of the individual Conditions under evaluation are 373 given. 375 3.3. Conflict, Resolution Strategy and Default Action 377 Formally, two I2NSF Policy Rules conflict with each other if: 379 o the Event Clauses of each evaluate to TRUE; 381 o the Condition Clauses of each evaluate to TRUE; 383 o the Action Clauses affect the same object in different ways. 385 For example, if we have two Policy Rules in the same Policy: 387 R1: During 8am-6pm, if traffic is external, then run through FW 389 R2: During 7am-8pm, conduct anti-malware investigation 391 There is no conflict between R1 and R2, since the actions are 392 different. However, consider these two rules: 394 R3: During 8am-6pm, John gets GoldService 396 R4: During 10am-4pm, FTP from all users gets BronzeService 398 R3 and R4 are now in conflict, between the hours of 10am and 4pm, 399 because the actions of R3 and R4 are different and apply to the same 400 user (i.e., John). 402 Conflicts theoretically compromise the correct functioning of devices 403 (as happened for routers several year ago). However, NSFs have been 404 designed to cope with these issues. Since conflicts are originated 405 by simultaneously matching rules, an additional process decides the 406 action to be applied, e.g., among the ones which the matching rule 407 would have enforced. This process is described by means of a 408 resolution strategy for conflicts. 410 On the other hand, it may happen that, if an event is caught, none of 411 the policy rules matches the event. As a simple case, no rules may 412 match a packet arriving at border firewall. In this case, the packet 413 is usually dropped, that is, the firewall has a default behavior to 414 manage the cases that are not covered by specific rules. 416 Therefore, this document introduces another security capability that 417 serves to characterize valid policies for an NSF that solve conflicts 418 with resolution strategies and enforce default actions if no rules 419 match: 421 o RSc is the set of Resolution Strategies that can be used to 422 specify how to resolve conflicts that occur between the actions of 423 the same or different policy rules that are matched and contained 424 in this particular NSF; 426 o Dc defines the notion of a Default action. This action can be 427 either an explicit action or a set of actions. 429 4. Overview of YANG Data Model 431 This section provides an overview of how the YANG data model can be 432 used in the I2NSF framework described in [RFC8329]. Figure 1 shows 433 the capabilities (e.g., firewall and web filter) of NSFs in the I2NSF 434 Framework. As shown in this figure, an NSF Developer's Management 435 System (DMS) can register NSFs and the capabilities that the NSFs can 436 support. To register NSFs in this way, the DMS utilizes this 437 standardized capability YANG data model through the I2NSF 438 Registration Interface [RFC8329]. That is, this Registration 439 Interface uses the YANG module described in this document to describe 440 the capabilities of an NSF that is registered with the Security 441 Controller. With the database of the capabilities of the NSFs that 442 are maintained centrally, the NSFs can be more easily managed, which 443 can resolve many of the problems described in [RFC8192]. 445 In Figure 1, a new NSF at a Developer's Management System has 446 capabilities of Firewall (FW) and Web Filter (WF), which are denoted 447 as (Cap = {FW, WF}), to support Event-Condition-Action (ECA) policy 448 rules where 'E', 'C', and 'A' mean "Event", "Condition", and 449 "Action", respectively. The condition involves IPv4 or IPv6 450 datagrams, and the action includes "Allow" and "Deny" for those 451 datagrams. 453 Note that the NSF-Facing Interface [RFC8329] is used for the Security 454 Controller to configure the security policy rules of generic NSFs 455 (e.g., firewall) and advanced NSFs (e.g., anti-virus and Distributed- 456 Denial-of-Service (DDoS) attack mitigator) with the capabilities of 457 the NSFs registered with the Security Controller. 459 +------------------------------------------------------+ 460 | I2NSF User (e.g., Overlay Network Mgmt, Enterprise | 461 | Network Mgmt, another network domain's mgmt, etc.) | 462 +--------------------+---------------------------------+ 463 I2NSF ^ 464 Consumer-Facing Interface | 465 | 466 v I2NSF 467 +-----------------+------------+ Registration +-------------+ 468 | Network Operator Mgmt System | Interface | Developer's | 469 | (i.e., Security Controller) |<-------------->| Mgmt System | 470 +-----------------+------------+ +-------------+ 471 ^ New NSF 472 | Cap = {FW, WF} 473 I2NSF | E = {} 474 NSF-Facing Interface | C = {IPv4, IPv6} 475 | A = {Allow, Deny} 476 v 477 +---------------+----+------------+-----------------+ 478 | | | | 479 +---+---+ +---+---+ +---+---+ +---+---+ 480 | NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-n | 481 +-------+ +-------+ +-------+ +-------+ 482 NSF-1 NSF-m NSF-1 NSF-n 483 Cap = {FW, WF} Cap = {FW, WF} Cap = {FW, WF} Cap = {FW, WF} 484 E = {} E = {user} E = {dev} E = {time} 485 C = {IPv4} C = {IPv6} C = {IPv4, IPv6} C = {IPv4} 486 A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} 488 Developer's Mgmt System A Developer's Mgmt System B 490 Figure 1: Capabilities of NSFs in I2NSF Framework 492 A use case of an NSF with the capabilities of firewall and web filter 493 is described as follows. 495 o If a network administrator wants to apply security policy rules to 496 block malicious users with firewall and web filter, it is a 497 tremendous burden for a network administrator to apply all of the 498 needed rules to NSFs one by one. This problem can be resolved by 499 managing the capabilities of NSFs as described in this document. 501 o If a network administrator wants to block IPv4 or IPv6 packets 502 from malicious users, the network administrator sends a security 503 policy rule to block the users to the Network Operator Management 504 System (i.e., Security Controller) using the I2NSF Consumer-Facing 505 Interface. 507 o When the Network Operator Management System receives the security 508 policy rule, it automatically sends that security policy rule to 509 appropriate NSFs (i.e., NSF-m in Developer's Management System A 510 and NSF-1 in Developer's Management System B) which can support 511 the capabilities (i.e., IPv6). This lets an I2NSF User not 512 consider which specific NSF(s) will work for the security policy 513 rule. 515 o If NSFs encounter the suspicious IPv4 or IPv6 packets of malicious 516 users, they can filter the packets out according to the configured 517 security policy rule. Therefore, the security policy rule against 518 the malicious users' packets can be automatically applied to 519 appropriate NSFs without human intervention. 521 5. YANG Tree Diagram 523 This section shows a YANG tree diagram of capabilities of network 524 security functions, as defined in the Section 3. 526 5.1. Network Security Function (NSF) Capabilities 528 This section explains a YANG tree diagram of NSF capabilities and its 529 features. Figure 2 shows a YANG tree diagram of NSF capabilities. 530 The NSF capabilities in the tree include time capabilities, event 531 capabilities, condition capabilities, action capabilities, resolution 532 strategy capabilities, and default action capabilities. Those 533 capabilities can be tailored or extended according to a vendor's 534 specific requirements. Refer to the NSF capabilities information 535 model for detailed discussion in Section 3. 537 module: ietf-i2nsf-capability 538 +--rw nsf* [nsf-name] 539 +--rw nsf-name string 540 +--rw time-capabilities* enumeration 541 +--rw event-capabilities 542 | +--rw system-event-capability* identityref 543 | +--rw system-alarm-capability* identityref 544 +--rw condition-capabilities 545 | +--rw generic-nsf-capabilities 546 | | +--rw ipv4-capability* identityref 547 | | +--rw icmp-capability* identityref 548 | | +--rw ipv6-capability* identityref 549 | | +--rw icmpv6-capability* identityref 550 | | +--rw tcp-capability* identityref 551 | | +--rw udp-capability* identityref 552 | | +--rw sctp-capability* identityref 553 | | +--rw dccp-capability* identityref 554 | +--rw advanced-nsf-capabilities 555 | | +--rw anti-virus-capability* identityref 556 | | +--rw anti-ddos-capability* identityref 557 | | +--rw ips-capability* identityref 558 | | +--rw url-capability* identityref 559 | | +--rw voip-volte-capability* identityref 560 | +--rw context-capabilities* identityref 561 +--rw action-capabilities 562 | +--rw ingress-action-capability* identityref 563 | +--rw egress-action-capability* identityref 564 | +--rw log-action-capability* identityref 565 +--rw resolution-strategy-capabilities* identityref 566 +--rw default-action-capabilities* identityref 567 +--rw ipsec-method* identityref 569 Figure 2: YANG Tree Diagram of Capabilities of Network Security 570 Functions 572 Time capabilities are used to specify the capabilities which describe 573 when to execute the I2NSF policy rule. The time capabilities are 574 defined in terms of absolute time and periodic time. The absolute 575 time means the exact time to start or end. The periodic time means 576 repeated time like day, week, or month. 578 Event capabilities are used to specify the capabilities that describe 579 an event that would trigger the evaluation of the condition clause of 580 the I2NSF Policy Rule. The defined event capabilities are system 581 event and system alarm. 583 Condition capabilities are used to specify capabilities of a set of 584 attributes, features, and/or values that are to be compared with a 585 set of known attributes, features, and/or values in order to 586 determine whether a set of actions needs to be executed or not so 587 that an imperative I2NSF policy rule can be executed. In this 588 document, two kinds of condition capabilities are used to classify 589 different capabilities of NSFs such as generic-nsf-capabilities for 590 generic NSFs and advanced-nsf-capabilities for advanced NSFs. First, 591 the generic-nsf-capabilities define the common capabilities of NSFs 592 such as IPv4 capability, IPv6 capability, TCP capability, UDP 593 capability, SCTP capability, DCCP capability, ICMP capability, and 594 ICMPv6 capability. Second, the advanced-nsf-capabilities define 595 advanced capabilities of NSFs such as anti-virus capability, anti- 596 DDoS capability, Intrusion Prevention System (IPS) capability, HTTP 597 capability, and VoIP/VoLTE capability. Note that VoIP and VoLTE are 598 merged into a single capability in this document because VoIP and 599 VoLTE use the Session Initiation Protocol (SIP) [RFC3261] for a call 600 setup. See Section 3.1 for more information about the condition in 601 the ECA policy model. 603 Action capabilities are used to specify the capabilities that 604 describe the control and monitoring aspects of flow-based NSFs when 605 the event and condition clauses are satisfied. The action 606 capabilities are defined as ingress-action capability, egress-action 607 capability, and log-action capability. See Section 3.1 for more 608 information about the action in the ECA policy model. Also, see 609 Section 7.2 (NSF-Facing Flow Security Policy Structure) in [RFC8329] 610 for more information about the ingress and egress actions. In 611 addition, see Section 9.1 (Flow-Based NSF Capability 612 Characterization) in [RFC8329] and Section 7.5 (NSF Logs) in 613 [I-D.ietf-i2nsf-nsf-monitoring-data-model] for more information about 614 logging at NSFs. 616 Resolution strategy capabilities are used to specify the capabilities 617 that describe conflicts that occur between the actions of the same or 618 different policy rules that are matched and contained in this 619 particular NSF. The resolution strategy capabilities are defined as 620 First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized 621 Matching Rule (PMR), Prioritized Matching Rule with Errors (PMRE), 622 and Prioritized Matching Rule with No Errors (PMRN). See Section 3.3 623 for more information about the resolution strategy. 625 Default action capabilities are used to specify the capabilities that 626 describe how to execute I2NSF policy rules when no rule matches a 627 packet. The default action capabilities are defined as pass, drop, 628 alert, and mirror. See Section 3.3 for more information about the 629 default action. 631 IPsec method capabilities are used to specify capabilities of how to 632 support an Internet Key Exchange (IKE) [RFC7296] for the security 633 communication. The default action capabilities are defined as IKE or 634 IKE-less. See [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] for more 635 information about the SDN-based IPsec flow protection in I2NSF. 637 6. YANG Data Model of I2NSF NSF Capability 639 This section introduces a YANG module for NSFs' capabilities, as 640 defined in the Section 3. 642 This YANG module imports from [RFC6991]. It makes references to 644 o [RFC0768] 646 o [RFC0791] 648 o [RFC0792] 650 o [RFC0793] 652 o [RFC2474] 654 o [RFC3168] 656 o [RFC3261] 658 o [RFC4340] 660 o [RFC4443] 662 o [RFC4960] 664 o [RFC5595] 666 o [RFC6335] 668 o [RFC6437] 670 o [RFC6691] 672 o [RFC6864] 674 o [RFC7230] 676 o [RFC7231] 678 o [RFC7296] 679 o [RFC7323] 681 o [RFC8200] 683 o [RFC8329] 685 o [RFC8519] 687 o [RFC8805] 689 o [IANA-Protocol-Numbers] 691 o [I-D.ietf-tcpm-rfc793bis] 693 o [I-D.ietf-tcpm-accurate-ecn] 695 o [I-D.ietf-tsvwg-udp-options] 697 o [I-D.ietf-i2nsf-nsf-monitoring-data-model] 699 o [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] 701 file "ietf-i2nsf-capability@2021-03-08.yang" 702 module ietf-i2nsf-capability { 703 yang-version 1.1; 704 namespace 705 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; 706 prefix 707 nsfcap; 709 organization 710 "IETF I2NSF (Interface to Network Security Functions) 711 Working Group"; 713 contact 714 "WG Web: 715 WG List: 717 Editor: Jaehoon Paul Jeong 718 720 Editor: Jinyong Tim Kim 721 723 Editor: Patrick Lingga 724 726 Editor: Susan Hares 727 "; 729 description 730 "This module is a YANG module for I2NSF Network Security 731 Functions (NSFs)'s Capabilities. 733 Copyright (c) 2021 IETF Trust and the persons identified as 734 authors of the code. All rights reserved. 736 Redistribution and use in source and binary forms, with or 737 without modification, is permitted pursuant to, and subject to 738 the license terms contained in, the Simplified BSD License set 739 forth in Section 4.c of the IETF Trust's Legal Provisions 740 Relating to IETF Documents 741 (https://trustee.ietf.org/license-info). 743 This version of this YANG module is part of RFC XXXX 744 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 745 for full legal notices."; 747 // RFC Ed.: replace XXXX with an actual RFC number and remove 748 // this note. 750 revision "2021-03-08"{ 751 description "Initial revision."; 752 reference 753 "RFC XXXX: I2NSF Capability YANG Data Model"; 755 // RFC Ed.: replace XXXX with an actual RFC number and remove 756 // this note. 757 } 759 /* 760 * Identities 761 */ 763 identity event { 764 description 765 "Base identity for I2NSF events."; 766 reference 767 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 768 Monitoring YANG Data Model - Event"; 770 // RFC Ed.: replace the above draft with an actual RFC in the 771 // YANG module and remove this note. 772 } 774 identity system-event-capability { 775 base event; 776 description 777 "Identity for system event"; 778 reference 779 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 780 Monitoring YANG Data Model - System event"; 781 } 783 identity system-alarm-capability { 784 base event; 785 description 786 "Identity for system alarm"; 787 reference 788 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 789 Monitoring YANG Data Model - System alarm"; 790 } 792 identity access-violation { 793 base system-event-capability; 794 description 795 "Identity for access violation event"; 796 reference 797 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 798 Monitoring YANG Data Model - System event for access 799 violation"; 800 } 802 identity configuration-change { 803 base system-event-capability; 804 description 805 "Identity for configuration change event"; 806 reference 807 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 808 Monitoring YANG Data Model - System event for configuration 809 change"; 810 } 812 identity memory-alarm { 813 base system-alarm-capability; 814 description 815 "Identity for memory alarm. Alarm when memory usage 816 exceeds a threshold."; 817 reference 818 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 819 Monitoring YANG Data Model - System alarm for memory"; 820 } 822 identity cpu-alarm { 823 base system-alarm-capability; 824 description 825 "Identity for CPU alarm. Alarm when CPU usage 826 exceeds a threshold."; 827 reference 828 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 829 Monitoring YANG Data Model - System alarm for CPU"; 830 } 832 identity disk-alarm { 833 base system-alarm-capability; 834 description 835 "Identity for disk alarm. Alarm when disk usage 836 exceeds a threshold."; 837 reference 838 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 839 Monitoring YANG Data Model - System alarm for disk"; 840 } 842 identity hardware-alarm { 843 base system-alarm-capability; 844 description 845 "Identity for hardware alarm. Alarm when a hardware failure 846 or hardware degradation occurs."; 847 reference 848 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 849 Monitoring YANG Data Model - System alarm for hardware"; 850 } 852 identity interface-alarm { 853 base system-alarm-capability; 854 description 855 "Identity for interface alarm. Alarm when interface usage 856 exceeds a threshold."; 857 reference 858 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 859 Monitoring YANG Data Model - System alarm for interface"; 860 } 862 identity condition { 863 description 864 "Base identity for I2NSF conditions"; 865 } 867 identity context-capability { 868 base condition; 869 description 870 "Base identity for context condition capabilities for an NSF. 872 The context contains background information of various 873 entities such as an access control list, application layer 874 filter, target, user, group, and geography."; 875 } 877 identity access-control-list { 878 base context-capability; 879 description 880 "Identity for Access Control List (ACL) condition capability"; 881 reference 882 "RFC 8519: YANG Data Model for Network Access Control Lists 883 (ACLs) - A user-ordered set of rules used to configure the 884 forwarding behavior in an NSF."; 885 } 887 identity application-layer-filter { 888 base context-capability; 889 description 890 "Identity for application-layer-filter condition capability. 891 application-layer-filter capability can examine the contents 892 of a packet (e.g., a URL contained in an HTTP message)."; 893 reference 894 "RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message 895 Syntax and Routing 896 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 897 and Content"; 898 } 900 identity target { 901 base context-capability; 902 description 903 "Identity for target condition capability"; 904 reference 905 "RFC 8519: YANG Data Model for Network Access Control Lists 906 (ACLs) - An access control for a target (e.g., the 907 corresponding IP address) in an NSF."; 908 } 910 identity user { 911 base context-capability; 912 description 913 "Identity for user condition capability. 914 A user (e.g., employee) can be mapped to an IP address of 915 a computing device (e.g., computer, laptop, and virtual 916 machine) which the user is using."; 917 reference 918 "RFC 8519: YANG Data Model for Network Access Control Lists 919 (ACLs) - An access control for a user (e.g., the 920 corresponding IP address) in an NSF."; 921 } 923 identity group { 924 base context-capability; 925 description 926 "Identity for group condition capability. 927 A group (e.g., employees) can be mapped to multiple IP 928 addresses of computing devices (e.g., computers, laptops, 929 and virtual machines) which the group is using."; 930 reference 931 "RFC 8519: YANG Data Model for Network Access Control Lists 932 (ACLs) - An access control for a group (e.g., the 933 corresponding IP addresses) in an NSF."; 934 } 936 identity geography { 937 base context-capability; 938 description 939 "Identity for geography condition capability"; 940 reference 941 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 942 An access control for a geographical location (i.e., 943 geolocation) that has the corresponding IP prefix."; 944 } 946 identity directional-capability { 947 description 948 "Base identity for directional traffic flow capability"; 949 reference 950 "RFC 5101: Specification of the IP Flow Information 951 Export (IPFIX) Protocol for the Exchange of IP 952 Traffic Flow Information - Terminology Unidirectional 953 and Bidirectional Flow"; 954 } 956 identity unidirectional { 957 base directional-capability; 958 description 959 "Identity for unirectional traffic flow."; 960 reference 961 "RFC 5101: Specification of the IP Flow Information 962 Export (IPFIX) Protocol for the Exchange of IP 963 Traffic Flow Information - Terminology Unidirectional 964 Flow"; 965 } 967 identity bidirectional { 968 base directional-capability; 969 description 970 "Identity for bidirectional traffic flow."; 971 reference 972 "RFC 5101: Specification of the IP Flow Information 973 Export (IPFIX) Protocol for the Exchange of IP 974 Traffic Flow Information - Terminology Bidirectional 975 Flow"; 976 } 978 identity ipv4-capability { 979 base condition; 980 description 981 "Base identity for IPv4 condition capability"; 982 reference 983 "RFC 791: Internet Protocol"; 984 } 986 identity exact-ipv4-header-length { 987 base ipv4-capability; 988 description 989 "Identity for exact-match IPv4 header-length 990 condition capability"; 991 reference 992 "RFC 791: Internet Protocol - Header Length"; 993 } 995 identity range-ipv4-header-length { 996 base ipv4-capability; 997 description 998 "Identity for range-match IPv4 header-length 999 condition capability"; 1000 reference 1001 "RFC 791: Internet Protocol - Header Length"; 1002 } 1004 identity ipv4-tos-dscp { 1005 base ipv4-capability; 1006 description 1007 "Identity for IPv4 Type-Of-Service (TOS) 1008 Differentiated Services Codepoint (DSCP) 1009 condition capability"; 1010 reference 1011 "RFC 791: Internet Protocol - Type of Service 1012 RFC 2474: Definition of the Differentiated 1013 Services Field (DS Field) in the IPv4 and 1014 IPv6 Headers"; 1015 } 1016 identity exact-ipv4-total-length { 1017 base ipv4-capability; 1018 description 1019 "Identity for exact-match IPv4 total length 1020 condition capability"; 1021 reference 1022 "RFC 791: Internet Protocol - Total Length"; 1023 } 1025 identity range-ipv4-total-length { 1026 base ipv4-capability; 1027 description 1028 "Identity for range-match IPv4 total length 1029 condition capability"; 1030 reference 1031 "RFC 791: Internet Protocol - Total Length"; 1032 } 1034 identity ipv4-id { 1035 base ipv4-capability; 1036 description 1037 "Identity for IPv4 identification condition capability. 1038 IPv4 ID field is used for fragmentation and reassembly."; 1039 reference 1040 "RFC 791: Internet Protocol - Identification 1041 RFC 6864: Updated Specification of the IPv4 ID Field - 1042 Fragmentation and Reassembly"; 1043 } 1045 identity ipv4-fragment-flags { 1046 base ipv4-capability; 1047 description 1048 "Identity for IPv4 fragment flags condition capability"; 1049 reference 1050 "RFC 791: Internet Protocol - Fragmentation Flags"; 1051 } 1053 identity exact-ipv4-fragment-offset { 1054 base ipv4-capability; 1055 description 1056 "Identity for exact-match IPv4 fragment offset 1057 condition capability"; 1058 reference 1059 "RFC 791: Internet Protocol - Fragmentation Offset"; 1060 } 1062 identity range-ipv4-fragment-offset { 1063 base ipv4-capability; 1064 description 1065 "Identity for range-match IPv4 fragment offset 1066 condition capability"; 1067 reference 1068 "RFC 791: Internet Protocol - Fragmentation Offset"; 1069 } 1071 identity exact-ipv4-ttl { 1072 base ipv4-capability; 1073 description 1074 "Identity for exact-match IPv4 Time-To-Live (TTL) 1075 condition capability"; 1076 reference 1077 "RFC 791: Internet Protocol - Time To Live (TTL)"; 1078 } 1080 identity range-ipv4-ttl { 1081 base ipv4-capability; 1082 description 1083 "Identity for range-match IPv4 Time-To-Live (TTL) 1084 condition capability"; 1085 reference 1086 "RFC 791: Internet Protocol - Time To Live (TTL)"; 1087 } 1089 identity ipv4-protocol { 1090 base ipv4-capability; 1091 description 1092 "Identity for IPv4 protocol condition capability"; 1093 reference 1094 "IANA Website: Assigned Internet Protocol Numbers 1095 - Protocol Number for IPv4 1096 RFC 791: Internet Protocol - Protocol"; 1097 } 1099 identity prefix-ipv4-address-flow-direction { 1100 base ipv4-capability; 1101 description 1102 "Identity for flow direction of prefix-match IPv4 source 1103 or destination address(es) condition capability where flow 1104 direction is either unidirectional or bidirectional"; 1105 reference 1106 "RFC 4340: Datagram Congestion Control Protocol"; 1107 } 1109 identity prefix-ipv4-address { 1110 base ipv4-capability; 1111 description 1112 "Identity for prefix-match IPv4 source or destination 1113 address condition capability. The addresses are specified 1114 by a pair of prefix and prefix length."; 1115 reference 1116 "RFC 791: Internet Protocol - Address"; 1117 } 1119 identity prefix-ipv4-src-address { 1120 base ipv4-capability; 1121 description 1122 "Identity for prefix-match IPv4 source address condition 1123 capability. The addresses are specified by a pair of 1124 prefix and prefix length."; 1125 reference 1126 "RFC 791: Internet Protocol - Address"; 1127 } 1129 identity prefix-ipv4-dst-address { 1130 base ipv4-capability; 1131 description 1132 "Identity for prefix-match IPv4 destination address 1133 condition capability. The addresses are specified by a 1134 pair of prefix and prefix length."; 1135 reference 1136 "RFC 791: Internet Protocol - Address"; 1137 } 1139 identity range-ipv4-address-flow-direction { 1140 base ipv4-capability; 1141 description 1142 "Identity for flow direction of range-match IPv4 source 1143 or destination address(es) condition capability where flow 1144 direction is either unidirectional or bidirectional"; 1145 reference 1146 "RFC 4340: Datagram Congestion Control Protocol"; 1147 } 1149 identity range-ipv4-address { 1150 base ipv4-capability; 1151 description 1152 "Identity for range-match IPv4 source or destination 1153 address condition capability. The addresses are specified 1154 by a pair of a start address and an end address."; 1155 reference 1156 "RFC 791: Internet Protocol - Address"; 1157 } 1159 identity range-ipv4-src-address { 1160 base ipv4-capability; 1161 description 1162 "Identity for range-match IPv4 source address condition 1163 capability. The addresses are specified by a pair of 1164 by a start address and an end address."; 1166 reference 1167 "RFC 791: Internet Protocol - Address"; 1168 } 1170 identity range-ipv4-dst-address { 1171 base ipv4-capability; 1172 description 1173 "Identity for range-match IPv4 destination address 1174 condition capability. The addresses are specified by 1175 a pair of by a start address and an end address."; 1176 reference 1177 "RFC 791: Internet Protocol - Address"; 1178 } 1180 identity ipv4-ip-opts { 1181 base ipv4-capability; 1182 description 1183 "Identity for IPv4 option condition capability"; 1184 reference 1185 "RFC 791: Internet Protocol - Options"; 1186 } 1188 identity ipv4-geo-ip { 1189 base ipv4-capability; 1190 description 1191 "Identity for IPv4 geography condition capability"; 1192 reference 1193 "RFC 8805: Self-published IP Geolocation Data - An 1194 access control for a geographical location i.e., 1195 geolocation (e.g., the corresponding IP address)."; 1196 } 1198 identity ipv6-capability { 1199 base condition; 1200 description 1201 "Base identity for IPv6 condition capabilities"; 1202 reference 1203 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1204 Specification"; 1205 } 1207 identity ipv6-traffic-class-dscp { 1208 base ipv6-capability; 1209 description 1210 "Identity for IPv6 traffic classes 1211 Differentiated Services Codepoint (DSCP) 1212 condition capability"; 1213 reference 1214 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1215 Specification - Traffic Class 1216 RFC 2474: Definition of the Differentiated 1217 Services Field (DS Field) in the IPv4 and 1218 IPv6 Headers."; 1219 } 1221 identity exact-ipv6-flow-label { 1222 base ipv6-capability; 1223 description 1224 "Identity for exact-match IPv6 flow label 1225 condition capability"; 1226 reference 1227 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1228 Specification - Flow Label 1229 RFC 6437: IPv6 Flow Label Specification"; 1230 } 1232 identity range-ipv6-flow-label { 1233 base ipv6-capability; 1234 description 1235 "Identity for range-match IPv6 flow label 1236 condition capability"; 1237 reference 1238 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1239 Specification - Flow Label 1240 RFC 6437: IPv6 Flow Label Specification"; 1241 } 1243 identity exact-ipv6-payload-length { 1244 base ipv6-capability; 1245 description 1246 "Identity for exact-match IPv6 payload length 1247 condition capability"; 1248 reference 1249 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1250 Specification - Payload Length"; 1251 } 1253 identity range-ipv6-payload-length { 1254 base ipv6-capability; 1255 description 1256 "Identity for range-match IPv6 payload length 1257 condition capability"; 1258 reference 1259 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1260 Specification - Payload Length"; 1261 } 1263 identity ipv6-next-header { 1264 base ipv6-capability; 1265 description 1266 "Identity for IPv6 next header condition capability"; 1267 reference 1268 "IANA Website: Assigned Internet Protocol Numbers 1269 - Protocol Number for IPv6 1270 RFC 8200: Internet Protocol, Version 6 (IPv6) 1271 Specification - Next Header"; 1272 } 1274 identity exact-ipv6-hop-limit { 1275 base ipv6-capability; 1276 description 1277 "Identity for exact-match IPv6 hop limit condition 1278 capability"; 1279 reference 1280 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1281 Specification - Hop Limit"; 1282 } 1284 identity range-ipv6-hop-limit { 1285 base ipv6-capability; 1286 description 1287 "Identity for range-match IPv6 hop limit condition 1288 capability"; 1289 reference 1290 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1291 Specification - Hop Limit"; 1292 } 1294 identity prefix-ipv6-address-flow-direction { 1295 base ipv6-capability; 1296 description 1297 "Identity for flow direction of prefix-match IPv6 source 1298 or destination address(es) condition capability where flow 1299 direction is either unidirectional or bidirectional"; 1300 reference 1301 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1302 Specification - Address"; 1303 } 1304 identity prefix-ipv6-address { 1305 base ipv6-capability; 1306 description 1307 "Identity for prefix-match IPv6 address condition 1308 capability. The addresses are specified by a pair 1309 of prefix and prefix length."; 1310 reference 1311 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1312 Specification - Address"; 1313 } 1315 identity prefix-ipv6-src-address { 1316 base ipv6-capability; 1317 description 1318 "Identity for prefix-match IPv6 source address condition 1319 capability. The addresses are specified by a pair of 1320 prefix and prefix length."; 1321 reference 1322 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1323 Specification - Address"; 1324 } 1326 identity prefix-ipv6-dst-address { 1327 base ipv6-capability; 1328 description 1329 "Identity for prefix-match IPv6 destination address 1330 condition capability. The addresses are specified by a 1331 pair of prefix and prefix length."; 1332 reference 1333 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1334 Specification - Address"; 1335 } 1337 identity range-ipv6-address-flow-direction { 1338 base ipv6-capability; 1339 description 1340 "Identity for flow direction of prefix-match IPv6 source 1341 or destination address(es) condition capability where flow 1342 direction is either unidirectional or bidirectional"; 1343 reference 1344 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1345 Specification - Address"; 1346 } 1348 identity range-ipv6-address { 1349 base ipv6-capability; 1350 description 1351 "Identity for range-match IPv6 source or destination 1352 address condition capability. The addresses are 1353 specified by a pair of a start address and an end 1354 address."; 1355 reference 1356 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1357 Specification - Address"; 1358 } 1360 identity range-ipv6-src-address { 1361 base ipv6-capability; 1362 description 1363 "Identity for range-match IPv6 source address 1364 condition capability. The addresses are specified 1365 by a pair of a start address and an end address."; 1366 reference 1367 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1368 Specification - Address"; 1369 } 1371 identity range-ipv6-dst-address { 1372 base ipv6-capability; 1373 description 1374 "Identity for range-match IPv6 destination address 1375 condition capability. The addresses are specified 1376 by a pair of a start address and an end address."; 1377 reference 1378 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1379 Specification - Address"; 1380 } 1382 identity ipv6-header-order { 1383 base ipv6-capability; 1384 description 1385 "Identity for IPv6 extension header order condition 1386 capability"; 1387 reference 1388 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1389 Specification - Extension Header Order"; 1390 } 1392 identity ipv6-options { 1393 base ipv6-capability; 1394 description 1395 "Identity for IPv6 options type condition 1396 capability"; 1397 reference 1398 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1399 Specification - Options"; 1401 } 1403 identity ipv6-hop-by-hop { 1404 base ipv6-capability; 1405 description 1406 "Identity for IPv6 hop by hop options header 1407 condition capability"; 1408 reference 1409 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1410 Specification - Options"; 1411 } 1413 identity ipv6-routing-header { 1414 base ipv6-capability; 1415 description 1416 "Identity for IPv6 routing header condition 1417 capability"; 1418 reference 1419 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1420 Specification - Routing Header"; 1421 } 1423 identity ipv6-fragment-header { 1424 base ipv6-capability; 1425 description 1426 "Identity for IPv6 fragment header condition 1427 capability"; 1428 reference 1429 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1430 Specification - Fragment Header"; 1431 } 1433 identity ipv6-destination-options { 1434 base ipv6-capability; 1435 description 1436 "Identity for IPv6 destination options condition 1437 capability"; 1438 reference 1439 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1440 Specification - Destination Options"; 1441 } 1443 identity ipv6-geo-ip { 1444 base ipv6-capability; 1445 description 1446 "Identity for IPv4 geography condition capability"; 1447 reference 1448 "RFC 8805: Self-published IP Geolocation Data - An 1449 access control for a geographical location i.e., 1450 geolocation (e.g., the corresponding IP address)."; 1451 } 1453 identity tcp-capability { 1454 base condition; 1455 description 1456 "Base identity for TCP condition capabilities"; 1457 reference 1458 "RFC 793: Transmission Control Protocol 1459 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1460 (TCP) Specification"; 1461 } 1463 identity exact-tcp-port-num-flow-direction { 1464 base tcp-capability; 1465 description 1466 "Identity for flow direction of exact-match TCP source or 1467 destination port number condition capability where flow 1468 direction is either unidirectional or bidirectional"; 1469 reference 1470 "RFC 793: Transmission Control Protocol - Port Number 1471 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1472 (TCP) Specification"; 1473 } 1475 identity exact-tcp-port-num { 1476 base tcp-capability; 1477 description 1478 "Identity for exact-match TCP source or destination port 1479 number condition capability"; 1480 reference 1481 "RFC 793: Transmission Control Protocol - Port Number 1482 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1483 (TCP) Specification"; 1484 } 1486 identity exact-tcp-src-port-num { 1487 base tcp-capability; 1488 description 1489 "Identity for exact-match TCP source port 1490 number condition capability"; 1491 reference 1492 "RFC 793: Transmission Control Protocol - Port Number 1493 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1494 (TCP) Specification"; 1495 } 1496 identity exact-tcp-dst-port-num { 1497 base tcp-capability; 1498 description 1499 "Identity for exact-match TCP destination port 1500 number condition capability"; 1501 reference 1502 "RFC 793: Transmission Control Protocol - Port Number 1503 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1504 (TCP) Specification"; 1505 } 1507 identity range-tcp-port-num-flow-direction { 1508 base tcp-capability; 1509 description 1510 "Identity for flow direction of range-match TCP source or 1511 destination port number condition capability where flow 1512 direction is either unidirectional or bidirectional"; 1513 reference 1514 "RFC 793: Transmission Control Protocol - Port Number 1515 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1516 (TCP) Specification"; 1517 } 1519 identity range-tcp-port-num { 1520 base tcp-capability; 1521 description 1522 "Identity for range-match TCP source or destination port 1523 number condition capability. The port numbers are 1524 specified by a pair of a start port number and an end 1525 port number."; 1527 reference 1528 "RFC 793: Transmission Control Protocol - Port Number 1529 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1530 (TCP) Specification"; 1531 } 1533 identity range-tcp-src-port-num { 1534 base tcp-capability; 1535 description 1536 "Identity for range-match TCP source port number 1537 condition capability. The port numbers are specified by 1538 a pair of a start port number and an end port number."; 1539 reference 1540 "RFC 793: Transmission Control Protocol - Port Number 1541 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1542 (TCP) Specification"; 1543 } 1544 identity range-tcp-dst-port-num { 1545 base tcp-capability; 1546 description 1547 "Identity for range-match TCP destination port number 1548 condition capability. The port numbers are specified by 1549 a pair of a start port number and an end port number."; 1550 reference 1551 "RFC 793: Transmission Control Protocol - Port Number 1552 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1553 (TCP) Specification"; 1554 } 1556 identity tcp-flags { 1557 base tcp-capability; 1558 description 1559 "Identity for TCP control bits (flags) condition capability"; 1560 reference 1561 "RFC 793: Transmission Control Protocol - Flags 1562 RFC 3168: The Addition of Explicit Congestion Notification 1563 (ECN) to IP - TCP Header Flags 1564 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1565 (TCP) Specification 1566 draft-ietf-tcpm-accurate-ecn: More Accurate ECN Feedback 1567 in TCP"; 1568 } 1570 identity tcp-options { 1571 base tcp-capability; 1572 description 1573 "Identity for TCP options condition capability"; 1574 reference 1575 "RFC 793: Transmission Control Protocol - Options 1576 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1577 (TCP) Specification 1578 RFC 6691: TCP Options and Maximum Segment Size 1579 RFC 7323: TCP Extensions for High Performance"; 1580 } 1582 identity udp-capability { 1583 base condition; 1584 description 1585 "Base identity for UDP condition capabilities"; 1586 reference 1587 "RFC 768: User Datagram Protocol"; 1588 } 1590 identity exact-udp-port-num-flow-direction { 1591 base udp-capability; 1592 description 1593 "Identity for flow direction of exact-match UDP source or 1594 destination port number condition capability where flow 1595 direction is either unidirectional or bidirectional"; 1596 reference 1597 "RFC 768: User Datagram Protocol - Port Number"; 1598 } 1600 identity exact-udp-port-num { 1601 base udp-capability; 1602 description 1603 "Identity for exact-match UDP source or destination 1604 port number condition capability"; 1605 reference 1606 "RFC 768: User Datagram Protocol - Port Number"; 1607 } 1609 identity exact-udp-src-port-num { 1610 base udp-capability; 1611 description 1612 "Identity for exact-match UDP source port number 1613 condition capability"; 1614 reference 1615 "RFC 768: User Datagram Protocol - Port Number"; 1616 } 1618 identity exact-udp-dst-port-num { 1619 base udp-capability; 1620 description 1621 "Identity for exact-match UDP destination port number 1622 condition capability"; 1623 reference 1624 "RFC 768: User Datagram Protocol - Port Number"; 1625 } 1627 identity range-udp-port-num-flow-direction { 1628 base udp-capability; 1629 description 1630 "Identity for flow direction of range-match UDP source or 1631 destination port number condition capability where flow 1632 direction is either unidirectional or bidirectional"; 1633 reference 1634 "RFC 768: User Datagram Protocol - Port Number"; 1635 } 1637 identity range-udp-port-num { 1638 base udp-capability; 1639 description 1640 "Identity for range-match UDP source or destination 1641 port number condition capability. The port numbers 1642 are specified by a pair of a start port number and 1643 an end port number."; 1644 reference 1645 "RFC 768: User Datagram Protocol - Port Number"; 1646 } 1648 identity range-udp-src-port-num { 1649 base udp-capability; 1650 description 1651 "Identity for range-match UDP source port number 1652 condition capability. The port numbers are specified by 1653 a pair of a start port number and an end port number."; 1654 reference 1655 "RFC 768: User Datagram Protocol - Port Number"; 1656 } 1658 identity range-udp-dst-port-num { 1659 base udp-capability; 1660 description 1661 "Identity for range-match TCP destination port number 1662 condition capability. The port numbers are specified by 1663 a pair of a start port number and an end port number."; 1664 reference 1665 "RFC 768: User Datagram Protocol - Port Number"; 1666 } 1668 identity exact-udp-total-length { 1669 base udp-capability; 1670 description 1671 "Identity for exact-match UDP total-length condition capability. 1672 The UDP total length can be smaller than the IP transport 1673 length for UDP transport layer options."; 1674 reference 1675 "RFC 768: User Datagram Protocol - Total Length 1676 draft-ietf-tsvwg-udp-options: Transport Options for UDP"; 1677 } 1679 identity range-udp-total-length { 1680 base udp-capability; 1681 description 1682 "Identity for range-match UDP total-length condition capability. 1683 The UDP total length can be smaller than the IP transport 1684 length for UDP transport layer options."; 1685 reference 1686 "RFC 768: User Datagram Protocol - Total Length 1687 draft-ietf-tsvwg-udp-options: Transport Options for UDP"; 1689 } 1691 identity sctp-capability { 1692 description 1693 "Identity for SCTP condition capabilities"; 1694 reference 1695 "RFC 4960: Stream Control Transmission Protocol"; 1696 } 1698 identity exact-sctp-port-num-flow-direction { 1699 base sctp-capability; 1700 description 1701 "Identity for flow direction of range-match SCTP source or 1702 destination port number condition capability where flow 1703 direction is either unidirectional or bidirectional"; 1704 reference 1705 "RFC 4960: Stream Control Transmission Protocol - Port Number"; 1706 } 1708 identity exact-sctp-port-num { 1709 base sctp-capability; 1710 description 1711 "Identity for exact-match SCTP source or destination 1712 port number condition capability"; 1713 reference 1714 "RFC 4960: Stream Control Transmission Protocol - Port Number"; 1715 } 1717 identity exact-sctp-src-port-num { 1718 base sctp-capability; 1719 description 1720 "Identity for exact-match SCTP source port number 1721 condition capability"; 1722 reference 1723 "RFC 4960: Stream Control Transmission Protocol - Port Number"; 1724 } 1726 identity exact-sctp-dst-port-num { 1727 base sctp-capability; 1728 description 1729 "Identity for exact-match SCTP destination port number 1730 condition capability"; 1731 reference 1732 "RFC 4960: Stream Control Transmission Protocol - Port Number"; 1733 } 1735 identity range-sctp-port-num-flow-direction { 1736 base sctp-capability; 1737 description 1738 "Identity for flow direction of range-match SCTP source or 1739 destination port number condition capability where flow 1740 direction is either unidirectional or bidirectional"; 1741 reference 1742 "RFC 4960: Stream Control Transmission Protocol - Port Number"; 1743 } 1745 identity range-sctp-port-num { 1746 base sctp-capability; 1747 description 1748 "Identity for range-match SCTP source or destination 1749 port number condition capability. The port numbers are 1750 specified by a pair of a start port number and an end 1751 port number."; 1752 reference 1753 "RFC 4960: Stream Control Transmission Protocol - Port Number"; 1754 } 1756 identity range-sctp-src-port-num { 1757 base sctp-capability; 1758 description 1759 "Identity for range-match SCTP source port number 1760 condition capability. The port numbers are specified by 1761 a pair of a start port number and an end port number."; 1762 reference 1763 "RFC 4960: Stream Control Transmission Protocol - Port Number"; 1764 } 1766 identity range-sctp-dst-port-num { 1767 base sctp-capability; 1768 description 1769 "Identity for range-match SCTP destination port number 1770 condition capability. The port numbers are specified by 1771 a pair of a start port number and an end port number."; 1772 reference 1773 "RFC 4960: Stream Control Transmission Protocol - Port Number"; 1774 } 1776 identity sctp-verification-tag { 1777 base sctp-capability; 1778 description 1779 "Identity for range-match SCTP verification tag condition 1780 capability"; 1781 reference 1782 "RFC 4960: Stream Control Transmission Protocol - Verification Tag"; 1783 } 1784 identity sctp-chunk-type { 1785 base sctp-capability; 1786 description 1787 "Identity for SCTP chunk type condition capability"; 1788 reference 1789 "RFC 4960: Stream Control Transmission Protocol - Chunk Type"; 1790 } 1792 identity dccp-capability { 1793 description 1794 "Identity for DCCP condition capabilities"; 1795 reference 1796 "RFC 4340: Datagram Congestion Control Protocol"; 1797 } 1799 identity exact-dccp-port-num-flow-direction { 1800 base dccp-capability; 1801 description 1802 "Identity for flow direction of exact-match DCCP source or 1803 destination port number condition capability where flow 1804 direction is either unidirectional or bidirectional"; 1805 reference 1806 "RFC 4340: Datagram Congestion Control Protocol"; 1807 } 1809 identity exact-dccp-port-num { 1810 base dccp-capability; 1811 description 1812 "Identity for exact-match DCCP source or destination 1813 port number condition capability"; 1814 reference 1815 "RFC 4340: Datagram Congestion Control Protocol"; 1816 } 1818 identity exact-dccp-src-port-num { 1819 base dccp-capability; 1820 description 1821 "Identity for exact-match DCCP source port number 1822 condition capability"; 1823 reference 1824 "RFC 4340: Datagram Congestion Control Protocol"; 1825 } 1827 identity exact-dccp-dst-port-num { 1828 base dccp-capability; 1829 description 1830 "Identity for exact-match DCCP destination port number 1831 condition capability"; 1833 reference 1834 "RFC 4340: Datagram Congestion Control Protocol"; 1835 } 1837 identity range-dccp-port-num-flow-direction { 1838 base dccp-capability; 1839 description 1840 "Identity for flow direction of range-match DCCP source or 1841 destination port number condition capability where flow 1842 direction is either unidirectional or bidirectional"; 1843 reference 1844 "RFC 4340: Datagram Congestion Control Protocol"; 1845 } 1847 identity range-dccp-port-num { 1848 base dccp-capability; 1849 description 1850 "Identity for range-match DCCP source or destination 1851 port number condition capability. The port numbers are 1852 specified by a pair of a start port number and an end 1853 port number."; 1854 reference 1855 "RFC 4340: Datagram Congestion Control Protocol"; 1856 } 1858 identity range-dccp-src-port-num { 1859 base dccp-capability; 1860 description 1861 "Identity for range-match DCCP source port number 1862 condition capability. The port numbers are specified by 1863 a pair of a start port number and an end port number."; 1864 reference 1865 "RFC 4340: Datagram Congestion Control Protocol"; 1866 } 1868 identity range-dccp-dst-port-num { 1869 base dccp-capability; 1870 description 1871 "Identity for range-match DCCP source port number 1872 condition capability. The port numbers are specified by 1873 a pair of a start port number and an end port number."; 1874 reference 1875 "RFC 4340: Datagram Congestion Control Protocol"; 1876 } 1878 identity dccp-service-code { 1879 base dccp-capability; 1880 description 1881 "Identity for DCCP Service Code condition capabilitiy"; 1882 reference 1883 "RFC 4340: Datagram Congestion Control Protocol 1884 RFC 5595: The Datagram Congestion Control Protocol (DCCP) 1885 Service Codes 1886 RFC 6335: Internet Assigned Numbers Authority (IANA) 1887 Procedures for the Management of the Service Name and 1888 Transport Protocol Port Number Registry - Service Code"; 1889 } 1891 identity icmp-capability { 1892 base condition; 1893 description 1894 "Base identity for ICMP condition capability"; 1895 reference 1896 "RFC 792: Internet Control Message Protocol"; 1897 } 1899 identity icmp-type { 1900 base icmp-capability; 1901 description 1902 "Identity for ICMP type condition capability"; 1903 reference 1904 "RFC 792: Internet Control Message Protocol"; 1905 } 1907 identity icmp-code { 1908 base icmp-capability; 1909 description 1910 "Identity for ICMP code condition capability"; 1911 reference 1912 "RFC 792: Internet Control Message Protocol"; 1913 } 1915 identity icmpv6-capability { 1916 base condition; 1917 description 1918 "Base identity for ICMPv6 condition capability"; 1919 reference 1920 "RFC 4443: Internet Control Message Protocol (ICMPv6) 1921 for the Internet Protocol Version 6 (IPv6) Specification 1922 - ICMPv6"; 1923 } 1925 identity icmpv6-type { 1926 base icmpv6-capability; 1927 description 1928 "Identity for ICMPv6 type condition capability"; 1930 reference 1931 "RFC 4443: Internet Control Message Protocol (ICMPv6) 1932 for the Internet Protocol Version 6 (IPv6) Specification 1933 - ICMPv6"; 1934 } 1936 identity icmpv6-code { 1937 base icmpv6-capability; 1938 description 1939 "Identity for ICMPv6 code condition capability"; 1940 reference 1941 "RFC 4443: Internet Control Message Protocol (ICMPv6) 1942 for the Internet Protocol Version 6 (IPv6) Specification 1943 - ICMPv6"; 1944 } 1946 identity url-capability { 1947 base condition; 1948 description 1949 "Base identity for URL condition capability"; 1950 } 1952 identity pre-defined { 1953 base url-capability; 1954 description 1955 "Identity for pre-defined URL Database condition capability. 1956 where URL database is a public database for URL filtering."; 1957 } 1959 identity user-defined { 1960 base url-capability; 1961 description 1962 "Identity for user-defined URL Database condition capability. 1963 that allows a users manual addition of URLs for URL 1964 filtering."; 1965 } 1967 identity log-action-capability { 1968 description 1969 "Base identity for log-action capability"; 1970 } 1972 identity rule-log { 1973 base log-action-capability; 1974 description 1975 "Identity for rule log log-action capability. 1976 Log the received packet based on the rule"; 1977 } 1978 identity session-log { 1979 base log-action-capability; 1980 description 1981 "Identity for session log log-action capability. 1982 Log the received packet based on the session."; 1983 } 1985 identity ingress-action-capability { 1986 description 1987 "Base identity for ingress-action capability"; 1988 reference 1989 "RFC 8329: Framework for Interface to Network Security 1990 Functions - Ingress action"; 1991 } 1993 identity egress-action-capability { 1994 description 1995 "Base identity for egress-action capability"; 1996 reference 1997 "RFC 8329: Framework for Interface to Network Security 1998 Functions - Egress action"; 1999 } 2001 identity default-action-capability { 2002 description 2003 "Base identity for default-action capability"; 2004 } 2006 identity pass { 2007 base ingress-action-capability; 2008 base egress-action-capability; 2009 base default-action-capability; 2010 description 2011 "Identity for pass action capability"; 2012 reference 2013 "RFC 8329: Framework for Interface to Network Security 2014 Functions - Ingress, egress, and pass actions."; 2015 } 2017 identity drop { 2018 base ingress-action-capability; 2019 base egress-action-capability; 2020 base default-action-capability; 2021 description 2022 "Identity for drop action capability"; 2023 reference 2024 "RFC 8329: Framework for Interface to Network Security 2025 Functions - Ingress, egress, and drop actions."; 2027 } 2029 identity alert { 2030 base ingress-action-capability; 2031 base egress-action-capability; 2032 base default-action-capability; 2033 description 2034 "Identity for alert action capability"; 2035 reference 2036 "RFC 8329: Framework for Interface to Network Security 2037 Functions - Ingress, egress, and alert actions. 2038 draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF 2039 NSF Monitoring YANG Data Model - Alarm (i.e., alert)."; 2040 } 2042 identity mirror { 2043 base ingress-action-capability; 2044 base egress-action-capability; 2045 base default-action-capability; 2046 description 2047 "Identity for mirror action capability"; 2048 reference 2049 "RFC 8329: Framework for Interface to Network Security 2050 Functions - Ingress, egress, and mirror actions."; 2051 } 2053 identity invoke-signaling { 2054 base egress-action-capability; 2055 description 2056 "Identity for invoke signaling action capability"; 2057 reference 2058 "RFC 8329: Framework for Interface to Network Security 2059 Functions - Invoke-signaling action"; 2060 } 2062 identity forwarding { 2063 base egress-action-capability; 2064 description 2065 "Identity for forwarding action capability"; 2066 reference 2067 "RFC 8329: Framework for Interface to Network Security 2068 Functions - Forwarding action"; 2069 } 2071 identity redirection { 2072 base egress-action-capability; 2073 description 2074 "Identity for redirection action capability"; 2076 reference 2077 "RFC 8329: Framework for Interface to Network Security 2078 Functions - Redirection action"; 2079 } 2081 identity resolution-strategy-capability { 2082 description 2083 "Base identity for resolution strategy capability"; 2084 } 2086 identity fmr { 2087 base resolution-strategy-capability; 2088 description 2089 "Identity for First Matching Rule (FMR) resolution 2090 strategy capability"; 2091 } 2093 identity lmr { 2094 base resolution-strategy-capability; 2095 description 2096 "Identity for Last Matching Rule (LMR) resolution 2097 strategy capability"; 2098 } 2100 identity pmr { 2101 base resolution-strategy-capability; 2102 description 2103 "Identity for Prioritized Matching Rule (PMR) resolution 2104 strategy capability"; 2105 } 2107 identity pmre { 2108 base resolution-strategy-capability; 2109 description 2110 "Identity for Prioritized Matching Rule with Errors (PMRE) 2111 resolution strategy capability"; 2112 } 2114 identity pmrn { 2115 base resolution-strategy-capability; 2116 description 2117 "Identity for Prioritized Matching Rule with No Errors (PMRN) 2118 resolution strategy capability"; 2119 } 2121 identity advanced-nsf-capability { 2122 description 2123 "Base identity for advanced Network Security Function (NSF) 2124 capability. This can be used for advanced NSFs such as 2125 Anti-Virus, Anti-DDoS Attack, IPS, and VoIP/VoLTE Security 2126 Service."; 2127 reference 2128 "RFC 8329: Framework for Interface to Network Security 2129 Functions - Advanced NSF capability"; 2130 } 2132 identity anti-virus-capability { 2133 base advanced-nsf-capability; 2134 description 2135 "Identity for advanced NSF Anti-Virus capability. 2136 This can be used for an extension point for Anti-Virus 2137 as an advanced NSF."; 2138 reference 2139 "RFC 8329: Framework for Interface to Network Security 2140 Functions - Advanced NSF Anti-Virus capability"; 2141 } 2143 identity anti-ddos-capability { 2144 base advanced-nsf-capability; 2145 description 2146 "Identity for advanced NSF Anti-DDoS Attack capability. 2147 This can be used for an extension point for Anti-DDoS 2148 Attack as an advanced NSF."; 2149 reference 2150 "RFC 8329: Framework for Interface to Network Security 2151 Functions - Advanced NSF Anti-DDoS Attack capability"; 2152 } 2154 identity ips-capability { 2155 base advanced-nsf-capability; 2156 description 2157 "Identity for advanced NSF IPS capabilities. This can be 2158 used for an extension point for IPS as an advanced NSF."; 2159 reference 2160 "RFC 8329: Framework for Interface to Network Security 2161 Functions - Advanced NSF IPS capability"; 2162 } 2164 identity voip-volte-capability { 2165 base advanced-nsf-capability; 2166 description 2167 "Identity for advanced NSF VoIP/VoLTE Security Service 2168 capability. This can be used for an extension point 2169 for VoIP/VoLTE Security Service as an advanced NSF."; 2170 reference 2171 "RFC 3261: SIP: Session Initiation Protocol"; 2173 } 2175 identity detect { 2176 base anti-virus-capability; 2177 description 2178 "Identity for advanced NSF Anti-Virus Detection capability. 2179 This can be used for an extension point for Anti-Virus 2180 Detection as an advanced NSF."; 2181 reference 2182 "RFC 8329: Framework for Interface to Network Security 2183 Functions - Advanced NSF Anti-Virus Detection capability"; 2184 } 2186 identity allow-list { 2187 base anti-virus-capability; 2188 description 2189 "Identity for advanced NSF Anti-Virus Allow List capability. 2190 This can be used for an extension point for Anti-Virus 2191 Allow List as an advanced NSF."; 2192 reference 2193 "RFC 8329: Framework for Interface to Network Security 2194 Functions - Advanced NSF Anti-Virus Allow List capability"; 2195 } 2197 identity syn-flood-action { 2198 base anti-ddos-capability; 2199 description 2200 "Identity for advanced NSF Anti-DDoS SYN Flood Action 2201 capability. This can be used for an extension point for 2202 Anti-DDoS SYN Flood Action as an advanced NSF."; 2203 reference 2204 "RFC 8329: Framework for Interface to Network Security 2205 Functions - Advanced NSF Anti-DDoS SYN Flood Action 2206 capability"; 2207 } 2209 identity udp-flood-action { 2210 base anti-ddos-capability; 2211 description 2212 "Identity for advanced NSF Anti-DDoS UDP Flood Action 2213 capability. This can be used for an extension point for 2214 Anti-DDoS UDP Flood Action as an advanced NSF."; 2215 reference 2216 "RFC 8329: Framework for Interface to Network Security 2217 Functions - Advanced NSF Anti-DDoS UDP Flood Action 2218 capability"; 2219 } 2220 identity http-flood-action { 2221 base anti-ddos-capability; 2222 description 2223 "Identity for advanced NSF Anti-DDoS HTTP Flood Action 2224 capability. This can be used for an extension point for 2225 Anti-DDoS HTTP Flood Action as an advanced NSF."; 2226 reference 2227 "RFC 8329: Framework for Interface to Network Security 2228 Functions - Advanced NSF Anti-DDoS HTTP Flood Action 2229 capability"; 2230 } 2232 identity https-flood-action { 2233 base anti-ddos-capability; 2234 description 2235 "Identity for advanced NSF Anti-DDoS HTTPS Flood Action 2236 capability. This can be used for an extension point for 2237 Anti-DDoS HTTPS Flood Action as an advanced NSF."; 2238 reference 2239 "RFC 8329: Framework for Interface to Network Security 2240 Functions - Advanced NSF Anti-DDoS HTTPS Flood Action 2241 capability"; 2242 } 2244 identity dns-request-flood-action { 2245 base anti-ddos-capability; 2246 description 2247 "Identity for advanced NSF Anti-DDoS DNS Request Flood 2248 Action capability. This can be used for an extension 2249 point for Anti-DDoS DNS Request Flood Action as an 2250 advanced NSF."; 2251 reference 2252 "RFC 8329: Framework for Interface to Network Security 2253 Functions - Advanced NSF Anti-DDoS DNS Request Flood 2254 Action capability"; 2255 } 2257 identity dns-reply-flood-action { 2258 base anti-ddos-capability; 2259 description 2260 "Identity for advanced NSF Anti-DDoS DNS Reply Flood 2261 Action capability. This can be used for an extension 2262 point for Anti-DDoS DNS Reply Flood Action as an 2263 advanced NSF."; 2264 reference 2265 "RFC 8329: Framework for Interface to Network Security 2266 Functions - Advanced NSF Anti-DDoS DNS Reply Flood 2267 Action capability"; 2269 } 2271 identity icmp-flood-action { 2272 base anti-ddos-capability; 2273 description 2274 "Identity for advanced NSF Anti-DDoS ICMP Flood Action 2275 capability. This can be used for an extension point 2276 for Anti-DDoS ICMP Flood Action as an advanced NSF."; 2277 reference 2278 "RFC 8329: Framework for Interface to Network Security 2279 Functions - Advanced NSF Anti-DDoS ICMP Flood Action 2280 capability"; 2281 } 2283 identity icmpv6-flood-action { 2284 base anti-ddos-capability; 2285 description 2286 "Identity for advanced NSF Anti-DDoS ICMPv6 Flood Action 2287 capability. This can be used for an extension point 2288 for Anti-DDoS ICMPv6 Flood Action as an advanced NSF."; 2289 reference 2290 "RFC 8329: Framework for Interface to Network Security 2291 Functions - Advanced NSF Anti-DDoS ICMPv6 Flood Action 2292 capability"; 2293 } 2295 identity sip-flood-action { 2296 base anti-ddos-capability; 2297 description 2298 "Identity for advanced NSF Anti-DDoS SIP Flood Action 2299 capability. This can be used for an extension point 2300 for Anti-DDoS SIP Flood Action as an advanced NSF."; 2301 reference 2302 "RFC 8329: Framework for Interface to Network Security 2303 Functions - Advanced NSF Anti-DDoS SIP Flood Action 2304 capability"; 2305 } 2307 identity detect-mode { 2308 base anti-ddos-capability; 2309 description 2310 "Identity for advanced NSF Anti-DDoS Detection Mode 2311 capability. This can be used for an extension point 2312 for Anti-DDoS Detection Mode as an advanced NSF."; 2313 reference 2314 "RFC 8329: Framework for Interface to Network Security 2315 Functions - Advanced NSF Anti-DDoS Detection Mode 2316 capability"; 2318 } 2320 identity baseline-learning { 2321 base anti-ddos-capability; 2322 description 2323 "Identity for advanced NSF Anti-DDoS Baseline Learning 2324 capability. This can be used for an extension point 2325 for Anti-DDoS Baseline Learning as an advanced NSF."; 2326 reference 2327 "RFC 8329: Framework for Interface to Network Security 2328 Functions - Advanced NSF Anti-DDoS Baseline Learning 2329 capability"; 2330 } 2332 identity signature-set { 2333 base ips-capability; 2334 description 2335 "Identity for advanced NSF IPS Signature Set capability. 2336 This can be used for an extension point for IPS Signature 2337 Set as an advanced NSF."; 2338 reference 2339 "RFC 8329: Framework for Interface to Network Security 2340 Functions - Advanced NSF IPS Signature Set capability"; 2341 } 2343 identity ips-exception-signature { 2344 base ips-capability; 2345 description 2346 "Identity for advanced NSF IPS Exception Signature 2347 capability. This can be used for an extension point for 2348 IPS Exception Signature as an advanced NSF."; 2349 reference 2350 "RFC 8329: Framework for Interface to Network Security 2351 Functions - Advanced NSF IPS Exception Signature Set 2352 capability"; 2353 } 2355 identity voip-volte-call-id { 2356 base voip-volte-capability; 2357 description 2358 "Identity for advanced NSF VoIP/VoLTE Call Identifier (ID) 2359 capability. This can be used for an extension point for 2360 VoIP/VoLTE Call ID as an advanced NSF."; 2361 reference 2362 "RFC 3261: SIP: Session Initiation Protocol"; 2363 } 2365 identity user-agent { 2366 base voip-volte-capability; 2367 description 2368 "Identity for advanced NSF VoIP/VoLTE User Agent capability. 2369 This can be used for an extension point for VoIP/VoLTE 2370 User Agent as an advanced NSF."; 2371 reference 2372 "RFC 3261: SIP: Session Initiation Protocol"; 2373 } 2375 identity ipsec-capability { 2376 description 2377 "Base identity for an IPsec capability"; 2378 reference 2379 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: 2380 Software-Defined Networking (SDN)-based IPsec Flow 2381 Protection - IPsec methods such as IKE and IKE-less"; 2382 } 2384 identity ike { 2385 base ipsec-capability; 2386 description 2387 "Identity for an IPsec Internet Key Exchange (IKE) 2388 capability"; 2389 reference 2390 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: 2391 Software-Defined Networking (SDN)-based IPsec Flow 2392 Protection - IPsec method with IKE. 2393 RFC 7296: Internet Key Exchange Protocol Version 2 2394 (IKEv2) - IKE as a component of IPsec used for 2395 performing mutual authentication and establishing and 2396 maintaining Security Associations (SAs)."; 2397 } 2399 identity ikeless { 2400 base ipsec-capability; 2401 description 2402 "Identity for an IPsec without Internet Key Exchange (IKE) 2403 capability"; 2404 reference 2405 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: 2406 Software-Defined Networking (SDN)-based IPsec Flow 2407 Protection - IPsec method without IKE"; 2408 } 2410 /* 2411 * Grouping 2412 */ 2414 grouping nsf-capabilities { 2415 description 2416 "Network Security Function (NSF) Capabilities"; 2417 reference 2418 "RFC 8329: Framework for Interface to Network Security 2419 Functions - I2NSF Flow Security Policy Structure."; 2421 leaf-list directional-capabilities { 2422 type identityref { 2423 base directional-capability; 2424 } 2425 description 2426 "The capability of an NSF for handling directional traffic 2427 flow (i.e., unidirectional or bidirectional traffic flow)."; 2428 } 2430 leaf-list time-capabilities { 2431 type enumeration { 2432 enum absolute-time { 2433 description 2434 "absolute time capabilities. 2435 If a network security function has the absolute time 2436 capability, the network security function supports 2437 rule execution according to absolute time."; 2438 } 2439 enum periodic-time { 2440 description 2441 "periodic time capabilities. 2442 If a network security function has the periodic time 2443 capability, the network security function supports 2444 rule execution according to periodic time."; 2445 } 2446 } 2447 description 2448 "Time capabilities"; 2449 } 2451 container event-capabilities { 2452 description 2453 "Capabilities of events. 2454 If a network security function has the event capabilities, 2455 the network security function supports rule execution 2456 according to system event and system alarm."; 2458 reference 2459 "RFC 8329: Framework for Interface to Network Security 2460 Functions - I2NSF Flow Security Policy Structure. 2461 draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF 2462 NSF Monitoring YANG Data Model - System Alarm and 2463 System Events."; 2465 leaf-list system-event-capability { 2466 type identityref { 2467 base system-event-capability; 2468 } 2469 description 2470 "System event capabilities"; 2471 } 2473 leaf-list system-alarm-capability { 2474 type identityref { 2475 base system-alarm-capability; 2476 } 2477 description 2478 "System alarm capabilities"; 2479 } 2480 } 2482 container condition-capabilities { 2483 description 2484 "Conditions capabilities."; 2486 container generic-nsf-capabilities { 2487 description 2488 "Conditions capabilities. 2489 If a network security function has the condition 2490 capabilities, the network security function 2491 supports rule execution according to conditions of 2492 IPv4, IPv6, TCP, UDP, SCTP, DCCP, ICMP, ICMPv6, or 2493 payload."; 2494 reference 2495 "RFC 791: Internet Protocol - IPv4. 2496 RFC 792: Internet Control Message Protocol - ICMP. 2497 RFC 793: Transmission Control Protocol - TCP. 2498 RFC 768: User Datagram Protocol - UDP. 2499 RFC 4960: Stream Control Transmission Protocol - SCTP. 2500 RFC 8200: Internet Protocol, Version 6 (IPv6) 2501 Specification - IPv6. 2502 RFC 4443: Internet Control Message Protocol (ICMPv6) 2503 for the Internet Protocol Version 6 (IPv6) Specification 2504 - ICMPv6. 2505 RFC 8329: Framework for Interface to Network Security 2506 Functions - I2NSF Flow Security Policy Structure."; 2508 leaf-list ipv4-capability { 2509 type identityref { 2510 base ipv4-capability; 2511 } 2512 description 2513 "IPv4 packet capabilities"; 2514 reference 2515 "RFC 791: Internet Protocol"; 2516 } 2518 leaf-list icmp-capability { 2519 type identityref { 2520 base icmp-capability; 2521 } 2522 description 2523 "ICMP packet capabilities"; 2524 reference 2525 "RFC 792: Internet Control Message Protocol - ICMP"; 2526 } 2528 leaf-list ipv6-capability { 2529 type identityref { 2530 base ipv6-capability; 2531 } 2532 description 2533 "IPv6 packet capabilities"; 2534 reference 2535 "RFC 8200: Internet Protocol, Version 6 (IPv6) 2536 Specification - IPv6"; 2537 } 2539 leaf-list icmpv6-capability { 2540 type identityref { 2541 base icmpv6-capability; 2542 } 2543 description 2544 "ICMPv6 packet capabilities"; 2545 reference 2546 "RFC 4443: Internet Control Message Protocol (ICMPv6) 2547 for the Internet Protocol Version 6 (IPv6) Specification 2548 - ICMPv6"; 2549 } 2551 leaf-list tcp-capability { 2552 type identityref { 2553 base tcp-capability; 2554 } 2555 description 2556 "TCP packet capabilities"; 2557 reference 2558 "RFC 793: Transmission Control Protocol - TCP 2559 draft-ietf-tcpm-rfc793bis-19: Transmission Control Protocol 2560 (TCP) Specification"; 2561 } 2563 leaf-list udp-capability { 2564 type identityref { 2565 base udp-capability; 2566 } 2567 description 2568 "UDP packet capabilities"; 2569 reference 2570 "RFC 768: User Datagram Protocol - UDP"; 2571 } 2573 leaf-list sctp-capability { 2574 type identityref { 2575 base sctp-capability; 2576 } 2577 description 2578 "SCTP packet capabilities"; 2579 reference 2580 "RFC 4960: Stream Control Transmission Protocol - SCTP"; 2581 } 2583 leaf-list dccp-capability { 2584 type identityref { 2585 base dccp-capability; 2586 } 2587 description 2588 "DCCP packet capabilities"; 2589 reference 2590 "RFC 4340: Datagram Congestion Control Protocol - DCCP"; 2591 } 2592 } 2594 container advanced-nsf-capabilities { 2595 description 2596 "Advanced Network Security Function (NSF) capabilities, 2597 such as Anti-Virus, Anti-DDoS, IPS, and VoIP/VoLTE. 2598 This container contains the leaf-lists of advanced 2599 NSF capabilities"; 2600 reference 2601 "RFC 8329: Framework for Interface to Network Security 2602 Functions - Advanced NSF capabilities"; 2604 leaf-list anti-virus-capability { 2605 type identityref { 2606 base anti-virus-capability; 2607 } 2608 description 2609 "Anti-Virus capabilities"; 2610 reference 2611 "RFC 8329: Framework for Interface to Network Security 2612 Functions - Advanced NSF Anti-Virus capabilities"; 2613 } 2615 leaf-list anti-ddos-capability { 2616 type identityref { 2617 base anti-ddos-capability; 2618 } 2619 description 2620 "Anti-DDoS Attack capabilities"; 2621 reference 2622 "RFC 8329: Framework for Interface to Network Security 2623 Functions - Advanced NSF Anti-DDoS Attack capabilities"; 2624 } 2626 leaf-list ips-capability { 2627 type identityref { 2628 base ips-capability; 2629 } 2630 description 2631 "IPS capabilities"; 2632 reference 2633 "RFC 8329: Framework for Interface to Network Security 2634 Functions - Advanced NSF IPS capabilities"; 2635 } 2637 leaf-list url-capability { 2638 type identityref { 2639 base url-capability; 2640 } 2641 description 2642 "URL capabilities"; 2643 reference 2644 "RFC 8329: Framework for Interface to Network Security 2645 Functions - Advanced NSF URL capabilities"; 2646 } 2648 leaf-list voip-volte-capability { 2649 type identityref { 2650 base voip-volte-capability; 2651 } 2652 description 2653 "VoIP/VoLTE capabilities"; 2655 reference 2656 "RFC 8329: Framework for Interface to Network Security 2657 Functions - Advanced NSF VoIP/VoLTE capabilities"; 2658 } 2659 } 2661 leaf-list context-capabilities { 2662 type identityref { 2663 base context-capability; 2664 } 2665 description 2666 "Security context capabilities"; 2667 } 2668 } 2670 container action-capabilities { 2671 description 2672 "Action capabilities. 2673 If a network security function has the action capabilities, 2674 the network security function supports the attendant 2675 actions for policy rules."; 2677 leaf-list ingress-action-capability { 2678 type identityref { 2679 base ingress-action-capability; 2680 } 2681 description 2682 "Ingress-action capabilities"; 2683 } 2685 leaf-list egress-action-capability { 2686 type identityref { 2687 base egress-action-capability; 2688 } 2689 description 2690 "Egress-action capabilities"; 2691 } 2693 leaf-list log-action-capability { 2694 type identityref { 2695 base log-action-capability; 2696 } 2697 description 2698 "Log-action capabilities"; 2699 } 2700 } 2702 leaf-list resolution-strategy-capabilities { 2703 type identityref { 2704 base resolution-strategy-capability; 2705 } 2706 description 2707 "Resolution strategy capabilities. 2708 The resolution strategies can be used to specify how 2709 to resolve conflicts that occur between the actions 2710 of the same or different policy rules that are matched 2711 for the same packet and by particular NSF."; 2712 } 2714 leaf-list default-action-capabilities { 2715 type identityref { 2716 base default-action-capability; 2717 } 2718 description 2719 "Default action capabilities. 2720 A default action is used to execute I2NSF policy rules 2721 when no rule matches a packet. The default action is 2722 defined as pass, drop, alert, or mirror. Note that 2723 alert makes a packet dropped and logged."; 2724 reference 2725 "RFC 8329: Framework for Interface to Network Security 2726 Functions - Ingress and egress actions."; 2727 } 2729 leaf-list ipsec-method { 2730 type identityref { 2731 base ipsec-capability; 2732 } 2733 description 2734 "IPsec method capabilities"; 2735 reference 2736 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: 2737 Software-Defined Networking (SDN)-based IPsec Flow 2738 Protection - IPsec methods such as IKE and IKE-less"; 2739 } 2740 } 2742 /* 2743 * Data nodes 2744 */ 2746 list nsf { 2747 key "nsf-name"; 2748 description 2749 "The list of Network Security Functions (NSFs)"; 2750 leaf nsf-name { 2751 type string; 2752 mandatory true; 2753 description 2754 "The name of Network Security Function (NSF)"; 2755 } 2756 uses nsf-capabilities; 2757 } 2758 } 2759 2761 Figure 3: YANG Data Module of I2NSF Capability 2763 7. IANA Considerations 2765 This document requests IANA to register the following URI in the 2766 "IETF XML Registry" [RFC3688]: 2768 ID: yang:ietf-i2nsf-capability 2769 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2770 Registrant Contact: The IESG. 2771 XML: N/A; the requested URI is an XML namespace. 2772 Filename: [ TBD-at-Registration ] 2773 Reference: [ RFC-to-be ] 2775 This document requests IANA to register the following YANG module in 2776 the "YANG Module Names" registry [RFC7950][RFC8525]: 2778 Name: ietf-i2nsf-capability 2779 Maintained by IANA? N 2780 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2781 Prefix: nsfcap 2782 Module: 2783 Reference: [ RFC-to-be ] 2785 8. Privacy Considerations 2787 This YANG module specified in this document make a trade-off between 2788 privacy and security. Some part of the YANG data model specified in 2789 this document might use highly sensitive private data of the client. 2790 The data used in this YANG data model can be used for the NSFs to 2791 improve the security of the network. 2793 In regards to the privacy data used, the security for accessibility 2794 of the data should be tightly secured and monitored. The Security 2795 Considerations are discussed in Section 9. 2797 9. Security Considerations 2799 The YANG module specified in this document defines a data schema 2800 designed to be accessed through network management protocols such as 2801 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest layer of NETCONF 2802 protocol layers can use Secure Shell (SSH) [RFC4254][RFC6242] as a 2803 secure transport layer. The lowest layer of RESTCONF protocol layers 2804 can use HTTP over Transport Layer Security (TLS), that is, HTTPS 2805 [RFC7230][RFC8446] as a secure transport layer. 2807 The Network Configuration Access Control Model (NACM) [RFC8341] 2808 provides a means of restricting access to specific NETCONF or 2809 RESTCONF users to a preconfigured subset of all available NETCONF or 2810 RESTCONF protocol operations and contents. Thus, NACM can be used to 2811 restrict the NSF registration from unauthorized users. 2813 There are a number of data nodes defined in this YANG module that are 2814 writable, creatable, and deletable (i.e., config true, which is the 2815 default). These data nodes may be considered sensitive or vulnerable 2816 in some network environments. Write operations to these data nodes 2817 could have a negative effect on network and security operations. 2818 These data nodes are collected into a single list node. This list 2819 node is defined by list nsf with the following sensitivity/ 2820 vulnerability: 2822 o list nsf: An attacker could alter the security capabilities 2823 associated with an NSF by disabling or enabling the functionality 2824 of the security capabilities of the NSF. 2826 Some of the features that this document defines capability indicators 2827 for are highly sensitive and/or privileged operations (e.g., 2828 listening to VoIP/VoLTE audio to identify individuals and web 2829 filtering) that inherently require access to individuals' private 2830 data. It is noted that private information is made accessible in 2831 this manner. Thus, the nodes/entities given access to this data need 2832 to be tightly secured and monitored, to prevent leakage or other 2833 unauthorized disclosure of private data. Refer to [RFC6973] for the 2834 description of privacy aspects that protocol designers (including 2835 YANG data model designers) should consider along with regular 2836 security and privacy analysis. 2838 10. References 2840 10.1. Normative References 2842 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 2843 Jeong, J., Lingga, P., Hares, S., Xia, L., and H. 2844 Birkholz, "I2NSF NSF Monitoring YANG Data Model", draft- 2845 ietf-i2nsf-nsf-monitoring-data-model-04 (work in 2846 progress), September 2020. 2848 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] 2849 Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 2850 Garcia, "Software-Defined Networking (SDN)-based IPsec 2851 Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow- 2852 protection-12 (work in progress), October 2020. 2854 [I-D.ietf-tcpm-accurate-ecn] 2855 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 2856 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 2857 ecn-13 (work in progress), November 2020. 2859 [I-D.ietf-tcpm-rfc793bis] 2860 Eddy, W., "Transmission Control Protocol (TCP) 2861 Specification", draft-ietf-tcpm-rfc793bis-20 (work in 2862 progress), January 2021. 2864 [I-D.ietf-tsvwg-udp-options] 2865 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 2866 udp-options-09 (work in progress), November 2020. 2868 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2869 DOI 10.17487/RFC0768, August 1980, 2870 . 2872 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2873 DOI 10.17487/RFC0791, September 1981, 2874 . 2876 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2877 RFC 792, DOI 10.17487/RFC0792, September 1981, 2878 . 2880 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2881 RFC 793, DOI 10.17487/RFC0793, September 1981, 2882 . 2884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2885 Requirement Levels", BCP 14, RFC 2119, 2886 DOI 10.17487/RFC2119, March 1997, 2887 . 2889 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2890 "Definition of the Differentiated Services Field (DS 2891 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2892 DOI 10.17487/RFC2474, December 1998, 2893 . 2895 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2896 of Explicit Congestion Notification (ECN) to IP", 2897 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2898 . 2900 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2901 A., Peterson, J., Sparks, R., Handley, M., and E. 2902 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2903 DOI 10.17487/RFC3261, June 2002, 2904 . 2906 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2907 DOI 10.17487/RFC3688, January 2004, 2908 . 2910 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2911 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 2912 January 2006, . 2914 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2915 Congestion Control Protocol (DCCP)", RFC 4340, 2916 DOI 10.17487/RFC4340, March 2006, 2917 . 2919 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2920 Control Message Protocol (ICMPv6) for the Internet 2921 Protocol Version 6 (IPv6) Specification", STD 89, 2922 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2923 . 2925 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2926 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2927 . 2929 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 2930 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 2931 September 2009, . 2933 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2934 the Network Configuration Protocol (NETCONF)", RFC 6020, 2935 DOI 10.17487/RFC6020, October 2010, 2936 . 2938 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2939 and A. Bierman, Ed., "Network Configuration Protocol 2940 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2941 . 2943 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2944 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2945 . 2947 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2948 Cheshire, "Internet Assigned Numbers Authority (IANA) 2949 Procedures for the Management of the Service Name and 2950 Transport Protocol Port Number Registry", BCP 165, 2951 RFC 6335, DOI 10.17487/RFC6335, August 2011, 2952 . 2954 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2955 "IPv6 Flow Label Specification", RFC 6437, 2956 DOI 10.17487/RFC6437, November 2011, 2957 . 2959 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2960 RFC 6691, DOI 10.17487/RFC6691, July 2012, 2961 . 2963 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2964 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2965 . 2967 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2968 Morris, J., Hansen, M., and R. Smith, "Privacy 2969 Considerations for Internet Protocols", RFC 6973, 2970 DOI 10.17487/RFC6973, July 2013, 2971 . 2973 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2974 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2975 . 2977 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2978 Protocol (HTTP/1.1): Message Syntax and Routing", 2979 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2980 . 2982 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2983 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2984 DOI 10.17487/RFC7231, June 2014, 2985 . 2987 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2988 Kivinen, "Internet Key Exchange Protocol Version 2 2989 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2990 2014, . 2992 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 2993 Scheffenegger, Ed., "TCP Extensions for High Performance", 2994 RFC 7323, DOI 10.17487/RFC7323, September 2014, 2995 . 2997 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2998 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2999 . 3001 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3002 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3003 . 3005 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 3006 and J. Jeong, "Interface to Network Security Functions 3007 (I2NSF): Problem Statement and Use Cases", RFC 8192, 3008 DOI 10.17487/RFC8192, July 2017, 3009 . 3011 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3012 (IPv6) Specification", STD 86, RFC 8200, 3013 DOI 10.17487/RFC8200, July 2017, 3014 . 3016 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 3017 Kumar, "Framework for Interface to Network Security 3018 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 3019 . 3021 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3022 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3023 . 3025 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 3026 Access Control Model", STD 91, RFC 8341, 3027 DOI 10.17487/RFC8341, March 2018, 3028 . 3030 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 3031 Documents Containing YANG Data Models", BCP 216, RFC 8407, 3032 DOI 10.17487/RFC8407, October 2018, 3033 . 3035 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3036 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3037 . 3039 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 3040 "YANG Data Model for Network Access Control Lists (ACLs)", 3041 RFC 8519, DOI 10.17487/RFC8519, March 2019, 3042 . 3044 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 3045 and R. Wilton, "YANG Library", RFC 8525, 3046 DOI 10.17487/RFC8525, March 2019, 3047 . 3049 10.2. Informative References 3051 [Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and 3052 management of firewall policies", 2004. 3054 [Galitsky] 3055 Galitsky, B. and R. Pampapathi, "Can many agents answer 3056 questions better than one", First 3057 Monday http://dx.doi.org/10.5210/fm.v10i1.1204, 2005. 3059 [Hirschman] 3060 Hirschman, L. and R. Gaizauskas, "Natural Language 3061 Question Answering: The View from Here", Natural Language 3062 Engineering 7:4, pgs 275-300, Cambridge University Press , 3063 Nov 2001. 3065 [Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns", 3066 ISBN 0-32-120068-3 , 2003. 3068 [IANA-Protocol-Numbers] 3069 "Assigned Internet Protocol Numbers", Available: 3070 https://www.iana.org/assignments/protocol- 3071 numbers/protocol-numbers.xhtml, September 2020. 3073 [Martin] Martin, R., "Agile Software Development, Principles, 3074 Patterns, and Practices", Prentice-Hall , ISBN: 3075 0-13-597444-5 , 2002. 3077 [OODMP] "http://www.oodesign.com/mediator-pattern.html". 3079 [OODOP] "http://www.oodesign.com/mediator-pattern.html". 3081 [OODSRP] "http://www.oodesign.com/mediator-pattern.html". 3083 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 3084 Kumari, "A Format for Self-Published IP Geolocation 3085 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 3086 . 3088 Appendix A. Configuration Examples 3090 This section shows configuration examples of "ietf-i2nsf-capability" 3091 module for capabilities registration of general firewall. 3093 A.1. Example 1: Registration for the Capabilities of a General Firewall 3095 This section shows a configuration example for the capabilities 3096 registration of a general firewall in either an IPv4 network or an 3097 IPv6 network. 3099 3100 general_firewall 3101 3102 3103 ipv4-protocol 3104 prefix-ipv4-address-flow-direction 3105 prefix-ipv4-address 3106 range-ipv4-address-flow-direction 3107 range-ipv4-address 3108 exact-tcp-port-num-flow-direction 3109 exact-tcp-src-port-num 3110 exact-tcp-dst-port-num 3111 range-tcp-port-num-flow-direction 3112 range-tcp-src-port-num 3113 range-tcp-dst-port-num 3114 exact-udp-port-num-flow-direction 3115 exact-udp-src-port-num 3116 exact-udp-dst-port-num 3117 range-udp-port-num-flow-direction 3118 range-udp-src-port-num 3119 range-udp-dst-port-num 3120 3121 3122 3123 pass 3124 drop 3125 alert 3126 pass 3127 drop 3128 alert 3129 3130 3132 Figure 4: Configuration XML for the Capabilities Registration of a 3133 General Firewall in an IPv4 Network 3135 Figure 4 shows the configuration XML for the capabilities 3136 registration of a general firewall as an NSF in an IPv4 network. Its 3137 capabilities are as follows. 3139 1. The name of the NSF is general_firewall. 3141 2. The NSF can inspect a protocol, a prefix of IPv4 addresses, and a 3142 range of IPv4 addresses for IPv4 packets. 3144 3. The NSF can inspect an exact port number and a range of port 3145 numbers for the transport layer (TCP and UDP). 3147 4. The NSF can control whether the packets are allowed to pass, 3148 drop, or alert. 3150 3151 general_firewall 3152 3153 3154 ipv6-next-header 3155 prefix-ipv6-address-flow-direction 3156 prefix-ipv6-address 3157 range-ipv6-address-flow-direction 3158 range-ipv6-address 3159 exact-tcp-port-num-flow-direction 3160 exact-tcp-src-port-num 3161 exact-tcp-dst-port-num 3162 range-tcp-port-num-flow-direction 3163 range-tcp-src-port-num 3164 range-tcp-dst-port-num 3165 exact-udp-port-num-flow-direction 3166 exact-udp-src-port-num 3167 exact-udp-dst-port-num 3168 range-udp-port-num-flow-direction 3169 range-udp-src-port-num 3170 range-udp-dst-port-num 3171 3172 3173 3174 pass 3175 drop 3176 alert 3177 pass 3178 drop 3179 alert 3180 3181 3183 Figure 5: Configuration XML for the Capabilities Registration of a 3184 General Firewall in an IPv6 Network 3186 In addition, Figure 5 shows the configuration XML for the 3187 capabilities registration of a general firewall as an NSF in an IPv6 3188 network. Its capabilities are as follows. 3190 1. The name of the NSF is general_firewall. 3192 2. The NSF can inspect a protocol (Next-Header), a prefix of IPv6 3193 addresses, and a range of IPv6 addresses for IPv6 packets. 3195 3. The NSF can inspect an exact port number and a range of port 3196 numbers for the transport layer (TCP and UDP). 3198 4. The NSF can control whether the packets are allowed to pass, 3199 drop, or alert. 3201 A.2. Example 2: Registration for the Capabilities of a Time-based 3202 Firewall 3204 This section shows a configuration example for the capabilities 3205 registration of a time-based firewall in either an IPv4 network or an 3206 IPv6 network. 3208 3209 time_based_firewall 3210 absolute-time 3211 periodic-time 3212 3213 3214 ipv4-protocol 3215 prefix-ipv4-address-flow-direction 3216 prefix-ipv4-address 3217 range-ipv4-address-flow-direction 3218 range-ipv4-address 3219 3220 3221 3222 pass 3223 drop 3224 alert 3225 pass 3226 drop 3227 alert 3228 3229 3231 Figure 6: Configuration XML for the Capabilities Registration of a 3232 Time-based Firewall in an IPv4 Network 3234 Figure 6 shows the configuration XML for the capabilities 3235 registration of a time-based firewall as an NSF in an IPv4 network. 3236 Its capabilities are as follows. 3238 1. The name of the NSF is time_based_firewall. 3240 2. The NSF can execute the security policy rule according to 3241 absolute time and periodic time. 3243 3. The NSF can inspect a protocol (Next-Header), an exact IPv4 3244 address, and a range of IPv4 addresses for IPv4 packets. 3246 4. The NSF can control whether the packets are allowed to pass, 3247 drop, or alert. 3249 3250 time_based_firewall 3251 absolute-time 3252 periodic-time 3253 3254 3255 ipv6-next-header 3256 prefix-ipv6-address-flow-direction 3257 prefix-ipv6-address 3258 range-ipv6-address-flow-direction 3259 range-ipv6-address 3260 3261 3262 3263 pass 3264 drop 3265 alert 3266 pass 3267 drop 3268 alert 3269 3270 3272 Figure 7: Configuration XML for the Capabilities Registration of a 3273 Time-based Firewall in an IPv6 Network 3275 In addition, Figure 7 shows the configuration XML for the 3276 capabilities registration of a time-based firewall as an NSF in an 3277 IPv6 network. Its capabilities are as follows. 3279 1. The name of the NSF is time_based_firewall. 3281 2. The NSF can execute the security policy rule according to 3282 absolute time and periodic time. 3284 3. The NSF can inspect a protocol (Next-Header), an exact IPv6 3285 address, and a range of IPv6 addresses for IPv6 packets. 3287 4. The NSF can control whether the packets are allowed to pass, 3288 drop, or alert. 3290 A.3. Example 3: Registration for the Capabilities of a Web Filter 3292 This section shows a configuration example for the capabilities 3293 registration of a web filter. 3295 3296 web_filter 3297 3298 3299 user-defined 3300 3301 3302 3303 pass 3304 drop 3305 alert 3306 pass 3307 drop 3308 alert 3309 3310 3312 Figure 8: Configuration XML for the Capabilities Registration of a 3313 Web Filter 3315 Figure 8 shows the configuration XML for the capabilities 3316 registration of a web filter as an NSF. Its capabilities are as 3317 follows. 3319 1. The name of the NSF is web_filter. 3321 2. The NSF can inspect a URL matched from a user-defined URL 3322 Database. User can add the new URL to the database. 3324 3. The NSF can control whether the packets are allowed to pass, 3325 drop, or alert. 3327 A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE 3328 Filter 3330 This section shows a configuration example for the capabilities 3331 registration of a VoIP/VoLTE filter. 3333 3334 voip_volte_filter 3335 3336 3337 voip-volte-call-id 3338 3339 3340 3341 pass 3342 drop 3343 alert 3344 pass 3345 drop 3346 alert 3347 3348 3350 Figure 9: Configuration XML for the Capabilities Registration of a 3351 VoIP/VoLTE Filter 3353 Figure 9 shows the configuration XML for the capabilities 3354 registration of a VoIP/VoLTE filter as an NSF. Its capabilities are 3355 as follows. 3357 1. The name of the NSF is voip_volte_filter. 3359 2. The NSF can inspect a voice call id for VoIP/VoLTE packets. 3361 3. The NSF can control whether the packets are allowed to pass, 3362 drop, or alert. 3364 A.5. Example 5: Registration for the Capabilities of a HTTP and HTTPS 3365 Flood Mitigator 3367 This section shows a configuration example for the capabilities 3368 registration of a HTTP and HTTPS flood mitigator. 3370 3371 http_and_https_flood_mitigation 3372 3373 3374 http-flood-action 3375 https-flood-action 3376 3377 3378 3379 pass 3380 drop 3381 alert 3382 pass 3383 drop 3384 alert 3385 3386 3388 Figure 10: Configuration XML for the Capabilities Registration of a 3389 HTTP and HTTPS Flood Mitigator 3391 Figure 10 shows the configuration XML for the capabilities 3392 registration of a HTTP and HTTPS flood mitigator as an NSF. Its 3393 capabilities are as follows. 3395 1. The name of the NSF is http_and_https_flood_mitigation. 3397 2. The NSF can control the amount of packets for HTTP and HTTPS 3398 packets, which are routed to the NSF's IPv4 address or the NSF's 3399 IPv6 address. 3401 3. The NSF can control whether the packets are allowed to pass, 3402 drop, or alert. 3404 Appendix B. Acknowledgments 3406 This work was supported by Institute of Information & Communications 3407 Technology Planning & Evaluation (IITP) grant funded by the Korea 3408 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 3409 Security Intelligence Technology Development for the Customized 3410 Security Service Provisioning). This work was supported in part by 3411 the IITP grant funded by the MSIT (2020-0-00395, Standard Development 3412 of Blockchain based Network Management Automation Technology). 3414 Appendix C. Contributors 3416 This document is made by the group effort of I2NSF working group. 3417 Many people actively contributed to this document, such as Acee 3418 Lindem, Roman Danyliw, and Tom Petch. The authors sincerely 3419 appreciate their contributions. 3421 The following are co-authors of this document: 3423 Patrick Lingga 3424 Department of Computer Science and Engineering 3425 Sungkyunkwan University 3426 2066 Seo-ro Jangan-gu 3427 Suwon, Gyeonggi-do 16419 3428 Republic of Korea 3430 EMail: patricklink@skku.edu 3432 Liang Xia 3433 Huawei 3434 101 Software Avenue 3435 Nanjing, Jiangsu 210012 3436 China 3438 EMail: Frank.Xialiang@huawei.com 3440 Cataldo Basile 3441 Politecnico di Torino 3442 Corso Duca degli Abruzzi, 34 3443 Torino, 10129 3444 Italy 3446 EMail: cataldo.basile@polito.it 3448 John Strassner 3449 Huawei 3450 2330 Central Expressway 3451 Santa Clara, CA 95050 3452 USA 3454 EMail: John.sc.Strassner@huawei.com 3456 Diego R. Lopez 3457 Telefonica I+D 3458 Zurbaran, 12 3459 Madrid, 28010 3460 Spain 3462 Email: diego.r.lopez@telefonica.com 3464 Hyoungshick Kim 3465 Department of Computer Science and Engineering 3466 Sungkyunkwan University 3467 2066 Seo-ro Jangan-gu 3468 Suwon, Gyeonggi-do 16419 3469 Republic of Korea 3471 EMail: hyoung@skku.edu 3473 Daeyoung Hyun 3474 Department of Computer Science and Engineering 3475 Sungkyunkwan University 3476 2066 Seo-ro Jangan-gu 3477 Suwon, Gyeonggi-do 16419 3478 Republic of Korea 3480 EMail: dyhyun@skku.edu 3482 Dongjin Hong 3483 Department of Electronic, Electrical and Computer Engineering 3484 Sungkyunkwan University 3485 2066 Seo-ro Jangan-gu 3486 Suwon, Gyeonggi-do 16419 3487 Republic of Korea 3489 EMail: dong.jin@skku.edu 3491 Jung-Soo Park 3492 Electronics and Telecommunications Research Institute 3493 218 Gajeong-Ro, Yuseong-Gu 3494 Daejeon, 34129 3495 Republic of Korea 3497 EMail: pjs@etri.re.kr 3499 Tae-Jin Ahn 3500 Korea Telecom 3501 70 Yuseong-Ro, Yuseong-Gu 3502 Daejeon, 305-811 3503 Republic of Korea 3505 EMail: taejin.ahn@kt.com 3507 Se-Hui Lee 3508 Korea Telecom 3509 70 Yuseong-Ro, Yuseong-Gu 3510 Daejeon, 305-811 3511 Republic of Korea 3513 EMail: sehuilee@kt.com 3515 Authors' Addresses 3517 Susan Hares (editor) 3518 Huawei 3519 7453 Hickory Hill 3520 Saline, MI 48176 3521 USA 3523 Phone: +1-734-604-0332 3524 EMail: shares@ndzh.com 3526 Jaehoon (Paul) Jeong (editor) 3527 Department of Computer Science and Engineering 3528 Sungkyunkwan University 3529 2066 Seobu-Ro, Jangan-Gu 3530 Suwon, Gyeonggi-Do 16419 3531 Republic of Korea 3533 Phone: +82 31 299 4957 3534 Fax: +82 31 290 7996 3535 EMail: pauljeong@skku.edu 3536 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3537 Jinyong (Tim) Kim 3538 Department of Electronic, Electrical and Computer Engineering 3539 Sungkyunkwan University 3540 2066 Seobu-Ro, Jangan-Gu 3541 Suwon, Gyeonggi-Do 16419 3542 Republic of Korea 3544 Phone: +82 10 8273 0930 3545 EMail: timkim@skku.edu 3547 Robert Moskowitz 3548 HTT Consulting 3549 Oak Park, MI 3550 USA 3552 Phone: +1-248-968-9809 3553 EMail: rgm@htt-consult.com 3555 Qiushi Lin 3556 Huawei 3557 Huawei Industrial Base 3558 Shenzhen, Guangdong 518129 3559 China 3561 EMail: linqiushi@huawei.com