idnits 2.17.1 draft-ietf-i2nsf-capability-data-model-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 January 2022) is 813 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) ** Downref: Normative reference to an Informational RFC: RFC 4766 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 8329 ** Downref: Normative reference to an Informational RFC: RFC 8805 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-rfc793bis-25 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-tcpm-rfc793bis' == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-15 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-13 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-12 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-16 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-13 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group S. Hares, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track J. Jeong, Ed. 5 Expires: 1 August 2022 J. Kim 6 Sungkyunkwan University 7 R. Moskowitz 8 HTT Consulting 9 Q. Lin 10 Huawei 11 28 January 2022 13 I2NSF Capability YANG Data Model 14 draft-ietf-i2nsf-capability-data-model-23 16 Abstract 18 This document defines an information model and the corresponding YANG 19 data model for the capabilities of various Network Security Functions 20 (NSFs) in the Interface to Network Security Functions (I2NSF) 21 framework to centrally manage the capabilities of the various NSFs. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 1 August 2022. 40 Copyright Notice 42 Copyright (c) 2022 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 Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . 50 66 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 50 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 52 70 10.2. Informative References . . . . . . . . . . . . . . . . . 57 71 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 58 72 A.1. Example 1: Registration for the Capabilities of a General 73 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 59 74 A.2. Example 2: Registration for the Capabilities of a 75 Time-based Firewall . . . . . . . . . . . . . . . . . . . 60 76 A.3. Example 3: Registration for the Capabilities of a Web 77 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 62 78 A.4. Example 4: Registration for the Capabilities of a VoIP/ 79 VoLTE Filter . . . . . . . . . . . . . . . . . . . . . . 63 80 A.5. Example 5: Registration for the Capabilities of a HTTP and 81 HTTPS Flood Mitigator . . . . . . . . . . . . . . . . . . 64 82 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 65 83 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 66 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 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 forms the basis of the NSF 114 Monitoring Interface YANG data model 115 [I-D.ietf-i2nsf-nsf-monitoring-data-model] and the NSF-Facing 116 Interface YANG data model [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 118 This document provides an information model and the corresponding 119 YANG data model [RFC6020][RFC7950] that defines the capabilities of 120 NSFs to centrally manage the capabilities of those NSFs. The NSFs 121 can register their own capabilities into a Network Operator 122 Management (Mgmt) System (i.e., Security Controller) with this YANG 123 data model through the registration interface [RFC8329]. With the 124 database of the capabilities of those NSFs that are maintained 125 centrally, those NSFs can be more easily managed [RFC8329]. 127 This YANG data model uses an "Event-Condition-Action" (ECA) policy 128 model that is used as the basis for the design of I2NSF Policy as 129 described in [RFC8329] and Section 3.1. The "ietf-i2nsf-capability" 130 YANG module defined in this document provides the following features: 132 * Definition for event capabilities of network security functions. 134 * Definition for condition capabilities of network security 135 functions. 137 * Definition for action capabilities of network security functions. 139 * Definition for resolution strategy capabilities of network 140 security functions. 142 * Definition for default action capabilities of network security 143 functions. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 This document uses the terminology described in [RFC8329]. 155 This document follows the guidelines of [RFC8407], uses the common 156 YANG types defined in [RFC6991], and adopts the Network Management 157 Datastore Architecture (NMDA). The meaning of the symbols in tree 158 diagrams is defined in [RFC8340]. 160 3. Information Model of I2NSF NSF Capability 162 This section provides the I2NSF Capability Information Model (CapIM). 163 A CapIM is a formalization of the functionality that an NSF 164 advertises. This enables the precise specification of what an NSF 165 can do in terms of security policy enforcement, so that computer- 166 based tasks can unambiguously refer to, use, configure, and manage 167 NSFs. Capabilities are defined in a vendor- and technology- 168 independent manner (i.e., regardless of the differences among vendors 169 and individual products). 171 Network security experts can refer to categories of security controls 172 and understand each other. For instance, network security experts 173 agree on what is meant by the terms "NAT", "filtering", and "VPN 174 concentrator". As a further example, network security experts 175 unequivocally refer to "packet filters" as devices that allow or deny 176 packet forwarding based on various conditions (e.g., source and 177 destination IP addresses, source and destination ports, and IP 178 protocol type 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. Network engineers deal with these differences by 185 asking more questions to determine the specific category and 186 functionality of the device. Machines can follow a similar approach, 187 which is commonly referred to as question-answering [Hirschman]. In 188 this context, the CapIM and the derived data model can provide 189 important 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 (e.g., events, conditions, 220 and actions) SHOULD be an independent function, with minimum 221 overlap or dependency on other capabilities. This enables each 222 security capability to be utilized and assembled with other 223 security capabilities together freely. More importantly, changes 224 to one capability SHOULD NOT affect other capabilities. This 225 follows the Single Responsibility Principle [Martin] [OODSRP]. 227 * Abstraction: Each capability MUST be defined in a vendor- 228 independent manner. 230 * Advertisement: Registration Interface 231 [I-D.ietf-i2nsf-registration-interface-dm] MUST be used to 232 advertise and register the capabilities of each NSF. This same 233 interface MUST be used by other I2NSF Components to determine what 234 Capabilities are currently available to them. 236 * Execution: NSF-Facing Interface 237 [I-D.ietf-i2nsf-nsf-facing-interface-dm] and NSF Monitoring 238 Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] MUST be used 239 to configure the use of a capability into an NSF and monitor the 240 NSF, respectively. These provide a standardized ability to 241 describe its functionality, and report its processing results, 242 respectively. These facilitate multi-vendor interoperability. 244 * Automation: The system MUST have the ability to auto-discover, 245 auto-negotiate, and auto-update its security capabilities (i.e., 246 without human intervention). These features are especially useful 247 for the management of a large number of NSFs. They are essential 248 for adding smart services (e.g., refinement, analysis, capability 249 reasoning, and optimization) to the security scheme employed. 250 These features are supported by many design patterns, including 251 the Observer Pattern [OODOP], the Mediator Pattern [OODMP], and a 252 set of Message Exchange Patterns [Hohpe]. Registration Interface 253 [I-D.ietf-i2nsf-registration-interface-dm] can register the 254 capabilities of NSFs with the security controller from the request 255 of Developer's Management System providing NSFs and the 256 corresponding security capabilities. Also, this interface can 257 send a query to Developer's Management System in order to find an 258 NSF to satisfy the requested security capability from the security 259 controller that receives a security policy. 261 * Scalability: The management system SHOULD have the capability to 262 scale up/down or scale in/out. Thus, it can meet various 263 performance requirements derived from changeable network traffic 264 or service requests. In addition, security capabilities that are 265 affected by scalability changes SHOULD support reporting 266 statistics to the security controller to assist its decision on 267 whether it needs to invoke scaling or not. NSF Monitoring 268 Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] can observe 269 the performance of NSFs to let the security controller decide 270 scalability changes of the NSFs. 272 Based on the above principles, this document defines a capability 273 model that enables an NSF to register (and hence advertise) its set 274 of capabilities that other I2NSF Components can use. These 275 capabilities MUST have their access control restricted by a policy; 276 this is out of scope for this document. The set of capabilities 277 provided by a given set of NSFs unambiguously defines the security 278 services offered by the set of NSFs used. The security controller 279 can compare the requirements of users and applications with the set 280 of capabilities that are currently available in order to choose which 281 capabilities of which NSFs are needed to meet those requirements. 282 Note that this choice is independent of vendor, and instead relies 283 specifically on the capabilities (i.e., the description) of the 284 functions provided. 286 Furthermore, NSFs are subject to the updates of security capabilities 287 and software to cope with newly found security attacks or threats, 288 hence new capabilities may be created, and/or existing capabilities 289 may be updated (e.g., by updating its signature and algorithm). New 290 capabilities may be sent to and stored in a centralized repository, 291 or stored separately in a vendor's local repository. In either case, 292 Registration Interface can facilitate this update process to 293 Developer's Management System to let the security controller update 294 its repository for NSFs and their security capabilities. 296 The "Event-Condition-Action" (ECA) policy model in [RFC8329] is used 297 as the basis for the design of the capability model; The following 298 three terms define the structure and behavior of an I2NSF imperative 299 policy rule: 301 * Event: An Event is defined as any important occurrence in time of 302 a change in the system being managed, and/or in the environment of 303 the system being managed. When used in the context of I2NSF 304 Policy Rules, it is used to determine whether the condition clause 305 of an I2NSF Policy Rule can be evaluated or not. Examples of an 306 I2NSF Event include time and user actions (e.g., logon, logoff, 307 and actions that violate an ACL). 309 * Condition: A condition is defined as a set of attributes, 310 features, and/or values that are to be compared with a set of 311 known attributes, features, and/or values in order to determine 312 whether or not the set of actions in that (imperative) I2NSF 313 Policy Rule can be executed or not. Examples of I2NSF conditions 314 include matching attributes of a packet or flow, and comparing the 315 internal state of an NSF with a desired state. 317 * Action: An action is used to control and monitor aspects of NSFs 318 to handle packets or flows when the event and condition clauses 319 are satisfied. NSFs provide security functions by executing 320 various Actions. Examples of I2NSF actions include providing 321 intrusion detection and/or protection, web filtering (i.e., URL 322 filtering) and flow filtering, and deep packet inspection for 323 packets and flows. 325 An I2NSF Policy Rule is made up of three clauses: an Event clause, a 326 Condition clause, and an Action clause. This structure is also 327 called an ECA (Event-Condition-Action) Policy Rule. A Boolean clause 328 is a logical statement that evaluates to either TRUE or FALSE. It 329 may be made up of one or more terms; if more than one term is 330 present, then each term in the Boolean clause is combined using 331 logical connectives (i.e., AND, OR, and NOT). 333 An I2NSF ECA Policy Rule has the following semantics: 335 IF is TRUE 337 IF is TRUE 339 THEN execute [constrained by metadata] 341 END-IF 343 END-IF 345 Technically, the "Policy Rule" is really a container that aggregates 346 the above three clauses, as well as metadata, which describe the 347 characteristics and behaviors of a capability (or an NSF). 348 Aggregating metadata enables a business logic to be used to prescribe 349 a behavior. For example, suppose a particular ECA Policy Rule 350 contains three actions (A1, A2, and A3, in that order). Action A2 351 has a priority of 10; actions A1 and A3 have no priority specified. 352 Then, metadata may be used to restrict the set of actions that can be 353 executed when the event and condition clauses of this ECA Policy Rule 354 are evaluated to be TRUE; two examples are: (1) only the first action 355 (A1) is executed, and then the policy rule returns to its caller, or 356 (2) all actions are executed, starting with the highest priority. 358 The above ECA policy model is very general and easily extensible. 360 For example, when an NSF has both url filtering capability and packet 361 filtering capability for protocol headers, it means that it can match 362 the URL as well as the Ethernet header, IP header, and Transport 363 header for packet filtering. The condition capability for url 364 filtering and packet filtering is not tightly linked to the action 365 capability due to the independence of our ECA design principle. The 366 action capability only lists the type of action that the NSF can take 367 to handle the matched packets. 369 3.2. Conflict, Resolution Strategy and Default Action 371 Formally, two I2NSF Policy Rules conflict with each other if: 373 * the Event Clauses of each evaluate to TRUE; 375 * the Condition Clauses of each evaluate to TRUE; 377 * the Action Clauses affect the same object in different ways. 379 For example, if we have two Policy Rules called R1 and R2 in the same 380 Policy: 382 R1: During 8am-6pm, if traffic is external, then run through 383 firewall 385 R2: During 7am-8pm, run anti-virus 387 There is no conflict between the two policy rules R1 and R2, since 388 the actions are different. However, consider these two rules called 389 R3 and R4: 391 R3: During 9am-6pm, allow John to access social networking service 392 websites 394 R4: During 9am-6pm, disallow all users to access social networking 395 service websites 397 The two policy rules R3 and R4 are now in conflict, between the hours 398 of 9am and 6pm, because the actions of R3 and R4 are different and 399 apply to the same user (i.e., John). 401 Conflicts theoretically compromise the correct functioning of 402 devices. However, NSFs have been designed to cope with these issues. 403 Since conflicts are originated by simultaneously matching rules, an 404 additional process decides the action to be applied, e.g., among the 405 actions which the matching rule would have enforced. This process is 406 described by means of a resolution strategy for conflicts. The 407 finding and handling of conflicted matching rules is performed by 408 resolution strategies in the security controller. The implementation 409 of such resolution strategies is out of scope for I2NSF. 411 On the other hand, it may happen that, if an event is caught, none of 412 the policy rules matches the condition. Note that a packet or flow 413 is handled only when it matches both the event and condition of a 414 policy rule according to the ECA policy model. As a simple case, no 415 condition in the rules may match a packet arriving at the border 416 firewall. In this case, the packet is usually dropped, that is, the 417 firewall has a default behavior of packet dropping in order to manage 418 the cases that are not covered by specific rules. 420 Therefore, this document introduces two further capabilities for an 421 NSF to handle security policy conflicts with resolution strategies 422 and enforce a default action if no rules match. 424 * Resolution Strategies: They can be used to specify how to resolve 425 conflicts that occur between the actions of the same or different 426 policy rules that are matched and contained in this particular 427 NSF; 429 * Default Action: It provides the default behavior to be executed 430 when there are no other alternatives. This action can be either 431 an explicit action or a set of actions. 433 4. Overview of YANG Data Model 435 This section provides an overview of how the YANG data model can be 436 used in the I2NSF framework described in [RFC8329]. Figure 1 shows 437 the capabilities (e.g., firewall and web filter) of NSFs in the I2NSF 438 Framework. As shown in this figure, a Developer's Management System 439 (DMS) can register NSFs and their capabilities with a Security 440 Controller. To register NSFs in this way, the DMS utilizes the 441 standardized capability YANG data model in this document through the 442 I2NSF Registration Interface [RFC8329]. That is, this Registration 443 Interface uses the YANG module described in this document to describe 444 the capabilities of an NSF that is registered with the Security 445 Controller. As described in [RFC8192], with the usage of 446 Registration Interface and the YANG module in this document, the NSFs 447 manufactured by multiple vendors can be managed together by the 448 Security Controller in a centralized way and be updated dynamically 449 by each vendor as the NSF has software or hardware updates. 451 In Figure 1, a new NSF at a Developer's Management System has 452 capabilities of Firewall (FW) and Web Filter (WF), which are denoted 453 as (Cap = {FW, WF}), to support Event-Condition-Action (ECA) policy 454 rules where 'E', 'C', and 'A' mean "Event", "Condition", and 455 "Action", respectively. The condition involves IPv4 or IPv6 456 datagrams, and the action includes "Allow" and "Deny" for those 457 datagrams. 459 Note that the NSF-Facing Interface [RFC8329] is used by the Security 460 Controller to configure the security policy rules of NSFs (e.g., 461 firewall and Distributed-Denial-of-Service (DDoS) attack mitigator) 462 with the capabilities of the NSFs registered with the Security 463 Controller. 465 +------------------------------------------------------+ 466 | I2NSF User (e.g., Overlay Network Mgmt, Enterprise | 467 | Network Mgmt, another network domain's mgmt, etc.) | 468 +--------------------+---------------------------------+ 469 I2NSF ^ 470 Consumer-Facing Interface | 471 | 472 v I2NSF 473 +-----------------+------------+ Registration +-------------+ 474 | Network Operator Mgmt System | Interface | Developer's | 475 | (i.e., Security Controller) |<------------->| Mgmt System | 476 +-----------------+------------+ +-------------+ 477 ^ New NSF 478 | Cap = {FW, WF} 479 I2NSF | E = {} 480 NSF-Facing Interface | C = {IPv4, IPv6} 481 | A = {Allow, Deny} 482 v 483 +---------------+----+------------+-----------------+ 484 | | | | 485 +---+---+ +---+---+ +---+---+ +---+---+ 486 | NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-n | 487 +-------+ +-------+ +-------+ +-------+ 488 NSF-1 NSF-m NSF-1 NSF-n 489 Cap = {FW, WF} Cap = {FW, WF} Cap = {FW, WF} Cap = {FW, WF} 490 E = {} E = {user} E = {dev} E = {time} 491 C = {IPv4} C = {IPv6} C = {IPv4, IPv6} C = {IPv4} 492 A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} 494 Developer's Mgmt System A Developer's Mgmt System B 496 Figure 1: Capabilities of NSFs in I2NSF Framework 498 A use case of an NSF with the capabilities of firewall and web filter 499 is described as follows. 501 * If a network administrator wants to apply security policy rules to 502 block malicious users with firewall and web filter, it is a 503 tremendous burden for a network administrator to apply all of the 504 needed rules to NSFs one by one. This problem can be resolved by 505 managing the capabilities of NSFs as described in this document. 507 * If a network administrator wants to block IPv4 or IPv6 packets 508 from malicious users, the network administrator sends a security 509 policy rule to block the users to the Network Operator Management 510 System (i.e., Security Controller) using the I2NSF Consumer-Facing 511 Interface. 513 * When the Network Operator Management System receives the security 514 policy rule, it automatically sends that security policy rule to 515 appropriate NSFs (i.e., NSF-m in Developer's Management System A 516 and NSF-1 in Developer's Management System B) which can support 517 the capabilities (i.e., IPv6). This lets an I2NSF User not 518 consider which specific NSF(s) will work for the security policy 519 rule. 521 * If NSFs encounter the suspicious IPv4 or IPv6 packets of malicious 522 users, they can filter the packets out according to the configured 523 security policy rule. Therefore, the security policy rule against 524 the malicious users' packets can be automatically applied to 525 appropriate NSFs without human intervention. 527 5. YANG Tree Diagram 529 This section shows a YANG tree diagram of capabilities of network 530 security functions, as defined in the Section 3. 532 5.1. Network Security Function (NSF) Capabilities 534 This section explains a YANG tree diagram of NSF capabilities and its 535 features. Figure 2 shows a YANG tree diagram of NSF capabilities. 536 The NSF capabilities in the tree include time capabilities, event 537 capabilities, condition capabilities, action capabilities, resolution 538 strategy capabilities, and default action capabilities. Those 539 capabilities can be tailored or extended according to a vendor's 540 specific requirements. Refer to the NSF capabilities information 541 model for detailed discussion in Section 3. 543 module: ietf-i2nsf-capability 544 +--rw nsf* [nsf-name] 545 +--rw nsf-name string 546 +--rw directional-capabilities* identityref 547 +--rw event-capabilities 548 | +--rw system-event-capability* identityref 549 | +--rw system-alarm-capability* identityref 550 | +--rw time-capabilities* identityref 551 +--rw condition-capabilities 552 | +--rw generic-nsf-capabilities 553 | | +--rw ethernet-capability* identityref 554 | | +--rw ipv4-capability* identityref 555 | | +--rw ipv6-capability* identityref 556 | | +--rw icmpv4-capability* identityref 557 | | +--rw icmpv6-capability* identityref 558 | | +--rw tcp-capability* identityref 559 | | +--rw udp-capability* identityref 560 | | +--rw sctp-capability* identityref 561 | | +--rw dccp-capability* identityref 562 | +--rw advanced-nsf-capabilities 563 | | +--rw anti-ddos-capability* identityref 564 | | +--rw ips-capability* identityref 565 | | +--rw anti-virus-capability* identityref 566 | | +--rw url-filtering-capability* identityref 567 | | +--rw voip-volte-filtering-capability* identityref 568 | +--rw context-capabilities 569 | +--rw application-filter-capabilities* identityref 570 | +--rw device-type-capabilities* identityref 571 | +--rw user-condition-capabilities* identityref 572 | +--rw geographic-capabilities* identityref 573 +--rw action-capabilities 574 | +--rw ingress-action-capability* identityref 575 | +--rw egress-action-capability* identityref 576 | +--rw log-action-capability* identityref 577 +--rw resolution-strategy-capabilities* identityref 578 +--rw default-action-capabilities* identityref 580 Figure 2: YANG Tree Diagram of Capabilities of Network Security 581 Functions 583 The data model in this document provides identities for the 584 capabilities of NSFs. Every identity in the data model represents 585 the capability of an NSF. Each identity is explained in the 586 description of the identity. 588 Event capabilities are used to specify the capabilities that describe 589 an event that would trigger the evaluation of the condition clause of 590 the I2NSF Policy Rule. The defined event capabilities are system 591 event, system alarm, and time. Time capabilities are used to specify 592 the capabilities which describe when to execute the I2NSF policy 593 rule. The time capabilities are defined in terms of absolute time 594 and periodic time. The absolute time means the exact time to start 595 or end. The periodic time means repeated time like day, week, month, 596 or year. 598 Condition capabilities are used to specify capabilities of a set of 599 attributes, features, and/or values that are to be compared with a 600 set of known attributes, features, and/or values in order to 601 determine whether a set of actions needs to be executed or not so 602 that an imperative I2NSF policy rule can be executed. In this 603 document, two kinds of condition capabilities are used to classify 604 different capabilities of NSFs such as generic-nsf-capabilities and 605 advanced-nsf-capabilities. First, the generic-nsf-capabilities 606 define NSFs that operate on packet header for layer 2 (i.e., Ethernet 607 capability), layer 3 (i.e., IPv4 capability, IPv6 capability, ICMPv4 608 capability, and ICMPv6 capability.), and layer 4 (i.e., TCP 609 capability, UDP capability, SCTP capability, and DCCP capability). 610 Second, the advanced-nsf-capabilities define NSFs that operate on 611 features different from the generic-nsf-capabilities, e.g., the 612 payload, cross flow state, application layer, traffic statistics, 613 network behavior, etc. This document defines the advanced-nsf into 614 two categories such as content-security-control and attack- 615 mitigation-control. 617 * Content security control is an NSF that evaluates the payload of a 618 packet, such as Intrusion Prevention System (IPS), URL-Filtering, 619 Antivirus, and VoIP/VoLTE Filter. 621 * Attack mitigation control is an NSF that mitigates an attack such 622 as anti-DDoS (DDoS-mitigator). 624 The advanced-nsf can be extended with other types of NSFs. This 625 document only provides five advanced-nsf capabilities, i.e., IPS 626 capability, URL-Filtering capability, Antivirus capability, VoIP/ 627 VoLTE Filter capability, and Anti-DDoS capability. Note that VoIP 628 and VoLTE are merged into a single capability in this document 629 because VoIP and VoLTE use the Session Initiation Protocol (SIP) 630 [RFC3261] for a call setup. See Section 3.1 for more information 631 about the condition in the ECA policy model. 633 The context capabilities provide extra information for the condition. 634 The given context conditions are application filter, target, user 635 condition, and geographic location. The application filter 636 capability is capability in matching the packet based on the 637 application protocol, such as HTTP, HTTPS, FTP, etc. The device type 638 capability is capability in matching the type of the destination 639 devices, such as PC, IoT, Network Infrastructure devices, etc. The 640 user condition is capability in matching the users of the network by 641 mapping each user ID to an IP address. Users can be combined into 642 one group. The geographic location capability is capability in 643 matching the geographical location of a source or destination of a 644 packet. 646 Action capabilities are used to specify the capabilities that 647 describe the control and monitoring aspects of flow-based NSFs when 648 the event and condition clauses are satisfied. The action 649 capabilities are defined as ingress-action capability, egress-action 650 capability, and log-action capability. See Section 3.1 for more 651 information about the action in the ECA policy model. Also, see 652 Section 7.2 (NSF-Facing Flow Security Policy Structure) in [RFC8329] 653 for more information about the ingress and egress actions. In 654 addition, see Section 9.1 (Flow-Based NSF Capability 655 Characterization) in [RFC8329] and Section 7.5 (NSF Logs) in 656 [I-D.ietf-i2nsf-nsf-monitoring-data-model] for more information about 657 logging at NSFs. 659 Resolution strategy capabilities are used to specify the capabilities 660 that describe conflicts that occur between the actions of the same or 661 different policy rules that are matched and contained in this 662 particular NSF. The resolution strategy capabilities are defined as 663 First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized 664 Matching Rule (PMR), Prioritized Matching Rule with Errors (PMRE), 665 and Prioritized Matching Rule with No Errors (PMRN). See Section 3.2 666 for more information about the resolution strategy. 668 Default action capabilities are used to specify the capabilities that 669 describe how to execute I2NSF policy rules when no rule matches a 670 packet. The default action capabilities are defined as pass, drop, 671 reject, rate-limit, and mirror. See Section 3.2 for more information 672 about the default action. 674 6. YANG Data Model of I2NSF NSF Capability 676 This section introduces a YANG module for NSFs' capabilities, as 677 defined in the Section 3. 679 It makes references to 681 * [RFC0768] 683 * [RFC0791] 684 * [RFC0792] 686 * [RFC0854] 688 * [RFC0959] 690 * [RFC1939] 692 * [RFC2474] 694 * [RFC2818] 696 * [RFC3168] 698 * [RFC3261] 700 * [RFC9051] 702 * [RFC4250] 704 * [RFC4340] 706 * [RFC4443] 708 * [RFC4766] 710 * [RFC4960] 712 * [RFC5103] 714 * [RFC5321] 716 * [RFC5595] 718 * [RFC6335] 720 * [RFC6437] 722 * [RFC6691] 724 * [RFC6864] 726 * [RFC7230] 728 * [RFC7231] 730 * [RFC7323] 731 * [RFC8200] 733 * [RFC8329] 735 * [RFC8805] 737 * [IEEE802.3-2018] 739 * [IANA-Protocol-Numbers] 741 * [I-D.ietf-tcpm-rfc793bis] 743 * [I-D.ietf-tcpm-accurate-ecn] 745 * [I-D.ietf-tsvwg-udp-options] 747 * [I-D.ietf-i2nsf-nsf-monitoring-data-model] 749 file "ietf-i2nsf-capability@2022-01-28.yang" 750 module ietf-i2nsf-capability { 751 yang-version 1.1; 752 namespace 753 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; 754 prefix 755 nsfcap; 757 organization 758 "IETF I2NSF (Interface to Network Security Functions) 759 Working Group"; 761 contact 762 "WG Web: 763 WG List: 765 Editor: Susan Hares 766 768 Editor: Jaehoon (Paul) Jeong 769 771 Editor: Jinyong (Tim) Kim 772 774 Editor: Robert Moskowitz 775 777 Editor: Qiushi Lin 778 779 Editor: Patrick Lingga 780 "; 782 description 783 "This module is a YANG module for I2NSF Network Security 784 Functions (NSFs)'s Capabilities. 786 Copyright (c) 2022 IETF Trust and the persons identified as 787 authors of the code. All rights reserved. 789 Redistribution and use in source and binary forms, with or 790 without modification, is permitted pursuant to, and subject to 791 the license terms contained in, the Simplified BSD License set 792 forth in Section 4.c of the IETF Trust's Legal Provisions 793 Relating to IETF Documents 794 (https://trustee.ietf.org/license-info). 796 This version of this YANG module is part of RFC XXXX 797 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 798 for full legal notices."; 800 // RFC Ed.: replace XXXX with an actual RFC number and remove 801 // this note. 803 revision "2022-01-28"{ 804 description "Initial revision."; 805 reference 806 "RFC XXXX: I2NSF Capability YANG Data Model"; 808 // RFC Ed.: replace XXXX with an actual RFC number and remove 809 // this note. 810 } 812 /* 813 * Identities 814 */ 816 identity event { 817 description 818 "Base identity for I2NSF events."; 819 reference 820 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 821 Monitoring YANG Data Model - Event"; 822 } 824 identity system-event { 825 base event; 826 description 827 "Identity for system event"; 828 reference 829 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 830 Monitoring YANG Data Model - System event"; 831 } 833 identity system-alarm { 834 base event; 835 description 836 "Identity for system alarm"; 837 reference 838 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 839 Monitoring YANG Data Model - System alarm"; 840 } 842 identity time { 843 base event; 844 description 845 "Identity for time capabilities"; 846 } 848 identity access-violation { 849 base system-event; 850 description 851 "Identity for access violation event"; 852 reference 853 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 854 Monitoring YANG Data Model - System event for access 855 violation"; 856 } 858 identity configuration-change { 859 base system-event; 860 description 861 "Identity for configuration change event"; 862 reference 863 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 864 Monitoring YANG Data Model - System event for configuration 865 change"; 866 } 868 identity memory-alarm { 869 base system-alarm; 870 description 871 "Identity for memory alarm. Alarm when memory usage 872 exceeds a threshold."; 873 reference 874 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 875 Monitoring YANG Data Model - System alarm for memory"; 876 } 878 identity cpu-alarm { 879 base system-alarm; 880 description 881 "Identity for CPU alarm. Alarm when CPU usage 882 exceeds a threshold."; 883 reference 884 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 885 Monitoring YANG Data Model - System alarm for CPU"; 886 } 888 identity disk-alarm { 889 base system-alarm; 890 description 891 "Identity for disk alarm. Alarm when disk usage 892 exceeds a threshold."; 893 reference 894 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 895 Monitoring YANG Data Model - System alarm for disk"; 896 } 898 identity hardware-alarm { 899 base system-alarm; 900 description 901 "Identity for hardware alarm. Alarm when a hardware failure 902 or hardware degradation occurs."; 903 reference 904 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 905 Monitoring YANG Data Model - System alarm for hardware"; 906 } 908 identity interface-alarm { 909 base system-alarm; 910 description 911 "Identity for interface alarm. Alarm when interface usage 912 exceeds a threshold."; 913 reference 914 "draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF NSF 915 Monitoring YANG Data Model - System alarm for interface"; 916 } 918 identity absolute-time { 919 base time; 920 description 921 "absolute time capabilities. 922 If a network security function has the absolute time 923 capability, the network security function supports 924 rule execution according to absolute time."; 925 } 927 identity periodic-time { 928 base time; 929 description 930 "periodic time capabilities. 931 If a network security function has the periodic time 932 capability, the network security function supports 933 rule execution according to periodic time."; 934 } 936 identity device-type { 937 description 938 "Identity for device type condition capability. The capability 939 for matching the destination device type."; 940 } 942 identity computer { 943 base device-type; 944 description 945 "Identity for computer such as personal computer (PC) 946 and server"; 947 } 949 identity mobile-phone { 950 base device-type; 951 description 952 "Identity for mobile-phone such as smartphone and 953 cellphone"; 954 } 956 identity voip-volte-phone { 957 base device-type; 958 description 959 "Identity for voip-volte-phone"; 960 } 962 identity tablet { 963 base device-type; 964 description 965 "Identity for tablet"; 966 } 968 identity network-infrastructure-device { 969 base device-type; 970 description 971 "Identity for network infrastructure devices 972 such as switch, router, and access point"; 973 } 975 identity iot { 976 base device-type; 977 description 978 "Identity for Internet of Things (IoT) devices 979 such as sensors, actuators, and low-power 980 low-capacity computing devices"; 981 } 983 identity ot { 984 base device-type; 985 description 986 "Identity for Operational Technology (OT) devices 987 also known as industrial control systems such as 988 programmable logic controllers (PLCs), digital 989 oscilloscopes, and building management systems (BMS)"; 990 } 992 identity vehicle { 993 base device-type; 994 description 995 "Identity for vehicle that connects to and shares 996 data through the Internet"; 997 } 999 identity user-condition { 1000 description 1001 "Base identity for user condition capability. This is the 1002 capability of mapping user(s) into their corresponding IP 1003 address"; 1004 } 1006 identity user { 1007 base user-condition; 1008 description 1009 "Identity for user condition capability. 1010 A user (e.g., employee) can be mapped to an IP address of 1011 a computing device (e.g., computer, laptop, and virtual 1012 machine) which the user is using."; 1013 } 1015 identity group { 1016 base user-condition; 1017 description 1018 "Identity for group condition capability. 1020 A group (e.g., employees) can be mapped to multiple IP 1021 addresses of computing devices (e.g., computers, laptops, 1022 and virtual machines) which the group is using."; 1023 } 1025 identity geographic-location { 1026 description 1027 "Identity for geographic location condition capability"; 1028 reference 1029 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1030 An access control for a geographical location (i.e., 1031 geolocation) that has the corresponding IP prefix."; 1032 } 1034 identity source-location { 1035 base geographic-location; 1036 description 1037 "Identity for source geographic location condition capability"; 1038 reference 1039 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1040 An access control for a geographical location (i.e., 1041 geolocation) that has the corresponding IP prefix."; 1042 } 1044 identity destination-location { 1045 base geographic-location; 1046 description 1047 "Identity for destination geographic location condition 1048 capability"; 1049 reference 1050 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1051 An access control for a geographical location (i.e., 1052 geolocation) that has the corresponding IP prefix."; 1053 } 1055 identity directional { 1056 description 1057 "Base identity for directional traffic flow capability"; 1058 reference 1059 "RFC 5103: Bidirectional Flow Export Using IP Flow Information 1060 Export (IPFIX) - Terminology Unidirectional and Bidirectional 1061 Flow"; 1062 } 1064 identity unidirectional { 1065 base directional; 1066 description 1067 "Identity for unidirectional traffic flow."; 1069 reference 1070 "RFC 5103: Bidirectional Flow Export Using IP Flow Information 1071 Export (IPFIX) - Terminology Unidirectional Flow"; 1072 } 1074 identity bidirectional { 1075 base directional; 1076 description 1077 "Identity for bidirectional traffic flow."; 1078 reference 1079 "RFC 5103: Bidirectional Flow Export Using IP Flow Information 1080 Export (IPFIX) - Terminology Bidirectional Flow"; 1081 } 1083 identity protocol { 1084 description 1085 "Base identity for protocols"; 1086 } 1088 identity ethernet { 1089 base protocol; 1090 description 1091 "Base identity for Ethernet protocol."; 1092 } 1094 identity source-mac-address { 1095 base ethernet; 1096 description 1097 "Identity for the capability of matching Media Access Control 1098 (MAC) source address(es) condition capability."; 1099 reference 1100 "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; 1101 } 1103 identity destination-mac-address { 1104 base ethernet; 1105 description 1106 "Identity for the capability of matching Media Access Control 1107 (MAC) destination address(es) condition capability."; 1108 reference 1109 "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; 1110 } 1112 identity ether-type { 1113 base ethernet; 1114 description 1115 "Identity for the capability of matching the EtherType in 1116 Ethernet II and Length in Ethernet 802.3 of a packet."; 1118 reference 1119 "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; 1120 } 1122 identity ip { 1123 base protocol; 1124 description 1125 "Base identity for internet/network layer protocol, 1126 e.g., IPv4, IPv6, and ICMP."; 1127 } 1129 identity ipv4 { 1130 base ip; 1131 description 1132 "Base identity for IPv4 condition capability"; 1133 reference 1134 "RFC 791: Internet Protocol"; 1135 } 1137 identity ipv6 { 1138 base ip; 1139 description 1140 "Base identity for IPv6 condition capabilities"; 1141 reference 1142 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1143 Specification"; 1144 } 1146 identity dscp { 1147 base ipv4; 1148 base ipv6; 1149 description 1150 "Identity for the capability of matching IPv4 annd IPv6 1151 Differentiated Services Codepoint (DSCP) condition"; 1152 reference 1153 "RFC 791: Internet Protocol - Type of Service 1154 RFC 2474: Definition of the Differentiated 1155 Services Field (DS Field) in the IPv4 and 1156 IPv6 Headers 1157 RFC 8200: Internet Protocol, Version 6 (IPv6) 1158 Specification - Traffic Class"; 1159 } 1161 identity ecn { 1162 base ipv4; 1163 base ipv6; 1164 description 1165 "Identity for the capability of matching IPv4 annd IPv6 1166 Explicit Congestion Notification (ECN) condition"; 1167 reference 1168 "RFC 3168: The Addition of Explicit Congestion 1169 Notification (ECN) to IP."; 1170 } 1172 identity total-length { 1173 base ipv4; 1174 base ipv6; 1175 description 1176 "Identity for the capability of matching IPv4 Total Length 1177 header field or IPv6 Payload Length header field. 1179 IPv4 Total Length is the length of datagram, measured in 1180 octets, including internet header and data. 1182 IPv6 Payload Length is the length of the IPv6 payload, i.e., 1183 the rest of the packet following the IPv6 header, measured in 1184 octets."; 1185 reference 1186 "RFC 791: Internet Protocol - Total Length 1187 RFC 8200: Internet Protocol, Version 6 (IPv6) 1188 Specification - Payload Length"; 1189 } 1191 identity ttl { 1192 base ipv4; 1193 base ipv6; 1194 description 1195 "Identity for the capability of matching IPv4 Time-To-Live 1196 (TTL) or IPv6 Hop Limit."; 1197 reference 1198 "RFC 791: Internet Protocol - Time To Live (TTL) 1199 RFC 8200: Internet Protocol, Version 6 (IPv6) 1200 Specification - Hop Limit"; 1201 } 1203 identity next-header { 1204 base ipv4; 1205 base ipv6; 1206 description 1207 "Identity for the capability of matching IPv4 Protocol Field or 1208 equivalent to IPv6 Next Header."; 1209 reference 1210 "IANA Website: Assigned Internet Protocol Numbers 1211 - Protocol Number for IPv4 1212 RFC 791: Internet Protocol - Protocol 1213 RFC 8200: Internet Protocol, Version 6 (IPv6) 1214 Specification - Next Header"; 1215 } 1217 identity source-address { 1218 base ipv4; 1219 base ipv6; 1220 description 1221 "Identity for the capability of matching IPv4 or IPv6 source 1222 address(es) condition capability."; 1223 reference 1224 "RFC 791: Internet Protocol - Address 1225 RFC 8200: Internet Protocol, Version 6 (IPv6) 1226 Specification - Source Address"; 1227 } 1229 identity destination-address { 1230 base ipv4; 1231 base ipv6; 1232 description 1233 "Identity for the capability of matching IPv4 or IPv6 1234 destination address(es) condition capability."; 1235 reference 1236 "RFC 791: Internet Protocol - Address 1237 RFC 8200: Internet Protocol, Version 6 (IPv6) 1238 Specification - Destination Address"; 1239 } 1241 identity flow-direction { 1242 base ipv4; 1243 base ipv6; 1244 description 1245 "Identity for flow direction of matching IPv4/IPv6 source 1246 or destination address(es) condition capability where a flow's 1247 direction is either unidirectional or bidirectional"; 1248 reference 1249 "RFC 791: Internet Protocol 1250 RFC 8200: Internet Protocol, Version 6 (IPv6) 1251 Specification"; 1252 } 1254 identity header-length { 1255 base ipv4; 1256 description 1257 "Identity for matching IPv4 header-length (IHL) 1258 condition capability"; 1259 reference 1260 "RFC 791: Internet Protocol - Header Length"; 1261 } 1262 identity identification { 1263 base ipv4; 1264 description 1265 "Identity for IPv4 identification condition capability. 1266 IPv4 ID field is used for fragmentation and reassembly."; 1267 reference 1268 "RFC 791: Internet Protocol - Identification 1269 RFC 6864: Updated Specification of the IPv4 ID Field - 1270 Fragmentation and Reassembly"; 1271 } 1273 identity fragment-flags { 1274 base ipv4; 1275 description 1276 "Identity for IPv4 fragment flags condition capability"; 1277 reference 1278 "RFC 791: Internet Protocol - Fragmentation Flags"; 1279 } 1281 identity fragment-offset { 1282 base ipv4; 1283 description 1284 "Identity for matching IPv4 fragment offset 1285 condition capability"; 1286 reference 1287 "RFC 791: Internet Protocol - Fragmentation Offset"; 1288 } 1290 identity flow-label { 1291 base ipv6; 1292 description 1293 "Identity for matching IPv6 flow label 1294 condition capability"; 1295 reference 1296 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1297 Specification - Flow Label 1298 RFC 6437: IPv6 Flow Label Specification"; 1299 } 1301 identity header-order { 1302 base ipv6; 1303 description 1304 "Identity for IPv6 extension header order condition 1305 capability"; 1306 reference 1307 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1308 Specification - Extension Header Order"; 1309 } 1310 identity hop-by-hop { 1311 base ipv6; 1312 description 1313 "Identity for IPv6 hop by hop options header 1314 condition capability"; 1315 reference 1316 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1317 Specification - Hop-by-Hop Options Header"; 1318 } 1320 identity routing-header { 1321 base ipv6; 1322 description 1323 "Identity for IPv6 routing header condition 1324 capability"; 1325 reference 1326 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1327 Specification - Routing Header"; 1328 } 1330 identity fragment-header { 1331 base ipv6; 1332 description 1333 "Identity for IPv6 fragment header condition 1334 capability"; 1335 reference 1336 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1337 Specification - Fragment Header"; 1338 } 1340 identity destination-options { 1341 base ipv6; 1342 description 1343 "Identity for IPv6 destination options condition 1344 capability"; 1345 reference 1346 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1347 Specification - Destination Options"; 1348 } 1350 identity icmp { 1351 base protocol; 1352 description 1353 "Base identity for ICMPv4 and ICMPv6 condition capability"; 1354 reference 1355 "RFC 792: Internet Control Message Protocol 1356 RFC 4443: Internet Control Message Protocol (ICMPv6) 1357 for the Internet Protocol Version 6 (IPv6) Specification 1358 - ICMPv6"; 1359 } 1361 identity icmpv4 { 1362 base icmp; 1363 description 1364 "Base identity for ICMPv4 condition capability"; 1365 reference 1366 "RFC 792: Internet Control Message Protocol"; 1367 } 1369 identity icmpv6 { 1370 base icmp; 1371 description 1372 "Base identity for ICMPv6 condition capability"; 1373 reference 1374 "RFC 4443: Internet Control Message Protocol (ICMPv6) 1375 for the Internet Protocol Ver sion 6 (IPv6) Specification 1376 - ICMPv6"; 1377 } 1379 identity type { 1380 base icmpv4; 1381 base icmpv6; 1382 description 1383 "Identity for ICMPv4 and ICMPv6 type condition capability"; 1384 reference 1385 "RFC 792: Internet Control Message Protocol 1386 RFC 4443: Internet Control Message Protocol (ICMPv6) 1387 for the Internet Protocol Version 6 (IPv6) Specification 1388 - ICMPv6"; 1389 } 1391 identity code { 1392 base icmpv4; 1393 base icmpv6; 1394 description 1395 "Identity for ICMPv4 and ICMPv6 code condition capability"; 1396 reference 1397 "RFC 792: Internet Control Message Protocol 1398 RFC 4443: Internet Control Message Protocol (ICMPv6) 1399 for the Internet Protocol Version 6 (IPv6) Specification 1400 - ICMPv6"; 1401 } 1403 identity transport-protocol { 1404 base protocol; 1405 description 1406 "Base identity for Layer 4 protocol condition capabilities, 1407 e.g., TCP, UDP, SCTP, and DCCP"; 1408 } 1410 identity tcp { 1411 base transport-protocol; 1412 description 1413 "Base identity for TCP condition capabilities"; 1414 reference 1415 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1416 (TCP) Specification"; 1417 } 1419 identity udp { 1420 base transport-protocol; 1421 description 1422 "Base identity for UDP condition capabilities"; 1423 reference 1424 "RFC 768: User Datagram Protocol"; 1425 } 1427 identity sctp { 1428 base transport-protocol; 1429 description 1430 "Identity for SCTP condition capabilities"; 1431 reference 1432 "RFC 4960: Stream Control Transmission Protocol"; 1433 } 1435 identity dccp { 1436 base transport-protocol; 1437 description 1438 "Identity for DCCP condition capabilities"; 1439 reference 1440 "RFC 4340: Datagram Congestion Control Protocol"; 1441 } 1443 identity source-port-number { 1444 base tcp; 1445 base udp; 1446 base sctp; 1447 base dccp; 1448 description 1449 "Identity for matching TCP, UDP, SCTP, and DCCP source port 1450 number condition capability"; 1451 reference 1452 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1453 (TCP) Specification 1454 RFC 768: User Datagram Protocol 1455 RFC 4960: Stream Control Transmission Protocol 1456 RFC 4340: Datagram Congestion Control Protocol"; 1457 } 1459 identity destination-port-number { 1460 base tcp; 1461 base udp; 1462 base sctp; 1463 base dccp; 1464 description 1465 "Identity for matching TCP, UDP, SCTP, and DCCP destination 1466 port number condition capability"; 1467 reference 1468 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1469 (TCP) Specification"; 1470 } 1472 identity flags { 1473 base tcp; 1474 description 1475 "Identity for TCP control bits (flags) condition capability"; 1476 reference 1477 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1478 (TCP) Specification - TCP Header Flags 1479 RFC 3168: The Addition of Explicit Congestion Notification 1480 (ECN) to IP - ECN-Echo (ECE) Flag and Congestion Window 1481 Reduced (CWR) Flag 1482 draft-ietf-tcpm-accurate-ecn-15: More Accurate ECN Feedback 1483 in TCP - ECN-Echo (ECE) Flag and Congestion Window Reduced 1484 (CWR) Flag"; 1485 } 1487 identity options { 1488 base tcp; 1489 description 1490 "Identity for TCP options condition capability"; 1491 reference 1492 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1493 (TCP) Specification 1494 RFC 6691: TCP Options and Maximum Segment Size 1495 RFC 7323: TCP Extensions for High Performance"; 1496 } 1498 identity length { 1499 base tcp; 1500 base udp; 1501 description 1502 "Identity for matching TCP or UDP length condition capability. 1503 TCP length is the Data Offset header field where it represents 1504 the size of the TCP header, expressed in 32-bit words. 1505 The UDP length is the length in octets of this user datagram 1506 including this header and the datagram. 1507 The UDP length can be smaller than the IP transport 1508 length for UDP transport layer options."; 1509 reference 1510 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1511 (TCP) Specification - Data Offset 1512 RFC 768: User Datagram Protocol - Length 1513 draft-ietf-tsvwg-udp-options: Transport Options for UDP"; 1514 } 1516 identity reserved { 1517 base tcp; 1518 description 1519 "Identity for TCP header reserved field condition capability. 1520 The set of control bits reserved for future used. The control 1521 bits are also known as flags. Must be zero in generated 1522 segments and must be ignored in received segments, if 1523 corresponding future features are unimplemented by the 1524 sending or receiving host."; 1525 reference 1526 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1527 (TCP) Specification"; 1528 } 1530 identity window-size { 1531 base tcp; 1532 description 1533 "Identity for TCP header Window field condition capability. 1534 The number of data octets beginning with the one indicated 1535 in the acknowledgment field that the sender of this segment 1536 is willing to accept."; 1537 reference 1538 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1539 (TCP) Specification"; 1540 } 1542 identity urgent-pointer { 1543 base tcp; 1544 description 1545 "Identity for TCP Urgent Pointer header field condition 1546 capability. The Urgent Pointer field in TCP describes the 1547 current value of urgent pointer as a positive offset from 1548 the sequence number in this segment. The urgent pointer 1549 points to the sequence number of the octet following the 1550 urgent data. This field is only be interpreted in segments 1551 with the URG control bit set."; 1552 reference 1553 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1554 (TCP) Specification"; 1555 } 1557 identity chunk-type { 1558 base sctp; 1559 description 1560 "Identity for SCTP chunk type condition capability"; 1561 reference 1562 "RFC 4960: Stream Control Transmission Protocol - Chunk Type"; 1563 } 1565 identity service-code { 1566 base dccp; 1567 description 1568 "Identity for DCCP Service Code condition capabilitiy"; 1569 reference 1570 "RFC 4340: Datagram Congestion Control Protocol 1571 RFC 5595: The Datagram Congestion Control Protocol (DCCP) 1572 Service Codes 1573 RFC 6335: Internet Assigned Numbers Authority (IANA) 1574 Procedures for the Management of the Service Name and 1575 Transport Protocol Port Number Registry - Service Code"; 1576 } 1578 identity application-protocol { 1579 base protocol; 1580 description 1581 "Base identity for Application protocol"; 1582 } 1584 identity http { 1585 base application-protocol; 1586 description 1587 "The identity for Hypertext Transfer Protocol."; 1588 reference 1589 "RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1590 Syntax and Routing 1591 RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1592 and Content"; 1593 } 1595 identity https { 1596 base application-protocol; 1597 description 1598 "The identity for Hypertext Transfer Protocol Secure."; 1599 reference 1600 "RFC 2818: HTTP over TLS (HTTPS) 1601 RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1602 Syntax and Routing 1603 RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1604 and Content"; 1605 } 1607 identity ftp { 1608 base application-protocol; 1609 description 1610 "The identity for File Transfer Protocol."; 1611 reference 1612 "RFC 959: File Transfer Protocol (FTP)"; 1613 } 1615 identity ssh { 1616 base application-protocol; 1617 description 1618 "The identity for Secure Shell (SSH) protocol."; 1619 reference 1620 "RFC 4250: The Secure Shell (SSH) Protocol"; 1621 } 1623 identity telnet { 1624 base application-protocol; 1625 description 1626 "The identity for telnet."; 1627 reference 1628 "RFC 854: Telnet Protocol"; 1629 } 1631 identity smtp { 1632 base application-protocol; 1633 description 1634 "The identity for Simple Mail Transfer Protocol."; 1635 reference 1636 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1637 } 1639 identity pop3 { 1640 base application-protocol; 1641 description 1642 "The identity for Post Office Protocol 3. This includes 1643 POP3 over TLS"; 1644 reference 1645 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1647 } 1649 identity imap { 1650 base application-protocol; 1651 description 1652 "The identity for Internet Message Access Protocol. This 1653 includes IMAP over TLS"; 1654 reference 1655 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 1656 4rev2"; 1657 } 1659 identity action { 1660 description 1661 "Base identity for action capability"; 1662 } 1664 identity log-action { 1665 base action; 1666 description 1667 "Base identity for log-action capability"; 1668 } 1670 identity ingress-action { 1671 base action; 1672 description 1673 "Base identity for ingress-action capability"; 1674 reference 1675 "RFC 8329: Framework for Interface to Network Security 1676 Functions - Section 7.2"; 1677 } 1679 identity egress-action { 1680 base action; 1681 description 1682 "Base identity for egress-action capability"; 1683 reference 1684 "RFC 8329: Framework for Interface to Network Security 1685 Functions - Section 7.2"; 1686 } 1688 identity default-action { 1689 base action; 1690 description 1691 "Base identity for default-action capability"; 1692 } 1694 identity rule-log { 1695 base log-action; 1696 description 1697 "Identity for rule log-action capability. 1698 Log the received packet based on the rule"; 1699 } 1701 identity session-log { 1702 base log-action; 1703 description 1704 "Identity for session log-action capability. 1705 Log the received packet based on the session."; 1706 } 1708 identity pass { 1709 base ingress-action; 1710 base egress-action; 1711 base default-action; 1712 description 1713 "Identity for pass action capability. The pass action allows 1714 packet or flow to go through the NSF entering or exiting the 1715 internal network."; 1716 } 1718 identity drop { 1719 base ingress-action; 1720 base egress-action; 1721 base default-action; 1722 description 1723 "Identity for drop action capability. The drop action denies 1724 a packet to go through the NSF entering or exiting the 1725 internal network without sending any response back to the 1726 source."; 1727 } 1729 identity reject { 1730 base ingress-action; 1731 base egress-action; 1732 base default-action; 1733 description 1734 "Identity for reject action capability. The reject action 1735 denies a packet to go through the NSF entering or exiting the 1736 internal network and send a response back to the source. 1737 The response depends on the packet and implementation. 1738 For example, a TCP packet is rejected with TCP RST response 1739 or a UDP packet may be rejected with ICMP message Type 3 1740 Code 3 response, i.e., Destination Unreachable: Destination 1741 port unreachable."; 1742 } 1743 identity mirror { 1744 base ingress-action; 1745 base egress-action; 1746 base default-action; 1747 description 1748 "Identity for mirror action capability. The mirror action 1749 copies packet and send it to the monitoring entity while still 1750 allow the packet or flow to go through the NSF."; 1751 } 1753 identity rate-limit { 1754 base ingress-action; 1755 base egress-action; 1756 base default-action; 1757 description 1758 "Identity for rate limiting action capability. The rate limit 1759 action limits the number of packets or flows that can go 1760 through the NSF by dropping packets or flows (randomly or 1761 systematically)."; 1762 } 1764 identity invoke-signaling { 1765 base egress-action; 1766 description 1767 "Identity for invoke signaling action capability"; 1768 } 1770 identity tunnel-encapsulation { 1771 base egress-action; 1772 description 1773 "Identity for tunnel encapsulation action capability"; 1774 } 1776 identity forwarding { 1777 base egress-action; 1778 description 1779 "Identity for forwarding action capability"; 1780 } 1782 identity transformation { 1783 base egress-action; 1784 description 1785 "Identity for transformation action capability"; 1786 } 1788 identity resolution-strategy { 1789 description 1790 "Base identity for resolution strategy capability"; 1792 } 1794 identity fmr { 1795 base resolution-strategy; 1796 description 1797 "Identity for First Matching Rule (FMR) resolution 1798 strategy capability"; 1799 } 1801 identity lmr { 1802 base resolution-strategy; 1803 description 1804 "Identity for Last Matching Rule (LMR) resolution 1805 strategy capability"; 1806 } 1808 identity pmr { 1809 base resolution-strategy; 1810 description 1811 "Identity for Prioritized Matching Rule (PMR) resolution 1812 strategy capability"; 1813 } 1815 identity pmre { 1816 base resolution-strategy; 1817 description 1818 "Identity for Prioritized Matching Rule with Errors (PMRE) 1819 resolution strategy capability"; 1820 } 1822 identity pmrn { 1823 base resolution-strategy; 1824 description 1825 "Identity for Prioritized Matching Rule with No Errors (PMRN) 1826 resolution strategy capability"; 1827 } 1829 identity advanced-nsf { 1830 description 1831 "Base identity for advanced Network Security Function (NSF) 1832 capability."; 1833 } 1835 identity content-security-control { 1836 base advanced-nsf; 1837 description 1838 "Base identity for content security control. Content security 1839 control is an NSF that evaluates a packet's payload such as 1840 Intrusion Prevention System (IPS), URL-Filtering, Antivirus, 1841 and VoIP/VoLTE Filter."; 1842 } 1844 identity attack-mitigation-control { 1845 base advanced-nsf; 1846 description 1847 "Base identity for attack mitigation control. Attack mitigation 1848 control is an NSF that mitigates an attack such as anti-DDoS 1849 or DDoS-mitigator."; 1850 } 1852 identity ips { 1853 base content-security-control; 1854 description 1855 "Base identity for IPS (Intrusion Prevention System) capability 1856 that prevents malicious activity within a network"; 1857 } 1859 identity url-filtering { 1860 base content-security-control; 1861 description 1862 "Base identity for url filtering capability that limits access 1863 by comparing the web traffic's URL with the URLs for web 1864 filtering in a database"; 1865 } 1867 identity anti-virus { 1868 base content-security-control; 1869 description 1870 "Base identity for anti-virus capability to protect the network 1871 by detecting and removing viruses."; 1872 } 1874 identity voip-volte-filtering { 1875 base content-security-control; 1876 description 1877 "Base identity for advanced NSF VoIP/VoLTE Security Service 1878 capability to filter the VoIP/VoLTE packets or flows."; 1879 reference 1880 "RFC 3261: SIP: Session Initiation Protocol"; 1881 } 1883 identity anti-ddos { 1884 base attack-mitigation-control; 1885 description 1886 "Base identity for advanced NSF Anti-DDoS Attack or DDoS 1887 Mitigator capability."; 1889 } 1891 identity packet-rate { 1892 base anti-ddos; 1893 description 1894 "Identity for advanced NSF Anti-DDoS detecting Packet Rate 1895 Capability where a packet rate is defined as the arrival rate 1896 of Packets toward a victim destination node. The NSF with 1897 this capability can detect the incoming packet rate and create 1898 an alert if the rate exceeds the threshold."; 1900 } 1902 identity flow-rate { 1903 base anti-ddos; 1904 description 1905 "Identity for advanced NSF Anti-DDoS detecting Flow Rate 1906 Capability where a flow rate is defined as the arrival rate of 1907 flows towards a victim destination node. The NSF with this 1908 capability can detect the incoming flow rate and create an 1909 alert if the rate exceeds the threshold."; 1910 } 1912 identity byte-rate { 1913 base anti-ddos; 1914 description 1915 "Identity for advanced NSF Anti-DDoS detecting Byte Rate 1916 Capability where a byte rate is defined as the arrival rate of 1917 Bytes toward a victim destination node. The NSF with this 1918 capability can detect the incoming byte rate and create an 1919 alert if the rate exceeds the threshold."; 1920 } 1922 identity signature-set { 1923 base ips; 1924 description 1925 "Identity for the capability of IPS to set the signature. 1926 Signature is a set of rules to detect an intrusive activity."; 1927 reference 1928 "RFC 4766: Intrusion Detection Message Exchange Requirements - 1929 Section 2.2.13"; 1930 } 1932 identity exception-signature { 1933 base ips; 1934 description 1935 "Identity for the capability of IPS to exclude signatures from 1936 detecting the intrusion."; 1938 reference 1939 "RFC 4766: Intrusion Detection Message Exchange Requirements - 1940 Section 2.2.13"; 1941 } 1943 identity detect { 1944 base anti-virus; 1945 description 1946 "Identity for advanced NSF Antivirus capability to detect 1947 viruses using a security profile. The security profile is used 1948 to scan threats, such as virus, malware, and spyware. The NSF 1949 should be able to update the security profile."; 1950 } 1952 identity exception-files { 1953 base anti-virus; 1954 description 1955 "Identity for advanced NSF Antivirus capability to exclude a 1956 certain file type or name from detection."; 1957 } 1959 identity pre-defined { 1960 base url-filtering; 1961 description 1962 "Identity for pre-defined URL Database condition capability 1963 where URL database is a public database for URL filtering."; 1964 } 1966 identity user-defined { 1967 base url-filtering; 1968 description 1969 "Identity for user-defined URL Database condition capability 1970 that allows a user's manual addition of URLs for URL 1971 filtering."; 1972 } 1974 identity call-id { 1975 base voip-volte-filtering; 1976 description 1977 "Identity for advanced NSF VoIP/VoLTE Call Identifier (ID) 1978 capability."; 1979 } 1981 identity user-agent { 1982 base voip-volte-filtering; 1983 description 1984 "Identity for advanced NSF VoIP/VoLTE User Agent capability."; 1985 } 1986 /* 1987 * Grouping 1988 */ 1990 grouping nsf-capabilities { 1991 description 1992 "Network Security Function (NSF) Capabilities"; 1993 reference 1994 "RFC 8329: Framework for Interface to Network Security 1995 Functions - I2NSF Flow Security Policy Structure."; 1997 leaf-list directional-capabilities { 1998 type identityref { 1999 base directional; 2000 } 2001 description 2002 "The capability of an NSF for handling directional traffic 2003 flow (i.e., unidirectional or bidirectional traffic flow)."; 2004 } 2006 container event-capabilities { 2007 description 2008 "Capabilities of events. 2009 If a network security function has the event capabilities, 2010 the network security function supports rule execution 2011 according to system event and system alarm."; 2013 reference 2014 "RFC 8329: Framework for Interface to Network Security 2015 Functions - Section 7. 2016 draft-ietf-i2nsf-nsf-monitoring-data-model-09: I2NSF 2017 NSF Monitoring YANG Data Model - System Alarm and 2018 System Events."; 2020 leaf-list system-event-capability { 2021 type identityref { 2022 base system-event; 2023 } 2024 description 2025 "System event capabilities"; 2026 } 2028 leaf-list system-alarm-capability { 2029 type identityref { 2030 base system-alarm; 2031 } 2032 description 2033 "System alarm capabilities"; 2035 } 2037 leaf-list time-capabilities { 2038 type identityref { 2039 base time; 2040 } 2041 description 2042 "The capabilities for activating the policy within a 2043 specific time."; 2044 } 2045 } 2047 container condition-capabilities { 2048 description 2049 "Conditions capabilities."; 2050 container generic-nsf-capabilities { 2051 description 2052 "Conditions capabilities. 2053 If a network security function has the condition 2054 capabilities, the network security function 2055 supports rule execution according to conditions of 2056 IPv4, IPv6, TCP, UDP, SCTP, DCCP, ICMP, or ICMPv6."; 2057 reference 2058 "RFC 768: User Datagram Protocol - UDP. 2059 RFC 791: Internet Protocol - IPv4. 2060 RFC 792: Internet Control Message Protocol - ICMP. 2061 RFC 4443: Internet Control Message Protocol (ICMPv6) 2062 for the Internet Protocol Version 6 (IPv6) Specification 2063 - ICMPv6. 2064 RFC 4960: Stream Control Transmission Protocol - SCTP. 2065 RFC 8200: Internet Protocol, Version 6 (IPv6) 2066 Specification - IPv6. 2067 RFC 8329: Framework for Interface to Network Security 2068 Functions - I2NSF Flow Security Policy Structure. 2069 draft-ietf-tcpm-rfc793bis-25: Transmission Control 2070 Protocol (TCP) Specification"; 2072 leaf-list ethernet-capability { 2073 type identityref { 2074 base ethernet; 2075 } 2076 description 2077 "Media Access Control (MAC) capabilities"; 2078 reference 2079 "IEEE 802.3: IEEE Standard for Ethernet"; 2080 } 2082 leaf-list ipv4-capability { 2083 type identityref { 2084 base ipv4; 2085 } 2086 description 2087 "IPv4 packet capabilities"; 2088 reference 2089 "RFC 791: Internet Protocol"; 2090 } 2092 leaf-list ipv6-capability { 2093 type identityref { 2094 base ipv6; 2095 } 2096 description 2097 "IPv6 packet capabilities"; 2098 reference 2099 "RFC 8200: Internet Protocol, Version 6 (IPv6) 2100 Specification - IPv6"; 2101 } 2103 leaf-list icmpv4-capability { 2104 type identityref { 2105 base icmpv4; 2106 } 2107 description 2108 "ICMPv4 packet capabilities"; 2109 reference 2110 "RFC 792: Internet Control Message Protocol - ICMP"; 2111 } 2113 leaf-list icmpv6-capability { 2114 type identityref { 2115 base icmpv6; 2116 } 2117 description 2118 "ICMPv6 packet capabilities"; 2119 reference 2120 "RFC 4443: Internet Control Message Protocol (ICMPv6) 2121 for the Internet Protocol Version 6 (IPv6) Specification 2122 - ICMPv6"; 2123 } 2125 leaf-list tcp-capability { 2126 type identityref { 2127 base tcp; 2128 } 2129 description 2130 "TCP packet capabilities"; 2132 reference 2133 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 2134 Protocol (TCP) Specification"; 2135 } 2137 leaf-list udp-capability { 2138 type identityref { 2139 base udp; 2140 } 2141 description 2142 "UDP packet capabilities"; 2143 reference 2144 "RFC 768: User Datagram Protocol - UDP"; 2145 } 2147 leaf-list sctp-capability { 2148 type identityref { 2149 base sctp; 2150 } 2151 description 2152 "SCTP packet capabilities"; 2153 reference 2154 "RFC 4960: Stream Control Transmission Protocol - SCTP"; 2155 } 2157 leaf-list dccp-capability { 2158 type identityref { 2159 base dccp; 2160 } 2161 description 2162 "DCCP packet capabilities"; 2163 reference 2164 "RFC 4340: Datagram Congestion Control Protocol - DCCP"; 2165 } 2166 } 2168 container advanced-nsf-capabilities { 2169 description 2170 "Advanced Network Security Function (NSF) capabilities, 2171 such as Anti-DDoS, IPS, and VoIP/VoLTE. 2172 This container contains the leaf-lists of advanced 2173 NSF capabilities"; 2175 leaf-list anti-ddos-capability { 2176 type identityref { 2177 base anti-ddos; 2178 } 2179 description 2180 "Anti-DDoS Attack capabilities"; 2181 } 2183 leaf-list ips-capability { 2184 type identityref { 2185 base ips; 2186 } 2187 description 2188 "IPS capabilities"; 2189 } 2191 leaf-list anti-virus-capability { 2192 type identityref { 2193 base anti-virus; 2194 } 2195 description 2196 "Anti-Virus capabilities"; 2197 } 2199 leaf-list url-filtering-capability { 2200 type identityref { 2201 base url-filtering; 2202 } 2203 description 2204 "URL Filtering capabilities"; 2205 } 2207 leaf-list voip-volte-filtering-capability { 2208 type identityref { 2209 base voip-volte-filtering; 2210 } 2211 description 2212 "VoIP/VoLTE capabilities"; 2213 } 2214 } 2216 container context-capabilities { 2217 description 2218 "Security context capabilities"; 2219 leaf-list application-filter-capabilities{ 2220 type identityref { 2221 base application-protocol; 2222 } 2223 description 2224 "Context capabilities based on the application protocol"; 2225 } 2227 leaf-list device-type-capabilities { 2228 type identityref { 2229 base device-type; 2230 } 2231 description 2232 "Context capabilities based on the device attribute that 2233 can identify a device type 2234 (i.e., router, switch, pc, ios, or android)."; 2235 } 2237 leaf-list user-condition-capabilities { 2238 type identityref { 2239 base user-condition; 2240 } 2241 description 2242 "Context capabilities based on user condition, such as 2243 user-id or user-name. The users can collected into a 2244 user-group and identified with group-id or group-name. 2245 An NSF is aware of the IP address of the user provided 2246 by a unified user management system via network. Based 2247 on name-address association, an NSF is able to enforce 2248 the security functions over the given user (or user 2249 group)"; 2250 } 2252 leaf-list geographic-capabilities { 2253 type identityref { 2254 base geographic-location; 2255 } 2256 description 2257 "Context condition capabilities based on the geographical 2258 location of the source or destination"; 2259 } 2260 } 2261 } 2263 container action-capabilities { 2264 description 2265 "Action capabilities. 2266 If a network security function has the action capabilities, 2267 the network security function supports the attendant 2268 actions for policy rules."; 2270 leaf-list ingress-action-capability { 2271 type identityref { 2272 base ingress-action; 2273 } 2274 description 2275 "Ingress-action capabilities"; 2277 } 2279 leaf-list egress-action-capability { 2280 type identityref { 2281 base egress-action; 2282 } 2283 description 2284 "Egress-action capabilities"; 2285 } 2287 leaf-list log-action-capability { 2288 type identityref { 2289 base log-action; 2290 } 2291 description 2292 "Log-action capabilities"; 2293 } 2294 } 2296 leaf-list resolution-strategy-capabilities { 2297 type identityref { 2298 base resolution-strategy; 2299 } 2300 description 2301 "Resolution strategy capabilities. 2302 The resolution strategies can be used to specify how 2303 to resolve conflicts that occur between the actions 2304 of the same or different policy rules that are matched 2305 for the same packet and by particular NSF."; 2306 } 2308 leaf-list default-action-capabilities { 2309 type identityref { 2310 base default-action; 2311 } 2312 description 2313 "Default action capabilities. 2314 A default action is used to execute I2NSF policy rules 2315 when no rule matches a packet. The default action is 2316 defined as pass, drop, rate-limit, or mirror."; 2317 } 2318 } 2320 /* 2321 * Data nodes 2322 */ 2324 list nsf { 2325 key "nsf-name"; 2326 description 2327 "The list of Network Security Functions (NSFs)"; 2328 leaf nsf-name { 2329 type string; 2330 mandatory true; 2331 description 2332 "The name of Network Security Function (NSF)"; 2333 } 2334 uses nsf-capabilities; 2335 } 2336 } 2337 2339 Figure 3: YANG Data Module of I2NSF Capability 2341 7. IANA Considerations 2343 This document requests IANA to register the following URI in the 2344 "IETF XML Registry" [RFC3688]: 2346 ID: yang:ietf-i2nsf-capability 2347 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2348 Registrant Contact: The IESG. 2349 XML: N/A; the requested URI is an XML namespace. 2350 Filename: [ TBD-at-Registration ] 2351 Reference: [ RFC-to-be ] 2353 This document requests IANA to register the following YANG module in 2354 the "YANG Module Names" registry [RFC7950][RFC8525]: 2356 Name: ietf-i2nsf-capability 2357 Maintained by IANA? N 2358 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2359 Prefix: nsfcap 2360 Module: 2361 Reference: [ RFC-to-be ] 2363 8. Privacy Considerations 2365 This YANG module specifies the capabilities of NSFs. These 2366 capabilities are consistent with the diverse set of network security 2367 functions in common use in enterprise security operations. The 2368 configuration of the capabilities may entail privacy sensitive 2369 information as explicitly outlined in Section 9. The NSFs 2370 implementing these capabilities may inspect, alter or drop user 2371 traffic; and be capable of attributing user traffic to individual 2372 users. 2374 Due to the sensitivity of these capabilities, notice must be provided 2375 to and consent must be received from the users of the network. 2376 Additionally, the collected data and associated infrastructure must 2377 be secured to prevent the leakage or unauthorized disclosure of this 2378 private data. 2380 9. Security Considerations 2382 The YANG module specified in this document defines a data schema 2383 designed to be accessed through network management protocols such as 2384 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest layer of NETCONF 2385 protocol layers MUST use Secure Shell (SSH) [RFC4254][RFC6242] as a 2386 secure transport layer. The lowest layer of RESTCONF protocol layers 2387 MUST use HTTP over Transport Layer Security (TLS), that is, HTTPS 2388 [RFC7230][RFC8446] as a secure transport layer. 2390 The Network Configuration Access Control Model (NACM) [RFC8341] 2391 provides a means of restricting access to specific NETCONF or 2392 RESTCONF users to a preconfigured subset of all available NETCONF or 2393 RESTCONF protocol operations and contents. Thus, NACM SHOULD be used 2394 to restrict the NSF registration from unauthorized users. 2396 There are a number of data nodes defined in this YANG module that are 2397 writable, creatable, and deletable (i.e., config true, which is the 2398 default). These data nodes may be considered sensitive or vulnerable 2399 in some network environments. Write operations to these data nodes 2400 could have a negative effect on network and security operations. 2401 These data nodes are collected into a single list node. This list 2402 node is defined by list nsf with the following sensitivity/ 2403 vulnerability: 2405 * list nsf: An attacker could alter the security capabilities 2406 associated with an NSF by disabling or enabling the functionality 2407 of the security capabilities of the NSF. 2409 Some of the readable data nodes in this YANG module may be considered 2410 sensitive or vulnerable in some network environments. It is thus 2411 important to control read access (e.g., via get, get-config, or 2412 notification) to these data nodes. These are the subtrees and data 2413 nodes with their sensitivity/vulnerability: 2415 * list nsf: The leak of this node to an attacker could reveal the 2416 specific configuration of security controls to an attacker. An 2417 attacker can craft an attack path that avoids observation or 2418 mitigations; one may reveal topology information to inform 2419 additional targets or enable lateral movement; one enables the 2420 construction of an attack path that avoids observation or 2421 mitigations; one provides an indication that the operator has 2422 discovered the attack. 2424 Some of the capability indicators (i.e., identities) defined in this 2425 document are highly sensitive and/or privileged operations that 2426 inherently require access to individuals' private data. These are 2427 subtrees and data nodes that are considered privacy sensitive: 2429 * voip-volte-filtering-capability: The NSF that is able to filter 2430 VoIP/VoLTE calls might identify certain individual identification. 2432 * user-condition-capabilities: The capability uses a set of IP 2433 addresses mapped to users. 2435 * geographic-capabilities: The IP address used in this capability 2436 can identify a user's geographical location. 2438 It is noted that some private information is made accessible in this 2439 manner. Thus, the nodes/entities given access to this data MUST be 2440 tightly secured, monitored, and audited to prevent leakage or other 2441 unauthorized disclosure of private data. Refer to [RFC6973] for the 2442 description of privacy aspects that protocol designers (including 2443 YANG data model designers) should consider along with regular 2444 security and privacy analysis. 2446 10. References 2448 10.1. Normative References 2450 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2451 DOI 10.17487/RFC0768, August 1980, 2452 . 2454 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2455 DOI 10.17487/RFC0791, September 1981, 2456 . 2458 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2459 RFC 792, DOI 10.17487/RFC0792, September 1981, 2460 . 2462 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 2463 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 2464 1983, . 2466 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2467 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 2468 . 2470 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2471 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 2472 . 2474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2475 Requirement Levels", BCP 14, RFC 2119, 2476 DOI 10.17487/RFC2119, March 1997, 2477 . 2479 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2480 "Definition of the Differentiated Services Field (DS 2481 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2482 DOI 10.17487/RFC2474, December 1998, 2483 . 2485 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2486 of Explicit Congestion Notification (ECN) to IP", 2487 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2488 . 2490 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2491 A., Peterson, J., Sparks, R., Handley, M., and E. 2492 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2493 DOI 10.17487/RFC3261, June 2002, 2494 . 2496 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2497 DOI 10.17487/RFC3688, January 2004, 2498 . 2500 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 2501 Protocol Assigned Numbers", RFC 4250, 2502 DOI 10.17487/RFC4250, January 2006, 2503 . 2505 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2506 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 2507 January 2006, . 2509 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2510 Congestion Control Protocol (DCCP)", RFC 4340, 2511 DOI 10.17487/RFC4340, March 2006, 2512 . 2514 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2515 Control Message Protocol (ICMPv6) for the Internet 2516 Protocol Version 6 (IPv6) Specification", STD 89, 2517 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2518 . 2520 [RFC4766] Wood, M. and M. Erlinger, "Intrusion Detection Message 2521 Exchange Requirements", RFC 4766, DOI 10.17487/RFC4766, 2522 March 2007, . 2524 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2525 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2526 . 2528 [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export 2529 Using IP Flow Information Export (IPFIX)", RFC 5103, 2530 DOI 10.17487/RFC5103, January 2008, 2531 . 2533 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2534 DOI 10.17487/RFC5321, October 2008, 2535 . 2537 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 2538 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 2539 September 2009, . 2541 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2542 the Network Configuration Protocol (NETCONF)", RFC 6020, 2543 DOI 10.17487/RFC6020, October 2010, 2544 . 2546 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2547 and A. Bierman, Ed., "Network Configuration Protocol 2548 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2549 . 2551 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2552 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2553 . 2555 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2556 Cheshire, "Internet Assigned Numbers Authority (IANA) 2557 Procedures for the Management of the Service Name and 2558 Transport Protocol Port Number Registry", BCP 165, 2559 RFC 6335, DOI 10.17487/RFC6335, August 2011, 2560 . 2562 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2563 "IPv6 Flow Label Specification", RFC 6437, 2564 DOI 10.17487/RFC6437, November 2011, 2565 . 2567 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2568 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2569 . 2571 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2572 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2573 . 2575 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2576 Protocol (HTTP/1.1): Message Syntax and Routing", 2577 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2578 . 2580 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2581 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2582 DOI 10.17487/RFC7231, June 2014, 2583 . 2585 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 2586 Scheffenegger, Ed., "TCP Extensions for High Performance", 2587 RFC 7323, DOI 10.17487/RFC7323, September 2014, 2588 . 2590 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2591 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2592 . 2594 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2595 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2596 . 2598 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2599 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2600 May 2017, . 2602 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2603 (IPv6) Specification", STD 86, RFC 8200, 2604 DOI 10.17487/RFC8200, July 2017, 2605 . 2607 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2608 Kumar, "Framework for Interface to Network Security 2609 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2610 . 2612 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2613 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2614 . 2616 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2617 Access Control Model", STD 91, RFC 8341, 2618 DOI 10.17487/RFC8341, March 2018, 2619 . 2621 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2622 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2623 DOI 10.17487/RFC8407, October 2018, 2624 . 2626 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2627 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2628 . 2630 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 2631 and R. Wilton, "YANG Library", RFC 8525, 2632 DOI 10.17487/RFC8525, March 2019, 2633 . 2635 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 2636 Kumari, "A Format for Self-Published IP Geolocation 2637 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 2638 . 2640 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message 2641 Access Protocol (IMAP) - Version 4rev2", RFC 9051, 2642 DOI 10.17487/RFC9051, August 2021, 2643 . 2645 [I-D.ietf-tcpm-rfc793bis] 2646 Eddy, W. M., "Transmission Control Protocol (TCP) 2647 Specification", Work in Progress, Internet-Draft, draft- 2648 ietf-tcpm-rfc793bis-25, 7 September 2021, 2649 . 2652 [I-D.ietf-tcpm-accurate-ecn] 2653 Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More 2654 Accurate ECN Feedback in TCP", Work in Progress, Internet- 2655 Draft, draft-ietf-tcpm-accurate-ecn-15, 12 July 2021, 2656 . 2659 [I-D.ietf-tsvwg-udp-options] 2660 Touch, J., "Transport Options for UDP", Work in Progress, 2661 Internet-Draft, draft-ietf-tsvwg-udp-options-13, 19 June 2662 2021, . 2665 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 2666 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 2667 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 2668 Model", Work in Progress, Internet-Draft, draft-ietf- 2669 i2nsf-nsf-monitoring-data-model-12, 17 November 2021, 2670 . 2673 10.2. Informative References 2675 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2676 DOI 10.17487/RFC2818, May 2000, 2677 . 2679 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2680 RFC 6691, DOI 10.17487/RFC6691, July 2012, 2681 . 2683 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2684 Morris, J., Hansen, M., and R. Smith, "Privacy 2685 Considerations for Internet Protocols", RFC 6973, 2686 DOI 10.17487/RFC6973, July 2013, 2687 . 2689 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2690 and J. Jeong, "Interface to Network Security Functions 2691 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2692 DOI 10.17487/RFC8192, July 2017, 2693 . 2695 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 2696 Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin, 2697 "I2NSF Network Security Function-Facing Interface YANG 2698 Data Model", Work in Progress, Internet-Draft, draft-ietf- 2699 i2nsf-nsf-facing-interface-dm-16, 13 November 2021, 2700 . 2703 [I-D.ietf-i2nsf-registration-interface-dm] 2704 Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Park, 2705 "I2NSF Registration Interface YANG Data Model", Work in 2706 Progress, Internet-Draft, draft-ietf-i2nsf-registration- 2707 interface-dm-13, 4 October 2021, 2708 . 2711 [IANA-Protocol-Numbers] 2712 "Assigned Internet Protocol Numbers", Available: 2713 https://www.iana.org/assignments/protocol- 2714 numbers/protocol-numbers.xhtml, September 2020. 2716 [IEEE802.3-2018] 2717 Committee, I. S., "IEEE 802.3-2018 - IEEE Standard for 2718 Ethernet", August 2018, 2719 . 2721 [Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and 2722 management of firewall policies", 2004. 2724 [Hirschman] 2725 Hirschman, L. and R. Gaizauskas, "Natural Language 2726 Question Answering: The View from Here", Natural Language 2727 Engineering 7:4, pgs 275-300, Cambridge University Press , 2728 November 2001. 2730 [Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns", 2731 ISBN 0-32-120068-3 , 2003. 2733 [Martin] Martin, R.C., "Agile Software Development, Principles, 2734 Patterns, and Practices", Prentice-Hall , ISBN: 2735 0-13-597444-5 , 2002. 2737 [OODMP] "https://www.oodesign.com/mediator-pattern.html". 2739 [OODOP] "https://www.oodesign.com/mediator-pattern.html". 2741 [OODSRP] "https://www.oodesign.com/mediator-pattern.html". 2743 Appendix A. Configuration Examples 2745 This section shows configuration examples of "ietf-i2nsf-capability" 2746 module for capabilities registration of general firewall. 2748 A.1. Example 1: Registration for the Capabilities of a General Firewall 2750 This section shows a configuration example for the capabilities 2751 registration of a general firewall in either an IPv4 network or an 2752 IPv6 network. 2754 2755 general_firewall 2756 2757 2758 next-header 2759 flow-direction 2760 source-address 2761 destination-address 2762 source-port-number 2763 destination-port-number 2764 source-port-number 2765 destination-port-number 2766 2767 2768 2769 pass 2770 drop 2771 mirror 2772 pass 2773 drop 2774 mirror 2775 2776 2778 Figure 4: Configuration XML for the Capabilities Registration of 2779 a General Firewall in an IPv4 Network 2781 Figure 4 shows the configuration XML for the capabilities 2782 registration of a general firewall as an NSF in an IPv4 network. Its 2783 capabilities are as follows. 2785 1. The name of the NSF is general_firewall. 2787 2. The NSF can inspect the IPv4 protocol header field, flow 2788 direction, source address(es), and destination address(es) 2790 3. The NSF can inspect the port number(s) and flow direction for the 2791 transport layer protocol, i.e., TCP and UDP. 2793 4. The NSF can control whether the packets are allowed to pass, 2794 drop, or mirror. 2796 2797 general_firewall 2798 2799 2800 next-header 2801 flow-direction 2802 source-address 2803 destination-address 2804 source-port-number 2805 destination-port-number 2806 source-port-number 2807 destination-port-number 2808 2809 2810 2811 pass 2812 drop 2813 mirror 2814 pass 2815 drop 2816 mirror 2817 2818 2820 Figure 5: Configuration XML for the Capabilities Registration of 2821 a General Firewall in an IPv6 Network 2823 In addition, Figure 5 shows the configuration XML for the 2824 capabilities registration of a general firewall as an NSF in an IPv6 2825 network. Its capabilities are as follows. 2827 1. The name of the NSF is general_firewall. 2829 2. The NSF can inspect IPv6 next header, flow direction, source 2830 address(es), and destination address(es) 2832 3. The NSF can inspect the port number(s) and flow direction for the 2833 transport layer protocol, i.e., TCP and UDP. 2835 4. The NSF can control whether the packets are allowed to pass, 2836 drop, or mirror. 2838 A.2. Example 2: Registration for the Capabilities of a Time-based 2839 Firewall 2841 This section shows a configuration example for the capabilities 2842 registration of a time-based firewall in either an IPv4 network or an 2843 IPv6 network. 2845 2846 time_based_firewall 2847 2848 absolute-time 2849 periodic-time 2850 2851 2852 2853 next-header 2854 flow-direction 2855 source-address 2856 destination-address 2857 2858 2859 2860 pass 2861 drop 2862 mirror 2863 pass 2864 drop 2865 mirror 2866 2867 2869 Figure 6: Configuration XML for the Capabilities Registration of 2870 a Time-based Firewall in an IPv4 Network 2872 Figure 6 shows the configuration XML for the capabilities 2873 registration of a time-based firewall as an NSF in an IPv4 network. 2874 Its capabilities are as follows. 2876 1. The name of the NSF is time_based_firewall. 2878 2. The NSF can execute the security policy rule according to 2879 absolute time and periodic time. 2881 3. The NSF can inspect the IPv4 protocol header field, flow 2882 direction, source address(es), and destination address(es). 2884 4. The NSF can control whether the packets are allowed to pass, 2885 drop, or mirror. 2887 2888 time_based_firewall 2889 2890 absolute-time 2891 periodic-time 2892 2893 2894 2895 next-header 2896 flow-direction 2897 source-address 2898 destination-address 2899 2900 2901 2902 pass 2903 drop 2904 mirror 2905 pass 2906 drop 2907 mirror 2908 2909 2911 Figure 7: Configuration XML for the Capabilities Registration of 2912 a Time-based Firewall in an IPv6 Network 2914 In addition, Figure 7 shows the configuration XML for the 2915 capabilities registration of a time-based firewall as an NSF in an 2916 IPv6 network. Its capabilities are as follows. 2918 1. The name of the NSF is time_based_firewall. 2920 2. The NSF can execute the security policy rule according to 2921 absolute time and periodic time. 2923 3. The NSF can inspect the IPv6 protocol header field, flow 2924 direction, source address(es), and destination address(es). 2926 4. The NSF can control whether the packets are allowed to pass, 2927 drop, or mirror. 2929 A.3. Example 3: Registration for the Capabilities of a Web Filter 2931 This section shows a configuration example for the capabilities 2932 registration of a web filter. 2934 2935 web_filter 2936 2937 2938 user-defined 2939 2940 2941 2942 pass 2943 drop 2944 mirror 2945 pass 2946 drop 2947 mirror 2948 2949 2951 Figure 8: Configuration XML for the Capabilities Registration of 2952 a Web Filter 2954 Figure 8 shows the configuration XML for the capabilities 2955 registration of a web filter as an NSF. Its capabilities are as 2956 follows. 2958 1. The name of the NSF is web_filter. 2960 2. The NSF can inspect a URL matched from a user-defined URL. User 2961 can specify their own URL. 2963 3. The NSF can control whether the packets are allowed to pass, 2964 drop, or mirror. 2966 4. Overall, the NSF can compare the URL of a packet to a user- 2967 defined database. The matched packet can be passed, dropped, or 2968 mirrored. 2970 A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE 2971 Filter 2973 This section shows a configuration example for the capabilities 2974 registration of a VoIP/VoLTE filter. 2976 2977 voip_volte_filter 2978 2979 2980 2981 call-id 2982 2983 2984 2985 2986 pass 2987 drop 2988 mirror 2989 pass 2990 drop 2991 mirror 2992 2993 2995 Figure 9: Configuration XML for the Capabilities Registration of 2996 a VoIP/VoLTE Filter 2998 Figure 9 shows the configuration XML for the capabilities 2999 registration of a VoIP/VoLTE filter as an NSF. Its capabilities are 3000 as follows. 3002 1. The name of the NSF is voip_volte_filter. 3004 2. The NSF can inspect a voice call id for VoIP/VoLTE packets. 3006 3. The NSF can control whether the packets are allowed to pass, 3007 drop, or mirror. 3009 A.5. Example 5: Registration for the Capabilities of a HTTP and HTTPS 3010 Flood Mitigator 3012 This section shows a configuration example for the capabilities 3013 registration of a HTTP and HTTPS flood mitigator. 3015 3016 DDoS_mitigator 3017 3018 3019 packet-rate 3020 byte-rate 3021 flow-rate 3022 3023 3024 3025 pass 3026 drop 3027 mirror 3028 pass 3029 drop 3030 mirror 3031 3032 3034 Figure 10: Configuration XML for the Capabilities Registration of 3035 a HTTP and HTTPS Flood Mitigator 3037 Figure 10 shows the configuration XML for the capabilities 3038 registration of a HTTP and HTTPS flood mitigator as an NSF. Its 3039 capabilities are as follows. 3041 1. The name of the NSF is DDoS_mitigator. 3043 2. The NSF can detect the amount of packet, flow, and byte rate in 3044 the network for potential DDoS Attack. 3046 3. The NSF can control whether the packets are allowed to pass, 3047 drop, or mirror. 3049 Appendix B. Acknowledgments 3051 This document is a product by the I2NSF Working Group (WG) including 3052 WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This 3053 document took advantage of the review and comments from the following 3054 experts: Roman Danyliw, Acee Lindem, Paul Wouters (SecDir), Michael 3055 Scharf (TSVART), Dan Romascanu (GenART), and Tom Petch. We authors 3056 sincerely appreciate their sincere efforts and kind help. 3058 This work was supported by Institute of Information & Communications 3059 Technology Planning & Evaluation (IITP) grant funded by the Korea 3060 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 3061 Security Intelligence Technology Development for the Customized 3062 Security Service Provisioning). This work was supported in part by 3063 the IITP grant funded by the MSIT (2020-0-00395, Standard Development 3064 of Blockchain based Network Management Automation Technology). 3066 Appendix C. Contributors 3068 The following are co-authors of this document: 3070 Patrick Lingga - Department of Electrical and Computer Engineering, 3071 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3072 16419, Republic of Korea, EMail: patricklink@skku.edu 3074 Liang Xia - Huawei, 101 Software Avenue, Nanjing, Jiangsu 210012, 3075 China, EMail: Frank.Xialiang@huawei.com 3077 Cataldo Basile - Politecnico di Torino, Corso Duca degli Abruzzi, 34, 3078 Torino, 10129, Italy, EMail: cataldo.basile@polito.it 3080 John Strassner - Huawei, 2330 Central Expressway, Santa Clara, CA 3081 95050, USA, EMail: John.sc.Strassner@huawei.com 3083 Diego R. Lopez - Telefonica I+D, Zurbaran, 12, Madrid, 28010, Spain, 3084 Email: diego.r.lopez@telefonica.com 3086 Hyoungshick Kim - Department of Computer Science and Engineering, 3087 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3088 16419, Republic of Korea, EMail: hyoung@skku.edu 3090 Daeyoung Hyun - Department of Computer Science and Engineering, 3091 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3092 16419, Republic of Korea, EMail: dyhyun@skku.edu 3094 Dongjin Hong - Department of Electronic, Electrical and Computer 3095 Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, 3096 Gyeonggi-do 16419, Republic of Korea, EMail: dong.jin@skku.edu 3098 Jung-Soo Park - Electronics and Telecommunications Research Institute 3099 218 Gajeong-Ro, Yuseong-Gu Daejeon, 34129 Republic of Korea EMail: 3100 pjs@etri.re.kr 3102 Tae-Jin Ahn Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 3103 Republic of Korea EMail: taejin.ahn@kt.com 3104 Se-Hui Lee Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 3105 Republic of Korea EMail: sehuilee@kt.com 3107 Authors' Addresses 3109 Susan Hares (editor) 3110 Huawei 3111 7453 Hickory Hill 3112 Saline, MI 48176 3113 United States of America 3115 Phone: +1-734-604-0332 3116 Email: shares@ndzh.com 3118 Jaehoon (Paul) Jeong (editor) 3119 Department of Computer Science and Engineering 3120 Sungkyunkwan University 3121 2066 Seobu-Ro, Jangan-Gu 3122 Suwon 3123 Gyeonggi-Do 3124 16419 3125 Republic of Korea 3127 Phone: +82 31 299 4957 3128 Email: pauljeong@skku.edu 3129 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3131 Jinyong (Tim) Kim 3132 Department of Electronic, Electrical and Computer Engineering 3133 Sungkyunkwan University 3134 2066 Seobu-Ro, Jangan-Gu 3135 Suwon 3136 Gyeonggi-Do 3137 16419 3138 Republic of Korea 3140 Phone: +82 10 8273 0930 3141 Email: timkim@skku.edu 3143 Robert Moskowitz 3144 HTT Consulting 3145 Oak Park, MI 3146 United States of America 3148 Phone: +1-248-968-9809 3149 Email: rgm@htt-consult.com 3151 Qiushi Lin 3152 Huawei 3153 Huawei Industrial Base 3154 Shenzhen 3155 Guangdong 518129, 3156 China 3158 Email: linqiushi@huawei.com