idnits 2.17.1 draft-hares-i2nsf-capability-data-model-05.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 517 has weird spacing: '...es-name str...' == Line 621 has weird spacing: '...es-name str...' == (4 more instances...) -- The document date (October 30, 2017) is 2364 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 Summary: 1 error (**), 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: May 3, 2018 J. Kim 6 Sungkyunkwan University 7 R. Moskowitz 8 HTT Consulting 9 Q. Lin 10 Huawei 11 October 30, 2017 13 I2NSF Capability YANG Data Model 14 draft-hares-i2nsf-capability-data-model-05 16 Abstract 18 This document defines a YANG data model for capabilities that enables 19 an I2NSF user to control various network security functions in 20 network security devices. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 3, 2018. 39 Copyright Notice 41 Copyright (c) 2017 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. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 13 75 6.2.4. Resolution Strategy Capabilities . . . . . . . . . . 14 76 6.2.5. Default Action Capabilities . . . . . . . . . . . . . 15 77 6.2.6. RPC for Acquiring Appropriate Network Security 78 Function . . . . . . . . . . . . . . . . . . . . . . 16 79 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17 80 7.1. I2NSF Capability YANG Data Module . . . . . . . . . . . . 17 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 84 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 52 87 12.2. Informative References . . . . . . . . . . . . . . . . . 52 88 Appendix A. Example: Extended VoIP-VoLTE Security Function 89 Capabilities Module . . . . . . . . . . . . . . . . 54 90 Appendix B. Example: Configuration XML of Capability Module . . 55 91 B.1. Example: Configuration XML of Generic Network Security 92 Function Capabilities . . . . . . . . . . . . . . . . . . 55 93 B.2. Example: Configuration XML of Extended VoIP/VoLTE 94 Security Function Capabilities Module . . . . . . . . . . 57 95 Appendix C. draft-hares-i2nsf-capability-data-model-04 . . . . . 58 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 98 1. Introduction 100 As the industry becomes more sophisticated and network devices (i.e., 101 IoT, Intelligent Vehicle, and VoIP/VoLTE Phone), service providers 102 has a lot of problems [RFC8192]. To resolve this problem, 103 [i2nsf-nsf-cap-im] standardize capabilities of network security 104 functions. 106 This document provides a YANG data model that defines the 107 capabilities to express capabilities of security devices. The 108 security devices can register own capabilities to Network Operator 109 Mgmt System with this YANG data model through registration interface. 110 After the capabilities of the devices are registered, this YANG data 111 model can be used by the IN2SF user or Service Function Forwarder 112 (SFF) [i2nsf-sfc] to acquire appropriate NSFs that can be controlled 113 by the Network Operator Mgmt System. This document defines a YANG 114 [RFC6020] data model based on the [i2nsf-nsf-cap-im]. Terms used in 115 document are defined in [i2nsf-terminology]. 117 The "Event-Condition-Action" (ECA) policy model is used as the basis 118 for the design of I2NSF Policy Rules. 120 The "ietf-i2nsf-capability" YANG module defined in this document 121 provides the following features: 123 o Configuration of identification for generic network security 124 function policy 126 o Configuration of event capabilities for generic network security 127 function policy 129 o Configuration of condition capabilities for generic network 130 security function policy 132 o Configuration of action capabilities for generic network security 133 function policy 135 o Configuration of strategy capabilities for generic network 136 security function policy 138 o Configuration of default action capabilities for generic network 139 security function policy 141 o RPC for acquiring appropriate network security function according 142 to type of NSF and/or target devices. 144 2. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 3. Terminology 152 This document uses the terminology described in [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. Objectives 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 objects are defined as user security event capabilities, 286 device security event capabilities, system security event 287 capabilities, and time security event capabilities. These objects 288 can be extended according to specific vendor event features. 290 5.3. Condition Capabilities 292 This shows a condition capabilities for generic network security 293 functions policy. This is used to specify capabilities about a set 294 of attributes, features, and/or values that are to be compared with a 295 set of known attributes, features, and/or values in order to 296 determine whether or not the set of Actions in that (imperative) 297 I2NSF Policy Rule can be executed or not. These objects are defined 298 as user security event, device security event, system security event, 299 and time security event. These objects are defined as packet 300 security condition capabilities, packet payload security condition 301 capabilities, target security condition capabilities, user security 302 condition capabilities, context condition capabilities, and generic 303 context condition capabilities. These objects can be extended 304 according to 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 objects are defined as ingress action 313 capabilities, egress action capabilities, and apply profile action 314 capabilities. These objects can be extended according to specific 315 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 time-zone 416 | +--rw start-time? boolean 417 | +--rw end-time? boolean 418 +--rw rule-description? boolean 419 +--rw rule-rev? boolean 420 +--rw rule-priority? boolean 421 +--rw event 422 | +--rw (event-type)? 423 | +--:(usr-event) 424 | | +--rw usr-manual? string 425 | | +--rw usr-sec-event-content? boolean 426 | | +--rw usr-sec-event-format 427 | | | +--rw unknown? boolean 428 | | | +--rw guid? boolean 429 | | | +--rw uuid? boolean 430 | | | +--rw uri? boolean 431 | | | +--rw fqdn? boolean 432 | | | +--rw fqpn? boolean 433 | | +--rw usr-sec-event-type 434 | | +--rw unknown? boolean 435 | | +--rw user-created? boolean 436 | | +--rw user-grp-created? boolean 437 | | +--rw user-deleted? boolean 438 | | +--rw user-grp-deleted? boolean 439 | | +--rw user-logon? boolean 440 | | +--rw user-logoff? boolean 441 | | +--rw user-access-request? boolean 442 | | +--rw user-access-granted? boolean 443 | | +--rw user-access-violation? boolean 444 | +--:(dev-event) 445 | | +--rw dev-manual? string 446 | | +--rw dev-sec-event-content boolean 447 | | +--rw dev-sec-event-format 448 | | | +--rw unknown? boolean 449 | | | +--rw guid? boolean 450 | | | +--rw uuid? boolean 451 | | | +--rw uri? boolean 452 | | | +--rw fqdn? boolean 453 | | | +--rw fqpn? boolean 454 | | +--rw dev-sec-event-type 455 | | | +--rw unknown? boolean 456 | | | +--rw comm-alarm? boolean 457 | | | +--rw quality-of-service-alarm? boolean 458 | | | +--rw process-err-alarm? boolean 459 | | | +--rw equipment-err-alarm? boolean 460 | | | +--rw environmental-err-alarm? boolean 461 | | +--rw dev-sec-event-type-severity 462 | | +--rw unknown? boolean 463 | | +--rw cleared? boolean 464 | | +--rw indeterminate? boolean 465 | | +--rw critical? boolean 466 | | +--rw major? boolean 467 | | +--rw minor? boolean 468 | | +--rw warning? boolean 469 | +--:(sys-event) 470 | | +--rw sys-manual? string 471 | | +--rw sys-sec-event-content? boolean 472 | | +--rw sys-sec-event-format 473 | | | +--rw unknown? boolean 474 | | | +--rw guid? boolean 475 | | | +--rw uuid? boolean 476 | | | +--rw uri? boolean 477 | | | +--rw fqdn? boolean 478 | | | +--rw fqpn? boolean 479 | | +--rw sys-sec-event-type 480 | | +--rw unknown? boolean 481 | | +--rw audit-log-written-to? boolean 482 | | +--rw audit-log-cleared? boolean 483 | | +--rw policy-created? boolean 484 | | +--rw policy-edited? boolean 485 | | +--rw policy-deleted? boolean 486 | | +--rw policy-executed? boolean 487 | +--:(time-event) 488 | +--rw time-manual? string 489 | +--rw time-sec-event-begin? boolean 490 | +--rw time-sec-event-end? boolean 491 | +--rw time-sec-event-time-zone? boolean 492 +--rw condition 493 | ... 494 +--rw action 495 | ... 496 +--rw resolution-strategy 497 | ... 498 +--rw default-action 499 ... 501 Figure 4: Data Model Structure for Event Capabilities of Network 502 Security Function 504 These objects are defined as capabilities of user security event, 505 device security event, system security event, and time security 506 event. These objects can be extended according to specific vendor 507 event features. We will add additional event objects for more 508 generic network security functions. 510 6.2.2. Condition Capabilities 512 The data model for condition capabilities has the following 513 structure: 515 +--rw i2nsf-net-sec-caps 516 +--rw net-sec-capabilities* [nsc-capabilities-name] 517 +--rw nsc-capabilities-name string 518 +--rw time-zone 519 | +--rw start-time? boolean 520 | +--rw end-time? boolean 521 +--rw rule-description? boolean 522 +--rw rule-rev? boolean 523 +--rw rule-priority? boolean 524 +--rw event 525 | ... 526 +--rw condition 527 | +--rw (condition-type)? 528 | +--:(packet-security-condition) 529 | | +--rw packet-manual? string 530 | | +--rw packet-security-mac-condition 531 | | | +--rw pkt-sec-cond-mac-dest? boolean 532 | | | +--rw pkt-sec-cond-mac-src? boolean 533 | | | +--rw pkt-sec-cond-mac-8021q? boolean 534 | | | +--rw pkt-sec-cond-mac-ether-type? boolean 535 | | | +--rw pkt-sec-cond-mac-tci? string 536 | | +--rw packet-security-ipv4-condition 537 | | | +--rw pkt-sec-cond-ipv4-header-length? boolean 538 | | | +--rw pkt-sec-cond-ipv4-tos? boolean 539 | | | +--rw pkt-sec-cond-ipv4-total-length? boolean 540 | | | +--rw pkt-sec-cond-ipv4-id? boolean 541 | | | +--rw pkt-sec-cond-ipv4-fragment? boolean 542 | | | +--rw pkt-sec-cond-ipv4-fragment-offset? boolean 543 | | | +--rw pkt-sec-cond-ipv4-ttl? boolean 544 | | | +--rw pkt-sec-cond-ipv4-protocol? boolean 545 | | | +--rw pkt-sec-cond-ipv4-src? boolean 546 | | | +--rw pkt-sec-cond-ipv4-dest? boolean 547 | | | +--rw pkt-sec-cond-ipv4-ipopts? boolean 548 | | | +--rw pkt-sec-cond-ipv4-sameip? boolean 549 | | | +--rw pkt-sec-cond-ipv4-geoip? boolean 550 | | +--rw packet-security-ipv6-condition 551 | | | +--rw pkt-sec-cond-ipv6-dscp? boolean 552 | | | +--rw pkt-sec-cond-ipv6-ecn? boolean 553 | | | +--rw pkt-sec-cond-ipv6-traffic-class? boolean 554 | | | +--rw pkt-sec-cond-ipv6-flow-label? boolean 555 | | | +--rw pkt-sec-cond-ipv6-payload-length? boolean 556 | | | +--rw pkt-sec-cond-ipv6-next-header? boolean 557 | | | +--rw pkt-sec-cond-ipv6-hop-limit? boolean 558 | | | +--rw pkt-sec-cond-ipv6-src? boolean 559 | | | +--rw pkt-sec-cond-ipv6-dest? boolean 560 | | +--rw packet-security-tcp-condition 561 | | | +--rw pkt-sec-cond-tcp-seq-num? boolean 562 | | | +--rw pkt-sec-cond-tcp-ack-num? boolean 563 | | | +--rw pkt-sec-cond-tcp-window-size? boolean 564 | | | +--rw pkt-sec-cond-tcp-flags? boolean 565 | | +--rw packet-security-udp-condition 566 | | | +--rw pkt-sec-cond-udp-length? boolean 567 | | +--rw packet-security-icmp-condition 568 | | +--rw pkt-sec-cond-icmp-type? boolean 569 | | +--rw pkt-sec-cond-icmp-code? boolean 570 | | +--rw pkt-sec-cond-icmp-seg-num? boolean 571 | +--:(packet-payload-condition) 572 | | +--rw packet-payload-manual? string 573 | | +--rw pkt-payload-content? boolean 574 | +--:(target-condition) 575 | | +--rw target-manual? string 576 | | +--rw device-sec-context-cond? boolean 577 | +--:(users-condition) 578 | | +--rw users-manual? string 579 | | +--rw user 580 | | | +--rw (user-name)? 581 | | | +--:(tenant) 582 | | | | +--rw tenant? boolean 583 | | | +--:(vn-id) 584 | | | +--rw vn-id? boolean 585 | | +--rw group 586 | | +--rw (group-name)? 587 | | +--:(tenant) 588 | | | +--rw tenant? boolean 589 | | +--:(vn-id) 590 | | +--rw vn-id? boolean 591 | +--:(context-condition) 592 | | +--rw context-manual? string 593 | +--:(gen-context-condition) 594 | +--rw gen-context-manual? string 595 | +--rw geographic-location 596 | +--rw src-geographic-location? boolean 597 | +--rw dest-geographic-location? boolean 598 +--rw action 599 | ... 600 +--rw resolution-strategy 601 | ... 602 +--rw default-action 603 ... 605 Figure 5: Data Model Structure for Condition Capabilities of Network 606 Security Function 608 These objects are defined as capabilities of packet security 609 condition, packet payload security condition, target security 610 condition, user security condition, context condition, and generic 611 context condition. These objects can be extended according to 612 specific vendor condition features. We will add additional condition 613 objects for more generic network security functions. 615 6.2.3. Action Capabilities 617 The data model for action capabilities has the following structure: 619 +--rw i2nsf-net-sec-caps 620 +--rw net-sec-capabilities* [nsc-capabilities-name] 621 +--rw nsc-capabilities-name string 622 +--rw time-zone 623 | +--rw start-time? boolean 624 | +--rw end-time? boolean 625 +--rw rule-description? boolean 626 +--rw rule-rev? boolean 627 +--rw rule-priority? boolean 628 +--rw event 629 | ... 630 +--rw condition 631 | ... 632 +--rw action 633 | +--rw (action-type)? 634 | +--:(ingress-action) 635 | | +--rw ingress-manual? string 636 | | +--rw ingress-action-type 637 | | +--rw pass? boolean 638 | | +--rw drop? boolean 639 | | +--rw reject? boolean 640 | | +--rw alert? boolean 641 | | +--rw mirror? boolean 642 | +--:(egress-action) 643 | +--rw egress-manual? string 644 | +--rw egress-action-type 645 | +--rw invoke-signaling? boolean 646 | +--rw tunnel-encapsulation? boolean 647 | +--rw forwarding? boolean 648 | +--rw redirection? boolean 649 +--rw resolution-strategy 650 | ... 651 +--rw default-action 652 ... 654 Figure 6: Data Model Structure for Action Capabilities of Network 655 Security Function 657 These objects are defined capabilities as ingress action, egress 658 action, and apply profile action. These objects can be extended 659 according to specific vendor action feature. We will add additional 660 action objects for more generic network security functions. 662 6.2.4. Resolution Strategy Capabilities 664 The data model for resolution strategy capabilities has the following 665 structure: 667 +--rw i2nsf-net-sec-caps 668 +--rw net-sec-capabilities* [nsc-capabilities-name] 669 +--rw nsc-capabilities-name string 670 +--rw time-zone 671 | +--rw start-time? boolean 672 | +--rw end-time? boolean 673 +--rw rule-description? boolean 674 +--rw rule-rev? boolean 675 +--rw rule-priority? boolean 676 +--rw event 677 | ... 678 +--rw condition 679 | ... 680 +--rw action 681 | ... 682 +--rw resolution-strategy 683 | +--rw first-matching-rule? boolean 684 | +--rw last-matching-rule? boolean 685 +--rw default-action 686 ... 688 Figure 7: Data Model Structure for Resolution Strategy Capabilities 689 of Network Security Function 691 These objects are defined capabilities as first-matching-rule and 692 last-matching-rule. These objects can be extended according to 693 specific vendor resolution strategy features. We will add additional 694 resolution strategy objects for more generic network security 695 functions. 697 6.2.5. Default Action Capabilities 699 The data model for default action capabilities has the following 700 structure: 702 +--rw i2nsf-net-sec-caps 703 +--rw net-sec-capabilities* [nsc-capabilities-name] 704 +--rw nsc-capabilities-name string 705 +--rw time-zone 706 | +--rw start-time? boolean 707 | +--rw end-time? boolean 708 +--rw rule-description? boolean 709 +--rw rule-rev? boolean 710 +--rw rule-priority? boolean 711 +--rw event 712 | ... 713 +--rw condition 714 | ... 715 +--rw action 716 | ... 717 +--rw resolution-strategy 718 | ... 719 +--rw default-action 720 +--rw default-action-type 721 +--rw ingress-action-type 722 +--rw pass? boolean 723 +--rw drop? boolean 724 +--rw reject? boolean 725 +--rw alert? boolean 726 +--rw mirror? boolean 728 Figure 8: Data Model Structure for Default Action Capabilities of 729 Network Security Function 731 6.2.6. RPC for Acquiring Appropriate Network Security Function 733 The data model for RPC for Acquiring Appropriate Network Security 734 Function has the following structure: 736 rpcs: 737 +---x call-appropriate-nsf 738 +---w input 739 | +---w nsf-type nsf-type 740 | +---w target-device 741 | +---w pc? boolean 742 | +---w mobile-phone? boolean 743 | +---w voip-volte-phone? boolean 744 | +---w tablet? boolean 745 | +---w iot? boolean 746 | +---w vehicle? boolean 747 +--ro output 748 +--ro nsf-address 749 +--ro (nsf-address-type)? 750 +--:(ipv4-address) 751 | +--ro ipv4-address inet:ipv4-address 752 +--:(ipv6-address) 753 +--ro ipv6-address inet:ipv6-address 755 Figure 9: RPC for Acquiring Appropriate Network Security Function 757 This shows a RPC for acquiring an appropriate network security 758 function according to type of NSF and/or target devices. If the SFF 759 [i2nsf-sfc]does not have the location information of network security 760 functions that it should send in own cache table, this can be used to 761 acquire the information. These objects are defined as input data 762 (i.e., NSF type and target devices) and output data (i.e., location 763 information of NSF). 765 7. YANG Modules 767 7.1. I2NSF Capability YANG Data Module 769 This section introduces a YANG module for the information model of 770 network security functions, as defined in the [i2nsf-nsf-cap-im]. 772 file "ietf-i2nsf-capability@2017-10-30.yang" 774 module ietf-i2nsf-capability { 775 namespace 776 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; 777 prefix 778 i2nsf-capability; 780 import ietf-inet-types{ 781 prefix inet; 782 } 783 organization 784 "IETF I2NSF (Interface to Network Security Functions) 785 Working Group"; 787 contact 788 "WG Web: 789 WG List: 791 WG Chair: Adrian Farrel 792 794 WG Chair: Linda Dunbar 795 797 Editor: Susan Hares 798 800 Editor: Jaehoon Paul Jeong 801 803 Editor: Jinyong Tim Kim 804 "; 806 description 807 "This module describes a capability model 808 for I2NSF devices."; 810 revision "2017-10-30"{ 811 description "The fourth revision"; 812 reference 813 "draft-ietf-i2nsf-capability-00"; 814 } 816 grouping i2nsf-nsf-location { 817 description 818 "This provides a location for capabilities."; 819 container nsf-address { 820 description 821 "This is location information for capabilities."; 822 choice nsf-address-type { 823 description 824 "nsf address type: ipv4 and ipv4"; 825 case ipv4-address { 826 description 827 "ipv4 case"; 828 leaf ipv4-address { 829 type inet:ipv4-address; 830 mandatory true; 831 description 832 "nsf address type is ipv4"; 833 } 834 } 835 case ipv6-address { 836 description 837 "ipv6 case"; 838 leaf ipv6-address { 839 type inet:ipv6-address; 840 mandatory true; 841 description 842 "nsf address type is ipv6"; 843 } 844 } 845 } 846 } 847 } 849 typedef nsf-type { 850 type enumeration { 851 enum network-firewall { 852 description 853 "If type of a NSF is Network Firewall."; 854 } 856 enum web-app-firewall { 857 description 858 "If type of a NSF is Web Application 859 Firewall."; 860 } 862 enum anti-virus { 863 description 864 "If type of a NSF is Anti-Virus"; 865 } 867 enum ids { 868 description 869 "If type of a NSF is IDS."; 870 } 872 enum ips { 873 description 874 "If type of a NSF is IPS."; 875 } 876 enum ddos-mitigator { 877 description 878 "If type of a NSF is DDoS Mitigator."; 879 } 880 } 881 description 882 "This is used for type of NSF."; 883 } 885 grouping i2nsf-it-resources { 886 description 887 "This provides a link between capabilities 888 and IT resources. This has a list of IT resources 889 by name."; 890 container target-device { 891 description 892 "it-resources"; 894 leaf pc { 895 type boolean; 896 description 897 "If type of a device is PC."; 898 } 900 leaf mobile-phone { 901 type boolean; 902 description 903 "If type of a device is mobile-phone."; 904 } 906 leaf voip-volte-phone { 907 type boolean; 908 description 909 "If type of a device is voip-volte-phone."; 910 } 912 leaf tablet { 913 type boolean; 914 description 915 "If type of a device is tablet."; 916 } 918 leaf iot { 919 type boolean; 920 description 921 "If type of a device is Internet of Things."; 922 } 923 leaf vehicle { 924 type boolean; 925 description 926 "If type of a device is vehicle."; 927 } 929 } 930 } 932 grouping capabilities-information { 933 description 934 "This includes information of capabilities."; 936 leaf nsf-type { 937 type nsf-type; 938 description 939 "This is type of NSF."; 940 } 941 uses i2nsf-nsf-location; 942 uses i2nsf-it-resources; 943 } 945 grouping i2nsf-net-sec-caps { 946 description 947 "i2nsf-net-sec-caps"; 948 list net-sec-capabilities { 949 key "nsc-capabilities-name"; 950 description 951 "net-sec-capabilities"; 952 leaf nsc-capabilities-name { 953 type string; 954 mandatory true; 955 description 956 "nsc-capabilities-name"; 957 } 959 container time-zone { 960 description 961 "This can be used to apply rules according to time"; 962 leaf start-time { 963 type boolean; 964 description 965 "This is start time for time zone"; 966 } 967 leaf end-time { 968 type boolean; 969 description 970 "This is end time for time zone"; 972 } 973 } 975 leaf rule-description { 976 type boolean; 977 description 978 "This is rule-description."; 979 } 980 leaf rule-rev { 981 type boolean; 982 description 983 "This is rule-revision"; 984 } 985 leaf rule-priority { 986 type boolean; 987 description 988 "This is rule-priority"; 989 } 991 container event { 992 description 993 " This is abstract. An event is defined as any important 994 occurrence in time of a change in the system being 995 managed, and/or in the environment of the system being 996 managed. When used in the context of policy rules for 997 a flow-based NSF, it is used to determine whether the 998 Condition clause of the Policy Rule can be evaluated 999 or not. Examples of an I2NSF event include time and 1000 user actions (e.g., logon, logoff, and actions that 1001 violate any ACL.)."; 1003 choice event-type { 1004 description 1005 "Vendors can use YANG data model to configure rules 1006 by concreting this event type"; 1007 case usr-event { 1008 leaf usr-manual { 1009 type string; 1010 description 1011 "This is manual for user event. 1012 Vendors can write instructions for user event 1013 that vendor made"; 1014 } 1016 leaf usr-sec-event-content { 1017 type boolean; 1018 description 1019 "This is a mandatory string that contains the content 1020 of the UserSecurityEvent. The format of the content 1021 is specified in the usrSecEventFormat class 1022 attribute, and the type of event is defined in the 1023 usrSecEventType class attribute. An example of the 1024 usrSecEventContent attribute is a string hrAdmin, 1025 with the usrSecEventFormat set to 1 (GUID) and the 1026 usrSecEventType attribute set to 5 (new logon)."; 1027 } 1029 container usr-sec-event-format { 1030 description 1031 "This is a mandatory uint 8 enumerated integer, which 1032 is used to specify the data type of the 1033 usrSecEventContent attribute. The content is 1034 specified in the usrSecEventContent class attribute, 1035 and the type of event is defined in the 1036 usrSecEventType class attribute. An example of the 1037 usrSecEventContent attribute is string hrAdmin, 1038 with the usrSecEventFormat attribute set to 1 (GUID) 1039 and the usrSecEventType attribute set to 5 1040 (new logon)."; 1041 leaf unknown { 1042 type boolean; 1043 description 1044 "If SecEventFormat is unknown"; 1045 } 1046 leaf guid { 1047 type boolean; 1048 description 1049 "If SecEventFormat is GUID 1050 (Generic Unique IDentifier)"; 1051 } 1052 leaf uuid { 1053 type boolean; 1054 description 1055 "If SecEventFormat is UUID 1056 (Universal Unique IDentifier)"; 1057 } 1058 leaf uri { 1059 type boolean; 1060 description 1061 "If SecEventFormat is URI 1062 (Uniform Resource Identifier)"; 1063 } 1064 leaf fqdn { 1065 type boolean; 1066 description 1067 "If SecEventFormat is FQDN 1068 (Fully Qualified Domain Name)"; 1069 } 1070 leaf fqpn { 1071 type boolean; 1072 description 1073 "If SecEventFormat is FQPN 1074 (Fully Qualified Path Name)"; 1075 } 1076 } 1078 container usr-sec-event-type { 1079 leaf unknown { 1080 type boolean; 1081 description 1082 "If usrSecEventType is unknown"; 1083 } 1084 leaf user-created { 1085 type boolean; 1086 description 1087 "If usrSecEventType is new user 1088 created"; 1089 } 1090 leaf user-grp-created { 1091 type boolean; 1092 description 1093 "If usrSecEventType is new user 1094 group created"; 1095 } 1096 leaf user-deleted { 1097 type boolean; 1098 description 1099 "If usrSecEventType is user 1100 deleted"; 1101 } 1102 leaf user-grp-deleted { 1103 type boolean; 1104 description 1105 "If usrSecEventType is user 1106 group deleted"; 1107 } 1108 leaf user-logon { 1109 type boolean; 1110 description 1111 "If usrSecEventType is user 1112 logon"; 1113 } 1114 leaf user-logoff { 1115 type boolean; 1116 description 1117 "If usrSecEventType is user 1118 logoff"; 1119 } 1120 leaf user-access-request { 1121 type boolean; 1122 description 1123 "If usrSecEventType is user 1124 access request"; 1125 } 1126 leaf user-access-granted { 1127 type boolean; 1128 description 1129 "If usrSecEventType is user 1130 granted"; 1131 } 1132 leaf user-access-violation { 1133 type boolean; 1134 description 1135 "If usrSecEventType is user 1136 violation"; 1137 } 1138 description 1139 "This is a mandatory uint 8 enumerated integer, which 1140 is used to specify the type of event that involves 1141 this user. The content and format are specified in 1142 the usrSecEventContent and usrSecEventFormat class 1143 attributes, respectively. An example of the 1144 usrSecEventContent attribute is string hrAdmin, 1145 with the usrSecEventFormat attribute set to 1 (GUID) 1146 and the usrSecEventType attribute set to 5 1147 (new logon)."; 1148 } 1150 } 1151 case dev-event { 1152 leaf dev-manual { 1153 type string; 1154 description 1155 "This is manual for device event. 1156 Vendors can write instructions for device event 1157 that vendor made"; 1158 } 1160 leaf dev-sec-event-content { 1161 type boolean; 1162 mandatory true; 1163 description 1164 "This is a mandatory string that contains the content 1165 of the DeviceSecurityEvent. The format of the 1166 content is specified in the devSecEventFormat class 1167 attribute, and the type of event is defined in the 1168 devSecEventType class attribute. An example of the 1169 devSecEventContent attribute is alarm, with the 1170 devSecEventFormat attribute set to 1 (GUID), the 1171 devSecEventType attribute set to 5 (new logon)."; 1172 } 1174 container dev-sec-event-format { 1175 description 1176 "This is a mandatory uint 8 enumerated integer, 1177 which is used to specify the data type of the 1178 devSecEventContent attribute."; 1180 leaf unknown { 1181 type boolean; 1182 description 1183 "If SecEventFormat is unknown"; 1184 } 1185 leaf guid { 1186 type boolean; 1187 description 1188 "If SecEventFormat is GUID 1189 (Generic Unique IDentifier)"; 1190 } 1191 leaf uuid { 1192 type boolean; 1193 description 1194 "If SecEventFormat is UUID 1195 (Universal Unique IDentifier)"; 1196 } 1197 leaf uri { 1198 type boolean; 1199 description 1200 "If SecEventFormat is URI 1201 (Uniform Resource Identifier)"; 1202 } 1203 leaf fqdn { 1204 type boolean; 1205 description 1206 "If SecEventFormat is FQDN 1207 (Fully Qualified Domain Name)"; 1208 } 1209 leaf fqpn { 1210 type boolean; 1211 description 1212 "If SecEventFormat is FQPN 1213 (Fully Qualified Path Name)"; 1214 } 1215 } 1217 container dev-sec-event-type { 1218 description 1219 "This is a mandatory uint 8 enumerated integer, 1220 which is used to specify the type of event 1221 that was generated by this device."; 1223 leaf unknown { 1224 type boolean; 1225 description 1226 "If devSecEventType is unknown"; 1227 } 1228 leaf comm-alarm { 1229 type boolean; 1230 description 1231 "If devSecEventType is communications 1232 alarm"; 1233 } 1234 leaf quality-of-service-alarm { 1235 type boolean; 1236 description 1237 "If devSecEventType is quality of service 1238 alarm"; 1239 } 1240 leaf process-err-alarm { 1241 type boolean; 1242 description 1243 "If devSecEventType is processing error 1244 alarm"; 1245 } 1246 leaf equipment-err-alarm { 1247 type boolean; 1248 description 1249 "If devSecEventType is equipment error 1250 alarm"; 1251 } 1252 leaf environmental-err-alarm { 1253 type boolean; 1254 description 1255 "If devSecEventType is environmental error 1256 alarm"; 1257 } 1259 } 1261 container dev-sec-event-type-severity { 1262 description 1263 "This is a mandatory uint 8 enumerated integer, 1264 which is used to specify the perceived 1265 severity of the event generated by this 1266 Device."; 1268 leaf unknown { 1269 type boolean; 1270 description 1271 "If devSecEventType is unknown"; 1272 } 1273 leaf cleared { 1274 type boolean; 1275 description 1276 "If devSecEventTypeSeverity is cleared"; 1277 } 1278 leaf indeterminate { 1279 type boolean; 1280 description 1281 "If devSecEventTypeSeverity is 1282 indeterminate"; 1283 } 1284 leaf critical { 1285 type boolean; 1286 description 1287 "If devSecEventTypeSeverity is critical"; 1288 } 1289 leaf major{ 1290 type boolean; 1291 description 1292 "If devSecEventTypeSeverity is major"; 1293 } 1294 leaf minor { 1295 type boolean; 1296 description 1297 "If devSecEventTypeSeverity is minor"; 1298 } 1299 leaf warning { 1300 type boolean; 1301 description 1302 "If devSecEventTypeSeverity is warning"; 1303 } 1304 } 1305 } 1306 case sys-event { 1307 leaf sys-manual { 1308 type string; 1309 description 1310 "This is manual for system event. 1311 Vendors can write instructions for system event 1312 that vendor made"; 1313 } 1315 leaf sys-sec-event-content { 1316 type boolean; 1317 description 1318 "This is a mandatory string that contains a content 1319 of the SystemSecurityEvent. The format of a content 1320 is specified in a sysSecEventFormat class attribute, 1321 and the type of event is defined in the 1322 sysSecEventType class attribute. An example of the 1323 sysSecEventContent attribute is string sysadmin3, 1324 with the sysSecEventFormat attribute set to 1(GUID), 1325 and the sysSecEventType attribute set to 2 1326 (audit log cleared)."; 1327 } 1329 container sys-sec-event-format { 1330 description 1331 "This is a mandatory uint 8 enumerated integer, which 1332 is used to specify the data type of the 1333 sysSecEventContent attribute."; 1335 leaf unknown { 1336 type boolean; 1337 description 1338 "If SecEventFormat is unknown"; 1339 } 1340 leaf guid { 1341 type boolean; 1342 description 1343 "If SecEventFormat is GUID 1344 (Generic Unique IDentifier)"; 1345 } 1346 leaf uuid { 1347 type boolean; 1348 description 1349 "If SecEventFormat is UUID 1350 (Universal Unique IDentifier)"; 1351 } 1352 leaf uri { 1353 type boolean; 1354 description 1355 "If SecEventFormat is URI 1356 (Uniform Resource Identifier)"; 1357 } 1358 leaf fqdn { 1359 type boolean; 1360 description 1361 "If SecEventFormat is FQDN 1362 (Fully Qualified Domain Name)"; 1363 } 1364 leaf fqpn { 1365 type boolean; 1366 description 1367 "If SecEventFormat is FQPN 1368 (Fully Qualified Path Name)"; 1369 } 1370 } 1372 container sys-sec-event-type { 1373 description 1374 "This is a mandatory uint 8 enumerated integer, which 1375 is used to specify the type of event that involves 1376 this device."; 1378 leaf unknown { 1379 type boolean; 1380 description 1381 "If sysSecEventType is unknown"; 1382 } 1383 leaf audit-log-written-to { 1384 type boolean; 1385 description 1386 "If sysSecEventTypeSeverity 1387 is that audit log is written to"; 1388 } 1389 leaf audit-log-cleared { 1390 type boolean; 1391 description 1392 "If sysSecEventTypeSeverity 1393 is that audit log is cleared"; 1394 } 1395 leaf policy-created { 1396 type boolean; 1397 description 1398 "If sysSecEventTypeSeverity 1399 is that policy is created"; 1400 } 1401 leaf policy-edited{ 1402 type boolean; 1403 description 1404 "If sysSecEventTypeSeverity 1405 is that policy is edited"; 1406 } 1407 leaf policy-deleted{ 1408 type boolean; 1409 description 1410 "If sysSecEventTypeSeverity 1411 is that policy is deleted"; 1412 } 1413 leaf policy-executed{ 1414 type boolean; 1415 description 1416 "If sysSecEventTypeSeverity 1417 is that policy is executed"; 1418 } 1419 } 1420 } 1421 case time-event { 1422 leaf time-manual { 1423 type string; 1424 description 1425 "This is manual for time event. 1426 Vendors can write instructions for time event 1427 that vendor made"; 1428 } 1429 leaf time-sec-event-begin { 1430 type boolean; 1431 description 1432 "This is a mandatory DateTime attribute, and 1433 represents the beginning of a time period. 1434 It has a value that has a date and/or a time 1435 component (as in the Java or Python libraries)."; 1436 } 1438 leaf time-sec-event-end { 1439 type boolean; 1440 description 1441 "This is a mandatory DateTime attribute, and 1442 represents the end of a time period. It has 1443 a value that has a date and/or a time component 1444 (as in the Java or Python libraries). If this is 1445 a single event occurrence, and not a time period 1446 when the event can occur, then the 1447 timeSecEventPeriodEnd attribute may be ignored."; 1448 } 1450 leaf time-sec-event-time-zone { 1451 type boolean; 1452 description 1453 "This is a mandatory string attribute, and defines a 1454 time zone that this event occurred in using the 1455 format specified in ISO8601."; 1456 } 1457 } 1458 } 1459 } 1461 container condition { 1462 description 1463 " This is abstract. A condition is defined as a set 1464 of attributes, features, and/or values that are to be 1465 compared with a set of known attributes, features, 1466 and/or values in order to determine whether or not the 1467 set of Actions in that (imperative) I2NSF Policy Rule 1468 can be executed or not. Examples of I2NSF Conditions 1469 include matching attributes of a packet or flow, and 1470 comparing the internal state of an NSF to a desired state."; 1472 choice condition-type { 1473 description 1474 "Vendors can use YANG data model to configure rules 1475 by concreting this condition type"; 1477 case packet-security-condition { 1478 leaf packet-manual { 1479 type string; 1480 description 1481 "This is manual for packet condition. 1482 Vendors can write instructions for packet condition 1483 that vendor made"; 1484 } 1486 container packet-security-mac-condition { 1487 description 1488 "The purpose of this Class is to represent packet MAC 1489 packet header information that can be used as part of 1490 a test to determine if the set of Policy Actions in 1491 this ECA Policy Rule should be execute or not."; 1493 leaf pkt-sec-cond-mac-dest { 1494 type boolean; 1495 description 1496 "The MAC destination address (6 octets long)."; 1497 } 1498 leaf pkt-sec-cond-mac-src { 1499 type boolean; 1500 description 1501 "The MAC source address (6 octets long)."; 1502 } 1504 leaf pkt-sec-cond-mac-8021q { 1505 type boolean; 1506 description 1507 "This is an optional string attribute, and defines 1508 The 802.1Q tab value (2 octets long)."; 1509 } 1511 leaf pkt-sec-cond-mac-ether-type { 1512 type boolean; 1513 description 1514 "The EtherType field (2 octets long). Values up to 1515 and including 1500 indicate the size of the payload 1516 in octets; values of 1536 and above define which 1517 protocol is encapsulated in the payload of the 1518 frame."; 1519 } 1521 leaf pkt-sec-cond-mac-tci { 1522 type string; 1523 description 1524 "This is an optional string attribute, and defines 1525 the Tag Control Information. This consists of a 3 1526 bit user priority field, a drop eligible indicator 1527 (1 bit), and a VLAN identifier (12 bits)."; 1528 } 1529 } 1531 container packet-security-ipv4-condition { 1532 description 1533 "The purpose of this Class is to represent packet IPv4 1534 packet header information that can be used as part of 1535 a test to determine if the set of Policy Actions in 1536 this ECA Policy Rule should be executed or not."; 1538 leaf pkt-sec-cond-ipv4-header-length { 1539 type boolean; 1540 description 1541 "The IPv4 packet header consists of 14 fields, 1542 of which 13 are required."; 1543 } 1545 leaf pkt-sec-cond-ipv4-tos { 1546 type boolean; 1547 description 1548 "The ToS field could specify a datagram's priority 1549 and request a route for low-delay, high-throughput, 1550 or highly-reliable service.."; 1551 } 1553 leaf pkt-sec-cond-ipv4-total-length { 1554 type boolean; 1555 description 1556 "This 16-bit field defines the entire packet size, 1557 including header and data, in bytes."; 1558 } 1560 leaf pkt-sec-cond-ipv4-id { 1561 type boolean; 1562 description 1563 "This field is an identification field and is 1564 primarily used for uniquely identifying 1565 the group of fragments of a single IP datagram."; 1566 } 1568 leaf pkt-sec-cond-ipv4-fragment { 1569 type boolean; 1570 description 1571 "IP fragmentation is an Internet Protocol (IP) 1572 process that breaks datagrams into smaller pieces 1573 (fragments), so that packets may be formed that 1574 can pass through a link with a smaller maximum 1575 transmission unit (MTU) than the original 1576 datagram size."; 1577 } 1579 leaf pkt-sec-cond-ipv4-fragment-offset { 1580 type boolean; 1581 description 1582 "Fragment offset field along with Don't Fragment 1583 and More Fragment flags in the IP protocol 1584 header are used for fragmentation and reassembly 1585 of IP datagrams."; 1586 } 1588 leaf pkt-sec-cond-ipv4-ttl { 1589 type boolean; 1590 description 1591 "The ttl keyword is used to check for a specific 1592 IP time-to-live value in the header of 1593 a packet."; 1595 } 1597 leaf pkt-sec-cond-ipv4-protocol { 1598 type boolean; 1599 description 1600 "Internet Protocol version 4(IPv4) is the fourth 1601 version of the Internet Protocol (IP)."; 1602 } 1604 leaf pkt-sec-cond-ipv4-src { 1605 type boolean; 1606 description 1607 "Defines the IPv4 Source Address."; 1608 } 1610 leaf pkt-sec-cond-ipv4-dest { 1611 type boolean; 1612 description 1613 "Defines the IPv4 Destination Address."; 1614 } 1616 leaf pkt-sec-cond-ipv4-ipopts { 1617 type boolean; 1618 description 1619 "With the ipopts keyword you can check if 1620 a specific ip option is set. Ipopts has 1621 to be used at the beginning of a rule."; 1622 } 1624 leaf pkt-sec-cond-ipv4-sameip { 1625 type boolean; 1626 description 1627 "Every packet has a source IP-address and 1628 a destination IP-address. It can be that 1629 the source IP is the same as 1630 the destination IP."; 1631 } 1633 leaf pkt-sec-cond-ipv4-geoip { 1634 type boolean; 1635 description 1636 "The geoip keyword enables you to match on 1637 the source, destination or source and destination 1638 IP addresses of network traffic and to see to 1639 which country it belongs. To do this, Suricata 1640 uses GeoIP API with MaxMind database format."; 1641 } 1642 } 1643 container packet-security-ipv6-condition { 1644 description 1645 "The purpose of this Class is to represent packet 1646 IPv6 packet header information that can be used as 1647 part of a test to determine if the set of Policy 1648 Actions in this ECA Policy Rule should be executed 1649 or not."; 1651 leaf pkt-sec-cond-ipv6-dscp { 1652 type boolean; 1653 description 1654 "Differentiated Services Code Point (DSCP) 1655 of ipv6."; 1656 } 1658 leaf pkt-sec-cond-ipv6-ecn { 1659 type boolean; 1660 description 1661 "ECN allows end-to-end notification of network 1662 congestion without dropping packets."; 1663 } 1665 leaf pkt-sec-cond-ipv6-traffic-class { 1666 type boolean; 1667 description 1668 "The bits of this field hold two values. The 6 1669 most-significant bits are used for 1670 differentiated services, which is used to 1671 classify packets."; 1672 } 1674 leaf pkt-sec-cond-ipv6-flow-label { 1675 type boolean; 1676 description 1677 "The flow label when set to a non-zero value 1678 serves as a hint to routers and switches 1679 with multiple outbound paths that these 1680 packets should stay on the same path so that 1681 they will not be reordered."; 1682 } 1684 leaf pkt-sec-cond-ipv6-payload-length { 1685 type boolean; 1686 description 1687 "The size of the payload in octets, 1688 including any extension headers."; 1689 } 1690 leaf pkt-sec-cond-ipv6-next-header { 1691 type boolean; 1692 description 1693 "Specifies the type of the next header. 1694 This field usually specifies the transport 1695 layer protocol used by a packet's payload."; 1696 } 1698 leaf pkt-sec-cond-ipv6-hop-limit { 1699 type boolean; 1700 description 1701 "Replaces the time to live field of IPv4."; 1702 } 1704 leaf pkt-sec-cond-ipv6-src { 1705 type boolean; 1706 description 1707 "The IPv6 address of the sending node."; 1708 } 1710 leaf pkt-sec-cond-ipv6-dest { 1711 type boolean; 1712 description 1713 "The IPv6 address of the destination node(s)."; 1714 } 1715 } 1717 container packet-security-tcp-condition { 1718 description 1719 "The purpose of this Class is to represent packet 1720 TCP packet header information that can be used as 1721 part of a test to determine if the set of Policy 1722 Actions in this ECA Policy Rule should be executed 1723 or not."; 1725 leaf pkt-sec-cond-tcp-seq-num { 1726 type boolean; 1727 description 1728 "If the SYN flag is set (1), then this is the 1729 initial sequence number."; 1730 } 1732 leaf pkt-sec-cond-tcp-ack-num { 1733 type boolean; 1734 description 1735 "If the ACK flag is set then the value of this 1736 field is the next sequence number that the sender 1737 is expecting."; 1739 } 1741 leaf pkt-sec-cond-tcp-window-size { 1742 type boolean; 1743 description 1744 "The size of the receive window, which specifies 1745 the number of windows size units (by default,bytes) 1746 (beyond the segment identified by the sequence 1747 number in the acknowledgment field) that the sender 1748 of this segment is currently willing to recive."; 1749 } 1751 leaf pkt-sec-cond-tcp-flags { 1752 type boolean; 1753 description 1754 "This is a mandatory string attribute, and defines 1755 the nine Control bit flags (9 bits)."; 1756 } 1757 } 1759 container packet-security-udp-condition { 1760 description 1761 "The purpose of this Class is to represent packet UDP 1762 packet header information that can be used as part 1763 of a test to determine if the set of Policy Actions 1764 in this ECA Policy Rule should be executed or not."; 1766 leaf pkt-sec-cond-udp-length { 1767 type boolean; 1768 description 1769 "This is a mandatory string attribute, and defines 1770 the length in bytes of the UDP header and data 1771 (16 bits)."; 1772 } 1773 } 1775 container packet-security-icmp-condition { 1776 description 1777 "The internet control message protocol condition."; 1779 leaf pkt-sec-cond-icmp-type { 1780 type boolean; 1781 description 1782 "ICMP type, see Control messages."; 1783 } 1785 leaf pkt-sec-cond-icmp-code { 1786 type boolean; 1787 description 1788 "ICMP subtype, see Control messages."; 1789 } 1791 leaf pkt-sec-cond-icmp-seg-num { 1792 type boolean; 1793 description 1794 "The icmp Sequence Number."; 1795 } 1796 } 1797 } 1799 case packet-payload-condition { 1800 leaf packet-payload-manual { 1801 type string; 1802 description 1803 "This is manual for payload condition. 1804 Vendors can write instructions for payload condition 1805 that vendor made"; 1806 } 1807 leaf pkt-payload-content { 1808 type boolean; 1809 description 1810 "The content keyword is very important in 1811 signatures. Between the quotation marks you 1812 can write on what you would like the 1813 signature to match."; 1814 } 1815 } 1816 case target-condition { 1817 leaf target-manual { 1818 type string; 1819 description 1820 "This is manual for target condition. 1821 Vendors can write instructions for target condition 1822 that vendor made"; 1823 } 1825 leaf device-sec-context-cond { 1826 type boolean; 1827 description 1828 "The device attribute that can identify a device, 1829 including the device type (i.e., router, switch, 1830 pc, ios, or android) and the device's owner as 1831 well."; 1832 } 1833 } 1834 case users-condition { 1835 leaf users-manual { 1836 type string; 1837 description 1838 "This is manual for user condition. 1839 Vendors can write instructions for user condition 1840 that vendor made"; 1841 } 1843 container user{ 1844 description 1845 "The user (or user group) information with which 1846 network flow is associated: The user has many 1847 attributes such as name, id, password, type, 1848 authentication mode and so on. Name/id is often 1849 used in the security policy to identify the user. 1850 Besides, NSF is aware of the IP address of the 1851 user provided by a unified user management system 1852 via network. Based on name-address association, 1853 NSF is able to enforce the security functions 1854 over the given user (or user group)"; 1856 choice user-name { 1857 description 1858 "The name of the user. 1859 This must be unique."; 1861 case tenant { 1862 description 1863 "Tenant information."; 1865 leaf tenant { 1866 type boolean; 1867 description 1868 "User's tenant information."; 1869 } 1870 } 1872 case vn-id { 1873 description 1874 "VN-ID information."; 1876 leaf vn-id { 1877 type boolean; 1878 description 1879 "User's VN-ID information."; 1880 } 1881 } 1882 } 1884 } 1885 container group { 1886 description 1887 "The user (or user group) information with which 1888 network flow is associated: The user has many 1889 attributes such as name, id, password, type, 1890 authentication mode and so on. Name/id is often 1891 used in the security policy to identify the user. 1892 Besides, NSF is aware of the IP address of the 1893 user provided by a unified user management system 1894 via network. Based on name-address association, 1895 NSF is able to enforce the security functions 1896 over the given user (or user group)"; 1898 choice group-name { 1899 description 1900 "The name of the user. 1901 This must be unique."; 1903 case tenant { 1904 description 1905 "Tenant information."; 1907 leaf tenant { 1908 type boolean; 1909 description 1910 "User's tenant information."; 1911 } 1912 } 1914 case vn-id { 1915 description 1916 "VN-ID information."; 1918 leaf vn-id { 1919 type boolean; 1920 description 1921 "User's VN-ID information."; 1922 } 1923 } 1924 } 1925 } 1927 } 1928 case context-condition { 1929 leaf context-manual { 1930 type string; 1931 description 1932 "This is manual for context condition. 1933 Vendors can write instructions for context condition 1934 that vendor made"; 1935 } 1936 } 1937 case gen-context-condition { 1938 leaf gen-context-manual { 1939 type string; 1940 description 1941 "This is manual for generic context condition. 1942 Vendors can write instructions for generic context 1943 condition that vendor made"; 1944 } 1946 container geographic-location { 1947 description 1948 "The location where network traffic is associated 1949 with. The region can be the geographic location 1950 such as country, province, and city, 1951 as well as the logical network location such as 1952 IP address, network section, and network domain."; 1954 leaf src-geographic-location { 1955 type boolean; 1956 description 1957 "This is mapped to ip address. We can acquire 1958 source region through ip address stored the 1959 database."; 1960 } 1961 leaf dest-geographic-location { 1962 type boolean; 1963 description 1964 "This is mapped to ip address. We can acquire 1965 destination region through ip address stored 1966 the database."; 1967 } 1968 } 1969 } 1970 } 1971 } 1972 container action { 1973 description 1974 "An action is used to control and monitor aspects of 1975 flow-based NSFs when the event and condition clauses 1976 are satisfied. NSFs provide security functions by 1977 executing various Actions. Examples of I2NSF Actions 1978 include providing intrusion detection and/or protection, 1979 web and flow filtering, and deep packet inspection 1980 for packets and flows."; 1982 choice action-type { 1983 description 1984 "Vendors can use YANG data model to configure rules 1985 by concreting this action type"; 1986 case ingress-action { 1987 leaf ingress-manual { 1988 type string; 1989 description 1990 "This is manual for ingress action. 1991 Vendors can write instructions for ingress action 1992 that vendor made"; 1993 } 1994 container ingress-action-type { 1995 description 1996 "Ingress action type: permit, deny, and mirror."; 1997 leaf pass { 1998 type boolean; 1999 description 2000 "If ingress action is pass"; 2001 } 2002 leaf drop { 2003 type boolean; 2004 description 2005 "If ingress action is drop"; 2006 } 2007 leaf reject { 2008 type boolean; 2009 description 2010 "If ingress action is reject"; 2011 } 2012 leaf alert { 2013 type boolean; 2014 description 2015 "If ingress action is alert"; 2016 } 2017 leaf mirror { 2018 type boolean; 2019 description 2020 "If ingress action is mirror"; 2021 } 2022 } 2023 } 2024 case egress-action { 2025 leaf egress-manual { 2026 type string; 2027 description 2028 "This is manual for egress action. 2029 Vendors can write instructions for egress action 2030 that vendor made"; 2031 } 2032 container egress-action-type { 2033 description 2034 "Egress-action-type: invoke-signaling, 2035 tunnel-encapsulation, and forwarding."; 2036 leaf invoke-signaling { 2037 type boolean; 2038 description 2039 "If egress action is invoke signaling"; 2040 } 2041 leaf tunnel-encapsulation { 2042 type boolean; 2043 description 2044 "If egress action is tunnel encapsulation"; 2045 } 2046 leaf forwarding { 2047 type boolean; 2048 description 2049 "If egress action is forwarding"; 2050 } 2051 leaf redirection { 2052 type boolean; 2053 description 2054 "If egress action is redirection"; 2055 } 2056 } 2057 } 2058 } 2059 } 2060 container resolution-strategy { 2061 description 2062 "The resolution strategies can be used to 2063 specify how to resolve conflicts that occur between 2064 the actions of the same or different policy rules that 2065 are matched and contained in this particular NSF"; 2067 leaf first-matching-rule { 2068 type boolean; 2069 description 2070 "If the resolution strategy is first matching rule"; 2071 } 2073 leaf last-matching-rule { 2074 type boolean; 2075 description 2076 "If the resolution strategy is last matching rule"; 2077 } 2078 } 2079 container default-action { 2080 description 2081 "This default action can be used to specify a predefined 2082 action when no other alternative action was matched 2083 by the currently executing I2NSF Policy Rule. An analogy 2084 is the use of a default statement in a C switch statement."; 2086 container default-action-type { 2087 description 2088 "Ingress action type: permit, deny, and mirror."; 2090 container ingress-action-type { 2091 description 2092 "Ingress action type: permit, deny, and mirror."; 2093 leaf pass { 2094 type boolean; 2095 description 2096 "If ingress action is pass"; 2097 } 2098 leaf drop { 2099 type boolean; 2100 description 2101 "If ingress action is drop"; 2102 } 2103 leaf reject { 2104 type boolean; 2105 description 2106 "If ingress action is reject"; 2107 } 2108 leaf alert { 2109 type boolean; 2110 description 2111 "If ingress action is alert"; 2112 } 2113 leaf mirror { 2114 type boolean; 2115 description 2116 "If ingress action is mirror"; 2117 } 2118 } 2119 } 2120 } 2121 } 2122 } 2123 grouping i2nsf-con-sec-control-caps { 2124 description 2125 "i2nsf-con-sec-control-caps"; 2127 container con-sec-control-capabilities { 2128 description 2129 "content-security-control-capabilities"; 2131 leaf anti-virus { 2132 type boolean; 2133 description 2134 "antivirus"; 2135 } 2136 leaf ips { 2137 type boolean; 2138 description 2139 "ips"; 2140 } 2142 leaf ids { 2143 type boolean; 2144 description 2145 "ids"; 2146 } 2148 leaf url-filter { 2149 type boolean; 2150 description 2151 "url-filter"; 2152 } 2153 leaf data-filter { 2154 type boolean; 2155 description 2156 "data-filter"; 2157 } 2158 leaf mail-filter { 2159 type boolean; 2160 description 2161 "mail-filter"; 2162 } 2163 leaf sql-filter { 2164 type boolean; 2165 description 2166 "sql-filter"; 2167 } 2168 leaf file-blocking { 2169 type boolean; 2170 description 2171 "file-blocking"; 2172 } 2173 leaf file-isolate { 2174 type boolean; 2175 description 2176 "file-isolate"; 2177 } 2178 leaf pkt-capture { 2179 type boolean; 2180 description 2181 "pkt-capture"; 2182 } 2183 leaf application-behavior { 2184 type boolean; 2185 description 2186 "application-behavior"; 2187 } 2188 leaf voip-volte { 2189 type boolean; 2190 description 2191 "voip-volte"; 2192 } 2193 } 2195 } 2197 grouping i2nsf-attack-mitigation-control-caps { 2198 description 2199 "i2nsf-attack-mitigation-control-caps"; 2201 container attack-mitigation-capabilities { 2202 description 2203 "attack-mitigation-capabilities"; 2204 choice attack-mitigation-control-type { 2205 description 2206 "attack-mitigation-control-type"; 2207 case ddos-attack { 2208 description 2209 "ddos-attack"; 2210 choice ddos-attack-type { 2211 description 2212 "ddos-attack-type"; 2213 case network-layer-ddos-attack { 2214 description 2215 "network-layer-ddos-attack"; 2216 container network-layer-ddos-attack-types { 2217 description 2218 "network-layer-ddos-attack-type"; 2219 leaf syn-flood-attack { 2220 type boolean; 2221 description 2222 "syn-flood-attack"; 2223 } 2224 leaf udp-flood-attack { 2225 type boolean; 2226 description 2227 "udp-flood-attack"; 2228 } 2229 leaf icmp-flood-attack { 2230 type boolean; 2231 description 2232 "icmp-flood-attack"; 2233 } 2234 leaf ip-fragment-flood-attack { 2235 type boolean; 2236 description 2237 "ip-fragment-flood-attack"; 2238 } 2239 leaf ipv6-related-attack { 2240 type boolean; 2241 description 2242 "ip-fragment-flood-attack"; 2243 } 2244 } 2245 } 2246 case app-layer-ddos-attack { 2247 description 2248 "app-layer-ddos-attack"; 2249 container app-layer-ddos-attack-types { 2250 description 2251 "app-layer-ddos-attack-types"; 2252 leaf http-flood-attack { 2253 type boolean; 2254 description 2255 "http-flood-attack"; 2256 } 2257 leaf https-flood-attack { 2258 type boolean; 2259 description 2260 "https-flood-attack"; 2261 } 2262 leaf dns-flood-attack { 2263 type boolean; 2264 description 2265 "dns-flood-attack"; 2266 } 2267 leaf dns-amp-flood-attack { 2268 type boolean; 2269 description 2270 "dns-amp-flood-attack"; 2271 } 2272 leaf ssl-flood-attack { 2273 type boolean; 2274 description 2275 "ssl-flood-attack"; 2276 } 2277 } 2278 } 2279 } 2280 } 2282 case single-packet-attack { 2283 description 2284 "single-packet-attack"; 2285 choice single-packet-attack-type { 2286 description 2287 "single-packet-attack-type"; 2288 case scan-and-sniff-attack { 2289 description 2290 "scan-and-sniff-attack"; 2291 leaf ip-sweep-attack { 2292 type boolean; 2293 description 2294 "ip-sweep-attack"; 2295 } 2296 leaf port-scanning-attack { 2297 type boolean; 2298 description 2299 "port-scanning-attack"; 2300 } 2301 } 2302 case malformed-packet-attack { 2303 description 2304 "malformed-packet-attack"; 2305 leaf ping-of-death-attack { 2306 type boolean; 2307 description 2308 "ping-of-death-attack"; 2309 } 2310 leaf teardrop-attack { 2311 type boolean; 2312 description 2313 "teardrop-attack"; 2314 } 2315 } 2316 case special-packet-attack { 2317 description 2318 "special-packet-attack"; 2319 leaf oversized-icmp-attack { 2320 type boolean; 2321 description 2322 "oversized-icmp-attack"; 2323 } 2324 leaf tracert-attack { 2325 type boolean; 2326 description 2327 "tracert-attack"; 2328 } 2329 } 2330 } 2331 } 2332 } 2333 } 2334 } 2336 list nsf { 2337 key "nsf-name"; 2338 description 2339 "nsf-name"; 2340 leaf nsf-name { 2341 type string; 2342 mandatory true; 2343 description 2344 "nsf-name"; 2345 } 2346 uses capabilities-information; 2348 container generic-nsf-capabilities { 2349 description 2350 "generic-nsf-capabilities"; 2351 uses i2nsf-net-sec-caps; 2352 } 2353 } 2355 rpc call-appropriate-nsf { 2356 description 2357 "We can acquire appropriate NSF that we want 2358 If we give type of NSF that we want to use, 2359 we acquire the location information of NSF"; 2361 input { 2362 leaf nsf-type { 2363 type nsf-type; 2364 mandatory true; 2365 description 2366 "This is used to acquire NSF 2367 This is mandatory"; 2368 } 2369 uses i2nsf-it-resources; 2370 } 2371 output { 2372 uses i2nsf-nsf-location; 2373 } 2374 } 2375 } 2377 2379 Figure 10: YANG Data Module of I2NSF Capability 2381 8. IANA Considerations 2383 No IANA considerations exist for this document at this time. URL 2384 will be added. 2386 9. Security Considerations 2388 This document introduces no additional security threats and SHOULD 2389 follow the security requirements as stated in [i2nsf-framework]. 2391 10. Acknowledgments 2393 This work was supported by Institute for Information & communications 2394 Technology Promotion (IITP) grant funded by the Korea government 2395 (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence 2396 Technology Development for the Customized Security Service 2397 Provisioning). 2399 11. Contributors 2401 I2NSF is a group effort. I2NSF has had a number of contributing 2402 authors. The following are considered co-authors: 2404 o Hyoungshick Kim (Sungkyunkwan University) 2406 o Daeyoung Hyun (Sungkyunkwan University) 2408 o Dongjin Hong (Sungkyunkwan University) 2410 o Liang Xia (Huawei) 2412 o Jung-Soo Park (ETRI) 2414 o Tae-Jin Ahn (Korea Telecom) 2416 o Se-Hui Lee (Korea Telecom) 2418 12. References 2420 12.1. Normative References 2422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2423 Requirement Levels", BCP 14, RFC 2119, March 1997. 2425 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 2426 Network Configuration Protocol (NETCONF)", RFC 6020, 2427 October 2010. 2429 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 2430 and J. Jeong, "I2NSF Problem Statement and Use cases", 2431 RFC 8192, July 2017. 2433 12.2. Informative References 2435 [i2nsf-framework] 2436 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2437 Kumar, "Framework for Interface to Network Security 2438 Functions", draft-ietf-i2nsf-framework-08 (work in 2439 progress), October 2017. 2441 [i2nsf-nsf-cap-im] 2442 Xia, L., Strassner, J., Basile, C., and D. Lopez, 2443 "Information Model of NSFs Capabilities", draft-ietf- 2444 i2nsf-capability-00 (work in progress), September 2017. 2446 [i2nsf-nsf-yang] 2447 Kim, J., Jeong, J., Park, J., Hares, S., and L. Xia, 2448 "I2NSF Network Security Functions-Facing Interface YANG 2449 Data Model", draft-kim-i2nsf-nsf-facing-interface-data- 2450 model-03 (work in progress), October 2017. 2452 [i2nsf-sfc] 2453 Hyun, S., Jeong, J., Park, J., and S. Hares, "Service 2454 Function Chaining-Enabled I2NSF Architecture", draft-hyun- 2455 i2nsf-nsf-triggered-steering-03 (work in progress), July 2456 2017. 2458 [i2nsf-terminology] 2459 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 2460 Birkholz, "Interface to Network Security Functions (I2NSF) 2461 Terminology", draft-ietf-i2nsf-terminology-04 (work in 2462 progress), July 2017. 2464 [i2rs-rib-data-model] 2465 Wang, L., Ananthakrishnan, H., Chen, M., Dass, A., Kini, 2466 S., and N. Bahadur, "A YANG Data Model for Routing 2467 Information Base (RIB)", draft-ietf-i2rs-rib-data-model-08 2468 (work in progress), July 2017. 2470 [supa-policy-info-model] 2471 Strassner, J., Halpern, J., and S. Meer, "Generic Policy 2472 Information Model for Simplified Use of Policy 2473 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 2474 model-03 (work in progress), May 2017. 2476 Appendix A. Example: Extended VoIP-VoLTE Security Function Capabilities 2477 Module 2479 This section gives a simple example of how VoIP-VoLTE Security 2480 Function Capabilities module could be extended. 2482 module 2483 ex-voip-volte-capa { 2484 namespace "http://example.com/voip-volte-capa"; 2485 prefix "voip-volte-capa"; 2487 import ietf-i2nsf-capability { 2488 prefix capa; 2489 } 2491 augment "/capa:nsf/capa:generic-nsf-capabilities/" 2492 + "capa:net-sec-control-capabilities/" 2493 + "capa:condition/capa:condition-type" { 2494 case voice-condition { 2495 leaf sip-header-method { 2496 type boolean; 2497 description 2498 "SIP header method."; 2499 } 2501 leaf sip-header-uri { 2502 type boolean; 2503 description 2504 "SIP header URI."; 2505 } 2507 leaf sip-header-from { 2508 type boolean; 2509 description 2510 "SIP header From."; 2511 } 2513 leaf sip-header-to { 2514 type boolean; 2515 description 2516 "SIP header To."; 2517 } 2519 leaf sip-header-expire-time { 2520 type boolean; 2521 description 2522 "SIP header expire time."; 2524 } 2526 leaf sip-header-user-agent { 2527 type boolean; 2528 description 2529 "SIP header user agent."; 2530 } 2531 } 2532 } 2533 } 2535 Figure 11: Example: Extended VoIP-VoLTE Security Function 2536 Capabilities Module 2538 Appendix B. Example: Configuration XML of Capability Module 2540 This section gives a xml examples for a configuration of Capability 2541 module according to a requirement. 2543 B.1. Example: Configuration XML of Generic Network Security Function 2544 Capabilities 2546 This section gives a xml example for generic network security 2547 function capability configuration according to a requirement. 2549 Requirement: Register packet filter according to requirements. 2551 1. The location of the NSF is 221.159.112.150. 2553 2. The NSF can obtain the best effect if the packet was generated by 2554 PC or IoT. 2556 3. The NSF can apply policies according to time. 2558 4. The NSF should be able to block the source packets or destination 2559 packets with IPv4 address. 2561 5. The NSF should be able to pass, reject, or alert packets. 2563 6. Here is XML example for the generic network security function 2564 capability configuration: 2566 2567 2568 2569 2570 2571 2572 2573 2575 Huawei-Firewall 2576 2577 221.159.112.150 2578 2579 2580 true 2581 2582 2583 true 2584 2585 2586 2587 ipv4-packet-filter 2588 2589 true 2590 true 2591 2592 2593 2594 true 2595 true 2596 2597 2598 2599 2600 true 2601 true 2602 true 2603 2604 2605 2606 2607 2608 2609 2610 2612 Figure 12: Example: Configuration XML for Generic Network Security 2613 Function Capability 2615 B.2. Example: Configuration XML of Extended VoIP/VoLTE Security 2616 Function Capabilities Module 2618 This section gives a xml example for extended VoIP-VoLTE security 2619 function capabilities (See Figure 11) configuration according to a 2620 requirement. 2622 Requirement: Register VoIP/VoLTe security function according to 2623 requirements. 2625 1. The location of the NSF is 221.159.112.151. 2627 2. The NSF can obtain the best effect if the packet was generated by 2628 VoIP-VoLTE phone. 2630 3. The NSF should be able to block the malicious sip packets with 2631 user agent. 2633 4. The NSF should be able to pass, reject, or alert packets. 2635 Here is XML example for the VoIP-VoLTE security function capabilities 2636 configuration: 2638 2639 2640 2641 2642 2643 2644 2645 2647 Cisco-VoIP-VoLTE 2648 2649 221.159.112.151 2650 2651 2652 2653 sip-packet-filter 2654 2655 true 2656 2657 2658 2659 true 2660 true 2661 true 2662 2663 2664 2665 2666 2667 2668 2669 2671 Figure 13: Example: Configuration XML for Extended VoIP/VoLTE 2672 Security Function Capabilities 2674 Appendix C. draft-hares-i2nsf-capability-data-model-04 2676 The following changes are made from draft-hares-i2nsf-capability- 2677 data-model-04: 2679 1. Overview section is added to help explain of this Capability YANG 2680 data model. 2682 2. Objectives section is added to specify objectives of this 2683 Capability YANG data model. 2685 3. Capabilities of Event, Condition, Action, Resolution Strategy, 2686 and Default Action are added to express capabilities that NSFs 2687 can support. 2689 4. RPC is added to acquire an appropriate network security function 2690 according to type of NSF and/or target devices. 2692 5. This YANG data model is modified for vendors to be extended the 2693 YANG data model if they need specific capabilities for their 2694 devices. 2696 6. An example is added for extended the YANG data model about 2697 specific NSF. 2699 7. An examples are added about configuration XML for generic network 2700 security function and extended VoIP/VoLTE security function 2701 capabilities. 2703 Authors' Addresses 2705 Susan Hares 2706 Huawei 2707 7453 Hickory Hill 2708 Saline, MI 48176 2709 USA 2711 Phone: +1-734-604-0332 2712 EMail: shares@ndzh.com 2714 Jaehoon Paul Jeong 2715 Department of Software 2716 Sungkyunkwan University 2717 2066 Seobu-Ro, Jangan-Gu 2718 Suwon, Gyeonggi-Do 16419 2719 Republic of Korea 2721 Phone: +82 31 299 4957 2722 Fax: +82 31 290 7996 2723 EMail: pauljeong@skku.edu 2724 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2725 Jinyong Tim Kim 2726 Department of Computer Engineering 2727 Sungkyunkwan University 2728 2066 Seobu-Ro, Jangan-Gu 2729 Suwon, Gyeonggi-Do 16419 2730 Republic of Korea 2732 Phone: +82 10 8273 0930 2733 EMail: timkim@skku.edu 2735 Robert Moskowitz 2736 HTT Consulting 2737 Oak Park, MI 2738 USA 2740 Phone: +1-248-968-9809 2741 EMail: rgm@htt-consult.com 2743 Qiushi Lin 2744 Huawei 2745 Huawei Industrial Base 2746 Shenzhen, Guangdong 518129 2747 China 2749 EMail: linqiushi@huawei.com