idnits 2.17.1 draft-ietf-i2nsf-capability-data-model-17.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 : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (14 August 2021) is 986 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** 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-08 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-12 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-10 -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-rfc793bis-24 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group S. Hares, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track J. Jeong, Ed. 5 Expires: 15 February 2022 J. Kim 6 Sungkyunkwan University 7 R. Moskowitz 8 HTT Consulting 9 Q. Lin 10 Huawei 11 14 August 2021 13 I2NSF Capability YANG Data Model 14 draft-ietf-i2nsf-capability-data-model-17 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 15 February 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 . . . . . . . . . . . . . . . . . . . . . 48 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 . . . . . . . . . . . . . . . . . . . . . . 61 80 A.5. Example 5: Registration for the Capabilities of a HTTP and 81 HTTPS Flood Mitigator . . . . . . . . . . . . . . . . . . 62 82 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 63 83 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 64 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 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 structurizes the NSF Monitoring 114 Interface YANG data model [I-D.ietf-i2nsf-nsf-monitoring-data-model] 115 and the NSF-Facing Interface YANG Data Model 116 [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 (e.g., 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] [Galitsky]. In this 188 context, the CapIM and the derived data model can provide important 189 and rich 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 Boolean clauses: an Event 324 clause, a Condition clause, and an Action clause. This structure is 325 also called an ECA (Event-Condition-Action) Policy Rule. A Boolean 326 clause is a logical statement that evaluates to either TRUE or FALSE. 327 It 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 ipv4-capability* identityref 543 | | +--rw ipv6-capability* identityref 544 | | +--rw icmpv4-capability* identityref 545 | | +--rw icmpv6-capability* identityref 546 | | +--rw tcp-capability* identityref 547 | | +--rw udp-capability* identityref 548 | | +--rw sctp-capability* identityref 549 | | +--rw dccp-capability* identityref 550 | +--rw advanced-nsf-capabilities 551 | | +--rw anti-ddos-capability* identityref 552 | | +--rw ips-capability* identityref 553 | | +--rw url-capability* identityref 554 | | +--rw voip-volte-filtering-capability* identityref 555 | +--rw context-capabilities 556 | +--rw application-filter-capabilities* identityref 557 | +--rw target-capabilities* identityref 558 | +--rw user-condition-capabilities* identityref 559 | +--rw geography-capabilities* identityref 560 +--rw action-capabilities 561 | +--rw ingress-action-capability* identityref 562 | +--rw egress-action-capability* identityref 563 | +--rw log-action-capability* identityref 564 +--rw resolution-strategy-capabilities* identityref 565 +--rw default-action-capabilities* identityref 567 Figure 2: YANG Tree Diagram of Capabilities of Network Security 568 Functions 570 The data model in this document provides identities for the 571 capabilities of NSFs. Every identity in the data model represents 572 the capability of an NSF. Each identity is explained in the 573 description of the identity. 575 Event capabilities are used to specify the capabilities that describe 576 an event that would trigger the evaluation of the condition clause of 577 the I2NSF Policy Rule. The defined event capabilities are system 578 event, system alarm, and time. Time capabilities are used to specify 579 the capabilities which describe when to execute the I2NSF policy 580 rule. The time capabilities are defined in terms of absolute time 581 and periodic time. The absolute time means the exact time to start 582 or end. The periodic time means repeated time like day, week, month, 583 or year. 585 Condition capabilities are used to specify capabilities of a set of 586 attributes, features, and/or values that are to be compared with a 587 set of known attributes, features, and/or values in order to 588 determine whether a set of actions needs to be executed or not so 589 that an imperative I2NSF policy rule can be executed. In this 590 document, two kinds of condition capabilities are used to classify 591 different capabilities of NSFs such as generic-nsf-capabilities and 592 advanced-nsf-capabilities. First, the generic-nsf-capabilities 593 define NSFs that operate on packet header for layer 2 (i.e., Ethernet 594 capability), layer 3 (i.e., IPv4 capability, IPv6 capability, ICMPv4 595 capability, and ICMPv6 capability.), and layer 4 (i.e., TCP 596 capability, UDP capability, SCTP capability, and DCCP capability). 597 Second, the advanced-nsf-capabilities define NSFs that operate on 598 features different from the generic-nsf-capabilities, e.g., the 599 payload, cross flow state, application layer, traffic statistics, 600 network behavior, etc. This document defines the advanced-nsf into 601 two categories such as content-security-control and attack- 602 mitigation-control. 604 * Content security control is an NSF that evaluates the payload of a 605 packet, such as Intrusion Prevention System (IPS), URL-Filtering, 606 Antivirus, and VoIP/VoLTE Filter. 608 * Attack mitigation control is an NSF that mitigates an attack such 609 as anti-DDoS (DDoS-mitigator). 611 The advanced-nsf can be extended with other types of NSFs. This 612 document only provides five advanced-nsf capabilities, i.e., IPS 613 capability, URL-Filtering capability, Antivirus capability, VoIP/ 614 VoLTE Filter capability, and Anti-DDoS capability. Note that VoIP 615 and VoLTE are merged into a single capability in this document 616 because VoIP and VoLTE use the Session Initiation Protocol (SIP) 617 [RFC3261] for a call setup. See Section 3.1 for more information 618 about the condition in the ECA policy model. 620 The context capabilities provide extra information for the condition. 621 The given context conditions are application filter, target, user 622 condition, and geography location. The application filter capability 623 is capability in matching the packet based on the application 624 protocol, such as HTTP, HTTPS, FTP, etc. The target capability is 625 capability in matching the type of the target devices, such as PC, 626 IoT, Network Infrastructure devices, etc. The user condition is 627 capability in matching the users of the network by mapping each user 628 ID to an IP address. Users can be combined into one group. The 629 geography location capability is capability in matching the 630 geographical location of a source or destination of a packet. 632 Action capabilities are used to specify the capabilities that 633 describe the control and monitoring aspects of flow-based NSFs when 634 the event and condition clauses are satisfied. The action 635 capabilities are defined as ingress-action capability, egress-action 636 capability, and log-action capability. See Section 3.1 for more 637 information about the action in the ECA policy model. Also, see 638 Section 7.2 (NSF-Facing Flow Security Policy Structure) in [RFC8329] 639 for more information about the ingress and egress actions. In 640 addition, see Section 9.1 (Flow-Based NSF Capability 641 Characterization) in [RFC8329] and Section 7.5 (NSF Logs) in 642 [I-D.ietf-i2nsf-nsf-monitoring-data-model] for more information about 643 logging at NSFs. 645 Resolution strategy capabilities are used to specify the capabilities 646 that describe conflicts that occur between the actions of the same or 647 different policy rules that are matched and contained in this 648 particular NSF. The resolution strategy capabilities are defined as 649 First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized 650 Matching Rule (PMR), Prioritized Matching Rule with Errors (PMRE), 651 and Prioritized Matching Rule with No Errors (PMRN). See Section 3.2 652 for more information about the resolution strategy. 654 Default action capabilities are used to specify the capabilities that 655 describe how to execute I2NSF policy rules when no rule matches a 656 packet. The default action capabilities are defined as pass, drop, 657 rate-limit, and mirror. See Section 3.2 for more information about 658 the default action. 660 6. YANG Data Model of I2NSF NSF Capability 662 This section introduces a YANG module for NSFs' capabilities, as 663 defined in the Section 3. 665 It makes references to 667 * [RFC0768] 669 * [RFC0791] 671 * [RFC0792] 673 * [RFC0793] 674 * [RFC2474] 676 * [RFC3168] 678 * [RFC3261] 680 * [RFC3501] 682 * [RFC4340] 684 * [RFC4443] 686 * [RFC4960] 688 * [RFC5595] 690 * [RFC6335] 692 * [RFC6437] 694 * [RFC6691] 696 * [RFC6864] 698 * [RFC7230] 700 * [RFC7231] 702 * [RFC7296] 704 * [RFC7323] 706 * [RFC8200] 708 * [RFC8329] 710 * [RFC8519] 712 * [RFC8805] 714 * [IANA-Protocol-Numbers] 716 * [I-D.ietf-tcpm-rfc793bis] 718 * [I-D.ietf-tcpm-accurate-ecn] 720 * [I-D.ietf-tsvwg-udp-options] 721 * [I-D.ietf-i2nsf-nsf-monitoring-data-model] 723 file "ietf-i2nsf-capability@2021-08-14.yang" 724 module ietf-i2nsf-capability { 725 yang-version 1.1; 726 namespace 727 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; 728 prefix 729 nsfcap; 731 organization 732 "IETF I2NSF (Interface to Network Security Functions) 733 Working Group"; 735 contact 736 "WG Web: 737 WG List: 739 Editor: Jaehoon Paul Jeong 740 742 Editor: Jinyong Tim Kim 743 745 Editor: Patrick Lingga 746 748 Editor: Susan Hares 749 "; 751 description 752 "This module is a YANG module for I2NSF Network Security 753 Functions (NSFs)'s Capabilities. 755 Copyright (c) 2021 IETF Trust and the persons identified as 756 authors of the code. All rights reserved. 758 Redistribution and use in source and binary forms, with or 759 without modification, is permitted pursuant to, and subject to 760 the license terms contained in, the Simplified BSD License set 761 forth in Section 4.c of the IETF Trust's Legal Provisions 762 Relating to IETF Documents 763 (https://trustee.ietf.org/license-info). 765 This version of this YANG module is part of RFC XXXX 766 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 767 for full legal notices."; 769 // RFC Ed.: replace XXXX with an actual RFC number and remove 770 // this note. 772 revision "2021-08-14"{ 773 description "Initial revision."; 774 reference 775 "RFC XXXX: I2NSF Capability YANG Data Model"; 777 // RFC Ed.: replace XXXX with an actual RFC number and remove 778 // this note. 779 } 781 /* 782 * Identities 783 */ 785 identity event { 786 description 787 "Base identity for I2NSF events."; 788 reference 789 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 790 Monitoring YANG Data Model - Event"; 791 } 793 identity system-event { 794 base event; 795 description 796 "Identity for system event"; 797 reference 798 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 799 Monitoring YANG Data Model - System event"; 800 } 802 identity system-alarm { 803 base event; 804 description 805 "Identity for system alarm"; 806 reference 807 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 808 Monitoring YANG Data Model - System alarm"; 809 } 811 identity time { 812 base event; 813 description 814 "Identity for time capabilities"; 815 } 816 identity access-violation { 817 base system-event; 818 description 819 "Identity for access violation event"; 820 reference 821 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 822 Monitoring YANG Data Model - System event for access 823 violation"; 824 } 826 identity configuration-change { 827 base system-event; 828 description 829 "Identity for configuration change event"; 830 reference 831 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 832 Monitoring YANG Data Model - System event for configuration 833 change"; 834 } 836 identity memory-alarm { 837 base system-alarm; 838 description 839 "Identity for memory alarm. Alarm when memory usage 840 exceeds a threshold."; 841 reference 842 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 843 Monitoring YANG Data Model - System alarm for memory"; 844 } 846 identity cpu-alarm { 847 base system-alarm; 848 description 849 "Identity for CPU alarm. Alarm when CPU usage 850 exceeds a threshold."; 851 reference 852 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 853 Monitoring YANG Data Model - System alarm for CPU"; 854 } 856 identity disk-alarm { 857 base system-alarm; 858 description 859 "Identity for disk alarm. Alarm when disk 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 disk"; 865 } 867 identity hardware-alarm { 868 base system-alarm; 869 description 870 "Identity for hardware alarm. Alarm when a hardware failure 871 or hardware degradation occurs."; 872 reference 873 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 874 Monitoring YANG Data Model - System alarm for hardware"; 875 } 877 identity interface-alarm { 878 base system-alarm; 879 description 880 "Identity for interface alarm. Alarm when interface usage 881 exceeds a threshold."; 882 reference 883 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 884 Monitoring YANG Data Model - System alarm for interface"; 885 } 887 identity absolute-time { 888 base time; 889 description 890 "absolute time capabilities. 891 If a network security function has the absolute time 892 capability, the network security function supports 893 rule execution according to absolute time."; 894 } 896 identity periodic-time { 897 base time; 898 description 899 "periodic time capabilities. 900 If a network security function has the periodic time 901 capability, the network security function supports 902 rule execution according to periodic time."; 903 } 905 identity target-device { 906 description 907 "Identity for target condition capability. The capability for 908 matching the target device type."; 909 } 911 identity computer { 912 base target-device; 913 description 914 "Identity for computer such as personal computer (PC) 915 and server"; 916 } 918 identity mobile-phone { 919 base target-device; 920 description 921 "Identity for mobile-phone such as smartphone and 922 cellphone"; 923 } 925 identity voip-volte-phone { 926 base target-device; 927 description 928 "Identity for voip-volte-phone"; 929 } 931 identity tablet { 932 base target-device; 933 description 934 "Identity for tablet"; 935 } 937 identity network-infrastructure-device { 938 base target-device; 939 description 940 "Identity for network infrastructure devices 941 such as switch, router, and access point"; 942 } 944 identity iot { 945 base target-device; 946 description 947 "Identity for IoT (Internet of Things)"; 948 } 950 identity ot { 951 base target-device; 952 description 953 "Identity for Operational Technology"; 954 } 956 identity vehicle { 957 base target-device; 958 description 959 "Identity for vehicle that connects to and shares 960 data through the Internet"; 962 } 964 identity user-condition { 965 description 966 "Base identity for user condition capability. This is the 967 capability of mapping user(s) into their corresponding IP 968 address"; 969 } 971 identity user { 972 base user-condition; 973 description 974 "Identity for user condition capability. 975 A user (e.g., employee) can be mapped to an IP address of 976 a computing device (e.g., computer, laptop, and virtual 977 machine) which the user is using."; 978 } 980 identity group { 981 base user-condition; 982 description 983 "Identity for group condition capability. 984 A group (e.g., employees) can be mapped to multiple IP 985 addresses of computing devices (e.g., computers, laptops, 986 and virtual machines) which the group is using."; 987 } 989 identity geography-location { 990 description 991 "Identity for geography condition capability"; 992 reference 993 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 994 An access control for a geographical location (i.e., 995 geolocation) that has the corresponding IP prefix."; 996 } 998 identity source-location { 999 base geography-location; 1000 description 1001 "Identity for source geography location condition capability"; 1002 reference 1003 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1004 An access control for a geographical location (i.e., 1005 geolocation) that has the corresponding IP prefix."; 1006 } 1008 identity destination-location { 1009 base geography-location; 1010 description 1011 "Identity for destination geography location condition 1012 capability"; 1013 reference 1014 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1015 An access control for a geographical location (i.e., 1016 geolocation) that has the corresponding IP prefix."; 1017 } 1019 identity directional { 1020 description 1021 "Base identity for directional traffic flow capability"; 1022 reference 1023 "RFC 5101: Specification of the IP Flow Information 1024 Export (IPFIX) Protocol for the Exchange of IP 1025 Traffic Flow Information - Terminology Unidirectional 1026 and Bidirectional Flow"; 1027 } 1029 identity unidirectional { 1030 base directional; 1031 description 1032 "Identity for unirectional traffic flow."; 1033 reference 1034 "RFC 5101: Specification of the IP Flow Information 1035 Export (IPFIX) Protocol for the Exchange of IP 1036 Traffic Flow Information - Terminology Unidirectional 1037 Flow"; 1038 } 1040 identity bidirectional { 1041 base directional; 1042 description 1043 "Identity for bidirectional traffic flow."; 1044 reference 1045 "RFC 5101: Specification of the IP Flow Information 1046 Export (IPFIX) Protocol for the Exchange of IP 1047 Traffic Flow Information - Terminology Bidirectional 1048 Flow"; 1049 } 1051 identity protocol { 1052 description 1053 "Base identity for Internet Protocols"; 1054 } 1056 identity ethernet { 1057 base protocol; 1058 description 1059 "Base identity for data link layer protocol."; 1060 } 1062 identity source-mac-address { 1063 base ethernet; 1064 description 1065 "Identity for the capability of matching Media Access Control 1066 (MAC) source address(es) condition capability."; 1067 reference 1068 "IEEE 802.3: IEEE Standard for Ethernet"; 1069 } 1071 identity destination-mac-address { 1072 base ethernet; 1073 description 1074 "Identity for the capability of matching Media Access Control 1075 (MAC) destination address(es) condition capability."; 1076 reference 1077 "IEEE 802.3: IEEE Standard for Ethernet"; 1078 } 1080 identity ether-type { 1081 base ethernet; 1082 description 1083 "Identity for the capability of matching the EtherType of a 1084 packet."; 1085 reference 1086 "IEEE 802.3: IEEE Standard for Ethernet"; 1087 } 1089 identity ip { 1090 base protocol; 1091 description 1092 "Base identity for internet/network layer protocol, 1093 e.g., IPv4, IPv6, and ICMP."; 1094 } 1096 identity ipv4 { 1097 base ip; 1098 description 1099 "Base identity for IPv4 condition capability"; 1100 reference 1101 "RFC 791: Internet Protocol"; 1102 } 1104 identity ipv6 { 1105 base ip; 1106 description 1107 "Base identity for IPv6 condition capabilities"; 1108 reference 1109 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1110 Specification"; 1111 } 1113 identity dscp { 1114 base ipv4; 1115 base ipv6; 1116 description 1117 "Identity for the capability of matching IPv4 annd IPv6 1118 Differentiated Services Codepoint (DSCP) condition"; 1119 reference 1120 "RFC 791: Internet Protocol - Type of Service 1121 RFC 2474: Definition of the Differentiated 1122 Services Field (DS Field) in the IPv4 and 1123 IPv6 Headers 1124 RFC 8200: Internet Protocol, Version 6 (IPv6) 1125 Specification - Traffic Class"; 1126 } 1128 identity length { 1129 base ipv4; 1130 base ipv6; 1131 description 1132 "Identity for the capability of matching IPv4 Total Length header 1133 field or IPv6 Payload Length header field. 1135 IPv4 Total Length is the length of datagram, measured in octets, 1136 including internet header and data. 1138 IPv6 Payload Length is the length of the IPv6 payload, i.e., the 1139 rest of the packet following the IPv6 header, measured in 1140 octets."; 1141 reference 1142 "RFC 791: Internet Protocol - Total Length 1143 RFC 8200: Internet Protocol, Version 6 (IPv6) 1144 Specification - Payload Length"; 1145 } 1147 identity ttl { 1148 base ipv4; 1149 base ipv6; 1150 description 1151 "Identity for the capability of matching IPv4 Time-To-Live (TTL) 1152 or IPv6 Hop Limit."; 1154 reference 1155 "RFC 791: Internet Protocol - Time To Live (TTL) 1156 RFC 8200: Internet Protocol, Version 6 (IPv6) 1157 Specification - Hop Limit"; 1158 } 1160 identity next-header { 1161 base ipv4; 1162 base ipv6; 1163 description 1164 "Identity for the capability of matching IPv4 Protocol Field or 1165 equivalent to IPv6 Next Header."; 1166 reference 1167 "IANA Website: Assigned Internet Protocol Numbers 1168 - Protocol Number for IPv4 1169 RFC 791: Internet Protocol - Protocol 1170 RFC 8200: Internet Protocol, Version 6 (IPv6) 1171 Specification - Next Header"; 1172 } 1174 identity source-address { 1175 base ipv4; 1176 base ipv6; 1177 description 1178 "Identity for the capability of matching IPv4 or IPv6 source 1179 address(es) condition capability."; 1180 reference 1181 "RFC 791: Internet Protocol - Address 1182 RFC 8200: Internet Protocol, Version 6 (IPv6) 1183 Specification - Source Address"; 1184 } 1186 identity destination-address { 1187 base ipv4; 1188 base ipv6; 1189 description 1190 "Identity for the capability of matching IPv4 or IPv6 destination 1191 address(es) condition capability."; 1192 reference 1193 "RFC 791: Internet Protocol - Address 1194 RFC 8200: Internet Protocol, Version 6 (IPv6) 1195 Specification - Destination Address"; 1196 } 1198 identity flow-direction { 1199 base ipv4; 1200 base ipv6; 1201 description 1202 "Identity for flow direction of matching IPv4/IPv6 source 1203 or destination address(es) condition capability where a flow's 1204 direction is either unidirectional or bidirectional"; 1205 reference 1206 "RFC 791: Internet Protocol 1207 RFC 8200: Internet Protocol, Version 6 (IPv6) 1208 Specification"; 1209 } 1211 identity header-length { 1212 base ipv4; 1213 description 1214 "Identity for matching IPv4 header-length 1215 condition capability"; 1216 reference 1217 "RFC 791: Internet Protocol - Header Length"; 1218 } 1220 identity identification { 1221 base ipv4; 1222 description 1223 "Identity for IPv4 identification condition capability. 1224 IPv4 ID field is used for fragmentation and reassembly."; 1225 reference 1226 "RFC 791: Internet Protocol - Identification 1227 RFC 6864: Updated Specification of the IPv4 ID Field - 1228 Fragmentation and Reassembly"; 1229 } 1231 identity fragment-flags { 1232 base ipv4; 1233 description 1234 "Identity for IPv4 fragment flags condition capability"; 1235 reference 1236 "RFC 791: Internet Protocol - Fragmentation Flags"; 1237 } 1239 identity fragment-offset { 1240 base ipv4; 1241 description 1242 "Identity for matching IPv4 fragment offset 1243 condition capability"; 1244 reference 1245 "RFC 791: Internet Protocol - Fragmentation Offset"; 1246 } 1248 identity ipv4-options { 1249 base ipv4; 1250 description 1251 "Identity for IPv4 options condition capability"; 1252 reference 1253 "RFC 791: Internet Protocol - Options"; 1254 } 1256 identity flow-label { 1257 base ipv6; 1258 description 1259 "Identity for matching IPv6 flow label 1260 condition capability"; 1261 reference 1262 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1263 Specification - Flow Label 1264 RFC 6437: IPv6 Flow Label Specification"; 1265 } 1267 identity header-order { 1268 base ipv6; 1269 description 1270 "Identity for IPv6 extension header order condition 1271 capability"; 1272 reference 1273 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1274 Specification - Extension Header Order"; 1275 } 1277 identity hop-by-hop { 1278 base ipv6; 1279 description 1280 "Identity for IPv6 hop by hop options header 1281 condition capability"; 1282 reference 1283 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1285 Specification - Options"; 1286 } 1288 identity routing-header { 1289 base ipv6; 1290 description 1291 "Identity for IPv6 routing header condition 1292 capability"; 1293 reference 1294 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1295 Specification - Routing Header"; 1296 } 1297 identity fragment-header { 1298 base ipv6; 1299 description 1300 "Identity for IPv6 fragment header condition 1301 capability"; 1302 reference 1303 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1304 Specification - Fragment Header"; 1305 } 1307 identity destination-options { 1308 base ipv6; 1309 description 1310 "Identity for IPv6 destination options condition 1311 capability"; 1312 reference 1313 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1314 Specification - Destination Options"; 1315 } 1317 identity icmp { 1318 base protocol; 1319 description 1320 "Base identity for ICMPv4 and ICMPv6 condition capability"; 1321 reference 1322 "RFC 792: Internet Control Message Protocol 1323 RFC 4443: Internet Control Message Protocol (ICMPv6) 1324 for the Internet Protocol Version 6 (IPv6) Specification 1325 - ICMPv6"; 1326 } 1328 identity icmpv4 { 1329 base icmp; 1330 description 1331 "Base identity for ICMPv4 condition capability"; 1332 reference 1333 "RFC 792: Internet Control Message Protocol"; 1334 } 1336 identity icmpv6 { 1337 base icmp; 1338 description 1339 "Base identity for ICMPv6 condition capability"; 1340 reference 1341 "RFC 4443: Internet Control Message Protocol (ICMPv6) 1342 for the Internet Protocol Version 6 (IPv6) Specification 1343 - ICMPv6"; 1344 } 1345 identity type { 1346 base icmpv4; 1347 base icmpv6; 1348 description 1349 "Identity for ICMPv4 and ICMPv6 type condition capability"; 1350 reference 1351 "RFC 792: Internet Control Message Protocol 1352 RFC 4443: Internet Control Message Protocol (ICMPv6) 1353 for the Internet Protocol Version 6 (IPv6) Specification 1354 - ICMPv6"; 1355 } 1357 identity code { 1358 base icmpv4; 1359 base icmpv6; 1360 description 1361 "Identity for ICMPv4 and ICMPv6 code condition capability"; 1362 reference 1363 "RFC 792: Internet Control Message Protocol 1364 RFC 4443: Internet Control Message Protocol (ICMPv6) 1365 for the Internet Protocol Version 6 (IPv6) Specification 1366 - ICMPv6"; 1367 } 1369 identity transport-protocol { 1370 base protocol; 1371 description 1372 "Base identity for Layer 4 protocol condition capabilities, e.g., 1373 TCP, UDP, SCTP, DCCP, and ICMP"; 1374 } 1376 identity tcp { 1377 base transport-protocol; 1378 description 1379 "Base identity for TCP condition capabilities"; 1380 reference 1381 "RFC 793: Transmission Control Protocol 1382 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1383 (TCP) Specification"; 1384 } 1386 identity udp { 1387 base transport-protocol; 1388 description 1389 "Base identity for UDP condition capabilities"; 1390 reference 1391 "RFC 768: User Datagram Protocol"; 1392 } 1393 identity sctp { 1394 base transport-protocol; 1395 description 1396 "Identity for SCTP condition capabilities"; 1397 reference 1398 "RFC 4960: Stream Control Transmission Protocol"; 1399 } 1401 identity dccp { 1402 base transport-protocol; 1403 description 1404 "Identity for DCCP condition capabilities"; 1405 reference 1406 "RFC 4340: Datagram Congestion Control Protocol"; 1407 } 1409 identity source-port-number { 1410 base tcp; 1411 base udp; 1412 base sctp; 1413 base dccp; 1414 description 1415 "Identity for matching TCP, UDP, SCTP, and DCCP source port 1416 number condition capability"; 1417 reference 1418 "RFC 793: Transmission Control Protocol - Port Number 1419 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1420 (TCP) Specification 1421 RFC 768: User Datagram Protocol 1422 RFC 4960: Stream Control Transmission Protocol 1423 RFC 4340: Datagram Congestion Control Protocol"; 1424 } 1426 identity destination-port-number { 1427 base tcp; 1428 base udp; 1429 base sctp; 1430 base dccp; 1431 description 1432 "Identity for matching TCP, UDP, SCTP, and DCCP destination port 1433 number condition capability"; 1434 reference 1435 "RFC 793: Transmission Control Protocol - Port Number 1436 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1437 (TCP) Specification"; 1438 } 1440 identity flags { 1441 base tcp; 1442 description 1443 "Identity for TCP control bits (flags) condition capability"; 1444 reference 1445 "RFC 793: Transmission Control Protocol - Flags 1446 RFC 3168: The Addition of Explicit Congestion Notification 1447 (ECN) to IP - TCP Header Flags 1448 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1449 (TCP) Specification 1450 draft-ietf-tcpm-accurate-ecn: More Accurate ECN Feedback 1451 in TCP"; 1452 } 1454 identity tcp-options { 1455 base tcp; 1456 description 1457 "Identity for TCP options condition capability."; 1458 reference 1459 "RFC 793: Transmission Control Protocol - Options 1460 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1461 (TCP) Specification 1462 RFC 6691: TCP Options and Maximum Segment Size 1463 RFC 7323: TCP Extensions for High Performance"; 1464 } 1466 identity total-length { 1467 base udp; 1468 description 1469 "Identity for matching UDP total-length condition capability. 1470 The UDP total length can be smaller than the IP transport 1471 length for UDP transport layer options."; 1472 reference 1473 "RFC 768: User Datagram Protocol - Total Length 1474 draft-ietf-tsvwg-udp-options: Transport Options for UDP"; 1475 } 1477 identity verification-tag { 1478 base sctp; 1479 description 1480 "Identity for range-match SCTP verification tag condition 1481 capability"; 1482 reference 1483 "RFC 4960: Stream Control Transmission Protocol - Verification 1484 Tag"; 1485 } 1487 identity chunk-type { 1488 base sctp; 1489 description 1490 "Identity for SCTP chunk type condition capability"; 1491 reference 1492 "RFC 4960: Stream Control Transmission Protocol - Chunk Type"; 1493 } 1495 identity service-code { 1496 base dccp; 1497 description 1498 "Identity for DCCP Service Code condition capabilitiy"; 1499 reference 1500 "RFC 4340: Datagram Congestion Control Protocol 1501 RFC 5595: The Datagram Congestion Control Protocol (DCCP) 1502 Service Codes 1503 RFC 6335: Internet Assigned Numbers Authority (IANA) 1504 Procedures for the Management of the Service Name and 1505 Transport Protocol Port Number Registry - Service Code"; 1506 } 1508 identity application-protocol { 1509 base protocol; 1510 description 1511 "Base identity for Application protocol"; 1512 } 1514 identity http { 1515 base application-protocol; 1516 description 1517 "The identity for HTTP protocol."; 1518 reference 1519 "RFC 2616: Hypertext Transfer Protocol (HTTP) 1520 RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1521 Syntax and Routing 1522 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1523 and Content"; 1524 } 1526 identity https { 1527 base application-protocol; 1528 description 1529 "The identity for HTTPS protocol."; 1530 reference 1531 "RFC 2818: HTTP over TLS (HTTPS) 1532 RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1533 Syntax and Routing 1534 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1535 and Content"; 1536 } 1537 identity ftp { 1538 base application-protocol; 1539 description 1540 "The identity for ftp protocol."; 1541 reference 1542 "RFC 959: File Transfer Protocol (FTP)"; 1543 } 1545 identity ssh { 1546 base application-protocol; 1547 description 1548 "The identity for ssh protocol."; 1549 reference 1550 "RFC 4250: The Secure Shell (SSH) Protocol"; 1551 } 1553 identity telnet { 1554 base application-protocol; 1555 description 1556 "The identity for telnet."; 1557 reference 1558 "RFC 854: Telnet Protocol"; 1559 } 1561 identity smtp { 1562 base application-protocol; 1563 description 1564 "The identity for smtp."; 1565 reference 1566 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1567 } 1569 identity sftp { 1570 base application-protocol; 1571 description 1572 "The identity for sftp."; 1573 reference 1574 "RFC 913: Simple File Transfer Protocol (SFTP)"; 1575 } 1577 identity pop3 { 1578 base application-protocol; 1579 description 1580 "The identity for pop3."; 1581 reference 1582 "RFC 1081: Post Office Protocol - Version 3 (POP3)"; 1583 } 1584 identity imap { 1585 base application-protocol; 1586 description 1587 "The identity for Internet Message Access Protocol (IMAP)."; 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"; 1633 } 1635 identity session-log { 1636 base log-action; 1637 description 1638 "Identity for session log-action capability. 1639 Log the received packet based on the session."; 1640 } 1642 identity pass { 1643 base ingress-action; 1644 base egress-action; 1645 base default-action; 1646 description 1647 "Identity for pass action capability. The pass action allows 1648 packet or flow to go through the NSF entering or exiting the 1649 internal network."; 1650 } 1652 identity drop { 1653 base ingress-action; 1654 base egress-action; 1655 base default-action; 1656 description 1657 "Identity for drop action capability. The drop action denies 1658 packet to go through the NSF entering or exiting the internal 1659 network."; 1660 } 1662 identity mirror { 1663 base ingress-action; 1664 base egress-action; 1665 base default-action; 1666 description 1667 "Identity for mirror action capability. The mirror action copies 1668 packet and send it to the monitoring entity while still allow 1669 the packet or flow to go through the NSF."; 1670 } 1672 identity rate-limit { 1673 base ingress-action; 1674 base egress-action; 1675 base default-action; 1676 description 1677 "Identity for rate limiting action capability. The rate limit 1678 action limits the number of packets or flows that can go through 1679 the NSF by dropping packets or flows (randomly or 1680 systematically)."; 1682 } 1684 identity invoke-signaling { 1685 base egress-action; 1686 description 1687 "Identity for invoke signaling action capability"; 1688 } 1690 identity tunnel-encapsulation { 1691 base egress-action; 1692 description 1693 "Identity for tunnel encapsulation action capability"; 1694 } 1696 identity forwarding { 1697 base egress-action; 1698 description 1699 "Identity for forwarding action capability"; 1700 } 1702 identity transformation { 1703 base egress-action; 1704 description 1705 "Identity for transformation action capability"; 1706 } 1708 identity resolution-strategy { 1709 description 1710 "Base identity for resolution strategy capability"; 1711 } 1713 identity fmr { 1714 base resolution-strategy; 1715 description 1716 "Identity for First Matching Rule (FMR) resolution 1717 strategy capability"; 1718 } 1720 identity lmr { 1721 base resolution-strategy; 1722 description 1723 "Identity for Last Matching Rule (LMR) resolution 1724 strategy capability"; 1725 } 1727 identity pmr { 1728 base resolution-strategy; 1729 description 1730 "Identity for Prioritized Matching Rule (PMR) resolution 1731 strategy capability"; 1732 } 1734 identity pmre { 1735 base resolution-strategy; 1736 description 1737 "Identity for Prioritized Matching Rule with Errors (PMRE) 1738 resolution strategy capability"; 1739 } 1741 identity pmrn { 1742 base resolution-strategy; 1743 description 1744 "Identity for Prioritized Matching Rule with No Errors (PMRN) 1745 resolution strategy capability"; 1746 } 1748 identity advanced-nsf { 1749 description 1750 "Base identity for advanced Network Security Function (NSF) 1751 capability."; 1752 } 1754 identity content-security-control { 1755 base advanced-nsf; 1756 description 1757 "Base identity for content security control. Content security 1758 control is an NSF that evaluates a packet's payload such as 1759 Intrusion Prevention System (IPS), URL-Filtering, Antivirus, 1760 and VoIP/VoLTE Filter."; 1761 } 1763 identity attack-mitigation-control { 1764 base advanced-nsf; 1765 description 1766 "Base identity for attack mitigation control. Attack mitigation 1767 control is an NSF that mitigates an attack such as anti-DDoS 1768 or DDoS-mitigator."; 1769 } 1771 identity ips { 1772 base content-security-control; 1773 description 1774 "Base identity for IPS (Intrusion Prevention System) capability 1775 that prevents malicious activity within a network"; 1776 } 1777 identity url-filtering { 1778 base content-security-control; 1779 description 1780 "Base identity for url filtering capability that limits access by 1781 comparing the web traffic's URL with the URLs for web filtering 1782 in a database"; 1783 } 1785 identity anti-virus { 1786 base content-security-control; 1787 description 1788 "Base identity for anti-virus capability to protect the network 1789 by detecting and removing viruses."; 1790 } 1792 identity voip-volte-filtering { 1793 base content-security-control; 1794 description 1795 "Base identity for advanced NSF VoIP/VoLTE Security Service 1796 capability to filter the VoIP/VoLTE packets or flows."; 1797 reference 1798 "RFC 3261: SIP: Session Initiation Protocol"; 1799 } 1801 identity anti-ddos { 1802 base attack-mitigation-control; 1803 description 1804 "Base identity for advanced NSF Anti-DDoS Attack or DDoS Mitigator 1805 capability."; 1806 } 1808 identity packet-rate { 1809 base anti-ddos; 1810 description 1811 "Identity for advanced NSF Anti-DDoS detecting Packet Rate 1812 Capability where a packet rate is defined as the arrival rate of 1813 Packets toward a victim destination node. The NSF with this 1814 capability can detect the incoming packet rate and create an 1815 alert if the rate exceeds the threshold."; 1817 } 1819 identity flow-rate { 1820 base anti-ddos; 1821 description 1822 "Identity for advanced NSF Anti-DDoS detecting Flow Rate 1823 Capability where a flow rate is defined as the arrival rate of 1824 flows towards a victim destination node. The NSF with this 1825 capability can detect the incoming flow rate and create an 1826 alert if the rate exceeds the threshold."; 1827 } 1829 identity byte-rate { 1830 base anti-ddos; 1831 description 1832 "Identity for advanced NSF Anti-DDoS detecting Byte Rate 1833 Capability where a byte rate is defined as the arrival rate of 1834 Bytes toward a victim destination node. The NSF with this 1835 capability can detect the incoming byte rate and create an 1836 alert if the rate exceeds the threshold."; 1837 } 1839 identity signature-set { 1840 base ips; 1841 description 1842 "Identity for the capability of IPS to set the signature. 1843 Signature is a set of rules to detect an intrusive activity."; 1844 reference 1845 "RFC 4766: Intrusion Detection Message Exchange Requirements - 1846 Section 2.2.13"; 1847 } 1849 identity exception-signature { 1850 base ips; 1851 description 1852 "Identity for the capability of IPS to exclude signatures from 1853 detecting the intrusion."; 1854 reference 1855 "RFC 4766: Intrusion Detection Message Exchange Requirements - 1856 Section 2.2.13"; 1857 } 1859 identity detect { 1860 base anti-virus; 1861 description 1862 "Identity for advanced NSF Antivirus capability to detect viruses 1863 using a security profile. The security profile is used to scan 1864 threats, such as virus, malware, and spyware. The NSF should 1865 be able to update the security profile."; 1866 } 1868 identity exception-files { 1869 base anti-virus; 1870 description 1871 "Identity for advanced NSF Antivirus capability to exclude a 1872 certain file type or name from detection."; 1874 } 1876 identity pre-defined { 1877 base url-filtering; 1878 description 1879 "Identity for pre-defined URL Database condition capability. 1880 where URL database is a public database for URL filtering."; 1881 } 1883 identity user-defined { 1884 base url-filtering; 1885 description 1886 "Identity for user-defined URL Database condition capability. 1887 that allows a users manual addition of URLs for URL 1888 filtering."; 1889 } 1891 identity call-id { 1892 base voip-volte-filtering; 1893 description 1894 "Identity for advanced NSF VoIP/VoLTE Call Identifier (ID) 1895 capability."; 1896 } 1898 identity user-agent { 1899 base voip-volte-filtering; 1900 description 1901 "Identity for advanced NSF VoIP/VoLTE User Agent capability."; 1902 } 1904 /* 1905 * Grouping 1906 */ 1908 grouping nsf-capabilities { 1909 description 1910 "Network Security Function (NSF) Capabilities"; 1911 reference 1912 "RFC 8329: Framework for Interface to Network Security 1913 Functions - I2NSF Flow Security Policy Structure."; 1915 leaf-list directional-capabilities { 1916 type identityref { 1917 base directional; 1918 } 1919 description 1920 "The capability of an NSF for handling directional traffic 1921 flow (i.e., unidirectional or bidirectional traffic flow)."; 1923 } 1925 container event-capabilities { 1926 description 1927 "Capabilities of events. 1928 If a network security function has the event capabilities, 1929 the network security function supports rule execution 1930 according to system event and system alarm."; 1932 reference 1933 "RFC 8329: Framework for Interface to Network Security 1934 Functions - Section 7. 1935 draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF 1936 NSF Monitoring YANG Data Model - System Alarm and 1937 System Events."; 1939 leaf-list system-event-capability { 1940 type identityref { 1941 base system-event; 1942 } 1943 description 1944 "System event capabilities"; 1945 } 1947 leaf-list system-alarm-capability { 1948 type identityref { 1949 base system-alarm; 1950 } 1951 description 1952 "System alarm capabilities"; 1953 } 1955 leaf-list time-capabilities { 1956 type identityref { 1957 base time; 1958 } 1959 description 1960 "The capabilities for activating the policy within a specific 1961 time."; 1962 } 1963 } 1965 container condition-capabilities { 1966 description 1967 "Conditions capabilities."; 1968 container generic-nsf-capabilities { 1969 description 1970 "Conditions capabilities. 1972 If a network security function has the condition 1973 capabilities, the network security function 1974 supports rule execution according to conditions of 1975 IPv4, IPv6, TCP, UDP, SCTP, DCCP, ICMP, or ICMPv6."; 1976 reference 1977 "RFC 768: User Datagram Protocol - UDP. 1978 RFC 791: Internet Protocol - IPv4. 1979 RFC 792: Internet Control Message Protocol - ICMP. 1980 RFC 793: Transmission Control Protocol - TCP. 1981 RFC 4443: Internet Control Message Protocol (ICMPv6) 1982 for the Internet Protocol Version 6 (IPv6) Specification 1983 - ICMPv6. 1984 RFC 4960: Stream Control Transmission Protocol - SCTP. 1985 RFC 8200: Internet Protocol, Version 6 (IPv6) 1986 Specification - IPv6. 1987 RFC 8329: Framework for Interface to Network Security 1988 Functions - I2NSF Flow Security Policy Structure."; 1990 leaf-list ethernet-capability { 1991 type identityref { 1992 base ethernet; 1993 } 1994 description 1995 "Media Access Control (MAC) capabilities"; 1996 reference 1997 "IEEE 802.3: IEEE Standard for Ethernet"; 1998 } 2000 leaf-list ipv4-capability { 2001 type identityref { 2002 base ipv4; 2003 } 2004 description 2005 "IPv4 packet capabilities"; 2006 reference 2007 "RFC 791: Internet Protocol"; 2008 } 2010 leaf-list ipv6-capability { 2011 type identityref { 2012 base ipv6; 2013 } 2014 description 2015 "IPv6 packet capabilities"; 2016 reference 2017 "RFC 8200: Internet Protocol, Version 6 (IPv6) 2018 Specification - IPv6"; 2019 } 2020 leaf-list icmpv4-capability { 2021 type identityref { 2022 base icmpv4; 2023 } 2024 description 2025 "ICMPv4 packet capabilities"; 2026 reference 2027 "RFC 792: Internet Control Message Protocol - ICMP"; 2028 } 2030 leaf-list icmpv6-capability { 2031 type identityref { 2032 base icmpv6; 2033 } 2034 description 2035 "ICMPv6 packet capabilities"; 2036 reference 2037 "RFC 4443: Internet Control Message Protocol (ICMPv6) 2038 for the Internet Protocol Version 6 (IPv6) Specification 2039 - ICMPv6"; 2040 } 2042 leaf-list tcp-capability { 2043 type identityref { 2044 base tcp; 2045 } 2046 description 2047 "TCP packet capabilities"; 2048 reference 2049 "RFC 793: Transmission Control Protocol - TCP 2050 draft-ietf-tcpm-rfc793bis-24: Transmission Control 2051 Protocol (TCP) Specification"; 2052 } 2054 leaf-list udp-capability { 2055 type identityref { 2056 base udp; 2057 } 2058 description 2059 "UDP packet capabilities"; 2060 reference 2061 "RFC 768: User Datagram Protocol - UDP"; 2062 } 2064 leaf-list sctp-capability { 2065 type identityref { 2066 base sctp; 2067 } 2068 description 2069 "SCTP packet capabilities"; 2070 reference 2071 "RFC 4960: Stream Control Transmission Protocol - SCTP"; 2072 } 2074 leaf-list dccp-capability { 2075 type identityref { 2076 base dccp; 2077 } 2078 description 2079 "DCCP packet capabilities"; 2080 reference 2081 "RFC 4340: Datagram Congestion Control Protocol - DCCP"; 2082 } 2083 } 2085 container advanced-nsf-capabilities { 2086 description 2087 "Advanced Network Security Function (NSF) capabilities, 2088 such as Anti-DDoS, IPS, and VoIP/VoLTE. 2089 This container contains the leaf-lists of advanced 2090 NSF capabilities"; 2092 leaf-list anti-ddos-capability { 2093 type identityref { 2094 base anti-ddos; 2095 } 2096 description 2097 "Anti-DDoS Attack capabilities"; 2098 } 2100 leaf-list ips-capability { 2101 type identityref { 2102 base ips; 2103 } 2104 description 2105 "IPS capabilities"; 2106 } 2108 leaf-list anti-virus-capability { 2109 type identityref { 2110 base anti-virus; 2111 } 2112 description 2113 "Anti-Virus capabilities"; 2114 } 2115 leaf-list url-capability { 2116 type identityref { 2117 base url-filtering; 2118 } 2119 description 2120 "URL capabilities"; 2121 } 2123 leaf-list voip-volte-filtering-capability { 2124 type identityref { 2125 base voip-volte-filtering; 2126 } 2127 description 2128 "VoIP/VoLTE capabilities"; 2129 } 2130 } 2132 container context-capabilities { 2133 description 2134 "Security context capabilities"; 2135 leaf-list application-filter-capabilities{ 2136 type identityref { 2137 base application-protocol; 2138 } 2139 description 2140 "Context capabilities based on the application protocol"; 2141 } 2143 leaf-list target-capabilities { 2144 type identityref { 2145 base target-device; 2146 } 2147 description 2148 "Context capabilities based on the device attribute that 2149 can identify a device type 2150 (i.e., router, switch, pc, ios, or android)."; 2151 } 2153 leaf-list user-condition-capabilities { 2154 type identityref { 2155 base user-condition; 2156 } 2157 description 2158 "Context capabilities based on user condition, such as 2159 user-id or user-name. The users can collected into a 2160 user-group and identified with group-id or group-name. 2161 An NSF is aware of the IP address of the user provided by 2162 a unified user management system via network. Based on 2163 name-address association, an NSF is able to enforce the 2164 security functions over the given user (or user group)"; 2165 } 2167 leaf-list geography-capabilities { 2168 type identityref { 2169 base geography-location; 2170 } 2171 description 2172 "Context condition capabilities based on the geographical 2173 location of the source or destination"; 2174 } 2175 } 2176 } 2178 container action-capabilities { 2179 description 2180 "Action capabilities. 2181 If a network security function has the action capabilities, 2182 the network security function supports the attendant 2183 actions for policy rules."; 2185 leaf-list ingress-action-capability { 2186 type identityref { 2187 base ingress-action; 2188 } 2189 description 2190 "Ingress-action capabilities"; 2191 } 2193 leaf-list egress-action-capability { 2194 type identityref { 2195 base egress-action; 2196 } 2197 description 2198 "Egress-action capabilities"; 2199 } 2201 leaf-list log-action-capability { 2202 type identityref { 2203 base log-action; 2204 } 2205 description 2206 "Log-action capabilities"; 2207 } 2208 } 2210 leaf-list resolution-strategy-capabilities { 2211 type identityref { 2212 base resolution-strategy; 2213 } 2214 description 2215 "Resolution strategy capabilities. 2216 The resolution strategies can be used to specify how 2217 to resolve conflicts that occur between the actions 2218 of the same or different policy rules that are matched 2219 for the same packet and by particular NSF."; 2220 } 2222 leaf-list default-action-capabilities { 2223 type identityref { 2224 base default-action; 2225 } 2226 description 2227 "Default action capabilities. 2228 A default action is used to execute I2NSF policy rules 2229 when no rule matches a packet. The default action is 2230 defined as pass, drop, rate-limit, or mirror."; 2231 } 2232 } 2234 /* 2235 * Data nodes 2236 */ 2238 list nsf { 2239 key "nsf-name"; 2240 description 2241 "The list of Network Security Functions (NSFs)"; 2242 leaf nsf-name { 2243 type string; 2244 mandatory true; 2245 description 2246 "The name of Network Security Function (NSF)"; 2247 } 2248 uses nsf-capabilities; 2249 } 2250 } 2251 2253 Figure 3: YANG Data Module of I2NSF Capability 2255 7. IANA Considerations 2257 This document requests IANA to register the following URI in the 2258 "IETF XML Registry" [RFC3688]: 2260 ID: yang:ietf-i2nsf-capability 2261 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2262 Registrant Contact: The IESG. 2263 XML: N/A; the requested URI is an XML namespace. 2264 Filename: [ TBD-at-Registration ] 2265 Reference: [ RFC-to-be ] 2267 This document requests IANA to register the following YANG module in 2268 the "YANG Module Names" registry [RFC7950][RFC8525]: 2270 Name: ietf-i2nsf-capability 2271 Maintained by IANA? N 2272 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2273 Prefix: nsfcap 2274 Module: 2275 Reference: [ RFC-to-be ] 2277 8. Privacy Considerations 2279 This YANG module specifies the capabilities for NSFs. Some of the 2280 capabilities in this document MAY require highly sensitive private 2281 data to operate properly. The usage of such capability MUST be 2282 reported to the users and permitted before using the private 2283 information related to the capability. Using any of the capabilities 2284 that require private data MUST preserve the privacy by preventing any 2285 leakage or unauthorized disclosure of the private data. 2287 In regards to the privacy data used, the security for accessibility 2288 of the data should be tightly secured and monitored. The Security 2289 Considerations are discussed in Section 9. 2291 9. Security Considerations 2293 The YANG module specified in this document defines a data schema 2294 designed to be accessed through network management protocols such as 2295 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest layer of NETCONF 2296 protocol layers MUST use Secure Shell (SSH) [RFC4254][RFC6242] as a 2297 secure transport layer. The lowest layer of RESTCONF protocol layers 2298 MUST use HTTP over Transport Layer Security (TLS), that is, HTTPS 2299 [RFC7230][RFC8446] as a secure transport layer. 2301 The Network Configuration Access Control Model (NACM) [RFC8341] 2302 provides a means of restricting access to specific NETCONF or 2303 RESTCONF users to a preconfigured subset of all available NETCONF or 2304 RESTCONF protocol operations and contents. Thus, NACM SHOULD be used 2305 to restrict the NSF registration from unauthorized users. 2307 There are a number of data nodes defined in this YANG module that are 2308 writable, creatable, and deletable (i.e., config true, which is the 2309 default). These data nodes may be considered sensitive or vulnerable 2310 in some network environments. Write operations to these data nodes 2311 could have a negative effect on network and security operations. 2312 These data nodes are collected into a single list node. This list 2313 node is defined by list nsf with the following sensitivity/ 2314 vulnerability: 2316 * list nsf: An attacker could alter the security capabilities 2317 associated with an NSF by disabling or enabling the functionality 2318 of the security capabilities of the NSF. 2320 Some of the readable data nodes in this YANG module may be considered 2321 sensitive or vulnerable in some network environments. It is thus 2322 important to control read access (e.g., via get, get-config, or 2323 notification) to these data nodes. These are the subtrees and data 2324 nodes with their sensitivity/vulnerability: 2326 * list nsf: The leak of this node to an attacker could reveal the 2327 specific configuration of security controls to an attacker. An 2328 attacker can craft an attack path that avoids observation or 2329 mitigations; one may reveal topology information to inform 2330 additional targets or enable lateral movement; one enables the 2331 construction of an attack path that avoids observation or 2332 mitigations; one provides an indication that the operator has 2333 discovered the attack. 2335 Some of the features that this document defines capability indicators 2336 for are highly sensitive and/or privileged operations that inherently 2337 require access to individuals' private data. These are subtrees and 2338 data nodes that are considered privacy sensitive: 2340 * voip-volte-filtering-capability: The NSF that is able to filter 2341 VoIP/VoLTE calls might identify certain individual identification. 2343 * user-condition-capabilities: The capability uses a set of IP 2344 addresses mapped to users. 2346 * geography-capabilities: The IP address used in this capability can 2347 identify a user's geographical location. 2349 It is noted that some private information is made accessible in this 2350 manner. Thus, the nodes/entities given access to this data MUST be 2351 tightly secured, monitored, and audited to prevent leakage or other 2352 unauthorized disclosure of private data. Refer to [RFC6973] for the 2353 description of privacy aspects that protocol designers (including 2354 YANG data model designers) should consider along with regular 2355 security and privacy analysis. 2357 10. References 2359 10.1. Normative References 2361 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2362 DOI 10.17487/RFC0768, August 1980, 2363 . 2365 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2366 DOI 10.17487/RFC0791, September 1981, 2367 . 2369 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2370 RFC 792, DOI 10.17487/RFC0792, September 1981, 2371 . 2373 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2374 RFC 793, DOI 10.17487/RFC0793, September 1981, 2375 . 2377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2378 Requirement Levels", BCP 14, RFC 2119, 2379 DOI 10.17487/RFC2119, March 1997, 2380 . 2382 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2383 "Definition of the Differentiated Services Field (DS 2384 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2385 DOI 10.17487/RFC2474, December 1998, 2386 . 2388 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2389 of Explicit Congestion Notification (ECN) to IP", 2390 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2391 . 2393 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2394 A., Peterson, J., Sparks, R., Handley, M., and E. 2395 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2396 DOI 10.17487/RFC3261, June 2002, 2397 . 2399 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 2400 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 2401 . 2403 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2404 DOI 10.17487/RFC3688, January 2004, 2405 . 2407 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2408 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 2409 January 2006, . 2411 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2412 Congestion Control Protocol (DCCP)", RFC 4340, 2413 DOI 10.17487/RFC4340, March 2006, 2414 . 2416 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2417 Control Message Protocol (ICMPv6) for the Internet 2418 Protocol Version 6 (IPv6) Specification", STD 89, 2419 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2420 . 2422 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2423 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2424 . 2426 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 2427 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 2428 September 2009, . 2430 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2431 the Network Configuration Protocol (NETCONF)", RFC 6020, 2432 DOI 10.17487/RFC6020, October 2010, 2433 . 2435 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2436 and A. Bierman, Ed., "Network Configuration Protocol 2437 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2438 . 2440 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2441 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2442 . 2444 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2445 Cheshire, "Internet Assigned Numbers Authority (IANA) 2446 Procedures for the Management of the Service Name and 2447 Transport Protocol Port Number Registry", BCP 165, 2448 RFC 6335, DOI 10.17487/RFC6335, August 2011, 2449 . 2451 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2452 "IPv6 Flow Label Specification", RFC 6437, 2453 DOI 10.17487/RFC6437, November 2011, 2454 . 2456 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2457 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2458 . 2460 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2461 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2462 . 2464 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2465 Protocol (HTTP/1.1): Message Syntax and Routing", 2466 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2467 . 2469 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2470 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2471 DOI 10.17487/RFC7231, June 2014, 2472 . 2474 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2475 Kivinen, "Internet Key Exchange Protocol Version 2 2476 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2477 2014, . 2479 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 2480 Scheffenegger, Ed., "TCP Extensions for High Performance", 2481 RFC 7323, DOI 10.17487/RFC7323, September 2014, 2482 . 2484 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2485 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2486 . 2488 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2489 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2490 . 2492 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2493 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2494 May 2017, . 2496 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2497 (IPv6) Specification", STD 86, RFC 8200, 2498 DOI 10.17487/RFC8200, July 2017, 2499 . 2501 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2502 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2503 . 2505 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2506 Access Control Model", STD 91, RFC 8341, 2507 DOI 10.17487/RFC8341, March 2018, 2508 . 2510 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2511 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2512 DOI 10.17487/RFC8407, October 2018, 2513 . 2515 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2516 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2517 . 2519 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 2520 and R. Wilton, "YANG Library", RFC 8525, 2521 DOI 10.17487/RFC8525, March 2019, 2522 . 2524 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 2525 "YANG Data Model for Network Access Control Lists (ACLs)", 2526 RFC 8519, DOI 10.17487/RFC8519, March 2019, 2527 . 2529 [I-D.ietf-tcpm-accurate-ecn] 2530 Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More 2531 Accurate ECN Feedback in TCP", Work in Progress, Internet- 2532 Draft, draft-ietf-tcpm-accurate-ecn-15, 12 July 2021, 2533 . 2536 [I-D.ietf-tsvwg-udp-options] 2537 Touch, J., "Transport Options for UDP", Work in Progress, 2538 Internet-Draft, draft-ietf-tsvwg-udp-options-13, 19 June 2539 2021, . 2542 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 2543 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 2544 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 2545 Model", Work in Progress, Internet-Draft, draft-ietf- 2546 i2nsf-nsf-monitoring-data-model-08, 29 April 2021, 2547 . 2550 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 2551 Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin, 2552 "I2NSF Network Security Function-Facing Interface YANG 2553 Data Model", Work in Progress, Internet-Draft, draft-ietf- 2554 i2nsf-nsf-facing-interface-dm-12, 8 March 2021, 2555 . 2558 [I-D.ietf-i2nsf-registration-interface-dm] 2559 Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Park, 2560 "I2NSF Registration Interface YANG Data Model", Work in 2561 Progress, Internet-Draft, draft-ietf-i2nsf-registration- 2562 interface-dm-10, 21 February 2021, 2563 . 2566 10.2. Informative References 2568 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2569 RFC 6691, DOI 10.17487/RFC6691, July 2012, 2570 . 2572 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2573 Morris, J., Hansen, M., and R. Smith, "Privacy 2574 Considerations for Internet Protocols", RFC 6973, 2575 DOI 10.17487/RFC6973, July 2013, 2576 . 2578 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2579 and J. Jeong, "Interface to Network Security Functions 2580 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2581 DOI 10.17487/RFC8192, July 2017, 2582 . 2584 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2585 Kumar, "Framework for Interface to Network Security 2586 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2587 . 2589 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 2590 Kumari, "A Format for Self-Published IP Geolocation 2591 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 2592 . 2594 [I-D.ietf-tcpm-rfc793bis] 2595 Eddy, W. M., "Transmission Control Protocol (TCP) 2596 Specification", Work in Progress, Internet-Draft, draft- 2597 ietf-tcpm-rfc793bis-24, 12 July 2021, 2598 . 2601 [IANA-Protocol-Numbers] 2602 "Assigned Internet Protocol Numbers", Available: 2603 https://www.iana.org/assignments/protocol- 2604 numbers/protocol-numbers.xhtml, September 2020. 2606 [Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and 2607 management of firewall policies", 2004. 2609 [Galitsky] Galitsky, B. and R. Pampapathi, "Can many agents answer 2610 questions better than one", First 2611 Monday http://dx.doi.org/10.5210/fm.v10i1.1204, 2005. 2613 [Hirschman] 2614 Hirschman, L. and R. Gaizauskas, "Natural Language 2615 Question Answering: The View from Here", Natural Language 2616 Engineering 7:4, pgs 275-300, Cambridge University Press , 2617 November 2001. 2619 [Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns", 2620 ISBN 0-32-120068-3 , 2003. 2622 [Martin] Martin, R.C., "Agile Software Development, Principles, 2623 Patterns, and Practices", Prentice-Hall , ISBN: 2624 0-13-597444-5 , 2002. 2626 [OODMP] "http://www.oodesign.com/mediator-pattern.html". 2628 [OODOP] "http://www.oodesign.com/mediator-pattern.html". 2630 [OODSRP] "http://www.oodesign.com/mediator-pattern.html". 2632 Appendix A. Configuration Examples 2634 This section shows configuration examples of "ietf-i2nsf-capability" 2635 module for capabilities registration of general firewall. 2637 A.1. Example 1: Registration for the Capabilities of a General Firewall 2639 This section shows a configuration example for the capabilities 2640 registration of a general firewall in either an IPv4 network or an 2641 IPv6 network. 2643 2644 general_firewall 2645 2646 2647 next-header 2648 flow-direction 2649 source-address 2650 destination-address 2651 source-port-number 2652 destination-port-number 2653 source-port-num 2654 destination-port-num 2655 2656 2657 2658 pass 2659 drop 2660 mirror 2661 pass 2662 drop 2663 mirror 2664 2665 2667 Figure 4: Configuration XML for the Capabilities Registration of 2668 a General Firewall in an IPv4 Network 2670 Figure 4 shows the configuration XML for the capabilities 2671 registration of a general firewall as an NSF in an IPv4 network. Its 2672 capabilities are as follows. 2674 1. The name of the NSF is general_firewall. 2676 2. The NSF can inspect the IPv4 protocol header field, flow 2677 direction, source address(es), and destination address(es) 2679 3. The NSF can inspect the port number(s) and flow direction for the 2680 transport layer protocol, i.e., TCP and UDP. 2682 4. The NSF can control whether the packets are allowed to pass, 2683 drop, or mirror. 2685 2686 general_firewall 2687 2688 2689 next-header 2690 flow-direction 2691 source-address 2692 destination-address 2693 source-port-number 2694 destination-port-number 2695 source-port-num 2696 destination-port-num 2697 2698 2699 2700 pass 2701 drop 2702 mirror 2703 pass 2704 drop 2705 mirror 2706 2707 2709 Figure 5: Configuration XML for the Capabilities Registration of 2710 a General Firewall in an IPv6 Network 2712 In addition, Figure 5 shows the configuration XML for the 2713 capabilities registration of a general firewall as an NSF in an IPv6 2714 network. Its capabilities are as follows. 2716 1. The name of the NSF is general_firewall. 2718 2. The NSF can inspect IPv6 next header, flow direction, source 2719 address(es), and destination address(es) 2721 3. The NSF can inspect the port number(s) and flow direction for the 2722 transport layer protocol, i.e., TCP and UDP. 2724 4. The NSF can control whether the packets are allowed to pass, 2725 drop, or mirror. 2727 A.2. Example 2: Registration for the Capabilities of a Time-based 2728 Firewall 2730 This section shows a configuration example for the capabilities 2731 registration of a time-based firewall in either an IPv4 network or an 2732 IPv6 network. 2734 2735 time_based_firewall 2736 2737 absolute-time 2738 periodic-time 2739 2740 2741 2742 ipv4-protocol 2743 flow-direction 2744 source-address 2745 destination-address 2746 2747 2748 2749 pass 2750 drop 2751 mirror 2752 pass 2753 drop 2754 mirror 2755 2756 2758 Figure 6: Configuration XML for the Capabilities Registration of 2759 a Time-based Firewall in an IPv4 Network 2761 Figure 6 shows the configuration XML for the capabilities 2762 registration of a time-based firewall as an NSF in an IPv4 network. 2763 Its capabilities are as follows. 2765 1. The name of the NSF is time_based_firewall. 2767 2. The NSF can execute the security policy rule according to 2768 absolute time and periodic time. 2770 3. The NSF can inspect the IPv4 protocol header field, flow 2771 direction, source address(es), and destination address(es). 2773 4. The NSF can control whether the packets are allowed to pass, 2774 drop, or mirror. 2776 2777 time_based_firewall 2778 2779 absolute-time 2780 periodic-time 2781 2782 2783 2784 next-header 2785 flow-direction 2786 source-address 2787 destination-address 2788 2789 2790 2791 pass 2792 drop 2793 mirror 2794 pass 2795 drop 2796 mirror 2797 2798 2800 Figure 7: Configuration XML for the Capabilities Registration of 2801 a Time-based Firewall in an IPv6 Network 2803 In addition, Figure 7 shows the configuration XML for the 2804 capabilities registration of a time-based firewall as an NSF in an 2805 IPv6 network. Its capabilities are as follows. 2807 1. The name of the NSF is time_based_firewall. 2809 2. The NSF can execute the security policy rule according to 2810 absolute time and periodic time. 2812 3. The NSF can inspect the IPv6 protocol header field, flow 2813 direction, source address(es), and destination address(es). 2815 4. The NSF can control whether the packets are allowed to pass, 2816 drop, or mirror. 2818 A.3. Example 3: Registration for the Capabilities of a Web Filter 2820 This section shows a configuration example for the capabilities 2821 registration of a web filter. 2823 2824 web_filter 2825 2826 2827 user-defined 2828 2829 2830 2831 pass 2832 drop 2833 mirror 2834 pass 2835 drop 2836 mirror 2837 2838 2840 Figure 8: Configuration XML for the Capabilities Registration of 2841 a Web Filter 2843 Figure 8 shows the configuration XML for the capabilities 2844 registration of a web filter as an NSF. Its capabilities are as 2845 follows. 2847 1. The name of the NSF is web_filter. 2849 2. The NSF can inspect a URL matched from a user-defined URL. User 2850 can specify their own URL. 2852 3. The NSF can control whether the packets are allowed to pass, 2853 drop, or mirror. 2855 A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE 2856 Filter 2858 This section shows a configuration example for the capabilities 2859 registration of a VoIP/VoLTE filter. 2861 2862 voip_volte_filter 2863 2864 2865 call-id 2866 2867 2868 2869 pass 2870 drop 2871 mirror 2872 pass 2873 drop 2874 mirror 2875 2876 2878 Figure 9: Configuration XML for the Capabilities Registration of 2879 a VoIP/VoLTE Filter 2881 Figure 9 shows the configuration XML for the capabilities 2882 registration of a VoIP/VoLTE filter as an NSF. Its capabilities are 2883 as follows. 2885 1. The name of the NSF is voip_volte_filter. 2887 2. The NSF can inspect a voice call id for VoIP/VoLTE packets. 2889 3. The NSF can control whether the packets are allowed to pass, 2890 drop, or mirror. 2892 A.5. Example 5: Registration for the Capabilities of a HTTP and HTTPS 2893 Flood Mitigator 2895 This section shows a configuration example for the capabilities 2896 registration of a HTTP and HTTPS flood mitigator. 2898 2899 DDoS_mitigator 2900 2901 2902 packet-rate 2903 byte-rate 2904 flow-rate 2905 2906 2907 2908 pass 2909 drop 2910 mirror 2911 pass 2912 drop 2913 mirror 2914 2915 2917 Figure 10: Configuration XML for the Capabilities Registration of 2918 a HTTP and HTTPS Flood Mitigator 2920 Figure 10 shows the configuration XML for the capabilities 2921 registration of a HTTP and HTTPS flood mitigator as an NSF. Its 2922 capabilities are as follows. 2924 1. The name of the NSF is DDoS_mitigator. 2926 2. The NSF can detect the amount of packet, flow, and byte rate in 2927 the network for potential DDoS Attack. 2929 3. The NSF can control whether the packets are allowed to pass, 2930 drop, or mirror. 2932 Appendix B. Acknowledgments 2934 This work was supported by Institute of Information & Communications 2935 Technology Planning & Evaluation (IITP) grant funded by the Korea 2936 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 2937 Security Intelligence Technology Development for the Customized 2938 Security Service Provisioning). This work was supported in part by 2939 the IITP grant funded by the MSIT (2020-0-00395, Standard Development 2940 of Blockchain based Network Management Automation Technology). 2942 Appendix C. Contributors 2944 This document is made by the group effort of I2NSF working group. 2945 Many people actively contributed to this document, such as Acee 2946 Lindem, Roman Danyliw, and Tom Petch. The authors sincerely 2947 appreciate their contributions. 2949 The following are co-authors of this document: 2951 Patrick Lingga Department of Electrical and Computer Engineering 2952 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 2953 16419 Republic of Korea EMail: patricklink@skku.edu 2955 Liang Xia Huawei 101 Software Avenue Nanjing, Jiangsu 210012 China 2956 EMail: Frank.Xialiang@huawei.com 2958 Cataldo Basile Politecnico di Torino Corso Duca degli Abruzzi, 34 2959 Torino, 10129 Italy EMail: cataldo.basile@polito.it 2961 John Strassner Huawei 2330 Central Expressway Santa Clara, CA 95050 2962 USA EMail: John.sc.Strassner@huawei.com 2964 Diego R. Lopez Telefonica I+D Zurbaran, 12 Madrid, 28010 Spain 2965 Email: diego.r.lopez@telefonica.com 2967 Hyoungshick Kim Department of Computer Science and Engineering 2968 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 2969 16419 Republic of Korea EMail: hyoung@skku.edu 2971 Daeyoung Hyun Department of Computer Science and Engineering 2972 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 2973 16419 Republic of Korea EMail: dyhyun@skku.edu 2975 Dongjin Hong Department of Electronic, Electrical and Computer 2976 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 2977 Gyeonggi-do 16419 Republic of Korea EMail: dong.jin@skku.edu 2979 Jung-Soo Park Electronics and Telecommunications Research Institute 2980 218 Gajeong-Ro, Yuseong-Gu Daejeon, 34129 Republic of Korea EMail: 2981 pjs@etri.re.kr 2983 Tae-Jin Ahn Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 2984 Republic of Korea EMail: taejin.ahn@kt.com 2986 Se-Hui Lee Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 2987 Republic of Korea EMail: sehuilee@kt.com 2989 Authors' Addresses 2991 Susan Hares (editor) 2992 Huawei 2993 7453 Hickory Hill 2994 Saline, MI 48176 2995 United States of America 2997 Phone: +1-734-604-0332 2998 Email: shares@ndzh.com 3000 Jaehoon (Paul) Jeong (editor) 3001 Department of Computer Science and Engineering 3002 Sungkyunkwan University 3003 2066 Seobu-Ro, Jangan-Gu 3004 Suwon 3005 Gyeonggi-Do 3006 16419 3007 Republic of Korea 3009 Phone: +82 31 299 4957 3010 Email: pauljeong@skku.edu 3011 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3013 Jinyong (Tim) Kim 3014 Department of Electronic, Electrical and Computer Engineering 3015 Sungkyunkwan University 3016 2066 Seobu-Ro, Jangan-Gu 3017 Suwon 3018 Gyeonggi-Do 3019 16419 3020 Republic of Korea 3022 Phone: +82 10 8273 0930 3023 Email: timkim@skku.edu 3025 Robert Moskowitz 3026 HTT Consulting 3027 Oak Park, MI 3028 United States of America 3030 Phone: +1-248-968-9809 3031 Email: rgm@htt-consult.com 3032 Qiushi Lin 3033 Huawei 3034 Huawei Industrial Base 3035 Shenzhen 3036 Guangdong 518129, 3037 China 3039 Email: linqiushi@huawei.com