idnits 2.17.1 draft-ietf-i2nsf-capability-data-model-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 September 2021) is 947 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7296' is defined on line 2519, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Downref: Normative reference to an Informational RFC: RFC 4766 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-15 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-13 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-09 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-13 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-11 -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-rfc793bis-25 Summary: 9 errors (**), 0 flaws (~~), 9 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: 19 March 2022 J. Kim 6 Sungkyunkwan University 7 R. Moskowitz 8 HTT Consulting 9 Q. Lin 10 Huawei 11 15 September 2021 13 I2NSF Capability YANG Data Model 14 draft-ietf-i2nsf-capability-data-model-18 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 19 March 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Information Model of I2NSF NSF Capability . . . . . . . . . . 4 59 3.1. Design Principles and ECA Policy Model . . . . . . . . . 5 60 3.2. Conflict, Resolution Strategy and Default Action . . . . 8 61 4. Overview of YANG Data Model . . . . . . . . . . . . . . . . . 10 62 5. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12 63 5.1. Network Security Function (NSF) Capabilities . . . . . . 12 64 6. YANG Data Model of I2NSF NSF Capability . . . . . . . . . . . 15 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 66 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 50 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 51 70 10.2. Informative References . . . . . . . . . . . . . . . . . 56 71 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 57 72 A.1. Example 1: Registration for the Capabilities of a General 73 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 58 74 A.2. Example 2: Registration for the Capabilities of a 75 Time-based Firewall . . . . . . . . . . . . . . . . . . . 59 76 A.3. Example 3: Registration for the Capabilities of a Web 77 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 61 78 A.4. Example 4: Registration for the Capabilities of a VoIP/ 79 VoLTE Filter . . . . . . . . . . . . . . . . . . . . . . 62 80 A.5. Example 5: Registration for the Capabilities of a HTTP and 81 HTTPS Flood Mitigator . . . . . . . . . . . . . . . . . . 63 82 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 64 83 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 65 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 86 1. Introduction 88 As the industry becomes more sophisticated and network devices (e.g., 89 Internet-of-Things (IoT) devices, autonomous vehicles, and 90 smartphones using Voice over IP (VoIP) and Voice over LTE (VoLTE)) 91 require advanced security protection in various scenarios, security 92 service providers have a lot of problems described in [RFC8192] to 93 provide such network devices with efficient and reliable security 94 services in network infrastructure. To resolve these problems, this 95 document specifies the information and data models of the 96 capabilities of Network Security Functions (NSFs) in a framework of 97 the Interface to Network Security Functions (I2NSF) [RFC8329]. 99 NSFs produced by multiple security vendors provide various security 100 capabilities to customers. Multiple NSFs can be combined together to 101 provide security services over the given network traffic, regardless 102 of whether the NSFs are implemented as physical or virtual functions. 103 Security Capabilities describe the functions that Network Security 104 Functions (NSFs) can provide for security policy enforcement. 105 Security Capabilities are independent of the actual security policy 106 that will implement the functionality of the NSF. 108 Every NSF SHOULD be described with the set of capabilities it offers. 109 Security Capabilities enable security functionality to be described 110 in a vendor-neutral manner. Security Capabilities are a market 111 enabler, providing a way to define customized security protection by 112 unambiguously describing the security features offered by a given 113 NSF. Note that this YANG data model 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 ethernet-capability* identityref 543 | | +--rw ipv4-capability* identityref 544 | | +--rw ipv6-capability* identityref 545 | | +--rw icmpv4-capability* identityref 546 | | +--rw icmpv6-capability* identityref 547 | | +--rw tcp-capability* identityref 548 | | +--rw udp-capability* identityref 549 | | +--rw sctp-capability* identityref 550 | | +--rw dccp-capability* identityref 551 | +--rw advanced-nsf-capabilities 552 | | +--rw anti-ddos-capability* identityref 553 | | +--rw ips-capability* identityref 554 | | +--rw anti-virus-capability* identityref 555 | | +--rw url-capability* identityref 556 | | +--rw voip-volte-filtering-capability* identityref 557 | +--rw context-capabilities 558 | +--rw application-filter-capabilities* identityref 559 | +--rw target-capabilities* identityref 560 | +--rw user-condition-capabilities* identityref 561 | +--rw geography-capabilities* identityref 562 +--rw action-capabilities 563 | +--rw ingress-action-capability* identityref 564 | +--rw egress-action-capability* identityref 565 | +--rw log-action-capability* identityref 566 +--rw resolution-strategy-capabilities* identityref 567 +--rw default-action-capabilities* identityref 569 Figure 2: YANG Tree Diagram of Capabilities of Network Security 570 Functions 572 The data model in this document provides identities for the 573 capabilities of NSFs. Every identity in the data model represents 574 the capability of an NSF. Each identity is explained in the 575 description of the identity. 577 Event capabilities are used to specify the capabilities that describe 578 an event that would trigger the evaluation of the condition clause of 579 the I2NSF Policy Rule. The defined event capabilities are system 580 event, system alarm, and time. Time capabilities are used to specify 581 the capabilities which describe when to execute the I2NSF policy 582 rule. The time capabilities are defined in terms of absolute time 583 and periodic time. The absolute time means the exact time to start 584 or end. The periodic time means repeated time like day, week, month, 585 or year. 587 Condition capabilities are used to specify capabilities of a set of 588 attributes, features, and/or values that are to be compared with a 589 set of known attributes, features, and/or values in order to 590 determine whether a set of actions needs to be executed or not so 591 that an imperative I2NSF policy rule can be executed. In this 592 document, two kinds of condition capabilities are used to classify 593 different capabilities of NSFs such as generic-nsf-capabilities and 594 advanced-nsf-capabilities. First, the generic-nsf-capabilities 595 define NSFs that operate on packet header for layer 2 (i.e., Ethernet 596 capability), layer 3 (i.e., IPv4 capability, IPv6 capability, ICMPv4 597 capability, and ICMPv6 capability.), and layer 4 (i.e., TCP 598 capability, UDP capability, SCTP capability, and DCCP capability). 599 Second, the advanced-nsf-capabilities define NSFs that operate on 600 features different from the generic-nsf-capabilities, e.g., the 601 payload, cross flow state, application layer, traffic statistics, 602 network behavior, etc. This document defines the advanced-nsf into 603 two categories such as content-security-control and attack- 604 mitigation-control. 606 * Content security control is an NSF that evaluates the payload of a 607 packet, such as Intrusion Prevention System (IPS), URL-Filtering, 608 Antivirus, and VoIP/VoLTE Filter. 610 * Attack mitigation control is an NSF that mitigates an attack such 611 as anti-DDoS (DDoS-mitigator). 613 The advanced-nsf can be extended with other types of NSFs. This 614 document only provides five advanced-nsf capabilities, i.e., IPS 615 capability, URL-Filtering capability, Antivirus capability, VoIP/ 616 VoLTE Filter capability, and Anti-DDoS capability. Note that VoIP 617 and VoLTE are merged into a single capability in this document 618 because VoIP and VoLTE use the Session Initiation Protocol (SIP) 619 [RFC3261] for a call setup. See Section 3.1 for more information 620 about the condition in the ECA policy model. 622 The context capabilities provide extra information for the condition. 623 The given context conditions are application filter, target, user 624 condition, and geography location. The application filter capability 625 is capability in matching the packet based on the application 626 protocol, such as HTTP, HTTPS, FTP, etc. The target capability is 627 capability in matching the type of the target devices, such as PC, 628 IoT, Network Infrastructure devices, etc. The user condition is 629 capability in matching the users of the network by mapping each user 630 ID to an IP address. Users can be combined into one group. The 631 geography location capability is capability in matching the 632 geographical location of a source or destination of a packet. 634 Action capabilities are used to specify the capabilities that 635 describe the control and monitoring aspects of flow-based NSFs when 636 the event and condition clauses are satisfied. The action 637 capabilities are defined as ingress-action capability, egress-action 638 capability, and log-action capability. See Section 3.1 for more 639 information about the action in the ECA policy model. Also, see 640 Section 7.2 (NSF-Facing Flow Security Policy Structure) in [RFC8329] 641 for more information about the ingress and egress actions. In 642 addition, see Section 9.1 (Flow-Based NSF Capability 643 Characterization) in [RFC8329] and Section 7.5 (NSF Logs) in 644 [I-D.ietf-i2nsf-nsf-monitoring-data-model] for more information about 645 logging at NSFs. 647 Resolution strategy capabilities are used to specify the capabilities 648 that describe conflicts that occur between the actions of the same or 649 different policy rules that are matched and contained in this 650 particular NSF. The resolution strategy capabilities are defined as 651 First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized 652 Matching Rule (PMR), Prioritized Matching Rule with Errors (PMRE), 653 and Prioritized Matching Rule with No Errors (PMRN). See Section 3.2 654 for more information about the resolution strategy. 656 Default action capabilities are used to specify the capabilities that 657 describe how to execute I2NSF policy rules when no rule matches a 658 packet. The default action capabilities are defined as pass, drop, 659 rate-limit, and mirror. See Section 3.2 for more information about 660 the default action. 662 6. YANG Data Model of I2NSF NSF Capability 664 This section introduces a YANG module for NSFs' capabilities, as 665 defined in the Section 3. 667 It makes references to 669 * [RFC0768] 671 * [RFC0791] 672 * [RFC0792] 674 * [RFC0793] 676 * [RFC0854] 678 * [RFC0959] 680 * [RFC1939] 682 * [RFC2474] 684 * [RFC2616] 686 * [RFC2818] 688 * [RFC3168] 690 * [RFC3261] 692 * [RFC3501] 694 * [RFC4340] 696 * [RFC4443] 698 * [RFC4766] 700 * [RFC4960] 702 * [RFC5101] 704 * [RFC5321] 706 * [RFC5595] 708 * [RFC6335] 710 * [RFC6437] 712 * [RFC6691] 714 * [RFC6864] 716 * [RFC7230] 718 * [RFC7231] 719 * [RFC7323] 721 * [RFC8200] 723 * [RFC8329] 725 * [RFC8805] 727 * [IEEE802.3-2018] 729 * [IANA-Protocol-Numbers] 731 * [I-D.ietf-tcpm-rfc793bis] 733 * [I-D.ietf-tcpm-accurate-ecn] 735 * [I-D.ietf-tsvwg-udp-options] 737 * [I-D.ietf-i2nsf-nsf-monitoring-data-model] 739 file "ietf-i2nsf-capability@2021-09-15.yang" 740 module ietf-i2nsf-capability { 741 yang-version 1.1; 742 namespace 743 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; 744 prefix 745 nsfcap; 747 organization 748 "IETF I2NSF (Interface to Network Security Functions) 749 Working Group"; 751 contact 752 "WG Web: 753 WG List: 755 Editor: Jaehoon Paul Jeong 756 758 Editor: Jinyong Tim Kim 759 761 Editor: Patrick Lingga 762 764 Editor: Susan Hares 765 "; 767 description 768 "This module is a YANG module for I2NSF Network Security 769 Functions (NSFs)'s Capabilities. 771 Copyright (c) 2021 IETF Trust and the persons identified as 772 authors of the code. All rights reserved. 774 Redistribution and use in source and binary forms, with or 775 without modification, is permitted pursuant to, and subject to 776 the license terms contained in, the Simplified BSD License set 777 forth in Section 4.c of the IETF Trust's Legal Provisions 778 Relating to IETF Documents 779 (https://trustee.ietf.org/license-info). 781 This version of this YANG module is part of RFC XXXX 782 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 783 for full legal notices."; 785 // RFC Ed.: replace XXXX with an actual RFC number and remove 786 // this note. 788 revision "2021-09-15"{ 789 description "Initial revision."; 790 reference 791 "RFC XXXX: I2NSF Capability YANG Data Model"; 793 // RFC Ed.: replace XXXX with an actual RFC number and remove 794 // this note. 795 } 797 /* 798 * Identities 799 */ 801 identity event { 802 description 803 "Base identity for I2NSF events."; 804 reference 805 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 806 Monitoring YANG Data Model - Event"; 807 } 809 identity system-event { 810 base event; 811 description 812 "Identity for system event"; 813 reference 814 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 815 Monitoring YANG Data Model - System event"; 816 } 818 identity system-alarm { 819 base event; 820 description 821 "Identity for system alarm"; 822 reference 823 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 824 Monitoring YANG Data Model - System alarm"; 825 } 827 identity time { 828 base event; 829 description 830 "Identity for time capabilities"; 831 } 833 identity access-violation { 834 base system-event; 835 description 836 "Identity for access violation event"; 837 reference 838 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 839 Monitoring YANG Data Model - System event for access 840 violation"; 841 } 843 identity configuration-change { 844 base system-event; 845 description 846 "Identity for configuration change event"; 847 reference 848 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 849 Monitoring YANG Data Model - System event for configuration 850 change"; 851 } 853 identity memory-alarm { 854 base system-alarm; 855 description 856 "Identity for memory alarm. Alarm when memory usage 857 exceeds a threshold."; 858 reference 859 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 860 Monitoring YANG Data Model - System alarm for memory"; 861 } 862 identity cpu-alarm { 863 base system-alarm; 864 description 865 "Identity for CPU alarm. Alarm when CPU usage 866 exceeds a threshold."; 867 reference 868 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 869 Monitoring YANG Data Model - System alarm for CPU"; 870 } 872 identity disk-alarm { 873 base system-alarm; 874 description 875 "Identity for disk alarm. Alarm when disk usage 876 exceeds a threshold."; 877 reference 878 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 879 Monitoring YANG Data Model - System alarm for disk"; 880 } 882 identity hardware-alarm { 883 base system-alarm; 884 description 885 "Identity for hardware alarm. Alarm when a hardware failure 886 or hardware degradation occurs."; 887 reference 888 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 889 Monitoring YANG Data Model - System alarm for hardware"; 890 } 892 identity interface-alarm { 893 base system-alarm; 894 description 895 "Identity for interface alarm. Alarm when interface usage 896 exceeds a threshold."; 897 reference 898 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 899 Monitoring YANG Data Model - System alarm for interface"; 900 } 902 identity absolute-time { 903 base time; 904 description 905 "absolute time capabilities. 906 If a network security function has the absolute time 907 capability, the network security function supports 908 rule execution according to absolute time."; 909 } 910 identity periodic-time { 911 base time; 912 description 913 "periodic time capabilities. 914 If a network security function has the periodic time 915 capability, the network security function supports 916 rule execution according to periodic time."; 917 } 919 identity target-device { 920 description 921 "Identity for target condition capability. The capability for 922 matching the target device type."; 923 } 925 identity computer { 926 base target-device; 927 description 928 "Identity for computer such as personal computer (PC) 929 and server"; 930 } 932 identity mobile-phone { 933 base target-device; 934 description 935 "Identity for mobile-phone such as smartphone and 936 cellphone"; 937 } 939 identity voip-volte-phone { 940 base target-device; 941 description 942 "Identity for voip-volte-phone"; 943 } 945 identity tablet { 946 base target-device; 947 description 948 "Identity for tablet"; 949 } 951 identity network-infrastructure-device { 952 base target-device; 953 description 954 "Identity for network infrastructure devices 955 such as switch, router, and access point"; 956 } 957 identity iot { 958 base target-device; 959 description 960 "Identity for IoT (Internet of Things)"; 961 } 963 identity ot { 964 base target-device; 965 description 966 "Identity for Operational Technology"; 967 } 969 identity vehicle { 970 base target-device; 971 description 972 "Identity for vehicle that connects to and shares 973 data through the Internet"; 974 } 976 identity user-condition { 977 description 978 "Base identity for user condition capability. This is the 979 capability of mapping user(s) into their corresponding IP 980 address"; 981 } 983 identity user { 984 base user-condition; 985 description 986 "Identity for user condition capability. 987 A user (e.g., employee) can be mapped to an IP address of 988 a computing device (e.g., computer, laptop, and virtual 989 machine) which the user is using."; 990 } 992 identity group { 993 base user-condition; 994 description 995 "Identity for group condition capability. 996 A group (e.g., employees) can be mapped to multiple IP 997 addresses of computing devices (e.g., computers, laptops, 998 and virtual machines) which the group is using."; 999 } 1001 identity geography-location { 1002 description 1003 "Identity for geography condition capability"; 1004 reference 1005 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1006 An access control for a geographical location (i.e., 1007 geolocation) that has the corresponding IP prefix."; 1008 } 1010 identity source-location { 1011 base geography-location; 1012 description 1013 "Identity for source geography location condition capability"; 1014 reference 1015 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1016 An access control for a geographical location (i.e., 1017 geolocation) that has the corresponding IP prefix."; 1018 } 1020 identity destination-location { 1021 base geography-location; 1022 description 1023 "Identity for destination geography location condition 1024 capability"; 1025 reference 1026 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1027 An access control for a geographical location (i.e., 1028 geolocation) that has the corresponding IP prefix."; 1029 } 1031 identity directional { 1032 description 1033 "Base identity for directional traffic flow capability"; 1034 reference 1035 "RFC 5101: Specification of the IP Flow Information 1036 Export (IPFIX) Protocol for the Exchange of IP 1037 Traffic Flow Information - Terminology Unidirectional 1038 and Bidirectional Flow"; 1039 } 1041 identity unidirectional { 1042 base directional; 1043 description 1044 "Identity for unirectional traffic flow."; 1045 reference 1046 "RFC 5101: Specification of the IP Flow Information 1047 Export (IPFIX) Protocol for the Exchange of IP 1048 Traffic Flow Information - Terminology Unidirectional 1049 Flow"; 1050 } 1052 identity bidirectional { 1053 base directional; 1054 description 1055 "Identity for bidirectional traffic flow."; 1056 reference 1057 "RFC 5101: Specification of the IP Flow Information 1058 Export (IPFIX) Protocol for the Exchange of IP 1059 Traffic Flow Information - Terminology Bidirectional 1060 Flow"; 1061 } 1063 identity protocol { 1064 description 1065 "Base identity for protocols"; 1066 } 1068 identity ethernet { 1069 base protocol; 1070 description 1071 "Base identity for Ethernet protocol."; 1072 } 1074 identity source-mac-address { 1075 base ethernet; 1076 description 1077 "Identity for the capability of matching Media Access Control 1078 (MAC) source address(es) condition capability."; 1079 reference 1080 "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; 1081 } 1083 identity destination-mac-address { 1084 base ethernet; 1085 description 1086 "Identity for the capability of matching Media Access Control 1087 (MAC) destination address(es) condition capability."; 1088 reference 1089 "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; 1090 } 1092 identity ether-type { 1093 base ethernet; 1094 description 1095 "Identity for the capability of matching the EtherType in 1096 Ethernet II and Length in Ethernet 802.3 of a packet."; 1097 reference 1098 "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; 1099 } 1100 identity ip { 1101 base protocol; 1102 description 1103 "Base identity for internet/network layer protocol, 1104 e.g., IPv4, IPv6, and ICMP."; 1105 } 1107 identity ipv4 { 1108 base ip; 1109 description 1110 "Base identity for IPv4 condition capability"; 1111 reference 1112 "RFC 791: Internet Protocol"; 1113 } 1115 identity ipv6 { 1116 base ip; 1117 description 1118 "Base identity for IPv6 condition capabilities"; 1119 reference 1120 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1121 Specification"; 1122 } 1124 identity dscp { 1125 base ipv4; 1126 base ipv6; 1127 description 1128 "Identity for the capability of matching IPv4 annd IPv6 1129 Differentiated Services Codepoint (DSCP) condition"; 1130 reference 1131 "RFC 791: Internet Protocol - Type of Service 1132 RFC 2474: Definition of the Differentiated 1133 Services Field (DS Field) in the IPv4 and 1134 IPv6 Headers 1135 RFC 8200: Internet Protocol, Version 6 (IPv6) 1136 Specification - Traffic Class"; 1137 } 1139 identity length { 1140 base ipv4; 1141 base ipv6; 1142 description 1143 "Identity for the capability of matching IPv4 Total Length 1144 header field or IPv6 Payload Length header field. 1146 IPv4 Total Length is the length of datagram, measured in 1147 octets, including internet header and data. 1149 IPv6 Payload Length is the length of the IPv6 payload, i.e., 1150 the rest of the packet following the IPv6 header, measured in 1151 octets."; 1152 reference 1153 "RFC 791: Internet Protocol - Total Length 1154 RFC 8200: Internet Protocol, Version 6 (IPv6) 1155 Specification - Payload Length"; 1156 } 1158 identity ttl { 1159 base ipv4; 1160 base ipv6; 1161 description 1162 "Identity for the capability of matching IPv4 Time-To-Live 1163 (TTL) or IPv6 Hop Limit."; 1164 reference 1165 "RFC 791: Internet Protocol - Time To Live (TTL) 1166 RFC 8200: Internet Protocol, Version 6 (IPv6) 1167 Specification - Hop Limit"; 1168 } 1170 identity next-header { 1171 base ipv4; 1172 base ipv6; 1173 description 1174 "Identity for the capability of matching IPv4 Protocol Field or 1175 equivalent to IPv6 Next Header."; 1176 reference 1177 "IANA Website: Assigned Internet Protocol Numbers 1178 - Protocol Number for IPv4 1179 RFC 791: Internet Protocol - Protocol 1180 RFC 8200: Internet Protocol, Version 6 (IPv6) 1181 Specification - Next Header"; 1182 } 1184 identity source-address { 1185 base ipv4; 1186 base ipv6; 1187 description 1188 "Identity for the capability of matching IPv4 or IPv6 source 1189 address(es) condition capability."; 1190 reference 1191 "RFC 791: Internet Protocol - Address 1192 RFC 8200: Internet Protocol, Version 6 (IPv6) 1193 Specification - Source Address"; 1194 } 1196 identity destination-address { 1197 base ipv4; 1198 base ipv6; 1199 description 1200 "Identity for the capability of matching IPv4 or IPv6 1201 destination address(es) condition capability."; 1202 reference 1203 "RFC 791: Internet Protocol - Address 1204 RFC 8200: Internet Protocol, Version 6 (IPv6) 1205 Specification - Destination Address"; 1206 } 1208 identity flow-direction { 1209 base ipv4; 1210 base ipv6; 1211 description 1212 "Identity for flow direction of matching IPv4/IPv6 source 1213 or destination address(es) condition capability where a flow's 1214 direction is either unidirectional or bidirectional"; 1215 reference 1216 "RFC 791: Internet Protocol 1217 RFC 8200: Internet Protocol, Version 6 (IPv6) 1218 Specification"; 1219 } 1221 identity header-length { 1222 base ipv4; 1223 description 1224 "Identity for matching IPv4 header-length 1225 condition capability"; 1226 reference 1227 "RFC 791: Internet Protocol - Header Length"; 1228 } 1230 identity identification { 1231 base ipv4; 1232 description 1233 "Identity for IPv4 identification condition capability. 1234 IPv4 ID field is used for fragmentation and reassembly."; 1235 reference 1236 "RFC 791: Internet Protocol - Identification 1237 RFC 6864: Updated Specification of the IPv4 ID Field - 1238 Fragmentation and Reassembly"; 1239 } 1241 identity fragment-flags { 1242 base ipv4; 1243 description 1244 "Identity for IPv4 fragment flags condition capability"; 1246 reference 1247 "RFC 791: Internet Protocol - Fragmentation Flags"; 1248 } 1250 identity fragment-offset { 1251 base ipv4; 1252 description 1253 "Identity for matching IPv4 fragment offset 1254 condition capability"; 1255 reference 1256 "RFC 791: Internet Protocol - Fragmentation Offset"; 1257 } 1259 identity ipv4-options { 1260 base ipv4; 1261 description 1262 "Identity for IPv4 options condition capability"; 1263 reference 1264 "RFC 791: Internet Protocol - Options"; 1265 } 1267 identity flow-label { 1268 base ipv6; 1269 description 1270 "Identity for matching IPv6 flow label 1271 condition capability"; 1272 reference 1273 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1274 Specification - Flow Label 1275 RFC 6437: IPv6 Flow Label Specification"; 1276 } 1278 identity header-order { 1279 base ipv6; 1280 description 1281 "Identity for IPv6 extension header order condition 1282 capability"; 1283 reference 1284 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1285 Specification - Extension Header Order"; 1286 } 1288 identity hop-by-hop { 1289 base ipv6; 1290 description 1291 "Identity for IPv6 hop by hop options header 1292 condition capability"; 1293 reference 1294 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1296 Specification - Options"; 1297 } 1299 identity routing-header { 1300 base ipv6; 1301 description 1302 "Identity for IPv6 routing header condition 1303 capability"; 1304 reference 1305 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1306 Specification - Routing Header"; 1307 } 1309 identity fragment-header { 1310 base ipv6; 1311 description 1312 "Identity for IPv6 fragment header condition 1313 capability"; 1314 reference 1315 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1316 Specification - Fragment Header"; 1317 } 1319 identity destination-options { 1320 base ipv6; 1321 description 1322 "Identity for IPv6 destination options condition 1323 capability"; 1324 reference 1325 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1326 Specification - Destination Options"; 1327 } 1329 identity icmp { 1330 base protocol; 1331 description 1332 "Base identity for ICMPv4 and ICMPv6 condition capability"; 1333 reference 1334 "RFC 792: Internet Control Message Protocol 1335 RFC 4443: Internet Control Message Protocol (ICMPv6) 1336 for the Internet Protocol Version 6 (IPv6) Specification 1337 - ICMPv6"; 1338 } 1340 identity icmpv4 { 1341 base icmp; 1342 description 1343 "Base identity for ICMPv4 condition capability"; 1344 reference 1345 "RFC 792: Internet Control Message Protocol"; 1346 } 1348 identity icmpv6 { 1349 base icmp; 1350 description 1351 "Base identity for ICMPv6 condition capability"; 1352 reference 1353 "RFC 4443: Internet Control Message Protocol (ICMPv6) 1354 for the Internet Protocol Version 6 (IPv6) Specification 1355 - ICMPv6"; 1356 } 1358 identity type { 1359 base icmpv4; 1360 base icmpv6; 1361 description 1362 "Identity for ICMPv4 and ICMPv6 type condition capability"; 1363 reference 1364 "RFC 792: Internet Control Message Protocol 1365 RFC 4443: Internet Control Message Protocol (ICMPv6) 1366 for the Internet Protocol Version 6 (IPv6) Specification 1367 - ICMPv6"; 1368 } 1370 identity code { 1371 base icmpv4; 1372 base icmpv6; 1373 description 1374 "Identity for ICMPv4 and ICMPv6 code condition capability"; 1375 reference 1376 "RFC 792: Internet Control Message Protocol 1377 RFC 4443: Internet Control Message Protocol (ICMPv6) 1378 for the Internet Protocol Version 6 (IPv6) Specification 1379 - ICMPv6"; 1380 } 1382 identity transport-protocol { 1383 base protocol; 1384 description 1385 "Base identity for Layer 4 protocol condition capabilities, 1386 e.g., TCP, UDP, SCTP, and DCCP"; 1387 } 1389 identity tcp { 1390 base transport-protocol; 1391 description 1392 "Base identity for TCP condition capabilities"; 1393 reference 1394 "RFC 793: Transmission Control Protocol 1395 draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1396 (TCP) Specification"; 1397 } 1399 identity udp { 1400 base transport-protocol; 1401 description 1402 "Base identity for UDP condition capabilities"; 1403 reference 1404 "RFC 768: User Datagram Protocol"; 1405 } 1407 identity sctp { 1408 base transport-protocol; 1409 description 1410 "Identity for SCTP condition capabilities"; 1411 reference 1412 "RFC 4960: Stream Control Transmission Protocol"; 1413 } 1415 identity dccp { 1416 base transport-protocol; 1417 description 1418 "Identity for DCCP condition capabilities"; 1419 reference 1420 "RFC 4340: Datagram Congestion Control Protocol"; 1421 } 1423 identity source-port-number { 1424 base tcp; 1425 base udp; 1426 base sctp; 1427 base dccp; 1428 description 1429 "Identity for matching TCP, UDP, SCTP, and DCCP source port 1430 number condition capability"; 1431 reference 1432 "RFC 793: Transmission Control Protocol - Port Number 1433 draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1434 (TCP) Specification 1435 RFC 768: User Datagram Protocol 1436 RFC 4960: Stream Control Transmission Protocol 1437 RFC 4340: Datagram Congestion Control Protocol"; 1439 } 1441 identity destination-port-number { 1442 base tcp; 1443 base udp; 1444 base sctp; 1445 base dccp; 1446 description 1447 "Identity for matching TCP, UDP, SCTP, and DCCP destination 1448 port number condition capability"; 1449 reference 1450 "RFC 793: Transmission Control Protocol - Port Number 1451 draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1452 (TCP) Specification"; 1453 } 1455 identity flags { 1456 base tcp; 1457 description 1458 "Identity for TCP control bits (flags) condition capability"; 1459 reference 1460 "RFC 793: Transmission Control Protocol - Flags 1461 RFC 3168: The Addition of Explicit Congestion Notification 1462 (ECN) to IP - TCP Header Flags 1463 draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1464 (TCP) Specification 1465 draft-ietf-tcpm-accurate-ecn: More Accurate ECN Feedback 1466 in TCP"; 1467 } 1469 identity tcp-options { 1470 base tcp; 1471 description 1472 "Identity for TCP options condition capability."; 1473 reference 1474 "RFC 793: Transmission Control Protocol - Options 1475 draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1476 (TCP) Specification 1477 RFC 6691: TCP Options and Maximum Segment Size 1478 RFC 7323: TCP Extensions for High Performance"; 1479 } 1481 identity total-length { 1482 base udp; 1483 description 1484 "Identity for matching UDP total-length condition capability. 1485 The UDP total length can be smaller than the IP transport 1486 length for UDP transport layer options."; 1488 reference 1489 "RFC 768: User Datagram Protocol - Total Length 1490 draft-ietf-tsvwg-udp-options: Transport Options for UDP"; 1491 } 1493 identity verification-tag { 1494 base sctp; 1495 description 1496 "Identity for range-match SCTP verification tag condition 1497 capability"; 1498 reference 1499 "RFC 4960: Stream Control Transmission Protocol - Verification 1500 Tag"; 1501 } 1503 identity chunk-type { 1504 base sctp; 1505 description 1506 "Identity for SCTP chunk type condition capability"; 1507 reference 1508 "RFC 4960: Stream Control Transmission Protocol - Chunk Type"; 1509 } 1511 identity service-code { 1512 base dccp; 1513 description 1514 "Identity for DCCP Service Code condition capabilitiy"; 1515 reference 1516 "RFC 4340: Datagram Congestion Control Protocol 1517 RFC 5595: The Datagram Congestion Control Protocol (DCCP) 1518 Service Codes 1519 RFC 6335: Internet Assigned Numbers Authority (IANA) 1520 Procedures for the Management of the Service Name and 1521 Transport Protocol Port Number Registry - Service Code"; 1522 } 1524 identity application-protocol { 1525 base protocol; 1526 description 1527 "Base identity for Application protocol"; 1528 } 1530 identity http { 1531 base application-protocol; 1532 description 1533 "The identity for Hypertext Transfer Protocol."; 1534 reference 1535 "RFC 2616: Hypertext Transfer Protocol (HTTP) 1536 RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1537 Syntax and Routing 1538 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1539 and Content"; 1540 } 1542 identity https { 1543 base application-protocol; 1544 description 1545 "The identity for Hypertext Transfer Protocol Secure."; 1546 reference 1547 "RFC 2818: HTTP over TLS (HTTPS) 1548 RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1549 Syntax and Routing 1550 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1551 and Content"; 1552 } 1554 identity ftp { 1555 base application-protocol; 1556 description 1557 "The identity for File Transfer Protocol."; 1558 reference 1559 "RFC 959: File Transfer Protocol (FTP)"; 1560 } 1562 identity ssh { 1563 base application-protocol; 1564 description 1565 "The identity for Secure Shell (SSH) protocol."; 1566 reference 1567 "RFC 4250: The Secure Shell (SSH) Protocol"; 1568 } 1570 identity telnet { 1571 base application-protocol; 1572 description 1573 "The identity for telnet."; 1574 reference 1575 "RFC 854: Telnet Protocol"; 1576 } 1578 identity smtp { 1579 base application-protocol; 1580 description 1581 "The identity for Simple Mail Transfer Protocol."; 1582 reference 1583 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1585 } 1587 identity pop3 { 1588 base application-protocol; 1589 description 1590 "The identity for Post Office Protocol 3."; 1591 reference 1592 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1593 } 1595 identity imap { 1596 base application-protocol; 1597 description 1598 "The identity for Internet Message Access Protocol."; 1599 reference 1600 "RFC 3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"; 1601 } 1603 identity action { 1604 description 1605 "Base identity for action capability"; 1606 } 1608 identity log-action { 1609 base action; 1610 description 1611 "Base identity for log-action capability"; 1612 } 1614 identity ingress-action { 1615 base action; 1616 description 1617 "Base identity for ingress-action capability"; 1618 reference 1619 "RFC 8329: Framework for Interface to Network Security 1620 Functions - Section 7.2"; 1621 } 1623 identity egress-action { 1624 base action; 1625 description 1626 "Base identity for egress-action capability"; 1627 reference 1628 "RFC 8329: Framework for Interface to Network Security 1629 Functions - Section 7.2"; 1630 } 1632 identity default-action { 1633 base action; 1634 description 1635 "Base identity for default-action capability"; 1636 } 1638 identity rule-log { 1639 base log-action; 1640 description 1641 "Identity for rule log-action capability. 1642 Log the received packet based on the rule"; 1643 } 1645 identity session-log { 1646 base log-action; 1647 description 1648 "Identity for session log-action capability. 1649 Log the received packet based on the session."; 1650 } 1652 identity pass { 1653 base ingress-action; 1654 base egress-action; 1655 base default-action; 1656 description 1657 "Identity for pass action capability. The pass action allows 1658 packet or flow to go through the NSF entering or exiting the 1659 internal network."; 1660 } 1662 identity drop { 1663 base ingress-action; 1664 base egress-action; 1665 base default-action; 1666 description 1667 "Identity for drop action capability. The drop action denies 1668 packet to go through the NSF entering or exiting the internal 1669 network."; 1670 } 1672 identity mirror { 1673 base ingress-action; 1674 base egress-action; 1675 base default-action; 1676 description 1677 "Identity for mirror action capability. The mirror action 1678 copies packet and send it to the monitoring entity while still 1679 allow the packet or flow to go through the NSF."; 1680 } 1681 identity rate-limit { 1682 base ingress-action; 1683 base egress-action; 1684 base default-action; 1685 description 1686 "Identity for rate limiting action capability. The rate limit 1687 action limits the number of packets or flows that can go 1688 through the NSF by dropping packets or flows (randomly or 1689 systematically)."; 1690 } 1692 identity invoke-signaling { 1693 base egress-action; 1694 description 1695 "Identity for invoke signaling action capability"; 1696 } 1698 identity tunnel-encapsulation { 1699 base egress-action; 1700 description 1701 "Identity for tunnel encapsulation action capability"; 1702 } 1704 identity forwarding { 1705 base egress-action; 1706 description 1707 "Identity for forwarding action capability"; 1708 } 1710 identity transformation { 1711 base egress-action; 1712 description 1713 "Identity for transformation action capability"; 1714 } 1716 identity resolution-strategy { 1717 description 1718 "Base identity for resolution strategy capability"; 1719 } 1721 identity fmr { 1722 base resolution-strategy; 1723 description 1724 "Identity for First Matching Rule (FMR) resolution 1725 strategy capability"; 1726 } 1728 identity lmr { 1729 base resolution-strategy; 1730 description 1731 "Identity for Last Matching Rule (LMR) resolution 1732 strategy capability"; 1733 } 1735 identity pmr { 1736 base resolution-strategy; 1737 description 1738 "Identity for Prioritized Matching Rule (PMR) resolution 1739 strategy capability"; 1740 } 1742 identity pmre { 1743 base resolution-strategy; 1744 description 1745 "Identity for Prioritized Matching Rule with Errors (PMRE) 1746 resolution strategy capability"; 1747 } 1749 identity pmrn { 1750 base resolution-strategy; 1751 description 1752 "Identity for Prioritized Matching Rule with No Errors (PMRN) 1753 resolution strategy capability"; 1754 } 1756 identity advanced-nsf { 1757 description 1758 "Base identity for advanced Network Security Function (NSF) 1759 capability."; 1760 } 1762 identity content-security-control { 1763 base advanced-nsf; 1764 description 1765 "Base identity for content security control. Content security 1766 control is an NSF that evaluates a packet's payload such as 1767 Intrusion Prevention System (IPS), URL-Filtering, Antivirus, 1768 and VoIP/VoLTE Filter."; 1769 } 1771 identity attack-mitigation-control { 1772 base advanced-nsf; 1773 description 1774 "Base identity for attack mitigation control. Attack mitigation 1775 control is an NSF that mitigates an attack such as anti-DDoS 1776 or DDoS-mitigator."; 1778 } 1780 identity ips { 1781 base content-security-control; 1782 description 1783 "Base identity for IPS (Intrusion Prevention System) capability 1784 that prevents malicious activity within a network"; 1785 } 1787 identity url-filtering { 1788 base content-security-control; 1789 description 1790 "Base identity for url filtering capability that limits access 1791 by comparing the web traffic's URL with the URLs for web 1792 filtering in a database"; 1793 } 1795 identity anti-virus { 1796 base content-security-control; 1797 description 1798 "Base identity for anti-virus capability to protect the network 1799 by detecting and removing viruses."; 1800 } 1802 identity voip-volte-filtering { 1803 base content-security-control; 1804 description 1805 "Base identity for advanced NSF VoIP/VoLTE Security Service 1806 capability to filter the VoIP/VoLTE packets or flows."; 1807 reference 1808 "RFC 3261: SIP: Session Initiation Protocol"; 1809 } 1811 identity anti-ddos { 1812 base attack-mitigation-control; 1813 description 1814 "Base identity for advanced NSF Anti-DDoS Attack or DDoS 1815 Mitigator capability."; 1816 } 1818 identity packet-rate { 1819 base anti-ddos; 1820 description 1821 "Identity for advanced NSF Anti-DDoS detecting Packet Rate 1822 Capability where a packet rate is defined as the arrival rate 1823 of Packets toward a victim destination node. The NSF with 1824 this capability can detect the incoming packet rate and create 1825 an alert if the rate exceeds the threshold."; 1827 } 1829 identity flow-rate { 1830 base anti-ddos; 1831 description 1832 "Identity for advanced NSF Anti-DDoS detecting Flow Rate 1833 Capability where a flow rate is defined as the arrival rate of 1834 flows towards a victim destination node. The NSF with this 1835 capability can detect the incoming flow rate and create an 1836 alert if the rate exceeds the threshold."; 1837 } 1839 identity byte-rate { 1840 base anti-ddos; 1841 description 1842 "Identity for advanced NSF Anti-DDoS detecting Byte Rate 1843 Capability where a byte rate is defined as the arrival rate of 1844 Bytes toward a victim destination node. The NSF with this 1845 capability can detect the incoming byte rate and create an 1846 alert if the rate exceeds the threshold."; 1847 } 1849 identity signature-set { 1850 base ips; 1851 description 1852 "Identity for the capability of IPS to set the signature. 1853 Signature is a set of rules to detect an intrusive activity."; 1854 reference 1855 "RFC 4766: Intrusion Detection Message Exchange Requirements - 1856 Section 2.2.13"; 1857 } 1859 identity exception-signature { 1860 base ips; 1861 description 1862 "Identity for the capability of IPS to exclude signatures from 1863 detecting the intrusion."; 1864 reference 1865 "RFC 4766: Intrusion Detection Message Exchange Requirements - 1866 Section 2.2.13"; 1867 } 1869 identity detect { 1870 base anti-virus; 1871 description 1872 "Identity for advanced NSF Antivirus capability to detect 1873 viruses using a security profile. The security profile is used 1874 to scan threats, such as virus, malware, and spyware. The NSF 1875 should be able to update the security profile."; 1876 } 1878 identity exception-files { 1879 base anti-virus; 1880 description 1881 "Identity for advanced NSF Antivirus capability to exclude a 1882 certain file type or name from detection."; 1883 } 1885 identity pre-defined { 1886 base url-filtering; 1887 description 1888 "Identity for pre-defined URL Database condition capability. 1889 where URL database is a public database for URL filtering."; 1890 } 1892 identity user-defined { 1893 base url-filtering; 1894 description 1895 "Identity for user-defined URL Database condition capability. 1896 that allows a users manual addition of URLs for URL 1897 filtering."; 1898 } 1900 identity call-id { 1901 base voip-volte-filtering; 1902 description 1903 "Identity for advanced NSF VoIP/VoLTE Call Identifier (ID) 1904 capability."; 1905 } 1907 identity user-agent { 1908 base voip-volte-filtering; 1909 description 1910 "Identity for advanced NSF VoIP/VoLTE User Agent capability."; 1911 } 1913 /* 1914 * Grouping 1915 */ 1917 grouping nsf-capabilities { 1918 description 1919 "Network Security Function (NSF) Capabilities"; 1920 reference 1921 "RFC 8329: Framework for Interface to Network Security 1922 Functions - I2NSF Flow Security Policy Structure."; 1924 leaf-list directional-capabilities { 1925 type identityref { 1926 base directional; 1927 } 1928 description 1929 "The capability of an NSF for handling directional traffic 1930 flow (i.e., unidirectional or bidirectional traffic flow)."; 1931 } 1933 container event-capabilities { 1934 description 1935 "Capabilities of events. 1936 If a network security function has the event capabilities, 1937 the network security function supports rule execution 1938 according to system event and system alarm."; 1940 reference 1941 "RFC 8329: Framework for Interface to Network Security 1942 Functions - Section 7. 1943 draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF 1944 NSF Monitoring YANG Data Model - System Alarm and 1945 System Events."; 1947 leaf-list system-event-capability { 1948 type identityref { 1949 base system-event; 1950 } 1951 description 1952 "System event capabilities"; 1953 } 1955 leaf-list system-alarm-capability { 1956 type identityref { 1957 base system-alarm; 1958 } 1959 description 1960 "System alarm capabilities"; 1961 } 1963 leaf-list time-capabilities { 1964 type identityref { 1965 base time; 1966 } 1967 description 1968 "The capabilities for activating the policy within a 1969 specific time."; 1970 } 1971 } 1972 container condition-capabilities { 1973 description 1974 "Conditions capabilities."; 1975 container generic-nsf-capabilities { 1976 description 1977 "Conditions capabilities. 1978 If a network security function has the condition 1979 capabilities, the network security function 1980 supports rule execution according to conditions of 1981 IPv4, IPv6, TCP, UDP, SCTP, DCCP, ICMP, or ICMPv6."; 1982 reference 1983 "RFC 768: User Datagram Protocol - UDP. 1984 RFC 791: Internet Protocol - IPv4. 1985 RFC 792: Internet Control Message Protocol - ICMP. 1986 RFC 793: Transmission Control Protocol - TCP. 1987 RFC 4443: Internet Control Message Protocol (ICMPv6) 1988 for the Internet Protocol Version 6 (IPv6) Specification 1989 - ICMPv6. 1990 RFC 4960: Stream Control Transmission Protocol - SCTP. 1991 RFC 8200: Internet Protocol, Version 6 (IPv6) 1992 Specification - IPv6. 1993 RFC 8329: Framework for Interface to Network Security 1994 Functions - I2NSF Flow Security Policy Structure."; 1996 leaf-list ethernet-capability { 1997 type identityref { 1998 base ethernet; 1999 } 2000 description 2001 "Media Access Control (MAC) capabilities"; 2002 reference 2003 "IEEE 802.3: IEEE Standard for Ethernet"; 2004 } 2006 leaf-list ipv4-capability { 2007 type identityref { 2008 base ipv4; 2009 } 2010 description 2011 "IPv4 packet capabilities"; 2012 reference 2013 "RFC 791: Internet Protocol"; 2014 } 2016 leaf-list ipv6-capability { 2017 type identityref { 2018 base ipv6; 2019 } 2020 description 2021 "IPv6 packet capabilities"; 2022 reference 2023 "RFC 8200: Internet Protocol, Version 6 (IPv6) 2024 Specification - IPv6"; 2025 } 2027 leaf-list icmpv4-capability { 2028 type identityref { 2029 base icmpv4; 2030 } 2031 description 2032 "ICMPv4 packet capabilities"; 2033 reference 2034 "RFC 792: Internet Control Message Protocol - ICMP"; 2035 } 2037 leaf-list icmpv6-capability { 2038 type identityref { 2039 base icmpv6; 2040 } 2041 description 2042 "ICMPv6 packet capabilities"; 2043 reference 2044 "RFC 4443: Internet Control Message Protocol (ICMPv6) 2045 for the Internet Protocol Version 6 (IPv6) Specification 2046 - ICMPv6"; 2047 } 2049 leaf-list tcp-capability { 2050 type identityref { 2051 base tcp; 2052 } 2053 description 2054 "TCP packet capabilities"; 2055 reference 2056 "RFC 793: Transmission Control Protocol - TCP 2057 draft-ietf-tcpm-rfc793bis-25: Transmission Control 2058 Protocol (TCP) Specification"; 2059 } 2061 leaf-list udp-capability { 2062 type identityref { 2063 base udp; 2064 } 2065 description 2066 "UDP packet capabilities"; 2067 reference 2068 "RFC 768: User Datagram Protocol - UDP"; 2069 } 2071 leaf-list sctp-capability { 2072 type identityref { 2073 base sctp; 2074 } 2075 description 2076 "SCTP packet capabilities"; 2077 reference 2078 "RFC 4960: Stream Control Transmission Protocol - SCTP"; 2079 } 2081 leaf-list dccp-capability { 2082 type identityref { 2083 base dccp; 2084 } 2085 description 2086 "DCCP packet capabilities"; 2087 reference 2088 "RFC 4340: Datagram Congestion Control Protocol - DCCP"; 2089 } 2090 } 2092 container advanced-nsf-capabilities { 2093 description 2094 "Advanced Network Security Function (NSF) capabilities, 2095 such as Anti-DDoS, IPS, and VoIP/VoLTE. 2096 This container contains the leaf-lists of advanced 2097 NSF capabilities"; 2099 leaf-list anti-ddos-capability { 2100 type identityref { 2101 base anti-ddos; 2102 } 2103 description 2104 "Anti-DDoS Attack capabilities"; 2105 } 2107 leaf-list ips-capability { 2108 type identityref { 2109 base ips; 2110 } 2111 description 2112 "IPS capabilities"; 2113 } 2115 leaf-list anti-virus-capability { 2116 type identityref { 2117 base anti-virus; 2118 } 2119 description 2120 "Anti-Virus capabilities"; 2121 } 2123 leaf-list url-capability { 2124 type identityref { 2125 base url-filtering; 2126 } 2127 description 2128 "URL capabilities"; 2129 } 2131 leaf-list voip-volte-filtering-capability { 2132 type identityref { 2133 base voip-volte-filtering; 2134 } 2135 description 2136 "VoIP/VoLTE capabilities"; 2137 } 2138 } 2140 container context-capabilities { 2141 description 2142 "Security context capabilities"; 2143 leaf-list application-filter-capabilities{ 2144 type identityref { 2145 base application-protocol; 2146 } 2147 description 2148 "Context capabilities based on the application protocol"; 2149 } 2151 leaf-list target-capabilities { 2152 type identityref { 2153 base target-device; 2154 } 2155 description 2156 "Context capabilities based on the device attribute that 2157 can identify a device type 2158 (i.e., router, switch, pc, ios, or android)."; 2159 } 2161 leaf-list user-condition-capabilities { 2162 type identityref { 2163 base user-condition; 2165 } 2166 description 2167 "Context capabilities based on user condition, such as 2168 user-id or user-name. The users can collected into a 2169 user-group and identified with group-id or group-name. 2170 An NSF is aware of the IP address of the user provided 2171 by a unified user management system via network. Based 2172 on name-address association, an NSF is able to enforce 2173 the security functions over the given user (or user 2174 group)"; 2175 } 2177 leaf-list geography-capabilities { 2178 type identityref { 2179 base geography-location; 2180 } 2181 description 2182 "Context condition capabilities based on the geographical 2183 location of the source or destination"; 2184 } 2185 } 2186 } 2188 container action-capabilities { 2189 description 2190 "Action capabilities. 2191 If a network security function has the action capabilities, 2192 the network security function supports the attendant 2193 actions for policy rules."; 2195 leaf-list ingress-action-capability { 2196 type identityref { 2197 base ingress-action; 2198 } 2199 description 2200 "Ingress-action capabilities"; 2201 } 2203 leaf-list egress-action-capability { 2204 type identityref { 2205 base egress-action; 2206 } 2207 description 2208 "Egress-action capabilities"; 2209 } 2211 leaf-list log-action-capability { 2212 type identityref { 2213 base log-action; 2214 } 2215 description 2216 "Log-action capabilities"; 2217 } 2218 } 2220 leaf-list resolution-strategy-capabilities { 2221 type identityref { 2222 base resolution-strategy; 2223 } 2224 description 2225 "Resolution strategy capabilities. 2226 The resolution strategies can be used to specify how 2227 to resolve conflicts that occur between the actions 2228 of the same or different policy rules that are matched 2229 for the same packet and by particular NSF."; 2230 } 2232 leaf-list default-action-capabilities { 2233 type identityref { 2234 base default-action; 2235 } 2236 description 2237 "Default action capabilities. 2238 A default action is used to execute I2NSF policy rules 2239 when no rule matches a packet. The default action is 2240 defined as pass, drop, rate-limit, or mirror."; 2241 } 2242 } 2244 /* 2245 * Data nodes 2246 */ 2248 list nsf { 2249 key "nsf-name"; 2250 description 2251 "The list of Network Security Functions (NSFs)"; 2252 leaf nsf-name { 2253 type string; 2254 mandatory true; 2255 description 2256 "The name of Network Security Function (NSF)"; 2257 } 2258 uses nsf-capabilities; 2259 } 2260 } 2261 2263 Figure 3: YANG Data Module of I2NSF Capability 2265 7. IANA Considerations 2267 This document requests IANA to register the following URI in the 2268 "IETF XML Registry" [RFC3688]: 2270 ID: yang:ietf-i2nsf-capability 2271 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2272 Registrant Contact: The IESG. 2273 XML: N/A; the requested URI is an XML namespace. 2274 Filename: [ TBD-at-Registration ] 2275 Reference: [ RFC-to-be ] 2277 This document requests IANA to register the following YANG module in 2278 the "YANG Module Names" registry [RFC7950][RFC8525]: 2280 Name: ietf-i2nsf-capability 2281 Maintained by IANA? N 2282 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2283 Prefix: nsfcap 2284 Module: 2285 Reference: [ RFC-to-be ] 2287 8. Privacy Considerations 2289 This YANG module specifies the capabilities for NSFs. Some of the 2290 capabilities in this document MAY require highly sensitive private 2291 data to operate properly. The usage of such capability MUST be 2292 reported to the users and permitted before using the private 2293 information related to the capability. Using any of the capabilities 2294 that require private data MUST preserve the privacy by preventing any 2295 leakage or unauthorized disclosure of the private data. 2297 In regards to the privacy data used, the security for accessibility 2298 of the data should be tightly secured and monitored. The Security 2299 Considerations are discussed in Section 9. 2301 9. Security Considerations 2303 The YANG module specified in this document defines a data schema 2304 designed to be accessed through network management protocols such as 2305 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest layer of NETCONF 2306 protocol layers MUST use Secure Shell (SSH) [RFC4254][RFC6242] as a 2307 secure transport layer. The lowest layer of RESTCONF protocol layers 2308 MUST use HTTP over Transport Layer Security (TLS), that is, HTTPS 2309 [RFC7230][RFC8446] as a secure transport layer. 2311 The Network Configuration Access Control Model (NACM) [RFC8341] 2312 provides a means of restricting access to specific NETCONF or 2313 RESTCONF users to a preconfigured subset of all available NETCONF or 2314 RESTCONF protocol operations and contents. Thus, NACM SHOULD be used 2315 to restrict the NSF registration from unauthorized users. 2317 There are a number of data nodes defined in this YANG module that are 2318 writable, creatable, and deletable (i.e., config true, which is the 2319 default). These data nodes may be considered sensitive or vulnerable 2320 in some network environments. Write operations to these data nodes 2321 could have a negative effect on network and security operations. 2322 These data nodes are collected into a single list node. This list 2323 node is defined by list nsf with the following sensitivity/ 2324 vulnerability: 2326 * list nsf: An attacker could alter the security capabilities 2327 associated with an NSF by disabling or enabling the functionality 2328 of the security capabilities of the NSF. 2330 Some of the readable data nodes in this YANG module may be considered 2331 sensitive or vulnerable in some network environments. It is thus 2332 important to control read access (e.g., via get, get-config, or 2333 notification) to these data nodes. These are the subtrees and data 2334 nodes with their sensitivity/vulnerability: 2336 * list nsf: The leak of this node to an attacker could reveal the 2337 specific configuration of security controls to an attacker. An 2338 attacker can craft an attack path that avoids observation or 2339 mitigations; one may reveal topology information to inform 2340 additional targets or enable lateral movement; one enables the 2341 construction of an attack path that avoids observation or 2342 mitigations; one provides an indication that the operator has 2343 discovered the attack. 2345 Some of the features that this document defines capability indicators 2346 for are highly sensitive and/or privileged operations that inherently 2347 require access to individuals' private data. These are subtrees and 2348 data nodes that are considered privacy sensitive: 2350 * voip-volte-filtering-capability: The NSF that is able to filter 2351 VoIP/VoLTE calls might identify certain individual identification. 2353 * user-condition-capabilities: The capability uses a set of IP 2354 addresses mapped to users. 2356 * geography-capabilities: The IP address used in this capability can 2357 identify a user's geographical location. 2359 It is noted that some private information is made accessible in this 2360 manner. Thus, the nodes/entities given access to this data MUST be 2361 tightly secured, monitored, and audited to prevent leakage or other 2362 unauthorized disclosure of private data. Refer to [RFC6973] for the 2363 description of privacy aspects that protocol designers (including 2364 YANG data model designers) should consider along with regular 2365 security and privacy analysis. 2367 10. References 2369 10.1. Normative References 2371 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2372 DOI 10.17487/RFC0768, August 1980, 2373 . 2375 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2376 DOI 10.17487/RFC0791, September 1981, 2377 . 2379 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2380 RFC 792, DOI 10.17487/RFC0792, September 1981, 2381 . 2383 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2384 RFC 793, DOI 10.17487/RFC0793, September 1981, 2385 . 2387 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 2388 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 2389 1983, . 2391 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2392 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 2393 . 2395 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2396 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 2397 . 2399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2400 Requirement Levels", BCP 14, RFC 2119, 2401 DOI 10.17487/RFC2119, March 1997, 2402 . 2404 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2405 "Definition of the Differentiated Services Field (DS 2406 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2407 DOI 10.17487/RFC2474, December 1998, 2408 . 2410 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2411 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2412 Transfer Protocol -- HTTP/1.1", RFC 2616, 2413 DOI 10.17487/RFC2616, June 1999, 2414 . 2416 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2417 DOI 10.17487/RFC2818, May 2000, 2418 . 2420 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2421 of Explicit Congestion Notification (ECN) to IP", 2422 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2423 . 2425 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2426 A., Peterson, J., Sparks, R., Handley, M., and E. 2427 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2428 DOI 10.17487/RFC3261, June 2002, 2429 . 2431 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 2432 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 2433 . 2435 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2436 DOI 10.17487/RFC3688, January 2004, 2437 . 2439 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2440 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 2441 January 2006, . 2443 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2444 Congestion Control Protocol (DCCP)", RFC 4340, 2445 DOI 10.17487/RFC4340, March 2006, 2446 . 2448 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2449 Control Message Protocol (ICMPv6) for the Internet 2450 Protocol Version 6 (IPv6) Specification", STD 89, 2451 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2452 . 2454 [RFC4766] Wood, M. and M. Erlinger, "Intrusion Detection Message 2455 Exchange Requirements", RFC 4766, DOI 10.17487/RFC4766, 2456 March 2007, . 2458 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2459 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2460 . 2462 [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information 2463 Export (IPFIX) Protocol for the Exchange of IP Traffic 2464 Flow Information", RFC 5101, DOI 10.17487/RFC5101, January 2465 2008, . 2467 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2468 DOI 10.17487/RFC5321, October 2008, 2469 . 2471 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 2472 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 2473 September 2009, . 2475 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2476 the Network Configuration Protocol (NETCONF)", RFC 6020, 2477 DOI 10.17487/RFC6020, October 2010, 2478 . 2480 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2481 and A. Bierman, Ed., "Network Configuration Protocol 2482 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2483 . 2485 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2486 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2487 . 2489 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2490 Cheshire, "Internet Assigned Numbers Authority (IANA) 2491 Procedures for the Management of the Service Name and 2492 Transport Protocol Port Number Registry", BCP 165, 2493 RFC 6335, DOI 10.17487/RFC6335, August 2011, 2494 . 2496 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2497 "IPv6 Flow Label Specification", RFC 6437, 2498 DOI 10.17487/RFC6437, November 2011, 2499 . 2501 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2502 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2503 . 2505 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2506 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2507 . 2509 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2510 Protocol (HTTP/1.1): Message Syntax and Routing", 2511 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2512 . 2514 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2515 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2516 DOI 10.17487/RFC7231, June 2014, 2517 . 2519 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2520 Kivinen, "Internet Key Exchange Protocol Version 2 2521 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2522 2014, . 2524 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 2525 Scheffenegger, Ed., "TCP Extensions for High Performance", 2526 RFC 7323, DOI 10.17487/RFC7323, September 2014, 2527 . 2529 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2530 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2531 . 2533 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2534 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2535 . 2537 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2538 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2539 May 2017, . 2541 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2542 (IPv6) Specification", STD 86, RFC 8200, 2543 DOI 10.17487/RFC8200, July 2017, 2544 . 2546 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2547 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2548 . 2550 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2551 Access Control Model", STD 91, RFC 8341, 2552 DOI 10.17487/RFC8341, March 2018, 2553 . 2555 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2556 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2557 DOI 10.17487/RFC8407, October 2018, 2558 . 2560 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2561 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2562 . 2564 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 2565 and R. Wilton, "YANG Library", RFC 8525, 2566 DOI 10.17487/RFC8525, March 2019, 2567 . 2569 [I-D.ietf-tcpm-accurate-ecn] 2570 Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More 2571 Accurate ECN Feedback in TCP", Work in Progress, Internet- 2572 Draft, draft-ietf-tcpm-accurate-ecn-15, 12 July 2021, 2573 . 2576 [I-D.ietf-tsvwg-udp-options] 2577 Touch, J., "Transport Options for UDP", Work in Progress, 2578 Internet-Draft, draft-ietf-tsvwg-udp-options-13, 19 June 2579 2021, . 2582 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 2583 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 2584 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 2585 Model", Work in Progress, Internet-Draft, draft-ietf- 2586 i2nsf-nsf-monitoring-data-model-09, 24 August 2021, 2587 . 2590 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 2591 Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin, 2592 "I2NSF Network Security Function-Facing Interface YANG 2593 Data Model", Work in Progress, Internet-Draft, draft-ietf- 2594 i2nsf-nsf-facing-interface-dm-13, 15 August 2021, 2595 . 2598 [I-D.ietf-i2nsf-registration-interface-dm] 2599 Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Park, 2600 "I2NSF Registration Interface YANG Data Model", Work in 2601 Progress, Internet-Draft, draft-ietf-i2nsf-registration- 2602 interface-dm-11, 21 August 2021, 2603 . 2606 10.2. Informative References 2608 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2609 RFC 6691, DOI 10.17487/RFC6691, July 2012, 2610 . 2612 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2613 Morris, J., Hansen, M., and R. Smith, "Privacy 2614 Considerations for Internet Protocols", RFC 6973, 2615 DOI 10.17487/RFC6973, July 2013, 2616 . 2618 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2619 and J. Jeong, "Interface to Network Security Functions 2620 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2621 DOI 10.17487/RFC8192, July 2017, 2622 . 2624 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2625 Kumar, "Framework for Interface to Network Security 2626 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2627 . 2629 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 2630 Kumari, "A Format for Self-Published IP Geolocation 2631 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 2632 . 2634 [I-D.ietf-tcpm-rfc793bis] 2635 Eddy, W. M., "Transmission Control Protocol (TCP) 2636 Specification", Work in Progress, Internet-Draft, draft- 2637 ietf-tcpm-rfc793bis-25, 7 September 2021, 2638 . 2641 [IANA-Protocol-Numbers] 2642 "Assigned Internet Protocol Numbers", Available: 2643 https://www.iana.org/assignments/protocol- 2644 numbers/protocol-numbers.xhtml, September 2020. 2646 [IEEE802.3-2018] 2647 Committee, I. S., "IEEE 802.3-2018 - IEEE Standard for 2648 Ethernet", August 2018, 2649 . 2651 [Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and 2652 management of firewall policies", 2004. 2654 [Galitsky] Galitsky, B. and R. Pampapathi, "Can many agents answer 2655 questions better than one", First 2656 Monday http://dx.doi.org/10.5210/fm.v10i1.1204, 2005. 2658 [Hirschman] 2659 Hirschman, L. and R. Gaizauskas, "Natural Language 2660 Question Answering: The View from Here", Natural Language 2661 Engineering 7:4, pgs 275-300, Cambridge University Press , 2662 November 2001. 2664 [Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns", 2665 ISBN 0-32-120068-3 , 2003. 2667 [Martin] Martin, R.C., "Agile Software Development, Principles, 2668 Patterns, and Practices", Prentice-Hall , ISBN: 2669 0-13-597444-5 , 2002. 2671 [OODMP] "http://www.oodesign.com/mediator-pattern.html". 2673 [OODOP] "http://www.oodesign.com/mediator-pattern.html". 2675 [OODSRP] "http://www.oodesign.com/mediator-pattern.html". 2677 Appendix A. Configuration Examples 2679 This section shows configuration examples of "ietf-i2nsf-capability" 2680 module for capabilities registration of general firewall. 2682 A.1. Example 1: Registration for the Capabilities of a General Firewall 2684 This section shows a configuration example for the capabilities 2685 registration of a general firewall in either an IPv4 network or an 2686 IPv6 network. 2688 2689 general_firewall 2690 2691 2692 next-header 2693 flow-direction 2694 source-address 2695 destination-address 2696 source-port-number 2697 destination-port-number 2698 source-port-number 2699 destination-port-number 2700 2701 2702 2703 pass 2704 drop 2705 mirror 2706 pass 2707 drop 2708 mirror 2709 2710 2712 Figure 4: Configuration XML for the Capabilities Registration of 2713 a General Firewall in an IPv4 Network 2715 Figure 4 shows the configuration XML for the capabilities 2716 registration of a general firewall as an NSF in an IPv4 network. Its 2717 capabilities are as follows. 2719 1. The name of the NSF is general_firewall. 2721 2. The NSF can inspect the IPv4 protocol header field, flow 2722 direction, source address(es), and destination address(es) 2724 3. The NSF can inspect the port number(s) and flow direction for the 2725 transport layer protocol, i.e., TCP and UDP. 2727 4. The NSF can control whether the packets are allowed to pass, 2728 drop, or mirror. 2730 2731 general_firewall 2732 2733 2734 next-header 2735 flow-direction 2736 source-address 2737 destination-address 2738 source-port-number 2739 destination-port-number 2740 source-port-number 2741 destination-port-number 2742 2743 2744 2745 pass 2746 drop 2747 mirror 2748 pass 2749 drop 2750 mirror 2751 2752 2754 Figure 5: Configuration XML for the Capabilities Registration of 2755 a General Firewall in an IPv6 Network 2757 In addition, Figure 5 shows the configuration XML for the 2758 capabilities registration of a general firewall as an NSF in an IPv6 2759 network. Its capabilities are as follows. 2761 1. The name of the NSF is general_firewall. 2763 2. The NSF can inspect IPv6 next header, flow direction, source 2764 address(es), and destination address(es) 2766 3. The NSF can inspect the port number(s) and flow direction for the 2767 transport layer protocol, i.e., TCP and UDP. 2769 4. The NSF can control whether the packets are allowed to pass, 2770 drop, or mirror. 2772 A.2. Example 2: Registration for the Capabilities of a Time-based 2773 Firewall 2775 This section shows a configuration example for the capabilities 2776 registration of a time-based firewall in either an IPv4 network or an 2777 IPv6 network. 2779 2780 time_based_firewall 2781 2782 absolute-time 2783 periodic-time 2784 2785 2786 2787 next-header 2788 flow-direction 2789 source-address 2790 destination-address 2791 2792 2793 2794 pass 2795 drop 2796 mirror 2797 pass 2798 drop 2799 mirror 2800 2801 2803 Figure 6: Configuration XML for the Capabilities Registration of 2804 a Time-based Firewall in an IPv4 Network 2806 Figure 6 shows the configuration XML for the capabilities 2807 registration of a time-based firewall as an NSF in an IPv4 network. 2808 Its capabilities are as follows. 2810 1. The name of the NSF is time_based_firewall. 2812 2. The NSF can execute the security policy rule according to 2813 absolute time and periodic time. 2815 3. The NSF can inspect the IPv4 protocol header field, flow 2816 direction, source address(es), and destination address(es). 2818 4. The NSF can control whether the packets are allowed to pass, 2819 drop, or mirror. 2821 2822 time_based_firewall 2823 2824 absolute-time 2825 periodic-time 2826 2827 2828 2829 next-header 2830 flow-direction 2831 source-address 2832 destination-address 2833 2834 2835 2836 pass 2837 drop 2838 mirror 2839 pass 2840 drop 2841 mirror 2842 2843 2845 Figure 7: Configuration XML for the Capabilities Registration of 2846 a Time-based Firewall in an IPv6 Network 2848 In addition, Figure 7 shows the configuration XML for the 2849 capabilities registration of a time-based firewall as an NSF in an 2850 IPv6 network. Its capabilities are as follows. 2852 1. The name of the NSF is time_based_firewall. 2854 2. The NSF can execute the security policy rule according to 2855 absolute time and periodic time. 2857 3. The NSF can inspect the IPv6 protocol header field, flow 2858 direction, source address(es), and destination address(es). 2860 4. The NSF can control whether the packets are allowed to pass, 2861 drop, or mirror. 2863 A.3. Example 3: Registration for the Capabilities of a Web Filter 2865 This section shows a configuration example for the capabilities 2866 registration of a web filter. 2868 2869 web_filter 2870 2871 2872 user-defined 2873 2874 2875 2876 pass 2877 drop 2878 mirror 2879 pass 2880 drop 2881 mirror 2882 2883 2885 Figure 8: Configuration XML for the Capabilities Registration of 2886 a Web Filter 2888 Figure 8 shows the configuration XML for the capabilities 2889 registration of a web filter as an NSF. Its capabilities are as 2890 follows. 2892 1. The name of the NSF is web_filter. 2894 2. The NSF can inspect a URL matched from a user-defined URL. User 2895 can specify their own URL. 2897 3. The NSF can control whether the packets are allowed to pass, 2898 drop, or mirror. 2900 A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE 2901 Filter 2903 This section shows a configuration example for the capabilities 2904 registration of a VoIP/VoLTE filter. 2906 2907 voip_volte_filter 2908 2909 2910 2911 call-id 2912 2913 2914 2915 2916 pass 2917 drop 2918 mirror 2919 pass 2920 drop 2921 mirror 2922 2923 2925 Figure 9: Configuration XML for the Capabilities Registration of 2926 a VoIP/VoLTE Filter 2928 Figure 9 shows the configuration XML for the capabilities 2929 registration of a VoIP/VoLTE filter as an NSF. Its capabilities are 2930 as follows. 2932 1. The name of the NSF is voip_volte_filter. 2934 2. The NSF can inspect a voice call id for VoIP/VoLTE packets. 2936 3. The NSF can control whether the packets are allowed to pass, 2937 drop, or mirror. 2939 A.5. Example 5: Registration for the Capabilities of a HTTP and HTTPS 2940 Flood Mitigator 2942 This section shows a configuration example for the capabilities 2943 registration of a HTTP and HTTPS flood mitigator. 2945 2946 DDoS_mitigator 2947 2948 2949 packet-rate 2950 byte-rate 2951 flow-rate 2952 2953 2954 2955 pass 2956 drop 2957 mirror 2958 pass 2959 drop 2960 mirror 2961 2962 2964 Figure 10: Configuration XML for the Capabilities Registration of 2965 a HTTP and HTTPS Flood Mitigator 2967 Figure 10 shows the configuration XML for the capabilities 2968 registration of a HTTP and HTTPS flood mitigator as an NSF. Its 2969 capabilities are as follows. 2971 1. The name of the NSF is DDoS_mitigator. 2973 2. The NSF can detect the amount of packet, flow, and byte rate in 2974 the network for potential DDoS Attack. 2976 3. The NSF can control whether the packets are allowed to pass, 2977 drop, or mirror. 2979 Appendix B. Acknowledgments 2981 This work was supported by Institute of Information & Communications 2982 Technology Planning & Evaluation (IITP) grant funded by the Korea 2983 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 2984 Security Intelligence Technology Development for the Customized 2985 Security Service Provisioning). This work was supported in part by 2986 the IITP grant funded by the MSIT (2020-0-00395, Standard Development 2987 of Blockchain based Network Management Automation Technology). 2989 Appendix C. Contributors 2991 This document is made by the group effort of I2NSF working group. 2992 Many people actively contributed to this document, such as Acee 2993 Lindem, Roman Danyliw, and Tom Petch. The authors sincerely 2994 appreciate their contributions. 2996 The following are co-authors of this document: 2998 Patrick Lingga Department of Electrical and Computer Engineering 2999 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 3000 16419 Republic of Korea EMail: patricklink@skku.edu 3002 Liang Xia Huawei 101 Software Avenue Nanjing, Jiangsu 210012 China 3003 EMail: Frank.Xialiang@huawei.com 3005 Cataldo Basile Politecnico di Torino Corso Duca degli Abruzzi, 34 3006 Torino, 10129 Italy EMail: cataldo.basile@polito.it 3008 John Strassner Huawei 2330 Central Expressway Santa Clara, CA 95050 3009 USA EMail: John.sc.Strassner@huawei.com 3011 Diego R. Lopez Telefonica I+D Zurbaran, 12 Madrid, 28010 Spain 3012 Email: diego.r.lopez@telefonica.com 3014 Hyoungshick Kim Department of Computer Science and Engineering 3015 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 3016 16419 Republic of Korea EMail: hyoung@skku.edu 3018 Daeyoung Hyun Department of Computer Science and Engineering 3019 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 3020 16419 Republic of Korea EMail: dyhyun@skku.edu 3022 Dongjin Hong Department of Electronic, Electrical and Computer 3023 Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, 3024 Gyeonggi-do 16419 Republic of Korea EMail: dong.jin@skku.edu 3026 Jung-Soo Park Electronics and Telecommunications Research Institute 3027 218 Gajeong-Ro, Yuseong-Gu Daejeon, 34129 Republic of Korea EMail: 3028 pjs@etri.re.kr 3030 Tae-Jin Ahn Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 3031 Republic of Korea EMail: taejin.ahn@kt.com 3033 Se-Hui Lee Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 3034 Republic of Korea EMail: sehuilee@kt.com 3036 Authors' Addresses 3038 Susan Hares (editor) 3039 Huawei 3040 7453 Hickory Hill 3041 Saline, MI 48176 3042 United States of America 3044 Phone: +1-734-604-0332 3045 Email: shares@ndzh.com 3047 Jaehoon (Paul) Jeong (editor) 3048 Department of Computer Science and Engineering 3049 Sungkyunkwan University 3050 2066 Seobu-Ro, Jangan-Gu 3051 Suwon 3052 Gyeonggi-Do 3053 16419 3054 Republic of Korea 3056 Phone: +82 31 299 4957 3057 Email: pauljeong@skku.edu 3058 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3060 Jinyong (Tim) Kim 3061 Department of Electronic, Electrical and Computer Engineering 3062 Sungkyunkwan University 3063 2066 Seobu-Ro, Jangan-Gu 3064 Suwon 3065 Gyeonggi-Do 3066 16419 3067 Republic of Korea 3069 Phone: +82 10 8273 0930 3070 Email: timkim@skku.edu 3072 Robert Moskowitz 3073 HTT Consulting 3074 Oak Park, MI 3075 United States of America 3077 Phone: +1-248-968-9809 3078 Email: rgm@htt-consult.com 3079 Qiushi Lin 3080 Huawei 3081 Huawei Industrial Base 3082 Shenzhen 3083 Guangdong 518129, 3084 China 3086 Email: linqiushi@huawei.com