idnits 2.17.1 draft-ietf-i2nsf-capability-data-model-02.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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 367 has weird spacing: '...address ine...' == Line 369 has weird spacing: '...address ine...' == Line 603 has weird spacing: '...ty-grup boo...' == Line 843 has weird spacing: '...address ine...' == Line 845 has weird spacing: '...address ine...' -- The document date (November 4, 2018) is 1992 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 8192 ** Downref: Normative reference to an Informational RFC: RFC 8329 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group S. Hares 3 Internet-Draft Huawei 4 Intended status: Standards Track J. Jeong 5 Expires: May 8, 2019 J. Kim 6 Sungkyunkwan University 7 R. Moskowitz 8 HTT Consulting 9 Q. Lin 10 Huawei 11 November 4, 2018 13 I2NSF Capability YANG Data Model 14 draft-ietf-i2nsf-capability-data-model-02 16 Abstract 18 This document defines a YANG data model for capabilities that enable 19 a user to control various Network Security Functions (NSFs) in the 20 framework for Interface to Network Security Functions (I2NSF). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 8, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. The Structure and Objective of NSF Capabilities . . . . . . . 6 62 5.1. Generic Network Security Function Identification . . . . 6 63 5.2. Event Capabilities . . . . . . . . . . . . . . . . . . . 6 64 5.3. Condition Capabilities . . . . . . . . . . . . . . . . . 7 65 5.4. Action Capabilities . . . . . . . . . . . . . . . . . . . 7 66 5.5. Resolution Strategy Capabilities . . . . . . . . . . . . 7 67 5.6. Default Action Capabilities . . . . . . . . . . . . . . . 8 68 5.7. RPC for Acquiring Appropriate Network Security Function . 8 69 6. Data Model Structure . . . . . . . . . . . . . . . . . . . . 8 70 6.1. Network Security Function Identification . . . . . . . . 8 71 6.2. Capabilities of Generic Network Security Function . . . . 9 72 6.2.1. Event Capabilities . . . . . . . . . . . . . . . . . 10 73 6.2.2. Condition Capabilities . . . . . . . . . . . . . . . 12 74 6.2.3. Action Capabilities . . . . . . . . . . . . . . . . . 14 75 6.2.4. Resolution Strategy Capabilities . . . . . . . . . . 16 76 6.2.5. Capabilities of Advanced Network Security Function . 16 77 6.2.6. Content Security Capabilities . . . . . . . . . . . . 17 78 6.2.7. Attack Mitigation Capabilities . . . . . . . . . . . 18 79 6.2.8. RPC for Acquiring Appropriate Network Security 80 Function . . . . . . . . . . . . . . . . . . . . . . 19 81 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20 82 7.1. I2NSF Capability YANG Data Module . . . . . . . . . . . . 20 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 57 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 57 87 10.2. Informative References . . . . . . . . . . . . . . . . . 57 88 Appendix A. Example: Extended VoIP-VoLTE Security Function 89 Capabilities Module . . . . . . . . . . . . . . . . 59 90 Appendix B. Example: Configuration XML of Capability Module . . 60 91 B.1. Example: Configuration XML of Generic Network Security 92 Function Capabilities . . . . . . . . . . . . . . . . . . 60 93 B.2. Example: Configuration XML of Extended VoIP/VoLTE 94 Security Function Capabilities Module . . . . . . . . . . 62 95 Appendix C. Changes from draft-ietf-i2nsf-capability-data- 96 model-01 . . . . . . . . . . . . . . . . . . . . . . 63 98 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 64 99 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 64 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 102 1. Introduction 104 As the industry becomes more sophisticated and network devices (e.g., 105 Internet of Things, Self-driving vehicles, and VoIP/VoLTE 106 smartphones), service providers have a lot of problems mentioned in 107 [RFC8192]. To resolve these problems, [i2nsf-nsf-cap-im] specifies 108 the information model of the capabilities of Network Security 109 Functions (NSFs). 111 This document provides a data model using YANG [RFC6020][RFC7950] 112 that defines the capabilities of NSFs to express capabilities of 113 those security devices. This YANG data model is based on the 114 information model for I2NSF NSF capabilities [i2nsf-nsf-cap-im]. The 115 security devices can register their own capabilities into Network 116 Operator Management (Mgmt) System (i.e., Security Controller) with 117 this YANG data model through the registration interface [RFC8329]. 118 After the capabilities of the NSFs are registered, this YANG data 119 model can be used by the IN2SF user or Service Function Forwarder 120 (SFF) [i2nsf-sfc] to acquire appropriate NSFs that can be controlled 121 by the Network Operator Mgmt System. 123 The "Event-Condition-Action" (ECA) policy model is used as the basis 124 for the design of I2NSF Policy Rules. The "ietf-i2nsf-capability" 125 YANG module defined in this document provides the following features: 127 o Configuration of identification for generic network security 128 function policy 130 o Configuration of event capabilities for generic network security 131 function policy 133 o Configuration of condition capabilities for generic network 134 security function policy 136 o Configuration of action capabilities for generic network security 137 function policy 139 o Configuration of strategy capabilities for generic network 140 security function policy 142 o Configuration of default action capabilities for generic network 143 security function policy 145 o RPC for acquiring appropriate network security function according 146 to type of NSF and/or target devices. 148 2. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 3. Terminology 156 This document uses the terminology described in 157 [i2nsf-terminology][i2nsf-nsf-cap-im] 158 [RFC8431][supa-policy-info-model]. Especially, the following terms 159 are from [supa-policy-info-model]: 161 o Data Model: A data model is a representation of concepts of 162 interest to an environment in a form that is dependent on data 163 repository, data definition language, query language, 164 implementation language, and protocol. 166 o Information Model: An information model is a representation of 167 concepts of interest to an environment in a form that is 168 independent of data repository, data definition language, query 169 language, implementation language, and protocol. 171 3.1. Tree Diagrams 173 A simplified graphical representation of the data model is used in 174 this document. The meaning of the symbols in these diagrams 175 [RFC8431] is as follows: 177 o Brackets "[" and "]" enclose list keys. 179 o Abbreviations before data node names: "rw" means configuration 180 (read-write) and "ro" state data (read-only). 182 o Symbols after data node names: "?" means an optional node and "*" 183 denotes a "list" and "leaf-list". 185 o Parentheses enclose choice and case nodes, and case nodes are also 186 marked with a colon (":"). 188 o Ellipsis ("...") stands for contents of subtrees that are not 189 shown. 191 4. Overview 193 This section explains overview how the YANG data model can be used by 194 I2NSF User, Developer's Mgmt System, and SFF. Figure 1 shows 195 capabilities of NSFs in I2NSF Framework. As shown in this figure, 196 Developer's Mgmt System can register NSFs with capabilities that the 197 device can support. To register NSFs in this way, the Developer's 198 Mgmt System utilizes this standardized capabilities YANG data model 199 through registration interface. Through this registration of 200 capabilities, the a lot of problems [RFC8192] can be resolved. The 201 following shows use cases. 203 Note [i2nsf-nsf-yang] is used to configure rules of NSFs in I2NSF 204 Framework. 206 +-------------------------------------------------------+ 207 | I2NSF User (e.g., Overlay Network Mgmt, Enterprise | 208 | Network Mgmt, another network domain's mgmt, etc.) | 209 +--------------------+----------------------------------+ 210 | 211 Consumer-Facing Interface | 212 | 213 | I2NSF 214 +-----------------+------------+ Registration +-------------+ 215 | Network Operator Mgmt System | Interface | Developer's | 216 | (i.e., Security Controller) | < --------- > | Mgmt System | 217 +-----------------+------------+ +-------------+ 218 | New NSF 219 | E = {} 220 NSF-Facing Interface | C = {IPv4, IPv6} 221 | A = {Allow, Deny} 222 | 223 +---------------+----+------------+-----------------+ 224 | | | | 225 +---+---+ +---+---+ +---+---+ +---+---+ 226 | NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-n | ... 227 +-------+ +-------+ +-------+ +-------+ 228 NSF-1 NSF-m NSF-1 NSF-n 229 E = {} E = {user} E = {dev} E = {time} 230 C = {IPv4} C = {IPv6} C = {IPv4, IPv6} C = {IPv4} 231 A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} 233 Developer Mgmt System A Developer Mgmt System B 235 Figure 1: Capabilities of NSFs in I2NSF Framework 237 o If I2NSF User wants to apply rules about blocking malicious users, 238 it is a tremendous burden to apply all of these rules to NSFs one 239 by one. This problem can be resolved by standardizing the 240 capabilities of NSFs. If I2NSF User wants to block malicious 241 users with IPv6, I2NSF User sends the rules about blocking the 242 users to Network Operator Mgmt System. When the Network Operator 243 Mgmt System receives the rules, it sends that rules to appropriate 244 NSFs (i.e., NSF-m in Developer Mgmt System A and NSF-1 in 245 Developer Mgmt System B) which can support the capabilities (i.e., 246 IPv6). Therefore, I2NSF User need not consider NSFs where to 247 apply the rules. 249 o If NSFs find the malicious packets, it is a tremendous burden for 250 I2NSF User to apply the rule about blocking the malicious packets 251 to NSFs one by one. This problem can be resolved by standardizing 252 the capabilities of NSFs. If NSFs find the malicious packets with 253 IPv4, they can ask the Network Operator Mgmt System to alter 254 specific rules and/or configurations. When the Network Operator 255 Mgmt System receives the rules for malicious packets, it inspects 256 whether the rules are reasonable and sends the rules to 257 appropriate NSFs (i.e., NSF-1 in Developer Mgmt System A and NSF-1 258 and NSF-n in Developer Mgmt System B) which can support the 259 capabilities (i.e., IPv4). Therefore, the new rules can be 260 applied to appropriate NSFs without control of I2NSF USer. 262 o If NSFs of Service Function Chaining (SFC) [i2nsf-sfc] fail, it is 263 a tremendous burden for I2NSF User to reconfigure the policy of 264 SFC immediately. This problem can be resolved by periodically 265 acquiring information of appropriate NSFs of SFC. If SFF needs 266 information of Web Application Firewall for SFC, it can ask the 267 Network Operator Mgmt System to acquire the location information 268 of appropriate Web Application Firewall. When the Network 269 Operator Mgmt System receives requested information from SFF, it 270 sends location information of Web Application Firewall to the SFF. 271 Therefore, the policy about the NSFs of SFC can be periodically 272 updated without control of I2NSF USer. 274 5. The Structure and Objective of NSF Capabilities 276 5.1. Generic Network Security Function Identification 278 This shows a identification for generic network security functions. 279 These objects are defined as location information and target device 280 information. 282 5.2. Event Capabilities 284 This shows a event capabilities for generic network security 285 functions policy. This is used to specify capabilities about any 286 important occurrence in time of a change in the system being managed, 287 and/or in the environment of the system being managed. When used in 288 the context of I2NSF Policy Rules, it is used to determine whether 289 the Condition clause of the I2NSF Policy Rule can be evaluated or 290 not. These object of event capabilities is defined as user security 291 event capabilities, device security event capabilities, system 292 security event capabilities, and time security event capabilities. 293 These object of event capabilities can be extended according to 294 specific vendor event features. 296 5.3. Condition Capabilities 298 This shows a condition capabilities for generic network security 299 functions policy. This is used to specify capabilities about a set 300 of attributes, features, and/or values that are to be compared with a 301 set of known attributes, features, and/or values in order to 302 determine whether or not the set of Actions in that (imperative) 303 I2NSF Policy Rule can be executed or not. These object of condition 304 capabilities is defined as packet security condition capabilities, 305 packet payload security condition capabilities, target security 306 condition capabilities, user security condition capabilities, context 307 condition capabilities, and generic context condition capabilities. 308 These object of condition capabilities can be extended according to 309 specific vendor condition features. 311 5.4. Action Capabilities 313 This shows a action capabilities for generic network security 314 functions policy. This is used to specify capabilities to control 315 and monitor aspects of flow-based NSFs when the event and condition 316 clauses are satisfied. NSFs provide security functions by executing 317 various Actions. These object of action capabilities is defined as 318 ingress action capabilities, egress action capabilities, and apply 319 profile action capabilities. These object of action capabilities can 320 be extended according to specific vendor action features. 322 5.5. Resolution Strategy Capabilities 324 This shows a resolution strategy capabilities for generic network 325 security functions policy. This can be used to specify capabilities 326 how to resolve conflicts that occur between the actions of the same 327 or different policy rules that are matched and contained in this 328 particular NSF. These objects are defined as first-matching-rule 329 capability and last-matching-rule capability. These objects can be 330 extended according to specific vendor resolution strategy features. 332 5.6. Default Action Capabilities 334 This shows a default action policy for generic network security 335 functions. This can be used to specify capabilities about a 336 predefined action when no other alternative action was matched by the 337 currently executing I2NSF Policy Rule. 339 5.7. RPC for Acquiring Appropriate Network Security Function 341 This shows a RPC for acquiring an appropriate network security 342 function according to type of NSF and/or target devices. If the SFF 343 [i2nsf-sfc]does not have the location information of network security 344 functions that it should send in own cache table, this can be used to 345 acquire the information. These objects are defined as input data 346 (i.e., NSF type and target devices) and output data (i.e., location 347 information of NSF). 349 6. Data Model Structure 351 This section shows an overview of a structure tree of capabilities 352 for generic network security functions, as defined in the 353 [i2nsf-nsf-cap-im]. 355 6.1. Network Security Function Identification 357 The data model for network security function identification has the 358 following structure: 360 module: ietf-i2nsf-capability 361 +--rw nsf* [nsf-name] 362 +--rw nsf-name string 363 +--rw nsf-type? nsf-type 364 +--rw nsf-address 365 | +--rw (nsf-address-type)? 366 | +--:(ipv4-address) 367 | | +--rw ipv4-address inet:ipv4-address 368 | +--:(ipv6-address) 369 | +--rw ipv6-address inet:ipv6-address 370 +--rw target-device 371 | +--rw pc? boolean 372 | +--rw mobile-phone? boolean 373 | +--rw voip-volte-phone? boolean 374 | +--rw tablet? boolean 375 | +--rw iot? boolean 376 | +--rw vehicle? boolean 377 +--rw generic-nsf-capabilities 378 | +--rw net-sec-capabilities 379 | uses net-sec-caps 380 +--rw advanced-nsf-capabilities 381 | +--rw advaneced-sec-capabilities 382 | uses advaneced-sec-caps 383 +--rw complete-nsf-capabilities 384 +--rw con-sec-control-capabilities 385 | uses i2nsf-con-sec-control-caps 386 +--rw attack-mitigation-capabilities 387 uses i2nsf-attack-mitigation-control-caps 389 Figure 2: Data Model Structure for NSF-Identification 391 This document also utilizes a formal model for policy reconciliation 392 proposed by Basile et al. [Policy-Reconciliation], which handles 393 conflict resolution, the use of external data, and target device. 395 The nsf-type object can be used for configuration about type of a 396 NSF. The types of NSF consists of Network Firewall, Web Application 397 Firewall, Anti-Virus, IDS, IPS, and DDoS Mitigator. The nsf-address 398 object can be used for configuration about location of a NSF. The 399 target-device object can be used for configuration about target 400 devices. We will add additional type of a NSF for more generic 401 network security functions. 403 6.2. Capabilities of Generic Network Security Function 405 The data model for Generic NSF capabilities has the following 406 structure: 408 +--rw generic-nsf-capabilities 409 +--rw net-sec-capabilities 410 uses i2nsf-net-sec-caps 412 Figure 3: Data Model Structure for Capabilities of Network Security 413 Function 415 6.2.1. Event Capabilities 417 The data model for event capabilities has the following structure: 419 +--rw i2nsf-net-sec-caps 420 +--rw net-sec-capabilities 421 +--rw time 422 | +--rw time-zone 423 | | +--rw time-zone-offset? boolean 424 | +--rw time-inteval 425 | +--rw absolute-time-inteval 426 | | +--rw start-time? boolean 427 | | +--rw end-time? boolean 428 | +--rw periodic-time-inteval 429 | +--rw day? boolean 430 | +--rw month? boolean 431 +--rw event 432 | +--rw usr-event 433 | | +--rw usr-sec-event-content? boolean 434 | | +--rw usr-sec-event-format 435 | | | +--rw unknown? boolean 436 | | | +--rw guid? boolean 437 | | | +--rw uuid? boolean 438 | | | +--rw uri? boolean 439 | | | +--rw fqdn? boolean 440 | | | +--rw fqpn? boolean 441 | | +--rw usr-sec-event-type 442 | | +--rw unknown? boolean 443 | | +--rw user-created? boolean 444 | | +--rw user-grp-created? boolean 445 | | +--rw user-deleted? boolean 446 | | +--rw user-grp-deleted? boolean 447 | | +--rw user-logon? boolean 448 | | +--rw user-logoff? boolean 449 | | +--rw user-access-request? boolean 450 | | +--rw user-access-granted? boolean 451 | | +--rw user-access-violation? boolean 452 | +--rw dev-event 453 | | +--rw dev-sec-event-content boolean 454 | | +--rw dev-sec-event-format 455 | | | +--rw unknown? boolean 456 | | | +--rw guid? boolean 457 | | | +--rw uuid? boolean 458 | | | +--rw uri? boolean 459 | | | +--rw fqdn? boolean 460 | | | +--rw fqpn? boolean 461 | | +--rw dev-sec-event-type 462 | | | +--rw unknown? boolean 463 | | | +--rw comm-alarm? boolean 464 | | | +--rw quality-of-service-alarm? boolean 465 | | | +--rw process-err-alarm? boolean 466 | | | +--rw equipment-err-alarm? boolean 467 | | | +--rw environmental-err-alarm? boolean 468 | | +--rw dev-sec-event-type-severity 469 | | +--rw unknown? boolean 470 | | +--rw cleared? boolean 471 | | +--rw indeterminate? boolean 472 | | +--rw critical? boolean 473 | | +--rw major? boolean 474 | | +--rw minor? boolean 475 | | +--rw warning? boolean 476 | +--rw sys-event 477 | | +--rw sys-sec-event-content? boolean 478 | | +--rw sys-sec-event-format 479 | | | +--rw unknown? boolean 480 | | | +--rw guid? boolean 481 | | | +--rw uuid? boolean 482 | | | +--rw uri? boolean 483 | | | +--rw fqdn? boolean 484 | | | +--rw fqpn? boolean 485 | | +--rw sys-sec-event-type 486 | | +--rw unknown? boolean 487 | | +--rw audit-log-written-to? boolean 488 | | +--rw audit-log-cleared? boolean 489 | | +--rw policy-created? boolean 490 | | +--rw policy-edited? boolean 491 | | +--rw policy-deleted? boolean 492 | | +--rw policy-executed? boolean 493 | +--rw time-event 494 | +--rw time-sec-event-begin? boolean 495 | +--rw time-sec-event-end? boolean 496 | +--rw time-sec-event-time-zone? boolean 497 +--rw condition 498 | ... 499 +--rw action 500 | ... 501 +--rw resolution-strategy 502 ... 504 Figure 4: Data Model Structure for Event Capabilities of Network 505 Security Function 507 These objects are defined as capabilities of user security event, 508 device security event, system security event, and time security 509 event. These objects can be extended according to specific vendor 510 event features. We will add additional event objects for more 511 generic network security functions. 513 6.2.2. Condition Capabilities 515 The data model for condition capabilities has the following 516 structure: 518 +--rw i2nsf-net-sec-caps 519 +--rw net-sec-capabilities 520 +--rw time 521 | +--rw time-zone 522 | | +--rw time-zone-offset? boolean 523 | +--rw time-inteval 524 | +--rw absolute-time-inteval 525 | | +--rw start-time? boolean 526 | | +--rw end-time? boolean 527 | +--rw periodic-time-inteval 528 | +--rw day? boolean 529 | +--rw month? boolean 530 +--rw event 531 | ... 532 +--rw condition 533 | +--rw packet-security-condition 534 | | +--rw packet-security-mac-condition 535 | | | +--rw pkt-sec-cond-mac-dest? boolean 536 | | | +--rw pkt-sec-cond-mac-src? boolean 537 | | | +--rw pkt-sec-cond-mac-8021q? boolean 538 | | | +--rw pkt-sec-cond-mac-ether-type? boolean 539 | | | +--rw pkt-sec-cond-mac-tci? string 540 | | +--rw packet-security-ipv4-condition 541 | | | +--rw pkt-sec-cond-ipv4-header-length? boolean 542 | | | +--rw pkt-sec-cond-ipv4-tos? boolean 543 | | | +--rw pkt-sec-cond-ipv4-total-length? boolean 544 | | | +--rw pkt-sec-cond-ipv4-id? boolean 545 | | | +--rw pkt-sec-cond-ipv4-fragment? boolean 546 | | | +--rw pkt-sec-cond-ipv4-fragment-offset? boolean 547 | | | +--rw pkt-sec-cond-ipv4-ttl? boolean 548 | | | +--rw pkt-sec-cond-ipv4-protocol? boolean 549 | | | +--rw pkt-sec-cond-ipv4-src? boolean 550 | | | +--rw pkt-sec-cond-ipv4-dest? boolean 551 | | | +--rw pkt-sec-cond-ipv4-ipopts? boolean 552 | | | +--rw pkt-sec-cond-ipv4-sameip? boolean 553 | | | +--rw pkt-sec-cond-ipv4-geoip? boolean 554 | | +--rw packet-security-ipv6-condition 555 | | | +--rw pkt-sec-cond-ipv6-dscp? boolean 556 | | | +--rw pkt-sec-cond-ipv6-ecn? boolean 557 | | | +--rw pkt-sec-cond-ipv6-traffic-class? boolean 558 | | | +--rw pkt-sec-cond-ipv6-flow-label? boolean 559 | | | +--rw pkt-sec-cond-ipv6-payload-length? boolean 560 | | | +--rw pkt-sec-cond-ipv6-next-header? boolean 561 | | | +--rw pkt-sec-cond-ipv6-hop-limit? boolean 562 | | | +--rw pkt-sec-cond-ipv6-src? boolean 563 | | | +--rw pkt-sec-cond-ipv6-dest? boolean 564 | | +--rw packet-security-tcp-condition 565 | | | +--rw pkt-sec-cond-tcp-src-port? boolean 566 | | | +--rw pkt-sec-cond-tcp-dest-port? boolean 567 | | | +--rw pkt-sec-cond-tcp-seq-num? boolean 568 | | | +--rw pkt-sec-cond-tcp-ack-num? boolean 569 | | | +--rw pkt-sec-cond-tcp-window-size? boolean 570 | | | +--rw pkt-sec-cond-tcp-flags? boolean 571 | | +--rw packet-security-udp-condition 572 | | | +--rw pkt-sec-cond-udp-src-port? boolean 573 | | | +--rw pkt-sec-cond-udp-dest-port? boolean 574 | | | +--rw pkt-sec-cond-udp-length? boolean 575 | | +--rw packet-security-icmp-condition 576 | | +--rw pkt-sec-cond-icmp-type? boolean 577 | | +--rw pkt-sec-cond-icmp-code? boolean 578 | | +--rw pkt-sec-cond-icmp-seg-num? boolean 579 | +--rw packet-payload-condition 580 | | +--rw pkt-payload-content? boolean 581 | +--rw acl-number? boolean 582 | +--rw application-condition 583 | | +--rw application-object? boolean 584 | | +--rw application-group? boolean 585 | | +--rw application-label? boolean 586 | | +--rw category 587 | | +--rw application-category? boolean 588 | +--rw target-condition 589 | | +--rw device-sec-context-cond? boolean 590 | +--rw users-condition 591 | | +--rw user 592 | | | +--rw (user-name)? 593 | | | +--:(tenant) 594 | | | | +--rw tenant? boolean 595 | | | +--:(vn-id) 596 | | | +--rw vn-id? boolean 597 | | +--rw group 598 | | +--rw (group-name)? 599 | | | +--:(tenant) 600 | | | | +--rw tenant? boolean 601 | | | +--:(vn-id) 602 | | | +--rw vn-id? boolean 603 | | +--rw security-grup boolean 604 | +--rw url-category-condition 605 | | +--rw pre-defined-category? boolean 606 | | +--rw user-defined-category? boolean 607 | +--rw context-condition 608 | | +--rw temp? string 609 | +--rw gen-context-condition 610 | +--rw geographic-location 611 | +--rw src-geographic-location? boolean 612 | +--rw dest-geographic-location? boolean 613 +--rw action 614 | ... 615 +--rw resolution-strategy 616 ... 618 Figure 5: Data Model Structure for Condition Capabilities of Network 619 Security Function 621 These objects are defined as capabilities of packet security 622 condition, packet payload security condition, target security 623 condition, user security condition, context condition, and generic 624 context condition. These objects can be extended according to 625 specific vendor condition features. We will add additional condition 626 objects for more generic network security functions. 628 6.2.3. Action Capabilities 630 The data model for action capabilities has the following structure: 632 +--rw i2nsf-net-sec-caps 633 +--rw net-sec-capabilities 634 +--rw time 635 | +--rw time-zone 636 | | +--rw time-zone-offset? boolean 637 | +--rw time-inteval 638 | +--rw absolute-time-inteval 639 | | +--rw start-time? boolean 640 | | +--rw end-time? boolean 641 | +--rw periodic-time-inteval 642 | +--rw day? boolean 643 | +--rw month? boolean 644 +--rw event 645 | ... 646 +--rw condition 647 | ... 648 +--rw action 649 | +--rw rule-log? boolean 650 | +--rw session-log? boolean 651 | +--rw ingress-action 652 | | +--rw ingress-action-type 653 | | +--rw pass? boolean 654 | | +--rw drop? boolean 655 | | +--rw reject? boolean 656 | | +--rw alert? boolean 657 | | +--rw mirror? boolean 658 | +--rw egress-action 659 | +--rw egress-action-type 660 | +--rw invoke-signaling? boolean 661 | +--rw tunnel-encapsulation? boolean 662 | +--rw forwarding? boolean 663 | +--rw redirection? boolean 664 +--rw resolution-strategy 665 ... 667 Figure 6: Data Model Structure for Action Capabilities of Network 668 Security Function 670 These objects are defined capabilities as ingress action, egress 671 action, and apply profile action. These objects can be extended 672 according to specific vendor action feature. We will add additional 673 action objects for more generic network security functions. 675 6.2.4. Resolution Strategy Capabilities 677 The data model for resolution strategy capabilities has the following 678 structure: 680 +--rw i2nsf-net-sec-caps 681 +--rw net-sec-capabilities 682 +--rw time 683 | +--rw time-zone 684 | | +--rw time-zone-offset? boolean 685 | +--rw time-inteval 686 | +--rw absolute-time-inteval 687 | | +--rw start-time? boolean 688 | | +--rw end-time? boolean 689 | +--rw periodic-time-inteval 690 | +--rw day? boolean 691 | +--rw month? boolean 692 +--rw event 693 | ... 694 +--rw condition 695 | ... 696 +--rw action 697 | ... 698 +--rw resolution-strategy 699 +--rw first-matching-rule? boolean 700 +--rw last-matching-rule? boolean 702 Figure 7: Data Model Structure for Resolution Strategy Capabilities 703 of Network Security Function 705 These objects are defined capabilities as first-matching-rule and 706 last-matching-rule. These objects can be extended according to 707 specific vendor resolution strategy features. We will add additional 708 resolution strategy objects for more generic network security 709 functions. 711 6.2.5. Capabilities of Advanced Network Security Function 713 The data model for advanced NSF capabilities has the following 714 structure: 716 +--rw advanced-nsf-capabilities 717 | +--rw advanced-sec-capabilities 718 | +--rw antivirus 719 | | +--rw detect? boolean 720 | | +--rw exception-application? boolean 721 | | +--rw exception-signature? boolean 722 | | +--rw whitelists? boolean 723 | +--rw antiddos 724 | | +--rw syn-flood-action? boolean 725 | | +--rw udp-flood-action? boolean 726 | | +--rw http-flood-action? boolean 727 | | +--rw https-flood-action? boolean 728 | | +--rw dns-request-flood-action? boolean 729 | | +--rw dns-reply-flood-action? boolean 730 | | +--rw icmp-flood-action? boolean 731 | | +--rw sip-flood-action? boolean 732 | | +--rw detect-mode? boolean 733 | | +--rw baseline-learn? boolean 734 | +--rw ips 735 | +--rw signature-set? boolean 736 | +--rw exception-signature? boolean 737 ... 739 Figure 8: Data Model Structure for Capabilities of Advanced Network 740 Security Function 742 These objects are defined capabilities of advanced network security 743 functions such as antivirus, antiddos, and ips. A detailed data 744 model for the configuration of the advanced network security 745 functions is described in [i2nsf-advanced-nsf-dm]. 747 6.2.6. Content Security Capabilities 749 The data model for content security capabilities has the following 750 structure: 752 +--rw complete-nsf-capabilities 753 +--rw con-sec-control-capabilities 754 | +--rw anti-virus? boolean 755 | +--rw ips? boolean 756 | +--rw ids? boolean 757 | +--rw url-filter? boolean 758 | +--rw data-filter? boolean 759 | +--rw mail-filter? boolean 760 | +--rw sql-filter? boolean 761 | +--rw file-blocking? boolean 762 | +--rw file-isolate? boolean 763 | +--rw pkt-capture? boolean 764 | +--rw application-behavior? boolean 765 | +--rw voip-volte? boolean 766 +--rw attack-mitigation-capabilities 767 ... 769 Figure 9: Data Model Structure for Content Security Capabilities of 770 Network Security Function 772 Content security is composed of a number of distinct security 773 Capabilities; each such Capability protects against a specific type 774 of threat in the application layer. Content security is a type of 775 Generic Network Security Function (GNSF), which summarizes a well- 776 defined set of security Capabilities. 778 6.2.7. Attack Mitigation Capabilities 780 The data model for attack mitigation capabilities has the following 781 structure: 783 +--rw complete-nsf-capabilities 784 ... 785 +--rw attack-mitigation-capabilities 786 +--rw (attack-mitigation-control-type)? 787 +--:(ddos-attack) 788 | +--rw (ddos-attack-type)? 789 | +--:(network-layer-ddos-attack) 790 | | +--rw network-layer-ddos-attack-types 791 | | +--rw syn-flood-attack? boolean 792 | | +--rw udp-flood-attack? boolean 793 | | +--rw icmp-flood-attack? boolean 794 | | +--rw ip-fragment-flood-attack? boolean 795 | | +--rw ipv6-related-attack? boolean 796 | +--:(app-layer-ddos-attack) 797 | +--rw app-layer-ddos-attack-types 798 | +--rw http-flood-attack? boolean 799 | +--rw https-flood-attack? boolean 800 | +--rw dns-flood-attack? boolean 801 | +--rw dns-amp-flood-attack? boolean 802 | +--rw ssl-flood-attack? boolean 803 +--:(single-packet-attack) 804 +--rw (single-packet-attack-type)? 805 +--:(scan-and-sniff-attack) 806 | +--rw ip-sweep-attack? boolean 807 | +--rw port-scanning-attack? boolean 808 +--:(malformed-packet-attack) 809 | +--rw ping-of-death-attack? boolean 810 | +--rw teardrop-attack? boolean 811 +--:(special-packet-attack) 812 +--rw oversized-icmp-attack? boolean 813 +--rw tracert-attack? boolean 815 Figure 10: Data Model Structure for Attack Mitigation Capabilities of 816 Network Security Function 818 Attack mitigation is composed of a number of GNSFs; each one protects 819 against a specific type of network attack. Attack Mitigation 820 security is a type of GNSF, which summarizes a well-defined set of 821 security Capabilities. 823 6.2.8. RPC for Acquiring Appropriate Network Security Function 825 The data model for RPC for Acquiring Appropriate Network Security 826 Function has the following structure: 828 rpcs: 829 +---x call-appropriate-nsf 830 +---w input 831 | +---w nsf-type nsf-type 832 | +---w target-device 833 | +---w pc? boolean 834 | +---w mobile-phone? boolean 835 | +---w voip-volte-phone? boolean 836 | +---w tablet? boolean 837 | +---w iot? boolean 838 | +---w vehicle? boolean 839 +--ro output 840 +--ro nsf-address 841 +--ro (nsf-address-type)? 842 +--:(ipv4-address) 843 | +--ro ipv4-address inet:ipv4-address 844 +--:(ipv6-address) 845 +--ro ipv6-address inet:ipv6-address 847 Figure 11: RPC for Acquiring Appropriate Network Security Function 849 This shows a RPC for acquiring an appropriate network security 850 function according to type of NSF and/or target devices. If the SFF 851 [i2nsf-sfc]does not have the location information of network security 852 functions that it should send in own cache table, this can be used to 853 acquire the information. These objects are defined as input data 854 (i.e., NSF type and target devices) and output data (i.e., location 855 information of NSF). 857 7. YANG Modules 859 7.1. I2NSF Capability YANG Data Module 861 This section introduces a YANG module for the information model of 862 network security functions, as defined in the [i2nsf-nsf-cap-im]. 864 file "ietf-i2nsf-capability@2018-11-04.yang" 866 module ietf-i2nsf-capability { 867 namespace 868 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; 869 prefix 870 i2nsf-capability; 872 import ietf-inet-types{ 873 prefix inet; 874 } 875 organization 876 "IETF I2NSF (Interface to Network Security Functions) 877 Working Group"; 879 contact 880 "WG Web: 881 WG List: 883 WG Chair: Adrian Farrel 884 886 WG Chair: Linda Dunbar 887 889 Editor: Susan Hares 890 892 Editor: Jaehoon Paul Jeong 893 895 Editor: Jinyong Tim Kim 896 "; 898 description 899 "This module describes a capability model 900 for I2NSF devices."; 902 revision "2018-11-04"{ 903 description "The fifth revision"; 904 reference 905 "draft-ietf-i2nsf-capability-04"; 906 } 908 grouping i2nsf-nsf-location { 909 description 910 "This provides a location for capabilities."; 911 container nsf-address { 912 description 913 "This is location information for capabilities."; 914 choice nsf-address-type { 915 description 916 "nsf address type: ipv4 and ipv4"; 917 case ipv4-address { 918 description 919 "ipv4 case"; 920 leaf ipv4-address { 921 type inet:ipv4-address; 922 mandatory true; 923 description 924 "nsf address type is ipv4"; 925 } 926 } 927 case ipv6-address { 928 description 929 "ipv6 case"; 930 leaf ipv6-address { 931 type inet:ipv6-address; 932 mandatory true; 933 description 934 "nsf address type is ipv6"; 935 } 936 } 937 } 938 } 939 } 941 typedef nsf-type { 942 type enumeration { 943 enum network-firewall { 944 description 945 "If type of a NSF is Network Firewall."; 946 } 948 enum web-app-firewall { 949 description 950 "If type of a NSF is Web Application 951 Firewall."; 952 } 954 enum anti-virus { 955 description 956 "If type of a NSF is Anti-Virus"; 957 } 959 enum ids { 960 description 961 "If type of a NSF is IDS."; 962 } 964 enum ips { 965 description 966 "If type of a NSF is IPS."; 967 } 968 enum ddos-mitigator { 969 description 970 "If type of a NSF is DDoS Mitigator."; 971 } 972 } 973 description 974 "This is used for type of NSF."; 975 } 977 grouping i2nsf-it-resources { 978 description 979 "This provides a link between capabilities 980 and IT resources. This has a list of IT resources 981 by name."; 982 container target-device { 983 description 984 "it-resources"; 986 leaf pc { 987 type boolean; 988 description 989 "If type of a device is PC."; 990 } 992 leaf mobile-phone { 993 type boolean; 994 description 995 "If type of a device is mobile-phone."; 996 } 998 leaf voip-volte-phone { 999 type boolean; 1000 description 1001 "If type of a device is voip-volte-phone."; 1002 } 1004 leaf tablet { 1005 type boolean; 1006 description 1007 "If type of a device is tablet."; 1008 } 1010 leaf iot { 1011 type boolean; 1012 description 1013 "If type of a device is Internet of Things."; 1014 } 1015 leaf vehicle { 1016 type boolean; 1017 description 1018 "If type of a device is vehicle."; 1019 } 1021 } 1022 } 1024 grouping capabilities-information { 1025 description 1026 "This includes information of capabilities."; 1028 leaf nsf-type { 1029 type nsf-type; 1030 description 1031 "This is type of NSF."; 1032 } 1033 uses i2nsf-nsf-location; 1034 uses i2nsf-it-resources; 1035 } 1037 grouping i2nsf-net-sec-caps { 1038 description 1039 "i2nsf-net-sec-caps"; 1040 container net-sec-capabilities { 1041 description 1042 "net-sec-capabilities"; 1044 container time { 1045 description 1046 "This is capabilities for time"; 1047 container time-zone { 1048 description 1049 "This can be used to apply rules 1050 according to time zone"; 1052 leaf time-zone-offset { 1053 type boolean; 1054 description 1055 "This is offset for UTC time zone"; 1056 } 1058 } 1060 container time-inteval { 1061 description 1062 "This can be used to apply rules 1063 according to time inteval"; 1064 container absolute-time-inteval { 1065 description 1066 "This can be used to apply rules according to 1067 absolute time inteval"; 1068 leaf start-time { 1069 type boolean; 1070 description 1071 "This is start time for absolute time inteval"; 1072 } 1073 leaf end-time { 1074 type boolean; 1075 description 1076 "This is end time for absolute time inteval"; 1077 } 1078 } 1079 container periodic-time-inteval { 1080 description 1081 "This can be used to apply rules according to 1082 periodic time inteval"; 1083 leaf day { 1084 type boolean; 1085 description 1086 "This is day for periodic time inteval"; 1087 } 1088 leaf month { 1089 type boolean; 1090 description 1091 "This is month for periodic time inteval"; 1092 } 1093 } 1094 } 1095 } 1097 container event { 1098 description 1099 " This is abstract. An event is defined as any important 1100 occurrence in time of a change in the system being 1101 managed, and/or in the environment of the system being 1102 managed. When used in the context of policy rules for 1103 a flow-based NSF, it is used to determine whether the 1104 Condition clause of the Policy Rule can be evaluated 1105 or not. Examples of an I2NSF event include time and 1106 user actions (e.g., logon, logoff, and actions that 1107 violate any ACL.)."; 1109 container usr-event { 1110 description "TBD"; 1111 leaf usr-sec-event-content { 1112 type boolean; 1113 description 1114 "This is a mandatory string that contains the content 1115 of the UserSecurityEvent. The format of the content 1116 is specified in the usrSecEventFormat class 1117 attribute, and the type of event is defined in the 1118 usrSecEventType class attribute. An example of the 1119 usrSecEventContent attribute is a string hrAdmin, 1120 with the usrSecEventFormat set to 1 (GUID) and the 1121 usrSecEventType attribute set to 5 (new logon)."; 1122 } 1124 container usr-sec-event-format { 1125 description 1126 "This is a mandatory uint 8 enumerated integer, which 1127 is used to specify the data type of the 1128 usrSecEventContent attribute. The content is 1129 specified in the usrSecEventContent class attribute, 1130 and the type of event is defined in the 1131 usrSecEventType class attribute. An example of the 1132 usrSecEventContent attribute is string hrAdmin, 1133 with the usrSecEventFormat attribute set to 1 (GUID) 1134 and the usrSecEventType attribute set to 5 1135 (new logon)."; 1136 leaf unknown { 1137 type boolean; 1138 description 1139 "If SecEventFormat is unknown"; 1140 } 1141 leaf guid { 1142 type boolean; 1143 description 1144 "If SecEventFormat is GUID 1145 (Generic Unique IDentifier)"; 1146 } 1147 leaf uuid { 1148 type boolean; 1149 description 1150 "If SecEventFormat is UUID 1151 (Universal Unique IDentifier)"; 1152 } 1153 leaf uri { 1154 type boolean; 1155 description 1156 "If SecEventFormat is URI 1157 (Uniform Resource Identifier)"; 1158 } 1159 leaf fqdn { 1160 type boolean; 1161 description 1162 "If SecEventFormat is FQDN 1163 (Fully Qualified Domain Name)"; 1164 } 1165 leaf fqpn { 1166 type boolean; 1167 description 1168 "If SecEventFormat is FQPN 1169 (Fully Qualified Path Name)"; 1170 } 1171 } 1173 container usr-sec-event-type { 1174 leaf unknown { 1175 type boolean; 1176 description 1177 "If usrSecEventType is unknown"; 1178 } 1179 leaf user-created { 1180 type boolean; 1181 description 1182 "If usrSecEventType is new user 1183 created"; 1184 } 1185 leaf user-grp-created { 1186 type boolean; 1187 description 1188 "If usrSecEventType is new user 1189 group created"; 1190 } 1191 leaf user-deleted { 1192 type boolean; 1193 description 1194 "If usrSecEventType is user 1195 deleted"; 1196 } 1197 leaf user-grp-deleted { 1198 type boolean; 1199 description 1200 "If usrSecEventType is user 1201 group deleted"; 1202 } 1203 leaf user-logon { 1204 type boolean; 1205 description 1206 "If usrSecEventType is user 1207 logon"; 1208 } 1209 leaf user-logoff { 1210 type boolean; 1211 description 1212 "If usrSecEventType is user 1213 logoff"; 1214 } 1215 leaf user-access-request { 1216 type boolean; 1217 description 1218 "If usrSecEventType is user 1219 access request"; 1220 } 1221 leaf user-access-granted { 1222 type boolean; 1223 description 1224 "If usrSecEventType is user 1225 granted"; 1226 } 1227 leaf user-access-violation { 1228 type boolean; 1229 description 1230 "If usrSecEventType is user 1231 violation"; 1232 } 1233 description 1234 "This is a mandatory uint 8 enumerated integer, which 1235 is used to specify the type of event that involves 1236 this user. The content and format are specified in 1237 the usrSecEventContent and usrSecEventFormat class 1238 attributes, respectively. An example of the 1239 usrSecEventContent attribute is string hrAdmin, 1240 with the usrSecEventFormat attribute set to 1 (GUID) 1241 and the usrSecEventType attribute set to 5 1242 (new logon)."; 1243 } 1245 } 1246 container dev-event { 1247 description "TBD"; 1249 leaf dev-sec-event-content { 1250 type boolean; 1251 mandatory true; 1252 description 1253 "This is a mandatory string that contains the content 1254 of the DeviceSecurityEvent. The format of the 1255 content is specified in the devSecEventFormat class 1256 attribute, and the type of event is defined in the 1257 devSecEventType class attribute. An example of the 1258 devSecEventContent attribute is alarm, with the 1259 devSecEventFormat attribute set to 1 (GUID), the 1260 devSecEventType attribute set to 5 (new logon)."; 1261 } 1263 container dev-sec-event-format { 1264 description 1265 "This is a mandatory uint 8 enumerated integer, 1266 which is used to specify the data type of the 1267 devSecEventContent attribute."; 1269 leaf unknown { 1270 type boolean; 1271 description 1272 "If SecEventFormat is unknown"; 1273 } 1274 leaf guid { 1275 type boolean; 1276 description 1277 "If SecEventFormat is GUID 1278 (Generic Unique IDentifier)"; 1279 } 1280 leaf uuid { 1281 type boolean; 1282 description 1283 "If SecEventFormat is UUID 1284 (Universal Unique IDentifier)"; 1285 } 1286 leaf uri { 1287 type boolean; 1288 description 1289 "If SecEventFormat is URI 1290 (Uniform Resource Identifier)"; 1291 } 1292 leaf fqdn { 1293 type boolean; 1294 description 1295 "If SecEventFormat is FQDN 1296 (Fully Qualified Domain Name)"; 1297 } 1298 leaf fqpn { 1299 type boolean; 1300 description 1301 "If SecEventFormat is FQPN 1302 (Fully Qualified Path Name)"; 1303 } 1304 } 1306 container dev-sec-event-type { 1307 description 1308 "This is a mandatory uint 8 enumerated integer, 1309 which is used to specify the type of event 1310 that was generated by this device."; 1312 leaf unknown { 1313 type boolean; 1314 description 1315 "If devSecEventType is unknown"; 1316 } 1317 leaf comm-alarm { 1318 type boolean; 1319 description 1320 "If devSecEventType is communications 1321 alarm"; 1322 } 1323 leaf quality-of-service-alarm { 1324 type boolean; 1325 description 1326 "If devSecEventType is quality of service 1327 alarm"; 1328 } 1329 leaf process-err-alarm { 1330 type boolean; 1331 description 1332 "If devSecEventType is processing error 1333 alarm"; 1334 } 1335 leaf equipment-err-alarm { 1336 type boolean; 1337 description 1338 "If devSecEventType is equipment error 1339 alarm"; 1340 } 1341 leaf environmental-err-alarm { 1342 type boolean; 1343 description 1344 "If devSecEventType is environmental error 1345 alarm"; 1346 } 1348 } 1349 container dev-sec-event-type-severity { 1350 description 1351 "This is a mandatory uint 8 enumerated integer, 1352 which is used to specify the perceived 1353 severity of the event generated by this 1354 Device."; 1356 leaf unknown { 1357 type boolean; 1358 description 1359 "If devSecEventType is unknown"; 1360 } 1361 leaf cleared { 1362 type boolean; 1363 description 1364 "If devSecEventTypeSeverity is cleared"; 1365 } 1366 leaf indeterminate { 1367 type boolean; 1368 description 1369 "If devSecEventTypeSeverity is 1370 indeterminate"; 1371 } 1372 leaf critical { 1373 type boolean; 1374 description 1375 "If devSecEventTypeSeverity is critical"; 1376 } 1377 leaf major{ 1378 type boolean; 1379 description 1380 "If devSecEventTypeSeverity is major"; 1381 } 1382 leaf minor { 1383 type boolean; 1384 description 1385 "If devSecEventTypeSeverity is minor"; 1386 } 1387 leaf warning { 1388 type boolean; 1389 description 1390 "If devSecEventTypeSeverity is warning"; 1391 } 1392 } 1393 } 1394 container sys-event { 1395 description "TBD"; 1396 leaf sys-sec-event-content { 1397 type boolean; 1398 description 1399 "This is a mandatory string that contains a content 1400 of the SystemSecurityEvent. The format of a content 1401 is specified in a sysSecEventFormat class attribute, 1402 and the type of event is defined in the 1403 sysSecEventType class attribute. An example of the 1404 sysSecEventContent attribute is string sysadmin3, 1405 with the sysSecEventFormat attribute set to 1(GUID), 1406 and the sysSecEventType attribute set to 2 1407 (audit log cleared)."; 1408 } 1410 container sys-sec-event-format { 1411 description 1412 "This is a mandatory uint 8 enumerated integer, which 1413 is used to specify the data type of the 1414 sysSecEventContent attribute."; 1416 leaf unknown { 1417 type boolean; 1418 description 1419 "If SecEventFormat is unknown"; 1420 } 1421 leaf guid { 1422 type boolean; 1423 description 1424 "If SecEventFormat is GUID 1425 (Generic Unique IDentifier)"; 1426 } 1427 leaf uuid { 1428 type boolean; 1429 description 1430 "If SecEventFormat is UUID 1431 (Universal Unique IDentifier)"; 1432 } 1433 leaf uri { 1434 type boolean; 1435 description 1436 "If SecEventFormat is URI 1437 (Uniform Resource Identifier)"; 1438 } 1439 leaf fqdn { 1440 type boolean; 1441 description 1442 "If SecEventFormat is FQDN 1443 (Fully Qualified Domain Name)"; 1445 } 1446 leaf fqpn { 1447 type boolean; 1448 description 1449 "If SecEventFormat is FQPN 1450 (Fully Qualified Path Name)"; 1451 } 1452 } 1454 container sys-sec-event-type { 1455 description 1456 "This is a mandatory uint 8 enumerated integer, which 1457 is used to specify the type of event that involves 1458 this device."; 1460 leaf unknown { 1461 type boolean; 1462 description 1463 "If sysSecEventType is unknown"; 1464 } 1465 leaf audit-log-written-to { 1466 type boolean; 1467 description 1468 "If sysSecEventTypeSeverity 1469 is that audit log is written to"; 1470 } 1471 leaf audit-log-cleared { 1472 type boolean; 1473 description 1474 "If sysSecEventTypeSeverity 1475 is that audit log is cleared"; 1476 } 1477 leaf policy-created { 1478 type boolean; 1479 description 1480 "If sysSecEventTypeSeverity 1481 is that policy is created"; 1482 } 1483 leaf policy-edited{ 1484 type boolean; 1485 description 1486 "If sysSecEventTypeSeverity 1487 is that policy is edited"; 1488 } 1489 leaf policy-deleted{ 1490 type boolean; 1491 description 1492 "If sysSecEventTypeSeverity 1493 is that policy is deleted"; 1494 } 1495 leaf policy-executed{ 1496 type boolean; 1497 description 1498 "If sysSecEventTypeSeverity 1499 is that policy is executed"; 1500 } 1501 } 1502 } 1503 container time-event { 1504 description "TBD"; 1506 leaf time-sec-event-begin { 1507 type boolean; 1508 description 1509 "This is a mandatory DateTime attribute, and 1510 represents the beginning of a time period. 1511 It has a value that has a date and/or a time 1512 component (as in the Java or Python libraries)."; 1513 } 1515 leaf time-sec-event-end { 1516 type boolean; 1517 description 1518 "This is a mandatory DateTime attribute, and 1519 represents the end of a time period. It has 1520 a value that has a date and/or a time component 1521 (as in the Java or Python libraries). If this is 1522 a single event occurrence, and not a time period 1523 when the event can occur, then the 1524 timeSecEventPeriodEnd attribute may be ignored."; 1525 } 1527 leaf time-sec-event-time-zone { 1528 type boolean; 1529 description 1530 "This is a mandatory string attribute, and defines a 1531 time zone that this event occurred in using the 1532 format specified in ISO8601."; 1533 } 1534 } 1536 } 1538 container condition { 1539 description 1540 " This is abstract. A condition is defined as a set 1541 of attributes, features, and/or values that are to be 1542 compared with a set of known attributes, features, 1543 and/or values in order to determine whether or not the 1544 set of Actions in that (imperative) I2NSF Policy Rule 1545 can be executed or not. Examples of I2NSF Conditions 1546 include matching attributes of a packet or flow, and 1547 comparing the internal state of an NSF to a desired state."; 1549 container packet-security-condition { 1550 description "TBD"; 1552 container packet-security-mac-condition { 1553 description 1554 "The purpose of this Class is to represent packet MAC 1555 packet header information that can be used as part of 1556 a test to determine if the set of Policy Actions in 1557 this ECA Policy Rule should be execute or not."; 1559 leaf pkt-sec-cond-mac-dest { 1560 type boolean; 1561 description 1562 "The MAC destination address (6 octets long)."; 1563 } 1565 leaf pkt-sec-cond-mac-src { 1566 type boolean; 1567 description 1568 "The MAC source address (6 octets long)."; 1569 } 1571 leaf pkt-sec-cond-mac-8021q { 1572 type boolean; 1573 description 1574 "This is an optional string attribute, and defines 1575 The 802.1Q tab value (2 octets long)."; 1576 } 1578 leaf pkt-sec-cond-mac-ether-type { 1579 type boolean; 1580 description 1581 "The EtherType field (2 octets long). Values up to 1582 and including 1500 indicate the size of the payload 1583 in octets; values of 1536 and above define which 1584 protocol is encapsulated in the payload of the 1585 frame."; 1586 } 1587 leaf pkt-sec-cond-mac-tci { 1588 type string; 1589 description 1590 "This is an optional string attribute, and defines 1591 the Tag Control Information. This consists of a 3 1592 bit user priority field, a drop eligible indicator 1593 (1 bit), and a VLAN identifier (12 bits)."; 1594 } 1595 } 1597 container packet-security-ipv4-condition { 1598 description 1599 "The purpose of this Class is to represent packet IPv4 1600 packet header information that can be used as part of 1601 a test to determine if the set of Policy Actions in 1602 this ECA Policy Rule should be executed or not."; 1604 leaf pkt-sec-cond-ipv4-header-length { 1605 type boolean; 1606 description 1607 "The IPv4 packet header consists of 14 fields, 1608 of which 13 are required."; 1609 } 1611 leaf pkt-sec-cond-ipv4-tos { 1612 type boolean; 1613 description 1614 "The ToS field could specify a datagram's priority 1615 and request a route for low-delay, high-throughput, 1616 or highly-reliable service.."; 1617 } 1619 leaf pkt-sec-cond-ipv4-total-length { 1620 type boolean; 1621 description 1622 "This 16-bit field defines the entire packet size, 1623 including header and data, in bytes."; 1624 } 1626 leaf pkt-sec-cond-ipv4-id { 1627 type boolean; 1628 description 1629 "This field is an identification field and is 1630 primarily used for uniquely identifying 1631 the group of fragments of a single IP datagram."; 1632 } 1634 leaf pkt-sec-cond-ipv4-fragment { 1635 type boolean; 1636 description 1637 "IP fragmentation is an Internet Protocol (IP) 1638 process that breaks datagrams into smaller pieces 1639 (fragments), so that packets may be formed that 1640 can pass through a link with a smaller maximum 1641 transmission unit (MTU) than the original 1642 datagram size."; 1643 } 1645 leaf pkt-sec-cond-ipv4-fragment-offset { 1646 type boolean; 1647 description 1648 "Fragment offset field along with Don't Fragment 1649 and More Fragment flags in the IP protocol 1650 header are used for fragmentation and reassembly 1651 of IP datagrams."; 1652 } 1654 leaf pkt-sec-cond-ipv4-ttl { 1655 type boolean; 1656 description 1657 "The ttl keyword is used to check for a specific 1658 IP time-to-live value in the header of 1659 a packet."; 1660 } 1662 leaf pkt-sec-cond-ipv4-protocol { 1663 type boolean; 1664 description 1665 "Internet Protocol version 4(IPv4) is the fourth 1666 version of the Internet Protocol (IP)."; 1667 } 1669 leaf pkt-sec-cond-ipv4-src { 1670 type boolean; 1671 description 1672 "Defines the IPv4 Source Address."; 1673 } 1675 leaf pkt-sec-cond-ipv4-dest { 1676 type boolean; 1677 description 1678 "Defines the IPv4 Destination Address."; 1679 } 1681 leaf pkt-sec-cond-ipv4-ipopts { 1682 type boolean; 1683 description 1684 "With the ipopts keyword you can check if 1685 a specific ip option is set. Ipopts has 1686 to be used at the beginning of a rule."; 1687 } 1689 leaf pkt-sec-cond-ipv4-sameip { 1690 type boolean; 1691 description 1692 "Every packet has a source IP-address and 1693 a destination IP-address. It can be that 1694 the source IP is the same as 1695 the destination IP."; 1696 } 1698 leaf pkt-sec-cond-ipv4-geoip { 1699 type boolean; 1700 description 1701 "The geoip keyword enables you to match on 1702 the source, destination or source and destination 1703 IP addresses of network traffic and to see to 1704 which country it belongs. To do this, Suricata 1705 uses GeoIP API with MaxMind database format."; 1706 } 1707 } 1709 container packet-security-ipv6-condition { 1710 description 1711 "The purpose of this Class is to represent packet 1712 IPv6 packet header information that can be used as 1713 part of a test to determine if the set of Policy 1714 Actions in this ECA Policy Rule should be executed 1715 or not."; 1717 leaf pkt-sec-cond-ipv6-dscp { 1718 type boolean; 1719 description 1720 "Differentiated Services Code Point (DSCP) 1721 of ipv6."; 1722 } 1724 leaf pkt-sec-cond-ipv6-ecn { 1725 type boolean; 1726 description 1727 "ECN allows end-to-end notification of network 1728 congestion without dropping packets."; 1729 } 1730 leaf pkt-sec-cond-ipv6-traffic-class { 1731 type boolean; 1732 description 1733 "The bits of this field hold two values. The 6 1734 most-significant bits are used for 1735 differentiated services, which is used to 1736 classify packets."; 1737 } 1739 leaf pkt-sec-cond-ipv6-flow-label { 1740 type boolean; 1741 description 1742 "The flow label when set to a non-zero value 1743 serves as a hint to routers and switches 1744 with multiple outbound paths that these 1745 packets should stay on the same path so that 1746 they will not be reordered."; 1747 } 1749 leaf pkt-sec-cond-ipv6-payload-length { 1750 type boolean; 1751 description 1752 "The size of the payload in octets, 1753 including any extension headers."; 1754 } 1756 leaf pkt-sec-cond-ipv6-next-header { 1757 type boolean; 1758 description 1759 "Specifies the type of the next header. 1760 This field usually specifies the transport 1761 layer protocol used by a packet's payload."; 1762 } 1764 leaf pkt-sec-cond-ipv6-hop-limit { 1765 type boolean; 1766 description 1767 "Replaces the time to live field of IPv4."; 1768 } 1770 leaf pkt-sec-cond-ipv6-src { 1771 type boolean; 1772 description 1773 "The IPv6 address of the sending node."; 1774 } 1776 leaf pkt-sec-cond-ipv6-dest { 1777 type boolean; 1778 description 1779 "The IPv6 address of the destination node(s)."; 1780 } 1781 } 1783 container packet-security-tcp-condition { 1784 description 1785 "The purpose of this Class is to represent packet 1786 TCP packet header information that can be used as 1787 part of a test to determine if the set of Policy 1788 Actions in this ECA Policy Rule should be executed 1789 or not."; 1791 leaf pkt-sec-cond-tcp-src-port { 1792 type boolean; 1793 description 1794 "This is a mandatory string attribute, and 1795 defines the Source Port number (16 bits)."; 1796 } 1798 leaf pkt-sec-cond-tcp-dest-port { 1799 type boolean; 1800 description 1801 "This is a mandatory string attribute, and 1802 defines the Destination Port number (16 bits)."; 1803 } 1805 leaf pkt-sec-cond-tcp-seq-num { 1806 type boolean; 1807 description 1808 "If the SYN flag is set (1), then this is the 1809 initial sequence number."; 1810 } 1812 leaf pkt-sec-cond-tcp-ack-num { 1813 type boolean; 1814 description 1815 "If the ACK flag is set then the value of this 1816 field is the next sequence number that the sender 1817 is expecting."; 1818 } 1820 leaf pkt-sec-cond-tcp-window-size { 1821 type boolean; 1822 description 1823 "The size of the receive window, which specifies 1824 the number of windows size units (by default,bytes) 1825 (beyond the segment identified by the sequence 1826 number in the acknowledgment field) that the sender 1827 of this segment is currently willing to recive."; 1828 } 1830 leaf pkt-sec-cond-tcp-flags { 1831 type boolean; 1832 description 1833 "This is a mandatory string attribute, and defines 1834 the nine Control bit flags (9 bits)."; 1835 } 1836 } 1838 container packet-security-udp-condition { 1839 description 1840 "The purpose of this Class is to represent packet UDP 1841 packet header information that can be used as part 1842 of a test to determine if the set of Policy Actions 1843 in this ECA Policy Rule should be executed or not."; 1845 leaf pkt-sec-cond-udp-src-port { 1846 type boolean; 1847 description 1848 "This is a mandatory string attribute, and 1849 defines the UDP Source Port number (16 bits)."; 1850 } 1852 leaf pkt-sec-cond-udp-dest-port { 1853 type boolean; 1854 description 1855 "This is a mandatory string attribute, and 1856 defines the UDP Destination Port number (16 bits)."; 1857 } 1859 leaf pkt-sec-cond-udp-length { 1860 type boolean; 1861 description 1862 "This is a mandatory string attribute, and defines 1863 the length in bytes of the UDP header and data 1864 (16 bits)."; 1865 } 1866 } 1868 container packet-security-icmp-condition { 1869 description 1870 "The internet control message protocol condition."; 1872 leaf pkt-sec-cond-icmp-type { 1873 type boolean; 1874 description 1875 "ICMP type, see Control messages."; 1876 } 1878 leaf pkt-sec-cond-icmp-code { 1879 type boolean; 1880 description 1881 "ICMP subtype, see Control messages."; 1882 } 1884 leaf pkt-sec-cond-icmp-seg-num { 1885 type boolean; 1886 description 1887 "The icmp Sequence Number."; 1888 } 1889 } 1890 } 1892 container packet-payload-condition { 1893 description "TBD"; 1894 leaf pkt-payload-content { 1895 type boolean; 1896 description 1897 "The content keyword is very important in 1898 signatures. Between the quotation marks you 1899 can write on what you would like the 1900 signature to match."; 1901 } 1902 } 1903 leaf acl-number { 1904 type boolean; 1905 description 1906 "This is acl-number."; 1907 } 1909 container application-condition { 1910 description 1911 "TBD"; 1913 leaf application-object { 1914 type boolean; 1915 description 1916 "This is application object."; 1917 } 1918 leaf application-group { 1919 type boolean; 1920 description 1921 "This is application group."; 1923 } 1924 leaf application-label { 1925 type boolean; 1926 description 1927 "This is application label."; 1928 } 1929 container category { 1930 description 1931 "TBD"; 1932 leaf application-category { 1933 type boolean; 1934 description 1935 "TBD"; 1937 } 1938 } 1939 } 1941 container target-condition { 1942 description "TBD"; 1944 leaf device-sec-context-cond { 1945 type boolean; 1946 description 1947 "The device attribute that can identify a device, 1948 including the device type (i.e., router, switch, 1949 pc, ios, or android) and the device's owner as 1950 well."; 1951 } 1952 } 1953 container users-condition { 1954 description "TBD"; 1956 container user{ 1957 description 1958 "The user (or user group) information with which 1959 network flow is associated: The user has many 1960 attributes such as name, id, password, type, 1961 authentication mode and so on. Name/id is often 1962 used in the security policy to identify the user. 1963 Besides, NSF is aware of the IP address of the 1964 user provided by a unified user management system 1965 via network. Based on name-address association, 1966 NSF is able to enforce the security functions 1967 over the given user (or user group)"; 1969 choice user-name { 1970 description 1971 "The name of the user. 1972 This must be unique."; 1974 case tenant { 1975 description 1976 "Tenant information."; 1978 leaf tenant { 1979 type boolean; 1980 description 1981 "User's tenant information."; 1982 } 1983 } 1985 case vn-id { 1986 description 1987 "VN-ID information."; 1989 leaf vn-id { 1990 type boolean; 1991 description 1992 "User's VN-ID information."; 1993 } 1994 } 1995 } 1996 } 1997 container group { 1998 description 1999 "The user (or user group) information with which 2000 network flow is associated: The user has many 2001 attributes such as name, id, password, type, 2002 authentication mode and so on. Name/id is often 2003 used in the security policy to identify the user. 2004 Besides, NSF is aware of the IP address of the 2005 user provided by a unified user management system 2006 via network. Based on name-address association, 2007 NSF is able to enforce the security functions 2008 over the given user (or user group)"; 2010 choice group-name { 2011 description 2012 "The name of the user. 2013 This must be unique."; 2015 case tenant { 2016 description 2017 "Tenant information."; 2019 leaf tenant { 2020 type boolean; 2021 description 2022 "User's tenant information."; 2023 } 2024 } 2026 case vn-id { 2027 description 2028 "VN-ID information."; 2030 leaf vn-id { 2031 type boolean; 2032 description 2033 "User's VN-ID information."; 2034 } 2035 } 2036 } 2037 leaf security-grup { 2038 type boolean; 2039 mandatory true; 2040 description 2041 "security-grup."; 2042 } 2043 } 2044 } 2046 container url-category-condition { 2047 description 2048 "TBD"; 2049 leaf pre-defined-category { 2050 type boolean; 2051 description 2052 "This is pre-defined-category."; 2053 } 2054 leaf user-defined-category { 2055 type boolean; 2056 description 2057 "This user-defined-category."; 2058 } 2059 } 2061 container context-condition { 2062 description "TBD"; 2063 leaf temp { 2064 type string; 2065 description 2066 "This is temp for context condition."; 2068 } 2069 } 2070 container gen-context-condition { 2071 description "TBD"; 2073 container geographic-location { 2074 description 2075 "The location where network traffic is associated 2076 with. The region can be the geographic location 2077 such as country, province, and city, 2078 as well as the logical network location such as 2079 IP address, network section, and network domain."; 2081 leaf src-geographic-location { 2082 type boolean; 2083 description 2084 "This is mapped to ip address. We can acquire 2085 source region through ip address stored the 2086 database."; 2087 } 2088 leaf dest-geographic-location { 2089 type boolean; 2090 description 2091 "This is mapped to ip address. We can acquire 2092 destination region through ip address stored 2093 the database."; 2094 } 2095 } 2096 } 2097 } 2098 container action { 2099 description 2100 "An action is used to control and monitor aspects of 2101 flow-based NSFs when the event and condition clauses 2102 are satisfied. NSFs provide security functions by 2103 executing various Actions. Examples of I2NSF Actions 2104 include providing intrusion detection and/or protection, 2105 web and flow filtering, and deep packet inspection 2106 for packets and flows."; 2108 leaf rule-log { 2109 type boolean; 2110 description 2111 "rule-log"; 2112 } 2113 leaf session-log { 2114 type boolean; 2115 description 2116 "session-log"; 2117 } 2119 container ingress-action { 2120 description "TBD"; 2122 container ingress-action-type { 2123 description 2124 "Ingress action type: permit, deny, and mirror."; 2125 leaf pass { 2126 type boolean; 2127 description 2128 "If ingress action is pass"; 2129 } 2130 leaf drop { 2131 type boolean; 2132 description 2133 "If ingress action is drop"; 2134 } 2135 leaf reject { 2136 type boolean; 2137 description 2138 "If ingress action is reject"; 2139 } 2140 leaf alert { 2141 type boolean; 2142 description 2143 "If ingress action is alert"; 2144 } 2145 leaf mirror { 2146 type boolean; 2147 description 2148 "If ingress action is mirror"; 2149 } 2150 } 2151 } 2152 container egress-action { 2153 description "TBD"; 2155 container egress-action-type { 2156 description 2157 "Egress-action-type: invoke-signaling, 2158 tunnel-encapsulation, and forwarding."; 2159 leaf invoke-signaling { 2160 type boolean; 2161 description 2162 "If egress action is invoke signaling"; 2163 } 2164 leaf tunnel-encapsulation { 2165 type boolean; 2166 description 2167 "If egress action is tunnel encapsulation"; 2168 } 2169 leaf forwarding { 2170 type boolean; 2171 description 2172 "If egress action is forwarding"; 2173 } 2174 leaf redirection { 2175 type boolean; 2176 description 2177 "If egress action is redirection"; 2178 } 2179 } 2180 } 2182 } 2183 container resolution-strategy { 2184 description 2185 "The resolution strategies can be used to 2186 specify how to resolve conflicts that occur between 2187 the actions of the same or different policy rules that 2188 are matched and contained in this particular NSF"; 2190 leaf first-matching-rule { 2191 type boolean; 2192 description 2193 "If the resolution strategy is first matching rule"; 2194 } 2196 leaf last-matching-rule { 2197 type boolean; 2198 description 2199 "If the resolution strategy is last matching rule"; 2200 } 2201 } 2202 } 2203 } 2205 grouping i2nsf-advanced-sec-caps { 2206 description 2207 "i2nsf-advanced-sec-caps"; 2208 container advanced-sec-capabilities { 2209 description 2210 "net-sec-capabilities"; 2212 container antivirus { 2213 description 2214 "antivirus"; 2216 leaf detect { 2217 type boolean; 2218 description 2219 "detect capability"; 2220 } 2221 leaf exception-application { 2222 type boolean; 2223 description 2224 "exception-application capability"; 2225 } 2226 leaf exception-signature { 2227 type boolean; 2228 description 2229 "exception-signature capability"; 2230 } 2231 leaf whitelists { 2232 type boolean; 2233 description 2234 "exception-signature capability"; 2235 } 2236 } 2238 container antiddos { 2239 description 2240 "antiddos"; 2242 leaf syn-flood-action { 2243 type boolean; 2244 description 2245 "syn-flood-action capability"; 2246 } 2247 leaf udp-flood-action { 2248 type boolean; 2249 description 2250 "udp-flood-action capability"; 2251 } 2252 leaf http-flood-action { 2253 type boolean; 2254 description 2255 "http-flood-action capability"; 2256 } 2257 leaf https-flood-action { 2258 type boolean; 2259 description 2260 "https-flood-action capability"; 2261 } 2262 leaf dns-request-flood-action { 2263 type boolean; 2264 description 2265 "dns-request-flood-action capability"; 2266 } 2267 leaf dns-reply-flood-action { 2268 type boolean; 2269 description 2270 "dns-reply-flood-action capability"; 2271 } 2272 leaf icmp-flood-action { 2273 type boolean; 2274 description 2275 "icmp-flood-action capability"; 2276 } 2277 leaf sip-flood-action { 2278 type boolean; 2279 description 2280 "sip-flood-action capability"; 2281 } 2282 leaf detect-mode { 2283 type boolean; 2284 description 2285 "detect mode capability"; 2286 } 2287 leaf baseline-learn { 2288 type boolean; 2289 description 2290 "baseline-learn capability"; 2291 } 2292 } 2294 container ips { 2295 description 2296 "ips"; 2298 leaf signature-set { 2299 type boolean; 2300 description 2301 "signature-set capability"; 2302 } 2303 leaf exception-signature { 2304 type boolean; 2305 description 2306 "exception-signature capability"; 2308 } 2309 } 2310 } 2311 } 2313 grouping i2nsf-con-sec-control-caps { 2314 description 2315 "i2nsf-con-sec-control-caps"; 2317 container con-sec-control-capabilities { 2318 description 2319 "content-security-control-capabilities"; 2321 leaf anti-virus { 2322 type boolean; 2323 description 2324 "antivirus"; 2325 } 2326 leaf ips { 2327 type boolean; 2328 description 2329 "ips"; 2330 } 2332 leaf ids { 2333 type boolean; 2334 description 2335 "ids"; 2336 } 2338 leaf url-filter { 2339 type boolean; 2340 description 2341 "url-filter"; 2342 } 2343 leaf data-filter { 2344 type boolean; 2345 description 2346 "data-filter"; 2347 } 2348 leaf mail-filter { 2349 type boolean; 2350 description 2351 "mail-filter"; 2352 } 2353 leaf sql-filter { 2354 type boolean; 2355 description 2356 "sql-filter"; 2357 } 2358 leaf file-blocking { 2359 type boolean; 2360 description 2361 "file-blocking"; 2362 } 2363 leaf file-isolate { 2364 type boolean; 2365 description 2366 "file-isolate"; 2367 } 2368 leaf pkt-capture { 2369 type boolean; 2370 description 2371 "pkt-capture"; 2372 } 2373 leaf application-behavior { 2374 type boolean; 2375 description 2376 "application-behavior"; 2377 } 2378 leaf voip-volte { 2379 type boolean; 2380 description 2381 "voip-volte"; 2382 } 2383 } 2385 } 2387 grouping i2nsf-attack-mitigation-control-caps { 2388 description 2389 "i2nsf-attack-mitigation-control-caps"; 2391 container attack-mitigation-capabilities { 2392 description 2393 "attack-mitigation-capabilities"; 2394 choice attack-mitigation-control-type { 2395 description 2396 "attack-mitigation-control-type"; 2397 case ddos-attack { 2398 description 2399 "ddos-attack"; 2400 choice ddos-attack-type { 2401 description 2402 "ddos-attack-type"; 2403 case network-layer-ddos-attack { 2404 description 2405 "network-layer-ddos-attack"; 2406 container network-layer-ddos-attack-types { 2407 description 2408 "network-layer-ddos-attack-type"; 2409 leaf syn-flood-attack { 2410 type boolean; 2411 description 2412 "syn-flood-attack"; 2413 } 2414 leaf udp-flood-attack { 2415 type boolean; 2416 description 2417 "udp-flood-attack"; 2418 } 2419 leaf icmp-flood-attack { 2420 type boolean; 2421 description 2422 "icmp-flood-attack"; 2423 } 2424 leaf ip-fragment-flood-attack { 2425 type boolean; 2426 description 2427 "ip-fragment-flood-attack"; 2428 } 2429 leaf ipv6-related-attack { 2430 type boolean; 2431 description 2432 "ip-fragment-flood-attack"; 2433 } 2434 } 2435 } 2436 case app-layer-ddos-attack { 2437 description 2438 "app-layer-ddos-attack"; 2439 container app-layer-ddos-attack-types { 2440 description 2441 "app-layer-ddos-attack-types"; 2442 leaf http-flood-attack { 2443 type boolean; 2444 description 2445 "http-flood-attack"; 2446 } 2447 leaf https-flood-attack { 2448 type boolean; 2449 description 2450 "https-flood-attack"; 2451 } 2452 leaf dns-flood-attack { 2453 type boolean; 2454 description 2455 "dns-flood-attack"; 2456 } 2457 leaf dns-amp-flood-attack { 2458 type boolean; 2459 description 2460 "dns-amp-flood-attack"; 2461 } 2462 leaf ssl-flood-attack { 2463 type boolean; 2464 description 2465 "ssl-flood-attack"; 2466 } 2467 } 2468 } 2469 } 2470 } 2472 case single-packet-attack { 2473 description 2474 "single-packet-attack"; 2475 choice single-packet-attack-type { 2476 description 2477 "single-packet-attack-type"; 2478 case scan-and-sniff-attack { 2479 description 2480 "scan-and-sniff-attack"; 2481 leaf ip-sweep-attack { 2482 type boolean; 2483 description 2484 "ip-sweep-attack"; 2485 } 2486 leaf port-scanning-attack { 2487 type boolean; 2488 description 2489 "port-scanning-attack"; 2490 } 2491 } 2492 case malformed-packet-attack { 2493 description 2494 "malformed-packet-attack"; 2495 leaf ping-of-death-attack { 2496 type boolean; 2497 description 2498 "ping-of-death-attack"; 2499 } 2500 leaf teardrop-attack { 2501 type boolean; 2502 description 2503 "teardrop-attack"; 2504 } 2505 } 2506 case special-packet-attack { 2507 description 2508 "special-packet-attack"; 2509 leaf oversized-icmp-attack { 2510 type boolean; 2511 description 2512 "oversized-icmp-attack"; 2513 } 2514 leaf tracert-attack { 2515 type boolean; 2516 description 2517 "tracert-attack"; 2518 } 2519 } 2520 } 2521 } 2522 } 2523 } 2524 } 2526 list nsf { 2527 key "nsf-name"; 2528 description 2529 "nsf-name"; 2530 leaf nsf-name { 2531 type string; 2532 mandatory true; 2533 description 2534 "nsf-name"; 2535 } 2537 uses capabilities-information; 2539 container generic-nsf-capabilities { 2540 description 2541 "generic-nsf-capabilities"; 2542 uses i2nsf-net-sec-caps; 2543 } 2544 container advanced-nsf-capabilities { 2545 description 2546 "advanced-nsf-capabilities"; 2547 uses i2nsf-advanced-sec-caps; 2548 } 2550 container complete-nsf-capabilities { 2551 description 2552 "generic-nsf-capabilities"; 2553 uses i2nsf-con-sec-control-caps; 2554 uses i2nsf-attack-mitigation-control-caps; 2555 } 2557 } 2559 rpc call-appropriate-nsf { 2560 description 2561 "We can acquire appropriate NSF that we want 2562 If we give type of NSF that we want to use, 2563 we acquire the location information of NSF"; 2565 input { 2566 leaf nsf-type { 2567 type nsf-type; 2568 mandatory true; 2569 description 2570 "This is used to acquire NSF 2571 This is mandatory"; 2572 } 2573 uses i2nsf-it-resources; 2574 } 2575 output { 2576 uses i2nsf-nsf-location; 2577 } 2578 } 2579 } 2581 2583 Figure 12: YANG Data Module of I2NSF Capability 2585 8. IANA Considerations 2587 No IANA considerations exist for this document at this time. URL 2588 will be added. 2590 9. Security Considerations 2592 This document introduces no additional security threats and SHOULD 2593 follow the security requirements as stated in [RFC8329]. 2595 10. References 2597 10.1. Normative References 2599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2600 Requirement Levels", BCP 14, RFC 2119, March 1997. 2602 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 2603 Network Configuration Protocol (NETCONF)", RFC 6020, 2604 October 2010. 2606 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 2607 RFC 7950, August 2016. 2609 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2610 and J. Jeong, "Interface to Network Security Functions 2611 (I2NSF): Problem Statement and Use Cases", RFC 8192, July 2612 2017. 2614 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2615 Kumar, "Framework for Interface to Network Security 2616 Functions", RFC 8329, February 2018. 2618 [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 2619 S., and N. Bahadur, "A YANG Data Model for Routing 2620 Information Base (RIB)", RFC RFC8431, September 2018. 2622 10.2. Informative References 2624 [i2nsf-advanced-nsf-dm] 2625 Pan, W. and L. Xia, "Configuration of Advanced Security 2626 Functions with I2NSF Security Controller", draft-dong- 2627 i2nsf-asf-config-01 (work in progress), October 2018. 2629 [i2nsf-nsf-cap-im] 2630 Xia, L., Strassner, J., Basile, C., and D. Lopez, 2631 "Information Model of NSFs Capabilities", draft-ietf- 2632 i2nsf-capability-04 (work in progress), October 2018. 2634 [i2nsf-nsf-yang] 2635 Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, 2636 "I2NSF Network Security Function-Facing Interface YANG 2637 Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-01 2638 (work in progress), July 2018. 2640 [i2nsf-sfc] 2641 Hyun, S., Jeong, J., Park, J., and S. Hares, "Service 2642 Function Chaining-Enabled I2NSF Architecture", draft-hyun- 2643 i2nsf-nsf-triggered-steering-06 (work in progress), July 2644 2018. 2646 [i2nsf-terminology] 2647 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 2648 Birkholz, "Interface to Network Security Functions (I2NSF) 2649 Terminology", draft-ietf-i2nsf-terminology-06 (work in 2650 progress), July 2018. 2652 [Policy-Reconciliation] 2653 Basile, C., Lioy, A., Pitscheider, C., and S. Zhao, "A 2654 Formal Model of Policy Reconciliation", 2655 Euromicro Euromicro International Conference on Parallel, 2656 Distributed and Network-Based Processing (PDP), March 2657 2015. 2659 [supa-policy-info-model] 2660 Strassner, J., Halpern, J., and S. Meer, "Generic Policy 2661 Information Model for Simplified Use of Policy 2662 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 2663 model-03 (work in progress), May 2017. 2665 Appendix A. Example: Extended VoIP-VoLTE Security Function Capabilities 2666 Module 2668 This section gives a simple example of how VoIP-VoLTE Security 2669 Function Capabilities module could be extended. 2671 module 2672 ex-voip-volte-capa { 2673 namespace "http://example.com/voip-volte-capa"; 2674 prefix "voip-volte-capa"; 2676 import ietf-i2nsf-capability { 2677 prefix capa; 2678 } 2680 augment "/capa:nsf/capa:generic-nsf-capabilities/" 2681 + "capa:net-sec-control-capabilities/" 2682 + "capa:condition/capa:condition-type" { 2683 case voice-condition { 2684 leaf sip-header-method { 2685 type boolean; 2686 description 2687 "SIP header method."; 2688 } 2690 leaf sip-header-uri { 2691 type boolean; 2692 description 2693 "SIP header URI."; 2694 } 2696 leaf sip-header-from { 2697 type boolean; 2698 description 2699 "SIP header From."; 2700 } 2702 leaf sip-header-to { 2703 type boolean; 2704 description 2705 "SIP header To."; 2706 } 2708 leaf sip-header-expire-time { 2709 type boolean; 2710 description 2711 "SIP header expire time."; 2713 } 2715 leaf sip-header-user-agent { 2716 type boolean; 2717 description 2718 "SIP header user agent."; 2719 } 2720 } 2721 } 2722 } 2724 Figure 13: Example: Extended VoIP-VoLTE Security Function 2725 Capabilities Module 2727 Appendix B. Example: Configuration XML of Capability Module 2729 This section gives a xml examples for a configuration of Capability 2730 module according to a requirement. 2732 B.1. Example: Configuration XML of Generic Network Security Function 2733 Capabilities 2735 This section gives a xml example for generic network security 2736 function capability configuration according to a requirement. 2738 Requirement: Register packet filter according to requirements. 2740 1. The location of the NSF is 221.159.112.150. 2742 2. The NSF can obtain the best effect if the packet was generated by 2743 PC or IoT. 2745 3. The NSF can apply policies according to time. 2747 4. The NSF should be able to block the source packets or destination 2748 packets with IPv4 address. 2750 5. The NSF should be able to pass, reject, or alert packets. 2752 6. Here is XML example for the generic network security function 2753 capability configuration: 2755 2756 2757 2758 2759 2760 2761 2762 2764 Huawei-Firewall 2765 2766 221.159.112.150 2767 2768 2769 true 2770 2771 2772 true 2773 2774 2775 2776 ipv4-packet-filter 2777 2778 true 2779 true 2780 2781 2782 2783 true 2784 true 2785 2786 2787 2788 2789 true 2790 true 2791 true 2792 2793 2794 2795 2796 2797 2798 2799 2801 Figure 14: Example: Configuration XML for Generic Network Security 2802 Function Capability 2804 B.2. Example: Configuration XML of Extended VoIP/VoLTE Security 2805 Function Capabilities Module 2807 This section gives a xml example for extended VoIP-VoLTE security 2808 function capabilities (See Figure 13) configuration according to a 2809 requirement. 2811 Requirement: Register VoIP/VoLTe security function according to 2812 requirements. 2814 1. The location of the NSF is 221.159.112.151. 2816 2. The NSF can obtain the best effect if the packet was generated by 2817 VoIP-VoLTE phone. 2819 3. The NSF should be able to block the malicious sip packets with 2820 user agent. 2822 4. The NSF should be able to pass, reject, or alert packets. 2824 Here is XML example for the VoIP-VoLTE security function capabilities 2825 configuration: 2827 2828 2829 2830 2831 2832 2833 2834 2836 Cisco-VoIP-VoLTE 2837 2838 221.159.112.151 2839 2840 2841 2842 sip-packet-filter 2843 2844 true 2845 2846 2847 2848 true 2849 true 2850 true 2851 2852 2853 2854 2855 2856 2857 2858 2860 Figure 15: Example: Configuration XML for Extended VoIP/VoLTE 2861 Security Function Capabilities 2863 Appendix C. Changes from draft-ietf-i2nsf-capability-data-model-01 2865 The following changes are made from draft-ietf-i2nsf-capability-data- 2866 model-01: 2868 o We added capabilities of advanced network security functions such 2869 as anti-virus, anti-ddos, and IPS. 2871 Appendix D. Acknowledgments 2873 This work was supported by Institute for Information & communications 2874 Technology Promotion (IITP) grant funded by the Korea government 2875 (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence 2876 Technology Development for the Customized Security Service 2877 Provisioning). 2879 Appendix E. Contributors 2881 This document is made by the group effort of I2NSF working group. 2882 Many people actively contributed to this document. The following are 2883 considered co-authors: 2885 o Hyoungshick Kim (Sungkyunkwan University) 2887 o Daeyoung Hyun (Sungkyunkwan University) 2889 o Dongjin Hong (Sungkyunkwan University) 2891 o Liang Xia (Huawei) 2893 o Jung-Soo Park (ETRI) 2895 o Tae-Jin Ahn (Korea Telecom) 2897 o Se-Hui Lee (Korea Telecom) 2899 Authors' Addresses 2901 Susan Hares 2902 Huawei 2903 7453 Hickory Hill 2904 Saline, MI 48176 2905 USA 2907 Phone: +1-734-604-0332 2908 EMail: shares@ndzh.com 2909 Jaehoon Paul Jeong 2910 Department of Software 2911 Sungkyunkwan University 2912 2066 Seobu-Ro, Jangan-Gu 2913 Suwon, Gyeonggi-Do 16419 2914 Republic of Korea 2916 Phone: +82 31 299 4957 2917 Fax: +82 31 290 7996 2918 EMail: pauljeong@skku.edu 2919 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2921 Jinyong Tim Kim 2922 Department of Computer Engineering 2923 Sungkyunkwan University 2924 2066 Seobu-Ro, Jangan-Gu 2925 Suwon, Gyeonggi-Do 16419 2926 Republic of Korea 2928 Phone: +82 10 8273 0930 2929 EMail: timkim@skku.edu 2931 Robert Moskowitz 2932 HTT Consulting 2933 Oak Park, MI 2934 USA 2936 Phone: +1-248-968-9809 2937 EMail: rgm@htt-consult.com 2939 Qiushi Lin 2940 Huawei 2941 Huawei Industrial Base 2942 Shenzhen, Guangdong 518129 2943 China 2945 EMail: linqiushi@huawei.com