idnits 2.17.1 draft-ietf-i2nsf-capability-data-model-24.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (31 January 2022) is 814 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: 7 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: 4 August 2022 J. Kim 6 Sungkyunkwan University 7 R. Moskowitz 8 HTT Consulting 9 Q. Lin 10 Huawei 11 31 January 2022 13 I2NSF Capability YANG Data Model 14 draft-ietf-i2nsf-capability-data-model-24 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 4 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 . . . . . . . . . . . . . . . . . . . 51 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 53 70 10.2. Informative References . . . . . . . . . . . . . . . . . 57 71 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 59 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 . . . . . . . . . . . . . . . . . . . 61 76 A.3. Example 3: Registration for the Capabilities of a Web 77 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 63 78 A.4. Example 4: Registration for the Capabilities of a VoIP/ 79 VoLTE Filter . . . . . . . . . . . . . . . . . . . . . . 64 80 A.5. Example 5: Registration for the Capabilities of a HTTP and 81 HTTPS Flood Mitigator . . . . . . . . . . . . . . . . . . 65 82 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 66 83 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 67 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 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-31.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-31"{ 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-14: I2NSF NSF 821 Monitoring Interface YANG Data Model - Event"; 822 } 824 identity system-event { 825 base event; 826 description 827 "Identity for system event. System event (called alert) is 828 defined as a warning about any changes of configuration, any 829 access violation, the information of sessions and traffic 830 flows."; 831 reference 832 "draft-ietf-i2nsf-nsf-monitoring-data-model-14: I2NSF NSF 833 Monitoring Interface YANG Data Model - System event"; 834 } 836 identity system-alarm { 837 base event; 838 description 839 "Identity for system alarm. System alarm is defined as a 840 warning related to service degradation in system hardware."; 841 reference 842 "draft-ietf-i2nsf-nsf-monitoring-data-model-14: I2NSF NSF 843 Monitoring Interface YANG Data Model - System alarm"; 844 } 846 identity time { 847 base event; 848 description 849 "Identity for time capabilities"; 850 } 852 identity access-violation { 853 base system-event; 854 description 855 "Identity for access violation event. Access-violation system 856 event is an event when a user tries to access (read, write, 857 create, or delete) any information or execute commands 858 above their privilege (i.e., not-conformant with the 859 access profile)."; 860 reference 861 "draft-ietf-i2nsf-nsf-monitoring-data-model-14: I2NSF NSF 862 Monitoring Interface YANG Data Model - System event for access 863 violation"; 864 } 866 identity configuration-change { 867 base system-event; 868 description 869 "Identity for configuration change event. Configuration change is 870 a system event when a new configuration is added or an 871 existing configuration is modified."; 872 reference 873 "draft-ietf-i2nsf-nsf-monitoring-data-model-14: I2NSF NSF 874 Monitoring Interface YANG Data Model - System event for 875 configuration change"; 876 } 878 identity memory-alarm { 879 base system-alarm; 880 description 881 "Identity for memory alarm. Alarm when memory usage 882 exceeds a threshold."; 883 reference 884 "draft-ietf-i2nsf-nsf-monitoring-data-model-14: I2NSF NSF 885 Monitoring Interface YANG Data Model - System alarm for memory"; 886 } 888 identity cpu-alarm { 889 base system-alarm; 890 description 891 "Identity for CPU alarm. CPU is the Central Processing Unit 892 that executes basic operations of the system. A cpu-alarm 893 is emitted when the CPU usage is exceeding the threshold."; 894 reference 895 "draft-ietf-i2nsf-nsf-monitoring-data-model-14: I2NSF NSF 896 Monitoring YANG Data Model - System alarm for CPU"; 897 } 899 identity disk-alarm { 900 base system-alarm; 901 description 902 "Identity for disk alarm. Disk is the hardware to store 903 information for a long period, i.e., Hard Disk and Solid-State 904 Drive. A disk-alarm is emitted when the disk usage is 905 exceeding the threshold."; 906 reference 907 "draft-ietf-i2nsf-nsf-monitoring-data-model-14: I2NSF NSF 908 Monitoring Interface YANG Data Model - System alarm for disk"; 909 } 911 identity hardware-alarm { 912 base system-alarm; 913 description 914 "Identity for hardware alarm. A hardware alarm is emitted 915 when a problem of hardware (e.g., CPU, memory, disk, or 916 interface) is detected."; 917 reference 918 "draft-ietf-i2nsf-nsf-monitoring-data-model-14: I2NSF NSF 919 Monitoring Interface YANG Data Model - System alarm for 920 hardware"; 921 } 922 identity interface-alarm { 923 base system-alarm; 924 description 925 "Identity for interface alarm. Interface is the network 926 interface for connecting a device with the network. The 927 interface-alarm is emitted when the state of the interface 928 is changed."; 929 reference 930 "draft-ietf-i2nsf-nsf-monitoring-data-model-14: I2NSF NSF 931 Monitoring Interface YANG Data Model - System alarm for 932 interface"; 933 } 935 identity absolute-time { 936 base time; 937 description 938 "absolute time capabilities. 939 If a network security function has the absolute time 940 capability, the network security function supports 941 rule execution according to absolute time."; 942 } 944 identity periodic-time { 945 base time; 946 description 947 "periodic time capabilities. 948 If a network security function has the periodic time 949 capability, the network security function supports 950 rule execution according to periodic time."; 951 } 953 identity device-type { 954 description 955 "Identity for device type condition capability. The capability 956 for matching the destination device type."; 957 } 959 identity computer { 960 base device-type; 961 description 962 "Identity for computer such as personal computer (PC) 963 and server"; 964 } 966 identity mobile-phone { 967 base device-type; 968 description 969 "Identity for mobile-phone such as smartphone and 970 cellphone"; 971 } 973 identity voip-volte-phone { 974 base device-type; 975 description 976 "Identity for voip-volte-phone"; 977 } 979 identity tablet { 980 base device-type; 981 description 982 "Identity for tablet"; 983 } 985 identity network-infrastructure-device { 986 base device-type; 987 description 988 "Identity for network infrastructure devices 989 such as switch, router, and access point"; 990 } 992 identity iot { 993 base device-type; 994 description 995 "Identity for Internet of Things (IoT) devices 996 such as sensors, actuators, and low-power 997 low-capacity computing devices"; 998 } 1000 identity ot { 1001 base device-type; 1002 description 1003 "Identity for Operational Technology (OT) devices 1004 also known as industrial control systems such as 1005 programmable logic controllers (PLCs), digital 1006 oscilloscopes, and building management systems (BMS)"; 1007 } 1009 identity vehicle { 1010 base device-type; 1011 description 1012 "Identity for vehicle that connects to and shares 1013 data through the Internet"; 1014 } 1016 identity user-condition { 1017 description 1018 "Base identity for user condition capability. This is the 1019 capability of mapping user(s) into their corresponding IP 1020 address"; 1021 } 1023 identity user { 1024 base user-condition; 1025 description 1026 "Identity for user condition capability. 1027 A user (e.g., employee) can be mapped to an IP address of 1028 a computing device (e.g., computer, laptop, and virtual 1029 machine) which the user is using."; 1030 } 1032 identity group { 1033 base user-condition; 1034 description 1035 "Identity for group condition capability. 1036 A group (e.g., employees) can be mapped to multiple IP 1037 addresses of computing devices (e.g., computers, laptops, 1038 and virtual machines) which the group is using."; 1039 } 1041 identity geographic-location { 1042 description 1043 "Identity for geographic location condition capability"; 1044 reference 1045 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1046 An access control for a geographical location (i.e., 1047 geolocation) that has the corresponding IP prefix."; 1048 } 1050 identity source-location { 1051 base geographic-location; 1052 description 1053 "Identity for source geographic location condition capability"; 1054 reference 1055 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1056 An access control for a geographical location (i.e., 1057 geolocation) that has the corresponding IP prefix."; 1058 } 1060 identity destination-location { 1061 base geographic-location; 1062 description 1063 "Identity for destination geographic location condition 1064 capability"; 1065 reference 1066 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 1067 An access control for a geographical location (i.e., 1068 geolocation) that has the corresponding IP prefix."; 1069 } 1071 identity directional { 1072 description 1073 "Base identity for directional traffic flow capability"; 1074 reference 1075 "RFC 5103: Bidirectional Flow Export Using IP Flow Information 1076 Export (IPFIX) - Terminology Unidirectional and Bidirectional 1077 Flow"; 1078 } 1080 identity unidirectional { 1081 base directional; 1082 description 1083 "Identity for unidirectional traffic flow."; 1084 reference 1085 "RFC 5103: Bidirectional Flow Export Using IP Flow Information 1086 Export (IPFIX) - Terminology Unidirectional Flow"; 1087 } 1089 identity bidirectional { 1090 base directional; 1091 description 1092 "Identity for bidirectional traffic flow."; 1093 reference 1094 "RFC 5103: Bidirectional Flow Export Using IP Flow Information 1095 Export (IPFIX) - Terminology Bidirectional Flow"; 1096 } 1098 identity protocol { 1099 description 1100 "Base identity for protocols"; 1101 } 1103 identity ethernet { 1104 base protocol; 1105 description 1106 "Base identity for Ethernet protocol."; 1107 } 1109 identity source-mac-address { 1110 base ethernet; 1111 description 1112 "Identity for the capability of matching Media Access Control 1113 (MAC) source address(es) condition capability."; 1115 reference 1116 "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; 1117 } 1119 identity destination-mac-address { 1120 base ethernet; 1121 description 1122 "Identity for the capability of matching Media Access Control 1123 (MAC) destination address(es) condition capability."; 1124 reference 1125 "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; 1126 } 1128 identity ether-type { 1129 base ethernet; 1130 description 1131 "Identity for the capability of matching the EtherType in 1132 Ethernet II and Length in Ethernet 802.3 of a packet."; 1133 reference 1134 "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; 1135 } 1137 identity ip { 1138 base protocol; 1139 description 1140 "Base identity for internet/network layer protocol, 1141 e.g., IPv4, IPv6, and ICMP."; 1142 } 1144 identity ipv4 { 1145 base ip; 1146 description 1147 "Base identity for IPv4 condition capability"; 1148 reference 1149 "RFC 791: Internet Protocol"; 1150 } 1152 identity ipv6 { 1153 base ip; 1154 description 1155 "Base identity for IPv6 condition capabilities"; 1156 reference 1157 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1158 Specification"; 1159 } 1161 identity dscp { 1162 base ipv4; 1163 base ipv6; 1164 description 1165 "Identity for the capability of matching IPv4 annd IPv6 1166 Differentiated Services Codepoint (DSCP) condition"; 1167 reference 1168 "RFC 791: Internet Protocol - Type of Service 1169 RFC 2474: Definition of the Differentiated 1170 Services Field (DS Field) in the IPv4 and 1171 IPv6 Headers 1172 RFC 8200: Internet Protocol, Version 6 (IPv6) 1173 Specification - Traffic Class"; 1174 } 1176 identity ecn { 1177 base ipv4; 1178 base ipv6; 1179 description 1180 "Identity for the capability of matching IPv4 annd IPv6 1181 Explicit Congestion Notification (ECN) condition"; 1182 reference 1183 "RFC 3168: The Addition of Explicit Congestion 1184 Notification (ECN) to IP."; 1185 } 1187 identity total-length { 1188 base ipv4; 1189 base ipv6; 1190 description 1191 "Identity for the capability of matching IPv4 Total Length 1192 header field or IPv6 Payload Length header field. 1194 IPv4 Total Length is the length of datagram, measured in 1195 octets, including internet header and data. 1197 IPv6 Payload Length is the length of the IPv6 payload, i.e., 1198 the rest of the packet following the IPv6 header, measured in 1199 octets."; 1200 reference 1201 "RFC 791: Internet Protocol - Total Length 1202 RFC 8200: Internet Protocol, Version 6 (IPv6) 1203 Specification - Payload Length"; 1204 } 1206 identity ttl { 1207 base ipv4; 1208 base ipv6; 1209 description 1210 "Identity for the capability of matching IPv4 Time-To-Live 1211 (TTL) or IPv6 Hop Limit."; 1212 reference 1213 "RFC 791: Internet Protocol - Time To Live (TTL) 1214 RFC 8200: Internet Protocol, Version 6 (IPv6) 1215 Specification - Hop Limit"; 1216 } 1218 identity next-header { 1219 base ipv4; 1220 base ipv6; 1221 description 1222 "Identity for the capability of matching IPv4 Protocol Field or 1223 equivalent to IPv6 Next Header."; 1224 reference 1225 "IANA Website: Assigned Internet Protocol Numbers 1226 - Protocol Number for IPv4 1227 RFC 791: Internet Protocol - Protocol 1228 RFC 8200: Internet Protocol, Version 6 (IPv6) 1229 Specification - Next Header"; 1230 } 1232 identity source-address { 1233 base ipv4; 1234 base ipv6; 1235 description 1236 "Identity for the capability of matching IPv4 or IPv6 source 1237 address(es) condition capability."; 1238 reference 1239 "RFC 791: Internet Protocol - Address 1240 RFC 8200: Internet Protocol, Version 6 (IPv6) 1241 Specification - Source Address"; 1242 } 1244 identity destination-address { 1245 base ipv4; 1246 base ipv6; 1247 description 1248 "Identity for the capability of matching IPv4 or IPv6 1249 destination address(es) condition capability."; 1250 reference 1251 "RFC 791: Internet Protocol - Address 1252 RFC 8200: Internet Protocol, Version 6 (IPv6) 1253 Specification - Destination Address"; 1254 } 1256 identity flow-direction { 1257 base ipv4; 1258 base ipv6; 1259 description 1260 "Identity for flow direction of matching IPv4/IPv6 source 1261 or destination address(es) condition capability where a flow's 1262 direction is either unidirectional or bidirectional"; 1263 reference 1264 "RFC 791: Internet Protocol 1265 RFC 8200: Internet Protocol, Version 6 (IPv6) 1266 Specification"; 1267 } 1269 identity header-length { 1270 base ipv4; 1271 description 1272 "Identity for matching IPv4 header-length (IHL) 1273 condition capability"; 1274 reference 1275 "RFC 791: Internet Protocol - Header Length"; 1276 } 1278 identity identification { 1279 base ipv4; 1280 description 1281 "Identity for IPv4 identification condition capability. 1282 IPv4 ID field is used for fragmentation and reassembly."; 1283 reference 1284 "RFC 791: Internet Protocol - Identification 1285 RFC 6864: Updated Specification of the IPv4 ID Field - 1286 Fragmentation and Reassembly"; 1287 } 1289 identity fragment-flags { 1290 base ipv4; 1291 description 1292 "Identity for IPv4 fragment flags condition capability"; 1293 reference 1294 "RFC 791: Internet Protocol - Fragmentation Flags"; 1295 } 1297 identity fragment-offset { 1298 base ipv4; 1299 description 1300 "Identity for matching IPv4 fragment offset 1301 condition capability"; 1302 reference 1303 "RFC 791: Internet Protocol - Fragmentation Offset"; 1304 } 1306 identity flow-label { 1307 base ipv6; 1308 description 1309 "Identity for matching IPv6 flow label 1310 condition capability"; 1311 reference 1312 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1313 Specification - Flow Label 1314 RFC 6437: IPv6 Flow Label Specification"; 1315 } 1317 identity header-order { 1318 base ipv6; 1319 description 1320 "Identity for IPv6 extension header order condition 1321 capability"; 1322 reference 1323 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1324 Specification - Extension Header Order"; 1325 } 1327 identity hop-by-hop { 1328 base ipv6; 1329 description 1330 "Identity for IPv6 hop by hop options header 1331 condition capability"; 1332 reference 1333 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1334 Specification - Hop-by-Hop Options Header"; 1335 } 1337 identity routing-header { 1338 base ipv6; 1339 description 1340 "Identity for IPv6 routing header condition 1341 capability"; 1342 reference 1343 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1344 Specification - Routing Header"; 1345 } 1347 identity fragment-header { 1348 base ipv6; 1349 description 1350 "Identity for IPv6 fragment header condition 1351 capability"; 1352 reference 1353 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1354 Specification - Fragment Header"; 1356 } 1358 identity destination-options { 1359 base ipv6; 1360 description 1361 "Identity for IPv6 destination options condition 1362 capability"; 1363 reference 1364 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1365 Specification - Destination Options"; 1366 } 1368 identity icmp { 1369 base protocol; 1370 description 1371 "Base identity for ICMPv4 and ICMPv6 condition capability"; 1372 reference 1373 "RFC 792: Internet Control Message Protocol 1374 RFC 4443: Internet Control Message Protocol (ICMPv6) 1375 for the Internet Protocol Version 6 (IPv6) Specification 1376 - ICMPv6"; 1377 } 1379 identity icmpv4 { 1380 base icmp; 1381 description 1382 "Base identity for ICMPv4 condition capability"; 1383 reference 1384 "RFC 792: Internet Control Message Protocol"; 1385 } 1387 identity icmpv6 { 1388 base icmp; 1389 description 1390 "Base identity for ICMPv6 condition capability"; 1391 reference 1392 "RFC 4443: Internet Control Message Protocol (ICMPv6) 1393 for the Internet Protocol Ver sion 6 (IPv6) Specification 1394 - ICMPv6"; 1395 } 1397 identity type { 1398 base icmpv4; 1399 base icmpv6; 1400 description 1401 "Identity for ICMPv4 and ICMPv6 type condition capability"; 1402 reference 1403 "RFC 792: Internet Control Message Protocol 1404 RFC 4443: Internet Control Message Protocol (ICMPv6) 1405 for the Internet Protocol Version 6 (IPv6) Specification 1406 - ICMPv6"; 1407 } 1409 identity code { 1410 base icmpv4; 1411 base icmpv6; 1412 description 1413 "Identity for ICMPv4 and ICMPv6 code condition capability"; 1414 reference 1415 "RFC 792: Internet Control Message Protocol 1416 RFC 4443: Internet Control Message Protocol (ICMPv6) 1417 for the Internet Protocol Version 6 (IPv6) Specification 1418 - ICMPv6"; 1419 } 1421 identity transport-protocol { 1422 base protocol; 1423 description 1424 "Base identity for Layer 4 protocol condition capabilities, 1425 e.g., TCP, UDP, SCTP, and DCCP"; 1426 } 1428 identity tcp { 1429 base transport-protocol; 1430 description 1431 "Base identity for TCP condition capabilities"; 1432 reference 1433 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1434 (TCP) Specification"; 1435 } 1437 identity udp { 1438 base transport-protocol; 1439 description 1440 "Base identity for UDP condition capabilities"; 1441 reference 1442 "RFC 768: User Datagram Protocol"; 1443 } 1445 identity sctp { 1446 base transport-protocol; 1447 description 1448 "Identity for SCTP condition capabilities"; 1449 reference 1450 "RFC 4960: Stream Control Transmission Protocol"; 1451 } 1452 identity dccp { 1453 base transport-protocol; 1454 description 1455 "Identity for DCCP condition capabilities"; 1456 reference 1457 "RFC 4340: Datagram Congestion Control Protocol"; 1458 } 1460 identity source-port-number { 1461 base tcp; 1462 base udp; 1463 base sctp; 1464 base dccp; 1465 description 1466 "Identity for matching TCP, UDP, SCTP, and DCCP source port 1467 number condition capability"; 1468 reference 1469 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1470 (TCP) Specification 1471 RFC 768: User Datagram Protocol 1472 RFC 4960: Stream Control Transmission Protocol 1473 RFC 4340: Datagram Congestion Control Protocol"; 1474 } 1476 identity destination-port-number { 1477 base tcp; 1478 base udp; 1479 base sctp; 1480 base dccp; 1481 description 1482 "Identity for matching TCP, UDP, SCTP, and DCCP destination 1483 port number condition capability"; 1484 reference 1485 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1486 (TCP) Specification"; 1487 } 1489 identity flags { 1490 base tcp; 1491 description 1492 "Identity for TCP control bits (flags) condition capability"; 1493 reference 1494 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1495 (TCP) Specification - TCP Header Flags 1496 RFC 3168: The Addition of Explicit Congestion Notification 1497 (ECN) to IP - ECN-Echo (ECE) Flag and Congestion Window 1498 Reduced (CWR) Flag 1499 draft-ietf-tcpm-accurate-ecn-15: More Accurate ECN Feedback 1500 in TCP - ECN-Echo (ECE) Flag and Congestion Window Reduced 1501 (CWR) Flag"; 1502 } 1504 identity options { 1505 base tcp; 1506 description 1507 "Identity for TCP options condition capability"; 1508 reference 1509 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1510 (TCP) Specification 1511 RFC 6691: TCP Options and Maximum Segment Size 1512 RFC 7323: TCP Extensions for High Performance"; 1513 } 1515 identity length { 1516 base tcp; 1517 base udp; 1518 description 1519 "Identity for matching TCP or UDP length condition capability. 1520 TCP length is the length in octets of this TCP segment including 1521 the TCP header and the TCP payload. 1522 The UDP length is the length in octets of this user datagram 1523 including this header and the datagram. 1524 The UDP length can be smaller than the IP transport 1525 length for UDP transport layer options."; 1526 reference 1527 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1528 (TCP) Specification - Data Offset 1529 RFC 768: User Datagram Protocol - Length 1530 draft-ietf-tsvwg-udp-options: Transport Options for UDP"; 1531 } 1533 identity reserved { 1534 base tcp; 1535 description 1536 "Identity for TCP header reserved field condition capability. 1537 The set of control bits reserved for future used. The control 1538 bits are also known as flags. Must be zero in generated 1539 segments and must be ignored in received segments, if 1540 corresponding future features are unimplemented by the 1541 sending or receiving host."; 1542 reference 1543 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1544 (TCP) Specification"; 1545 } 1547 identity window-size { 1548 base tcp; 1549 description 1550 "Identity for TCP header Window field condition capability. 1551 The number of data octets beginning with the one indicated 1552 in the acknowledgment field that the sender of this segment 1553 is willing to accept."; 1554 reference 1555 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1556 (TCP) Specification"; 1557 } 1559 identity urgent-pointer { 1560 base tcp; 1561 description 1562 "Identity for TCP Urgent Pointer header field condition 1563 capability. The Urgent Pointer field in TCP describes the 1564 current value of urgent pointer as a positive offset from 1565 the sequence number in this segment. The urgent pointer 1566 points to the sequence number of the octet following the 1567 urgent data. This field is only be interpreted in segments 1568 with the URG control bit set."; 1569 reference 1570 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1571 (TCP) Specification"; 1572 } 1574 identity chunk-type { 1575 base sctp; 1576 description 1577 "Identity for SCTP chunk type condition capability"; 1578 reference 1579 "RFC 4960: Stream Control Transmission Protocol - Chunk Type"; 1580 } 1582 identity service-code { 1583 base dccp; 1584 description 1585 "Identity for DCCP Service Code condition capabilitiy"; 1586 reference 1587 "RFC 4340: Datagram Congestion Control Protocol 1588 RFC 5595: The Datagram Congestion Control Protocol (DCCP) 1589 Service Codes 1590 RFC 6335: Internet Assigned Numbers Authority (IANA) 1591 Procedures for the Management of the Service Name and 1592 Transport Protocol Port Number Registry - Service Code"; 1593 } 1595 identity application-protocol { 1596 base protocol; 1597 description 1598 "Base identity for Application protocol"; 1599 } 1601 identity http { 1602 base application-protocol; 1603 description 1604 "The identity for Hypertext Transfer Protocol."; 1605 reference 1606 "RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1607 Syntax and Routing 1608 RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1609 and Content"; 1610 } 1612 identity https { 1613 base application-protocol; 1614 description 1615 "The identity for Hypertext Transfer Protocol Secure."; 1616 reference 1617 "RFC 2818: HTTP over TLS (HTTPS) 1618 RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1619 Syntax and Routing 1620 RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1621 and Content"; 1622 } 1624 identity ftp { 1625 base application-protocol; 1626 description 1627 "The identity for File Transfer Protocol."; 1628 reference 1629 "RFC 959: File Transfer Protocol (FTP)"; 1630 } 1632 identity ssh { 1633 base application-protocol; 1634 description 1635 "The identity for Secure Shell (SSH) protocol."; 1636 reference 1637 "RFC 4250: The Secure Shell (SSH) Protocol"; 1638 } 1640 identity telnet { 1641 base application-protocol; 1642 description 1643 "The identity for telnet."; 1645 reference 1646 "RFC 854: Telnet Protocol"; 1647 } 1649 identity smtp { 1650 base application-protocol; 1651 description 1652 "The identity for Simple Mail Transfer Protocol."; 1653 reference 1654 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1655 } 1657 identity pop3 { 1658 base application-protocol; 1659 description 1660 "The identity for Post Office Protocol 3. This includes 1661 POP3 over TLS"; 1662 reference 1663 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1664 } 1666 identity imap { 1667 base application-protocol; 1668 description 1669 "The identity for Internet Message Access Protocol. This 1670 includes IMAP over TLS"; 1671 reference 1672 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 1673 4rev2"; 1674 } 1676 identity action { 1677 description 1678 "Base identity for action capability"; 1679 } 1681 identity log-action { 1682 base action; 1683 description 1684 "Base identity for log-action capability"; 1685 } 1687 identity ingress-action { 1688 base action; 1689 description 1690 "Base identity for ingress-action capability"; 1691 reference 1692 "RFC 8329: Framework for Interface to Network Security 1693 Functions - Section 7.2"; 1694 } 1696 identity egress-action { 1697 base action; 1698 description 1699 "Base identity for egress-action capability"; 1700 reference 1701 "RFC 8329: Framework for Interface to Network Security 1702 Functions - Section 7.2"; 1703 } 1705 identity default-action { 1706 base action; 1707 description 1708 "Base identity for default-action capability"; 1709 } 1711 identity rule-log { 1712 base log-action; 1713 description 1714 "Identity for rule log-action capability. 1715 Log the received packet based on the rule"; 1716 } 1718 identity session-log { 1719 base log-action; 1720 description 1721 "Identity for session log-action capability. 1722 Log the received packet based on the session."; 1723 } 1725 identity pass { 1726 base ingress-action; 1727 base egress-action; 1728 base default-action; 1729 description 1730 "Identity for pass action capability. The pass action allows 1731 packet or flow to go through the NSF entering or exiting the 1732 internal network."; 1733 } 1735 identity drop { 1736 base ingress-action; 1737 base egress-action; 1738 base default-action; 1739 description 1740 "Identity for drop action capability. The drop action denies 1741 a packet to go through the NSF entering or exiting the 1742 internal network without sending any response back to the 1743 source."; 1744 } 1746 identity reject { 1747 base ingress-action; 1748 base egress-action; 1749 base default-action; 1750 description 1751 "Identity for reject action capability. The reject action 1752 denies a packet to go through the NSF entering or exiting the 1753 internal network and send a response back to the source. 1754 The response depends on the packet and implementation. 1755 For example, a TCP packet is rejected with TCP RST response 1756 or a UDP packet may be rejected with ICMP message Type 3 1757 Code 3 response, i.e., Destination Unreachable: Destination 1758 port unreachable."; 1759 } 1761 identity mirror { 1762 base ingress-action; 1763 base egress-action; 1764 base default-action; 1765 description 1766 "Identity for mirror action capability. The mirror action 1767 copies packet and send it to the monitoring entity while still 1768 allow the packet or flow to go through the NSF."; 1769 } 1771 identity rate-limit { 1772 base ingress-action; 1773 base egress-action; 1774 base default-action; 1775 description 1776 "Identity for rate limiting action capability. The rate limit 1777 action limits the number of packets or flows that can go 1778 through the NSF by dropping packets or flows (randomly or 1779 systematically)."; 1780 } 1782 identity invoke-signaling { 1783 base egress-action; 1784 description 1785 "Identity for invoke signaling action capability"; 1786 } 1788 identity tunnel-encapsulation { 1789 base egress-action; 1790 description 1791 "Identity for tunnel encapsulation action capability"; 1792 } 1794 identity forwarding { 1795 base egress-action; 1796 description 1797 "Identity for forwarding action capability"; 1798 } 1800 identity transformation { 1801 base egress-action; 1802 description 1803 "Identity for transformation action capability"; 1804 } 1806 identity resolution-strategy { 1807 description 1808 "Base identity for resolution strategy capability"; 1809 } 1811 identity fmr { 1812 base resolution-strategy; 1813 description 1814 "Identity for First Matching Rule (FMR) resolution 1815 strategy capability"; 1816 } 1818 identity lmr { 1819 base resolution-strategy; 1820 description 1821 "Identity for Last Matching Rule (LMR) resolution 1822 strategy capability"; 1823 } 1825 identity pmr { 1826 base resolution-strategy; 1827 description 1828 "Identity for Prioritized Matching Rule (PMR) resolution 1829 strategy capability"; 1830 } 1832 identity pmre { 1833 base resolution-strategy; 1834 description 1835 "Identity for Prioritized Matching Rule with Errors (PMRE) 1836 resolution strategy capability"; 1838 } 1840 identity pmrn { 1841 base resolution-strategy; 1842 description 1843 "Identity for Prioritized Matching Rule with No Errors (PMRN) 1844 resolution strategy capability"; 1845 } 1847 identity advanced-nsf { 1848 description 1849 "Base identity for advanced Network Security Function (NSF) 1850 capability."; 1851 } 1853 identity content-security-control { 1854 base advanced-nsf; 1855 description 1856 "Base identity for content security control. Content security 1857 control is an NSF that evaluates a packet's payload such as 1858 Intrusion Prevention System (IPS), URL-Filtering, Antivirus, 1859 and VoIP/VoLTE Filter."; 1860 } 1862 identity attack-mitigation-control { 1863 base advanced-nsf; 1864 description 1865 "Base identity for attack mitigation control. Attack mitigation 1866 control is an NSF that mitigates an attack such as anti-DDoS 1867 or DDoS-mitigator."; 1868 } 1870 identity ips { 1871 base content-security-control; 1872 description 1873 "Base identity for IPS (Intrusion Prevention System) capability 1874 that prevents malicious activity within a network"; 1875 } 1877 identity url-filtering { 1878 base content-security-control; 1879 description 1880 "Base identity for url filtering capability that limits access 1881 by comparing the web traffic's URL with the URLs for web 1882 filtering in a database"; 1883 } 1885 identity anti-virus { 1886 base content-security-control; 1887 description 1888 "Base identity for anti-virus capability to protect the network 1889 by detecting and removing viruses."; 1890 } 1892 identity voip-volte-filtering { 1893 base content-security-control; 1894 description 1895 "Base identity for advanced NSF VoIP/VoLTE Security Service 1896 capability to filter the VoIP/VoLTE packets or flows."; 1897 reference 1898 "RFC 3261: SIP: Session Initiation Protocol"; 1899 } 1901 identity anti-ddos { 1902 base attack-mitigation-control; 1903 description 1904 "Base identity for advanced NSF Anti-DDoS Attack or DDoS 1905 Mitigator capability."; 1906 } 1908 identity packet-rate { 1909 base anti-ddos; 1910 description 1911 "Identity for advanced NSF Anti-DDoS detecting Packet Rate 1912 Capability where a packet rate is defined as the arrival rate 1913 of Packets toward a victim destination node. The NSF with 1914 this capability can detect the incoming packet rate and create 1915 an alert if the rate exceeds the threshold."; 1917 } 1919 identity flow-rate { 1920 base anti-ddos; 1921 description 1922 "Identity for advanced NSF Anti-DDoS detecting Flow Rate 1923 Capability where a flow rate is defined as the arrival rate of 1924 flows towards a victim destination node. The NSF with this 1925 capability can detect the incoming flow rate and create an 1926 alert if the rate exceeds the threshold."; 1927 } 1929 identity byte-rate { 1930 base anti-ddos; 1931 description 1932 "Identity for advanced NSF Anti-DDoS detecting Byte Rate 1933 Capability where a byte rate is defined as the arrival rate of 1934 Bytes toward a victim destination node. The NSF with this 1935 capability can detect the incoming byte rate and create an 1936 alert if the rate exceeds the threshold."; 1937 } 1939 identity signature-set { 1940 base ips; 1941 description 1942 "Identity for the capability of IPS to set the signature. 1943 Signature is a set of rules to detect an intrusive activity."; 1944 reference 1945 "RFC 4766: Intrusion Detection Message Exchange Requirements - 1946 Section 2.2.13"; 1947 } 1949 identity exception-signature { 1950 base ips; 1951 description 1952 "Identity for the capability of IPS to exclude signatures from 1953 detecting the intrusion."; 1954 reference 1955 "RFC 4766: Intrusion Detection Message Exchange Requirements - 1956 Section 2.2.13"; 1957 } 1959 identity detect { 1960 base anti-virus; 1961 description 1962 "Identity for advanced NSF Antivirus capability to detect 1963 viruses using a security profile. The security profile is used 1964 to scan threats, such as virus, malware, and spyware. The NSF 1965 should be able to update the security profile."; 1966 } 1968 identity exception-files { 1969 base anti-virus; 1970 description 1971 "Identity for advanced NSF Antivirus capability to exclude a 1972 certain file type or name from detection."; 1973 } 1975 identity pre-defined { 1976 base url-filtering; 1977 description 1978 "Identity for pre-defined URL Database condition capability 1979 where URL database is a public database for URL filtering."; 1980 } 1981 identity user-defined { 1982 base url-filtering; 1983 description 1984 "Identity for user-defined URL Database condition capability 1985 that allows a user's manual addition of URLs for URL 1986 filtering."; 1987 } 1989 identity call-id { 1990 base voip-volte-filtering; 1991 description 1992 "Identity for advanced NSF VoIP/VoLTE Call Identifier (ID) 1993 capability."; 1994 } 1996 identity user-agent { 1997 base voip-volte-filtering; 1998 description 1999 "Identity for advanced NSF VoIP/VoLTE User Agent capability."; 2000 } 2002 /* 2003 * Grouping 2004 */ 2006 grouping nsf-capabilities { 2007 description 2008 "Network Security Function (NSF) Capabilities"; 2009 reference 2010 "RFC 8329: Framework for Interface to Network Security 2011 Functions - I2NSF Flow Security Policy Structure."; 2013 leaf-list directional-capabilities { 2014 type identityref { 2015 base directional; 2016 } 2017 description 2018 "The capability of an NSF for handling directional traffic 2019 flow (i.e., unidirectional or bidirectional traffic flow)."; 2020 } 2022 container event-capabilities { 2023 description 2024 "Capabilities of events. 2025 If a network security function has the event capabilities, 2026 the network security function supports rule execution 2027 according to system event and system alarm."; 2029 reference 2030 "RFC 8329: Framework for Interface to Network Security 2031 Functions - Section 7. 2032 draft-ietf-i2nsf-nsf-monitoring-data-model-14: I2NSF 2033 NSF Monitoring Interface YANG Data Model - System Alarm and 2034 System Events."; 2036 leaf-list system-event-capability { 2037 type identityref { 2038 base system-event; 2039 } 2040 description 2041 "System event capabilities"; 2042 } 2044 leaf-list system-alarm-capability { 2045 type identityref { 2046 base system-alarm; 2047 } 2048 description 2049 "System alarm capabilities"; 2050 } 2052 leaf-list time-capabilities { 2053 type identityref { 2054 base time; 2055 } 2056 description 2057 "The capabilities for activating the policy within a 2058 specific time."; 2059 } 2060 } 2062 container condition-capabilities { 2063 description 2064 "Conditions capabilities."; 2065 container generic-nsf-capabilities { 2066 description 2067 "Conditions capabilities. 2068 If a network security function has the condition 2069 capabilities, the network security function 2070 supports rule execution according to conditions of 2071 IPv4, IPv6, TCP, UDP, SCTP, DCCP, ICMP, or ICMPv6."; 2072 reference 2073 "RFC 768: User Datagram Protocol - UDP. 2074 RFC 791: Internet Protocol - IPv4. 2075 RFC 792: Internet Control Message Protocol - ICMP. 2076 RFC 4443: Internet Control Message Protocol (ICMPv6) 2077 for the Internet Protocol Version 6 (IPv6) Specification 2078 - ICMPv6. 2079 RFC 4960: Stream Control Transmission Protocol - SCTP. 2080 RFC 8200: Internet Protocol, Version 6 (IPv6) 2081 Specification - IPv6. 2082 RFC 8329: Framework for Interface to Network Security 2083 Functions - I2NSF Flow Security Policy Structure. 2084 draft-ietf-tcpm-rfc793bis-25: Transmission Control 2085 Protocol (TCP) Specification"; 2087 leaf-list ethernet-capability { 2088 type identityref { 2089 base ethernet; 2090 } 2091 description 2092 "Media Access Control (MAC) capabilities"; 2093 reference 2094 "IEEE 802.3: IEEE Standard for Ethernet"; 2095 } 2097 leaf-list ipv4-capability { 2098 type identityref { 2099 base ipv4; 2100 } 2101 description 2102 "IPv4 packet capabilities"; 2103 reference 2104 "RFC 791: Internet Protocol"; 2105 } 2107 leaf-list ipv6-capability { 2108 type identityref { 2109 base ipv6; 2110 } 2111 description 2112 "IPv6 packet capabilities"; 2113 reference 2114 "RFC 8200: Internet Protocol, Version 6 (IPv6) 2115 Specification - IPv6"; 2116 } 2118 leaf-list icmpv4-capability { 2119 type identityref { 2120 base icmpv4; 2121 } 2122 description 2123 "ICMPv4 packet capabilities"; 2124 reference 2125 "RFC 792: Internet Control Message Protocol - ICMP"; 2126 } 2128 leaf-list icmpv6-capability { 2129 type identityref { 2130 base icmpv6; 2131 } 2132 description 2133 "ICMPv6 packet capabilities"; 2134 reference 2135 "RFC 4443: Internet Control Message Protocol (ICMPv6) 2136 for the Internet Protocol Version 6 (IPv6) Specification 2137 - ICMPv6"; 2138 } 2140 leaf-list tcp-capability { 2141 type identityref { 2142 base tcp; 2143 } 2144 description 2145 "TCP packet capabilities"; 2146 reference 2147 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 2148 Protocol (TCP) Specification"; 2149 } 2151 leaf-list udp-capability { 2152 type identityref { 2153 base udp; 2154 } 2155 description 2156 "UDP packet capabilities"; 2157 reference 2158 "RFC 768: User Datagram Protocol - UDP"; 2159 } 2161 leaf-list sctp-capability { 2162 type identityref { 2163 base sctp; 2164 } 2165 description 2166 "SCTP packet capabilities"; 2167 reference 2168 "RFC 4960: Stream Control Transmission Protocol - SCTP"; 2169 } 2171 leaf-list dccp-capability { 2172 type identityref { 2173 base dccp; 2174 } 2175 description 2176 "DCCP packet capabilities"; 2177 reference 2178 "RFC 4340: Datagram Congestion Control Protocol - DCCP"; 2179 } 2180 } 2182 container advanced-nsf-capabilities { 2183 description 2184 "Advanced Network Security Function (NSF) capabilities, 2185 such as Anti-DDoS, IPS, and VoIP/VoLTE. 2186 This container contains the leaf-lists of advanced 2187 NSF capabilities"; 2189 leaf-list anti-ddos-capability { 2190 type identityref { 2191 base anti-ddos; 2192 } 2193 description 2194 "Anti-DDoS Attack capabilities"; 2195 } 2197 leaf-list ips-capability { 2198 type identityref { 2199 base ips; 2200 } 2201 description 2202 "IPS capabilities"; 2203 } 2205 leaf-list anti-virus-capability { 2206 type identityref { 2207 base anti-virus; 2208 } 2209 description 2210 "Anti-Virus capabilities"; 2211 } 2213 leaf-list url-filtering-capability { 2214 type identityref { 2215 base url-filtering; 2216 } 2217 description 2218 "URL Filtering capabilities"; 2219 } 2220 leaf-list voip-volte-filtering-capability { 2221 type identityref { 2222 base voip-volte-filtering; 2223 } 2224 description 2225 "VoIP/VoLTE capabilities"; 2226 } 2227 } 2229 container context-capabilities { 2230 description 2231 "Security context capabilities"; 2232 leaf-list application-filter-capabilities{ 2233 type identityref { 2234 base application-protocol; 2235 } 2236 description 2237 "Context capabilities based on the application protocol"; 2238 } 2240 leaf-list device-type-capabilities { 2241 type identityref { 2242 base device-type; 2243 } 2244 description 2245 "Context capabilities based on the device attribute that 2246 can identify a device type 2247 (i.e., router, switch, pc, ios, or android)."; 2248 } 2250 leaf-list user-condition-capabilities { 2251 type identityref { 2252 base user-condition; 2253 } 2254 description 2255 "Context capabilities based on user condition, such as 2256 user-id or user-name. The users can collected into a 2257 user-group and identified with group-id or group-name. 2258 An NSF is aware of the IP address of the user provided 2259 by a unified user management system via network. Based 2260 on name-address association, an NSF is able to enforce 2261 the security functions over the given user (or user 2262 group)"; 2263 } 2265 leaf-list geographic-capabilities { 2266 type identityref { 2267 base geographic-location; 2269 } 2270 description 2271 "Context condition capabilities based on the geographical 2272 location of the source or destination"; 2273 } 2274 } 2275 } 2277 container action-capabilities { 2278 description 2279 "Action capabilities. 2280 If a network security function has the action capabilities, 2281 the network security function supports the attendant 2282 actions for policy rules."; 2284 leaf-list ingress-action-capability { 2285 type identityref { 2286 base ingress-action; 2287 } 2288 description 2289 "Ingress-action capabilities"; 2290 } 2292 leaf-list egress-action-capability { 2293 type identityref { 2294 base egress-action; 2295 } 2296 description 2297 "Egress-action capabilities"; 2298 } 2300 leaf-list log-action-capability { 2301 type identityref { 2302 base log-action; 2303 } 2304 description 2305 "Log-action capabilities"; 2306 } 2307 } 2309 leaf-list resolution-strategy-capabilities { 2310 type identityref { 2311 base resolution-strategy; 2312 } 2313 description 2314 "Resolution strategy capabilities. 2315 The resolution strategies can be used to specify how 2316 to resolve conflicts that occur between the actions 2317 of the same or different policy rules that are matched 2318 for the same packet and by particular NSF."; 2319 } 2321 leaf-list default-action-capabilities { 2322 type identityref { 2323 base default-action; 2324 } 2325 description 2326 "Default action capabilities. 2327 A default action is used to execute I2NSF policy rules 2328 when no rule matches a packet. The default action is 2329 defined as pass, drop, reject, rate-limit, or mirror."; 2330 } 2331 } 2333 /* 2334 * Data nodes 2335 */ 2337 list nsf { 2338 key "nsf-name"; 2339 description 2340 "The list of Network Security Functions (NSFs)"; 2341 leaf nsf-name { 2342 type string; 2343 mandatory true; 2344 description 2345 "The name of Network Security Function (NSF)"; 2346 } 2347 uses nsf-capabilities; 2348 } 2349 } 2350 2352 Figure 3: YANG Data Module of I2NSF Capability 2354 7. IANA Considerations 2356 This document requests IANA to register the following URI in the 2357 "IETF XML Registry" [RFC3688]: 2359 ID: yang:ietf-i2nsf-capability 2360 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2361 Registrant Contact: The IESG. 2362 XML: N/A; the requested URI is an XML namespace. 2363 Filename: [ TBD-at-Registration ] 2364 Reference: [ RFC-to-be ] 2366 This document requests IANA to register the following YANG module in 2367 the "YANG Module Names" registry [RFC7950][RFC8525]: 2369 Name: ietf-i2nsf-capability 2370 Maintained by IANA? N 2371 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2372 Prefix: nsfcap 2373 Module: 2374 Reference: [ RFC-to-be ] 2376 8. Privacy Considerations 2378 This YANG module specifies the capabilities of NSFs. These 2379 capabilities are consistent with the diverse set of network security 2380 functions in common use in enterprise security operations. The 2381 configuration of the capabilities may entail privacy sensitive 2382 information as explicitly outlined in Section 9. The NSFs 2383 implementing these capabilities may inspect, alter or drop user 2384 traffic; and be capable of attributing user traffic to individual 2385 users. 2387 Due to the sensitivity of these capabilities, notice must be provided 2388 to and consent must be received from the users of the network. 2389 Additionally, the collected data and associated infrastructure must 2390 be secured to prevent the leakage or unauthorized disclosure of this 2391 private data. 2393 9. Security Considerations 2395 The YANG module specified in this document defines a data schema 2396 designed to be accessed through network management protocols such as 2397 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest layer of NETCONF 2398 protocol layers MUST use Secure Shell (SSH) [RFC4254][RFC6242] as a 2399 secure transport layer. The lowest layer of RESTCONF protocol layers 2400 MUST use HTTP over Transport Layer Security (TLS), that is, HTTPS 2401 [RFC7230][RFC8446] as a secure transport layer. 2403 The Network Configuration Access Control Model (NACM) [RFC8341] 2404 provides a means of restricting access to specific NETCONF or 2405 RESTCONF users to a preconfigured subset of all available NETCONF or 2406 RESTCONF protocol operations and contents. Thus, NACM SHOULD be used 2407 to restrict the NSF registration from unauthorized users. 2409 There are a number of data nodes defined in this YANG module that are 2410 writable, creatable, and deletable (i.e., config true, which is the 2411 default). These data nodes may be considered sensitive or vulnerable 2412 in some network environments. Write operations to these data nodes 2413 could have a negative effect on network and security operations. 2414 These data nodes are collected into a single list node. This list 2415 node is defined by list nsf with the following sensitivity/ 2416 vulnerability: 2418 * list nsf: An attacker could alter the security capabilities 2419 associated with an NSF by disabling or enabling the functionality 2420 of the security capabilities of the NSF. 2422 Some of the readable data nodes in this YANG module may be considered 2423 sensitive or vulnerable in some network environments. It is thus 2424 important to control read access (e.g., via get, get-config, or 2425 notification) to these data nodes. These are the subtrees and data 2426 nodes with their sensitivity/vulnerability: 2428 * list nsf: The leak of this node to an attacker could reveal the 2429 specific configuration of security controls to an attacker. An 2430 attacker can craft an attack path that avoids observation or 2431 mitigations; one may reveal topology information to inform 2432 additional targets or enable lateral movement; one enables the 2433 construction of an attack path that avoids observation or 2434 mitigations; one provides an indication that the operator has 2435 discovered the attack. 2437 Some of the capability indicators (i.e., identities) defined in this 2438 document are highly sensitive and/or privileged operations that 2439 inherently require access to individuals' private data. These are 2440 subtrees and data nodes that are considered privacy sensitive: 2442 * voip-volte-filtering-capability: The NSF that is able to filter 2443 VoIP/VoLTE calls might identify certain individual identification. 2445 * user-condition-capabilities: The capability uses a set of IP 2446 addresses mapped to users. 2448 * geographic-capabilities: The IP address used in this capability 2449 can identify a user's geographical location. 2451 It is noted that some private information is made accessible in this 2452 manner. Thus, the nodes/entities given access to this data MUST be 2453 tightly secured, monitored, and audited to prevent leakage or other 2454 unauthorized disclosure of private data. Refer to [RFC6973] for the 2455 description of privacy aspects that protocol designers (including 2456 YANG data model designers) should consider along with regular 2457 security and privacy analysis. 2459 10. References 2461 10.1. Normative References 2463 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2464 DOI 10.17487/RFC0768, August 1980, 2465 . 2467 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2468 DOI 10.17487/RFC0791, September 1981, 2469 . 2471 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2472 RFC 792, DOI 10.17487/RFC0792, September 1981, 2473 . 2475 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 2476 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 2477 1983, . 2479 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2480 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 2481 . 2483 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2484 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 2485 . 2487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2488 Requirement Levels", BCP 14, RFC 2119, 2489 DOI 10.17487/RFC2119, March 1997, 2490 . 2492 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2493 "Definition of the Differentiated Services Field (DS 2494 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2495 DOI 10.17487/RFC2474, December 1998, 2496 . 2498 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2499 of Explicit Congestion Notification (ECN) to IP", 2500 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2501 . 2503 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2504 A., Peterson, J., Sparks, R., Handley, M., and E. 2505 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2506 DOI 10.17487/RFC3261, June 2002, 2507 . 2509 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2510 DOI 10.17487/RFC3688, January 2004, 2511 . 2513 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 2514 Protocol Assigned Numbers", RFC 4250, 2515 DOI 10.17487/RFC4250, January 2006, 2516 . 2518 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2519 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 2520 January 2006, . 2522 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2523 Congestion Control Protocol (DCCP)", RFC 4340, 2524 DOI 10.17487/RFC4340, March 2006, 2525 . 2527 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2528 Control Message Protocol (ICMPv6) for the Internet 2529 Protocol Version 6 (IPv6) Specification", STD 89, 2530 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2531 . 2533 [RFC4766] Wood, M. and M. Erlinger, "Intrusion Detection Message 2534 Exchange Requirements", RFC 4766, DOI 10.17487/RFC4766, 2535 March 2007, . 2537 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2538 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2539 . 2541 [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export 2542 Using IP Flow Information Export (IPFIX)", RFC 5103, 2543 DOI 10.17487/RFC5103, January 2008, 2544 . 2546 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2547 DOI 10.17487/RFC5321, October 2008, 2548 . 2550 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 2551 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 2552 September 2009, . 2554 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2555 the Network Configuration Protocol (NETCONF)", RFC 6020, 2556 DOI 10.17487/RFC6020, October 2010, 2557 . 2559 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2560 and A. Bierman, Ed., "Network Configuration Protocol 2561 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2562 . 2564 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2565 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2566 . 2568 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2569 Cheshire, "Internet Assigned Numbers Authority (IANA) 2570 Procedures for the Management of the Service Name and 2571 Transport Protocol Port Number Registry", BCP 165, 2572 RFC 6335, DOI 10.17487/RFC6335, August 2011, 2573 . 2575 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2576 "IPv6 Flow Label Specification", RFC 6437, 2577 DOI 10.17487/RFC6437, November 2011, 2578 . 2580 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2581 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2582 . 2584 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2585 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2586 . 2588 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2589 Protocol (HTTP/1.1): Message Syntax and Routing", 2590 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2591 . 2593 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2594 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2595 DOI 10.17487/RFC7231, June 2014, 2596 . 2598 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 2599 Scheffenegger, Ed., "TCP Extensions for High Performance", 2600 RFC 7323, DOI 10.17487/RFC7323, September 2014, 2601 . 2603 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2604 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2605 . 2607 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2608 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2609 . 2611 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2612 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2613 May 2017, . 2615 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2616 (IPv6) Specification", STD 86, RFC 8200, 2617 DOI 10.17487/RFC8200, July 2017, 2618 . 2620 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2621 Kumar, "Framework for Interface to Network Security 2622 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2623 . 2625 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2626 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2627 . 2629 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2630 Access Control Model", STD 91, RFC 8341, 2631 DOI 10.17487/RFC8341, March 2018, 2632 . 2634 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2635 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2636 DOI 10.17487/RFC8407, October 2018, 2637 . 2639 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2640 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2641 . 2643 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 2644 and R. Wilton, "YANG Library", RFC 8525, 2645 DOI 10.17487/RFC8525, March 2019, 2646 . 2648 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 2649 Kumari, "A Format for Self-Published IP Geolocation 2650 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 2651 . 2653 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message 2654 Access Protocol (IMAP) - Version 4rev2", RFC 9051, 2655 DOI 10.17487/RFC9051, August 2021, 2656 . 2658 [I-D.ietf-tcpm-rfc793bis] 2659 Eddy, W. M., "Transmission Control Protocol (TCP) 2660 Specification", Work in Progress, Internet-Draft, draft- 2661 ietf-tcpm-rfc793bis-25, 7 September 2021, 2662 . 2665 [I-D.ietf-tcpm-accurate-ecn] 2666 Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More 2667 Accurate ECN Feedback in TCP", Work in Progress, Internet- 2668 Draft, draft-ietf-tcpm-accurate-ecn-15, 12 July 2021, 2669 . 2672 [I-D.ietf-tsvwg-udp-options] 2673 Touch, J., "Transport Options for UDP", Work in Progress, 2674 Internet-Draft, draft-ietf-tsvwg-udp-options-13, 19 June 2675 2021, . 2678 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 2679 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 2680 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 2681 Model", Work in Progress, Internet-Draft, draft-ietf- 2682 i2nsf-nsf-monitoring-data-model-12, 17 November 2021, 2683 . 2686 10.2. Informative References 2688 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2689 DOI 10.17487/RFC2818, May 2000, 2690 . 2692 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2693 RFC 6691, DOI 10.17487/RFC6691, July 2012, 2694 . 2696 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2697 Morris, J., Hansen, M., and R. Smith, "Privacy 2698 Considerations for Internet Protocols", RFC 6973, 2699 DOI 10.17487/RFC6973, July 2013, 2700 . 2702 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2703 and J. Jeong, "Interface to Network Security Functions 2704 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2705 DOI 10.17487/RFC8192, July 2017, 2706 . 2708 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 2709 Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin, 2710 "I2NSF Network Security Function-Facing Interface YANG 2711 Data Model", Work in Progress, Internet-Draft, draft-ietf- 2712 i2nsf-nsf-facing-interface-dm-16, 13 November 2021, 2713 . 2716 [I-D.ietf-i2nsf-registration-interface-dm] 2717 Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Park, 2718 "I2NSF Registration Interface YANG Data Model", Work in 2719 Progress, Internet-Draft, draft-ietf-i2nsf-registration- 2720 interface-dm-13, 4 October 2021, 2721 . 2724 [IANA-Protocol-Numbers] 2725 "Assigned Internet Protocol Numbers", Available: 2726 https://www.iana.org/assignments/protocol- 2727 numbers/protocol-numbers.xhtml, September 2020. 2729 [IEEE802.3-2018] 2730 Committee, I. S., "IEEE 802.3-2018 - IEEE Standard for 2731 Ethernet", August 2018, 2732 . 2734 [Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and 2735 management of firewall policies", 2004. 2737 [Hirschman] 2738 Hirschman, L. and R. Gaizauskas, "Natural Language 2739 Question Answering: The View from Here", Natural Language 2740 Engineering 7:4, pgs 275-300, Cambridge University Press , 2741 November 2001. 2743 [Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns", 2744 ISBN 0-32-120068-3 , 2003. 2746 [Martin] Martin, R.C., "Agile Software Development, Principles, 2747 Patterns, and Practices", Prentice-Hall , ISBN: 2748 0-13-597444-5 , 2002. 2750 [OODMP] "https://www.oodesign.com/mediator-pattern.html". 2752 [OODOP] "https://www.oodesign.com/mediator-pattern.html". 2754 [OODSRP] "https://www.oodesign.com/mediator-pattern.html". 2756 Appendix A. Configuration Examples 2758 This section shows configuration examples of "ietf-i2nsf-capability" 2759 module for capabilities registration of general firewall. 2761 A.1. Example 1: Registration for the Capabilities of a General Firewall 2763 This section shows a configuration example for the capabilities 2764 registration of a general firewall in either an IPv4 network or an 2765 IPv6 network. 2767 2768 general_firewall 2769 2770 2771 next-header 2772 flow-direction 2773 source-address 2774 destination-address 2775 source-port-number 2776 destination-port-number 2777 source-port-number 2778 destination-port-number 2779 2780 2781 2782 pass 2783 drop 2784 mirror 2785 pass 2786 drop 2787 mirror 2788 2789 2791 Figure 4: Configuration XML for the Capabilities Registration of 2792 a General Firewall in an IPv4 Network 2794 Figure 4 shows the configuration XML for the capabilities 2795 registration of a general firewall as an NSF in an IPv4 network. Its 2796 capabilities are as follows. 2798 1. The name of the NSF is general_firewall. 2800 2. The NSF can inspect the IPv4 protocol header field, flow 2801 direction, source address(es), and destination address(es) 2803 3. The NSF can inspect the port number(s) and flow direction for the 2804 transport layer protocol, i.e., TCP and UDP. 2806 4. The NSF can control whether the packets are allowed to pass, 2807 drop, or mirror. 2809 2810 general_firewall 2811 2812 2813 next-header 2814 flow-direction 2815 source-address 2816 destination-address 2817 source-port-number 2818 destination-port-number 2819 source-port-number 2820 destination-port-number 2821 2822 2823 2824 pass 2825 drop 2826 mirror 2827 pass 2828 drop 2829 mirror 2830 2831 2833 Figure 5: Configuration XML for the Capabilities Registration of 2834 a General Firewall in an IPv6 Network 2836 In addition, Figure 5 shows the configuration XML for the 2837 capabilities registration of a general firewall as an NSF in an IPv6 2838 network. Its capabilities are as follows. 2840 1. The name of the NSF is general_firewall. 2842 2. The NSF can inspect IPv6 next header, flow direction, source 2843 address(es), and destination address(es) 2845 3. The NSF can inspect the port number(s) and flow direction for the 2846 transport layer protocol, i.e., TCP and UDP. 2848 4. The NSF can control whether the packets are allowed to pass, 2849 drop, or mirror. 2851 A.2. Example 2: Registration for the Capabilities of a Time-based 2852 Firewall 2854 This section shows a configuration example for the capabilities 2855 registration of a time-based firewall in either an IPv4 network or an 2856 IPv6 network. 2858 2859 time_based_firewall 2860 2861 absolute-time 2862 periodic-time 2863 2864 2865 2866 next-header 2867 flow-direction 2868 source-address 2869 destination-address 2870 2871 2872 2873 pass 2874 drop 2875 mirror 2876 pass 2877 drop 2878 mirror 2879 2880 2882 Figure 6: Configuration XML for the Capabilities Registration of 2883 a Time-based Firewall in an IPv4 Network 2885 Figure 6 shows the configuration XML for the capabilities 2886 registration of a time-based firewall as an NSF in an IPv4 network. 2887 Its capabilities are as follows. 2889 1. The name of the NSF is time_based_firewall. 2891 2. The NSF can execute the security policy rule according to 2892 absolute time and periodic time. 2894 3. The NSF can inspect the IPv4 protocol header field, flow 2895 direction, source address(es), and destination address(es). 2897 4. The NSF can control whether the packets are allowed to pass, 2898 drop, or mirror. 2900 2901 time_based_firewall 2902 2903 absolute-time 2904 periodic-time 2905 2906 2907 2908 next-header 2909 flow-direction 2910 source-address 2911 destination-address 2912 2913 2914 2915 pass 2916 drop 2917 mirror 2918 pass 2919 drop 2920 mirror 2921 2922 2924 Figure 7: Configuration XML for the Capabilities Registration of 2925 a Time-based Firewall in an IPv6 Network 2927 In addition, Figure 7 shows the configuration XML for the 2928 capabilities registration of a time-based firewall as an NSF in an 2929 IPv6 network. Its capabilities are as follows. 2931 1. The name of the NSF is time_based_firewall. 2933 2. The NSF can execute the security policy rule according to 2934 absolute time and periodic time. 2936 3. The NSF can inspect the IPv6 protocol header field, flow 2937 direction, source address(es), and destination address(es). 2939 4. The NSF can control whether the packets are allowed to pass, 2940 drop, or mirror. 2942 A.3. Example 3: Registration for the Capabilities of a Web Filter 2944 This section shows a configuration example for the capabilities 2945 registration of a web filter. 2947 2948 web_filter 2949 2950 2951 user-defined 2952 2953 2954 2955 pass 2956 drop 2957 mirror 2958 pass 2959 drop 2960 mirror 2961 2962 2964 Figure 8: Configuration XML for the Capabilities Registration of 2965 a Web Filter 2967 Figure 8 shows the configuration XML for the capabilities 2968 registration of a web filter as an NSF. Its capabilities are as 2969 follows. 2971 1. The name of the NSF is web_filter. 2973 2. The NSF can inspect a URL matched from a user-defined URL. User 2974 can specify their own URL. 2976 3. The NSF can control whether the packets are allowed to pass, 2977 drop, or mirror. 2979 4. Overall, the NSF can compare the URL of a packet to a user- 2980 defined database. The matched packet can be passed, dropped, or 2981 mirrored. 2983 A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE 2984 Filter 2986 This section shows a configuration example for the capabilities 2987 registration of a VoIP/VoLTE filter. 2989 2990 voip_volte_filter 2991 2992 2993 2994 call-id 2995 2996 2997 2998 2999 pass 3000 drop 3001 mirror 3002 pass 3003 drop 3004 mirror 3005 3006 3008 Figure 9: Configuration XML for the Capabilities Registration of 3009 a VoIP/VoLTE Filter 3011 Figure 9 shows the configuration XML for the capabilities 3012 registration of a VoIP/VoLTE filter as an NSF. Its capabilities are 3013 as follows. 3015 1. The name of the NSF is voip_volte_filter. 3017 2. The NSF can inspect a voice call id for VoIP/VoLTE packets. 3019 3. The NSF can control whether the packets are allowed to pass, 3020 drop, or mirror. 3022 A.5. Example 5: Registration for the Capabilities of a HTTP and HTTPS 3023 Flood Mitigator 3025 This section shows a configuration example for the capabilities 3026 registration of a HTTP and HTTPS flood mitigator. 3028 3029 DDoS_mitigator 3030 3031 3032 packet-rate 3033 byte-rate 3034 flow-rate 3035 3036 3037 3038 pass 3039 drop 3040 mirror 3041 pass 3042 drop 3043 mirror 3044 3045 3047 Figure 10: Configuration XML for the Capabilities Registration of 3048 a HTTP and HTTPS Flood Mitigator 3050 Figure 10 shows the configuration XML for the capabilities 3051 registration of a HTTP and HTTPS flood mitigator as an NSF. Its 3052 capabilities are as follows. 3054 1. The name of the NSF is DDoS_mitigator. 3056 2. The NSF can detect the amount of packet, flow, and byte rate in 3057 the network for potential DDoS Attack. 3059 3. The NSF can control whether the packets are allowed to pass, 3060 drop, or mirror. 3062 Appendix B. Acknowledgments 3064 This document is a product by the I2NSF Working Group (WG) including 3065 WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This 3066 document took advantage of the review and comments from the following 3067 experts: Roman Danyliw, Acee Lindem, Paul Wouters (SecDir), Michael 3068 Scharf (TSVART), Dan Romascanu (GenART), and Tom Petch. We authors 3069 sincerely appreciate their sincere efforts and kind help. 3071 This work was supported by Institute of Information & Communications 3072 Technology Planning & Evaluation (IITP) grant funded by the Korea 3073 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 3074 Security Intelligence Technology Development for the Customized 3075 Security Service Provisioning). This work was supported in part by 3076 the IITP grant funded by the MSIT (2020-0-00395, Standard Development 3077 of Blockchain based Network Management Automation Technology). 3079 Appendix C. Contributors 3081 The following are co-authors of this document: 3083 Patrick Lingga - Department of Electrical and Computer Engineering, 3084 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3085 16419, Republic of Korea, EMail: patricklink@skku.edu 3087 Liang Xia - Huawei, 101 Software Avenue, Nanjing, Jiangsu 210012, 3088 China, EMail: Frank.Xialiang@huawei.com 3090 Cataldo Basile - Politecnico di Torino, Corso Duca degli Abruzzi, 34, 3091 Torino, 10129, Italy, EMail: cataldo.basile@polito.it 3093 John Strassner - Huawei, 2330 Central Expressway, Santa Clara, CA 3094 95050, USA, EMail: John.sc.Strassner@huawei.com 3096 Diego R. Lopez - Telefonica I+D, Zurbaran, 12, Madrid, 28010, Spain, 3097 Email: diego.r.lopez@telefonica.com 3099 Hyoungshick Kim - Department of Computer Science and Engineering, 3100 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3101 16419, Republic of Korea, EMail: hyoung@skku.edu 3103 Daeyoung Hyun - Department of Computer Science and Engineering, 3104 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3105 16419, Republic of Korea, EMail: dyhyun@skku.edu 3107 Dongjin Hong - Department of Electronic, Electrical and Computer 3108 Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, 3109 Gyeonggi-do 16419, Republic of Korea, EMail: dong.jin@skku.edu 3111 Jung-Soo Park - Electronics and Telecommunications Research 3112 Institute, 218 Gajeong-Ro, Yuseong-Gu, Daejeon, 34129, Republic of 3113 Korea, EMail: pjs@etri.re.kr 3115 Tae-Jin Ahn - Korea Telecom, 70 Yuseong-Ro, Yuseong-Gu, Daejeon, 3116 305-811, Republic of Korea, EMail: taejin.ahn@kt.com 3117 Se-Hui Lee - Korea Telecom, 70 Yuseong-Ro, Yuseong-Gu, Daejeon, 3118 305-811, Republic of Korea, EMail: sehuilee@kt.com 3120 Authors' Addresses 3122 Susan Hares (editor) 3123 Huawei 3124 7453 Hickory Hill 3125 Saline, MI 48176 3126 United States of America 3128 Phone: +1-734-604-0332 3129 Email: shares@ndzh.com 3131 Jaehoon (Paul) Jeong (editor) 3132 Department of Computer Science and Engineering 3133 Sungkyunkwan University 3134 2066 Seobu-Ro, Jangan-Gu 3135 Suwon 3136 Gyeonggi-Do 3137 16419 3138 Republic of Korea 3140 Phone: +82 31 299 4957 3141 Email: pauljeong@skku.edu 3142 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3144 Jinyong (Tim) Kim 3145 Department of Electronic, Electrical and Computer Engineering 3146 Sungkyunkwan University 3147 2066 Seobu-Ro, Jangan-Gu 3148 Suwon 3149 Gyeonggi-Do 3150 16419 3151 Republic of Korea 3153 Phone: +82 10 8273 0930 3154 Email: timkim@skku.edu 3156 Robert Moskowitz 3157 HTT Consulting 3158 Oak Park, MI 3159 United States of America 3161 Phone: +1-248-968-9809 3162 Email: rgm@htt-consult.com 3164 Qiushi Lin 3165 Huawei 3166 Huawei Industrial Base 3167 Shenzhen 3168 Guangdong 518129, 3169 China 3171 Email: linqiushi@huawei.com