idnits 2.17.1 draft-ietf-i2nsf-capability-data-model-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 October 2021) is 928 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Downref: Normative reference to an Informational RFC: RFC 4766 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-rfc793bis-25 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-tcpm-rfc793bis' == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-15 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-13 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-10 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-14 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-12 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 4 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: 7 April 2022 J. Kim 6 Sungkyunkwan University 7 R. Moskowitz 8 HTT Consulting 9 Q. Lin 10 Huawei 11 4 October 2021 13 I2NSF Capability YANG Data Model 14 draft-ietf-i2nsf-capability-data-model-20 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 7 April 2022. 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 (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Information Model of I2NSF NSF Capability . . . . . . . . . . 4 59 3.1. Design Principles and ECA Policy Model . . . . . . . . . 5 60 3.2. Conflict, Resolution Strategy and Default Action . . . . 8 61 4. Overview of YANG Data Model . . . . . . . . . . . . . . . . . 10 62 5. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12 63 5.1. Network Security Function (NSF) Capabilities . . . . . . 12 64 6. YANG Data Model of I2NSF NSF Capability . . . . . . . . . . . 15 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 66 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 50 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 51 70 10.2. Informative References . . . . . . . . . . . . . . . . . 56 71 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 57 72 A.1. Example 1: Registration for the Capabilities of a General 73 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 57 74 A.2. Example 2: Registration for the Capabilities of a 75 Time-based Firewall . . . . . . . . . . . . . . . . . . . 59 76 A.3. Example 3: Registration for the Capabilities of a Web 77 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 61 78 A.4. Example 4: Registration for the Capabilities of a VoIP/ 79 VoLTE Filter . . . . . . . . . . . . . . . . . . . . . . 62 80 A.5. Example 5: Registration for the Capabilities of a HTTP and 81 HTTPS Flood Mitigator . . . . . . . . . . . . . . . . . . 63 82 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 64 83 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 65 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 86 1. Introduction 88 As the industry becomes more sophisticated and network devices (e.g., 89 Internet-of-Things (IoT) devices, autonomous vehicles, and 90 smartphones using Voice over IP (VoIP) and Voice over LTE (VoLTE)) 91 require advanced security protection in various scenarios, security 92 service providers have a lot of problems described in [RFC8192] to 93 provide such network devices with efficient and reliable security 94 services in network infrastructure. To resolve these problems, this 95 document specifies the information and data models of the 96 capabilities of Network Security Functions (NSFs) in a framework of 97 the Interface to Network Security Functions (I2NSF) [RFC8329]. 99 NSFs produced by multiple security vendors provide various security 100 capabilities to customers. Multiple NSFs can be combined together to 101 provide security services over the given network traffic, regardless 102 of whether the NSFs are implemented as physical or virtual functions. 103 Security Capabilities describe the functions that Network Security 104 Functions (NSFs) can provide for security policy enforcement. 105 Security Capabilities are independent of the actual security policy 106 that will implement the functionality of the NSF. 108 Every NSF SHOULD be described with the set of capabilities it offers. 109 Security Capabilities enable security functionality to be described 110 in a vendor-neutral manner. Security Capabilities are a market 111 enabler, providing a way to define customized security protection by 112 unambiguously describing the security features offered by a given 113 NSF. Note that this YANG data model constructs the structure of the 114 NSF Monitoring Interface YANG data model 115 [I-D.ietf-i2nsf-nsf-monitoring-data-model] and the NSF-Facing 116 Interface YANG Data Model [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 118 This document provides an information model and the corresponding 119 YANG data model [RFC6020][RFC7950] that defines the capabilities of 120 NSFs to centrally manage the capabilities of those NSFs. The NSFs 121 can register their own capabilities into a Network Operator 122 Management (Mgmt) System (i.e., Security Controller) with this YANG 123 data model through the registration interface [RFC8329]. With the 124 database of the capabilities of those NSFs that are maintained 125 centrally, those NSFs can be more easily managed [RFC8329]. 127 This YANG data model uses an "Event-Condition-Action" (ECA) policy 128 model that is used as the basis for the design of I2NSF Policy as 129 described in [RFC8329] and Section 3.1. The "ietf-i2nsf-capability" 130 YANG module defined in this document provides the following features: 132 * Definition for event capabilities of network security functions. 134 * Definition for condition capabilities of network security 135 functions. 137 * Definition for action capabilities of network security functions. 139 * Definition for resolution strategy capabilities of network 140 security functions. 142 * Definition for default action capabilities of network security 143 functions. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 This document uses the terminology described in [RFC8329]. 155 This document follows the guidelines of [RFC8407], uses the common 156 YANG types defined in [RFC6991], and adopts the Network Management 157 Datastore Architecture (NMDA). The meaning of the symbols in tree 158 diagrams is defined in [RFC8340]. 160 3. Information Model of I2NSF NSF Capability 162 This section provides the I2NSF Capability Information Model (CapIM). 163 A CapIM is a formalization of the functionality that an NSF 164 advertises. This enables the precise specification of what an NSF 165 can do in terms of security policy enforcement, so that computer- 166 based tasks can unambiguously refer to, use, configure, and manage 167 NSFs. Capabilities MUST be defined in a vendor- and technology- 168 independent manner (i.e., regardless of the differences among vendors 169 and individual products). 171 Humans can refer to categories of security controls and understand 172 each other. For instance, network security experts agree on what is 173 meant by the terms "NAT", "filtering", and "VPN concentrator". As a 174 further example, network security experts unequivocally refer to 175 "packet filters" as stateless devices that allow or deny packet 176 forwarding based on various conditions (e.g., source and destination 177 IP addresses, source and destination ports, and IP protocol type 178 fields) [Alshaer]. 180 However, more information is required in case of other devices, like 181 stateful firewalls or application layer filters. These devices 182 filter packets or communications, but there are differences in the 183 packets and communications that they can categorize and the states 184 they maintain. Humans deal with these differences by asking more 185 questions to determine the specific category and functionality of the 186 device. Machines can follow a similar approach, which is commonly 187 referred to as question-answering [Hirschman]. In this context, the 188 CapIM and the derived data model can provide important and rich 189 information sources. 191 Analogous considerations can be applied for channel protection 192 protocols, where we all understand that they will protect packets by 193 means of symmetric algorithms whose keys could have been negotiated 194 with asymmetric cryptography, but they may work at different layers 195 and support different algorithms and protocols. To ensure 196 protection, these protocols apply integrity, optionally 197 confidentiality, anti-reply protections, and authentication. 199 The CapIM is intended to clarify these ambiguities by providing a 200 formal description of NSF functionality. The set of functions that 201 are advertised MAY be restricted according to the privileges of the 202 user or application that is viewing those functions. I2NSF 203 Capabilities enable unambiguous specification of the security 204 capabilities available in a (virtualized) networking environment, and 205 their automatic processing by means of computer-based techniques. 207 This CapIM includes enabling a security controller in an I2NSF 208 framework [RFC8329] to properly identify and manage NSFs, and allow 209 NSFs to properly declare their functionality through a Developer's 210 Management System (DMS) [RFC8329], so that they can be used in the 211 correct way. 213 3.1. Design Principles and ECA Policy Model 215 This document defines an information model for representing NSF 216 capabilities. Some basic design principles for security capabilities 217 and the systems that manage them are: 219 * Independence: Each security capability SHOULD be an independent 220 function, with minimum overlap or dependency on other 221 capabilities. This enables each security capability to be 222 utilized and assembled together freely. More importantly, changes 223 to one capability SHOULD NOT affect other capabilities. This 224 follows the Single Responsibility Principle [Martin] [OODSRP]. 226 * Abstraction: Each capability MUST be defined in a vendor- 227 independent manner. 229 * Advertisement: Registration Interface 230 [I-D.ietf-i2nsf-registration-interface-dm] MUST be used to 231 advertise and register the capabilities of each NSF. This same 232 interface MUST be used by other I2NSF Components to determine what 233 Capabilities are currently available to them. 235 * Execution: NSF-Facing Interface 236 [I-D.ietf-i2nsf-nsf-facing-interface-dm] and NSF Monitoring 237 Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] MUST be used 238 to configure the use of a capability into an NSF and monitor the 239 NSF, respectively. These provide a standardized ability to 240 describe its functionality, and report its processing results, 241 respectively. These facilitate multi-vendor interoperability. 243 * Automation: The system MUST have the ability to auto-discover, 244 auto-negotiate, and auto-update its security capabilities (i.e., 245 without human intervention). These features are especially useful 246 for the management of a large number of NSFs. They are essential 247 for adding smart services (e.g., refinement, analysis, capability 248 reasoning, and optimization) to the security scheme employed. 249 These features are supported by many design patterns, including 250 the Observer Pattern [OODOP], the Mediator Pattern [OODMP], and a 251 set of Message Exchange Patterns [Hohpe]. Registration Interface 252 [I-D.ietf-i2nsf-registration-interface-dm] can register the 253 capabilities of NSFs with the security controller from the request 254 of Developer's Management System providing NSFs and the 255 corresponding security capabilities. Also, this interface can 256 send a query to Developer's Management System in order to find an 257 NSF to satisfy the requested security capability from the security 258 controller that receives a security policy. 260 * Scalability: The management system SHOULD have the capability to 261 scale up/down or scale in/out. Thus, it can meet various 262 performance requirements derived from changeable network traffic 263 or service requests. In addition, security capabilities that are 264 affected by scalability changes SHOULD support reporting 265 statistics to the security controller to assist its decision on 266 whether it needs to invoke scaling or not. NSF Monitoring 267 Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] can observe 268 the performance of NSFs to let the security controller decide 269 scalability changes of the NSFs. 271 Based on the above principles, this document defines a capability 272 model that enables an NSF to register (and hence advertise) its set 273 of capabilities that other I2NSF Components can use. These 274 capabilities MUST have their access control restricted by a policy; 275 this is out of scope for this document. The set of capabilities 276 provided by a given set of NSFs unambiguously defines the security 277 services offered by the set of NSFs used. The security controller 278 can compare the requirements of users and applications with the set 279 of capabilities that are currently available in order to choose which 280 capabilities of which NSFs are needed to meet those requirements. 281 Note that this choice is independent of vendor, and instead relies 282 specifically on the capabilities (i.e., the description) of the 283 functions provided. 285 Furthermore, NSFs are subject to the updates of security capabilities 286 and software to cope with newly found security attacks or threats, 287 hence new capabilities may be created, and/or existing capabilities 288 may be updated (e.g., by updating its signature and algorithm). New 289 capabilities may be sent to and stored in a centralized repository, 290 or stored separately in a vendor's local repository. In either case, 291 Registration Interface can facilitate this update process to 292 Developer's Management System to let the security controller update 293 its repository for NSFs and their security capabilities. 295 The "Event-Condition-Action" (ECA) policy model in [RFC8329] is used 296 as the basis for the design of the capability model; The following 297 three terms define the structure and behavior of an I2NSF imperative 298 policy rule: 300 * Event: An Event is defined as any important occurrence in time of 301 a change in the system being managed, and/or in the environment of 302 the system being managed. When used in the context of I2NSF 303 Policy Rules, it is used to determine whether the condition clause 304 of an I2NSF Policy Rule can be evaluated or not. Examples of an 305 I2NSF Event include time and user actions (e.g., logon, logoff, 306 and actions that violate an ACL). 308 * Condition: A condition is defined as a set of attributes, 309 features, and/or values that are to be compared with a set of 310 known attributes, features, and/or values in order to determine 311 whether or not the set of actions in that (imperative) I2NSF 312 Policy Rule can be executed or not. Examples of I2NSF conditions 313 include matching attributes of a packet or flow, and comparing the 314 internal state of an NSF with a desired state. 316 * Action: An action is used to control and monitor aspects of NSFs 317 to handle packets or flows when the event and condition clauses 318 are satisfied. NSFs provide security functions by executing 319 various Actions. Examples of I2NSF actions include providing 320 intrusion detection and/or protection, web and flow filtering, and 321 deep packet inspection for packets and flows. 323 An I2NSF Policy Rule is made up of three clauses: an Event clause, a 324 Condition clause, and an Action clause. This structure is also 325 called an ECA (Event-Condition-Action) Policy Rule. A Boolean clause 326 is a logical statement that evaluates to either TRUE or FALSE. It 327 may be made up of one or more terms; if more than one term is 328 present, then each term in the Boolean clause is combined using 329 logical connectives (i.e., AND, OR, and NOT). 331 An I2NSF ECA Policy Rule has the following semantics: 333 IF is TRUE 335 IF is TRUE 337 THEN execute [constrained by metadata] 339 END-IF 341 END-IF 343 Technically, the "Policy Rule" is really a container that aggregates 344 the above three clauses, as well as metadata, which describe the 345 characteristics and behaviors of a capability (or an NSF). 346 Aggregating metadata enables a business logic to be used to prescribe 347 a behavior. For example, suppose a particular ECA Policy Rule 348 contains three actions (A1, A2, and A3, in that order). Action A2 349 has a priority of 10; actions A1 and A3 have no priority specified. 350 Then, metadata may be used to restrict the set of actions that can be 351 executed when the event and condition clauses of this ECA Policy Rule 352 are evaluated to be TRUE; two examples are: (1) only the first action 353 (A1) is executed, and then the policy rule returns to its caller, or 354 (2) all actions are executed, starting with the highest priority. 356 The above ECA policy model is very general and easily extensible. 358 3.2. Conflict, Resolution Strategy and Default Action 360 Formally, two I2NSF Policy Rules conflict with each other if: 362 * the Event Clauses of each evaluate to TRUE; 364 * the Condition Clauses of each evaluate to TRUE; 366 * the Action Clauses affect the same object in different ways. 368 For example, if we have two Policy Rules called R1 and R2 in the same 369 Policy: 371 R1: During 8am-6pm, if traffic is external, then run through 372 firewall 374 R2: During 7am-8pm, run anti-virus 376 There is no conflict between the two policy rules R1 and R2, since 377 the actions are different. However, consider these two rules called 378 R3 and R4: 380 R3: During 9am-6pm, allow John to access social networking service 381 websites 383 R4: During 9am-6pm, disallow all users to access social networking 384 service websites 386 The two policy rules R3 and R4 are now in conflict, between the hours 387 of 9am and 6pm, because the actions of R3 and R4 are different and 388 apply to the same user (i.e., John). 390 Conflicts theoretically compromise the correct functioning of 391 devices. However, NSFs have been designed to cope with these issues. 392 Since conflicts are originated by simultaneously matching rules, an 393 additional process decides the action to be applied, e.g., among the 394 actions which the matching rule would have enforced. This process is 395 described by means of a resolution strategy for conflicts. The 396 finding and handling of conflicted matching rules is performed by 397 resolution strategies in the security controller. The implementation 398 of such resolution strategies is out of scope for I2NSF. 400 On the other hand, it may happen that, if an event is caught, none of 401 the policy rules matches the condition. Note that a packet or flow 402 is handled only when it matches both the event and condition of a 403 policy rule according to the ECA policy model. As a simple case, no 404 condition in the rules may match a packet arriving at the border 405 firewall. In this case, the packet is usually dropped, that is, the 406 firewall has a default behavior of packet dropping in order to manage 407 the cases that are not covered by specific rules. 409 Therefore, this document introduces two further capabilities for an 410 NSF to handle security policy conflicts with resolution strategies 411 and enforce a default action if no rules match. 413 * Resolution Strategies: They can be used to specify how to resolve 414 conflicts that occur between the actions of the same or different 415 policy rules that are matched and contained in this particular 416 NSF; 418 * Default Action: It provides the default behavior to be executed 419 when there are no other alternatives. This action can be either 420 an explicit action or a set of actions. 422 4. Overview of YANG Data Model 424 This section provides an overview of how the YANG data model can be 425 used in the I2NSF framework described in [RFC8329]. Figure 1 shows 426 the capabilities (e.g., firewall and web filter) of NSFs in the I2NSF 427 Framework. As shown in this figure, a Developer's Management System 428 (DMS) can register NSFs and their capabilities with a Security 429 Controller. To register NSFs in this way, the DMS utilizes the 430 standardized capability YANG data model in this document through the 431 I2NSF Registration Interface [RFC8329]. That is, this Registration 432 Interface uses the YANG module described in this document to describe 433 the capabilities of an NSF that is registered with the Security 434 Controller. As described in [RFC8192], with the usage of 435 Registration Interface and the YANG module in this document, the NSFs 436 manufactured by multiple vendors can be managed together by the 437 Security Controller in a centralized way and be updated dynamically 438 by each vendor as the NSF has software or hardware updates. 440 In Figure 1, a new NSF at a Developer's Management System has 441 capabilities of Firewall (FW) and Web Filter (WF), which are denoted 442 as (Cap = {FW, WF}), to support Event-Condition-Action (ECA) policy 443 rules where 'E', 'C', and 'A' mean "Event", "Condition", and 444 "Action", respectively. The condition involves IPv4 or IPv6 445 datagrams, and the action includes "Allow" and "Deny" for those 446 datagrams. 448 Note that the NSF-Facing Interface [RFC8329] is used by the Security 449 Controller to configure the security policy rules of NSFs (e.g., 450 firewall and Distributed-Denial-of-Service (DDoS) attack mitigator) 451 with the capabilities of the NSFs registered with the Security 452 Controller. 454 +------------------------------------------------------+ 455 | I2NSF User (e.g., Overlay Network Mgmt, Enterprise | 456 | Network Mgmt, another network domain's mgmt, etc.) | 457 +--------------------+---------------------------------+ 458 I2NSF ^ 459 Consumer-Facing Interface | 460 | 461 v I2NSF 462 +-----------------+------------+ Registration +-------------+ 463 | Network Operator Mgmt System | Interface | Developer's | 464 | (i.e., Security Controller) |<------------->| Mgmt System | 465 +-----------------+------------+ +-------------+ 466 ^ New NSF 467 | Cap = {FW, WF} 468 I2NSF | E = {} 469 NSF-Facing Interface | C = {IPv4, IPv6} 470 | A = {Allow, Deny} 471 v 472 +---------------+----+------------+-----------------+ 473 | | | | 474 +---+---+ +---+---+ +---+---+ +---+---+ 475 | NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-n | 476 +-------+ +-------+ +-------+ +-------+ 477 NSF-1 NSF-m NSF-1 NSF-n 478 Cap = {FW, WF} Cap = {FW, WF} Cap = {FW, WF} Cap = {FW, WF} 479 E = {} E = {user} E = {dev} E = {time} 480 C = {IPv4} C = {IPv6} C = {IPv4, IPv6} C = {IPv4} 481 A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} 483 Developer's Mgmt System A Developer's Mgmt System B 485 Figure 1: Capabilities of NSFs in I2NSF Framework 487 A use case of an NSF with the capabilities of firewall and web filter 488 is described as follows. 490 * If a network administrator wants to apply security policy rules to 491 block malicious users with firewall and web filter, it is a 492 tremendous burden for a network administrator to apply all of the 493 needed rules to NSFs one by one. This problem can be resolved by 494 managing the capabilities of NSFs as described in this document. 496 * If a network administrator wants to block IPv4 or IPv6 packets 497 from malicious users, the network administrator sends a security 498 policy rule to block the users to the Network Operator Management 499 System (i.e., Security Controller) using the I2NSF Consumer-Facing 500 Interface. 502 * When the Network Operator Management System receives the security 503 policy rule, it automatically sends that security policy rule to 504 appropriate NSFs (i.e., NSF-m in Developer's Management System A 505 and NSF-1 in Developer's Management System B) which can support 506 the capabilities (i.e., IPv6). This lets an I2NSF User not 507 consider which specific NSF(s) will work for the security policy 508 rule. 510 * If NSFs encounter the suspicious IPv4 or IPv6 packets of malicious 511 users, they can filter the packets out according to the configured 512 security policy rule. Therefore, the security policy rule against 513 the malicious users' packets can be automatically applied to 514 appropriate NSFs without human intervention. 516 5. YANG Tree Diagram 518 This section shows a YANG tree diagram of capabilities of network 519 security functions, as defined in the Section 3. 521 5.1. Network Security Function (NSF) Capabilities 523 This section explains a YANG tree diagram of NSF capabilities and its 524 features. Figure 2 shows a YANG tree diagram of NSF capabilities. 525 The NSF capabilities in the tree include time capabilities, event 526 capabilities, condition capabilities, action capabilities, resolution 527 strategy capabilities, and default action capabilities. Those 528 capabilities can be tailored or extended according to a vendor's 529 specific requirements. Refer to the NSF capabilities information 530 model for detailed discussion in Section 3. 532 module: ietf-i2nsf-capability 533 +--rw nsf* [nsf-name] 534 +--rw nsf-name string 535 +--rw directional-capabilities* identityref 536 +--rw event-capabilities 537 | +--rw system-event-capability* identityref 538 | +--rw system-alarm-capability* identityref 539 | +--rw time-capabilities* identityref 540 +--rw condition-capabilities 541 | +--rw generic-nsf-capabilities 542 | | +--rw ethernet-capability* identityref 543 | | +--rw ipv4-capability* identityref 544 | | +--rw ipv6-capability* identityref 545 | | +--rw icmpv4-capability* identityref 546 | | +--rw icmpv6-capability* identityref 547 | | +--rw tcp-capability* identityref 548 | | +--rw udp-capability* identityref 549 | | +--rw sctp-capability* identityref 550 | | +--rw dccp-capability* identityref 551 | +--rw advanced-nsf-capabilities 552 | | +--rw anti-ddos-capability* identityref 553 | | +--rw ips-capability* identityref 554 | | +--rw anti-virus-capability* identityref 555 | | +--rw url-capability* identityref 556 | | +--rw voip-volte-filtering-capability* identityref 557 | +--rw context-capabilities 558 | +--rw application-filter-capabilities* identityref 559 | +--rw target-capabilities* identityref 560 | +--rw user-condition-capabilities* identityref 561 | +--rw geography-capabilities* identityref 562 +--rw action-capabilities 563 | +--rw ingress-action-capability* identityref 564 | +--rw egress-action-capability* identityref 565 | +--rw log-action-capability* identityref 566 +--rw resolution-strategy-capabilities* identityref 567 +--rw default-action-capabilities* identityref 569 Figure 2: YANG Tree Diagram of Capabilities of Network Security 570 Functions 572 The data model in this document provides identities for the 573 capabilities of NSFs. Every identity in the data model represents 574 the capability of an NSF. Each identity is explained in the 575 description of the identity. 577 Event capabilities are used to specify the capabilities that describe 578 an event that would trigger the evaluation of the condition clause of 579 the I2NSF Policy Rule. The defined event capabilities are system 580 event, system alarm, and time. Time capabilities are used to specify 581 the capabilities which describe when to execute the I2NSF policy 582 rule. The time capabilities are defined in terms of absolute time 583 and periodic time. The absolute time means the exact time to start 584 or end. The periodic time means repeated time like day, week, month, 585 or year. 587 Condition capabilities are used to specify capabilities of a set of 588 attributes, features, and/or values that are to be compared with a 589 set of known attributes, features, and/or values in order to 590 determine whether a set of actions needs to be executed or not so 591 that an imperative I2NSF policy rule can be executed. In this 592 document, two kinds of condition capabilities are used to classify 593 different capabilities of NSFs such as generic-nsf-capabilities and 594 advanced-nsf-capabilities. First, the generic-nsf-capabilities 595 define NSFs that operate on packet header for layer 2 (i.e., Ethernet 596 capability), layer 3 (i.e., IPv4 capability, IPv6 capability, ICMPv4 597 capability, and ICMPv6 capability.), and layer 4 (i.e., TCP 598 capability, UDP capability, SCTP capability, and DCCP capability). 599 Second, the advanced-nsf-capabilities define NSFs that operate on 600 features different from the generic-nsf-capabilities, e.g., the 601 payload, cross flow state, application layer, traffic statistics, 602 network behavior, etc. This document defines the advanced-nsf into 603 two categories such as content-security-control and attack- 604 mitigation-control. 606 * Content security control is an NSF that evaluates the payload of a 607 packet, such as Intrusion Prevention System (IPS), URL-Filtering, 608 Antivirus, and VoIP/VoLTE Filter. 610 * Attack mitigation control is an NSF that mitigates an attack such 611 as anti-DDoS (DDoS-mitigator). 613 The advanced-nsf can be extended with other types of NSFs. This 614 document only provides five advanced-nsf capabilities, i.e., IPS 615 capability, URL-Filtering capability, Antivirus capability, VoIP/ 616 VoLTE Filter capability, and Anti-DDoS capability. Note that VoIP 617 and VoLTE are merged into a single capability in this document 618 because VoIP and VoLTE use the Session Initiation Protocol (SIP) 619 [RFC3261] for a call setup. See Section 3.1 for more information 620 about the condition in the ECA policy model. 622 The context capabilities provide extra information for the condition. 623 The given context conditions are application filter, target, user 624 condition, and geography location. The application filter capability 625 is capability in matching the packet based on the application 626 protocol, such as HTTP, HTTPS, FTP, etc. The target capability is 627 capability in matching the type of the target devices, such as PC, 628 IoT, Network Infrastructure devices, etc. The user condition is 629 capability in matching the users of the network by mapping each user 630 ID to an IP address. Users can be combined into one group. The 631 geography location capability is capability in matching the 632 geographical location of a source or destination of a packet. 634 Action capabilities are used to specify the capabilities that 635 describe the control and monitoring aspects of flow-based NSFs when 636 the event and condition clauses are satisfied. The action 637 capabilities are defined as ingress-action capability, egress-action 638 capability, and log-action capability. See Section 3.1 for more 639 information about the action in the ECA policy model. Also, see 640 Section 7.2 (NSF-Facing Flow Security Policy Structure) in [RFC8329] 641 for more information about the ingress and egress actions. In 642 addition, see Section 9.1 (Flow-Based NSF Capability 643 Characterization) in [RFC8329] and Section 7.5 (NSF Logs) in 644 [I-D.ietf-i2nsf-nsf-monitoring-data-model] for more information about 645 logging at NSFs. 647 Resolution strategy capabilities are used to specify the capabilities 648 that describe conflicts that occur between the actions of the same or 649 different policy rules that are matched and contained in this 650 particular NSF. The resolution strategy capabilities are defined as 651 First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized 652 Matching Rule (PMR), Prioritized Matching Rule with Errors (PMRE), 653 and Prioritized Matching Rule with No Errors (PMRN). See Section 3.2 654 for more information about the resolution strategy. 656 Default action capabilities are used to specify the capabilities that 657 describe how to execute I2NSF policy rules when no rule matches a 658 packet. The default action capabilities are defined as pass, drop, 659 rate-limit, and mirror. See Section 3.2 for more information about 660 the default action. 662 6. YANG Data Model of I2NSF NSF Capability 664 This section introduces a YANG module for NSFs' capabilities, as 665 defined in the Section 3. 667 It makes references to 669 * [RFC0768] 671 * [RFC0791] 672 * [RFC0792] 674 * [RFC0854] 676 * [RFC0959] 678 * [RFC1939] 680 * [RFC2474] 682 * [RFC2818] 684 * [RFC3168] 686 * [RFC3261] 688 * [RFC3501] 690 * [RFC4250] 692 * [RFC4340] 694 * [RFC4443] 696 * [RFC4766] 698 * [RFC4960] 700 * [RFC5103] 702 * [RFC5321] 704 * [RFC5595] 706 * [RFC6335] 708 * [RFC6437] 710 * [RFC6691] 712 * [RFC6864] 714 * [RFC7230] 716 * [RFC7231] 718 * [RFC7323] 719 * [RFC8200] 721 * [RFC8329] 723 * [RFC8805] 725 * [IEEE802.3-2018] 727 * [IANA-Protocol-Numbers] 729 * [I-D.ietf-tcpm-rfc793bis] 731 * [I-D.ietf-tcpm-accurate-ecn] 733 * [I-D.ietf-tsvwg-udp-options] 735 * [I-D.ietf-i2nsf-nsf-monitoring-data-model] 737 file "ietf-i2nsf-capability@2021-10-04.yang" 738 module ietf-i2nsf-capability { 739 yang-version 1.1; 740 namespace 741 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; 742 prefix 743 nsfcap; 745 organization 746 "IETF I2NSF (Interface to Network Security Functions) 747 Working Group"; 749 contact 750 "WG Web: 751 WG List: 753 Editor: Susan Hares 754 756 Editor: Jaehoon (Paul) Jeong 757 759 Editor: Jinyong (Tim) Kim 760 762 Editor: Robert Moskowitz 763 765 Editor: Qiushi Lin 766 767 Editor: Patrick Lingga 768 "; 770 description 771 "This module is a YANG module for I2NSF Network Security 772 Functions (NSFs)'s Capabilities. 774 Copyright (c) 2021 IETF Trust and the persons identified as 775 authors of the code. All rights reserved. 777 Redistribution and use in source and binary forms, with or 778 without modification, is permitted pursuant to, and subject to 779 the license terms contained in, the Simplified BSD License set 780 forth in Section 4.c of the IETF Trust's Legal Provisions 781 Relating to IETF Documents 782 (https://trustee.ietf.org/license-info). 784 This version of this YANG module is part of RFC XXXX 785 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 786 for full legal notices."; 788 // RFC Ed.: replace XXXX with an actual RFC number and remove 789 // this note. 791 revision "2021-10-04"{ 792 description "Initial revision."; 793 reference 794 "RFC XXXX: I2NSF Capability YANG Data Model"; 796 // RFC Ed.: replace XXXX with an actual RFC number and remove 797 // this note. 798 } 800 /* 801 * Identities 802 */ 804 identity event { 805 description 806 "Base identity for I2NSF events."; 807 reference 808 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 809 Monitoring YANG Data Model - Event"; 810 } 812 identity system-event { 813 base event; 814 description 815 "Identity for system event"; 816 reference 817 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 818 Monitoring YANG Data Model - System event"; 819 } 821 identity system-alarm { 822 base event; 823 description 824 "Identity for system alarm"; 825 reference 826 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 827 Monitoring YANG Data Model - System alarm"; 828 } 830 identity time { 831 base event; 832 description 833 "Identity for time capabilities"; 834 } 836 identity access-violation { 837 base system-event; 838 description 839 "Identity for access violation event"; 840 reference 841 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 842 Monitoring YANG Data Model - System event for access 843 violation"; 844 } 846 identity configuration-change { 847 base system-event; 848 description 849 "Identity for configuration change event"; 850 reference 851 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 852 Monitoring YANG Data Model - System event for configuration 853 change"; 854 } 856 identity memory-alarm { 857 base system-alarm; 858 description 859 "Identity for memory alarm. Alarm when memory usage 860 exceeds a threshold."; 861 reference 862 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 863 Monitoring YANG Data Model - System alarm for memory"; 864 } 866 identity cpu-alarm { 867 base system-alarm; 868 description 869 "Identity for CPU alarm. Alarm when CPU usage 870 exceeds a threshold."; 871 reference 872 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 873 Monitoring YANG Data Model - System alarm for CPU"; 874 } 876 identity disk-alarm { 877 base system-alarm; 878 description 879 "Identity for disk alarm. Alarm when disk usage 880 exceeds a threshold."; 881 reference 882 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 883 Monitoring YANG Data Model - System alarm for disk"; 884 } 886 identity hardware-alarm { 887 base system-alarm; 888 description 889 "Identity for hardware alarm. Alarm when a hardware failure 890 or hardware degradation occurs."; 891 reference 892 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 893 Monitoring YANG Data Model - System alarm for hardware"; 894 } 896 identity interface-alarm { 897 base system-alarm; 898 description 899 "Identity for interface alarm. Alarm when interface usage 900 exceeds a threshold."; 901 reference 902 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 903 Monitoring YANG Data Model - System alarm for interface"; 904 } 906 identity absolute-time { 907 base time; 908 description 909 "absolute time capabilities. 910 If a network security function has the absolute time 911 capability, the network security function supports 912 rule execution according to absolute time."; 913 } 915 identity periodic-time { 916 base time; 917 description 918 "periodic time capabilities. 919 If a network security function has the periodic time 920 capability, the network security function supports 921 rule execution according to periodic time."; 922 } 924 identity target-device { 925 description 926 "Identity for target condition capability. The capability for 927 matching the target device type."; 928 } 930 identity computer { 931 base target-device; 932 description 933 "Identity for computer such as personal computer (PC) 934 and server"; 935 } 937 identity mobile-phone { 938 base target-device; 939 description 940 "Identity for mobile-phone such as smartphone and 941 cellphone"; 942 } 944 identity voip-volte-phone { 945 base target-device; 946 description 947 "Identity for voip-volte-phone"; 948 } 950 identity tablet { 951 base target-device; 952 description 953 "Identity for tablet"; 954 } 956 identity network-infrastructure-device { 957 base target-device; 958 description 959 "Identity for network infrastructure devices 960 such as switch, router, and access point"; 961 } 963 identity iot { 964 base target-device; 965 description 966 "Identity for IoT (Internet of Things)"; 967 } 969 identity ot { 970 base target-device; 971 description 972 "Identity for Operational Technology"; 973 } 975 identity vehicle { 976 base target-device; 977 description 978 "Identity for vehicle that connects to and shares 979 data through the Internet"; 980 } 982 identity user-condition { 983 description 984 "Base identity for user condition capability. This is the 985 capability of mapping user(s) into their corresponding IP 986 address"; 987 } 989 identity user { 990 base user-condition; 991 description 992 "Identity for user condition capability. 993 A user (e.g., employee) can be mapped to an IP address of 994 a computing device (e.g., computer, laptop, and virtual 995 machine) which the user is using."; 996 } 998 identity group { 999 base user-condition; 1000 description 1001 "Identity for group condition capability. 1002 A group (e.g., employees) can be mapped to multiple IP 1003 addresses of computing devices (e.g., computers, laptops, 1004 and virtual machines) which the group is using."; 1005 } 1006 identity geography-location { 1007 description 1008 "Identity for geography condition capability"; 1009 reference 1010 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1011 An access control for a geographical location (i.e., 1012 geolocation) that has the corresponding IP prefix."; 1013 } 1015 identity source-location { 1016 base geography-location; 1017 description 1018 "Identity for source geography location condition capability"; 1019 reference 1020 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1021 An access control for a geographical location (i.e., 1022 geolocation) that has the corresponding IP prefix."; 1023 } 1025 identity destination-location { 1026 base geography-location; 1027 description 1028 "Identity for destination geography location condition 1029 capability"; 1030 reference 1031 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1032 An access control for a geographical location (i.e., 1033 geolocation) that has the corresponding IP prefix."; 1034 } 1036 identity directional { 1037 description 1038 "Base identity for directional traffic flow capability"; 1039 reference 1040 "RFC 5103: Bidirectional Flow Export Using IP Flow Information 1041 Export (IPFIX) - Terminology Unidirectional and Bidirectional 1042 Flow"; 1043 } 1045 identity unidirectional { 1046 base directional; 1047 description 1048 "Identity for unidirectional traffic flow."; 1049 reference 1050 "RFC 5103: Bidirectional Flow Export Using IP Flow Information 1051 Export (IPFIX) - Terminology Unidirectional Flow"; 1052 } 1053 identity bidirectional { 1054 base directional; 1055 description 1056 "Identity for bidirectional traffic flow."; 1057 reference 1058 "RFC 5103: Bidirectional Flow Export Using IP Flow Information 1059 Export (IPFIX) - Terminology Bidirectional Flow"; 1060 } 1062 identity protocol { 1063 description 1064 "Base identity for protocols"; 1065 } 1067 identity ethernet { 1068 base protocol; 1069 description 1070 "Base identity for Ethernet protocol."; 1071 } 1073 identity source-mac-address { 1074 base ethernet; 1075 description 1076 "Identity for the capability of matching Media Access Control 1077 (MAC) source address(es) condition capability."; 1078 reference 1079 "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; 1080 } 1082 identity destination-mac-address { 1083 base ethernet; 1084 description 1085 "Identity for the capability of matching Media Access Control 1086 (MAC) destination address(es) condition capability."; 1087 reference 1088 "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; 1089 } 1091 identity ether-type { 1092 base ethernet; 1093 description 1094 "Identity for the capability of matching the EtherType in 1095 Ethernet II and Length in Ethernet 802.3 of a packet."; 1096 reference 1097 "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; 1098 } 1100 identity ip { 1101 base protocol; 1102 description 1103 "Base identity for internet/network layer protocol, 1104 e.g., IPv4, IPv6, and ICMP."; 1105 } 1107 identity ipv4 { 1108 base ip; 1109 description 1110 "Base identity for IPv4 condition capability"; 1111 reference 1112 "RFC 791: Internet Protocol"; 1113 } 1115 identity ipv6 { 1116 base ip; 1117 description 1118 "Base identity for IPv6 condition capabilities"; 1119 reference 1120 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1121 Specification"; 1122 } 1124 identity dscp { 1125 base ipv4; 1126 base ipv6; 1127 description 1128 "Identity for the capability of matching IPv4 annd IPv6 1129 Differentiated Services Codepoint (DSCP) condition"; 1130 reference 1131 "RFC 791: Internet Protocol - Type of Service 1132 RFC 2474: Definition of the Differentiated 1133 Services Field (DS Field) in the IPv4 and 1134 IPv6 Headers 1135 RFC 8200: Internet Protocol, Version 6 (IPv6) 1136 Specification - Traffic Class"; 1137 } 1139 identity length { 1140 base ipv4; 1141 base ipv6; 1142 description 1143 "Identity for the capability of matching IPv4 Total Length 1144 header field or IPv6 Payload Length header field. 1146 IPv4 Total Length is the length of datagram, measured in 1147 octets, including internet header and data. 1149 IPv6 Payload Length is the length of the IPv6 payload, i.e., 1150 the rest of the packet following the IPv6 header, measured in 1151 octets."; 1152 reference 1153 "RFC 791: Internet Protocol - Total Length 1154 RFC 8200: Internet Protocol, Version 6 (IPv6) 1155 Specification - Payload Length"; 1156 } 1158 identity ttl { 1159 base ipv4; 1160 base ipv6; 1161 description 1162 "Identity for the capability of matching IPv4 Time-To-Live 1163 (TTL) or IPv6 Hop Limit."; 1164 reference 1165 "RFC 791: Internet Protocol - Time To Live (TTL) 1166 RFC 8200: Internet Protocol, Version 6 (IPv6) 1167 Specification - Hop Limit"; 1168 } 1170 identity next-header { 1171 base ipv4; 1172 base ipv6; 1173 description 1174 "Identity for the capability of matching IPv4 Protocol Field or 1175 equivalent to IPv6 Next Header."; 1176 reference 1177 "IANA Website: Assigned Internet Protocol Numbers 1178 - Protocol Number for IPv4 1179 RFC 791: Internet Protocol - Protocol 1180 RFC 8200: Internet Protocol, Version 6 (IPv6) 1181 Specification - Next Header"; 1182 } 1184 identity source-address { 1185 base ipv4; 1186 base ipv6; 1187 description 1188 "Identity for the capability of matching IPv4 or IPv6 source 1189 address(es) condition capability."; 1190 reference 1191 "RFC 791: Internet Protocol - Address 1192 RFC 8200: Internet Protocol, Version 6 (IPv6) 1193 Specification - Source Address"; 1194 } 1196 identity destination-address { 1197 base ipv4; 1198 base ipv6; 1199 description 1200 "Identity for the capability of matching IPv4 or IPv6 1201 destination address(es) condition capability."; 1202 reference 1203 "RFC 791: Internet Protocol - Address 1204 RFC 8200: Internet Protocol, Version 6 (IPv6) 1205 Specification - Destination Address"; 1206 } 1208 identity flow-direction { 1209 base ipv4; 1210 base ipv6; 1211 description 1212 "Identity for flow direction of matching IPv4/IPv6 source 1213 or destination address(es) condition capability where a flow's 1214 direction is either unidirectional or bidirectional"; 1215 reference 1216 "RFC 791: Internet Protocol 1217 RFC 8200: Internet Protocol, Version 6 (IPv6) 1218 Specification"; 1219 } 1221 identity header-length { 1222 base ipv4; 1223 description 1224 "Identity for matching IPv4 header-length 1225 condition capability"; 1226 reference 1227 "RFC 791: Internet Protocol - Header Length"; 1228 } 1230 identity identification { 1231 base ipv4; 1232 description 1233 "Identity for IPv4 identification condition capability. 1234 IPv4 ID field is used for fragmentation and reassembly."; 1235 reference 1236 "RFC 791: Internet Protocol - Identification 1237 RFC 6864: Updated Specification of the IPv4 ID Field - 1238 Fragmentation and Reassembly"; 1239 } 1241 identity fragment-flags { 1242 base ipv4; 1243 description 1244 "Identity for IPv4 fragment flags condition capability"; 1246 reference 1247 "RFC 791: Internet Protocol - Fragmentation Flags"; 1248 } 1250 identity fragment-offset { 1251 base ipv4; 1252 description 1253 "Identity for matching IPv4 fragment offset 1254 condition capability"; 1255 reference 1256 "RFC 791: Internet Protocol - Fragmentation Offset"; 1257 } 1259 identity ipv4-options { 1260 base ipv4; 1261 description 1262 "Identity for IPv4 options condition capability"; 1263 reference 1264 "RFC 791: Internet Protocol - Options"; 1265 } 1267 identity flow-label { 1268 base ipv6; 1269 description 1270 "Identity for matching IPv6 flow label 1271 condition capability"; 1272 reference 1273 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1274 Specification - Flow Label 1275 RFC 6437: IPv6 Flow Label Specification"; 1276 } 1278 identity header-order { 1279 base ipv6; 1280 description 1281 "Identity for IPv6 extension header order condition 1282 capability"; 1283 reference 1284 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1285 Specification - Extension Header Order"; 1286 } 1288 identity hop-by-hop { 1289 base ipv6; 1290 description 1291 "Identity for IPv6 hop by hop options header 1292 condition capability"; 1293 reference 1294 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1296 Specification - Options"; 1297 } 1299 identity routing-header { 1300 base ipv6; 1301 description 1302 "Identity for IPv6 routing header condition 1303 capability"; 1304 reference 1305 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1306 Specification - Routing Header"; 1307 } 1309 identity fragment-header { 1310 base ipv6; 1311 description 1312 "Identity for IPv6 fragment header condition 1313 capability"; 1314 reference 1315 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1316 Specification - Fragment Header"; 1317 } 1319 identity destination-options { 1320 base ipv6; 1321 description 1322 "Identity for IPv6 destination options condition 1323 capability"; 1324 reference 1325 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1326 Specification - Destination Options"; 1327 } 1329 identity icmp { 1330 base protocol; 1331 description 1332 "Base identity for ICMPv4 and ICMPv6 condition capability"; 1333 reference 1334 "RFC 792: Internet Control Message Protocol 1335 RFC 4443: Internet Control Message Protocol (ICMPv6) 1336 for the Internet Protocol Version 6 (IPv6) Specification 1337 - ICMPv6"; 1338 } 1340 identity icmpv4 { 1341 base icmp; 1342 description 1343 "Base identity for ICMPv4 condition capability"; 1344 reference 1345 "RFC 792: Internet Control Message Protocol"; 1346 } 1348 identity icmpv6 { 1349 base icmp; 1350 description 1351 "Base identity for ICMPv6 condition capability"; 1352 reference 1353 "RFC 4443: Internet Control Message Protocol (ICMPv6) 1354 for the Internet Protocol Version 6 (IPv6) Specification 1355 - ICMPv6"; 1356 } 1358 identity type { 1359 base icmpv4; 1360 base icmpv6; 1361 description 1362 "Identity for ICMPv4 and ICMPv6 type condition capability"; 1363 reference 1364 "RFC 792: Internet Control Message Protocol 1365 RFC 4443: Internet Control Message Protocol (ICMPv6) 1366 for the Internet Protocol Version 6 (IPv6) Specification 1367 - ICMPv6"; 1368 } 1370 identity code { 1371 base icmpv4; 1372 base icmpv6; 1373 description 1374 "Identity for ICMPv4 and ICMPv6 code condition capability"; 1375 reference 1376 "RFC 792: Internet Control Message Protocol 1377 RFC 4443: Internet Control Message Protocol (ICMPv6) 1378 for the Internet Protocol Version 6 (IPv6) Specification 1379 - ICMPv6"; 1380 } 1382 identity transport-protocol { 1383 base protocol; 1384 description 1385 "Base identity for Layer 4 protocol condition capabilities, 1386 e.g., TCP, UDP, SCTP, and DCCP"; 1387 } 1389 identity tcp { 1390 base transport-protocol; 1391 description 1392 "Base identity for TCP condition capabilities"; 1393 reference 1394 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1395 (TCP) Specification"; 1396 } 1398 identity udp { 1399 base transport-protocol; 1400 description 1401 "Base identity for UDP condition capabilities"; 1402 reference 1403 "RFC 768: User Datagram Protocol"; 1404 } 1406 identity sctp { 1407 base transport-protocol; 1408 description 1409 "Identity for SCTP condition capabilities"; 1410 reference 1411 "RFC 4960: Stream Control Transmission Protocol"; 1412 } 1414 identity dccp { 1415 base transport-protocol; 1416 description 1417 "Identity for DCCP condition capabilities"; 1418 reference 1419 "RFC 4340: Datagram Congestion Control Protocol"; 1420 } 1422 identity source-port-number { 1423 base tcp; 1424 base udp; 1425 base sctp; 1426 base dccp; 1427 description 1428 "Identity for matching TCP, UDP, SCTP, and DCCP source port 1429 number condition capability"; 1430 reference 1431 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1432 (TCP) Specification 1433 RFC 768: User Datagram Protocol 1434 RFC 4960: Stream Control Transmission Protocol 1435 RFC 4340: Datagram Congestion Control Protocol"; 1436 } 1437 identity destination-port-number { 1438 base tcp; 1439 base udp; 1440 base sctp; 1441 base dccp; 1442 description 1443 "Identity for matching TCP, UDP, SCTP, and DCCP destination 1444 port number condition capability"; 1445 reference 1446 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1447 (TCP) Specification"; 1448 } 1450 identity flags { 1451 base tcp; 1452 description 1453 "Identity for TCP control bits (flags) condition capability"; 1454 reference 1455 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1456 (TCP) Specification - TCP Header Flags 1457 RFC 3168: The Addition of Explicit Congestion Notification 1458 (ECN) to IP - ECN-Echo (ECE) Flag and Congestion Window 1459 Reduced (CWR) Flag 1460 draft-ietf-tcpm-accurate-ecn-15: More Accurate ECN Feedback 1461 in TCP - ECN-Echo (ECE) Flag and Congestion Window Reduced 1462 (CWR) Flag"; 1463 } 1465 identity tcp-options { 1466 base tcp; 1467 description 1468 "Identity for TCP options condition capability."; 1469 reference 1470 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1471 (TCP) Specification 1472 RFC 6691: TCP Options and Maximum Segment Size 1473 RFC 7323: TCP Extensions for High Performance"; 1474 } 1476 identity total-length { 1477 base udp; 1478 description 1479 "Identity for matching UDP total-length condition capability. 1480 The UDP total length can be smaller than the IP transport 1481 length for UDP transport layer options."; 1482 reference 1483 "RFC 768: User Datagram Protocol - Total Length 1484 draft-ietf-tsvwg-udp-options: Transport Options for UDP"; 1486 } 1488 identity verification-tag { 1489 base sctp; 1490 description 1491 "Identity for range-match SCTP verification tag condition 1492 capability"; 1493 reference 1494 "RFC 4960: Stream Control Transmission Protocol - Verification 1495 Tag"; 1496 } 1498 identity chunk-type { 1499 base sctp; 1500 description 1501 "Identity for SCTP chunk type condition capability"; 1502 reference 1503 "RFC 4960: Stream Control Transmission Protocol - Chunk Type"; 1504 } 1506 identity service-code { 1507 base dccp; 1508 description 1509 "Identity for DCCP Service Code condition capabilitiy"; 1510 reference 1511 "RFC 4340: Datagram Congestion Control Protocol 1512 RFC 5595: The Datagram Congestion Control Protocol (DCCP) 1513 Service Codes 1514 RFC 6335: Internet Assigned Numbers Authority (IANA) 1515 Procedures for the Management of the Service Name and 1516 Transport Protocol Port Number Registry - Service Code"; 1517 } 1519 identity application-protocol { 1520 base protocol; 1521 description 1522 "Base identity for Application protocol"; 1523 } 1525 identity http { 1526 base application-protocol; 1527 description 1528 "The identity for Hypertext Transfer Protocol."; 1529 reference 1530 "RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1531 Syntax and Routing 1532 RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1533 and Content"; 1535 } 1537 identity https { 1538 base application-protocol; 1539 description 1540 "The identity for Hypertext Transfer Protocol Secure."; 1541 reference 1542 "RFC 2818: HTTP over TLS (HTTPS) 1543 RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1544 Syntax and Routing 1545 RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1546 and Content"; 1547 } 1549 identity ftp { 1550 base application-protocol; 1551 description 1552 "The identity for File Transfer Protocol."; 1553 reference 1554 "RFC 959: File Transfer Protocol (FTP)"; 1555 } 1557 identity ssh { 1558 base application-protocol; 1559 description 1560 "The identity for Secure Shell (SSH) protocol."; 1561 reference 1562 "RFC 4250: The Secure Shell (SSH) Protocol"; 1563 } 1565 identity telnet { 1566 base application-protocol; 1567 description 1568 "The identity for telnet."; 1569 reference 1570 "RFC 854: Telnet Protocol"; 1571 } 1573 identity smtp { 1574 base application-protocol; 1575 description 1576 "The identity for Simple Mail Transfer Protocol."; 1577 reference 1578 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1579 } 1581 identity pop3 { 1582 base application-protocol; 1583 description 1584 "The identity for Post Office Protocol 3."; 1585 reference 1586 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1587 } 1589 identity imap { 1590 base application-protocol; 1591 description 1592 "The identity for Internet Message Access Protocol."; 1593 reference 1594 "RFC 3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"; 1595 } 1597 identity action { 1598 description 1599 "Base identity for action capability"; 1600 } 1602 identity log-action { 1603 base action; 1604 description 1605 "Base identity for log-action capability"; 1606 } 1608 identity ingress-action { 1609 base action; 1610 description 1611 "Base identity for ingress-action capability"; 1612 reference 1613 "RFC 8329: Framework for Interface to Network Security 1614 Functions - Section 7.2"; 1615 } 1617 identity egress-action { 1618 base action; 1619 description 1620 "Base identity for egress-action capability"; 1621 reference 1622 "RFC 8329: Framework for Interface to Network Security 1623 Functions - Section 7.2"; 1624 } 1626 identity default-action { 1627 base action; 1628 description 1629 "Base identity for default-action capability"; 1630 } 1631 identity rule-log { 1632 base log-action; 1633 description 1634 "Identity for rule log-action capability. 1635 Log the received packet based on the rule"; 1636 } 1638 identity session-log { 1639 base log-action; 1640 description 1641 "Identity for session log-action capability. 1642 Log the received packet based on the session."; 1643 } 1645 identity pass { 1646 base ingress-action; 1647 base egress-action; 1648 base default-action; 1649 description 1650 "Identity for pass action capability. The pass action allows 1651 packet or flow to go through the NSF entering or exiting the 1652 internal network."; 1653 } 1655 identity drop { 1656 base ingress-action; 1657 base egress-action; 1658 base default-action; 1659 description 1660 "Identity for drop action capability. The drop action denies 1661 packet to go through the NSF entering or exiting the internal 1662 network."; 1663 } 1665 identity mirror { 1666 base ingress-action; 1667 base egress-action; 1668 base default-action; 1669 description 1670 "Identity for mirror action capability. The mirror action 1671 copies packet and send it to the monitoring entity while still 1672 allow the packet or flow to go through the NSF."; 1673 } 1675 identity rate-limit { 1676 base ingress-action; 1677 base egress-action; 1678 base default-action; 1679 description 1680 "Identity for rate limiting action capability. The rate limit 1681 action limits the number of packets or flows that can go 1682 through the NSF by dropping packets or flows (randomly or 1683 systematically)."; 1684 } 1686 identity invoke-signaling { 1687 base egress-action; 1688 description 1689 "Identity for invoke signaling action capability"; 1690 } 1692 identity tunnel-encapsulation { 1693 base egress-action; 1694 description 1695 "Identity for tunnel encapsulation action capability"; 1696 } 1698 identity forwarding { 1699 base egress-action; 1700 description 1701 "Identity for forwarding action capability"; 1702 } 1704 identity transformation { 1705 base egress-action; 1706 description 1707 "Identity for transformation action capability"; 1708 } 1710 identity resolution-strategy { 1711 description 1712 "Base identity for resolution strategy capability"; 1713 } 1715 identity fmr { 1716 base resolution-strategy; 1717 description 1718 "Identity for First Matching Rule (FMR) resolution 1719 strategy capability"; 1720 } 1722 identity lmr { 1723 base resolution-strategy; 1724 description 1725 "Identity for Last Matching Rule (LMR) resolution 1726 strategy capability"; 1728 } 1730 identity pmr { 1731 base resolution-strategy; 1732 description 1733 "Identity for Prioritized Matching Rule (PMR) resolution 1734 strategy capability"; 1735 } 1737 identity pmre { 1738 base resolution-strategy; 1739 description 1740 "Identity for Prioritized Matching Rule with Errors (PMRE) 1741 resolution strategy capability"; 1742 } 1744 identity pmrn { 1745 base resolution-strategy; 1746 description 1747 "Identity for Prioritized Matching Rule with No Errors (PMRN) 1748 resolution strategy capability"; 1749 } 1751 identity advanced-nsf { 1752 description 1753 "Base identity for advanced Network Security Function (NSF) 1754 capability."; 1755 } 1757 identity content-security-control { 1758 base advanced-nsf; 1759 description 1760 "Base identity for content security control. Content security 1761 control is an NSF that evaluates a packet's payload such as 1762 Intrusion Prevention System (IPS), URL-Filtering, Antivirus, 1763 and VoIP/VoLTE Filter."; 1764 } 1766 identity attack-mitigation-control { 1767 base advanced-nsf; 1768 description 1769 "Base identity for attack mitigation control. Attack mitigation 1770 control is an NSF that mitigates an attack such as anti-DDoS 1771 or DDoS-mitigator."; 1772 } 1774 identity ips { 1775 base content-security-control; 1776 description 1777 "Base identity for IPS (Intrusion Prevention System) capability 1778 that prevents malicious activity within a network"; 1779 } 1781 identity url-filtering { 1782 base content-security-control; 1783 description 1784 "Base identity for url filtering capability that limits access 1785 by comparing the web traffic's URL with the URLs for web 1786 filtering in a database"; 1787 } 1789 identity anti-virus { 1790 base content-security-control; 1791 description 1792 "Base identity for anti-virus capability to protect the network 1793 by detecting and removing viruses."; 1794 } 1796 identity voip-volte-filtering { 1797 base content-security-control; 1798 description 1799 "Base identity for advanced NSF VoIP/VoLTE Security Service 1800 capability to filter the VoIP/VoLTE packets or flows."; 1801 reference 1802 "RFC 3261: SIP: Session Initiation Protocol"; 1803 } 1805 identity anti-ddos { 1806 base attack-mitigation-control; 1807 description 1808 "Base identity for advanced NSF Anti-DDoS Attack or DDoS 1809 Mitigator capability."; 1810 } 1812 identity packet-rate { 1813 base anti-ddos; 1814 description 1815 "Identity for advanced NSF Anti-DDoS detecting Packet Rate 1816 Capability where a packet rate is defined as the arrival rate 1817 of Packets toward a victim destination node. The NSF with 1818 this capability can detect the incoming packet rate and create 1819 an alert if the rate exceeds the threshold."; 1821 } 1823 identity flow-rate { 1824 base anti-ddos; 1825 description 1826 "Identity for advanced NSF Anti-DDoS detecting Flow Rate 1827 Capability where a flow rate is defined as the arrival rate of 1828 flows towards a victim destination node. The NSF with this 1829 capability can detect the incoming flow rate and create an 1830 alert if the rate exceeds the threshold."; 1831 } 1833 identity byte-rate { 1834 base anti-ddos; 1835 description 1836 "Identity for advanced NSF Anti-DDoS detecting Byte Rate 1837 Capability where a byte rate is defined as the arrival rate of 1838 Bytes toward a victim destination node. The NSF with this 1839 capability can detect the incoming byte rate and create an 1840 alert if the rate exceeds the threshold."; 1841 } 1843 identity signature-set { 1844 base ips; 1845 description 1846 "Identity for the capability of IPS to set the signature. 1847 Signature is a set of rules to detect an intrusive activity."; 1848 reference 1849 "RFC 4766: Intrusion Detection Message Exchange Requirements - 1850 Section 2.2.13"; 1851 } 1853 identity exception-signature { 1854 base ips; 1855 description 1856 "Identity for the capability of IPS to exclude signatures from 1857 detecting the intrusion."; 1858 reference 1859 "RFC 4766: Intrusion Detection Message Exchange Requirements - 1860 Section 2.2.13"; 1861 } 1863 identity detect { 1864 base anti-virus; 1865 description 1866 "Identity for advanced NSF Antivirus capability to detect 1867 viruses using a security profile. The security profile is used 1868 to scan threats, such as virus, malware, and spyware. The NSF 1869 should be able to update the security profile."; 1870 } 1871 identity exception-files { 1872 base anti-virus; 1873 description 1874 "Identity for advanced NSF Antivirus capability to exclude a 1875 certain file type or name from detection."; 1876 } 1878 identity pre-defined { 1879 base url-filtering; 1880 description 1881 "Identity for pre-defined URL Database condition capability. 1882 where URL database is a public database for URL filtering."; 1883 } 1885 identity user-defined { 1886 base url-filtering; 1887 description 1888 "Identity for user-defined URL Database condition capability. 1889 that allows a users manual addition of URLs for URL 1890 filtering."; 1891 } 1893 identity call-id { 1894 base voip-volte-filtering; 1895 description 1896 "Identity for advanced NSF VoIP/VoLTE Call Identifier (ID) 1897 capability."; 1898 } 1900 identity user-agent { 1901 base voip-volte-filtering; 1902 description 1903 "Identity for advanced NSF VoIP/VoLTE User Agent capability."; 1904 } 1906 /* 1907 * Grouping 1908 */ 1910 grouping nsf-capabilities { 1911 description 1912 "Network Security Function (NSF) Capabilities"; 1913 reference 1914 "RFC 8329: Framework for Interface to Network Security 1915 Functions - I2NSF Flow Security Policy Structure."; 1917 leaf-list directional-capabilities { 1918 type identityref { 1919 base directional; 1920 } 1921 description 1922 "The capability of an NSF for handling directional traffic 1923 flow (i.e., unidirectional or bidirectional traffic flow)."; 1924 } 1926 container event-capabilities { 1927 description 1928 "Capabilities of events. 1929 If a network security function has the event capabilities, 1930 the network security function supports rule execution 1931 according to system event and system alarm."; 1933 reference 1934 "RFC 8329: Framework for Interface to Network Security 1935 Functions - Section 7. 1936 draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF 1937 NSF Monitoring YANG Data Model - System Alarm and 1938 System Events."; 1940 leaf-list system-event-capability { 1941 type identityref { 1942 base system-event; 1943 } 1944 description 1945 "System event capabilities"; 1946 } 1948 leaf-list system-alarm-capability { 1949 type identityref { 1950 base system-alarm; 1951 } 1952 description 1953 "System alarm capabilities"; 1954 } 1956 leaf-list time-capabilities { 1957 type identityref { 1958 base time; 1959 } 1960 description 1961 "The capabilities for activating the policy within a 1962 specific time."; 1963 } 1964 } 1966 container condition-capabilities { 1967 description 1968 "Conditions capabilities."; 1969 container generic-nsf-capabilities { 1970 description 1971 "Conditions capabilities. 1972 If a network security function has the condition 1973 capabilities, the network security function 1974 supports rule execution according to conditions of 1975 IPv4, IPv6, TCP, UDP, SCTP, DCCP, ICMP, or ICMPv6."; 1976 reference 1977 "RFC 768: User Datagram Protocol - UDP. 1978 RFC 791: Internet Protocol - IPv4. 1979 RFC 792: Internet Control Message Protocol - ICMP. 1980 RFC 4443: Internet Control Message Protocol (ICMPv6) 1981 for the Internet Protocol Version 6 (IPv6) Specification 1982 - ICMPv6. 1983 RFC 4960: Stream Control Transmission Protocol - SCTP. 1984 RFC 8200: Internet Protocol, Version 6 (IPv6) 1985 Specification - IPv6. 1986 RFC 8329: Framework for Interface to Network Security 1987 Functions - I2NSF Flow Security Policy Structure. 1988 draft-ietf-tcpm-rfc793bis-25: Transmission Control 1989 Protocol (TCP) Specification"; 1991 leaf-list ethernet-capability { 1992 type identityref { 1993 base ethernet; 1994 } 1995 description 1996 "Media Access Control (MAC) capabilities"; 1997 reference 1998 "IEEE 802.3: IEEE Standard for Ethernet"; 1999 } 2001 leaf-list ipv4-capability { 2002 type identityref { 2003 base ipv4; 2004 } 2005 description 2006 "IPv4 packet capabilities"; 2007 reference 2008 "RFC 791: Internet Protocol"; 2009 } 2011 leaf-list ipv6-capability { 2012 type identityref { 2013 base ipv6; 2014 } 2015 description 2016 "IPv6 packet capabilities"; 2017 reference 2018 "RFC 8200: Internet Protocol, Version 6 (IPv6) 2019 Specification - IPv6"; 2020 } 2022 leaf-list icmpv4-capability { 2023 type identityref { 2024 base icmpv4; 2025 } 2026 description 2027 "ICMPv4 packet capabilities"; 2028 reference 2029 "RFC 792: Internet Control Message Protocol - ICMP"; 2030 } 2032 leaf-list icmpv6-capability { 2033 type identityref { 2034 base icmpv6; 2035 } 2036 description 2037 "ICMPv6 packet capabilities"; 2038 reference 2039 "RFC 4443: Internet Control Message Protocol (ICMPv6) 2040 for the Internet Protocol Version 6 (IPv6) Specification 2041 - ICMPv6"; 2042 } 2044 leaf-list tcp-capability { 2045 type identityref { 2046 base tcp; 2047 } 2048 description 2049 "TCP packet capabilities"; 2050 reference 2051 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 2052 Protocol (TCP) Specification"; 2053 } 2055 leaf-list udp-capability { 2056 type identityref { 2057 base udp; 2058 } 2059 description 2060 "UDP packet capabilities"; 2061 reference 2062 "RFC 768: User Datagram Protocol - UDP"; 2064 } 2066 leaf-list sctp-capability { 2067 type identityref { 2068 base sctp; 2069 } 2070 description 2071 "SCTP packet capabilities"; 2072 reference 2073 "RFC 4960: Stream Control Transmission Protocol - SCTP"; 2074 } 2076 leaf-list dccp-capability { 2077 type identityref { 2078 base dccp; 2079 } 2080 description 2081 "DCCP packet capabilities"; 2082 reference 2083 "RFC 4340: Datagram Congestion Control Protocol - DCCP"; 2084 } 2085 } 2087 container advanced-nsf-capabilities { 2088 description 2089 "Advanced Network Security Function (NSF) capabilities, 2090 such as Anti-DDoS, IPS, and VoIP/VoLTE. 2091 This container contains the leaf-lists of advanced 2092 NSF capabilities"; 2094 leaf-list anti-ddos-capability { 2095 type identityref { 2096 base anti-ddos; 2097 } 2098 description 2099 "Anti-DDoS Attack capabilities"; 2100 } 2102 leaf-list ips-capability { 2103 type identityref { 2104 base ips; 2105 } 2106 description 2107 "IPS capabilities"; 2108 } 2110 leaf-list anti-virus-capability { 2111 type identityref { 2112 base anti-virus; 2113 } 2114 description 2115 "Anti-Virus capabilities"; 2116 } 2118 leaf-list url-capability { 2119 type identityref { 2120 base url-filtering; 2121 } 2122 description 2123 "URL capabilities"; 2124 } 2126 leaf-list voip-volte-filtering-capability { 2127 type identityref { 2128 base voip-volte-filtering; 2129 } 2130 description 2131 "VoIP/VoLTE capabilities"; 2132 } 2133 } 2135 container context-capabilities { 2136 description 2137 "Security context capabilities"; 2138 leaf-list application-filter-capabilities{ 2139 type identityref { 2140 base application-protocol; 2141 } 2142 description 2143 "Context capabilities based on the application protocol"; 2144 } 2146 leaf-list target-capabilities { 2147 type identityref { 2148 base target-device; 2149 } 2150 description 2151 "Context capabilities based on the device attribute that 2152 can identify a device type 2153 (i.e., router, switch, pc, ios, or android)."; 2154 } 2156 leaf-list user-condition-capabilities { 2157 type identityref { 2158 base user-condition; 2159 } 2160 description 2161 "Context capabilities based on user condition, such as 2162 user-id or user-name. The users can collected into a 2163 user-group and identified with group-id or group-name. 2164 An NSF is aware of the IP address of the user provided 2165 by a unified user management system via network. Based 2166 on name-address association, an NSF is able to enforce 2167 the security functions over the given user (or user 2168 group)"; 2169 } 2171 leaf-list geography-capabilities { 2172 type identityref { 2173 base geography-location; 2174 } 2175 description 2176 "Context condition capabilities based on the geographical 2177 location of the source or destination"; 2178 } 2179 } 2180 } 2182 container action-capabilities { 2183 description 2184 "Action capabilities. 2185 If a network security function has the action capabilities, 2186 the network security function supports the attendant 2187 actions for policy rules."; 2189 leaf-list ingress-action-capability { 2190 type identityref { 2191 base ingress-action; 2192 } 2193 description 2194 "Ingress-action capabilities"; 2195 } 2197 leaf-list egress-action-capability { 2198 type identityref { 2199 base egress-action; 2200 } 2201 description 2202 "Egress-action capabilities"; 2203 } 2205 leaf-list log-action-capability { 2206 type identityref { 2207 base log-action; 2209 } 2210 description 2211 "Log-action capabilities"; 2212 } 2213 } 2215 leaf-list resolution-strategy-capabilities { 2216 type identityref { 2217 base resolution-strategy; 2218 } 2219 description 2220 "Resolution strategy capabilities. 2221 The resolution strategies can be used to specify how 2222 to resolve conflicts that occur between the actions 2223 of the same or different policy rules that are matched 2224 for the same packet and by particular NSF."; 2225 } 2227 leaf-list default-action-capabilities { 2228 type identityref { 2229 base default-action; 2230 } 2231 description 2232 "Default action capabilities. 2233 A default action is used to execute I2NSF policy rules 2234 when no rule matches a packet. The default action is 2235 defined as pass, drop, rate-limit, or mirror."; 2236 } 2237 } 2239 /* 2240 * Data nodes 2241 */ 2243 list nsf { 2244 key "nsf-name"; 2245 description 2246 "The list of Network Security Functions (NSFs)"; 2247 leaf nsf-name { 2248 type string; 2249 mandatory true; 2250 description 2251 "The name of Network Security Function (NSF)"; 2252 } 2253 uses nsf-capabilities; 2254 } 2255 } 2256 2257 Figure 3: YANG Data Module of I2NSF Capability 2259 7. IANA Considerations 2261 This document requests IANA to register the following URI in the 2262 "IETF XML Registry" [RFC3688]: 2264 ID: yang:ietf-i2nsf-capability 2265 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2266 Registrant Contact: The IESG. 2267 XML: N/A; the requested URI is an XML namespace. 2268 Filename: [ TBD-at-Registration ] 2269 Reference: [ RFC-to-be ] 2271 This document requests IANA to register the following YANG module in 2272 the "YANG Module Names" registry [RFC7950][RFC8525]: 2274 Name: ietf-i2nsf-capability 2275 Maintained by IANA? N 2276 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2277 Prefix: nsfcap 2278 Module: 2279 Reference: [ RFC-to-be ] 2281 8. Privacy Considerations 2283 This YANG module specifies the capabilities for NSFs. Some of the 2284 capabilities in this document MAY require highly sensitive private 2285 data to operate properly. The usage of such capability MUST be 2286 reported to the users and permitted before using the private 2287 information related to the capability. Using any of the capabilities 2288 that require private data MUST preserve the privacy by preventing any 2289 leakage or unauthorized disclosure of the private data. 2291 In regards to the privacy data used, the security for accessibility 2292 of the data should be tightly secured and monitored. The Security 2293 Considerations are discussed in Section 9. 2295 9. Security Considerations 2297 The YANG module specified in this document defines a data schema 2298 designed to be accessed through network management protocols such as 2299 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest layer of NETCONF 2300 protocol layers MUST use Secure Shell (SSH) [RFC4254][RFC6242] as a 2301 secure transport layer. The lowest layer of RESTCONF protocol layers 2302 MUST use HTTP over Transport Layer Security (TLS), that is, HTTPS 2303 [RFC7230][RFC8446] as a secure transport layer. 2305 The Network Configuration Access Control Model (NACM) [RFC8341] 2306 provides a means of restricting access to specific NETCONF or 2307 RESTCONF users to a preconfigured subset of all available NETCONF or 2308 RESTCONF protocol operations and contents. Thus, NACM SHOULD be used 2309 to restrict the NSF registration from unauthorized users. 2311 There are a number of data nodes defined in this YANG module that are 2312 writable, creatable, and deletable (i.e., config true, which is the 2313 default). These data nodes may be considered sensitive or vulnerable 2314 in some network environments. Write operations to these data nodes 2315 could have a negative effect on network and security operations. 2316 These data nodes are collected into a single list node. This list 2317 node is defined by list nsf with the following sensitivity/ 2318 vulnerability: 2320 * list nsf: An attacker could alter the security capabilities 2321 associated with an NSF by disabling or enabling the functionality 2322 of the security capabilities of the NSF. 2324 Some of the readable data nodes in this YANG module may be considered 2325 sensitive or vulnerable in some network environments. It is thus 2326 important to control read access (e.g., via get, get-config, or 2327 notification) to these data nodes. These are the subtrees and data 2328 nodes with their sensitivity/vulnerability: 2330 * list nsf: The leak of this node to an attacker could reveal the 2331 specific configuration of security controls to an attacker. An 2332 attacker can craft an attack path that avoids observation or 2333 mitigations; one may reveal topology information to inform 2334 additional targets or enable lateral movement; one enables the 2335 construction of an attack path that avoids observation or 2336 mitigations; one provides an indication that the operator has 2337 discovered the attack. 2339 Some of the features that this document defines capability indicators 2340 for are highly sensitive and/or privileged operations that inherently 2341 require access to individuals' private data. These are subtrees and 2342 data nodes that are considered privacy sensitive: 2344 * voip-volte-filtering-capability: The NSF that is able to filter 2345 VoIP/VoLTE calls might identify certain individual identification. 2347 * user-condition-capabilities: The capability uses a set of IP 2348 addresses mapped to users. 2350 * geography-capabilities: The IP address used in this capability can 2351 identify a user's geographical location. 2353 It is noted that some private information is made accessible in this 2354 manner. Thus, the nodes/entities given access to this data MUST be 2355 tightly secured, monitored, and audited to prevent leakage or other 2356 unauthorized disclosure of private data. Refer to [RFC6973] for the 2357 description of privacy aspects that protocol designers (including 2358 YANG data model designers) should consider along with regular 2359 security and privacy analysis. 2361 10. References 2363 10.1. Normative References 2365 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2366 DOI 10.17487/RFC0768, August 1980, 2367 . 2369 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2370 DOI 10.17487/RFC0791, September 1981, 2371 . 2373 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2374 RFC 792, DOI 10.17487/RFC0792, September 1981, 2375 . 2377 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 2378 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 2379 1983, . 2381 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2382 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 2383 . 2385 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2386 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 2387 . 2389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2390 Requirement Levels", BCP 14, RFC 2119, 2391 DOI 10.17487/RFC2119, March 1997, 2392 . 2394 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2395 "Definition of the Differentiated Services Field (DS 2396 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2397 DOI 10.17487/RFC2474, December 1998, 2398 . 2400 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2401 of Explicit Congestion Notification (ECN) to IP", 2402 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2403 . 2405 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2406 A., Peterson, J., Sparks, R., Handley, M., and E. 2407 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2408 DOI 10.17487/RFC3261, June 2002, 2409 . 2411 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 2412 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 2413 . 2415 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2416 DOI 10.17487/RFC3688, January 2004, 2417 . 2419 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 2420 Protocol Assigned Numbers", RFC 4250, 2421 DOI 10.17487/RFC4250, January 2006, 2422 . 2424 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2425 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 2426 January 2006, . 2428 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2429 Congestion Control Protocol (DCCP)", RFC 4340, 2430 DOI 10.17487/RFC4340, March 2006, 2431 . 2433 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2434 Control Message Protocol (ICMPv6) for the Internet 2435 Protocol Version 6 (IPv6) Specification", STD 89, 2436 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2437 . 2439 [RFC4766] Wood, M. and M. Erlinger, "Intrusion Detection Message 2440 Exchange Requirements", RFC 4766, DOI 10.17487/RFC4766, 2441 March 2007, . 2443 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2444 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2445 . 2447 [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export 2448 Using IP Flow Information Export (IPFIX)", RFC 5103, 2449 DOI 10.17487/RFC5103, January 2008, 2450 . 2452 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2453 DOI 10.17487/RFC5321, October 2008, 2454 . 2456 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 2457 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 2458 September 2009, . 2460 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2461 the Network Configuration Protocol (NETCONF)", RFC 6020, 2462 DOI 10.17487/RFC6020, October 2010, 2463 . 2465 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2466 and A. Bierman, Ed., "Network Configuration Protocol 2467 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2468 . 2470 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2471 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2472 . 2474 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2475 Cheshire, "Internet Assigned Numbers Authority (IANA) 2476 Procedures for the Management of the Service Name and 2477 Transport Protocol Port Number Registry", BCP 165, 2478 RFC 6335, DOI 10.17487/RFC6335, August 2011, 2479 . 2481 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2482 "IPv6 Flow Label Specification", RFC 6437, 2483 DOI 10.17487/RFC6437, November 2011, 2484 . 2486 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2487 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2488 . 2490 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2491 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2492 . 2494 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2495 Protocol (HTTP/1.1): Message Syntax and Routing", 2496 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2497 . 2499 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2500 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2501 DOI 10.17487/RFC7231, June 2014, 2502 . 2504 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 2505 Scheffenegger, Ed., "TCP Extensions for High Performance", 2506 RFC 7323, DOI 10.17487/RFC7323, September 2014, 2507 . 2509 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2510 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2511 . 2513 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2514 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2515 . 2517 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2518 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2519 May 2017, . 2521 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2522 (IPv6) Specification", STD 86, RFC 8200, 2523 DOI 10.17487/RFC8200, July 2017, 2524 . 2526 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2527 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2528 . 2530 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2531 Access Control Model", STD 91, RFC 8341, 2532 DOI 10.17487/RFC8341, March 2018, 2533 . 2535 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2536 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2537 DOI 10.17487/RFC8407, October 2018, 2538 . 2540 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2541 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2542 . 2544 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 2545 and R. Wilton, "YANG Library", RFC 8525, 2546 DOI 10.17487/RFC8525, March 2019, 2547 . 2549 [I-D.ietf-tcpm-rfc793bis] 2550 Eddy, W. M., "Transmission Control Protocol (TCP) 2551 Specification", Work in Progress, Internet-Draft, draft- 2552 ietf-tcpm-rfc793bis-25, 7 September 2021, 2553 . 2556 [I-D.ietf-tcpm-accurate-ecn] 2557 Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More 2558 Accurate ECN Feedback in TCP", Work in Progress, Internet- 2559 Draft, draft-ietf-tcpm-accurate-ecn-15, 12 July 2021, 2560 . 2563 [I-D.ietf-tsvwg-udp-options] 2564 Touch, J., "Transport Options for UDP", Work in Progress, 2565 Internet-Draft, draft-ietf-tsvwg-udp-options-13, 19 June 2566 2021, . 2569 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 2570 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 2571 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 2572 Model", Work in Progress, Internet-Draft, draft-ietf- 2573 i2nsf-nsf-monitoring-data-model-10, 15 September 2021, 2574 . 2577 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 2578 Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin, 2579 "I2NSF Network Security Function-Facing Interface YANG 2580 Data Model", Work in Progress, Internet-Draft, draft-ietf- 2581 i2nsf-nsf-facing-interface-dm-14, 15 September 2021, 2582 . 2585 [I-D.ietf-i2nsf-registration-interface-dm] 2586 Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Park, 2587 "I2NSF Registration Interface YANG Data Model", Work in 2588 Progress, Internet-Draft, draft-ietf-i2nsf-registration- 2589 interface-dm-12, 15 September 2021, 2590 . 2593 10.2. Informative References 2595 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2596 DOI 10.17487/RFC2818, May 2000, 2597 . 2599 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2600 RFC 6691, DOI 10.17487/RFC6691, July 2012, 2601 . 2603 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2604 Morris, J., Hansen, M., and R. Smith, "Privacy 2605 Considerations for Internet Protocols", RFC 6973, 2606 DOI 10.17487/RFC6973, July 2013, 2607 . 2609 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2610 and J. Jeong, "Interface to Network Security Functions 2611 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2612 DOI 10.17487/RFC8192, July 2017, 2613 . 2615 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2616 Kumar, "Framework for Interface to Network Security 2617 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2618 . 2620 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 2621 Kumari, "A Format for Self-Published IP Geolocation 2622 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 2623 . 2625 [IANA-Protocol-Numbers] 2626 "Assigned Internet Protocol Numbers", Available: 2627 https://www.iana.org/assignments/protocol- 2628 numbers/protocol-numbers.xhtml, September 2020. 2630 [IEEE802.3-2018] 2631 Committee, I. S., "IEEE 802.3-2018 - IEEE Standard for 2632 Ethernet", August 2018, 2633 . 2635 [Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and 2636 management of firewall policies", 2004. 2638 [Hirschman] 2639 Hirschman, L. and R. Gaizauskas, "Natural Language 2640 Question Answering: The View from Here", Natural Language 2641 Engineering 7:4, pgs 275-300, Cambridge University Press , 2642 November 2001. 2644 [Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns", 2645 ISBN 0-32-120068-3 , 2003. 2647 [Martin] Martin, R.C., "Agile Software Development, Principles, 2648 Patterns, and Practices", Prentice-Hall , ISBN: 2649 0-13-597444-5 , 2002. 2651 [OODMP] "https://www.oodesign.com/mediator-pattern.html". 2653 [OODOP] "https://www.oodesign.com/mediator-pattern.html". 2655 [OODSRP] "https://www.oodesign.com/mediator-pattern.html". 2657 Appendix A. Configuration Examples 2659 This section shows configuration examples of "ietf-i2nsf-capability" 2660 module for capabilities registration of general firewall. 2662 A.1. Example 1: Registration for the Capabilities of a General Firewall 2664 This section shows a configuration example for the capabilities 2665 registration of a general firewall in either an IPv4 network or an 2666 IPv6 network. 2668 2669 general_firewall 2670 2671 2672 next-header 2673 flow-direction 2674 source-address 2675 destination-address 2676 source-port-number 2677 destination-port-number 2678 source-port-number 2679 destination-port-number 2680 2681 2682 2683 pass 2684 drop 2685 mirror 2686 pass 2687 drop 2688 mirror 2689 2690 2692 Figure 4: Configuration XML for the Capabilities Registration of 2693 a General Firewall in an IPv4 Network 2695 Figure 4 shows the configuration XML for the capabilities 2696 registration of a general firewall as an NSF in an IPv4 network. Its 2697 capabilities are as follows. 2699 1. The name of the NSF is general_firewall. 2701 2. The NSF can inspect the IPv4 protocol header field, flow 2702 direction, source address(es), and destination address(es) 2704 3. The NSF can inspect the port number(s) and flow direction for the 2705 transport layer protocol, i.e., TCP and UDP. 2707 4. The NSF can control whether the packets are allowed to pass, 2708 drop, or mirror. 2710 2711 general_firewall 2712 2713 2714 next-header 2715 flow-direction 2716 source-address 2717 destination-address 2718 source-port-number 2719 destination-port-number 2720 source-port-number 2721 destination-port-number 2722 2723 2724 2725 pass 2726 drop 2727 mirror 2728 pass 2729 drop 2730 mirror 2731 2732 2734 Figure 5: Configuration XML for the Capabilities Registration of 2735 a General Firewall in an IPv6 Network 2737 In addition, Figure 5 shows the configuration XML for the 2738 capabilities registration of a general firewall as an NSF in an IPv6 2739 network. Its capabilities are as follows. 2741 1. The name of the NSF is general_firewall. 2743 2. The NSF can inspect IPv6 next header, flow direction, source 2744 address(es), and destination address(es) 2746 3. The NSF can inspect the port number(s) and flow direction for the 2747 transport layer protocol, i.e., TCP and UDP. 2749 4. The NSF can control whether the packets are allowed to pass, 2750 drop, or mirror. 2752 A.2. Example 2: Registration for the Capabilities of a Time-based 2753 Firewall 2755 This section shows a configuration example for the capabilities 2756 registration of a time-based firewall in either an IPv4 network or an 2757 IPv6 network. 2759 2760 time_based_firewall 2761 2762 absolute-time 2763 periodic-time 2764 2765 2766 2767 next-header 2768 flow-direction 2769 source-address 2770 destination-address 2771 2772 2773 2774 pass 2775 drop 2776 mirror 2777 pass 2778 drop 2779 mirror 2780 2781 2783 Figure 6: Configuration XML for the Capabilities Registration of 2784 a Time-based Firewall in an IPv4 Network 2786 Figure 6 shows the configuration XML for the capabilities 2787 registration of a time-based firewall as an NSF in an IPv4 network. 2788 Its capabilities are as follows. 2790 1. The name of the NSF is time_based_firewall. 2792 2. The NSF can execute the security policy rule according to 2793 absolute time and periodic time. 2795 3. The NSF can inspect the IPv4 protocol header field, flow 2796 direction, source address(es), and destination address(es). 2798 4. The NSF can control whether the packets are allowed to pass, 2799 drop, or mirror. 2801 2802 time_based_firewall 2803 2804 absolute-time 2805 periodic-time 2806 2807 2808 2809 next-header 2810 flow-direction 2811 source-address 2812 destination-address 2813 2814 2815 2816 pass 2817 drop 2818 mirror 2819 pass 2820 drop 2821 mirror 2822 2823 2825 Figure 7: Configuration XML for the Capabilities Registration of 2826 a Time-based Firewall in an IPv6 Network 2828 In addition, Figure 7 shows the configuration XML for the 2829 capabilities registration of a time-based firewall as an NSF in an 2830 IPv6 network. Its capabilities are as follows. 2832 1. The name of the NSF is time_based_firewall. 2834 2. The NSF can execute the security policy rule according to 2835 absolute time and periodic time. 2837 3. The NSF can inspect the IPv6 protocol header field, flow 2838 direction, source address(es), and destination address(es). 2840 4. The NSF can control whether the packets are allowed to pass, 2841 drop, or mirror. 2843 A.3. Example 3: Registration for the Capabilities of a Web Filter 2845 This section shows a configuration example for the capabilities 2846 registration of a web filter. 2848 2849 web_filter 2850 2851 2852 user-defined 2853 2854 2855 2856 pass 2857 drop 2858 mirror 2859 pass 2860 drop 2861 mirror 2862 2863 2865 Figure 8: Configuration XML for the Capabilities Registration of 2866 a Web Filter 2868 Figure 8 shows the configuration XML for the capabilities 2869 registration of a web filter as an NSF. Its capabilities are as 2870 follows. 2872 1. The name of the NSF is web_filter. 2874 2. The NSF can inspect a URL matched from a user-defined URL. User 2875 can specify their own URL. 2877 3. The NSF can control whether the packets are allowed to pass, 2878 drop, or mirror. 2880 A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE 2881 Filter 2883 This section shows a configuration example for the capabilities 2884 registration of a VoIP/VoLTE filter. 2886 2887 voip_volte_filter 2888 2889 2890 2891 call-id 2892 2893 2894 2895 2896 pass 2897 drop 2898 mirror 2899 pass 2900 drop 2901 mirror 2902 2903 2905 Figure 9: Configuration XML for the Capabilities Registration of 2906 a VoIP/VoLTE Filter 2908 Figure 9 shows the configuration XML for the capabilities 2909 registration of a VoIP/VoLTE filter as an NSF. Its capabilities are 2910 as follows. 2912 1. The name of the NSF is voip_volte_filter. 2914 2. The NSF can inspect a voice call id for VoIP/VoLTE packets. 2916 3. The NSF can control whether the packets are allowed to pass, 2917 drop, or mirror. 2919 A.5. Example 5: Registration for the Capabilities of a HTTP and HTTPS 2920 Flood Mitigator 2922 This section shows a configuration example for the capabilities 2923 registration of a HTTP and HTTPS flood mitigator. 2925 2926 DDoS_mitigator 2927 2928 2929 packet-rate 2930 byte-rate 2931 flow-rate 2932 2933 2934 2935 pass 2936 drop 2937 mirror 2938 pass 2939 drop 2940 mirror 2941 2942 2944 Figure 10: Configuration XML for the Capabilities Registration of 2945 a HTTP and HTTPS Flood Mitigator 2947 Figure 10 shows the configuration XML for the capabilities 2948 registration of a HTTP and HTTPS flood mitigator as an NSF. Its 2949 capabilities are as follows. 2951 1. The name of the NSF is DDoS_mitigator. 2953 2. The NSF can detect the amount of packet, flow, and byte rate in 2954 the network for potential DDoS Attack. 2956 3. The NSF can control whether the packets are allowed to pass, 2957 drop, or mirror. 2959 Appendix B. Acknowledgments 2961 This work was supported by Institute of Information & Communications 2962 Technology Planning & Evaluation (IITP) grant funded by the Korea 2963 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 2964 Security Intelligence Technology Development for the Customized 2965 Security Service Provisioning). This work was supported in part by 2966 the IITP grant funded by the MSIT (2020-0-00395, Standard Development 2967 of Blockchain based Network Management Automation Technology). 2969 Appendix C. Contributors 2971 This document is made by the group effort of I2NSF working group. 2972 Many people actively contributed to this document, such as Acee 2973 Lindem, Roman Danyliw, and Tom Petch. The authors sincerely 2974 appreciate their contributions. 2976 The following are co-authors of this document: 2978 Patrick Lingga Department of Electrical and Computer Engineering 2979 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 2980 16419 Republic of Korea EMail: patricklink@skku.edu 2982 Liang Xia Huawei 101 Software Avenue Nanjing, Jiangsu 210012 China 2983 EMail: Frank.Xialiang@huawei.com 2985 Cataldo Basile Politecnico di Torino Corso Duca degli Abruzzi, 34 2986 Torino, 10129 Italy EMail: cataldo.basile@polito.it 2988 John Strassner Huawei 2330 Central Expressway Santa Clara, CA 95050 2989 USA EMail: John.sc.Strassner@huawei.com 2991 Diego R. Lopez Telefonica I+D Zurbaran, 12 Madrid, 28010 Spain 2992 Email: diego.r.lopez@telefonica.com 2994 Hyoungshick Kim Department of Computer Science and Engineering 2995 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 2996 16419 Republic of Korea EMail: hyoung@skku.edu 2998 Daeyoung Hyun Department of Computer Science and Engineering 2999 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 3000 16419 Republic of Korea EMail: dyhyun@skku.edu 3002 Dongjin Hong Department of Electronic, Electrical and Computer 3003 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 3004 Gyeonggi-do 16419 Republic of Korea EMail: dong.jin@skku.edu 3006 Jung-Soo Park Electronics and Telecommunications Research Institute 3007 218 Gajeong-Ro, Yuseong-Gu Daejeon, 34129 Republic of Korea EMail: 3008 pjs@etri.re.kr 3010 Tae-Jin Ahn Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 3011 Republic of Korea EMail: taejin.ahn@kt.com 3013 Se-Hui Lee Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 3014 Republic of Korea EMail: sehuilee@kt.com 3016 Authors' Addresses 3018 Susan Hares (editor) 3019 Huawei 3020 7453 Hickory Hill 3021 Saline, MI 48176 3022 United States of America 3024 Phone: +1-734-604-0332 3025 Email: shares@ndzh.com 3027 Jaehoon (Paul) Jeong (editor) 3028 Department of Computer Science and Engineering 3029 Sungkyunkwan University 3030 2066 Seobu-Ro, Jangan-Gu 3031 Suwon 3032 Gyeonggi-Do 3033 16419 3034 Republic of Korea 3036 Phone: +82 31 299 4957 3037 Email: pauljeong@skku.edu 3038 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3040 Jinyong (Tim) Kim 3041 Department of Electronic, Electrical and Computer Engineering 3042 Sungkyunkwan University 3043 2066 Seobu-Ro, Jangan-Gu 3044 Suwon 3045 Gyeonggi-Do 3046 16419 3047 Republic of Korea 3049 Phone: +82 10 8273 0930 3050 Email: timkim@skku.edu 3052 Robert Moskowitz 3053 HTT Consulting 3054 Oak Park, MI 3055 United States of America 3057 Phone: +1-248-968-9809 3058 Email: rgm@htt-consult.com 3059 Qiushi Lin 3060 Huawei 3061 Huawei Industrial Base 3062 Shenzhen 3063 Guangdong 518129, 3064 China 3066 Email: linqiushi@huawei.com