idnits 2.17.1 draft-ietf-i2nsf-capability-data-model-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 September 2021) is 938 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-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-09 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-13 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-11 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-rfc793bis-25 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 3 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: 1 April 2022 J. Kim 6 Sungkyunkwan University 7 R. Moskowitz 8 HTT Consulting 9 Q. Lin 10 Huawei 11 28 September 2021 13 I2NSF Capability YANG Data Model 14 draft-ietf-i2nsf-capability-data-model-19 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 1 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 . . . . . . . . . . . . . . . . . . . 49 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 51 70 10.2. Informative References . . . . . . . . . . . . . . . . . 55 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-09-28.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-09-28"{ 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 "RFC 3168: The Addition of Explicit Congestion Notification 1456 (ECN) to IP - TCP Header Flags 1457 draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1458 (TCP) Specification 1459 draft-ietf-tcpm-accurate-ecn: More Accurate ECN Feedback 1460 in TCP"; 1461 } 1463 identity tcp-options { 1464 base tcp; 1465 description 1466 "Identity for TCP options condition capability."; 1467 reference 1468 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1469 (TCP) Specification 1470 RFC 6691: TCP Options and Maximum Segment Size 1471 RFC 7323: TCP Extensions for High Performance"; 1472 } 1474 identity total-length { 1475 base udp; 1476 description 1477 "Identity for matching UDP total-length condition capability. 1478 The UDP total length can be smaller than the IP transport 1479 length for UDP transport layer options."; 1480 reference 1481 "RFC 768: User Datagram Protocol - Total Length 1482 draft-ietf-tsvwg-udp-options: Transport Options for UDP"; 1483 } 1484 identity verification-tag { 1485 base sctp; 1486 description 1487 "Identity for range-match SCTP verification tag condition 1488 capability"; 1489 reference 1490 "RFC 4960: Stream Control Transmission Protocol - Verification 1491 Tag"; 1492 } 1494 identity chunk-type { 1495 base sctp; 1496 description 1497 "Identity for SCTP chunk type condition capability"; 1498 reference 1499 "RFC 4960: Stream Control Transmission Protocol - Chunk Type"; 1500 } 1502 identity service-code { 1503 base dccp; 1504 description 1505 "Identity for DCCP Service Code condition capabilitiy"; 1506 reference 1507 "RFC 4340: Datagram Congestion Control Protocol 1508 RFC 5595: The Datagram Congestion Control Protocol (DCCP) 1509 Service Codes 1510 RFC 6335: Internet Assigned Numbers Authority (IANA) 1511 Procedures for the Management of the Service Name and 1512 Transport Protocol Port Number Registry - Service Code"; 1513 } 1515 identity application-protocol { 1516 base protocol; 1517 description 1518 "Base identity for Application protocol"; 1519 } 1521 identity http { 1522 base application-protocol; 1523 description 1524 "The identity for Hypertext Transfer Protocol."; 1525 reference 1526 "RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1527 Syntax and Routing 1528 RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1529 and Content"; 1530 } 1531 identity https { 1532 base application-protocol; 1533 description 1534 "The identity for Hypertext Transfer Protocol Secure."; 1535 reference 1536 "RFC 2818: HTTP over TLS (HTTPS) 1537 RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1538 Syntax and Routing 1539 RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1540 and Content"; 1541 } 1543 identity ftp { 1544 base application-protocol; 1545 description 1546 "The identity for File Transfer Protocol."; 1547 reference 1548 "RFC 959: File Transfer Protocol (FTP)"; 1549 } 1551 identity ssh { 1552 base application-protocol; 1553 description 1554 "The identity for Secure Shell (SSH) protocol."; 1555 reference 1556 "RFC 4250: The Secure Shell (SSH) Protocol"; 1557 } 1559 identity telnet { 1560 base application-protocol; 1561 description 1562 "The identity for telnet."; 1563 reference 1564 "RFC 854: Telnet Protocol"; 1565 } 1567 identity smtp { 1568 base application-protocol; 1569 description 1570 "The identity for Simple Mail Transfer Protocol."; 1571 reference 1572 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1573 } 1575 identity pop3 { 1576 base application-protocol; 1577 description 1578 "The identity for Post Office Protocol 3."; 1580 reference 1581 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1582 } 1584 identity imap { 1585 base application-protocol; 1586 description 1587 "The identity for Internet Message Access Protocol."; 1588 reference 1589 "RFC 3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"; 1590 } 1592 identity action { 1593 description 1594 "Base identity for action capability"; 1595 } 1597 identity log-action { 1598 base action; 1599 description 1600 "Base identity for log-action capability"; 1601 } 1603 identity ingress-action { 1604 base action; 1605 description 1606 "Base identity for ingress-action capability"; 1607 reference 1608 "RFC 8329: Framework for Interface to Network Security 1609 Functions - Section 7.2"; 1610 } 1612 identity egress-action { 1613 base action; 1614 description 1615 "Base identity for egress-action capability"; 1616 reference 1617 "RFC 8329: Framework for Interface to Network Security 1618 Functions - Section 7.2"; 1619 } 1621 identity default-action { 1622 base action; 1623 description 1624 "Base identity for default-action capability"; 1625 } 1627 identity rule-log { 1628 base log-action; 1629 description 1630 "Identity for rule log-action capability. 1631 Log the received packet based on the rule"; 1632 } 1634 identity session-log { 1635 base log-action; 1636 description 1637 "Identity for session log-action capability. 1638 Log the received packet based on the session."; 1639 } 1641 identity pass { 1642 base ingress-action; 1643 base egress-action; 1644 base default-action; 1645 description 1646 "Identity for pass action capability. The pass action allows 1647 packet or flow to go through the NSF entering or exiting the 1648 internal network."; 1649 } 1651 identity drop { 1652 base ingress-action; 1653 base egress-action; 1654 base default-action; 1655 description 1656 "Identity for drop action capability. The drop action denies 1657 packet to go through the NSF entering or exiting the internal 1658 network."; 1659 } 1661 identity mirror { 1662 base ingress-action; 1663 base egress-action; 1664 base default-action; 1665 description 1666 "Identity for mirror action capability. The mirror action 1667 copies packet and send it to the monitoring entity while still 1668 allow the packet or flow to go through the NSF."; 1669 } 1671 identity rate-limit { 1672 base ingress-action; 1673 base egress-action; 1674 base default-action; 1675 description 1676 "Identity for rate limiting action capability. The rate limit 1677 action limits the number of packets or flows that can go 1678 through the NSF by dropping packets or flows (randomly or 1679 systematically)."; 1680 } 1682 identity invoke-signaling { 1683 base egress-action; 1684 description 1685 "Identity for invoke signaling action capability"; 1686 } 1688 identity tunnel-encapsulation { 1689 base egress-action; 1690 description 1691 "Identity for tunnel encapsulation action capability"; 1692 } 1694 identity forwarding { 1695 base egress-action; 1696 description 1697 "Identity for forwarding action capability"; 1698 } 1700 identity transformation { 1701 base egress-action; 1702 description 1703 "Identity for transformation action capability"; 1704 } 1706 identity resolution-strategy { 1707 description 1708 "Base identity for resolution strategy capability"; 1709 } 1711 identity fmr { 1712 base resolution-strategy; 1713 description 1714 "Identity for First Matching Rule (FMR) resolution 1715 strategy capability"; 1716 } 1718 identity lmr { 1719 base resolution-strategy; 1720 description 1721 "Identity for Last Matching Rule (LMR) resolution 1722 strategy capability"; 1723 } 1724 identity pmr { 1725 base resolution-strategy; 1726 description 1727 "Identity for Prioritized Matching Rule (PMR) resolution 1728 strategy capability"; 1729 } 1731 identity pmre { 1732 base resolution-strategy; 1733 description 1734 "Identity for Prioritized Matching Rule with Errors (PMRE) 1735 resolution strategy capability"; 1736 } 1738 identity pmrn { 1739 base resolution-strategy; 1740 description 1741 "Identity for Prioritized Matching Rule with No Errors (PMRN) 1742 resolution strategy capability"; 1743 } 1745 identity advanced-nsf { 1746 description 1747 "Base identity for advanced Network Security Function (NSF) 1748 capability."; 1749 } 1751 identity content-security-control { 1752 base advanced-nsf; 1753 description 1754 "Base identity for content security control. Content security 1755 control is an NSF that evaluates a packet's payload such as 1756 Intrusion Prevention System (IPS), URL-Filtering, Antivirus, 1757 and VoIP/VoLTE Filter."; 1758 } 1760 identity attack-mitigation-control { 1761 base advanced-nsf; 1762 description 1763 "Base identity for attack mitigation control. Attack mitigation 1764 control is an NSF that mitigates an attack such as anti-DDoS 1765 or DDoS-mitigator."; 1766 } 1768 identity ips { 1769 base content-security-control; 1770 description 1771 "Base identity for IPS (Intrusion Prevention System) capability 1772 that prevents malicious activity within a network"; 1773 } 1775 identity url-filtering { 1776 base content-security-control; 1777 description 1778 "Base identity for url filtering capability that limits access 1779 by comparing the web traffic's URL with the URLs for web 1780 filtering in a database"; 1781 } 1783 identity anti-virus { 1784 base content-security-control; 1785 description 1786 "Base identity for anti-virus capability to protect the network 1787 by detecting and removing viruses."; 1788 } 1790 identity voip-volte-filtering { 1791 base content-security-control; 1792 description 1793 "Base identity for advanced NSF VoIP/VoLTE Security Service 1794 capability to filter the VoIP/VoLTE packets or flows."; 1795 reference 1796 "RFC 3261: SIP: Session Initiation Protocol"; 1797 } 1799 identity anti-ddos { 1800 base attack-mitigation-control; 1801 description 1802 "Base identity for advanced NSF Anti-DDoS Attack or DDoS 1803 Mitigator capability."; 1804 } 1806 identity packet-rate { 1807 base anti-ddos; 1808 description 1809 "Identity for advanced NSF Anti-DDoS detecting Packet Rate 1810 Capability where a packet rate is defined as the arrival rate 1811 of Packets toward a victim destination node. The NSF with 1812 this capability can detect the incoming packet rate and create 1813 an alert if the rate exceeds the threshold."; 1815 } 1817 identity flow-rate { 1818 base anti-ddos; 1819 description 1820 "Identity for advanced NSF Anti-DDoS detecting Flow Rate 1821 Capability where a flow rate is defined as the arrival rate of 1822 flows towards a victim destination node. The NSF with this 1823 capability can detect the incoming flow rate and create an 1824 alert if the rate exceeds the threshold."; 1825 } 1827 identity byte-rate { 1828 base anti-ddos; 1829 description 1830 "Identity for advanced NSF Anti-DDoS detecting Byte Rate 1831 Capability where a byte rate is defined as the arrival rate of 1832 Bytes toward a victim destination node. The NSF with this 1833 capability can detect the incoming byte rate and create an 1834 alert if the rate exceeds the threshold."; 1835 } 1837 identity signature-set { 1838 base ips; 1839 description 1840 "Identity for the capability of IPS to set the signature. 1841 Signature is a set of rules to detect an intrusive activity."; 1842 reference 1843 "RFC 4766: Intrusion Detection Message Exchange Requirements - 1844 Section 2.2.13"; 1845 } 1847 identity exception-signature { 1848 base ips; 1849 description 1850 "Identity for the capability of IPS to exclude signatures from 1851 detecting the intrusion."; 1852 reference 1853 "RFC 4766: Intrusion Detection Message Exchange Requirements - 1854 Section 2.2.13"; 1855 } 1857 identity detect { 1858 base anti-virus; 1859 description 1860 "Identity for advanced NSF Antivirus capability to detect 1861 viruses using a security profile. The security profile is used 1862 to scan threats, such as virus, malware, and spyware. The NSF 1863 should be able to update the security profile."; 1864 } 1866 identity exception-files { 1867 base anti-virus; 1868 description 1869 "Identity for advanced NSF Antivirus capability to exclude a 1870 certain file type or name from detection."; 1871 } 1873 identity pre-defined { 1874 base url-filtering; 1875 description 1876 "Identity for pre-defined URL Database condition capability. 1877 where URL database is a public database for URL filtering."; 1878 } 1880 identity user-defined { 1881 base url-filtering; 1882 description 1883 "Identity for user-defined URL Database condition capability. 1884 that allows a users manual addition of URLs for URL 1885 filtering."; 1886 } 1888 identity call-id { 1889 base voip-volte-filtering; 1890 description 1891 "Identity for advanced NSF VoIP/VoLTE Call Identifier (ID) 1892 capability."; 1893 } 1895 identity user-agent { 1896 base voip-volte-filtering; 1897 description 1898 "Identity for advanced NSF VoIP/VoLTE User Agent capability."; 1899 } 1901 /* 1902 * Grouping 1903 */ 1905 grouping nsf-capabilities { 1906 description 1907 "Network Security Function (NSF) Capabilities"; 1908 reference 1909 "RFC 8329: Framework for Interface to Network Security 1910 Functions - I2NSF Flow Security Policy Structure."; 1912 leaf-list directional-capabilities { 1913 type identityref { 1914 base directional; 1915 } 1916 description 1917 "The capability of an NSF for handling directional traffic 1918 flow (i.e., unidirectional or bidirectional traffic flow)."; 1919 } 1921 container event-capabilities { 1922 description 1923 "Capabilities of events. 1924 If a network security function has the event capabilities, 1925 the network security function supports rule execution 1926 according to system event and system alarm."; 1928 reference 1929 "RFC 8329: Framework for Interface to Network Security 1930 Functions - Section 7. 1931 draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF 1932 NSF Monitoring YANG Data Model - System Alarm and 1933 System Events."; 1935 leaf-list system-event-capability { 1936 type identityref { 1937 base system-event; 1938 } 1939 description 1940 "System event capabilities"; 1941 } 1943 leaf-list system-alarm-capability { 1944 type identityref { 1945 base system-alarm; 1946 } 1947 description 1948 "System alarm capabilities"; 1949 } 1951 leaf-list time-capabilities { 1952 type identityref { 1953 base time; 1954 } 1955 description 1956 "The capabilities for activating the policy within a 1957 specific time."; 1958 } 1959 } 1961 container condition-capabilities { 1962 description 1963 "Conditions capabilities."; 1965 container generic-nsf-capabilities { 1966 description 1967 "Conditions capabilities. 1968 If a network security function has the condition 1969 capabilities, the network security function 1970 supports rule execution according to conditions of 1971 IPv4, IPv6, TCP, UDP, SCTP, DCCP, ICMP, or ICMPv6."; 1972 reference 1973 "RFC 768: User Datagram Protocol - UDP. 1974 RFC 791: Internet Protocol - IPv4. 1975 RFC 792: Internet Control Message Protocol - ICMP. 1976 RFC 4443: Internet Control Message Protocol (ICMPv6) 1977 for the Internet Protocol Version 6 (IPv6) Specification 1978 - ICMPv6. 1979 RFC 4960: Stream Control Transmission Protocol - SCTP. 1980 RFC 8200: Internet Protocol, Version 6 (IPv6) 1981 Specification - IPv6. 1982 RFC 8329: Framework for Interface to Network Security 1983 Functions - I2NSF Flow Security Policy Structure. 1984 draft-ietf-tcpm-rfc793bis-25: Transmission Control 1985 Protocol (TCP) Specification"; 1987 leaf-list ethernet-capability { 1988 type identityref { 1989 base ethernet; 1990 } 1991 description 1992 "Media Access Control (MAC) capabilities"; 1993 reference 1994 "IEEE 802.3: IEEE Standard for Ethernet"; 1995 } 1997 leaf-list ipv4-capability { 1998 type identityref { 1999 base ipv4; 2000 } 2001 description 2002 "IPv4 packet capabilities"; 2003 reference 2004 "RFC 791: Internet Protocol"; 2005 } 2007 leaf-list ipv6-capability { 2008 type identityref { 2009 base ipv6; 2010 } 2011 description 2012 "IPv6 packet capabilities"; 2014 reference 2015 "RFC 8200: Internet Protocol, Version 6 (IPv6) 2016 Specification - IPv6"; 2017 } 2019 leaf-list icmpv4-capability { 2020 type identityref { 2021 base icmpv4; 2022 } 2023 description 2024 "ICMPv4 packet capabilities"; 2025 reference 2026 "RFC 792: Internet Control Message Protocol - ICMP"; 2027 } 2029 leaf-list icmpv6-capability { 2030 type identityref { 2031 base icmpv6; 2032 } 2033 description 2034 "ICMPv6 packet capabilities"; 2035 reference 2036 "RFC 4443: Internet Control Message Protocol (ICMPv6) 2037 for the Internet Protocol Version 6 (IPv6) Specification 2038 - ICMPv6"; 2039 } 2041 leaf-list tcp-capability { 2042 type identityref { 2043 base tcp; 2044 } 2045 description 2046 "TCP packet capabilities"; 2047 reference 2048 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 2049 Protocol (TCP) Specification"; 2050 } 2052 leaf-list udp-capability { 2053 type identityref { 2054 base udp; 2055 } 2056 description 2057 "UDP packet capabilities"; 2058 reference 2059 "RFC 768: User Datagram Protocol - UDP"; 2060 } 2061 leaf-list sctp-capability { 2062 type identityref { 2063 base sctp; 2064 } 2065 description 2066 "SCTP packet capabilities"; 2067 reference 2068 "RFC 4960: Stream Control Transmission Protocol - SCTP"; 2069 } 2071 leaf-list dccp-capability { 2072 type identityref { 2073 base dccp; 2074 } 2075 description 2076 "DCCP packet capabilities"; 2077 reference 2078 "RFC 4340: Datagram Congestion Control Protocol - DCCP"; 2079 } 2080 } 2082 container advanced-nsf-capabilities { 2083 description 2084 "Advanced Network Security Function (NSF) capabilities, 2085 such as Anti-DDoS, IPS, and VoIP/VoLTE. 2086 This container contains the leaf-lists of advanced 2087 NSF capabilities"; 2089 leaf-list anti-ddos-capability { 2090 type identityref { 2091 base anti-ddos; 2092 } 2093 description 2094 "Anti-DDoS Attack capabilities"; 2095 } 2097 leaf-list ips-capability { 2098 type identityref { 2099 base ips; 2100 } 2101 description 2102 "IPS capabilities"; 2103 } 2105 leaf-list anti-virus-capability { 2106 type identityref { 2107 base anti-virus; 2108 } 2109 description 2110 "Anti-Virus capabilities"; 2111 } 2113 leaf-list url-capability { 2114 type identityref { 2115 base url-filtering; 2116 } 2117 description 2118 "URL capabilities"; 2119 } 2121 leaf-list voip-volte-filtering-capability { 2122 type identityref { 2123 base voip-volte-filtering; 2124 } 2125 description 2126 "VoIP/VoLTE capabilities"; 2127 } 2128 } 2130 container context-capabilities { 2131 description 2132 "Security context capabilities"; 2133 leaf-list application-filter-capabilities{ 2134 type identityref { 2135 base application-protocol; 2136 } 2137 description 2138 "Context capabilities based on the application protocol"; 2139 } 2141 leaf-list target-capabilities { 2142 type identityref { 2143 base target-device; 2144 } 2145 description 2146 "Context capabilities based on the device attribute that 2147 can identify a device type 2148 (i.e., router, switch, pc, ios, or android)."; 2149 } 2151 leaf-list user-condition-capabilities { 2152 type identityref { 2153 base user-condition; 2154 } 2155 description 2156 "Context capabilities based on user condition, such as 2157 user-id or user-name. The users can collected into a 2158 user-group and identified with group-id or group-name. 2159 An NSF is aware of the IP address of the user provided 2160 by a unified user management system via network. Based 2161 on name-address association, an NSF is able to enforce 2162 the security functions over the given user (or user 2163 group)"; 2164 } 2166 leaf-list geography-capabilities { 2167 type identityref { 2168 base geography-location; 2169 } 2170 description 2171 "Context condition capabilities based on the geographical 2172 location of the source or destination"; 2173 } 2174 } 2175 } 2177 container action-capabilities { 2178 description 2179 "Action capabilities. 2180 If a network security function has the action capabilities, 2181 the network security function supports the attendant 2182 actions for policy rules."; 2184 leaf-list ingress-action-capability { 2185 type identityref { 2186 base ingress-action; 2187 } 2188 description 2189 "Ingress-action capabilities"; 2190 } 2192 leaf-list egress-action-capability { 2193 type identityref { 2194 base egress-action; 2195 } 2196 description 2197 "Egress-action capabilities"; 2198 } 2200 leaf-list log-action-capability { 2201 type identityref { 2202 base log-action; 2203 } 2204 description 2205 "Log-action capabilities"; 2206 } 2207 } 2209 leaf-list resolution-strategy-capabilities { 2210 type identityref { 2211 base resolution-strategy; 2212 } 2213 description 2214 "Resolution strategy capabilities. 2215 The resolution strategies can be used to specify how 2216 to resolve conflicts that occur between the actions 2217 of the same or different policy rules that are matched 2218 for the same packet and by particular NSF."; 2219 } 2221 leaf-list default-action-capabilities { 2222 type identityref { 2223 base default-action; 2224 } 2225 description 2226 "Default action capabilities. 2227 A default action is used to execute I2NSF policy rules 2228 when no rule matches a packet. The default action is 2229 defined as pass, drop, rate-limit, or mirror."; 2230 } 2231 } 2233 /* 2234 * Data nodes 2235 */ 2237 list nsf { 2238 key "nsf-name"; 2239 description 2240 "The list of Network Security Functions (NSFs)"; 2241 leaf nsf-name { 2242 type string; 2243 mandatory true; 2244 description 2245 "The name of Network Security Function (NSF)"; 2246 } 2247 uses nsf-capabilities; 2248 } 2249 } 2250 2252 Figure 3: YANG Data Module of I2NSF Capability 2254 7. IANA Considerations 2256 This document requests IANA to register the following URI in the 2257 "IETF XML Registry" [RFC3688]: 2259 ID: yang:ietf-i2nsf-capability 2260 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2261 Registrant Contact: The IESG. 2262 XML: N/A; the requested URI is an XML namespace. 2263 Filename: [ TBD-at-Registration ] 2264 Reference: [ RFC-to-be ] 2266 This document requests IANA to register the following YANG module in 2267 the "YANG Module Names" registry [RFC7950][RFC8525]: 2269 Name: ietf-i2nsf-capability 2270 Maintained by IANA? N 2271 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2272 Prefix: nsfcap 2273 Module: 2274 Reference: [ RFC-to-be ] 2276 8. Privacy Considerations 2278 This YANG module specifies the capabilities for NSFs. Some of the 2279 capabilities in this document MAY require highly sensitive private 2280 data to operate properly. The usage of such capability MUST be 2281 reported to the users and permitted before using the private 2282 information related to the capability. Using any of the capabilities 2283 that require private data MUST preserve the privacy by preventing any 2284 leakage or unauthorized disclosure of the private data. 2286 In regards to the privacy data used, the security for accessibility 2287 of the data should be tightly secured and monitored. The Security 2288 Considerations are discussed in Section 9. 2290 9. Security Considerations 2292 The YANG module specified in this document defines a data schema 2293 designed to be accessed through network management protocols such as 2294 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest layer of NETCONF 2295 protocol layers MUST use Secure Shell (SSH) [RFC4254][RFC6242] as a 2296 secure transport layer. The lowest layer of RESTCONF protocol layers 2297 MUST use HTTP over Transport Layer Security (TLS), that is, HTTPS 2298 [RFC7230][RFC8446] as a secure transport layer. 2300 The Network Configuration Access Control Model (NACM) [RFC8341] 2301 provides a means of restricting access to specific NETCONF or 2302 RESTCONF users to a preconfigured subset of all available NETCONF or 2303 RESTCONF protocol operations and contents. Thus, NACM SHOULD be used 2304 to restrict the NSF registration from unauthorized users. 2306 There are a number of data nodes defined in this YANG module that are 2307 writable, creatable, and deletable (i.e., config true, which is the 2308 default). These data nodes may be considered sensitive or vulnerable 2309 in some network environments. Write operations to these data nodes 2310 could have a negative effect on network and security operations. 2311 These data nodes are collected into a single list node. This list 2312 node is defined by list nsf with the following sensitivity/ 2313 vulnerability: 2315 * list nsf: An attacker could alter the security capabilities 2316 associated with an NSF by disabling or enabling the functionality 2317 of the security capabilities of the NSF. 2319 Some of the readable data nodes in this YANG module may be considered 2320 sensitive or vulnerable in some network environments. It is thus 2321 important to control read access (e.g., via get, get-config, or 2322 notification) to these data nodes. These are the subtrees and data 2323 nodes with their sensitivity/vulnerability: 2325 * list nsf: The leak of this node to an attacker could reveal the 2326 specific configuration of security controls to an attacker. An 2327 attacker can craft an attack path that avoids observation or 2328 mitigations; one may reveal topology information to inform 2329 additional targets or enable lateral movement; one enables the 2330 construction of an attack path that avoids observation or 2331 mitigations; one provides an indication that the operator has 2332 discovered the attack. 2334 Some of the features that this document defines capability indicators 2335 for are highly sensitive and/or privileged operations that inherently 2336 require access to individuals' private data. These are subtrees and 2337 data nodes that are considered privacy sensitive: 2339 * voip-volte-filtering-capability: The NSF that is able to filter 2340 VoIP/VoLTE calls might identify certain individual identification. 2342 * user-condition-capabilities: The capability uses a set of IP 2343 addresses mapped to users. 2345 * geography-capabilities: The IP address used in this capability can 2346 identify a user's geographical location. 2348 It is noted that some private information is made accessible in this 2349 manner. Thus, the nodes/entities given access to this data MUST be 2350 tightly secured, monitored, and audited to prevent leakage or other 2351 unauthorized disclosure of private data. Refer to [RFC6973] for the 2352 description of privacy aspects that protocol designers (including 2353 YANG data model designers) should consider along with regular 2354 security and privacy analysis. 2356 10. References 2358 10.1. Normative References 2360 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2361 DOI 10.17487/RFC0768, August 1980, 2362 . 2364 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2365 DOI 10.17487/RFC0791, September 1981, 2366 . 2368 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2369 RFC 792, DOI 10.17487/RFC0792, September 1981, 2370 . 2372 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 2373 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 2374 1983, . 2376 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2377 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 2378 . 2380 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2381 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 2382 . 2384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2385 Requirement Levels", BCP 14, RFC 2119, 2386 DOI 10.17487/RFC2119, March 1997, 2387 . 2389 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2390 "Definition of the Differentiated Services Field (DS 2391 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2392 DOI 10.17487/RFC2474, December 1998, 2393 . 2395 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2396 of Explicit Congestion Notification (ECN) to IP", 2397 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2398 . 2400 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2401 A., Peterson, J., Sparks, R., Handley, M., and E. 2402 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2403 DOI 10.17487/RFC3261, June 2002, 2404 . 2406 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 2407 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 2408 . 2410 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2411 DOI 10.17487/RFC3688, January 2004, 2412 . 2414 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 2415 Protocol Assigned Numbers", RFC 4250, 2416 DOI 10.17487/RFC4250, January 2006, 2417 . 2419 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2420 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 2421 January 2006, . 2423 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2424 Congestion Control Protocol (DCCP)", RFC 4340, 2425 DOI 10.17487/RFC4340, March 2006, 2426 . 2428 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2429 Control Message Protocol (ICMPv6) for the Internet 2430 Protocol Version 6 (IPv6) Specification", STD 89, 2431 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2432 . 2434 [RFC4766] Wood, M. and M. Erlinger, "Intrusion Detection Message 2435 Exchange Requirements", RFC 4766, DOI 10.17487/RFC4766, 2436 March 2007, . 2438 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2439 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2440 . 2442 [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export 2443 Using IP Flow Information Export (IPFIX)", RFC 5103, 2444 DOI 10.17487/RFC5103, January 2008, 2445 . 2447 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2448 DOI 10.17487/RFC5321, October 2008, 2449 . 2451 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 2452 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 2453 September 2009, . 2455 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2456 the Network Configuration Protocol (NETCONF)", RFC 6020, 2457 DOI 10.17487/RFC6020, October 2010, 2458 . 2460 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2461 and A. Bierman, Ed., "Network Configuration Protocol 2462 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2463 . 2465 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2466 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2467 . 2469 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2470 Cheshire, "Internet Assigned Numbers Authority (IANA) 2471 Procedures for the Management of the Service Name and 2472 Transport Protocol Port Number Registry", BCP 165, 2473 RFC 6335, DOI 10.17487/RFC6335, August 2011, 2474 . 2476 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2477 "IPv6 Flow Label Specification", RFC 6437, 2478 DOI 10.17487/RFC6437, November 2011, 2479 . 2481 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2482 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2483 . 2485 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2486 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2487 . 2489 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2490 Protocol (HTTP/1.1): Message Syntax and Routing", 2491 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2492 . 2494 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2495 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2496 DOI 10.17487/RFC7231, June 2014, 2497 . 2499 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 2500 Scheffenegger, Ed., "TCP Extensions for High Performance", 2501 RFC 7323, DOI 10.17487/RFC7323, September 2014, 2502 . 2504 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2505 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2506 . 2508 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2509 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2510 . 2512 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2513 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2514 May 2017, . 2516 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2517 (IPv6) Specification", STD 86, RFC 8200, 2518 DOI 10.17487/RFC8200, July 2017, 2519 . 2521 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2522 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2523 . 2525 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2526 Access Control Model", STD 91, RFC 8341, 2527 DOI 10.17487/RFC8341, March 2018, 2528 . 2530 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2531 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2532 DOI 10.17487/RFC8407, October 2018, 2533 . 2535 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2536 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2537 . 2539 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 2540 and R. Wilton, "YANG Library", RFC 8525, 2541 DOI 10.17487/RFC8525, March 2019, 2542 . 2544 [I-D.ietf-tcpm-accurate-ecn] 2545 Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More 2546 Accurate ECN Feedback in TCP", Work in Progress, Internet- 2547 Draft, draft-ietf-tcpm-accurate-ecn-15, 12 July 2021, 2548 . 2551 [I-D.ietf-tsvwg-udp-options] 2552 Touch, J., "Transport Options for UDP", Work in Progress, 2553 Internet-Draft, draft-ietf-tsvwg-udp-options-13, 19 June 2554 2021, . 2557 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 2558 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 2559 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 2560 Model", Work in Progress, Internet-Draft, draft-ietf- 2561 i2nsf-nsf-monitoring-data-model-09, 24 August 2021, 2562 . 2565 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 2566 Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin, 2567 "I2NSF Network Security Function-Facing Interface YANG 2568 Data Model", Work in Progress, Internet-Draft, draft-ietf- 2569 i2nsf-nsf-facing-interface-dm-13, 15 August 2021, 2570 . 2573 [I-D.ietf-i2nsf-registration-interface-dm] 2574 Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Park, 2575 "I2NSF Registration Interface YANG Data Model", Work in 2576 Progress, Internet-Draft, draft-ietf-i2nsf-registration- 2577 interface-dm-11, 21 August 2021, 2578 . 2581 10.2. Informative References 2583 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2584 DOI 10.17487/RFC2818, May 2000, 2585 . 2587 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2588 RFC 6691, DOI 10.17487/RFC6691, July 2012, 2589 . 2591 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2592 Morris, J., Hansen, M., and R. Smith, "Privacy 2593 Considerations for Internet Protocols", RFC 6973, 2594 DOI 10.17487/RFC6973, July 2013, 2595 . 2597 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2598 and J. Jeong, "Interface to Network Security Functions 2599 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2600 DOI 10.17487/RFC8192, July 2017, 2601 . 2603 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2604 Kumar, "Framework for Interface to Network Security 2605 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2606 . 2608 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 2609 Kumari, "A Format for Self-Published IP Geolocation 2610 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 2611 . 2613 [I-D.ietf-tcpm-rfc793bis] 2614 Eddy, W. M., "Transmission Control Protocol (TCP) 2615 Specification", Work in Progress, Internet-Draft, draft- 2616 ietf-tcpm-rfc793bis-25, 7 September 2021, 2617 . 2620 [IANA-Protocol-Numbers] 2621 "Assigned Internet Protocol Numbers", Available: 2622 https://www.iana.org/assignments/protocol- 2623 numbers/protocol-numbers.xhtml, September 2020. 2625 [IEEE802.3-2018] 2626 Committee, I. S., "IEEE 802.3-2018 - IEEE Standard for 2627 Ethernet", August 2018, 2628 . 2630 [Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and 2631 management of firewall policies", 2004. 2633 [Hirschman] 2634 Hirschman, L. and R. Gaizauskas, "Natural Language 2635 Question Answering: The View from Here", Natural Language 2636 Engineering 7:4, pgs 275-300, Cambridge University Press , 2637 November 2001. 2639 [Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns", 2640 ISBN 0-32-120068-3 , 2003. 2642 [Martin] Martin, R.C., "Agile Software Development, Principles, 2643 Patterns, and Practices", Prentice-Hall , ISBN: 2644 0-13-597444-5 , 2002. 2646 [OODMP] "https://www.oodesign.com/mediator-pattern.html". 2648 [OODOP] "https://www.oodesign.com/mediator-pattern.html". 2650 [OODSRP] "https://www.oodesign.com/mediator-pattern.html". 2652 Appendix A. Configuration Examples 2654 This section shows configuration examples of "ietf-i2nsf-capability" 2655 module for capabilities registration of general firewall. 2657 A.1. Example 1: Registration for the Capabilities of a General Firewall 2659 This section shows a configuration example for the capabilities 2660 registration of a general firewall in either an IPv4 network or an 2661 IPv6 network. 2663 2664 general_firewall 2665 2666 2667 next-header 2668 flow-direction 2669 source-address 2670 destination-address 2671 source-port-number 2672 destination-port-number 2673 source-port-number 2674 destination-port-number 2675 2676 2677 2678 pass 2679 drop 2680 mirror 2681 pass 2682 drop 2683 mirror 2684 2685 2687 Figure 4: Configuration XML for the Capabilities Registration of 2688 a General Firewall in an IPv4 Network 2690 Figure 4 shows the configuration XML for the capabilities 2691 registration of a general firewall as an NSF in an IPv4 network. Its 2692 capabilities are as follows. 2694 1. The name of the NSF is general_firewall. 2696 2. The NSF can inspect the IPv4 protocol header field, flow 2697 direction, source address(es), and destination address(es) 2699 3. The NSF can inspect the port number(s) and flow direction for the 2700 transport layer protocol, i.e., TCP and UDP. 2702 4. The NSF can control whether the packets are allowed to pass, 2703 drop, or mirror. 2705 2706 general_firewall 2707 2708 2709 next-header 2710 flow-direction 2711 source-address 2712 destination-address 2713 source-port-number 2714 destination-port-number 2715 source-port-number 2716 destination-port-number 2717 2718 2719 2720 pass 2721 drop 2722 mirror 2723 pass 2724 drop 2725 mirror 2726 2727 2729 Figure 5: Configuration XML for the Capabilities Registration of 2730 a General Firewall in an IPv6 Network 2732 In addition, Figure 5 shows the configuration XML for the 2733 capabilities registration of a general firewall as an NSF in an IPv6 2734 network. Its capabilities are as follows. 2736 1. The name of the NSF is general_firewall. 2738 2. The NSF can inspect IPv6 next header, flow direction, source 2739 address(es), and destination address(es) 2741 3. The NSF can inspect the port number(s) and flow direction for the 2742 transport layer protocol, i.e., TCP and UDP. 2744 4. The NSF can control whether the packets are allowed to pass, 2745 drop, or mirror. 2747 A.2. Example 2: Registration for the Capabilities of a Time-based 2748 Firewall 2750 This section shows a configuration example for the capabilities 2751 registration of a time-based firewall in either an IPv4 network or an 2752 IPv6 network. 2754 2755 time_based_firewall 2756 2757 absolute-time 2758 periodic-time 2759 2760 2761 2762 next-header 2763 flow-direction 2764 source-address 2765 destination-address 2766 2767 2768 2769 pass 2770 drop 2771 mirror 2772 pass 2773 drop 2774 mirror 2775 2776 2778 Figure 6: Configuration XML for the Capabilities Registration of 2779 a Time-based Firewall in an IPv4 Network 2781 Figure 6 shows the configuration XML for the capabilities 2782 registration of a time-based firewall as an NSF in an IPv4 network. 2783 Its capabilities are as follows. 2785 1. The name of the NSF is time_based_firewall. 2787 2. The NSF can execute the security policy rule according to 2788 absolute time and periodic time. 2790 3. The NSF can inspect the IPv4 protocol header field, flow 2791 direction, source address(es), and destination address(es). 2793 4. The NSF can control whether the packets are allowed to pass, 2794 drop, or mirror. 2796 2797 time_based_firewall 2798 2799 absolute-time 2800 periodic-time 2801 2802 2803 2804 next-header 2805 flow-direction 2806 source-address 2807 destination-address 2808 2809 2810 2811 pass 2812 drop 2813 mirror 2814 pass 2815 drop 2816 mirror 2817 2818 2820 Figure 7: Configuration XML for the Capabilities Registration of 2821 a Time-based Firewall in an IPv6 Network 2823 In addition, Figure 7 shows the configuration XML for the 2824 capabilities registration of a time-based firewall as an NSF in an 2825 IPv6 network. Its capabilities are as follows. 2827 1. The name of the NSF is time_based_firewall. 2829 2. The NSF can execute the security policy rule according to 2830 absolute time and periodic time. 2832 3. The NSF can inspect the IPv6 protocol header field, flow 2833 direction, source address(es), and destination address(es). 2835 4. The NSF can control whether the packets are allowed to pass, 2836 drop, or mirror. 2838 A.3. Example 3: Registration for the Capabilities of a Web Filter 2840 This section shows a configuration example for the capabilities 2841 registration of a web filter. 2843 2844 web_filter 2845 2846 2847 user-defined 2848 2849 2850 2851 pass 2852 drop 2853 mirror 2854 pass 2855 drop 2856 mirror 2857 2858 2860 Figure 8: Configuration XML for the Capabilities Registration of 2861 a Web Filter 2863 Figure 8 shows the configuration XML for the capabilities 2864 registration of a web filter as an NSF. Its capabilities are as 2865 follows. 2867 1. The name of the NSF is web_filter. 2869 2. The NSF can inspect a URL matched from a user-defined URL. User 2870 can specify their own URL. 2872 3. The NSF can control whether the packets are allowed to pass, 2873 drop, or mirror. 2875 A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE 2876 Filter 2878 This section shows a configuration example for the capabilities 2879 registration of a VoIP/VoLTE filter. 2881 2882 voip_volte_filter 2883 2884 2885 2886 call-id 2887 2888 2889 2890 2891 pass 2892 drop 2893 mirror 2894 pass 2895 drop 2896 mirror 2897 2898 2900 Figure 9: Configuration XML for the Capabilities Registration of 2901 a VoIP/VoLTE Filter 2903 Figure 9 shows the configuration XML for the capabilities 2904 registration of a VoIP/VoLTE filter as an NSF. Its capabilities are 2905 as follows. 2907 1. The name of the NSF is voip_volte_filter. 2909 2. The NSF can inspect a voice call id for VoIP/VoLTE packets. 2911 3. The NSF can control whether the packets are allowed to pass, 2912 drop, or mirror. 2914 A.5. Example 5: Registration for the Capabilities of a HTTP and HTTPS 2915 Flood Mitigator 2917 This section shows a configuration example for the capabilities 2918 registration of a HTTP and HTTPS flood mitigator. 2920 2921 DDoS_mitigator 2922 2923 2924 packet-rate 2925 byte-rate 2926 flow-rate 2927 2928 2929 2930 pass 2931 drop 2932 mirror 2933 pass 2934 drop 2935 mirror 2936 2937 2939 Figure 10: Configuration XML for the Capabilities Registration of 2940 a HTTP and HTTPS Flood Mitigator 2942 Figure 10 shows the configuration XML for the capabilities 2943 registration of a HTTP and HTTPS flood mitigator as an NSF. Its 2944 capabilities are as follows. 2946 1. The name of the NSF is DDoS_mitigator. 2948 2. The NSF can detect the amount of packet, flow, and byte rate in 2949 the network for potential DDoS Attack. 2951 3. The NSF can control whether the packets are allowed to pass, 2952 drop, or mirror. 2954 Appendix B. Acknowledgments 2956 This work was supported by Institute of Information & Communications 2957 Technology Planning & Evaluation (IITP) grant funded by the Korea 2958 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 2959 Security Intelligence Technology Development for the Customized 2960 Security Service Provisioning). This work was supported in part by 2961 the IITP grant funded by the MSIT (2020-0-00395, Standard Development 2962 of Blockchain based Network Management Automation Technology). 2964 Appendix C. Contributors 2966 This document is made by the group effort of I2NSF working group. 2967 Many people actively contributed to this document, such as Acee 2968 Lindem, Roman Danyliw, and Tom Petch. The authors sincerely 2969 appreciate their contributions. 2971 The following are co-authors of this document: 2973 Patrick Lingga Department of Electrical and Computer Engineering 2974 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 2975 16419 Republic of Korea EMail: patricklink@skku.edu 2977 Liang Xia Huawei 101 Software Avenue Nanjing, Jiangsu 210012 China 2978 EMail: Frank.Xialiang@huawei.com 2980 Cataldo Basile Politecnico di Torino Corso Duca degli Abruzzi, 34 2981 Torino, 10129 Italy EMail: cataldo.basile@polito.it 2983 John Strassner Huawei 2330 Central Expressway Santa Clara, CA 95050 2984 USA EMail: John.sc.Strassner@huawei.com 2986 Diego R. Lopez Telefonica I+D Zurbaran, 12 Madrid, 28010 Spain 2987 Email: diego.r.lopez@telefonica.com 2989 Hyoungshick Kim Department of Computer Science and Engineering 2990 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 2991 16419 Republic of Korea EMail: hyoung@skku.edu 2993 Daeyoung Hyun Department of Computer Science and Engineering 2994 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 2995 16419 Republic of Korea EMail: dyhyun@skku.edu 2997 Dongjin Hong Department of Electronic, Electrical and Computer 2998 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 2999 Gyeonggi-do 16419 Republic of Korea EMail: dong.jin@skku.edu 3001 Jung-Soo Park Electronics and Telecommunications Research Institute 3002 218 Gajeong-Ro, Yuseong-Gu Daejeon, 34129 Republic of Korea EMail: 3003 pjs@etri.re.kr 3005 Tae-Jin Ahn Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 3006 Republic of Korea EMail: taejin.ahn@kt.com 3008 Se-Hui Lee Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 3009 Republic of Korea EMail: sehuilee@kt.com 3011 Authors' Addresses 3013 Susan Hares (editor) 3014 Huawei 3015 7453 Hickory Hill 3016 Saline, MI 48176 3017 United States of America 3019 Phone: +1-734-604-0332 3020 Email: shares@ndzh.com 3022 Jaehoon (Paul) Jeong (editor) 3023 Department of Computer Science and Engineering 3024 Sungkyunkwan University 3025 2066 Seobu-Ro, Jangan-Gu 3026 Suwon 3027 Gyeonggi-Do 3028 16419 3029 Republic of Korea 3031 Phone: +82 31 299 4957 3032 Email: pauljeong@skku.edu 3033 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3035 Jinyong (Tim) Kim 3036 Department of Electronic, Electrical and Computer Engineering 3037 Sungkyunkwan University 3038 2066 Seobu-Ro, Jangan-Gu 3039 Suwon 3040 Gyeonggi-Do 3041 16419 3042 Republic of Korea 3044 Phone: +82 10 8273 0930 3045 Email: timkim@skku.edu 3047 Robert Moskowitz 3048 HTT Consulting 3049 Oak Park, MI 3050 United States of America 3052 Phone: +1-248-968-9809 3053 Email: rgm@htt-consult.com 3054 Qiushi Lin 3055 Huawei 3056 Huawei Industrial Base 3057 Shenzhen 3058 Guangdong 518129, 3059 China 3061 Email: linqiushi@huawei.com