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