idnits 2.17.1 draft-ietf-i2nsf-capability-data-model-00.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 362 has weird spacing: '...address ine...' == Line 364 has weird spacing: '...address ine...' == Line 414 has weird spacing: '...es-name str...' == Line 420 has weird spacing: '...-offset bool...' == Line 524 has weird spacing: '...es-name str...' == (9 more instances...) -- The document date (April 23, 2018) is 2195 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 384 ** 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: October 25, 2018 J. Kim 6 Sungkyunkwan University 7 R. Moskowitz 8 HTT Consulting 9 Q. Lin 10 Huawei 11 April 23, 2018 13 I2NSF Capability YANG Data Model 14 draft-ietf-i2nsf-capability-data-model-00 16 Abstract 18 This document defines a YANG data model for capabilities that enable 19 an I2NSF user to control various Network Security Functions (NSFs) in 20 the framework for Interface to Network Security Functions (I2NSF). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 25, 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 97 1. Introduction 99 As the industry becomes more sophisticated and network devices (e.g., 100 Internet of Things, Self-driving vehicles, and VoIP/VoLTE 101 smartphones), service providers have a lot of problems mentioned in 102 [RFC8192]. To resolve these problems, [i2nsf-nsf-cap-im] specifies 103 the information model of the capabilities of Network Security 104 Functions (NSFs). 106 This document provides a data model using YANG [RFC6020][RFC7950] 107 that defines the capabilities of NSFs to express capabilities of 108 those security devices. This YANG data model is based on the 109 information model for I2NSF NSF capabilities [i2nsf-nsf-cap-im]. The 110 security devices can register their own capabilities into Network 111 Operator Management (Mgmt) System (i.e., Security Controller) with 112 this YANG data model through the registration interface [RFC8329]. 113 After the capabilities of the NSFs are registered, this YANG data 114 model can be used by the IN2SF user or Service Function Forwarder 115 (SFF) [i2nsf-sfc] to acquire appropriate NSFs that can be controlled 116 by the Network Operator Mgmt System. 118 The "Event-Condition-Action" (ECA) policy model is used as the basis 119 for the design of I2NSF Policy Rules. The "ietf-i2nsf-capability" 120 YANG module defined in this document provides the following features: 122 o Configuration of identification for generic network security 123 function policy 125 o Configuration of event capabilities for generic network security 126 function policy 128 o Configuration of condition capabilities for generic network 129 security function policy 131 o Configuration of action capabilities for generic network security 132 function policy 134 o Configuration of strategy capabilities for generic network 135 security function policy 137 o Configuration of default action capabilities for generic network 138 security function policy 140 o RPC for acquiring appropriate network security function according 141 to type of NSF and/or target devices. 143 2. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 3. Terminology 151 This document uses the terminology described in 152 [i2nsf-terminology][i2nsf-nsf-cap-im] 153 [i2rs-rib-data-model][supa-policy-info-model]. Especially, the 154 following terms are from [supa-policy-info-model]: 156 o Data Model: A data model is a representation of concepts of 157 interest to an environment in a form that is dependent on data 158 repository, data definition language, query language, 159 implementation language, and protocol. 161 o Information Model: An information model is a representation of 162 concepts of interest to an environment in a form that is 163 independent of data repository, data definition language, query 164 language, implementation language, and protocol. 166 3.1. Tree Diagrams 168 A simplified graphical representation of the data model is used in 169 this document. The meaning of the symbols in these diagrams 170 [i2rs-rib-data-model] is as follows: 172 o Brackets "[" and "]" enclose list keys. 174 o Abbreviations before data node names: "rw" means configuration 175 (read-write) and "ro" state data (read-only). 177 o Symbols after data node names: "?" means an optional node and "*" 178 denotes a "list" and "leaf-list". 180 o Parentheses enclose choice and case nodes, and case nodes are also 181 marked with a colon (":"). 183 o Ellipsis ("...") stands for contents of subtrees that are not 184 shown. 186 4. Overview 188 This section explains overview how the YANG data model can be used by 189 I2NSF User, Developer's Mgmt System, and SFF. Figure 1 shows 190 capabilities of NSFs in I2NSF Framework. As shown in this figure, 191 Developer's Mgmt System can register NSFs with capabilities that the 192 device can support. To register NSFs in this way, the Developer's 193 Mgmt System utilizes this standardized capabilities YANG data model 194 through registration interface. Through this registration of 195 capabilities, the a lot of problems [RFC8192] can be resolved. The 196 following shows use cases. 198 Note [i2nsf-nsf-yang] is used to configure rules of NSFs in I2NSF 199 Framework. 201 +-------------------------------------------------------+ 202 | I2NSF User (e.g., Overlay Network Mgmt, Enterprise | 203 | Network Mgmt, another network domain's mgmt, etc.) | 204 +--------------------+----------------------------------+ 205 | 206 Consumer-Facing Interface | 207 | 208 | I2NSF 209 +-----------------+------------+ Registration +-------------+ 210 | Network Operator Mgmt System | Interface | Developer's | 211 | (i.e., Security Controller) | < --------- > | Mgmt System | 212 +-----------------+------------+ +-------------+ 213 | New NSF 214 | E = {} 215 NSF-Facing Interface | C = {IPv4, IPv6} 216 | A = {Allow, Deny} 217 | 218 +---------------+----+------------+-----------------+ 219 | | | | 220 +---+---+ +---+---+ +---+---+ +---+---+ 221 | NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-n | ... 222 +-------+ +-------+ +-------+ +-------+ 223 NSF-1 NSF-m NSF-1 NSF-n 224 E = {} E = {user} E = {dev} E = {time} 225 C = {IPv4} C = {IPv6} C = {IPv4, IPv6} C = {IPv4} 226 A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} 228 Developer Mgmt System A Developer Mgmt System B 230 Figure 1: Capabilities of NSFs in I2NSF Framework 232 o If I2NSF User wants to apply rules about blocking malicious users, 233 it is a tremendous burden to apply all of these rules to NSFs one 234 by one. This problem can be resolved by standardizing the 235 capabilities of NSFs. If I2NSF User wants to block malicious 236 users with IPv6, I2NSF User sends the rules about blocking the 237 users to Network Operator Mgmt System. When the Network Operator 238 Mgmt System receives the rules, it sends that rules to appropriate 239 NSFs (i.e., NSF-m in Developer Mgmt System A and NSF-1 in 240 Developer Mgmt System B) which can support the capabilities (i.e., 241 IPv6). Therefore, I2NSF User need not consider NSFs where to 242 apply the rules. 244 o If NSFs find the malicious packets, it is a tremendous burden for 245 I2NSF User to apply the rule about blocking the malicious packets 246 to NSFs one by one. This problem can be resolved by standardizing 247 the capabilities of NSFs. If NSFs find the malicious packets with 248 IPv4, they can ask the Network Operator Mgmt System to alter 249 specific rules and/or configurations. When the Network Operator 250 Mgmt System receives the rules for malicious packets, it inspects 251 whether the rules are reasonable and sends the rules to 252 appropriate NSFs (i.e., NSF-1 in Developer Mgmt System A and NSF-1 253 and NSF-n in Developer Mgmt System B) which can support the 254 capabilities (i.e., IPv4). Therefore, the new rules can be 255 applied to appropriate NSFs without control of I2NSF USer. 257 o If NSFs of Service Function Chaining (SFC) [i2nsf-sfc] fail, it is 258 a tremendous burden for I2NSF User to reconfigure the policy of 259 SFC immediately. This problem can be resolved by periodically 260 acquiring information of appropriate NSFs of SFC. If SFF needs 261 information of Web Application Firewall for SFC, it can ask the 262 Network Operator Mgmt System to acquire the location information 263 of appropriate Web Application Firewall. When the Network 264 Operator Mgmt System receives requested information from SFF, it 265 sends location information of Web Application Firewall to the SFF. 266 Therefore, the policy about the NSFs of SFC can be periodically 267 updated without control of I2NSF USer. 269 5. The Structure and Objective of NSF Capabilities 271 5.1. Generic Network Security Function Identification 273 This shows a identification for generic network security functions. 274 These objects are defined as location information and target device 275 information. 277 5.2. Event Capabilities 279 This shows a event capabilities for generic network security 280 functions policy. This is used to specify capabilities about any 281 important occurrence in time of a change in the system being managed, 282 and/or in the environment of the system being managed. When used in 283 the context of I2NSF Policy Rules, it is used to determine whether 284 the Condition clause of the I2NSF Policy Rule can be evaluated or 285 not. These object of event capabilities is defined as user security 286 event capabilities, device security event capabilities, system 287 security event capabilities, and time security event capabilities. 288 These object of event capabilities can be extended according to 289 specific vendor event features. 291 5.3. Condition Capabilities 293 This shows a condition capabilities for generic network security 294 functions policy. This is used to specify capabilities about a set 295 of attributes, features, and/or values that are to be compared with a 296 set of known attributes, features, and/or values in order to 297 determine whether or not the set of Actions in that (imperative) 298 I2NSF Policy Rule can be executed or not. These object of condition 299 capabilities is defined as packet security condition capabilities, 300 packet payload security condition capabilities, target security 301 condition capabilities, user security condition capabilities, context 302 condition capabilities, and generic context condition capabilities. 303 These object of condition capabilities can be extended according to 304 specific vendor condition features. 306 5.4. Action Capabilities 308 This shows a action capabilities for generic network security 309 functions policy. This is used to specify capabilities to control 310 and monitor aspects of flow-based NSFs when the event and condition 311 clauses are satisfied. NSFs provide security functions by executing 312 various Actions. These object of action capabilities is defined as 313 ingress action capabilities, egress action capabilities, and apply 314 profile action capabilities. These object of action capabilities can 315 be extended according to specific vendor action features. 317 5.5. Resolution Strategy Capabilities 319 This shows a resolution strategy capabilities for generic network 320 security functions policy. This can be used to specify capabilities 321 how to resolve conflicts that occur between the actions of the same 322 or different policy rules that are matched and contained in this 323 particular NSF. These objects are defined as first-matching-rule 324 capability and last-matching-rule capability. These objects can be 325 extended according to specific vendor resolution strategy features. 327 5.6. Default Action Capabilities 329 This shows a default action policy for generic network security 330 functions. This can be used to specify capabilities about a 331 predefined action when no other alternative action was matched by the 332 currently executing I2NSF Policy Rule. 334 5.7. RPC for Acquiring Appropriate Network Security Function 336 This shows a RPC for acquiring an appropriate network security 337 function according to type of NSF and/or target devices. If the SFF 338 [i2nsf-sfc]does not have the location information of network security 339 functions that it should send in own cache table, this can be used to 340 acquire the information. These objects are defined as input data 341 (i.e., NSF type and target devices) and output data (i.e., location 342 information of NSF). 344 6. Data Model Structure 346 This section shows an overview of a structure tree of capabilities 347 for generic network security functions, as defined in the 348 [i2nsf-nsf-cap-im]. 350 6.1. Network Security Function Identification 352 The data model for network security function identification has the 353 following structure: 355 module: ietf-i2nsf-capability 356 +--rw nsf* [nsf-name] 357 +--rw nsf-name string 358 +--rw nsf-type? nsf-type 359 +--rw nsf-address 360 | +--rw (nsf-address-type)? 361 | +--:(ipv4-address) 362 | | +--rw ipv4-address inet:ipv4-address 363 | +--:(ipv6-address) 364 | +--rw ipv6-address inet:ipv6-address 365 +--rw target-device 366 | +--rw pc? boolean 367 | +--rw mobile-phone? boolean 368 | +--rw voip-volte-phone? boolean 369 | +--rw tablet? boolean 370 | +--rw iot? boolean 371 | +--rw vehicle? boolean 372 +--rw generic-nsf-capabilities 373 | +--rw net-sec-capabilities 374 | uses net-sec-caps 375 +--rw complete-nsf-capabilities 376 +--rw con-sec-control-capabilities 377 | uses i2nsf-con-sec-control-caps 378 +--rw attack-mitigation-capabilities 379 uses i2nsf-attack-mitigation-control-caps 381 Figure 2: Data Model Structure for NSF-Identification 383 This draft also utilizes the concepts originated in Basile, Lioy, 384 Pitscheider, and Zhao[2015] concerning conflict resolution, use of 385 external data, and target device. The authors are grateful to 386 Cataldo for pointing out this excellent work. 388 The nsf-type object can be used for configuration about type of a 389 NSF. The types of NSF consists of Network Firewall, Web Application 390 Firewall, Anti-Virus, IDS, IPS, and DDoS Mitigator. The nsf-address 391 object can be used for configuration about location of a NSF. The 392 target-device object can be used for configuration about target 393 devices. We will add additional type of a NSF for more generic 394 network security functions. 396 6.2. Capabilities of Generic Network Security Function 398 The data model for Generic NSF capabilities has the following 399 structure: 401 +--rw generic-nsf-capabilities 402 +--rw net-sec-capabilities 403 uses i2nsf-net-sec-caps 405 Figure 3: Data Model Structure for Capabilities of Network Security 406 Function 408 6.2.1. Event Capabilities 410 The data model for event capabilities has the following structure: 412 +--rw i2nsf-net-sec-caps 413 +--rw net-sec-capabilities* [nsc-capabilities-name] 414 +--rw nsc-capabilities-name string 415 +--rw rule-description? boolean 416 +--rw rule-rev? boolean 417 +--rw rule-priority? boolean 418 +--rw time 419 | +--rw time-zone 420 | | +--rw time-zone-offset boolean 421 | +--rw time-interval 422 | +--rw absolute-time-interval 423 | | +--rw start-time? boolean 424 | | +--rw end-time? boolean 425 | +--rw periodic-time-interval 426 | +--rw day? boolean 427 | +--rw month? boolean 428 +--rw event 429 | +--rw (event-type)? 430 | +--:(usr-event) 431 | | +--rw usr-manual? string 432 | | +--rw usr-sec-event-content? boolean 433 | | +--rw usr-sec-event-format 434 | | | +--rw unknown? boolean 435 | | | +--rw guid? boolean 436 | | | +--rw uuid? boolean 437 | | | +--rw uri? boolean 438 | | | +--rw fqdn? boolean 439 | | | +--rw fqpn? boolean 440 | | +--rw usr-sec-event-type 441 | | +--rw unknown? boolean 442 | | +--rw user-created? boolean 443 | | +--rw user-grp-created? boolean 444 | | +--rw user-deleted? boolean 445 | | +--rw user-grp-deleted? boolean 446 | | +--rw user-logon? boolean 447 | | +--rw user-logoff? boolean 448 | | +--rw user-access-request? boolean 449 | | +--rw user-access-granted? boolean 450 | | +--rw user-access-violation? boolean 451 | +--:(dev-event) 452 | | +--rw dev-manual? string 453 | | +--rw dev-sec-event-content boolean 454 | | +--rw dev-sec-event-format 455 | | | +--rw unknown? boolean 456 | | | +--rw guid? boolean 457 | | | +--rw uuid? boolean 458 | | | +--rw uri? boolean 459 | | | +--rw fqdn? boolean 460 | | | +--rw fqpn? boolean 461 | | +--rw dev-sec-event-type 462 | | | +--rw unknown? boolean 463 | | | +--rw comm-alarm? boolean 464 | | | +--rw quality-of-service-alarm? boolean 465 | | | +--rw process-err-alarm? boolean 466 | | | +--rw equipment-err-alarm? boolean 467 | | | +--rw environmental-err-alarm? boolean 468 | | +--rw dev-sec-event-type-severity 469 | | +--rw unknown? boolean 470 | | +--rw cleared? boolean 471 | | +--rw indeterminate? boolean 472 | | +--rw critical? boolean 473 | | +--rw major? boolean 474 | | +--rw minor? boolean 475 | | +--rw warning? boolean 476 | +--:(sys-event) 477 | | +--rw sys-manual? string 478 | | +--rw sys-sec-event-content? boolean 479 | | +--rw sys-sec-event-format 480 | | | +--rw unknown? boolean 481 | | | +--rw guid? boolean 482 | | | +--rw uuid? boolean 483 | | | +--rw uri? boolean 484 | | | +--rw fqdn? boolean 485 | | | +--rw fqpn? boolean 486 | | +--rw sys-sec-event-type 487 | | +--rw unknown? boolean 488 | | +--rw audit-log-written-to? boolean 489 | | +--rw audit-log-cleared? boolean 490 | | +--rw policy-created? boolean 491 | | +--rw policy-edited? boolean 492 | | +--rw policy-deleted? boolean 493 | | +--rw policy-executed? boolean 494 | +--:(time-event) 495 | +--rw time-manual? string 496 | +--rw time-sec-event-begin? boolean 497 | +--rw time-sec-event-end? boolean 498 | +--rw time-sec-event-time-zone? boolean 499 +--rw condition 500 | ... 501 +--rw action 502 | ... 503 +--rw resolution-strategy 504 | ... 505 +--rw default-action 506 ... 508 Figure 4: Data Model Structure for Event Capabilities of Network 509 Security Function 511 These objects are defined as capabilities of user security event, 512 device security event, system security event, and time security 513 event. These objects can be extended according to specific vendor 514 event features. We will add additional event objects for more 515 generic network security functions. 517 6.2.2. Condition Capabilities 519 The data model for condition capabilities has the following 520 structure: 522 +--rw i2nsf-net-sec-caps 523 +--rw net-sec-capabilities* [nsc-capabilities-name] 524 +--rw nsc-capabilities-name string 525 +--rw rule-description? boolean 526 +--rw rule-rev? boolean 527 +--rw time 528 | +--rw time-zone 529 | | +--rw time-zone-offset boolean 530 | +--rw time-interval 531 | +--rw absolute-time-interval 532 | | +--rw start-time? boolean 533 | | +--rw end-time? boolean 534 | +--rw periodic-time-interval 535 | +--rw day? boolean 536 | +--rw month? boolean 537 +--rw event 538 | ... 539 +--rw condition 540 | +--rw (condition-type)? 541 | +--:(packet-security-condition) 542 | | +--rw packet-manual? string 543 | | +--rw packet-security-mac-condition 544 | | | +--rw pkt-sec-cond-mac-dest? boolean 545 | | | +--rw pkt-sec-cond-mac-src? boolean 546 | | | +--rw pkt-sec-cond-mac-8021q? boolean 547 | | | +--rw pkt-sec-cond-mac-ether-type? boolean 548 | | | +--rw pkt-sec-cond-mac-tci? string 549 | | +--rw packet-security-ipv4-condition 550 | | | +--rw pkt-sec-cond-ipv4-header-length? boolean 551 | | | +--rw pkt-sec-cond-ipv4-tos? boolean 552 | | | +--rw pkt-sec-cond-ipv4-total-length? boolean 553 | | | +--rw pkt-sec-cond-ipv4-id? boolean 554 | | | +--rw pkt-sec-cond-ipv4-fragment? boolean 555 | | | +--rw pkt-sec-cond-ipv4-fragment-offset? boolean 556 | | | +--rw pkt-sec-cond-ipv4-ttl? boolean 557 | | | +--rw pkt-sec-cond-ipv4-protocol? boolean 558 | | | +--rw pkt-sec-cond-ipv4-src? boolean 559 | | | +--rw pkt-sec-cond-ipv4-dest? boolean 560 | | | +--rw pkt-sec-cond-ipv4-ipopts? boolean 561 | | | +--rw pkt-sec-cond-ipv4-sameip? boolean 562 | | | +--rw pkt-sec-cond-ipv4-geoip? boolean 563 | | +--rw packet-security-ipv6-condition 564 | | | +--rw pkt-sec-cond-ipv6-dscp? boolean 565 | | | +--rw pkt-sec-cond-ipv6-ecn? boolean 566 | | | +--rw pkt-sec-cond-ipv6-traffic-class? boolean 567 | | | +--rw pkt-sec-cond-ipv6-flow-label? boolean 568 | | | +--rw pkt-sec-cond-ipv6-payload-length? boolean 569 | | | +--rw pkt-sec-cond-ipv6-next-header? boolean 570 | | | +--rw pkt-sec-cond-ipv6-hop-limit? boolean 571 | | | +--rw pkt-sec-cond-ipv6-src? boolean 572 | | | +--rw pkt-sec-cond-ipv6-dest? boolean 573 | | +--rw packet-security-tcp-condition 574 | | | +--rw pkt-sec-cond-tcp-src-port? boolean 575 | | | +--rw pkt-sec-cond-tcp-dest-port? boolean 576 | | | +--rw pkt-sec-cond-tcp-seq-num? boolean 577 | | | +--rw pkt-sec-cond-tcp-ack-num? boolean 578 | | | +--rw pkt-sec-cond-tcp-window-size? boolean 579 | | | +--rw pkt-sec-cond-tcp-flags? boolean 580 | | +--rw packet-security-udp-condition 581 | | | +--rw pkt-sec-cond-udp-src-port? boolean 582 | | | +--rw pkt-sec-cond-udp-dest-port? boolean 583 | | | +--rw pkt-sec-cond-udp-length? boolean 584 | | +--rw packet-security-icmp-condition 585 | | +--rw pkt-sec-cond-icmp-type? boolean 586 | | +--rw pkt-sec-cond-icmp-code? boolean 587 | | +--rw pkt-sec-cond-icmp-seg-num? boolean 588 | +--:(packet-payload-condition) 589 | | +--rw packet-payload-manual? string 590 | | +--rw pkt-payload-content? boolean 591 | +--:(target-condition) 592 | | +--rw target-manual? string 593 | | +--rw device-sec-context-cond? boolean 594 | +--:(users-condition) 595 | | +--rw users-manual? string 596 | | +--rw user 597 | | | +--rw (user-name)? 598 | | | +--:(tenant) 599 | | | | +--rw tenant? boolean 600 | | | +--:(vn-id) 601 | | | +--rw vn-id? boolean 602 | | +--rw group 603 | | +--rw (group-name)? 604 | | +--:(tenant) 605 | | | +--rw tenant? boolean 606 | | +--:(vn-id) 607 | | +--rw vn-id? boolean 608 | +--:(context-condition) 609 | | +--rw context-manual? string 610 | +--:(gen-context-condition) 611 | +--rw gen-context-manual? string 612 | +--rw geographic-location 613 | +--rw src-geographic-location? boolean 614 | +--rw dest-geographic-location? boolean 615 +--rw action 616 | ... 617 +--rw resolution-strategy 618 | ... 619 +--rw default-action 620 ... 622 Figure 5: Data Model Structure for Condition Capabilities of Network 623 Security Function 625 These objects are defined as capabilities of packet security 626 condition, packet payload security condition, target security 627 condition, user security condition, context condition, and generic 628 context condition. These objects can be extended according to 629 specific vendor condition features. We will add additional condition 630 objects for more generic network security functions. 632 6.2.3. Action Capabilities 634 The data model for action capabilities has the following structure: 636 +--rw i2nsf-net-sec-caps 637 +--rw net-sec-capabilities* [nsc-capabilities-name] 638 +--rw nsc-capabilities-name string 639 +--rw rule-description? boolean 640 +--rw rule-rev? boolean 641 +--rw rule-priority? boolean 642 +--rw time 643 | +--rw time-zone 644 | | +--rw time-zone-offset boolean 645 | +--rw time-interval 646 | +--rw absolute-time-interval 647 | | +--rw start-time? boolean 648 | | +--rw end-time? boolean 649 | +--rw periodic-time-interval 650 | +--rw day? boolean 651 | +--rw month? boolean 652 +--rw event 653 | ... 654 +--rw condition 655 | ... 656 +--rw action 657 | +--rw (action-type)? 658 | +--:(ingress-action) 659 | | +--rw ingress-manual? string 660 | | +--rw ingress-action-type 661 | | +--rw pass? boolean 662 | | +--rw drop? boolean 663 | | +--rw reject? boolean 664 | | +--rw alert? boolean 665 | | +--rw mirror? boolean 666 | +--:(egress-action) 667 | +--rw egress-manual? string 668 | +--rw egress-action-type 669 | +--rw invoke-signaling? boolean 670 | +--rw tunnel-encapsulation? boolean 671 | +--rw forwarding? boolean 672 | +--rw redirection? boolean 673 +--rw resolution-strategy 674 | ... 675 +--rw default-action 676 ... 678 Figure 6: Data Model Structure for Action Capabilities of Network 679 Security Function 681 These objects are defined capabilities as ingress action, egress 682 action, and apply profile action. These objects can be extended 683 according to specific vendor action feature. We will add additional 684 action objects for more generic network security functions. 686 6.2.4. Resolution Strategy Capabilities 688 The data model for resolution strategy capabilities has the following 689 structure: 691 +--rw i2nsf-net-sec-caps 692 +--rw net-sec-capabilities* [nsc-capabilities-name] 693 +--rw nsc-capabilities-name string 694 +--rw rule-description? boolean 695 +--rw rule-rev? boolean 696 +--rw rule-priority? boolean 697 +--rw time 698 | +--rw time-zone 699 | | +--rw time-zone-offset boolean 700 | +--rw time-interval 701 | +--rw absolute-time-interval 702 | | +--rw start-time? boolean 703 | | +--rw end-time? boolean 704 | +--rw periodic-time-interval 705 | +--rw day? boolean 706 | +--rw month? boolean 707 +--rw event 708 | ... 709 +--rw condition 710 | ... 711 +--rw action 712 | ... 713 +--rw resolution-strategy 714 | +--rw first-matching-rule? boolean 715 | +--rw last-matching-rule? boolean 716 +--rw default-action 717 ... 719 Figure 7: Data Model Structure for Resolution Strategy Capabilities 720 of Network Security Function 722 These objects are defined capabilities as first-matching-rule and 723 last-matching-rule. These objects can be extended according to 724 specific vendor resolution strategy features. We will add additional 725 resolution strategy objects for more generic network security 726 functions. 728 6.2.5. Default Action Capabilities 730 The data model for default action capabilities has the following 731 structure: 733 +--rw i2nsf-net-sec-caps 734 +--rw net-sec-capabilities* [nsc-capabilities-name] 735 +--rw nsc-capabilities-name string 736 +--rw rule-description? boolean 737 +--rw rule-rev? boolean 738 +--rw rule-priority? boolean 739 +--rw time 740 | +--rw time-zone 741 | | +--rw time-zone-offset boolean 742 | +--rw time-interval 743 | +--rw absolute-time-interval 744 | | +--rw start-time? boolean 745 | | +--rw end-time? boolean 746 | +--rw periodic-time-interval 747 | +--rw day? boolean 748 | +--rw month? boolean 749 +--rw event 750 | ... 751 +--rw condition 752 | ... 753 +--rw action 754 | ... 755 +--rw resolution-strategy 756 | ... 757 +--rw default-action 758 +--rw default-action-type 759 +--rw ingress-action-type 760 +--rw pass? boolean 761 +--rw drop? boolean 762 +--rw reject? boolean 763 +--rw alert? boolean 764 +--rw mirror? boolean 766 Figure 8: Data Model Structure for Default Action Capabilities of 767 Network Security Function 769 6.2.6. RPC for Acquiring Appropriate Network Security Function 771 The data model for RPC for Acquiring Appropriate Network Security 772 Function has the following structure: 774 rpcs: 775 +---x call-appropriate-nsf 776 +---w input 777 | +---w nsf-type nsf-type 778 | +---w target-device 779 | +---w pc? boolean 780 | +---w mobile-phone? boolean 781 | +---w voip-volte-phone? boolean 782 | +---w tablet? boolean 783 | +---w iot? boolean 784 | +---w vehicle? boolean 785 +--ro output 786 +--ro nsf-address 787 +--ro (nsf-address-type)? 788 +--:(ipv4-address) 789 | +--ro ipv4-address inet:ipv4-address 790 +--:(ipv6-address) 791 +--ro ipv6-address inet:ipv6-address 793 Figure 9: RPC for Acquiring Appropriate Network Security Function 795 This shows a RPC for acquiring an appropriate network security 796 function according to type of NSF and/or target devices. If the SFF 797 [i2nsf-sfc]does not have the location information of network security 798 functions that it should send in own cache table, this can be used to 799 acquire the information. These objects are defined as input data 800 (i.e., NSF type and target devices) and output data (i.e., location 801 information of NSF). 803 7. YANG Modules 805 7.1. I2NSF Capability YANG Data Module 807 This section introduces a YANG module for the information model of 808 network security functions, as defined in the [i2nsf-nsf-cap-im]. 810 file "ietf-i2nsf-capability@2018-03-23.yang" 812 module ietf-i2nsf-capability { 813 namespace 814 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; 815 prefix 816 i2nsf-capability; 818 import ietf-inet-types{ 819 prefix inet; 820 } 821 organization 822 "IETF I2NSF (Interface to Network Security Functions) 823 Working Group"; 825 contact 826 "WG Web: 827 WG List: 829 WG Chair: Adrian Farrel 830 832 WG Chair: Linda Dunbar 833 835 Editor: Susan Hares 836 838 Editor: Jaehoon Paul Jeong 839 841 Editor: Jinyong Tim Kim 842 "; 844 description 845 "This module describes a capability model 846 for I2NSF devices."; 848 revision "2018-03-23"{ 849 description "The fifth revision"; 850 reference 851 "draft-ietf-i2nsf-capability-00"; 852 } 854 grouping i2nsf-nsf-location { 855 description 856 "This provides a location for capabilities."; 857 container nsf-address { 858 description 859 "This is location information for capabilities."; 860 choice nsf-address-type { 861 description 862 "nsf address type: ipv4 and ipv4"; 863 case ipv4-address { 864 description 865 "ipv4 case"; 866 leaf ipv4-address { 867 type inet:ipv4-address; 868 mandatory true; 869 description 870 "nsf address type is ipv4"; 871 } 872 } 873 case ipv6-address { 874 description 875 "ipv6 case"; 876 leaf ipv6-address { 877 type inet:ipv6-address; 878 mandatory true; 879 description 880 "nsf address type is ipv6"; 881 } 882 } 883 } 884 } 885 } 887 typedef nsf-type { 888 type enumeration { 889 enum network-firewall { 890 description 891 "If type of a NSF is Network Firewall."; 892 } 894 enum web-app-firewall { 895 description 896 "If type of a NSF is Web Application 897 Firewall."; 898 } 900 enum anti-virus { 901 description 902 "If type of a NSF is Anti-Virus"; 903 } 905 enum ids { 906 description 907 "If type of a NSF is IDS."; 908 } 910 enum ips { 911 description 912 "If type of a NSF is IPS."; 913 } 914 enum ddos-mitigator { 915 description 916 "If type of a NSF is DDoS Mitigator."; 917 } 918 } 919 description 920 "This is used for type of NSF."; 921 } 923 grouping i2nsf-it-resources { 924 description 925 "This provides a link between capabilities 926 and IT resources. This has a list of IT resources 927 by name."; 928 container target-device { 929 description 930 "it-resources"; 932 leaf pc { 933 type boolean; 934 description 935 "If type of a device is PC."; 936 } 938 leaf mobile-phone { 939 type boolean; 940 description 941 "If type of a device is mobile-phone."; 942 } 944 leaf voip-volte-phone { 945 type boolean; 946 description 947 "If type of a device is voip-volte-phone."; 948 } 950 leaf tablet { 951 type boolean; 952 description 953 "If type of a device is tablet."; 954 } 956 leaf iot { 957 type boolean; 958 description 959 "If type of a device is Internet of Things."; 960 } 961 leaf vehicle { 962 type boolean; 963 description 964 "If type of a device is vehicle."; 965 } 967 } 968 } 970 grouping capabilities-information { 971 description 972 "This includes information of capabilities."; 974 leaf nsf-type { 975 type nsf-type; 976 description 977 "This is type of NSF."; 978 } 979 uses i2nsf-nsf-location; 980 uses i2nsf-it-resources; 981 } 983 grouping i2nsf-net-sec-caps { 984 description 985 "i2nsf-net-sec-caps"; 986 list net-sec-capabilities { 987 key "nsc-capabilities-name"; 988 description 989 "net-sec-capabilities"; 990 leaf nsc-capabilities-name { 991 type string; 992 mandatory true; 993 description 994 "nsc-capabilities-name"; 995 } 997 leaf rule-description { 998 type boolean; 999 description 1000 "This is rule-description."; 1001 } 1002 leaf rule-rev { 1003 type boolean; 1004 description 1005 "This is rule-revision"; 1006 } 1007 leaf rule-priority { 1008 type boolean; 1009 description 1010 "This is rule-priority"; 1011 } 1013 container time { 1014 description 1015 "This is capabilities for time"; 1016 container time-zone { 1017 description 1018 "This can be used to apply rules 1019 according to time zone"; 1021 leaf time-zone-offset { 1022 type boolean; 1023 description 1024 "This is offset for UTC time zone"; 1025 } 1027 } 1029 container time-inteval { 1030 description 1031 "This can be used to apply rules 1032 according to time inteval"; 1033 container absolute-time-inteval { 1034 description 1035 "This can be used to apply rules according to 1036 absolute time inteval"; 1037 leaf start-time { 1038 type boolean; 1039 description 1040 "This is start time for absolute time inteval"; 1041 } 1042 leaf end-time { 1043 type boolean; 1044 description 1045 "This is end time for absolute time inteval"; 1046 } 1047 } 1048 container periodic-time-inteval { 1049 description 1050 "This can be used to apply rules according to 1051 periodic time inteval"; 1052 leaf day { 1053 type boolean; 1054 description 1055 "This is day for periodic time inteval"; 1056 } 1057 leaf month { 1058 type boolean; 1059 description 1060 "This is month for periodic time inteval"; 1061 } 1062 } 1063 } 1064 } 1066 container event { 1067 description 1068 " This is abstract. An event is defined as any important 1069 occurrence in time of a change in the system being 1070 managed, and/or in the environment of the system being 1071 managed. When used in the context of policy rules for 1072 a flow-based NSF, it is used to determine whether the 1073 Condition clause of the Policy Rule can be evaluated 1074 or not. Examples of an I2NSF event include time and 1075 user actions (e.g., logon, logoff, and actions that 1076 violate any ACL.)."; 1078 choice event-type { 1079 description 1080 "Vendors can use YANG data model to configure rules 1081 by concreting this event type"; 1082 case usr-event { 1083 leaf usr-manual { 1084 type string; 1085 description 1086 "This is manual for user event. 1087 Vendors can write instructions for user event 1088 that vendor made"; 1089 } 1091 leaf usr-sec-event-content { 1092 type boolean; 1093 description 1094 "This is a mandatory string that contains the content 1095 of the UserSecurityEvent. The format of the content 1096 is specified in the usrSecEventFormat class 1097 attribute, and the type of event is defined in the 1098 usrSecEventType class attribute. An example of the 1099 usrSecEventContent attribute is a string hrAdmin, 1100 with the usrSecEventFormat set to 1 (GUID) and the 1101 usrSecEventType attribute set to 5 (new logon)."; 1102 } 1103 container usr-sec-event-format { 1104 description 1105 "This is a mandatory uint 8 enumerated integer, which 1106 is used to specify the data type of the 1107 usrSecEventContent attribute. The content is 1108 specified in the usrSecEventContent class attribute, 1109 and the type of event is defined in the 1110 usrSecEventType class attribute. An example of the 1111 usrSecEventContent attribute is string hrAdmin, 1112 with the usrSecEventFormat attribute set to 1 (GUID) 1113 and the usrSecEventType attribute set to 5 1114 (new logon)."; 1115 leaf unknown { 1116 type boolean; 1117 description 1118 "If SecEventFormat is unknown"; 1119 } 1120 leaf guid { 1121 type boolean; 1122 description 1123 "If SecEventFormat is GUID 1124 (Generic Unique IDentifier)"; 1125 } 1126 leaf uuid { 1127 type boolean; 1128 description 1129 "If SecEventFormat is UUID 1130 (Universal Unique IDentifier)"; 1131 } 1132 leaf uri { 1133 type boolean; 1134 description 1135 "If SecEventFormat is URI 1136 (Uniform Resource Identifier)"; 1137 } 1138 leaf fqdn { 1139 type boolean; 1140 description 1141 "If SecEventFormat is FQDN 1142 (Fully Qualified Domain Name)"; 1143 } 1144 leaf fqpn { 1145 type boolean; 1146 description 1147 "If SecEventFormat is FQPN 1148 (Fully Qualified Path Name)"; 1149 } 1150 } 1151 container usr-sec-event-type { 1152 leaf unknown { 1153 type boolean; 1154 description 1155 "If usrSecEventType is unknown"; 1156 } 1157 leaf user-created { 1158 type boolean; 1159 description 1160 "If usrSecEventType is new user 1161 created"; 1162 } 1163 leaf user-grp-created { 1164 type boolean; 1165 description 1166 "If usrSecEventType is new user 1167 group created"; 1168 } 1169 leaf user-deleted { 1170 type boolean; 1171 description 1172 "If usrSecEventType is user 1173 deleted"; 1174 } 1175 leaf user-grp-deleted { 1176 type boolean; 1177 description 1178 "If usrSecEventType is user 1179 group deleted"; 1180 } 1181 leaf user-logon { 1182 type boolean; 1183 description 1184 "If usrSecEventType is user 1185 logon"; 1186 } 1187 leaf user-logoff { 1188 type boolean; 1189 description 1190 "If usrSecEventType is user 1191 logoff"; 1192 } 1193 leaf user-access-request { 1194 type boolean; 1195 description 1196 "If usrSecEventType is user 1197 access request"; 1198 } 1199 leaf user-access-granted { 1200 type boolean; 1201 description 1202 "If usrSecEventType is user 1203 granted"; 1204 } 1205 leaf user-access-violation { 1206 type boolean; 1207 description 1208 "If usrSecEventType is user 1209 violation"; 1210 } 1211 description 1212 "This is a mandatory uint 8 enumerated integer, which 1213 is used to specify the type of event that involves 1214 this user. The content and format are specified in 1215 the usrSecEventContent and usrSecEventFormat class 1216 attributes, respectively. An example of the 1217 usrSecEventContent attribute is string hrAdmin, 1218 with the usrSecEventFormat attribute set to 1 (GUID) 1219 and the usrSecEventType attribute set to 5 1220 (new logon)."; 1221 } 1223 } 1224 case dev-event { 1225 leaf dev-manual { 1226 type string; 1227 description 1228 "This is manual for device event. 1229 Vendors can write instructions for device event 1230 that vendor made"; 1231 } 1233 leaf dev-sec-event-content { 1234 type boolean; 1235 mandatory true; 1236 description 1237 "This is a mandatory string that contains the content 1238 of the DeviceSecurityEvent. The format of the 1239 content is specified in the devSecEventFormat class 1240 attribute, and the type of event is defined in the 1241 devSecEventType class attribute. An example of the 1242 devSecEventContent attribute is alarm, with the 1243 devSecEventFormat attribute set to 1 (GUID), the 1244 devSecEventType attribute set to 5 (new logon)."; 1245 } 1246 container dev-sec-event-format { 1247 description 1248 "This is a mandatory uint 8 enumerated integer, 1249 which is used to specify the data type of the 1250 devSecEventContent attribute."; 1252 leaf unknown { 1253 type boolean; 1254 description 1255 "If SecEventFormat is unknown"; 1256 } 1257 leaf guid { 1258 type boolean; 1259 description 1260 "If SecEventFormat is GUID 1261 (Generic Unique IDentifier)"; 1262 } 1263 leaf uuid { 1264 type boolean; 1265 description 1266 "If SecEventFormat is UUID 1267 (Universal Unique IDentifier)"; 1268 } 1269 leaf uri { 1270 type boolean; 1271 description 1272 "If SecEventFormat is URI 1273 (Uniform Resource Identifier)"; 1274 } 1275 leaf fqdn { 1276 type boolean; 1277 description 1278 "If SecEventFormat is FQDN 1279 (Fully Qualified Domain Name)"; 1280 } 1281 leaf fqpn { 1282 type boolean; 1283 description 1284 "If SecEventFormat is FQPN 1285 (Fully Qualified Path Name)"; 1286 } 1287 } 1289 container dev-sec-event-type { 1290 description 1291 "This is a mandatory uint 8 enumerated integer, 1292 which is used to specify the type of event 1293 that was generated by this device."; 1295 leaf unknown { 1296 type boolean; 1297 description 1298 "If devSecEventType is unknown"; 1299 } 1300 leaf comm-alarm { 1301 type boolean; 1302 description 1303 "If devSecEventType is communications 1304 alarm"; 1305 } 1306 leaf quality-of-service-alarm { 1307 type boolean; 1308 description 1309 "If devSecEventType is quality of service 1310 alarm"; 1311 } 1312 leaf process-err-alarm { 1313 type boolean; 1314 description 1315 "If devSecEventType is processing error 1316 alarm"; 1317 } 1318 leaf equipment-err-alarm { 1319 type boolean; 1320 description 1321 "If devSecEventType is equipment error 1322 alarm"; 1323 } 1324 leaf environmental-err-alarm { 1325 type boolean; 1326 description 1327 "If devSecEventType is environmental error 1328 alarm"; 1329 } 1331 } 1333 container dev-sec-event-type-severity { 1334 description 1335 "This is a mandatory uint 8 enumerated integer, 1336 which is used to specify the perceived 1337 severity of the event generated by this 1338 Device."; 1340 leaf unknown { 1341 type boolean; 1342 description 1343 "If devSecEventType is unknown"; 1344 } 1345 leaf cleared { 1346 type boolean; 1347 description 1348 "If devSecEventTypeSeverity is cleared"; 1349 } 1350 leaf indeterminate { 1351 type boolean; 1352 description 1353 "If devSecEventTypeSeverity is 1354 indeterminate"; 1355 } 1356 leaf critical { 1357 type boolean; 1358 description 1359 "If devSecEventTypeSeverity is critical"; 1360 } 1361 leaf major{ 1362 type boolean; 1363 description 1364 "If devSecEventTypeSeverity is major"; 1365 } 1366 leaf minor { 1367 type boolean; 1368 description 1369 "If devSecEventTypeSeverity is minor"; 1370 } 1371 leaf warning { 1372 type boolean; 1373 description 1374 "If devSecEventTypeSeverity is warning"; 1375 } 1376 } 1377 } 1378 case sys-event { 1379 leaf sys-manual { 1380 type string; 1381 description 1382 "This is manual for system event. 1383 Vendors can write instructions for system event 1384 that vendor made"; 1385 } 1387 leaf sys-sec-event-content { 1388 type boolean; 1389 description 1390 "This is a mandatory string that contains a content 1391 of the SystemSecurityEvent. The format of a content 1392 is specified in a sysSecEventFormat class attribute, 1393 and the type of event is defined in the 1394 sysSecEventType class attribute. An example of the 1395 sysSecEventContent attribute is string sysadmin3, 1396 with the sysSecEventFormat attribute set to 1(GUID), 1397 and the sysSecEventType attribute set to 2 1398 (audit log cleared)."; 1399 } 1401 container sys-sec-event-format { 1402 description 1403 "This is a mandatory uint 8 enumerated integer, which 1404 is used to specify the data type of the 1405 sysSecEventContent attribute."; 1407 leaf unknown { 1408 type boolean; 1409 description 1410 "If SecEventFormat is unknown"; 1411 } 1412 leaf guid { 1413 type boolean; 1414 description 1415 "If SecEventFormat is GUID 1416 (Generic Unique IDentifier)"; 1417 } 1418 leaf uuid { 1419 type boolean; 1420 description 1421 "If SecEventFormat is UUID 1422 (Universal Unique IDentifier)"; 1423 } 1424 leaf uri { 1425 type boolean; 1426 description 1427 "If SecEventFormat is URI 1428 (Uniform Resource Identifier)"; 1429 } 1430 leaf fqdn { 1431 type boolean; 1432 description 1433 "If SecEventFormat is FQDN 1434 (Fully Qualified Domain Name)"; 1435 } 1436 leaf fqpn { 1437 type boolean; 1438 description 1439 "If SecEventFormat is FQPN 1440 (Fully Qualified Path Name)"; 1441 } 1442 } 1444 container sys-sec-event-type { 1445 description 1446 "This is a mandatory uint 8 enumerated integer, which 1447 is used to specify the type of event that involves 1448 this device."; 1450 leaf unknown { 1451 type boolean; 1452 description 1453 "If sysSecEventType is unknown"; 1454 } 1455 leaf audit-log-written-to { 1456 type boolean; 1457 description 1458 "If sysSecEventTypeSeverity 1459 is that audit log is written to"; 1460 } 1461 leaf audit-log-cleared { 1462 type boolean; 1463 description 1464 "If sysSecEventTypeSeverity 1465 is that audit log is cleared"; 1466 } 1467 leaf policy-created { 1468 type boolean; 1469 description 1470 "If sysSecEventTypeSeverity 1471 is that policy is created"; 1472 } 1473 leaf policy-edited{ 1474 type boolean; 1475 description 1476 "If sysSecEventTypeSeverity 1477 is that policy is edited"; 1478 } 1479 leaf policy-deleted{ 1480 type boolean; 1481 description 1482 "If sysSecEventTypeSeverity 1483 is that policy is deleted"; 1484 } 1485 leaf policy-executed{ 1486 type boolean; 1487 description 1488 "If sysSecEventTypeSeverity 1489 is that policy is executed"; 1490 } 1491 } 1492 } 1493 case time-event { 1494 leaf time-manual { 1495 type string; 1496 description 1497 "This is manual for time event. 1498 Vendors can write instructions for time event 1499 that vendor made"; 1500 } 1501 leaf time-sec-event-begin { 1502 type boolean; 1503 description 1504 "This is a mandatory DateTime attribute, and 1505 represents the beginning of a time period. 1506 It has a value that has a date and/or a time 1507 component (as in the Java or Python libraries)."; 1508 } 1510 leaf time-sec-event-end { 1511 type boolean; 1512 description 1513 "This is a mandatory DateTime attribute, and 1514 represents the end of a time period. It has 1515 a value that has a date and/or a time component 1516 (as in the Java or Python libraries). If this is 1517 a single event occurrence, and not a time period 1518 when the event can occur, then the 1519 timeSecEventPeriodEnd attribute may be ignored."; 1520 } 1522 leaf time-sec-event-time-zone { 1523 type boolean; 1524 description 1525 "This is a mandatory string attribute, and defines a 1526 time zone that this event occurred in using the 1527 format specified in ISO8601."; 1528 } 1529 } 1530 } 1531 } 1533 container condition { 1534 description 1535 " This is abstract. A condition is defined as a set 1536 of attributes, features, and/or values that are to be 1537 compared with a set of known attributes, features, 1538 and/or values in order to determine whether or not the 1539 set of Actions in that (imperative) I2NSF Policy Rule 1540 can be executed or not. Examples of I2NSF Conditions 1541 include matching attributes of a packet or flow, and 1542 comparing the internal state of an NSF to a desired state."; 1544 choice condition-type { 1545 description 1546 "Vendors can use YANG data model to configure rules 1547 by concreting this condition type"; 1549 case packet-security-condition { 1550 leaf packet-manual { 1551 type string; 1552 description 1553 "This is manual for packet condition. 1554 Vendors can write instructions for packet condition 1555 that vendor made"; 1556 } 1558 container packet-security-mac-condition { 1559 description 1560 "The purpose of this Class is to represent packet MAC 1561 packet header information that can be used as part of 1562 a test to determine if the set of Policy Actions in 1563 this ECA Policy Rule should be execute or not."; 1565 leaf pkt-sec-cond-mac-dest { 1566 type boolean; 1567 description 1568 "The MAC destination address (6 octets long)."; 1569 } 1571 leaf pkt-sec-cond-mac-src { 1572 type boolean; 1573 description 1574 "The MAC source address (6 octets long)."; 1575 } 1577 leaf pkt-sec-cond-mac-8021q { 1578 type boolean; 1579 description 1580 "This is an optional string attribute, and defines 1581 The 802.1Q tab value (2 octets long)."; 1582 } 1583 leaf pkt-sec-cond-mac-ether-type { 1584 type boolean; 1585 description 1586 "The EtherType field (2 octets long). Values up to 1587 and including 1500 indicate the size of the payload 1588 in octets; values of 1536 and above define which 1589 protocol is encapsulated in the payload of the 1590 frame."; 1591 } 1593 leaf pkt-sec-cond-mac-tci { 1594 type string; 1595 description 1596 "This is an optional string attribute, and defines 1597 the Tag Control Information. This consists of a 3 1598 bit user priority field, a drop eligible indicator 1599 (1 bit), and a VLAN identifier (12 bits)."; 1600 } 1601 } 1603 container packet-security-ipv4-condition { 1604 description 1605 "The purpose of this Class is to represent packet IPv4 1606 packet header information that can be used as part of 1607 a test to determine if the set of Policy Actions in 1608 this ECA Policy Rule should be executed or not."; 1610 leaf pkt-sec-cond-ipv4-header-length { 1611 type boolean; 1612 description 1613 "The IPv4 packet header consists of 14 fields, 1614 of which 13 are required."; 1615 } 1617 leaf pkt-sec-cond-ipv4-tos { 1618 type boolean; 1619 description 1620 "The ToS field could specify a datagram's priority 1621 and request a route for low-delay, high-throughput, 1622 or highly-reliable service.."; 1623 } 1625 leaf pkt-sec-cond-ipv4-total-length { 1626 type boolean; 1627 description 1628 "This 16-bit field defines the entire packet size, 1629 including header and data, in bytes."; 1630 } 1631 leaf pkt-sec-cond-ipv4-id { 1632 type boolean; 1633 description 1634 "This field is an identification field and is 1635 primarily used for uniquely identifying 1636 the group of fragments of a single IP datagram."; 1637 } 1639 leaf pkt-sec-cond-ipv4-fragment { 1640 type boolean; 1641 description 1642 "IP fragmentation is an Internet Protocol (IP) 1643 process that breaks datagrams into smaller pieces 1644 (fragments), so that packets may be formed that 1645 can pass through a link with a smaller maximum 1646 transmission unit (MTU) than the original 1647 datagram size."; 1648 } 1650 leaf pkt-sec-cond-ipv4-fragment-offset { 1651 type boolean; 1652 description 1653 "Fragment offset field along with Don't Fragment 1654 and More Fragment flags in the IP protocol 1655 header are used for fragmentation and reassembly 1656 of IP datagrams."; 1657 } 1659 leaf pkt-sec-cond-ipv4-ttl { 1660 type boolean; 1661 description 1662 "The ttl keyword is used to check for a specific 1663 IP time-to-live value in the header of 1664 a packet."; 1665 } 1667 leaf pkt-sec-cond-ipv4-protocol { 1668 type boolean; 1669 description 1670 "Internet Protocol version 4(IPv4) is the fourth 1671 version of the Internet Protocol (IP)."; 1672 } 1674 leaf pkt-sec-cond-ipv4-src { 1675 type boolean; 1676 description 1677 "Defines the IPv4 Source Address."; 1678 } 1679 leaf pkt-sec-cond-ipv4-dest { 1680 type boolean; 1681 description 1682 "Defines the IPv4 Destination Address."; 1683 } 1685 leaf pkt-sec-cond-ipv4-ipopts { 1686 type boolean; 1687 description 1688 "With the ipopts keyword you can check if 1689 a specific ip option is set. Ipopts has 1690 to be used at the beginning of a rule."; 1691 } 1693 leaf pkt-sec-cond-ipv4-sameip { 1694 type boolean; 1695 description 1696 "Every packet has a source IP-address and 1697 a destination IP-address. It can be that 1698 the source IP is the same as 1699 the destination IP."; 1700 } 1702 leaf pkt-sec-cond-ipv4-geoip { 1703 type boolean; 1704 description 1705 "The geoip keyword enables you to match on 1706 the source, destination or source and destination 1707 IP addresses of network traffic and to see to 1708 which country it belongs. To do this, Suricata 1709 uses GeoIP API with MaxMind database format."; 1710 } 1711 } 1713 container packet-security-ipv6-condition { 1714 description 1715 "The purpose of this Class is to represent packet 1716 IPv6 packet header information that can be used as 1717 part of a test to determine if the set of Policy 1718 Actions in this ECA Policy Rule should be executed 1719 or not."; 1721 leaf pkt-sec-cond-ipv6-dscp { 1722 type boolean; 1723 description 1724 "Differentiated Services Code Point (DSCP) 1725 of ipv6."; 1726 } 1727 leaf pkt-sec-cond-ipv6-ecn { 1728 type boolean; 1729 description 1730 "ECN allows end-to-end notification of network 1731 congestion without dropping packets."; 1732 } 1734 leaf pkt-sec-cond-ipv6-traffic-class { 1735 type boolean; 1736 description 1737 "The bits of this field hold two values. The 6 1738 most-significant bits are used for 1739 differentiated services, which is used to 1740 classify packets."; 1741 } 1743 leaf pkt-sec-cond-ipv6-flow-label { 1744 type boolean; 1745 description 1746 "The flow label when set to a non-zero value 1747 serves as a hint to routers and switches 1748 with multiple outbound paths that these 1749 packets should stay on the same path so that 1750 they will not be reordered."; 1751 } 1753 leaf pkt-sec-cond-ipv6-payload-length { 1754 type boolean; 1755 description 1756 "The size of the payload in octets, 1757 including any extension headers."; 1758 } 1760 leaf pkt-sec-cond-ipv6-next-header { 1761 type boolean; 1762 description 1763 "Specifies the type of the next header. 1764 This field usually specifies the transport 1765 layer protocol used by a packet's payload."; 1766 } 1768 leaf pkt-sec-cond-ipv6-hop-limit { 1769 type boolean; 1770 description 1771 "Replaces the time to live field of IPv4."; 1772 } 1774 leaf pkt-sec-cond-ipv6-src { 1775 type boolean; 1776 description 1777 "The IPv6 address of the sending node."; 1778 } 1780 leaf pkt-sec-cond-ipv6-dest { 1781 type boolean; 1782 description 1783 "The IPv6 address of the destination node(s)."; 1784 } 1785 } 1787 container packet-security-tcp-condition { 1788 description 1789 "The purpose of this Class is to represent packet 1790 TCP packet header information that can be used as 1791 part of a test to determine if the set of Policy 1792 Actions in this ECA Policy Rule should be executed 1793 or not."; 1795 leaf pkt-sec-cond-tcp-src-port { 1796 type boolean; 1797 description 1798 "This is a mandatory string attribute, and 1799 defines the Source Port number (16 bits)."; 1800 } 1802 leaf pkt-sec-cond-tcp-dest-port { 1803 type boolean; 1804 description 1805 "This is a mandatory string attribute, and 1806 defines the Destination Port number (16 bits)."; 1807 } 1809 leaf pkt-sec-cond-tcp-seq-num { 1810 type boolean; 1811 description 1812 "If the SYN flag is set (1), then this is the 1813 initial sequence number."; 1814 } 1816 leaf pkt-sec-cond-tcp-ack-num { 1817 type boolean; 1818 description 1819 "If the ACK flag is set then the value of this 1820 field is the next sequence number that the sender 1821 is expecting."; 1822 } 1823 leaf pkt-sec-cond-tcp-window-size { 1824 type boolean; 1825 description 1826 "The size of the receive window, which specifies 1827 the number of windows size units (by default,bytes) 1828 (beyond the segment identified by the sequence 1829 number in the acknowledgment field) that the sender 1830 of this segment is currently willing to recive."; 1831 } 1833 leaf pkt-sec-cond-tcp-flags { 1834 type boolean; 1835 description 1836 "This is a mandatory string attribute, and defines 1837 the nine Control bit flags (9 bits)."; 1838 } 1839 } 1841 container packet-security-udp-condition { 1842 description 1843 "The purpose of this Class is to represent packet UDP 1844 packet header information that can be used as part 1845 of a test to determine if the set of Policy Actions 1846 in this ECA Policy Rule should be executed or not."; 1848 leaf-list pkt-sec-cond-udp-src-port { 1849 type boolean; 1850 description 1851 "This is a mandatory string attribute, and 1852 defines the UDP Source Port number (16 bits)."; 1853 } 1855 leaf-list pkt-sec-cond-udp-dest-port { 1856 type boolean; 1857 description 1858 "This is a mandatory string attribute, and 1859 defines the UDP Destination Port number (16 bits)."; 1860 } 1862 leaf pkt-sec-cond-udp-length { 1863 type boolean; 1864 description 1865 "This is a mandatory string attribute, and defines 1866 the length in bytes of the UDP header and data 1867 (16 bits)."; 1868 } 1869 } 1870 container packet-security-icmp-condition { 1871 description 1872 "The internet control message protocol condition."; 1874 leaf pkt-sec-cond-icmp-type { 1875 type boolean; 1876 description 1877 "ICMP type, see Control messages."; 1878 } 1880 leaf pkt-sec-cond-icmp-code { 1881 type boolean; 1882 description 1883 "ICMP subtype, see Control messages."; 1884 } 1886 leaf pkt-sec-cond-icmp-seg-num { 1887 type boolean; 1888 description 1889 "The icmp Sequence Number."; 1890 } 1891 } 1892 } 1894 case packet-payload-condition { 1895 leaf packet-payload-manual { 1896 type string; 1897 description 1898 "This is manual for payload condition. 1899 Vendors can write instructions for payload condition 1900 that vendor made"; 1901 } 1902 leaf pkt-payload-content { 1903 type boolean; 1904 description 1905 "The content keyword is very important in 1906 signatures. Between the quotation marks you 1907 can write on what you would like the 1908 signature to match."; 1909 } 1910 } 1911 case target-condition { 1912 leaf target-manual { 1913 type string; 1914 description 1915 "This is manual for target condition. 1916 Vendors can write instructions for target condition 1917 that vendor made"; 1919 } 1921 leaf device-sec-context-cond { 1922 type boolean; 1923 description 1924 "The device attribute that can identify a device, 1925 including the device type (i.e., router, switch, 1926 pc, ios, or android) and the device's owner as 1927 well."; 1928 } 1929 } 1930 case users-condition { 1931 leaf users-manual { 1932 type string; 1933 description 1934 "This is manual for user condition. 1935 Vendors can write instructions for user condition 1936 that vendor made"; 1937 } 1939 container user{ 1940 description 1941 "The user (or user group) information with which 1942 network flow is associated: The user has many 1943 attributes such as name, id, password, type, 1944 authentication mode and so on. Name/id is often 1945 used in the security policy to identify the user. 1946 Besides, NSF is aware of the IP address of the 1947 user provided by a unified user management system 1948 via network. Based on name-address association, 1949 NSF is able to enforce the security functions 1950 over the given user (or user group)"; 1952 choice user-name { 1953 description 1954 "The name of the user. 1955 This must be unique."; 1957 case tenant { 1958 description 1959 "Tenant information."; 1961 leaf tenant { 1962 type boolean; 1963 description 1964 "User's tenant information."; 1965 } 1966 } 1967 case vn-id { 1968 description 1969 "VN-ID information."; 1971 leaf vn-id { 1972 type boolean; 1973 description 1974 "User's VN-ID information."; 1975 } 1976 } 1977 } 1978 } 1979 container group { 1980 description 1981 "The user (or user group) information with which 1982 network flow is associated: The user has many 1983 attributes such as name, id, password, type, 1984 authentication mode and so on. Name/id is often 1985 used in the security policy to identify the user. 1986 Besides, NSF is aware of the IP address of the 1987 user provided by a unified user management system 1988 via network. Based on name-address association, 1989 NSF is able to enforce the security functions 1990 over the given user (or user group)"; 1992 choice group-name { 1993 description 1994 "The name of the user. 1995 This must be unique."; 1997 case tenant { 1998 description 1999 "Tenant information."; 2001 leaf tenant { 2002 type boolean; 2003 description 2004 "User's tenant information."; 2005 } 2006 } 2008 case vn-id { 2009 description 2010 "VN-ID information."; 2012 leaf vn-id { 2013 type boolean; 2014 description 2015 "User's VN-ID information."; 2016 } 2017 } 2018 } 2019 } 2021 } 2022 case context-condition { 2023 leaf context-manual { 2024 type string; 2025 description 2026 "This is manual for context condition. 2027 Vendors can write instructions for context condition 2028 that vendor made"; 2029 } 2030 } 2031 case gen-context-condition { 2032 leaf gen-context-manual { 2033 type string; 2034 description 2035 "This is manual for generic context condition. 2036 Vendors can write instructions for generic context 2037 condition that vendor made"; 2038 } 2040 container geographic-location { 2041 description 2042 "The location where network traffic is associated 2043 with. The region can be the geographic location 2044 such as country, province, and city, 2045 as well as the logical network location such as 2046 IP address, network section, and network domain."; 2048 leaf src-geographic-location { 2049 type boolean; 2050 description 2051 "This is mapped to ip address. We can acquire 2052 source region through ip address stored the 2053 database."; 2054 } 2055 leaf dest-geographic-location { 2056 type boolean; 2057 description 2058 "This is mapped to ip address. We can acquire 2059 destination region through ip address stored 2060 the database."; 2061 } 2062 } 2064 } 2065 } 2066 } 2067 container action { 2068 description 2069 "An action is used to control and monitor aspects of 2070 flow-based NSFs when the event and condition clauses 2071 are satisfied. NSFs provide security functions by 2072 executing various Actions. Examples of I2NSF Actions 2073 include providing intrusion detection and/or protection, 2074 web and flow filtering, and deep packet inspection 2075 for packets and flows."; 2077 choice action-type { 2078 description 2079 "Vendors can use YANG data model to configure rules 2080 by concreting this action type"; 2081 case ingress-action { 2082 leaf ingress-manual { 2083 type string; 2084 description 2085 "This is manual for ingress action. 2086 Vendors can write instructions for ingress action 2087 that vendor made"; 2088 } 2089 container ingress-action-type { 2090 description 2091 "Ingress action type: permit, deny, and mirror."; 2092 leaf pass { 2093 type boolean; 2094 description 2095 "If ingress action is pass"; 2096 } 2097 leaf drop { 2098 type boolean; 2099 description 2100 "If ingress action is drop"; 2101 } 2102 leaf reject { 2103 type boolean; 2104 description 2105 "If ingress action is reject"; 2106 } 2107 leaf alert { 2108 type boolean; 2109 description 2110 "If ingress action is alert"; 2112 } 2113 leaf mirror { 2114 type boolean; 2115 description 2116 "If ingress action is mirror"; 2117 } 2118 } 2119 } 2120 case egress-action { 2121 leaf egress-manual { 2122 type string; 2123 description 2124 "This is manual for egress action. 2125 Vendors can write instructions for egress action 2126 that vendor made"; 2127 } 2128 container egress-action-type { 2129 description 2130 "Egress-action-type: invoke-signaling, 2131 tunnel-encapsulation, and forwarding."; 2132 leaf invoke-signaling { 2133 type boolean; 2134 description 2135 "If egress action is invoke signaling"; 2136 } 2137 leaf tunnel-encapsulation { 2138 type boolean; 2139 description 2140 "If egress action is tunnel encapsulation"; 2141 } 2142 leaf forwarding { 2143 type boolean; 2144 description 2145 "If egress action is forwarding"; 2146 } 2147 leaf redirection { 2148 type boolean; 2149 description 2150 "If egress action is redirection"; 2151 } 2152 } 2153 } 2154 } 2155 } 2156 container resolution-strategy { 2157 description 2158 "The resolution strategies can be used to 2159 specify how to resolve conflicts that occur between 2160 the actions of the same or different policy rules that 2161 are matched and contained in this particular NSF"; 2163 leaf first-matching-rule { 2164 type boolean; 2165 description 2166 "If the resolution strategy is first matching rule"; 2167 } 2169 leaf last-matching-rule { 2170 type boolean; 2171 description 2172 "If the resolution strategy is last matching rule"; 2173 } 2174 } 2175 container default-action { 2176 description 2177 "This default action can be used to specify a predefined 2178 action when no other alternative action was matched 2179 by the currently executing I2NSF Policy Rule. An analogy 2180 is the use of a default statement in a C switch statement."; 2182 container default-action-type { 2183 description 2184 "Ingress action type: permit, deny, and mirror."; 2186 container ingress-action-type { 2187 description 2188 "Ingress action type: permit, deny, and mirror."; 2189 leaf pass { 2190 type boolean; 2191 description 2192 "If ingress action is pass"; 2193 } 2194 leaf drop { 2195 type boolean; 2196 description 2197 "If ingress action is drop"; 2198 } 2199 leaf reject { 2200 type boolean; 2201 description 2202 "If ingress action is reject"; 2203 } 2204 leaf alert { 2205 type boolean; 2206 description 2207 "If ingress action is alert"; 2209 } 2210 leaf mirror { 2211 type boolean; 2212 description 2213 "If ingress action is mirror"; 2214 } 2215 } 2216 } 2217 } 2218 } 2219 } 2221 grouping i2nsf-con-sec-control-caps { 2222 description 2223 "i2nsf-con-sec-control-caps"; 2225 container con-sec-control-capabilities { 2226 description 2227 "content-security-control-capabilities"; 2229 leaf anti-virus { 2230 type boolean; 2231 description 2232 "antivirus"; 2233 } 2234 leaf ips { 2235 type boolean; 2236 description 2237 "ips"; 2238 } 2240 leaf ids { 2241 type boolean; 2242 description 2243 "ids"; 2244 } 2246 leaf url-filter { 2247 type boolean; 2248 description 2249 "url-filter"; 2250 } 2251 leaf data-filter { 2252 type boolean; 2253 description 2254 "data-filter"; 2255 } 2256 leaf mail-filter { 2257 type boolean; 2258 description 2259 "mail-filter"; 2260 } 2261 leaf sql-filter { 2262 type boolean; 2263 description 2264 "sql-filter"; 2265 } 2266 leaf file-blocking { 2267 type boolean; 2268 description 2269 "file-blocking"; 2270 } 2271 leaf file-isolate { 2272 type boolean; 2273 description 2274 "file-isolate"; 2275 } 2276 leaf pkt-capture { 2277 type boolean; 2278 description 2279 "pkt-capture"; 2280 } 2281 leaf application-behavior { 2282 type boolean; 2283 description 2284 "application-behavior"; 2285 } 2286 leaf voip-volte { 2287 type boolean; 2288 description 2289 "voip-volte"; 2290 } 2291 } 2293 } 2295 grouping i2nsf-attack-mitigation-control-caps { 2296 description 2297 "i2nsf-attack-mitigation-control-caps"; 2299 container attack-mitigation-capabilities { 2300 description 2301 "attack-mitigation-capabilities"; 2302 choice attack-mitigation-control-type { 2303 description 2304 "attack-mitigation-control-type"; 2305 case ddos-attack { 2306 description 2307 "ddos-attack"; 2308 choice ddos-attack-type { 2309 description 2310 "ddos-attack-type"; 2311 case network-layer-ddos-attack { 2312 description 2313 "network-layer-ddos-attack"; 2314 container network-layer-ddos-attack-types { 2315 description 2316 "network-layer-ddos-attack-type"; 2317 leaf syn-flood-attack { 2318 type boolean; 2319 description 2320 "syn-flood-attack"; 2321 } 2322 leaf udp-flood-attack { 2323 type boolean; 2324 description 2325 "udp-flood-attack"; 2326 } 2327 leaf icmp-flood-attack { 2328 type boolean; 2329 description 2330 "icmp-flood-attack"; 2331 } 2332 leaf ip-fragment-flood-attack { 2333 type boolean; 2334 description 2335 "ip-fragment-flood-attack"; 2336 } 2337 leaf ipv6-related-attack { 2338 type boolean; 2339 description 2340 "ip-fragment-flood-attack"; 2341 } 2342 } 2343 } 2344 case app-layer-ddos-attack { 2345 description 2346 "app-layer-ddos-attack"; 2347 container app-layer-ddos-attack-types { 2348 description 2349 "app-layer-ddos-attack-types"; 2350 leaf http-flood-attack { 2351 type boolean; 2352 description 2353 "http-flood-attack"; 2354 } 2355 leaf https-flood-attack { 2356 type boolean; 2357 description 2358 "https-flood-attack"; 2359 } 2360 leaf dns-flood-attack { 2361 type boolean; 2362 description 2363 "dns-flood-attack"; 2364 } 2365 leaf dns-amp-flood-attack { 2366 type boolean; 2367 description 2368 "dns-amp-flood-attack"; 2369 } 2370 leaf ssl-flood-attack { 2371 type boolean; 2372 description 2373 "ssl-flood-attack"; 2374 } 2375 } 2376 } 2377 } 2378 } 2380 case single-packet-attack { 2381 description 2382 "single-packet-attack"; 2383 choice single-packet-attack-type { 2384 description 2385 "single-packet-attack-type"; 2386 case scan-and-sniff-attack { 2387 description 2388 "scan-and-sniff-attack"; 2389 leaf ip-sweep-attack { 2390 type boolean; 2391 description 2392 "ip-sweep-attack"; 2393 } 2394 leaf port-scanning-attack { 2395 type boolean; 2396 description 2397 "port-scanning-attack"; 2398 } 2400 } 2401 case malformed-packet-attack { 2402 description 2403 "malformed-packet-attack"; 2404 leaf ping-of-death-attack { 2405 type boolean; 2406 description 2407 "ping-of-death-attack"; 2408 } 2409 leaf teardrop-attack { 2410 type boolean; 2411 description 2412 "teardrop-attack"; 2413 } 2414 } 2415 case special-packet-attack { 2416 description 2417 "special-packet-attack"; 2418 leaf oversized-icmp-attack { 2419 type boolean; 2420 description 2421 "oversized-icmp-attack"; 2422 } 2423 leaf tracert-attack { 2424 type boolean; 2425 description 2426 "tracert-attack"; 2427 } 2428 } 2429 } 2430 } 2431 } 2432 } 2433 } 2435 list nsf { 2436 key "nsf-name"; 2437 description 2438 "nsf-name"; 2439 leaf nsf-name { 2440 type string; 2441 mandatory true; 2442 description 2443 "nsf-name"; 2444 } 2445 uses capabilities-information; 2446 container generic-nsf-capabilities { 2447 description 2448 "generic-nsf-capabilities"; 2449 uses i2nsf-net-sec-caps; 2450 } 2451 } 2453 rpc call-appropriate-nsf { 2454 description 2455 "We can acquire appropriate NSF that we want 2456 If we give type of NSF that we want to use, 2457 we acquire the location information of NSF"; 2459 input { 2460 leaf nsf-type { 2461 type nsf-type; 2462 mandatory true; 2463 description 2464 "This is used to acquire NSF 2465 This is mandatory"; 2466 } 2467 uses i2nsf-it-resources; 2468 } 2469 output { 2470 uses i2nsf-nsf-location; 2471 } 2472 } 2473 } 2475 2477 Figure 10: YANG Data Module of I2NSF Capability 2479 8. IANA Considerations 2481 No IANA considerations exist for this document at this time. URL 2482 will be added. 2484 9. Security Considerations 2486 This document introduces no additional security threats and SHOULD 2487 follow the security requirements as stated in [RFC8329]. 2489 10. Acknowledgments 2491 This work was supported by Institute for Information & communications 2492 Technology Promotion (IITP) grant funded by the Korea government 2493 (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence 2494 Technology Development for the Customized Security Service 2495 Provisioning). 2497 11. Contributors 2499 I2NSF is a group effort. I2NSF has had a number of contributing 2500 authors. The following are considered co-authors: 2502 o Hyoungshick Kim (Sungkyunkwan University) 2504 o Daeyoung Hyun (Sungkyunkwan University) 2506 o Dongjin Hong (Sungkyunkwan University) 2508 o Liang Xia (Huawei) 2510 o Jung-Soo Park (ETRI) 2512 o Tae-Jin Ahn (Korea Telecom) 2514 o Se-Hui Lee (Korea Telecom) 2516 12. References 2518 12.1. Normative References 2520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2521 Requirement Levels", BCP 14, RFC 2119, March 1997. 2523 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 2524 Network Configuration Protocol (NETCONF)", RFC 6020, 2525 October 2010. 2527 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 2528 RFC 7950, August 2016. 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-01 (work in progress), April 2018. 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-ietf-i2nsf-nsf-facing-interface-dm-00 2550 (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-12 2568 (work in progress), April 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 Authors' Addresses 2776 Susan Hares 2777 Huawei 2778 7453 Hickory Hill 2779 Saline, MI 48176 2780 USA 2782 Phone: +1-734-604-0332 2783 EMail: shares@ndzh.com 2784 Jaehoon Paul Jeong 2785 Department of Software 2786 Sungkyunkwan University 2787 2066 Seobu-Ro, Jangan-Gu 2788 Suwon, Gyeonggi-Do 16419 2789 Republic of Korea 2791 Phone: +82 31 299 4957 2792 Fax: +82 31 290 7996 2793 EMail: pauljeong@skku.edu 2794 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2796 Jinyong Tim Kim 2797 Department of Computer Engineering 2798 Sungkyunkwan University 2799 2066 Seobu-Ro, Jangan-Gu 2800 Suwon, Gyeonggi-Do 16419 2801 Republic of Korea 2803 Phone: +82 10 8273 0930 2804 EMail: timkim@skku.edu 2806 Robert Moskowitz 2807 HTT Consulting 2808 Oak Park, MI 2809 USA 2811 Phone: +1-248-968-9809 2812 EMail: rgm@htt-consult.com 2814 Qiushi Lin 2815 Huawei 2816 Huawei Industrial Base 2817 Shenzhen, Guangdong 518129 2818 China 2820 EMail: linqiushi@huawei.com