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