idnits 2.17.1 draft-ietf-i2nsf-capability-data-model-14.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 30, 2020) is 1213 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 2461, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-04 == Outdated reference: A later version (-14) exists of draft-ietf-i2nsf-sdn-ipsec-flow-protection-12 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-13 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-rfc793bis-19 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-tcpm-rfc793bis' == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-09 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6691 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 6973 ** 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 8192 ** Downref: Normative reference to an Informational RFC: RFC 8329 Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group S. Hares, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track J. Jeong, Ed. 5 Expires: July 3, 2021 J. Kim 6 Sungkyunkwan University 7 R. Moskowitz 8 HTT Consulting 9 Q. Lin 10 Huawei 11 December 30, 2020 13 I2NSF Capability YANG Data Model 14 draft-ietf-i2nsf-capability-data-model-14 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 July 3, 2021. 40 Copyright Notice 42 Copyright (c) 2020 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Capability Information Model Design . . . . . . . . . . . . . 4 60 3.1. Design Principles and ECA Policy Model Overview . . . . . 5 61 3.2. Matched Policy Rule . . . . . . . . . . . . . . . . . . . 8 62 3.3. Conflict, Resolution Strategy and Default Action . . . . 8 63 4. Overview of YANG Data Model . . . . . . . . . . . . . . . . . 9 64 5. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12 65 5.1. Network Security Function (NSF) Capabilities . . . . . . 12 66 6. YANG Data Model of I2NSF NSF Capability . . . . . . . . . . . 15 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 68 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 50 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 52 72 10.2. Informative References . . . . . . . . . . . . . . . . . 56 73 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 58 74 A.1. Example 1: Registration for the Capabilities of a General 75 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 58 76 A.2. Example 2: Registration for the Capabilities of a Time- 77 based Firewall . . . . . . . . . . . . . . . . . . . . . 60 78 A.3. Example 3: Registration for the Capabilities of a Web 79 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 61 80 A.4. Example 4: Registration for the Capabilities of a 81 VoIP/VoLTE Filter . . . . . . . . . . . . . . . . . . . . 62 82 A.5. Example 5: Registration for the Capabilities of a HTTP 83 and HTTPS Flood Mitigator . . . . . . . . . . . . . . . . 63 84 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 64 85 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 65 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 88 1. Introduction 90 As the industry becomes more sophisticated and network devices (e.g., 91 Internet-of-Things (IoT) devices, autonomous vehicles, and 92 smartphones using Voice over IP (VoIP) and Voice over LTE (VoLTE)) 93 require advanced security protection in various scenario, service 94 providers have a lot of problems described in [RFC8192]. To resolve 95 these problems, this document specifies the information and data 96 models of the capabilities of Network Security Functions (NSFs) in a 97 framework of the Interface to Network Security Functions (I2NSF) 98 [RFC8329]. 100 NSFs produced by multiple security vendors provide various security 101 capabilities to customers. Multiple NSFs can be combined together to 102 provide security services over the given network traffic, regardless 103 of whether the NSFs are implemented as physical or virtual functions. 104 Security Capabilities describe the functions that Network Security 105 Functions (NSFs) are available to provide for security policy 106 enforcement purposes. Security Capabilities are independent of the 107 actual security control mechanisms that will implement them. 109 Every NSF SHOULD be described with the set of capabilities it offers. 110 Security Capabilities enable security functionality to be described 111 in a vendor-neutral manner. That is, it is not needed to refer to a 112 specific product or technology when designing the network; rather, 113 the functions characterized by their capabilities are considered. 114 Security Capabilities are a market enabler, providing a way to define 115 customized security protection by unambiguously describing the 116 security features offered by a given NSF. Note that this YANG data 117 model outlines an NSF monitoring YANG data model 118 [I-D.ietf-i2nsf-nsf-monitoring-data-model] and a YANG data model for 119 Software-Defined Networking (SDN)-based IPsec flow protection 120 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 122 This document provides an information model and the corresponding 123 YANG data model [RFC6020][RFC7950] that defines the capabilities of 124 NSFs to centrally manage the capabilities of those security devices. 125 The security devices can register their own capabilities into a 126 Network Operator Management (Mgmt) System (i.e., Security Controller) 127 with this YANG data model through the registration interface 128 [RFC8329]. With the database of the capabilities of those security 129 devices that are maintained centrally, those security devices can be 130 more easily managed [RFC8329]. 132 This YANG data model uses an "Event-Condition-Action" (ECA) policy 133 model that is used as the basis for the design of I2NSF Policy as 134 described in [RFC8329] and Section 3.1. The "ietf-i2nsf-capability" 135 YANG module defined in this document provides the following features: 137 o Definition for time capabilities of network security functions. 139 o Definition for event capabilities of generic network security 140 functions. 142 o Definition for condition capabilities of generic network security 143 functions. 145 o Definition for condition capabilities of advanced network security 146 functions. 148 o Definition for action capabilities of generic network security 149 functions. 151 o Definition for resolution strategy capabilities of generic network 152 security functions. 154 o Definition for default action capabilities of generic network 155 security functions. 157 2. Terminology 159 This document uses the terminology described in [RFC8329]. 161 This document follows the guidelines of [RFC8407], uses the common 162 YANG types defined in [RFC6991], and adopts the Network Management 163 Datastore Architecture (NMDA). The meaning of the symbols in tree 164 diagrams is defined in [RFC8340]. 166 3. Capability Information Model Design 168 A Capability Information Model (CapIM) is a formalization of the 169 functionality that an NSF advertises. This enables the precise 170 specification of what an NSF can do in terms of security policy 171 enforcement, so that computer-based tasks can unambiguously refer to, 172 use, configure, and manage NSFs. Capabilities MUST be defined in a 173 vendor- and technology-independent manner (e.g., regardless of the 174 differences among vendors and individual products). 176 Humans can refer to categories of security controls and understand 177 each other. For instance, network security experts agree on what is 178 meant by the terms "NAT", "filtering", and "VPN concentrator". As a 179 further example, network security experts unequivocally refer to 180 "packet filters" as stateless devices that allow or deny packet 181 forwarding based on various conditions (e.g., source and destination 182 IP addresses, source and destination ports, and IP protocol type 183 fields) [Alshaer]. 185 However, more information is required in case of other devices, like 186 stateful firewalls or application layer filters. These devices 187 filter packets or communications, but there are differences in the 188 packets and communications that they can categorize and the states 189 they maintain. Humans deal with these differences by asking more 190 questions to determine the specific category and functionality of the 191 device. Machines can follow a similar approach, which is commonly 192 referred to as question-answering [Hirschman] [Galitsky]. In this 193 context, the CapIM and the derived data model can provide important 194 and rich information sources. 196 Analogous considerations can be applied for channel protection 197 protocols, where we all understand that they will protect packets by 198 means of symmetric algorithms whose keys could have been negotiated 199 with asymmetric cryptography, but they may work at different layers 200 and support different algorithms and protocols. To ensure 201 protection, these protocols apply integrity, optionally 202 confidentiality, anti-reply protections, and authentication. 204 The CapIM is intended to clarify these ambiguities by providing a 205 formal description of NSF functionality. The set of functions that 206 are advertised MAY be restricted according to the privileges of the 207 user or application that is viewing those functions. I2NSF 208 Capabilities enable unambiguous specification of the security 209 capabilities available in a (virtualized) networking environment, and 210 their automatic processing by means of computer-based techniques. 212 This CapIM includes enabling a security controller in an I2NSF 213 framework [RFC8329] to properly identify and manage NSFs, and allow 214 NSFs to properly declare their functionality through a Developer's 215 Management System (DMS) [RFC8329] , so that they can be used in the 216 correct way. 218 3.1. Design Principles and ECA Policy Model Overview 220 This document defines an information model for representing NSF 221 capabilities. Some basic design principles for security capabilities 222 and the systems that manage them are: 224 o Independence: Each security capability SHOULD be an independent 225 function, with minimum overlap or dependency on other 226 capabilities. This enables each security capability to be 227 utilized and assembled together freely. More importantly, changes 228 to one capability SHOULD NOT affect other capabilities. This 229 follows the Single Responsibility Principle [Martin] [OODSRP]. 231 o Abstraction: Each capability MUST be defined in a vendor- 232 independent manner. 234 o Advertisement: A dedicated, well-known interface MUST be used to 235 advertise and register the capabilities of each NSF. This same 236 interface MUST be used by other I2NSF Components to determine what 237 Capabilities are currently available to them. 239 o Execution: Dedicated, well-known interfaces MUST be used to 240 configure and monitor the use of a capability, resepectively. 242 These provide a standardized ability to describe its 243 functionality, and report its processing results, resepectively. 244 These facilitate multi-vendor interoperability. 246 o Automation: The system MUST have the ability to auto-discover, 247 auto-negotiate, and auto-update its security capabilities (i.e., 248 without human intervention). These features are especially useful 249 for the management of a large number of NSFs. They are essential 250 for adding smart services (e.g., refinement, analysis, capability 251 reasoning, and optimization) to the security scheme employed. 252 These features are supported by many design patterns, including 253 the Observer Pattern [OODOP], the Mediator Pattern [OODMP], and a 254 set of Message Exchange Patterns [Hohpe]. 256 o Scalability: The management system SHOULD have the capability to 257 scale up/down or scale in/out. Thus, it can meet various 258 performance requirements derived from changeable network traffic 259 or service requests. In addition, security capabilities that are 260 affected by scalability changes SHOULD support reporting 261 statistics to the security controller to assist its decision on 262 whether it needs to invoke scaling or not. 264 Based on the above principles, this document defines a capability 265 model that enables an NSF to register (and hence advertise) its set 266 of capabilities that other I2NSF Components can use. These 267 capabilities MAY have their access control restricted by a policy; 268 this is out of scope for this document. The set of capabilities 269 provided by a given set of NSFs unambiguously defines the security 270 services offered by the set of NSFs used. The security controller 271 can compare the requirements of users and applications with the set 272 of capabilities that are currently available in order to choose which 273 capabilities of which NSFs are needed to meet those requirements. 274 Note that this choice is independent of vendor, and instead relies 275 specifically on the capabilities (i.e., the description) of the 276 functions provided. 278 Furthermore, when an unknown threat (e.g., zero-day exploits and 279 unknown malware) is reported by an NSF, new capabilities may be 280 created, and/or existing capabilities may be updated (e.g., by 281 updating its signature and algorithm). This results in enhancing the 282 existing NSFs (and/or creating new NSFs) to address the new threats. 283 New capabilities may be sent to and stored in a centralized 284 repository, or stored separately in a vendor's local repository. In 285 either case, a standard interface facilitates this update process. 287 The "Event-Condition-Action" (ECA) policy model in [RFC8329] is used 288 as the basis for the design of the capability model; definitions of 289 all I2NSF policy-related terms are also defined in [RFC8329]. The 290 following three terms define the structure and behavior of an I2NSF 291 imperative policy rule: 293 o Event: An Event is defined as any important occurrence in time of 294 a change in the system being managed, and/or in the environment of 295 the system being managed. When used in the context of I2NSF 296 Policy Rules, it is used to determine whether the condition clause 297 of an I2NSF Policy Rule can be evaluated or not. Examples of an 298 I2NSF Event include time and user actions (e.g., logon, logoff, 299 and actions that violate an ACL). 301 o Condition: A condition is defined as a set of attributes, 302 features, and/or values that are to be compared with a set of 303 known attributes, features, and/or values in order to determine 304 whether or not the set of actions in that (imperative) I2NSF 305 Policy Rule can be executed or not. Examples of I2NSF conditions 306 include matching attributes of a packet or flow, and comparing the 307 internal state of an NSF with a desired state. 309 o Action: An action is used to control and monitor aspects of flow- 310 based NSFs when the event and condition clauses are satisfied. 311 NSFs provide security functions by executing various Actions. 312 Examples of I2NSF actions include providing intrusion detection 313 and/or protection, web and flow filtering, and deep packet 314 inspection for packets and flows. 316 An I2NSF Policy Rule is made up of three Boolean clauses: an Event 317 clause, a Condition clause, and an Action clause. This structure is 318 also called an ECA (Event-Condition-Action) Policy Rule. A Boolean 319 clause is a logical statement that evaluates to either TRUE or FALSE. 320 It may be made up of one or more terms; if more than one term is 321 present, then each term in the Boolean clause is combined using 322 logical connectives (i.e., AND, OR, and NOT). 324 An I2NSF ECA Policy Rule has the following semantics: 326 IF is TRUE 328 IF is TRUE 330 THEN execute [constrained by metadata] 332 END-IF 334 END-IF 336 Technically, the "Policy Rule" is really a container that aggregates 337 the above three clauses, as well as metadata, which describe the 338 characteristics and behaviors of a capability (or an NSF). 339 Aggregating metadata enables a business logic to be used to prescribe 340 a behavior. For example, suppose a particular ECA Policy Rule 341 contains three actions (A1, A2, and A3, in that order). Action A2 342 has a priority of 10; actions A1 and A3 have no priority specified. 343 Then, metadata may be used to restrict the set of actions that can be 344 executed when the event and condition clauses of this ECA Policy Rule 345 are evaluated to be TRUE; two examples are: (1) only the first action 346 (A1) is executed, and then the policy rule returns to its caller, or 347 (2) all actions are executed, starting with the highest priority. 349 The above ECA policy model is very general and easily extensible. 351 3.2. Matched Policy Rule 353 The concept of a "matched" policy rule is defined as one in which its 354 event and condition clauses both evaluate to true. To precisely 355 describe what an NSF can do in terms of security, that a policy rule 356 needs to describe the events that it can catch, the conditions it can 357 evaluate, and the actions that it can enforce. 359 Therefore, the properties to characterize the capabilities of an NSF 360 are as follows: 362 o Ac is the set of Actions currently available from the NSF; 364 o Ec is the set of Events that an NSF can catch. Note that for NSF 365 (e.g., a packet filter) that are not able to react to events, this 366 set will be empty; 368 o Cc is the set of Conditions currently available from the NSF; 370 o EVc defines the set of Condition Clause Evaluation Rules that can 371 be used by the NSF to decide when the Condition Clause is true 372 when the results of the individual Conditions under evaluation are 373 given. 375 3.3. Conflict, Resolution Strategy and Default Action 377 Formally, two I2NSF Policy Rules conflict with each other if: 379 o the Event Clauses of each evaluate to TRUE; 381 o the Condition Clauses of each evaluate to TRUE; 383 o the Action Clauses affect the same object in different ways. 385 For example, if we have two Policy Rules in the same Policy: 387 R1: During 8am-6pm, if traffic is external, then run through FW 389 R2: During 7am-8pm, conduct anti-malware investigation 391 There is no conflict between R1 and R2, since the actions are 392 different. However, consider these two rules: 394 R3: During 8am-6pm, John gets GoldService 396 R4: During 10am-4pm, FTP from all users gets BronzeService 398 R3 and R4 are now in conflict, between the hours of 10am and 4pm, 399 because the actions of R3 and R4 are different and apply to the same 400 user (i.e., John). 402 Conflicts theoretically compromise the correct functioning of devices 403 (as happened for routers several year ago). However, NSFs have been 404 designed to cope with these issues. Since conflicts are originated 405 by simultaneously matching rules, an additional process decides the 406 action to be applied, e.g., among the ones which the matching rule 407 would have enforced. This process is described by means of a 408 resolution strategy for conflicts. 410 On the other hand, it may happen that, if an event is caught, none of 411 the policy rules matches the event. As a simple case, no rules may 412 match a packet arriving at border firewall. In this case, the packet 413 is usually dropped, that is, the firewall has a default behavior to 414 manage the cases that are not covered by specific rules. 416 Therefore, this document introduces another security capability that 417 serves to characterize valid policies for an NSF that solve conflicts 418 with resolution strategies and enforce default actions if no rules 419 match: 421 o RSc is the set of Resolution Strategies that can be used to 422 specify how to resolve conflicts that occur between the actions of 423 the same or different policy rules that are matched and contained 424 in this particular NSF; 426 o Dc defines the notion of a Default action. This action can be 427 either an explicit action or a set of actions. 429 4. Overview of YANG Data Model 431 This section provides an overview of how the YANG data model can be 432 used in the I2NSF framework described in [RFC8329]. Figure 1 shows 433 the capabilities (e.g., firewall and web filter) of NSFs in the I2NSF 434 Framework. As shown in this figure, an NSF Developer's Management 435 System (DMS) can register NSFs and the capabilities that the NSFs can 436 support. To register NSFs in this way, the DMS utilizes this 437 standardized capability YANG data model through the I2NSF 438 Registration Interface [RFC8329]. That is, this Registration 439 Interface uses the YANG module described in this document to describe 440 the capabilities of an NSF that is registered with the Security 441 Controller. With the database of the capabilities of the NSFs that 442 are maintained centrally, the NSFs can be more easily managed, which 443 can resolve many of the problems described in [RFC8192]. 445 In Figure 1, a new NSF at a Developer's Management System has 446 capabilities of Firewall (FW) and Web Filter (WF), which are denoted 447 as (Cap = {FW, WF}), to support Event-Condition-Action (ECA) policy 448 rules where 'E', 'C', and 'A' mean "Event", "Condition", and 449 "Action", respectively. The condition involves IPv4 or IPv6 450 datagrams, and the action includes "Allow" and "Deny" for those 451 datagrams. 453 Note that the NSF-Facing Interface [RFC8329] is used for the Security 454 Controller to configure the security policy rules of generic NSFs 455 (e.g., firewall) and advanced NSFs (e.g., anti-virus and Distributed- 456 Denial-of-Service (DDoS) attack mitigator) with the capabilities of 457 the NSFs registered with the Security Controller. 459 +------------------------------------------------------+ 460 | I2NSF User (e.g., Overlay Network Mgmt, Enterprise | 461 | Network Mgmt, another network domain's mgmt, etc.) | 462 +--------------------+---------------------------------+ 463 I2NSF ^ 464 Consumer-Facing Interface | 465 | 466 v I2NSF 467 +-----------------+------------+ Registration +-------------+ 468 | Network Operator Mgmt System | Interface | Developer's | 469 | (i.e., Security Controller) |<-------------->| Mgmt System | 470 +-----------------+------------+ +-------------+ 471 ^ New NSF 472 | Cap = {FW, WF} 473 I2NSF | E = {} 474 NSF-Facing Interface | C = {IPv4, IPv6} 475 | A = {Allow, Deny} 476 v 477 +---------------+----+------------+-----------------+ 478 | | | | 479 +---+---+ +---+---+ +---+---+ +---+---+ 480 | NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-n | 481 +-------+ +-------+ +-------+ +-------+ 482 NSF-1 NSF-m NSF-1 NSF-n 483 Cap = {FW, WF} Cap = {FW, WF} Cap = {FW, WF} Cap = {FW, WF} 484 E = {} E = {user} E = {dev} E = {time} 485 C = {IPv4} C = {IPv6} C = {IPv4, IPv6} C = {IPv4} 486 A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} 488 Developer's Mgmt System A Developer's Mgmt System B 490 Figure 1: Capabilities of NSFs in I2NSF Framework 492 A use case of an NSF with the capabilities of firewall and web filter 493 is described as follows. 495 o If a network administrator wants to apply security policy rules to 496 block malicious users with firewall and web filter, it is a 497 tremendous burden for a network administrator to apply all of the 498 needed rules to NSFs one by one. This problem can be resolved by 499 managing the capabilities of NSFs as described in this document. 501 o If a network administrator wants to block IPv4 or IPv6 packets 502 from malicious users, the network administrator sends a security 503 policy rule to block the users to the Network Operator Management 504 System (i.e., Security Controller) using the I2NSF Consumer-Facing 505 Interface. 507 o When the Network Operator Management System receives the security 508 policy rule, it automatically sends that security policy rule to 509 appropriate NSFs (i.e., NSF-m in Developer's Management System A 510 and NSF-1 in Developer's Management System B) which can support 511 the capabilities (i.e., IPv6). This lets an I2NSF User not 512 consider which specific NSF(s) will work for the security policy 513 rule. 515 o If NSFs encounter the suspicious IPv4 or IPv6 packets of malicious 516 users, they can filter the packets out according to the configured 517 security policy rule. Therefore, the security policy rule against 518 the malicious users' packets can be automatically applied to 519 appropriate NSFs without human intervention. 521 5. YANG Tree Diagram 523 This section shows a YANG tree diagram of capabilities of network 524 security functions, as defined in the Section 3. 526 5.1. Network Security Function (NSF) Capabilities 528 This section explains a YANG tree diagram of NSF capabilities and its 529 features. Figure 2 shows a YANG tree diagram of NSF capabilities. 530 The NSF capabilities in the tree include time capabilities, event 531 capabilities, condition capabilities, action capabilities, resolution 532 strategy capabilities, and default action capabilities. Those 533 capabilities can be tailored or extended according to a vendor's 534 specific requirements. Refer to the NSF capabilities information 535 model for detailed discussion in Section 3. 537 module: ietf-i2nsf-capability 538 +--rw nsf* [nsf-name] 539 +--rw nsf-name string 540 +--rw time-capabilities* enumeration 541 +--rw event-capabilities 542 | +--rw system-event-capability* identityref 543 | +--rw system-alarm-capability* identityref 544 +--rw condition-capabilities 545 | +--rw generic-nsf-capabilities 546 | | +--rw ipv4-capability* identityref 547 | | +--rw icmp-capability* identityref 548 | | +--rw ipv6-capability* identityref 549 | | +--rw icmpv6-capability* identityref 550 | | +--rw tcp-capability* identityref 551 | | +--rw udp-capability* identityref 552 | | +--rw sctp-capability* identityref 553 | | +--rw dccp-capability* identityref 554 | +--rw advanced-nsf-capabilities 555 | | +--rw anti-virus-capability* identityref 556 | | +--rw anti-ddos-capability* identityref 557 | | +--rw ips-capability* identityref 558 | | +--rw url-capability* identityref 559 | | +--rw voip-volte-capability* identityref 560 | +--rw context-capabilities* identityref 561 +--rw action-capabilities 562 | +--rw ingress-action-capability* identityref 563 | +--rw egress-action-capability* identityref 564 | +--rw log-action-capability* identityref 565 +--rw resolution-strategy-capabilities* identityref 566 +--rw default-action-capabilities* identityref 567 +--rw ipsec-method* identityref 569 Figure 2: YANG Tree Diagram of Capabilities of Network Security 570 Functions 572 Time capabilities are used to specify the capabilities which describe 573 when to execute the I2NSF policy rule. The time capabilities are 574 defined in terms of absolute time and periodic time. The absolute 575 time means the exact time to start or end. The periodic time means 576 repeated time like day, week, or month. 578 Event capabilities are used to specify the capabilities that describe 579 an event that would trigger the evaluation of the condition clause of 580 the I2NSF Policy Rule. The defined event capabilities are system 581 event and system alarm. 583 Condition capabilities are used to specify capabilities of a set of 584 attributes, features, and/or values that are to be compared with a 585 set of known attributes, features, and/or values in order to 586 determine whether a set of actions needs to be executed or not so 587 that an imperative I2NSF policy rule can be executed. In this 588 document, two kinds of condition capabilities are used to classify 589 different capabilities of NSFs such as generic-nsf-capabilities for 590 generic NSFs and advanced-nsf-capabilities for advanced NSFs. First, 591 the generic-nsf-capabilities define the common capabilities of NSFs 592 such as IPv4 capability, IPv6 capability, TCP capability, UDP 593 capability, SCTP capability, DCCP capability, ICMP capability, and 594 ICMPv6 capability. Second, the advanced-nsf-capabilities define 595 advanced capabilities of NSFs such as anti-virus capability, anti- 596 DDoS capability, Intrusion Prevention System (IPS) capability, HTTP 597 capability, and VoIP/VoLTE capability. Note that VoIP and VoLTE are 598 merged into a single capability in this document because VoIP and 599 VoLTE use the Session Initiation Protocol (SIP) [RFC3261] for a call 600 setup. See Section 3.1 for more information about the condition in 601 the ECA policy model. 603 Action capabilities are used to specify the capabilities that 604 describe the control and monitoring aspects of flow-based NSFs when 605 the event and condition clauses are satisfied. The action 606 capabilities are defined as ingress-action capability, egress-action 607 capability, and log-action capability. See Section 3.1 for more 608 information about the action in the ECA policy model. Also, see 609 Section 7.2 (NSF-Facing Flow Security Policy Structure) in [RFC8329] 610 for more information about the ingress and egress actions. In 611 addition, see Section 9.1 (Flow-Based NSF Capability 612 Characterization) in [RFC8329] and Section 7.5 (NSF Logs) in 613 [I-D.ietf-i2nsf-nsf-monitoring-data-model] for more information about 614 logging at NSFs. 616 Resolution strategy capabilities are used to specify the capabilities 617 that describe conflicts that occur between the actions of the same or 618 different policy rules that are matched and contained in this 619 particular NSF. The resolution strategy capabilities are defined as 620 First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized 621 Matching Rule (PMR), Prioritized Matching Rule with Errors (PMRE), 622 and Prioritized Matching Rule with No Errors (PMRN). See Section 3.3 623 for more information about the resolution strategy. 625 Default action capabilities are used to specify the capabilities that 626 describe how to execute I2NSF policy rules when no rule matches a 627 packet. The default action capabilities are defined as pass, drop, 628 alert, and mirror. See Section 3.3 for more information about the 629 default action. 631 IPsec method capabilities are used to specify capabilities of how to 632 support an Internet Key Exchange (IKE) [RFC7296] for the security 633 communication. The default action capabilities are defined as IKE or 634 IKE-less. See [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] for more 635 information about the SDN-based IPsec flow protection in I2NSF. 637 6. YANG Data Model of I2NSF NSF Capability 639 This section introduces a YANG module for NSFs' capabilities, as 640 defined in the Section 3. 642 This YANG module imports from [RFC6991]. It makes references to 644 o [RFC0768] 646 o [RFC0791] 648 o [RFC0792] 650 o [RFC0793] 652 o [RFC2474] 654 o [RFC3168] 656 o [RFC3261] 658 o [RFC4340] 660 o [RFC4443] 662 o [RFC4960] 664 o [RFC5595] 666 o [RFC6335] 668 o [RFC6437] 670 o [RFC6691] 672 o [RFC6864] 674 o [RFC7230] 676 o [RFC7231] 678 o [RFC7296] 679 o [RFC7323] 681 o [RFC8200] 683 o [RFC8329] 685 o [RFC8519] 687 o [RFC8805] 689 o [IANA-Protocol-Numbers] 691 o [I-D.ietf-tcpm-rfc793bis] 693 o [I-D.ietf-tcpm-accurate-ecn] 695 o [I-D.ietf-tsvwg-udp-options] 697 o [I-D.ietf-i2nsf-nsf-monitoring-data-model] 699 o [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] 701 file "ietf-i2nsf-capability@2020-12-30.yang" 703 module ietf-i2nsf-capability { 704 yang-version 1.1; 705 namespace 706 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; 707 prefix 708 nsfcap; 710 organization 711 "IETF I2NSF (Interface to Network Security Functions) 712 Working Group"; 714 contact 715 "WG Web: 716 WG List: 718 Editor: Jaehoon Paul Jeong 719 721 Editor: Jinyong Tim Kim 722 724 Editor: Susan Hares 725 "; 727 description 728 "This module is a YANG module for I2NSF Network Security 729 Functions (NSFs)'s Capabilities. 731 Copyright (c) 2020 IETF Trust and the persons identified as 732 authors of the code. All rights reserved. 734 Redistribution and use in source and binary forms, with or 735 without modification, is permitted pursuant to, and subject 736 to the license terms contained in, the Simplified BSD License 737 set forth in Section 4.c of the IETF Trust's Legal Provisions 738 Relating to IETF Documents 739 http://trustee.ietf.org/license-info). 741 This version of this YANG module is part of RFC XXXX; see 742 the RFC itself for full legal notices."; 744 // RFC Ed.: replace XXXX with an actual RFC number and remove 745 // this note. 747 revision "2020-12-30"{ 748 description "Initial revision."; 749 reference 750 "RFC XXXX: I2NSF Capability YANG Data Model"; 752 // RFC Ed.: replace XXXX with an actual RFC number and remove 753 // this note. 754 } 756 /* 757 * Identities 758 */ 760 identity event { 761 description 762 "Base identity for I2NSF events."; 763 reference 764 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 765 Monitoring YANG Data Model - Event"; 767 // RFC Ed.: replace the above draft with an actual RFC in the 768 // YANG module and remove this note. 769 } 771 identity system-event-capability { 772 base event; 773 description 774 "Identity for system event"; 776 reference 777 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 778 Monitoring YANG Data Model - System event"; 779 } 781 identity system-alarm-capability { 782 base event; 783 description 784 "Identity for system alarm"; 785 reference 786 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 787 Monitoring YANG Data Model - System alarm"; 788 } 790 identity access-violation { 791 base system-event-capability; 792 description 793 "Identity for access violation event"; 794 reference 795 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 796 Monitoring YANG Data Model - System event for access 797 violation"; 798 } 800 identity configuration-change { 801 base system-event-capability; 802 description 803 "Identity for configuration change event"; 804 reference 805 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 806 Monitoring YANG Data Model - System event for configuration 807 change"; 808 } 810 identity memory-alarm { 811 base system-alarm-capability; 812 description 813 "Identity for memory alarm. Alarm when memory usage 814 exceeds a threshold."; 815 reference 816 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 817 Monitoring YANG Data Model - System alarm for memory"; 818 } 820 identity cpu-alarm { 821 base system-alarm-capability; 822 description 823 "Identity for CPU alarm. Alarm when CPU usage 824 exceeds a threshold."; 825 reference 826 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 827 Monitoring YANG Data Model - System alarm for CPU"; 828 } 830 identity disk-alarm { 831 base system-alarm-capability; 832 description 833 "Identity for disk alarm. Alarm when disk usage 834 exceeds a threshold."; 835 reference 836 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 837 Monitoring YANG Data Model - System alarm for disk"; 838 } 840 identity hardware-alarm { 841 base system-alarm-capability; 842 description 843 "Identity for hardware alarm. Alarm when a hardware failure 844 or hardware degradation occurs."; 845 reference 846 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 847 Monitoring YANG Data Model - System alarm for hardware"; 848 } 850 identity interface-alarm { 851 base system-alarm-capability; 852 description 853 "Identity for interface alarm. Alarm when interface usage 854 exceeds a threshold."; 855 reference 856 "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF 857 Monitoring YANG Data Model - System alarm for interface"; 858 } 860 identity condition { 861 description 862 "Base identity for I2NSF conditions"; 863 } 865 identity context-capability { 866 base condition; 867 description 868 "Base identity for context condition capabilities for an NSF. 869 The context contains background information of various 870 entities such as an access control list, application layer 871 filter, target, user, group, and geography."; 873 } 875 identity access-control-list { 876 base context-capability; 877 description 878 "Identity for Access Control List (ACL) condition capability"; 879 reference 880 "RFC 8519: YANG Data Model for Network Access Control Lists 881 (ACLs) - A user-ordered set of rules used to configure the 882 forwarding behavior in an NSF."; 883 } 885 identity application-layer-filter { 886 base context-capability; 887 description 888 "Identity for application-layer-filter condition capability. 889 application-layer-filter capability can examine the contents 890 of a packet (e.g., a URL contained in an HTTP message)."; 891 reference 892 "RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message 893 Syntax and Routing 894 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 895 and Content"; 896 } 898 identity target { 899 base context-capability; 900 description 901 "Identity for target condition capability"; 902 reference 903 "RFC 8519: YANG Data Model for Network Access Control Lists 904 (ACLs) - An access control for a target (e.g., the 905 corresponding IP address) in an NSF."; 906 } 908 identity user { 909 base context-capability; 910 description 911 "Identity for user condition capability. 912 A user (e.g., employee) can be mapped to an IP address of 913 a computing device (e.g., computer, laptop, and virtual 914 machine) which the user is using."; 915 reference 916 "RFC 8519: YANG Data Model for Network Access Control Lists 917 (ACLs) - An access control for a user (e.g., the 918 corresponding IP address) in an NSF."; 919 } 920 identity group { 921 base context-capability; 922 description 923 "Identity for group condition capability. 924 A group (e.g., employees) can be mapped to multiple IP 925 addresses of computing devices (e.g., computers, laptops, 926 and virtual machines) which the group is using."; 927 reference 928 "RFC 8519: YANG Data Model for Network Access Control Lists 929 (ACLs) - An access control for a group (e.g., the 930 corresponding IP addresses) in an NSF."; 931 } 933 identity geography { 934 base context-capability; 935 description 936 "Identity for geography condition capability"; 937 reference 938 "RFC 8805: A Format for Self-Published IP Geolocation Feeds - 939 An access control for a geographical location (i.e., 940 geolocation) that has the corresponding IP prefix."; 941 } 943 identity ipv4-capability { 944 base condition; 945 description 946 "Base identity for IPv4 condition capability"; 947 reference 948 "RFC 791: Internet Protocol"; 949 } 951 identity exact-ipv4-header-length { 952 base ipv4-capability; 953 description 954 "Identity for exact-match IPv4 header-length 955 condition capability"; 956 reference 957 "RFC 791: Internet Protocol - Header Length"; 958 } 960 identity range-ipv4-header-length { 961 base ipv4-capability; 962 description 963 "Identity for range-match IPv4 header-length 964 condition capability"; 965 reference 966 "RFC 791: Internet Protocol - Header Length"; 967 } 968 identity ipv4-tos-dscp { 969 base ipv4-capability; 970 description 971 "Identity for IPv4 Type-Of-Service (TOS) 972 Differentiated Services Codepoint (DSCP) 973 condition capability"; 974 reference 975 "RFC 791: Internet Protocol - Type of Service 976 RFC 2474: Definition of the Differentiated 977 Services Field (DS Field) in the IPv4 and 978 IPv6 Headers"; 979 } 981 identity exact-ipv4-total-length { 982 base ipv4-capability; 983 description 984 "Identity for exact-match IPv4 total length 985 condition capability"; 986 reference 987 "RFC 791: Internet Protocol - Total Length"; 988 } 990 identity range-ipv4-total-length { 991 base ipv4-capability; 992 description 993 "Identity for range-match IPv4 total length 994 condition capability"; 995 reference 996 "RFC 791: Internet Protocol - Total Length"; 997 } 999 identity ipv4-id { 1000 base ipv4-capability; 1001 description 1002 "Identity for IPv4 identification condition capability. 1003 IPv4 ID field is used for fragmentation and reassembly."; 1004 reference 1005 "RFC 791: Internet Protocol - Identification 1006 RFC 6864: Updated Specification of the IPv4 ID Field - 1007 Fragmentation and Reassembly"; 1008 } 1010 identity ipv4-fragment-flags { 1011 base ipv4-capability; 1012 description 1013 "Identity for IPv4 fragment flags condition capability"; 1014 reference 1015 "RFC 791: Internet Protocol - Fragmentation Flags"; 1017 } 1019 identity exact-ipv4-fragment-offset { 1020 base ipv4-capability; 1021 description 1022 "Identity for exact-match IPv4 fragment offset 1023 condition capability"; 1024 reference 1025 "RFC 791: Internet Protocol - Fragmentation Offset"; 1026 } 1028 identity range-ipv4-fragment-offset { 1029 base ipv4-capability; 1030 description 1031 "Identity for range-match IPv4 fragment offset 1032 condition capability"; 1033 reference 1034 "RFC 791: Internet Protocol - Fragmentation Offset"; 1035 } 1037 identity exact-ipv4-ttl { 1038 base ipv4-capability; 1039 description 1040 "Identity for exact-match IPv4 Time-To-Live (TTL) 1041 condition capability"; 1042 reference 1043 "RFC 791: Internet Protocol - Time To Live (TTL)"; 1044 } 1046 identity range-ipv4-ttl { 1047 base ipv4-capability; 1048 description 1049 "Identity for range-match IPv4 Time-To-Live (TTL) 1050 condition capability"; 1051 reference 1052 "RFC 791: Internet Protocol - Time To Live (TTL)"; 1053 } 1055 identity ipv4-protocol { 1056 base ipv4-capability; 1057 description 1058 "Identity for IPv4 protocol condition capability"; 1059 reference 1060 "IANA Website: Assigned Internet Protocol Numbers 1061 - Protocol Number for IPv4 1062 RFC 791: Internet Protocol - Protocol"; 1063 } 1064 identity prefix-ipv4-address { 1065 base ipv4-capability; 1066 description 1067 "Identity for prefix-match IPv4 address 1068 condition capability. The addresses are 1069 specified by a pair of prefix and prefix 1070 length."; 1071 reference 1072 "RFC 791: Internet Protocol - Address"; 1073 } 1075 identity range-ipv4-address { 1076 base ipv4-capability; 1077 description 1078 "Identity for range-match IPv4 address condition 1079 capability. The range addresses are specified 1080 by a start address and an end address."; 1081 reference 1082 "RFC 791: Internet Protocol - Address"; 1083 } 1085 identity ipv4-ip-opts { 1086 base ipv4-capability; 1087 description 1088 "Identity for IPv4 option condition capability"; 1089 reference 1090 "RFC 791: Internet Protocol - Options"; 1091 } 1093 identity ipv4-geo-ip { 1094 base ipv4-capability; 1095 description 1096 "Identity for IPv4 geography condition capability"; 1097 reference 1098 "RFC 8805: Self-published IP Geolocation Data - An 1099 access control for a geographical location i.e., 1100 geolocation (e.g., the corresponding IP address)."; 1101 } 1103 identity ipv6-capability { 1104 base condition; 1105 description 1106 "Base identity for IPv6 condition capabilities"; 1107 reference 1108 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1109 Specification"; 1110 } 1111 identity ipv6-traffic-class-dscp { 1112 base ipv6-capability; 1113 description 1114 "Identity for IPv6 traffic classes 1115 Differentiated Services Codepoint (DSCP) 1116 condition capability"; 1117 reference 1118 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1119 Specification - Traffic Class 1120 RFC 2474: Definition of the Differentiated 1121 Services Field (DS Field) in the IPv4 and 1122 IPv6 Headers."; 1123 } 1125 identity exact-ipv6-flow-label { 1126 base ipv6-capability; 1127 description 1128 "Identity for exact-match IPv6 flow label 1129 condition capability"; 1130 reference 1131 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1132 Specification - Flow Label 1133 RFC 6437: IPv6 Flow Label Specification"; 1134 } 1136 identity range-ipv6-flow-label { 1137 base ipv6-capability; 1138 description 1139 "Identity for range-match IPv6 flow label 1140 condition capability"; 1141 reference 1142 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1143 Specification - Flow Label 1144 RFC 6437: IPv6 Flow Label Specification"; 1145 } 1147 identity exact-ipv6-payload-length { 1148 base ipv6-capability; 1149 description 1150 "Identity for exact-match IPv6 payload length 1151 condition capability"; 1152 reference 1153 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1154 Specification - Payload Length"; 1155 } 1157 identity range-ipv6-payload-length { 1158 base ipv6-capability; 1159 description 1160 "Identity for range-match IPv6 payload length 1161 condition capability"; 1162 reference 1163 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1164 Specification - Payload Length"; 1165 } 1167 identity ipv6-next-header { 1168 base ipv6-capability; 1169 description 1170 "Identity for IPv6 next header condition capability"; 1171 reference 1172 "IANA Website: Assigned Internet Protocol Numbers 1173 - Protocol Number for IPv6 1174 RFC 8200: Internet Protocol, Version 6 (IPv6) 1175 Specification - Next Header"; 1176 } 1178 identity exact-ipv6-hop-limit { 1179 base ipv6-capability; 1180 description 1181 "Identity for exact-match IPv6 hop limit condition 1182 capability"; 1183 reference 1184 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1185 Specification - Hop Limit"; 1186 } 1188 identity range-ipv6-hop-limit { 1189 base ipv6-capability; 1190 description 1191 "Identity for range-match IPv6 hop limit condition 1192 capability"; 1193 reference 1194 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1195 Specification - Hop Limit"; 1196 } 1198 identity prefix-ipv6-address { 1199 base ipv6-capability; 1200 description 1201 "Identity for prefix-match IPv6 address condition 1202 capability. The addresses are specified by a pair 1203 of prefix and prefix length."; 1204 reference 1205 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1206 Specification - Address"; 1208 } 1210 identity range-ipv6-address { 1211 base ipv6-capability; 1212 description 1213 "Identity for range-match IPv6 address condition 1214 capability. The addresses are specified by a start 1215 address and an end address."; 1216 reference 1217 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1218 Specification - Address"; 1219 } 1221 identity ipv6-header-order { 1222 base ipv6-capability; 1223 description 1224 "Identity for IPv6 extension header order condition 1225 capability"; 1226 reference 1227 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1228 Specification - Extension Header Order"; 1229 } 1231 identity ipv6-options { 1232 base ipv6-capability; 1233 description 1234 "Identity for IPv6 options type condition 1235 capability"; 1236 reference 1237 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1238 Specification - Options"; 1239 } 1241 identity ipv6-hop-by-hop { 1242 base ipv6-capability; 1243 description 1244 "Identity for IPv6 hop by hop options header 1245 condition capability"; 1246 reference 1247 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1248 Specification - Options"; 1249 } 1251 identity ipv6-routing-header { 1252 base ipv6-capability; 1253 description 1254 "Identity for IPv6 routing header condition 1255 capability"; 1257 reference 1258 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1259 Specification - Routing Header"; 1260 } 1262 identity ipv6-fragment-header { 1263 base ipv6-capability; 1264 description 1265 "Identity for IPv6 fragment header condition 1266 capability"; 1267 reference 1268 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1269 Specification - Fragment Header"; 1270 } 1272 identity ipv6-destination-options { 1273 base ipv6-capability; 1274 description 1275 "Identity for IPv6 destination options condition 1276 capability"; 1277 reference 1278 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1279 Specification - Destination Options"; 1280 } 1282 identity ipv6-geo-ip { 1283 base ipv6-capability; 1284 description 1285 "Identity for IPv4 geography condition capability"; 1286 reference 1287 "RFC 8805: Self-published IP Geolocation Data - An 1288 access control for a geographical location i.e., 1289 geolocation (e.g., the corresponding IP address)."; 1290 } 1292 identity tcp-capability { 1293 base condition; 1294 description 1295 "Base identity for TCP condition capabilities"; 1296 reference 1297 "RFC 793: Transmission Control Protocol 1298 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1299 (TCP) Specification"; 1300 } 1302 identity exact-tcp-port-num { 1303 base tcp-capability; 1304 description 1305 "Identity for exact-match TCP port number condition 1306 capability"; 1307 reference 1308 "RFC 793: Transmission Control Protocol - Port Number 1309 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1310 (TCP) Specification"; 1311 } 1313 identity range-tcp-port-num { 1314 base tcp-capability; 1315 description 1316 "Identity for range-match TCP port number condition 1317 capability"; 1318 reference 1319 "RFC 793: Transmission Control Protocol - Port Number 1320 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1321 (TCP) Specification"; 1322 } 1324 identity tcp-flags { 1325 base tcp-capability; 1326 description 1327 "Identity for TCP control bits (flags) condition capability"; 1328 reference 1329 "RFC 793: Transmission Control Protocol - Flags 1330 RFC 3168: The Addition of Explicit Congestion Notification 1331 (ECN) to IP - TCP Header Flags 1332 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1333 (TCP) Specification 1334 draft-ietf-tcpm-accurate-ecn: More Accurate ECN Feedback 1335 in TCP"; 1336 } 1338 identity tcp-options { 1339 base tcp-capability; 1340 description 1341 "Identity for TCP options condition capability"; 1342 reference 1343 "RFC 793: Transmission Control Protocol - Options 1344 draft-ietf-tcpm-rfc793bis: Transmission Control Protocol 1345 (TCP) Specification 1346 RFC 6691: TCP Options and Maximum Segment Size 1347 RFC 7323: TCP Extensions for High Performance"; 1348 } 1350 identity udp-capability { 1351 base condition; 1352 description 1353 "Base identity for UDP condition capabilities"; 1354 reference 1355 "RFC 768: User Datagram Protocol"; 1356 } 1358 identity exact-udp-port-num { 1359 base udp-capability; 1360 description 1361 "Identity for exact-match UDP port number condition capability"; 1362 reference 1363 "RFC 768: User Datagram Protocol - Port Number"; 1364 } 1366 identity range-udp-port-num { 1367 base udp-capability; 1368 description 1369 "Identity for range-match UDP port number condition capability"; 1370 reference 1371 "RFC 768: User Datagram Protocol - Port Number"; 1372 } 1374 identity exact-udp-total-length { 1375 base udp-capability; 1376 description 1377 "Identity for exact-match UDP total-length condition capability. 1378 The UDP total length can be smaller than the IP transport 1379 length for UDP transport layer options."; 1380 reference 1381 "RFC 768: User Datagram Protocol - Total Length 1382 draft-ietf-tsvwg-udp-options: Transport Options for UDP"; 1383 } 1385 identity range-udp-total-length { 1386 base udp-capability; 1387 description 1388 "Identity for range-match UDP total-length condition capability 1389 The UDP total length can be smaller than the IP transport 1390 length for UDP transport layer options."; 1391 reference 1392 "RFC 768: User Datagram Protocol - Total Length 1393 draft-ietf-tsvwg-udp-options: Transport Options for UDP"; 1394 } 1396 identity sctp-capability { 1397 description 1398 "Identity for SCTP condition capabilities"; 1399 reference 1400 "RFC 4960: Stream Control Transmission Protocol"; 1402 } 1404 identity exact-sctp-port-num { 1405 base sctp-capability; 1406 description 1407 "Identity for exact-match SCTP port number condition 1408 capability"; 1409 reference 1410 "RFC 4960: Stream Control Transmission Protocol - Port Number"; 1411 } 1413 identity range-sctp-port-num { 1414 base sctp-capability; 1415 description 1416 "Identity for range-match SCTP port number condition 1417 capability"; 1418 reference 1419 "RFC 4960: Stream Control Transmission Protocol - Port Number"; 1420 } 1422 identity sctp-verification-tag { 1423 base sctp-capability; 1424 description 1425 "Identity for range-match SCTP verification tag condition 1426 capability"; 1427 reference 1428 "RFC 4960: Stream Control Transmission Protocol - Verification Tag"; 1429 } 1431 identity sctp-chunk-type { 1432 base sctp-capability; 1433 description 1434 "Identity for SCTP chunk type condition capability"; 1435 reference 1436 "RFC 4960: Stream Control Transmission Protocol - Chunk Type"; 1437 } 1439 identity dccp-capability { 1440 description 1441 "Identity for DCCP condition capabilities"; 1442 reference 1443 "RFC 4340: Datagram Congestion Control Protocol"; 1444 } 1446 identity exact-dccp-port-num { 1447 base dccp-capability; 1448 description 1449 "Identity for exact-match DCCP port number condition 1450 capability"; 1451 reference 1452 "RFC 4340: Datagram Congestion Control Protocol"; 1453 } 1455 identity range-dccp-port-num { 1456 base dccp-capability; 1457 description 1458 "Identity for range-match DCCP port number condition 1459 capability"; 1460 reference 1461 "RFC 4340: Datagram Congestion Control Protocol"; 1462 } 1464 identity dccp-service-code { 1465 base dccp-capability; 1466 description 1467 "Identity for DCCP Service Code condition capabilitiy"; 1468 reference 1469 "RFC 4340: Datagram Congestion Control Protocol 1470 RFC 5595: The Datagram Congestion Control Protocol (DCCP) 1471 Service Codes 1472 RFC 6335: Internet Assigned Numbers Authority (IANA) 1473 Procedures for the Management of the Service Name and 1474 Transport Protocol Port Number Registry - Service Code"; 1475 } 1477 identity icmp-capability { 1478 base condition; 1479 description 1480 "Base identity for ICMP condition capability"; 1481 reference 1482 "RFC 792: Internet Control Message Protocol"; 1483 } 1485 identity icmp-type { 1486 base icmp-capability; 1487 description 1488 "Identity for ICMP type condition capability"; 1489 reference 1490 "RFC 792: Internet Control Message Protocol"; 1491 } 1493 identity icmp-code { 1494 base icmp-capability; 1495 description 1496 "Identity for ICMP code condition capability"; 1497 reference 1498 "RFC 792: Internet Control Message Protocol"; 1499 } 1501 identity icmpv6-capability { 1502 base condition; 1503 description 1504 "Base identity for ICMPv6 condition capability"; 1505 reference 1506 "RFC 4443: Internet Control Message Protocol (ICMPv6) 1507 for the Internet Protocol Version 6 (IPv6) Specification 1508 - ICMPv6"; 1509 } 1511 identity icmpv6-type { 1512 base icmpv6-capability; 1513 description 1514 "Identity for ICMPv6 type condition capability"; 1515 reference 1516 "RFC 4443: Internet Control Message Protocol (ICMPv6) 1517 for the Internet Protocol Version 6 (IPv6) Specification 1518 - ICMPv6"; 1519 } 1521 identity icmpv6-code { 1522 base icmpv6-capability; 1523 description 1524 "Identity for ICMPv6 code condition capability"; 1525 reference 1526 "RFC 4443: Internet Control Message Protocol (ICMPv6) 1527 for the Internet Protocol Version 6 (IPv6) Specification 1528 - ICMPv6"; 1529 } 1531 identity url-capability { 1532 base condition; 1533 description 1534 "Base identity for URL condition capability"; 1535 } 1537 identity pre-defined { 1538 base url-capability; 1539 description 1540 "Identity for pre-defined URL Database condition capability. 1541 where URL database is a public database for URL filtering."; 1542 } 1544 identity user-defined { 1545 base url-capability; 1546 description 1547 "Identity for user-defined URL Database condition capability. 1548 that allows a users manual addition of URLs for URL 1549 filtering."; 1550 } 1552 identity log-action-capability { 1553 description 1554 "Base identity for log-action capability"; 1555 } 1557 identity rule-log { 1558 base log-action-capability; 1559 description 1560 "Identity for rule log log-action capability. 1561 Log the received packet based on the rule"; 1562 } 1564 identity session-log { 1565 base log-action-capability; 1566 description 1567 "Identity for session log log-action capability. 1568 Log the received packet based on the session."; 1569 } 1571 identity ingress-action-capability { 1572 description 1573 "Base identity for ingress-action capability"; 1574 reference 1575 "RFC 8329: Framework for Interface to Network Security 1576 Functions - Ingress action"; 1577 } 1579 identity egress-action-capability { 1580 description 1581 "Base identity for egress-action capability"; 1582 reference 1583 "RFC 8329: Framework for Interface to Network Security 1584 Functions - Egress action"; 1585 } 1587 identity default-action-capability { 1588 description 1589 "Base identity for default-action capability"; 1590 } 1592 identity pass { 1593 base ingress-action-capability; 1594 base egress-action-capability; 1595 base default-action-capability; 1596 description 1597 "Identity for pass action capability"; 1598 reference 1599 "RFC 8329: Framework for Interface to Network Security 1600 Functions - Ingress, egress, and pass actions."; 1601 } 1603 identity drop { 1604 base ingress-action-capability; 1605 base egress-action-capability; 1606 base default-action-capability; 1607 description 1608 "Identity for drop action capability"; 1609 reference 1610 "RFC 8329: Framework for Interface to Network Security 1611 Functions - Ingress, egress, and drop actions."; 1612 } 1614 identity alert { 1615 base ingress-action-capability; 1616 base egress-action-capability; 1617 base default-action-capability; 1618 description 1619 "Identity for alert action capability"; 1620 reference 1621 "RFC 8329: Framework for Interface to Network Security 1622 Functions - Ingress, egress, and alert actions. 1623 draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF 1624 NSF Monitoring YANG Data Model - Alarm (i.e., alert)."; 1625 } 1627 identity mirror { 1628 base ingress-action-capability; 1629 base egress-action-capability; 1630 base default-action-capability; 1631 description 1632 "Identity for mirror action capability"; 1633 reference 1634 "RFC 8329: Framework for Interface to Network Security 1635 Functions - Ingress, egress, and mirror actions."; 1636 } 1638 identity invoke-signaling { 1639 base egress-action-capability; 1640 description 1641 "Identity for invoke signaling action capability"; 1643 reference 1644 "RFC 8329: Framework for Interface to Network Security 1645 Functions - Invoke-signaling action"; 1646 } 1648 identity forwarding { 1649 base egress-action-capability; 1650 description 1651 "Identity for forwarding action capability"; 1652 reference 1653 "RFC 8329: Framework for Interface to Network Security 1654 Functions - Forwarding action"; 1655 } 1657 identity redirection { 1658 base egress-action-capability; 1659 description 1660 "Identity for redirection action capability"; 1661 reference 1662 "RFC 8329: Framework for Interface to Network Security 1663 Functions - Redirection action"; 1664 } 1666 identity resolution-strategy-capability { 1667 description 1668 "Base identity for resolution strategy capability"; 1669 } 1671 identity fmr { 1672 base resolution-strategy-capability; 1673 description 1674 "Identity for First Matching Rule (FMR) resolution 1675 strategy capability"; 1676 } 1678 identity lmr { 1679 base resolution-strategy-capability; 1680 description 1681 "Identity for Last Matching Rule (LMR) resolution 1682 strategy capability"; 1683 } 1685 identity pmr { 1686 base resolution-strategy-capability; 1687 description 1688 "Identity for Prioritized Matching Rule (PMR) resolution 1689 strategy capability"; 1690 } 1691 identity pmre { 1692 base resolution-strategy-capability; 1693 description 1694 "Identity for Prioritized Matching Rule with Errors (PMRE) 1695 resolution strategy capability"; 1696 } 1698 identity pmrn { 1699 base resolution-strategy-capability; 1700 description 1701 "Identity for Prioritized Matching Rule with No Errors (PMRN) 1702 resolution strategy capability"; 1703 } 1705 identity advanced-nsf-capability { 1706 description 1707 "Base identity for advanced Network Security Function (NSF) 1708 capability. This can be used for advanced NSFs such as 1709 Anti-Virus, Anti-DDoS Attack, IPS, and VoIP/VoLTE Security 1710 Service."; 1711 reference 1712 "RFC 8329: Framework for Interface to Network Security 1713 Functions - Advanced NSF capability"; 1714 } 1716 identity anti-virus-capability { 1717 base advanced-nsf-capability; 1718 description 1719 "Identity for advanced NSF Anti-Virus capability. 1720 This can be used for an extension point for Anti-Virus 1721 as an advanced NSF."; 1722 reference 1723 "RFC 8329: Framework for Interface to Network Security 1724 Functions - Advanced NSF Anti-Virus capability"; 1725 } 1727 identity anti-ddos-capability { 1728 base advanced-nsf-capability; 1729 description 1730 "Identity for advanced NSF Anti-DDoS Attack capability. 1731 This can be used for an extension point for Anti-DDoS 1732 Attack as an advanced NSF."; 1733 reference 1734 "RFC 8329: Framework for Interface to Network Security 1735 Functions - Advanced NSF Anti-DDoS Attack capability"; 1736 } 1738 identity ips-capability { 1739 base advanced-nsf-capability; 1740 description 1741 "Identity for advanced NSF IPS capabilities. This can be 1742 used for an extension point for IPS as an advanced NSF."; 1743 reference 1744 "RFC 8329: Framework for Interface to Network Security 1745 Functions - Advanced NSF IPS capability"; 1746 } 1748 identity voip-volte-capability { 1749 base advanced-nsf-capability; 1750 description 1751 "Identity for advanced NSF VoIP/VoLTE Security Service 1752 capability. This can be used for an extension point 1753 for VoIP/VoLTE Security Service as an advanced NSF."; 1754 reference 1755 "RFC 3261: SIP: Session Initiation Protocol"; 1756 } 1758 identity detect { 1759 base anti-virus-capability; 1760 description 1761 "Identity for advanced NSF Anti-Virus Detection capability. 1762 This can be used for an extension point for Anti-Virus 1763 Detection as an advanced NSF."; 1764 reference 1765 "RFC 8329: Framework for Interface to Network Security 1766 Functions - Advanced NSF Anti-Virus Detection capability"; 1767 } 1769 identity allow-list { 1770 base anti-virus-capability; 1771 description 1772 "Identity for advanced NSF Anti-Virus Allow List capability. 1773 This can be used for an extension point for Anti-Virus 1774 Allow List as an advanced NSF."; 1775 reference 1776 "RFC 8329: Framework for Interface to Network Security 1777 Functions - Advanced NSF Anti-Virus Allow List capability"; 1778 } 1780 identity syn-flood-action { 1781 base anti-ddos-capability; 1782 description 1783 "Identity for advanced NSF Anti-DDoS SYN Flood Action 1784 capability. This can be used for an extension point for 1785 Anti-DDoS SYN Flood Action as an advanced NSF."; 1786 reference 1787 "RFC 8329: Framework for Interface to Network Security 1788 Functions - Advanced NSF Anti-DDoS SYN Flood Action 1789 capability"; 1790 } 1792 identity udp-flood-action { 1793 base anti-ddos-capability; 1794 description 1795 "Identity for advanced NSF Anti-DDoS UDP Flood Action 1796 capability. This can be used for an extension point for 1797 Anti-DDoS UDP Flood Action as an advanced NSF."; 1798 reference 1799 "RFC 8329: Framework for Interface to Network Security 1800 Functions - Advanced NSF Anti-DDoS UDP Flood Action 1801 capability"; 1802 } 1804 identity http-flood-action { 1805 base anti-ddos-capability; 1806 description 1807 "Identity for advanced NSF Anti-DDoS HTTP Flood Action 1808 capability. This can be used for an extension point for 1809 Anti-DDoS HTTP Flood Action as an advanced NSF."; 1810 reference 1811 "RFC 8329: Framework for Interface to Network Security 1812 Functions - Advanced NSF Anti-DDoS HTTP Flood Action 1813 capability"; 1814 } 1816 identity https-flood-action { 1817 base anti-ddos-capability; 1818 description 1819 "Identity for advanced NSF Anti-DDoS HTTPS Flood Action 1820 capability. This can be used for an extension point for 1821 Anti-DDoS HTTPS Flood Action as an advanced NSF."; 1822 reference 1823 "RFC 8329: Framework for Interface to Network Security 1824 Functions - Advanced NSF Anti-DDoS HTTPS Flood Action 1825 capability"; 1826 } 1828 identity dns-request-flood-action { 1829 base anti-ddos-capability; 1830 description 1831 "Identity for advanced NSF Anti-DDoS DNS Request Flood 1832 Action capability. This can be used for an extension 1833 point for Anti-DDoS DNS Request Flood Action as an 1834 advanced NSF."; 1836 reference 1837 "RFC 8329: Framework for Interface to Network Security 1838 Functions - Advanced NSF Anti-DDoS DNS Request Flood 1839 Action capability"; 1840 } 1842 identity dns-reply-flood-action { 1843 base anti-ddos-capability; 1844 description 1845 "Identity for advanced NSF Anti-DDoS DNS Reply Flood 1846 Action capability. This can be used for an extension 1847 point for Anti-DDoS DNS Reply Flood Action as an 1848 advanced NSF."; 1849 reference 1850 "RFC 8329: Framework for Interface to Network Security 1851 Functions - Advanced NSF Anti-DDoS DNS Reply Flood 1852 Action capability"; 1853 } 1855 identity icmp-flood-action { 1856 base anti-ddos-capability; 1857 description 1858 "Identity for advanced NSF Anti-DDoS ICMP Flood Action 1859 capability. This can be used for an extension point 1860 for Anti-DDoS ICMP Flood Action as an advanced NSF."; 1861 reference 1862 "RFC 8329: Framework for Interface to Network Security 1863 Functions - Advanced NSF Anti-DDoS ICMP Flood Action 1864 capability"; 1865 } 1867 identity icmpv6-flood-action { 1868 base anti-ddos-capability; 1869 description 1870 "Identity for advanced NSF Anti-DDoS ICMPv6 Flood Action 1871 capability. This can be used for an extension point 1872 for Anti-DDoS ICMPv6 Flood Action as an advanced NSF."; 1873 reference 1874 "RFC 8329: Framework for Interface to Network Security 1875 Functions - Advanced NSF Anti-DDoS ICMPv6 Flood Action 1876 capability"; 1877 } 1879 identity sip-flood-action { 1880 base anti-ddos-capability; 1881 description 1882 "Identity for advanced NSF Anti-DDoS SIP Flood Action 1883 capability. This can be used for an extension point 1884 for Anti-DDoS SIP Flood Action as an advanced NSF."; 1885 reference 1886 "RFC 8329: Framework for Interface to Network Security 1887 Functions - Advanced NSF Anti-DDoS SIP Flood Action 1888 capability"; 1889 } 1891 identity detect-mode { 1892 base anti-ddos-capability; 1893 description 1894 "Identity for advanced NSF Anti-DDoS Detection Mode 1895 capability. This can be used for an extension point 1896 for Anti-DDoS Detection Mode as an advanced NSF."; 1897 reference 1898 "RFC 8329: Framework for Interface to Network Security 1899 Functions - Advanced NSF Anti-DDoS Detection Mode 1900 capability"; 1901 } 1903 identity baseline-learning { 1904 base anti-ddos-capability; 1905 description 1906 "Identity for advanced NSF Anti-DDoS Baseline Learning 1907 capability. This can be used for an extension point 1908 for Anti-DDoS Baseline Learning as an advanced NSF."; 1909 reference 1910 "RFC 8329: Framework for Interface to Network Security 1911 Functions - Advanced NSF Anti-DDoS Baseline Learning 1912 capability"; 1913 } 1915 identity signature-set { 1916 base ips-capability; 1917 description 1918 "Identity for advanced NSF IPS Signature Set capability. 1919 This can be used for an extension point for IPS Signature 1920 Set as an advanced NSF."; 1921 reference 1922 "RFC 8329: Framework for Interface to Network Security 1923 Functions - Advanced NSF IPS Signature Set capability"; 1924 } 1926 identity ips-exception-signature { 1927 base ips-capability; 1928 description 1929 "Identity for advanced NSF IPS Exception Signature 1930 capability. This can be used for an extension point for 1931 IPS Exception Signature as an advanced NSF."; 1933 reference 1934 "RFC 8329: Framework for Interface to Network Security 1935 Functions - Advanced NSF IPS Exception Signature Set 1936 capability"; 1937 } 1939 identity voip-volte-call-id { 1940 base voip-volte-capability; 1941 description 1942 "Identity for advanced NSF VoIP/VoLTE Call Identifier (ID) 1943 capability. This can be used for an extension point for 1944 VoIP/VoLTE Call ID as an advanced NSF."; 1945 reference 1946 "RFC 3261: SIP: Session Initiation Protocol"; 1947 } 1949 identity user-agent { 1950 base voip-volte-capability; 1951 description 1952 "Identity for advanced NSF VoIP/VoLTE User Agent capability. 1953 This can be used for an extension point for VoIP/VoLTE 1954 User Agent as an advanced NSF."; 1955 reference 1956 "RFC 3261: SIP: Session Initiation Protocol"; 1957 } 1959 identity ipsec-capability { 1960 description 1961 "Base identity for an IPsec capability"; 1962 reference 1963 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: 1964 Software-Defined Networking (SDN)-based IPsec Flow 1965 Protection - IPsec methods such as IKE and IKE-less"; 1966 } 1968 identity ike { 1969 base ipsec-capability; 1970 description 1971 "Identity for an IPsec Internet Key Exchange (IKE) 1972 capability"; 1973 reference 1974 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: 1975 Software-Defined Networking (SDN)-based IPsec Flow 1976 Protection - IPsec method with IKE. 1977 RFC 7296: Internet Key Exchange Protocol Version 2 1978 (IKEv2) - IKE as a component of IPsec used for 1979 performing mutual authentication and establishing and 1980 maintaining Security Associations (SAs)."; 1982 } 1984 identity ikeless { 1985 base ipsec-capability; 1986 description 1987 "Identity for an IPsec without Internet Key Exchange (IKE) 1988 capability"; 1989 reference 1990 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: 1991 Software-Defined Networking (SDN)-based IPsec Flow 1992 Protection - IPsec method without IKE"; 1993 } 1995 /* 1996 * Grouping 1997 */ 1999 grouping nsf-capabilities { 2000 description 2001 "Network Security Function (NSF) Capabilities"; 2002 reference 2003 "RFC 8329: Framework for Interface to Network Security 2004 Functions - I2NSF Flow Security Policy Structure."; 2006 leaf-list time-capabilities { 2007 type enumeration { 2008 enum absolute-time { 2009 description 2010 "absolute time capabilities. 2011 If a network security function has the absolute time 2012 capability, the network security function supports 2013 rule execution according to absolute time."; 2014 } 2015 enum periodic-time { 2016 description 2017 "periodic time capabilities. 2018 If a network security function has the periodic time 2019 capability, the network security function supports 2020 rule execution according to periodic time."; 2021 } 2022 } 2023 description 2024 "Time capabilities"; 2025 } 2027 container event-capabilities { 2028 description 2029 "Capabilities of events. 2031 If a network security function has the event capabilities, 2032 the network security function supports rule execution 2033 according to system event and system alarm."; 2035 reference 2036 "RFC 8329: Framework for Interface to Network Security 2037 Functions - I2NSF Flow Security Policy Structure. 2038 draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF 2039 NSF Monitoring YANG Data Model - System Alarm and 2040 System Events."; 2042 leaf-list system-event-capability { 2043 type identityref { 2044 base system-event-capability; 2045 } 2046 description 2047 "System event capabilities"; 2048 } 2050 leaf-list system-alarm-capability { 2051 type identityref { 2052 base system-alarm-capability; 2053 } 2054 description 2055 "System alarm capabilities"; 2056 } 2057 } 2059 container condition-capabilities { 2060 description 2061 "Conditions capabilities."; 2063 container generic-nsf-capabilities { 2064 description 2065 "Conditions capabilities. 2066 If a network security function has the condition 2067 capabilities, the network security function 2068 supports rule execution according to conditions of 2069 IPv4, IPv6, TCP, UDP, SCTP, DCCP, ICMP, ICMPv6, or 2070 payload."; 2071 reference 2072 "RFC 791: Internet Protocol - IPv4. 2073 RFC 792: Internet Control Message Protocol - ICMP. 2074 RFC 793: Transmission Control Protocol - TCP. 2075 RFC 768: User Datagram Protocol - UDP. 2076 RFC 4960: Stream Control Transmission Protocol - SCTP. 2077 RFC 8200: Internet Protocol, Version 6 (IPv6) 2078 Specification - IPv6. 2080 RFC 4443: Internet Control Message Protocol (ICMPv6) 2081 for the Internet Protocol Version 6 (IPv6) Specification 2082 - ICMPv6. 2083 RFC 8329: Framework for Interface to Network Security 2084 Functions - I2NSF Flow Security Policy Structure."; 2086 leaf-list ipv4-capability { 2087 type identityref { 2088 base ipv4-capability; 2089 } 2090 description 2091 "IPv4 packet capabilities"; 2092 reference 2093 "RFC 791: Internet Protocol"; 2094 } 2096 leaf-list icmp-capability { 2097 type identityref { 2098 base icmp-capability; 2099 } 2100 description 2101 "ICMP packet capabilities"; 2102 reference 2103 "RFC 792: Internet Control Message Protocol - ICMP"; 2104 } 2106 leaf-list ipv6-capability { 2107 type identityref { 2108 base ipv6-capability; 2109 } 2110 description 2111 "IPv6 packet capabilities"; 2112 reference 2113 "RFC 8200: Internet Protocol, Version 6 (IPv6) 2114 Specification - IPv6"; 2115 } 2117 leaf-list icmpv6-capability { 2118 type identityref { 2119 base icmpv6-capability; 2120 } 2121 description 2122 "ICMPv6 packet capabilities"; 2123 reference 2124 "RFC 4443: Internet Control Message Protocol (ICMPv6) 2125 for the Internet Protocol Version 6 (IPv6) Specification 2126 - ICMPv6"; 2127 } 2128 leaf-list tcp-capability { 2129 type identityref { 2130 base tcp-capability; 2131 } 2132 description 2133 "TCP packet capabilities"; 2134 reference 2135 "RFC 793: Transmission Control Protocol - TCP 2136 draft-ietf-tcpm-rfc793bis-19: Transmission Control Protocol 2137 (TCP) Specification"; 2138 } 2140 leaf-list udp-capability { 2141 type identityref { 2142 base udp-capability; 2143 } 2144 description 2145 "UDP packet capabilities"; 2146 reference 2147 "RFC 768: User Datagram Protocol - UDP"; 2148 } 2150 leaf-list sctp-capability { 2151 type identityref { 2152 base sctp-capability; 2153 } 2154 description 2155 "SCTP packet capabilities"; 2156 reference 2157 "RFC 4960: Stream Control Transmission Protocol - SCTP"; 2158 } 2160 leaf-list dccp-capability { 2161 type identityref { 2162 base dccp-capability; 2163 } 2164 description 2165 "DCCP packet capabilities"; 2166 reference 2167 "RFC 4340: Datagram Congestion Control Protocol - DCCP"; 2168 } 2169 } 2171 container advanced-nsf-capabilities { 2172 description 2173 "Advanced Network Security Function (NSF) capabilities, 2174 such as Anti-Virus, Anti-DDoS, IPS, and VoIP/VoLTE. 2175 This container contains the leaf-lists of advanced 2176 NSF capabilities"; 2177 reference 2178 "RFC 8329: Framework for Interface to Network Security 2179 Functions - Advanced NSF capabilities"; 2181 leaf-list anti-virus-capability { 2182 type identityref { 2183 base anti-virus-capability; 2184 } 2185 description 2186 "Anti-Virus capabilities"; 2187 reference 2188 "RFC 8329: Framework for Interface to Network Security 2189 Functions - Advanced NSF Anti-Virus capabilities"; 2190 } 2192 leaf-list anti-ddos-capability { 2193 type identityref { 2194 base anti-ddos-capability; 2195 } 2196 description 2197 "Anti-DDoS Attack capabilities"; 2198 reference 2199 "RFC 8329: Framework for Interface to Network Security 2200 Functions - Advanced NSF Anti-DDoS Attack capabilities"; 2201 } 2203 leaf-list ips-capability { 2204 type identityref { 2205 base ips-capability; 2206 } 2207 description 2208 "IPS capabilities"; 2209 reference 2210 "RFC 8329: Framework for Interface to Network Security 2211 Functions - Advanced NSF IPS capabilities"; 2212 } 2214 leaf-list url-capability { 2215 type identityref { 2216 base url-capability; 2217 } 2218 description 2219 "URL capabilities"; 2220 reference 2221 "RFC 8329: Framework for Interface to Network Security 2222 Functions - Advanced NSF URL capabilities"; 2223 } 2224 leaf-list voip-volte-capability { 2225 type identityref { 2226 base voip-volte-capability; 2227 } 2228 description 2229 "VoIP/VoLTE capabilities"; 2230 reference 2231 "RFC 8329: Framework for Interface to Network Security 2232 Functions - Advanced NSF VoIP/VoLTE capabilities"; 2233 } 2234 } 2236 leaf-list context-capabilities { 2237 type identityref { 2238 base context-capability; 2239 } 2240 description 2241 "Security context capabilities"; 2242 } 2243 } 2245 container action-capabilities { 2246 description 2247 "Action capabilities. 2248 If a network security function has the action capabilities, 2249 the network security function supports the attendant 2250 actions for policy rules."; 2252 leaf-list ingress-action-capability { 2253 type identityref { 2254 base ingress-action-capability; 2255 } 2256 description 2257 "Ingress-action capabilities"; 2258 } 2260 leaf-list egress-action-capability { 2261 type identityref { 2262 base egress-action-capability; 2263 } 2264 description 2265 "Egress-action capabilities"; 2266 } 2268 leaf-list log-action-capability { 2269 type identityref { 2270 base log-action-capability; 2271 } 2272 description 2273 "Log-action capabilities"; 2274 } 2275 } 2277 leaf-list resolution-strategy-capabilities { 2278 type identityref { 2279 base resolution-strategy-capability; 2280 } 2281 description 2282 "Resolution strategy capabilities. 2283 The resolution strategies can be used to specify how 2284 to resolve conflicts that occur between the actions 2285 of the same or different policy rules that are matched 2286 for the same packet and by particular NSF."; 2287 } 2289 leaf-list default-action-capabilities { 2290 type identityref { 2291 base default-action-capability; 2292 } 2293 description 2294 "Default action capabilities. 2295 A default action is used to execute I2NSF policy rules 2296 when no rule matches a packet. The default action is 2297 defined as pass, drop, alert, or mirror. Note that 2298 alert makes a packet dropped and logged."; 2299 reference 2300 "RFC 8329: Framework for Interface to Network Security 2301 Functions - Ingress and egress actions."; 2302 } 2304 leaf-list ipsec-method { 2305 type identityref { 2306 base ipsec-capability; 2307 } 2308 description 2309 "IPsec method capabilities"; 2310 reference 2311 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: 2312 Software-Defined Networking (SDN)-based IPsec Flow 2313 Protection - IPsec methods such as IKE and IKE-less"; 2314 } 2315 } 2317 /* 2318 * Data nodes 2319 */ 2321 list nsf { 2322 key "nsf-name"; 2323 description 2324 "The list of Network Security Functions (NSFs)"; 2325 leaf nsf-name { 2326 type string; 2327 mandatory true; 2328 description 2329 "The name of Network Security Function (NSF)"; 2330 } 2331 uses nsf-capabilities; 2332 } 2333 } 2335 2337 Figure 3: YANG Data Module of I2NSF Capability 2339 7. IANA Considerations 2341 This document requests IANA to register the following URI in the 2342 "IETF XML Registry" [RFC3688]: 2344 ID: yang:ietf-i2nsf-capability 2345 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2346 Registrant Contact: The IESG. 2347 XML: N/A; the requested URI is an XML namespace. 2348 Filename: [ TBD-at-Registration ] 2349 Reference: [ RFC-to-be ] 2351 This document requests IANA to register the following YANG module in 2352 the "YANG Module Names" registry [RFC7950][RFC8525]: 2354 Name: ietf-i2nsf-capability 2355 Maintained by IANA? N 2356 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability 2357 Prefix: nsfcap 2358 Module: 2359 Reference: [ RFC-to-be ] 2361 8. Privacy Considerations 2363 This YANG module specified in this document make a trade-off between 2364 privacy and security. Some part of the YANG data model specified in 2365 this document might use highly sensitive private data of the client. 2367 The data used in this YANG data model can be used for the NSFs to 2368 improve the security of the network. 2370 In regards to the privacy data used, the security for accessibility 2371 of the data should be tightly secured and monitored. The Security 2372 Considerations are discussed in Section 9. 2374 9. Security Considerations 2376 The YANG module specified in this document defines a data schema 2377 designed to be accessed through network management protocols such as 2378 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest layer of NETCONF 2379 protocol layers can use Secure Shell (SSH) [RFC4254][RFC6242] as a 2380 secure transport layer. The lowest layer of RESTCONF protocol layers 2381 can use HTTP over Transport Layer Security (TLS), that is, HTTPS 2382 [RFC7230][RFC8446] as a secure transport layer. 2384 The Network Configuration Access Control Model (NACM) [RFC8341] 2385 provides a means of restricting access to specific NETCONF or 2386 RESTCONF users to a preconfigured subset of all available NETCONF or 2387 RESTCONF protocol operations and contents. Thus, NACM can be used to 2388 restrict the NSF registration from unauthorized users. 2390 There are a number of data nodes defined in this YANG module that are 2391 writable, creatable, and deletable (i.e., config true, which is the 2392 default). These data nodes may be considered sensitive or vulnerable 2393 in some network environments. Write operations to these data nodes 2394 could have a negative effect on network and security operations. 2395 These data nodes are collected into a single list node. This list 2396 node is defined by list nsf with the following sensitivity/ 2397 vulnerability: 2399 o list nsf: An attacker could alter the security capabilities 2400 associated with an NSF by disabling or enabling the functionality 2401 of the security capabilities of the NSF. 2403 Some of the features that this document defines capability indicators 2404 for are highly sensitive and/or privileged operations (e.g., 2405 listening to VoIP/VoLTE audio to identify individuals and web 2406 filtering) that inherently require access to individuals' private 2407 data. It is noted that private information is made accessible in 2408 this manner. Thus, the nodes/entities given access to this data need 2409 to be tightly secured and monitored, to prevent leakage or other 2410 unauthorized disclosure of private data. Refer to [RFC6973] for the 2411 description of privacy aspects that protocol designers (including 2412 YANG data model designers) should consider along with regular 2413 security and privacy analysis. 2415 10. References 2417 10.1. Normative References 2419 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 2420 Jeong, J., Lingga, P., Hares, S., Xia, L., and H. 2421 Birkholz, "I2NSF NSF Monitoring YANG Data Model", draft- 2422 ietf-i2nsf-nsf-monitoring-data-model-04 (work in 2423 progress), September 2020. 2425 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] 2426 Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 2427 Garcia, "Software-Defined Networking (SDN)-based IPsec 2428 Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow- 2429 protection-12 (work in progress), October 2020. 2431 [I-D.ietf-tcpm-accurate-ecn] 2432 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 2433 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 2434 ecn-13 (work in progress), November 2020. 2436 [I-D.ietf-tcpm-rfc793bis] 2437 Eddy, W., "Transmission Control Protocol (TCP) 2438 Specification", draft-ietf-tcpm-rfc793bis-19 (work in 2439 progress), October 2020. 2441 [I-D.ietf-tsvwg-udp-options] 2442 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 2443 udp-options-09 (work in progress), November 2020. 2445 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2446 DOI 10.17487/RFC0768, August 1980, 2447 . 2449 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2450 DOI 10.17487/RFC0791, September 1981, 2451 . 2453 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2454 RFC 792, DOI 10.17487/RFC0792, September 1981, 2455 . 2457 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2458 RFC 793, DOI 10.17487/RFC0793, September 1981, 2459 . 2461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2462 Requirement Levels", BCP 14, RFC 2119, 2463 DOI 10.17487/RFC2119, March 1997, 2464 . 2466 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2467 "Definition of the Differentiated Services Field (DS 2468 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2469 DOI 10.17487/RFC2474, December 1998, 2470 . 2472 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2473 of Explicit Congestion Notification (ECN) to IP", 2474 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2475 . 2477 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2478 A., Peterson, J., Sparks, R., Handley, M., and E. 2479 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2480 DOI 10.17487/RFC3261, June 2002, 2481 . 2483 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2484 DOI 10.17487/RFC3688, January 2004, 2485 . 2487 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2488 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 2489 January 2006, . 2491 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2492 Congestion Control Protocol (DCCP)", RFC 4340, 2493 DOI 10.17487/RFC4340, March 2006, 2494 . 2496 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2497 Control Message Protocol (ICMPv6) for the Internet 2498 Protocol Version 6 (IPv6) Specification", STD 89, 2499 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2500 . 2502 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2503 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2504 . 2506 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 2507 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 2508 September 2009, . 2510 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2511 the Network Configuration Protocol (NETCONF)", RFC 6020, 2512 DOI 10.17487/RFC6020, October 2010, 2513 . 2515 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2516 and A. Bierman, Ed., "Network Configuration Protocol 2517 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2518 . 2520 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2521 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2522 . 2524 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2525 Cheshire, "Internet Assigned Numbers Authority (IANA) 2526 Procedures for the Management of the Service Name and 2527 Transport Protocol Port Number Registry", BCP 165, 2528 RFC 6335, DOI 10.17487/RFC6335, August 2011, 2529 . 2531 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2532 "IPv6 Flow Label Specification", RFC 6437, 2533 DOI 10.17487/RFC6437, November 2011, 2534 . 2536 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2537 RFC 6691, DOI 10.17487/RFC6691, July 2012, 2538 . 2540 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2541 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2542 . 2544 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2545 Morris, J., Hansen, M., and R. Smith, "Privacy 2546 Considerations for Internet Protocols", RFC 6973, 2547 DOI 10.17487/RFC6973, July 2013, 2548 . 2550 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2551 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2552 . 2554 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2555 Protocol (HTTP/1.1): Message Syntax and Routing", 2556 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2557 . 2559 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2560 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2561 DOI 10.17487/RFC7231, June 2014, 2562 . 2564 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2565 Kivinen, "Internet Key Exchange Protocol Version 2 2566 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2567 2014, . 2569 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 2570 Scheffenegger, Ed., "TCP Extensions for High Performance", 2571 RFC 7323, DOI 10.17487/RFC7323, September 2014, 2572 . 2574 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2575 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2576 . 2578 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2579 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2580 . 2582 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2583 and J. Jeong, "Interface to Network Security Functions 2584 (I2NSF): Problem Statement and Use Cases", RFC 8192, 2585 DOI 10.17487/RFC8192, July 2017, 2586 . 2588 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2589 (IPv6) Specification", STD 86, RFC 8200, 2590 DOI 10.17487/RFC8200, July 2017, 2591 . 2593 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2594 Kumar, "Framework for Interface to Network Security 2595 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2596 . 2598 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2599 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2600 . 2602 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2603 Access Control Model", STD 91, RFC 8341, 2604 DOI 10.17487/RFC8341, March 2018, 2605 . 2607 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2608 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2609 DOI 10.17487/RFC8407, October 2018, 2610 . 2612 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2613 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2614 . 2616 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 2617 "YANG Data Model for Network Access Control Lists (ACLs)", 2618 RFC 8519, DOI 10.17487/RFC8519, March 2019, 2619 . 2621 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 2622 and R. Wilton, "YANG Library", RFC 8525, 2623 DOI 10.17487/RFC8525, March 2019, 2624 . 2626 10.2. Informative References 2628 [Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and 2629 management of firewall policies", 2004. 2631 [Galitsky] 2632 Galitsky, B. and R. Pampapathi, "Can many agents answer 2633 questions better than one", First 2634 Monday http://dx.doi.org/10.5210/fm.v10i1.1204, 2005. 2636 [Hirschman] 2637 Hirschman, L. and R. Gaizauskas, "Natural Language 2638 Question Answering: The View from Here", Natural Language 2639 Engineering 7:4, pgs 275-300, Cambridge University Press , 2640 Nov 2001. 2642 [Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns", 2643 ISBN 0-32-120068-3 , 2003. 2645 [IANA-Protocol-Numbers] 2646 "Assigned Internet Protocol Numbers", Available: 2647 https://www.iana.org/assignments/protocol- 2648 numbers/protocol-numbers.xhtml, September 2020. 2650 [Martin] Martin, R., "Agile Software Development, Principles, 2651 Patterns, and Practices", Prentice-Hall , ISBN: 2652 0-13-597444-5 , 2002. 2654 [OODMP] "http://www.oodesign.com/mediator-pattern.html". 2656 [OODOP] "http://www.oodesign.com/mediator-pattern.html". 2658 [OODSRP] "http://www.oodesign.com/mediator-pattern.html". 2660 [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 2661 Kumari, "A Format for Self-Published IP Geolocation 2662 Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, 2663 . 2665 Appendix A. Configuration Examples 2667 This section shows configuration examples of "ietf-i2nsf-capability" 2668 module for capabilities registration of general firewall. 2670 A.1. Example 1: Registration for the Capabilities of a General Firewall 2672 This section shows a configuration example for the capabilities 2673 registration of a general firewall in either an IPv4 network or an 2674 IPv6 network. 2676 2677 general_firewall 2678 2679 2680 ipv4-protocol 2681 prefix-ipv4-address 2682 range-ipv4-address 2683 exact-tcp-port-num 2684 range-tcp-port-num 2685 exact-udp-port-num 2686 range-udp-port-num 2687 2688 2689 2690 pass 2691 drop 2692 alert 2693 pass 2694 drop 2695 alert 2696 2697 2699 Figure 4: Configuration XML for the Capabilities Registration of a 2700 General Firewall in an IPv4 Network 2702 Figure 4 shows the configuration XML for the capabilities 2703 registration of a general firewall as an NSF in an IPv4 network. Its 2704 capabilities are as follows. 2706 1. The name of the NSF is general_firewall. 2708 2. The NSF can inspect a protocol, a prefix of IPv4 addresses, and a 2709 range of IPv4 addresses for IPv4 packets. 2711 3. The NSF can inspect an exact port number and a range of port 2712 numbers for the transport layer (TCP and UDP). 2714 4. The NSF can control whether the packets are allowed to pass, 2715 drop, or alert. 2717 2718 general_firewall 2719 2720 2721 ipv6-next-header 2722 prefix-ipv6-address 2723 range-ipv6-address 2724 exact-tcp-port-num 2725 range-tcp-port-num 2726 exact-udp-port-num 2727 range-udp-port-num 2728 2729 2730 2731 pass 2732 drop 2733 alert 2734 pass 2735 drop 2736 alert 2737 2738 2740 Figure 5: Configuration XML for the Capabilities Registration of a 2741 General Firewall in an IPv6 Network 2743 In addition, Figure 5 shows the configuration XML for the 2744 capabilities registration of a general firewall as an NSF in an IPv6 2745 network. Its capabilities are as follows. 2747 1. The name of the NSF is general_firewall. 2749 2. The NSF can inspect a protocol (Next-Header), a prefix of IPv6 2750 addresses, and a range of IPv6 addresses for IPv6 packets. 2752 3. The NSF can inspect an exact port number and a range of port 2753 numbers for the transport layer (TCP and UDP). 2755 4. The NSF can control whether the packets are allowed to pass, 2756 drop, or alert. 2758 A.2. Example 2: Registration for the Capabilities of a Time-based 2759 Firewall 2761 This section shows a configuration example for the capabilities 2762 registration of a time-based firewall in either an IPv4 network or an 2763 IPv6 network. 2765 2766 time_based_firewall 2767 absolute-time 2768 periodic-time 2769 2770 2771 ipv4-protocol 2772 prefix-ipv4-address 2773 range-ipv4-address 2774 2775 2776 2777 pass 2778 drop 2779 alert 2780 pass 2781 drop 2782 alert 2783 2784 2786 Figure 6: Configuration XML for the Capabilities Registration of a 2787 Time-based Firewall in an IPv4 Network 2789 Figure 6 shows the configuration XML for the capabilities 2790 registration of a time-based firewall as an NSF in an IPv4 network. 2791 Its capabilities are as follows. 2793 1. The name of the NSF is time_based_firewall. 2795 2. The NSF can execute the security policy rule according to 2796 absolute time and periodic time. 2798 3. The NSF can inspect a protocol (Next-Header), an exact IPv4 2799 address, and a range of IPv4 addresses for IPv4 packets. 2801 4. The NSF can control whether the packets are allowed to pass, 2802 drop, or alert. 2804 2805 time_based_firewall 2806 absolute-time 2807 periodic-time 2808 2809 2810 ipv6-next-header 2811 prefix-ipv6-address 2812 range-ipv6-address 2813 2814 2815 2816 pass 2817 drop 2818 alert 2819 pass 2820 drop 2821 alert 2822 2823 2825 Figure 7: Configuration XML for the Capabilities Registration of a 2826 Time-based Firewall in an IPv6 Network 2828 In addition, Figure 7 shows the configuration XML for the 2829 capabilities registration of a time-based firewall as an NSF in an 2830 IPv6 network. Its capabilities are as follows. 2832 1. The name of the NSF is time_based_firewall. 2834 2. The NSF can execute the security policy rule according to 2835 absolute time and periodic time. 2837 3. The NSF can inspect a protocol (Next-Header), an exact IPv6 2838 address, and a range of IPv6 addresses for IPv6 packets. 2840 4. The NSF can control whether the packets are allowed to pass, 2841 drop, or alert. 2843 A.3. Example 3: Registration for the Capabilities of a Web Filter 2845 This section shows a configuration example for the capabilities 2846 registration of a web filter. 2848 2849 web_filter 2850 2851 2852 user-defined 2853 2854 2855 2856 pass 2857 drop 2858 alert 2859 pass 2860 drop 2861 alert 2862 2863 2865 Figure 8: Configuration XML for the Capabilities Registration of a 2866 Web Filter 2868 Figure 8 shows the configuration XML for the capabilities 2869 registration of a web filter as an NSF. Its capabilities are as 2870 follows. 2872 1. The name of the NSF is web_filter. 2874 2. The NSF can inspect a URL matched from a user-defined URL 2875 Database. User can add the new URL to the database. 2877 3. The NSF can control whether the packets are allowed to pass, 2878 drop, or alert. 2880 A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE 2881 Filter 2883 This section shows a configuration example for the capabilities 2884 registration of a VoIP/VoLTE filter. 2886 2887 voip_volte_filter 2888 2889 2890 voip-volte-call-id 2891 2892 2893 2894 pass 2895 drop 2896 alert 2897 pass 2898 drop 2899 alert 2900 2901 2903 Figure 9: Configuration XML for the Capabilities Registration of a 2904 VoIP/VoLTE Filter 2906 Figure 9 shows the configuration XML for the capabilities 2907 registration of a VoIP/VoLTE filter as an NSF. Its capabilities are 2908 as follows. 2910 1. The name of the NSF is voip_volte_filter. 2912 2. The NSF can inspect a voice call id for VoIP/VoLTE packets. 2914 3. The NSF can control whether the packets are allowed to pass, 2915 drop, or alert. 2917 A.5. Example 5: Registration for the Capabilities of a HTTP and HTTPS 2918 Flood Mitigator 2920 This section shows a configuration example for the capabilities 2921 registration of a HTTP and HTTPS flood mitigator. 2923 2924 http_and_https_flood_mitigation 2925 2926 2927 http-flood-action 2928 https-flood-action 2929 2930 2931 2932 pass 2933 drop 2934 alert 2935 pass 2936 drop 2937 alert 2938 2939 2941 Figure 10: Configuration XML for the Capabilities Registration of a 2942 HTTP and HTTPS Flood Mitigator 2944 Figure 10 shows the configuration XML for the capabilities 2945 registration of a HTTP and HTTPS flood mitigator as an NSF. Its 2946 capabilities are as follows. 2948 1. The name of the NSF is http_and_https_flood_mitigation. 2950 2. The NSF can control the amount of packets for HTTP and HTTPS 2951 packets, which are routed to the NSF's IPv4 address or the NSF's 2952 IPv6 address. 2954 3. The NSF can control whether the packets are allowed to pass, 2955 drop, or alert. 2957 Appendix B. Acknowledgments 2959 This work was supported by Institute of Information & Communications 2960 Technology Planning & Evaluation (IITP) grant funded by the Korea 2961 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 2962 Security Intelligence Technology Development for the Customized 2963 Security Service Provisioning). This work was supported in part by 2964 the IITP grant funded by the MSIT (2020-0-00395, Standard Development 2965 of Blockchain based Network Management Automation Technology). 2967 Appendix C. Contributors 2969 This document is made by the group effort of I2NSF working group. 2970 Many people actively contributed to this document, such as Acee 2971 Lindem, Roman Danyliw, and Tom Petch. The authors sincerely 2972 appreciate their contributions. 2974 The following are co-authors of this document: 2976 Patrick Lingga 2977 Department of Computer Science and Engineering 2978 Sungkyunkwan University 2979 2066 Seo-ro Jangan-gu 2980 Suwon, Gyeonggi-do 16419 2981 Republic of Korea 2983 EMail: patricklink@skku.edu 2985 Liang Xia 2986 Huawei 2987 101 Software Avenue 2988 Nanjing, Jiangsu 210012 2989 China 2991 EMail: Frank.Xialiang@huawei.com 2993 Cataldo Basile 2994 Politecnico di Torino 2995 Corso Duca degli Abruzzi, 34 2996 Torino, 10129 2997 Italy 2999 EMail: cataldo.basile@polito.it 3001 John Strassner 3002 Huawei 3003 2330 Central Expressway 3004 Santa Clara, CA 95050 3005 USA 3007 EMail: John.sc.Strassner@huawei.com 3009 Diego R. Lopez 3010 Telefonica I+D 3011 Zurbaran, 12 3012 Madrid, 28010 3013 Spain 3015 Email: diego.r.lopez@telefonica.com 3017 Hyoungshick Kim 3018 Department of Computer Science and Engineering 3019 Sungkyunkwan University 3020 2066 Seo-ro Jangan-gu 3021 Suwon, Gyeonggi-do 16419 3022 Republic of Korea 3024 EMail: hyoung@skku.edu 3026 Daeyoung Hyun 3027 Department of Computer Science and Engineering 3028 Sungkyunkwan University 3029 2066 Seo-ro Jangan-gu 3030 Suwon, Gyeonggi-do 16419 3031 Republic of Korea 3033 EMail: dyhyun@skku.edu 3035 Dongjin Hong 3036 Department of Electronic, Electrical and Computer Engineering 3037 Sungkyunkwan University 3038 2066 Seo-ro Jangan-gu 3039 Suwon, Gyeonggi-do 16419 3040 Republic of Korea 3042 EMail: dong.jin@skku.edu 3044 Jung-Soo Park 3045 Electronics and Telecommunications Research Institute 3046 218 Gajeong-Ro, Yuseong-Gu 3047 Daejeon, 34129 3048 Republic of Korea 3050 EMail: pjs@etri.re.kr 3052 Tae-Jin Ahn 3053 Korea Telecom 3054 70 Yuseong-Ro, Yuseong-Gu 3055 Daejeon, 305-811 3056 Republic of Korea 3058 EMail: taejin.ahn@kt.com 3060 Se-Hui Lee 3061 Korea Telecom 3062 70 Yuseong-Ro, Yuseong-Gu 3063 Daejeon, 305-811 3064 Republic of Korea 3066 EMail: sehuilee@kt.com 3068 Authors' Addresses 3070 Susan Hares (editor) 3071 Huawei 3072 7453 Hickory Hill 3073 Saline, MI 48176 3074 USA 3076 Phone: +1-734-604-0332 3077 EMail: shares@ndzh.com 3079 Jaehoon Paul Jeong (editor) 3080 Department of Computer Science and Engineering 3081 Sungkyunkwan University 3082 2066 Seobu-Ro, Jangan-Gu 3083 Suwon, Gyeonggi-Do 16419 3084 Republic of Korea 3086 Phone: +82 31 299 4957 3087 Fax: +82 31 290 7996 3088 EMail: pauljeong@skku.edu 3089 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3090 Jinyong Tim Kim 3091 Department of Electronic, Electrical and Computer Engineering 3092 Sungkyunkwan University 3093 2066 Seobu-Ro, Jangan-Gu 3094 Suwon, Gyeonggi-Do 16419 3095 Republic of Korea 3097 Phone: +82 10 8273 0930 3098 EMail: timkim@skku.edu 3100 Robert Moskowitz 3101 HTT Consulting 3102 Oak Park, MI 3103 USA 3105 Phone: +1-248-968-9809 3106 EMail: rgm@htt-consult.com 3108 Qiushi Lin 3109 Huawei 3110 Huawei Industrial Base 3111 Shenzhen, Guangdong 518129 3112 China 3114 EMail: linqiushi@huawei.com