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