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