idnits 2.17.1 draft-kim-i2nsf-nsf-facing-interface-data-model-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == 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 299 has weird spacing: '...everity enu...' == Line 307 has weird spacing: '...t-begin yan...' == Line 400 has weird spacing: '... tenant uin...' == Line 406 has weird spacing: '... tenant uin...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 2, 2017) is 2398 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Kim 3 Internet-Draft J. Jeong 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: April 5, 2018 J. Park 6 ETRI 7 S. Hares 8 L. Xia 9 Huawei 10 October 2, 2017 12 I2NSF Network Security Functions-Facing Interface YANG Data Model 13 draft-kim-i2nsf-nsf-facing-interface-data-model-03 15 Abstract 17 This document defines a YANG data model corresponding to the 18 information model for Network Security Functions (NSF)-Facing 19 Interface in the Interface to Network Security Functions (I2NSF) 20 framework. It describes a data model for the features provided by 21 generic security functions. This data model provides generic 22 components whose vendors is well understood so that the generic 23 component can be used even if it has some vendor specific functions. 24 These generic functions represent a point of interoperability, and 25 can be provided by any product that offers the required capabilities. 26 Also, if vendors need additional features for their NSFs, they can 27 add the features by extending the YANG data model. 29 Status of This Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on April 5, 2018. 52 Copyright Notice 54 Copyright (c) 2017 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Objective . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.1. Policy Identification . . . . . . . . . . . . . . . . . . 5 75 4.2. Event Policy . . . . . . . . . . . . . . . . . . . . . . . 5 76 4.3. Condition Policy . . . . . . . . . . . . . . . . . . . . . 6 77 4.4. Action Policy . . . . . . . . . . . . . . . . . . . . . . 6 78 4.5. Resolution Strategy Policy . . . . . . . . . . . . . . . . 6 79 4.6. Default Action Policy . . . . . . . . . . . . . . . . . . 6 80 5. Data Model Structure . . . . . . . . . . . . . . . . . . . . . 6 81 5.1. Network Security Policy Identification . . . . . . . . . . 7 82 5.2. Event Rule . . . . . . . . . . . . . . . . . . . . . . . . 7 83 5.3. Condition Rule . . . . . . . . . . . . . . . . . . . . . . 9 84 5.4. Action Rule . . . . . . . . . . . . . . . . . . . . . . . 11 85 5.5. Resolution Strategy Policy . . . . . . . . . . . . . . . . 12 86 5.6. Default Action Policy . . . . . . . . . . . . . . . . . . 13 87 6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 6.1. IETF NSF-Facing Interface YANG Data Module . . . . . . . . 14 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 91 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 46 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 47 95 Appendix A. Example: Extended VoIP-VoLTE Security Function 96 Module . . . . . . . . . . . . . . . . . . . . . . . 47 97 Appendix B. Example: XML Configuration of NSF-Facing 98 Interface Module . . . . . . . . . . . . . . . . . . 48 99 B.1. Example: XML Configuration of Generic Network Security 100 Function . . . . . . . . . . . . . . . . . . . . . . . . . 49 101 B.2. Example: XML Configuration of Extended VoIP-VoLTE 102 Security Function Module . . . . . . . . . . . . . . . . . 51 103 Appendix C. draft-kim-i2nsf-nsf-facing-interface-data-model-02 . 51 105 1. Introduction 107 This document defines a YANG [RFC6020] data model for the 108 configuration of security services provided by Network Security 109 Functions (NSF)-Facing Interface in the Interface to Network Security 110 Functions (I2NSF) framework [i2nsf-framework]. It provides the 111 corresponding data model for an information model of NSF-facing 112 interface for generic NSFs, as defined in [i2nsf-nsf-cap-im]. With 113 this data model, Security Controller can configure and control the 114 capabilities of NSFs [i2nsf-framework]. 116 The "Event-Condition-Action" (ECA) policy model is used as the basis 117 for the design of I2NSF policy rules. 119 The "ietf-i2nsf-nsf-facing-interface" YANG module defined in this 120 document provides the following features: 122 o Configuration of an identification for a generic NSF policy 124 o Configuration of an event for a generic NSF policy 126 o Configuration of a condition for a generic NSF policy 128 o Configuration of an action for a generic NSF policy 130 o Configuration of a strategy for a generic NSF policy 132 o Configuration of a default action for a generic NSF policy 134 2. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 3. Terminology 142 This document uses the terminology described in 143 [i2nsf-nsf-cap-im][i2rs-rib-data-model][supa-policy-info-model]. 144 Especially, the following terms are from [supa-policy-info-model]: 146 o Data Model: A data model is a representation of concepts of 147 interest to an environment in a form that is dependent on data 148 repository, data definition language, query language, 149 implementation language, and protocol. 151 o Information Model: An information model is a representation of 152 concepts of interest to an environment in a form that is 153 independent of data repository, data definition language, query 154 language, implementation language, and protocol. 156 3.1. Tree Diagrams 158 A simplified graphical representation of the data model is used in 159 this document. The meaning of the symbols in these diagrams 160 [i2rs-rib-data-model] is as follows: 162 o Brackets "[" and "]" enclose list keys. 164 o Abbreviations before data node names: "rw" means configuration 165 (read-write) and "ro" state data (read-only). 167 o Symbols after data node names: "?" means an optional node and "*" 168 denotes a "list" and "leaf-list". 170 o Parentheses enclose choice and case nodes, and case nodes are also 171 marked with a colon (":"). 173 o Ellipsis ("...") stands for contents of subtrees that are not 174 shown. 176 4. Objective 178 This section explains the objective of policy identification, event 179 policy, condition policy, action policy, resolution strategy policy, 180 and default action policy. The policies of event, condition, action, 181 resolution strategy, and default action are defined in 182 [i2nsf-nsf-cap-im]. 184 4.1. Policy Identification 186 This subsection explains the identification of a policy for a generic 187 NSF. Objects are defined for policy information and rule 188 information. 190 4.2. Event Policy 192 This subsection explains an event policy for a generic NSF. An event 193 capability is used to specify the capability about an event in a 194 managed system or the environment of the system. When used in the 195 context of I2NSF policy rules, it is used to determine whether the 196 condition clause of an I2NSF policy rule can be evaluated or not. 197 Objects are defined for a user security event, device security event, 198 system security event, and time security event. These objects can be 199 extended according to specific vendor event features. 201 4.3. Condition Policy 203 This subsection explains a condition policy for a generic NSF. A 204 condition is used to specify a policy with a set of attributes, 205 features, and values that are to be compared with a set of known 206 attributes, features, and values in order to determine whether or not 207 the set of actions in an imperative I2NSF policy rule can be executed 208 or not. Objects are defined for packet security condition, packet 209 payload security condition, target security condition, user security 210 condition, context condition, and generic context condition. These 211 objects can be extended according to specific vendor condition 212 features. 214 4.4. Action Policy 216 This subsection explains an action policy for a generic NSF. An 217 action is used to specify the policy to control and monitor aspects 218 of flow-based NSFs when the event and condition clauses are 219 satisfied. NSFs provide security functions by executing various 220 actions. Objects are defined for an ingress action, egress action, 221 and apply-profile (i.e., advanced action) action. These objects can 222 be extended according to specific vendor action features. 224 4.5. Resolution Strategy Policy 226 This subsection explains a resolution strategy policy for a generic 227 NSF. A resolution strategy policy can be used to specify a policy of 228 how to resolve policy rule conflicts that may occur among the actions 229 of the same or different policy rules that are matched and contained 230 in a particular NSF. Objects are defined for the first-matching-rule 231 policy and last-matching-rule policy. These objects can be extended 232 according to specific vendor resolution strategy features. 234 4.6. Default Action Policy 236 This subsection explains a default action policy for a generic NSF. 237 A default action policy can be used to specify a policy about a 238 predefined action when no other alternative action was matched by the 239 currently executed I2NSF policy rule. 241 5. Data Model Structure 243 This section shows the overview of a structure tree of generic NSFs 244 defined in the [i2nsf-nsf-cap-im]. 246 5.1. Network Security Policy Identification 248 The data model for the identification of a network security policy 249 has the following structure: 251 module: ietf-i2nsf-nsf-facing-interface 252 +--rw generic-nsf 253 +--rw net-sec-policy* [policy-name] 254 +--rw policy-name string 255 +--rw time-zone 256 | +--rw start-time? yang:date-and-time 257 | +--rw end-time? yang:date-and-time 258 +--rw eca-policy-rules* [rule-id] 259 | +--rw rule-id uint8 260 | +--rw rule-description? string 261 | +--rw rule-rev? uint8 262 | +--rw rule-priority? uint8 263 | +--rw event 264 | | ... 265 | +--rw condition 266 | | ... 267 | +--rw action 268 | ... 269 +--rw resolution-strategy 270 | ... 271 +--rw default-action 272 ... 274 Figure 1: Data Model Structure for Network Security Policy 275 Identification 277 5.2. Event Rule 279 The data model for an event rule has the following structure: 281 module: ietf-i2nsf-nsf-facing-interface 282 +--rw generic-nsf 283 +--rw net-sec-policy* [policy-name] 284 ... 285 +--rw eca-policy-rules* [rule-id] 286 | ... 287 | +--rw event 288 | | +--rw (event-type)? 289 | | +--:(usr-event) 290 | | | +--rw usr-manual? string 291 | | | +--rw usr-sec-event-content string 292 | | | +--rw usr-sec-event-format sec-event-format 293 | | | +--rw usr-sec-event-type enumeration 294 | | +--:(dev-event) 295 | | | +--rw dev-manual? string 296 | | | +--rw dev-sec-event-content string 297 | | | +--rw dev-sec-event-format sec-event-format 298 | | | +--rw dev-sec-event-type enumeration 299 | | | +--rw dev-sec-event-type-severity enumeration 300 | | +--:(sys-event) 301 | | | +--rw sys-manual? string 302 | | | +--rw sys-sec-event-content string 303 | | | +--rw sys-sec-event-format sec-event-format 304 | | | +--rw sys-sec-event-type enumeration 305 | | +--:(time-event) 306 | | +--rw time-manual? string 307 | | +--rw time-sec-event-begin yang:date-and-time 308 | | +--rw time-sec-event-end yang:date-and-time 309 | | +--rw time-sec-event-time-zone string 310 | +--rw condition 311 | | ... 312 | +--rw action 313 | ... 314 +--rw resolution-strategy 315 | ... 316 +--rw default-action 317 ... 319 Figure 2: Data Model Structure for Event Rule 321 Objects are defined for a user security event, device security event, 322 system security event, and time security event. These objects can be 323 extended according to specific vendor event features. We will add 324 additional event objects for more generic network security functions. 326 5.3. Condition Rule 328 The data model for a condition rule has the following structure: 330 module: ietf-i2nsf-nsf-facing-interface 331 +--rw generic-nsf 332 +--rw net-sec-policy* [policy-name] 333 ... 334 +--rw eca-policy-rules* [rule-id] 335 | ... 336 | +--rw event 337 | | ... 338 | +--rw condition 339 | | +--rw (condition-type)? 340 | | +--:(packet-security-condition) 341 | | | +--rw packet-manual? string 342 | | | +--rw packet-security-mac-condition 343 | | | | +--rw pkt-sec-cond-mac-dest* yang:phys-address 344 | | | | +--rw pkt-sec-cond-mac-src* yang:phys-address 345 | | | | +--rw pkt-sec-cond-mac-8021q* string 346 | | | | +--rw pkt-sec-cond-mac-ether-type* string 347 | | | | +--rw pkt-sec-cond-mac-tci* string 348 | | | +--rw packet-security-ipv4-condition 349 | | | | +--rw pkt-sec-cond-ipv4-header-length* uint8 350 | | | | +--rw pkt-sec-cond-ipv4-tos* uint8 351 | | | | +--rw pkt-sec-cond-ipv4-total-length* uint16 352 | | | | +--rw pkt-sec-cond-ipv4-id* uint8 353 | | | | +--rw pkt-sec-cond-ipv4-fragment* uint8 354 | | | | +--rw pkt-sec-cond-ipv4-fragment-offset* uint16 355 | | | | +--rw pkt-sec-cond-ipv4-ttl* uint8 356 | | | | +--rw pkt-sec-cond-ipv4-protocol* uint8 357 | | | | +--rw pkt-sec-cond-ipv4-src* inet:ipv4-address 358 | | | | +--rw pkt-sec-cond-ipv4-dest* inet:ipv4-address 359 | | | | +--rw pkt-sec-cond-ipv4-ipopts? string 360 | | | | +--rw pkt-sec-cond-ipv4-sameip? boolean 361 | | | | +--rw pkt-sec-cond-ipv4-geoip* string 362 | | | +--rw packet-security-ipv6-condition 363 | | | | +--rw pkt-sec-cond-ipv6-dscp* string 364 | | | | +--rw pkt-sec-cond-ipv6-ecn* string 365 | | | | +--rw pkt-sec-cond-ipv6-traffic-class* uint8 366 | | | | +--rw pkt-sec-cond-ipv6-flow-label* uint32 367 | | | | +--rw pkt-sec-cond-ipv6-payload-length* uint16 368 | | | | +--rw pkt-sec-cond-ipv6-next-header* uint8 369 | | | | +--rw pkt-sec-cond-ipv6-hop-limit* uint8 370 | | | | +--rw pkt-sec-cond-ipv6-src* inet:ipv6-address 371 | | | | +--rw pkt-sec-cond-ipv6-dest* inet:ipv6-address 372 | | | +--rw packet-security-tcp-condition 373 | | | | +--rw pkt-sec-cond-tcp-seq-num* uint32 374 | | | | +--rw pkt-sec-cond-tcp-ack-num* uint32 375 | | | | +--rw pkt-sec-cond-tcp-window-size* uint16 376 | | | | +--rw pkt-sec-cond-tcp-flags* uint8 377 | | | +--rw packet-security-udp-condition 378 | | | | +--rw pkt-sec-cond-udp-length* string 379 | | | +--rw packet-security-icmp-condition 380 | | | +--rw pkt-sec-cond-icmp-type* uint8 381 | | | +--rw pkt-sec-cond-icmp-code* uint8 382 | | | +--rw pkt-sec-cond-icmp-seg-num* uint32 383 | | +--:(packet-payload-condition) 384 | | | +--rw packet-payload-manual? string 385 | | | +--rw pkt-payload-content* string 386 | | +--:(target-condition) 387 | | | +--rw target-manual? string 388 | | | +--rw device-sec-context-cond 389 | | | +--rw pc? boolean 390 | | | +--rw mobile-phone? boolean 391 | | | +--rw voip-volte-phone? boolean 392 | | | +--rw tablet? boolean 393 | | | +--rw iot? boolean 394 | | | +--rw vehicle? boolean 395 | | +--:(users-condition) 396 | | | +--rw users-manual? string 397 | | | +--rw user 398 | | | | +--rw (user-name)? 399 | | | | +--:(tenant) 400 | | | | | +--rw tenant uint8 401 | | | | +--:(vn-id) 402 | | | | +--rw vn-id uint8 403 | | | +--rw group 404 | | | +--rw (group-name)? 405 | | | +--:(tenant) 406 | | | | +--rw tenant uint8 407 | | | +--:(vn-id) 408 | | | +--rw vn-id uint8 409 | | +--:(context-condition) 410 | | | +--rw context-manual? string 411 | | +--:(gen-context-condition) 412 | | +--rw gen-context-manual? string 413 | | +--rw geographic-location 414 | | +--rw src-geographic-location* uint32 415 | | +--rw dest-geographic-location* uint32 416 | +--rw action 417 | ... 418 +--rw resolution-strategy 419 | ... 420 +--rw default-action 421 ... 423 Figure 3: Data Model Structure for Condition Rule 425 Objects are defined for a packet security condition, packet payload 426 security condition, target security condition, user security 427 condition, context condition, and generic context condition. These 428 objects can be extended according to specific vendor condition 429 features. We will add additional condition objects for more generic 430 network security functions. 432 5.4. Action Rule 434 The data model for an action rule has the following structure: 436 module: ietf-i2nsf-nsf-facing-interface 437 +--rw generic-nsf 438 +--rw net-sec-policy* [policy-name] 439 ... 440 +--rw eca-policy-rules* [rule-id] 441 | ... 442 | +--rw event 443 | | ... 444 | +--rw condition 445 | | ... 446 | +--rw action 447 | +--rw (action-type)? 448 | +--:(ingress-action) 449 | | +--rw ingress-manual? string 450 | | +--rw ingress-action-type? ingress-action 451 | +--:(egress-action) 452 | | +--rw egress-manual? string 453 | | +--rw egress-action-type? egress-action 454 | +--:(apply-profile) 455 | +--rw profile-manual? string 456 | +--rw (apply-profile-action-type)? 457 | +--:(content-security-control) 458 | | +--rw content-security-control-types 459 | | +--rw antivirus? boolean 460 | | +--rw ips? boolean 461 | | +--rw ids? boolean 462 | | +--rw url-filtering? boolean 463 | | +--rw data-filtering? boolean 464 | | +--rw mail-filtering? boolean 465 | | +--rw file-blocking? boolean 466 | | +--rw file-isolate? boolean 467 | | +--rw pkt-capture? boolean 468 | | +--rw application-control? boolean 469 | | +--rw voip-volte? boolean 470 | +--:(attack-mitigation-control) 471 | +--rw (attack-mitigation-control-type)? 472 | +--:(ddos-attack) 473 | | +--rw ddos-attack-type 474 | | +--rw network-layer-ddos-attack 475 | | | +--rw network-layer-ddos-attack-type 476 | | | +--rw syn-flood? boolean 477 | | | +--rw udp-flood? boolean 478 | | | +--rw icmp-flood? boolean 479 | | | +--rw ip-frag-flood? boolean 480 | | | +--rw ipv6-related? boolean 481 | | +--rw app-layer-ddos-attack 482 | | +--rw app-ddos-attack-types 483 | | +--rw http-flood? boolean 484 | | +--rw https-flood? boolean 485 | | +--rw dns-flood? boolean 486 | | +--rw dns-amp-flood? boolean 487 | | +--rw ssl-ddos? boolean 488 | +--:(single-packet-attack) 489 | +--rw single-packet-attack-type 490 | +--rw scan-and-sniff-attack 491 | | +--rw scan-and-sniff-attack-types 492 | | +--rw ip-sweep? boolean 493 | | +--rw port-scanning? boolean 494 | +--rw malformed-packet-attack 495 | | +--rw malformed-packet-attack-types 496 | | +--rw ping-of-death? boolean 497 | | +--rw teardrop? boolean 498 | +--rw special-packet-attack 499 | +--rw special-packet-attack-types 500 | +--rw oversized-icmp? boolean 501 | +--rw tracert? boolean 502 +--rw resolution-strategy 503 | ... 504 +--rw default-action 505 ... 507 Figure 4: Data Model Structure for Action Rule 509 Objects are defined for an ingress action, egress action, and apply 510 profile action. These objects can be extended according to specific 511 vendor action feature. We will add additional action objects for 512 more generic network security functions. 514 5.5. Resolution Strategy Policy 516 The data model for a resolution strategy policy has the following 517 structure: 519 module: ietf-i2nsf-nsf-facing-interface 520 +--rw generic-nsf 521 +--rw net-sec-policy* [policy-name] 522 ... 523 +--rw eca-policy-rules* [rule-id] 524 | ... 525 | +--rw event 526 | | ... 527 | +--rw condition 528 | | ... 529 | +--rw action 530 | ... 531 +--rw resolution-strategy 532 | +--rw (resolution-strategy-type)? 533 | +--:(fmr) 534 | | +--rw first-matching-rule? boolean 535 | +--:(lmr) 536 | +--rw last-matching-rule? boolean 537 +--rw default-action 538 ... 540 Figure 5: Data Model Structure for Resolution Strategy Policy 542 Objects are defined for the first-matching-rule and last-matching- 543 rule policy. These objects can be extended according to specific 544 vendor resolution strategy features. We will add additional 545 resolution strategy objects for more generic network security 546 functions. 548 5.6. Default Action Policy 550 The data model for a default action policy has the following 551 structure: 553 module: ietf-i2nsf-nsf-facing-interface 554 +--rw generic-nsf 555 +--rw net-sec-policy* [policy-name] 556 ... 557 +--rw eca-policy-rules* [rule-id] 558 | ... 559 | +--rw event 560 | | ... 561 | +--rw condition 562 | | ... 563 | +--rw action 564 | ... 565 +--rw resolution-strategy 566 | ... 567 +--rw default-action 568 +--rw default-action-type? ingress-action 570 Figure 6: Data Model Structure for Default Action Policy 572 6. YANG Module 574 6.1. IETF NSF-Facing Interface YANG Data Module 576 This section introduces a YANG module for the information model of 577 network security functions, as defined in the [i2nsf-nsf-cap-im]. 579 file "ietf-i2nsf-nsf-facing-interface@2017-10-02.yang" 581 module ietf-i2nsf-nsf-facing-interface { 582 namespace 583 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-facing-interface"; 584 prefix 585 nsf-facing-interface; 587 import ietf-inet-types{ 588 prefix inet; 589 } 590 import ietf-yang-types{ 591 prefix yang; 592 } 594 organization 595 "IETF I2NSF (Interface to Network Security Functions) 596 Working Group"; 598 contact 599 "WG Web: 600 WG List: 601 WG Chair: Adrian Farrel 602 604 WG Chair: Linda Dunbar 605 607 Editor: Jingyong Tim Kim 608 610 Editor: Jaehoon Paul Jeong 611 613 Editor: Susan Hares 614 "; 616 description 617 "This module defines a YANG data module for network security 618 functions."; 619 revision "2017-10-02"{ 620 description "The first version"; 621 reference 622 "draft-ietf-i2nsf-capability-00"; 623 } 625 typedef sec-event-format { 626 type enumeration { 627 enum unknown { 628 description 629 "If SecEventFormat is unknown"; 630 } 631 enum guid { 632 description 633 "If SecEventFormat is GUID 634 (Generic Unique IDentifier)"; 635 } 636 enum uuid { 637 description 638 "If SecEventFormat is UUID 639 (Universal Unique IDentifier)"; 640 } 641 enum uri { 642 description 643 "If SecEventFormat is URI 644 (Uniform Resource Identifier)"; 645 } 646 enum fqdn { 647 description 648 "If SecEventFormat is FQDN 649 (Fully Qualified Domain Name)"; 650 } 651 enum fqpn { 652 description 653 "If SecEventFormat is FQPN 654 (Fully Qualified Path Name)"; 655 } 656 } 657 description 658 "This is used for SecEventFormat."; 659 } 661 typedef ingress-action { 662 type enumeration { 663 enum pass { 664 description 665 "If ingress action is pass"; 666 } 667 enum drop { 668 description 669 "If ingress action is drop"; 670 } 671 enum reject { 672 description 673 "If ingress action is reject"; 674 } 675 enum alert { 676 description 677 "If ingress action is alert"; 678 } 679 enum mirror { 680 description 681 "If ingress action is mirror"; 682 } 683 } 684 description 685 "This is used for ingress action."; 686 } 688 typedef egress-action { 689 type enumeration { 690 enum invoke-signaling { 691 description 692 "If egress action is invoke signaling"; 693 } 694 enum tunnel-encapsulation { 695 description 696 "If egress action is tunnel encapsulation"; 698 } 699 enum forwarding { 700 description 701 "If egress action is forwarding"; 702 } 703 enum redirection { 704 description 705 "If egress action is redirection"; 706 } 707 } 708 description 709 "This is used for egress action."; 710 } 712 container generic-nsf { 713 description 714 "Configuration for Generic Network Security Functions."; 716 list net-sec-policy { 717 key "policy-name"; 718 description 719 "policy is a list 720 including a set of security rules according to certain logic, 721 i.e., their similarity or mutual relations, etc. The network 722 security policy is able to apply over both the unidirectional 723 and bidirectional traffic across the NSF."; 725 leaf policy-name { 726 type string; 727 mandatory true; 728 description 729 "The name of the policy. 730 This must be unique."; 731 } 732 container time-zone { 733 description 734 "This can be used to apply rules according to time"; 735 leaf start-time { 736 type yang:date-and-time; 737 description 738 "This is start time for time zone"; 739 } 740 leaf end-time { 741 type yang:date-and-time; 742 description 743 "This is end time for time zone"; 744 } 745 } 747 list eca-policy-rules { 748 key "rule-id"; 749 description 750 "This is a rule for network security functions."; 752 leaf rule-id { 753 type uint8; 754 mandatory true; 755 description 756 "The id of the rule. 757 This must be unique."; 758 } 760 leaf rule-description { 761 type string; 762 description 763 "This description gives more information about 764 rules."; 765 } 767 leaf rule-rev { 768 type uint8; 769 description 770 "This shows rule version."; 771 } 773 leaf rule-priority { 774 type uint8; 775 description 776 "The priority keyword comes with a mandatory 777 numeric value which can range from 1 till 255."; 778 } 780 container event { 781 description 782 " This is abstract. An event is defined as any important 783 occurrence in time of a change in the system being 784 managed, and/or in the environment of the system being 785 managed. When used in the context of policy rules for 786 a flow-based NSF, it is used to determine whether the 787 Condition clause of the Policy Rule can be evaluated 788 or not. Examples of an I2NSF event include time and 789 user actions (e.g., logon, logoff, and actions that 790 violate any ACL.)."; 792 choice event-type { 793 description 794 "Vendors can use YANG data model to configure rules 795 by concreting this event type"; 796 case usr-event { 797 leaf usr-manual { 798 type string; 799 description 800 "This is manual for user event. 801 Vendors can write instructions for user event 802 that vendor made"; 803 } 805 leaf usr-sec-event-content { 806 type string; 807 mandatory true; 808 description 809 "This is a mandatory string that contains the content 810 of the UserSecurityEvent. The format of the content 811 is specified in the usrSecEventFormat class 812 attribute, and the type of event is defined in the 813 usrSecEventType class attribute. An example of the 814 usrSecEventContent attribute is a string hrAdmin, 815 with the usrSecEventFormat set to 1 (GUID) and the 816 usrSecEventType attribute set to 5 (new logon)."; 817 } 819 leaf usr-sec-event-format { 820 type sec-event-format; 821 mandatory true; 822 description 823 "This is a mandatory uint 8 enumerated integer, which 824 is used to specify the data type of the 825 usrSecEventContent attribute. The content is 826 specified in the usrSecEventContent class attribute, 827 and the type of event is defined in the 828 usrSecEventType class attribute. An example of the 829 usrSecEventContent attribute is string hrAdmin, 830 with the usrSecEventFormat attribute set to 1 (GUID) 831 and the usrSecEventType attribute set to 5 832 (new logon)."; 833 } 835 leaf usr-sec-event-type { 836 type enumeration { 837 enum unknown { 838 description 839 "If usrSecEventType is unknown"; 840 } 841 enum user-created { 842 description 843 "If usrSecEventType is new user 844 created"; 845 } 846 enum user-grp-created { 847 description 848 "If usrSecEventType is new user 849 group created"; 850 } 851 enum user-deleted { 852 description 853 "If usrSecEventType is user 854 deleted"; 855 } 856 enum user-grp-deleted { 857 description 858 "If usrSecEventType is user 859 group deleted"; 860 } 861 enum user-logon { 862 description 863 "If usrSecEventType is user 864 logon"; 865 } 866 enum user-logoff { 867 description 868 "If usrSecEventType is user 869 logoff"; 870 } 871 enum user-access-request { 872 description 873 "If usrSecEventType is user 874 access request"; 875 } 876 enum user-access-granted { 877 description 878 "If usrSecEventType is user 879 granted"; 880 } 881 enum user-access-violation { 882 description 883 "If usrSecEventType is user 884 violation"; 886 } 887 } 888 mandatory true; 889 description 890 "This is a mandatory uint 8 enumerated integer, which 891 is used to specify the type of event that involves 892 this user. The content and format are specified in 893 the usrSecEventContent and usrSecEventFormat class 894 attributes, respectively. An example of the 895 usrSecEventContent attribute is string hrAdmin, 896 with the usrSecEventFormat attribute set to 1 (GUID) 897 and the usrSecEventType attribute set to 5 898 (new logon)."; 899 } 901 } 902 case dev-event { 903 leaf dev-manual { 904 type string; 905 description 906 "This is manual for device event. 907 Vendors can write instructions for device event 908 that vendor made"; 909 } 911 leaf dev-sec-event-content { 912 type string; 913 mandatory true; 914 description 915 "This is a mandatory string that contains the content 916 of the DeviceSecurityEvent. The format of the 917 content is specified in the devSecEventFormat class 918 attribute, and the type of event is defined in the 919 devSecEventType class attribute. An example of the 920 devSecEventContent attribute is alarm, with the 921 devSecEventFormat attribute set to 1 (GUID), the 922 devSecEventType attribute set to 5 (new logon)."; 923 } 925 leaf dev-sec-event-format { 926 type sec-event-format; 927 mandatory true; 928 description 929 "This is a mandatory uint 8 enumerated integer, 930 which is used to specify the data type of the 931 devSecEventContent attribute."; 932 } 933 leaf dev-sec-event-type { 934 type enumeration { 935 enum unknown { 936 description 937 "If devSecEventType is unknown"; 938 } 939 enum comm-alarm { 940 description 941 "If devSecEventType is communications 942 alarm"; 943 } 944 enum quality-of-service-alarm { 945 description 946 "If devSecEventType is quality of service 947 alarm"; 948 } 949 enum process-err-alarm { 950 description 951 "If devSecEventType is processing error 952 alarm"; 953 } 954 enum equipment-err-alarm { 955 description 956 "If devSecEventType is equipment error 957 alarm"; 958 } 959 enum environmental-err-alarm { 960 description 961 "If devSecEventType is environmental error 962 alarm"; 963 } 964 } 965 mandatory true; 966 description 967 "This is a mandatory uint 8 enumerated integer, 968 which is used to specify the type of event 969 that was generated by this device."; 970 } 972 leaf dev-sec-event-type-severity { 973 type enumeration { 974 enum unknown { 975 description 976 "If devSecEventType is unknown"; 977 } 978 enum cleared { 979 description 980 "If devSecEventTypeSeverity is cleared"; 982 } 983 enum indeterminate { 984 description 985 "If devSecEventTypeSeverity is 986 indeterminate"; 987 } 988 enum critical { 989 description 990 "If devSecEventTypeSeverity is critical"; 991 } 992 enum major{ 993 description 994 "If devSecEventTypeSeverity is major"; 995 } 996 enum minor { 997 description 998 "If devSecEventTypeSeverity is minor"; 999 } 1000 enum warning { 1001 description 1002 "If devSecEventTypeSeverity is warning"; 1003 } 1005 } 1006 mandatory true; 1007 description 1008 "This is a mandatory uint 8 enumerated integer, 1009 which is used to specify the perceived 1010 severity of the event generated by this 1011 Device."; 1012 } 1014 } 1015 case sys-event { 1016 leaf sys-manual { 1017 type string; 1018 description 1019 "This is manual for system event. 1020 Vendors can write instructions for system event 1021 that vendor made"; 1022 } 1024 leaf sys-sec-event-content { 1025 type string; 1026 mandatory true; 1027 description 1028 "This is a mandatory string that contains a content 1029 of the SystemSecurityEvent. The format of a content 1030 is specified in a sysSecEventFormat class attribute, 1031 and the type of event is defined in the 1032 sysSecEventType class attribute. An example of the 1033 sysSecEventContent attribute is string sysadmin3, 1034 with the sysSecEventFormat attribute set to 1(GUID), 1035 and the sysSecEventType attribute set to 2 1036 (audit log cleared)."; 1037 } 1039 leaf sys-sec-event-format { 1040 type sec-event-format; 1041 mandatory true; 1042 description 1043 "This is a mandatory uint 8 enumerated integer, which 1044 is used to specify the data type of the 1045 sysSecEventContent attribute."; 1046 } 1048 leaf sys-sec-event-type { 1049 type enumeration { 1050 enum unknown { 1051 description 1052 "If sysSecEventType is unknown"; 1053 } 1054 enum audit-log-written-to { 1055 description 1056 "If sysSecEventTypeSeverity 1057 is that audit log is written to"; 1058 } 1059 enum audit-log-cleared { 1060 description 1061 "If sysSecEventTypeSeverity 1062 is that audit log is cleared"; 1063 } 1064 enum policy-created { 1065 description 1066 "If sysSecEventTypeSeverity 1067 is that policy is created"; 1068 } 1069 enum policy-edited{ 1070 description 1071 "If sysSecEventTypeSeverity 1072 is that policy is edited"; 1073 } 1074 enum policy-deleted{ 1075 description 1076 "If sysSecEventTypeSeverity 1077 is that policy is deleted"; 1079 } 1080 enum policy-executed{ 1081 description 1082 "If sysSecEventTypeSeverity 1083 is that policy is executed"; 1084 } 1085 } 1086 mandatory true; 1087 description 1088 "This is a mandatory uint 8 enumerated integer, which 1089 is used to specify the type of event that involves 1090 this device."; 1091 } 1093 } 1094 case time-event { 1095 leaf time-manual { 1096 type string; 1097 description 1098 "This is manual for time event. 1099 Vendors can write instructions for time event 1100 that vendor made"; 1101 } 1102 leaf time-sec-event-begin { 1103 type yang:date-and-time; 1104 mandatory true; 1105 description 1106 "This is a mandatory DateTime attribute, and 1107 represents the beginning of a time period. 1108 It has a value that has a date and/or a time 1109 component (as in the Java or Python libraries)."; 1110 } 1112 leaf time-sec-event-end { 1113 type yang:date-and-time; 1114 mandatory true; 1115 description 1116 "This is a mandatory DateTime attribute, and 1117 represents the end of a time period. It has 1118 a value that has a date and/or a time component 1119 (as in the Java or Python libraries). If this is 1120 a single event occurrence, and not a time period 1121 when the event can occur, then the 1122 timeSecEventPeriodEnd attribute may be ignored."; 1123 } 1125 leaf time-sec-event-time-zone { 1126 type string; 1127 mandatory true; 1128 description 1129 "This is a mandatory string attribute, and defines a 1130 time zone that this event occurred in using the 1131 format specified in ISO8601."; 1132 } 1133 } 1134 } 1136 } 1138 container condition { 1139 description 1140 " This is abstract. A condition is defined as a set 1141 of attributes, features, and/or values that are to be 1142 compared with a set of known attributes, features, 1143 and/or values in order to determine whether or not the 1144 set of Actions in that (imperative) I2NSF Policy Rule 1145 can be executed or not. Examples of I2NSF Conditions 1146 include matching attributes of a packet or flow, and 1147 comparing the internal state of an NSF to a desired 1148 state."; 1150 choice condition-type { 1151 description 1152 "Vendors can use YANG data model to configure rules 1153 by concreting this condition type"; 1155 case packet-security-condition { 1156 leaf packet-manual { 1157 type string; 1158 description 1159 "This is manual for packet condition. 1160 Vendors can write instructions for packet condition 1161 that vendor made"; 1162 } 1164 container packet-security-mac-condition { 1165 description 1166 "The purpose of this Class is to represent packet MAC 1167 packet header information that can be used as part of 1168 a test to determine if the set of Policy Actions in 1169 this ECA Policy Rule should be execute or not."; 1171 leaf-list pkt-sec-cond-mac-dest { 1172 type yang:phys-address; 1173 description 1174 "The MAC destination address (6 octets long)."; 1176 } 1178 leaf-list pkt-sec-cond-mac-src { 1179 type yang:phys-address; 1180 description 1181 "The MAC source address (6 octets long)."; 1182 } 1184 leaf-list pkt-sec-cond-mac-8021q { 1185 type string; 1186 description 1187 "This is an optional string attribute, and defines 1188 The 802.1Q tab value (2 octets long)."; 1189 } 1191 leaf-list pkt-sec-cond-mac-ether-type { 1192 type string; 1193 description 1194 "The EtherType field (2 octets long). Values up to 1195 and including 1500 indicate the size of the 1196 payload in octets; values of 1536 and above 1197 define which protocol is encapsulated in the 1198 payload of the frame."; 1199 } 1201 leaf-list pkt-sec-cond-mac-tci { 1202 type string; 1203 description 1204 "This is an optional string attribute, and defines 1205 the Tag Control Information. This consists of a 3 1206 bit user priority field, a drop eligible indicator 1207 (1 bit), and a VLAN identifier (12 bits)."; 1208 } 1209 } 1211 container packet-security-ipv4-condition { 1212 description 1213 "The purpose of this Class is to represent IPv4 1214 packet header information that can be used as 1215 part of a test to determine if the set of Policy 1216 Actions in this ECA Policy Rule should be executed 1217 or not."; 1219 leaf-list pkt-sec-cond-ipv4-header-length { 1220 type uint8; 1221 description 1222 "The IPv4 packet header consists of 14 fields, 1223 of which 13 are required."; 1225 } 1227 leaf-list pkt-sec-cond-ipv4-tos { 1228 type uint8; 1229 description 1230 "The ToS field could specify a datagram's priority 1231 and request a route for low-delay, 1232 high-throughput, or highly-reliable service.."; 1233 } 1235 leaf-list pkt-sec-cond-ipv4-total-length { 1236 type uint16; 1237 description 1238 "This 16-bit field defines the entire packet size, 1239 including header and data, in bytes."; 1240 } 1242 leaf-list pkt-sec-cond-ipv4-id { 1243 type uint8; 1244 description 1245 "This field is an identification field and is 1246 primarily used for uniquely identifying 1247 the group of fragments of a single IP datagram."; 1248 } 1250 leaf-list pkt-sec-cond-ipv4-fragment { 1251 type uint8; 1252 description 1253 "IP fragmentation is an Internet Protocol (IP) 1254 process that breaks datagrams into smaller pieces 1255 (fragments), so that packets may be formed that 1256 can pass through a link with a smaller maximum 1257 transmission unit (MTU) than the original 1258 datagram size."; 1259 } 1261 leaf-list pkt-sec-cond-ipv4-fragment-offset { 1262 type uint16; 1263 description 1264 "Fragment offset field along with Don't Fragment 1265 and More Fragment flags in the IP protocol 1266 header are used for fragmentation and reassembly 1267 of IP datagrams."; 1268 } 1270 leaf-list pkt-sec-cond-ipv4-ttl { 1271 type uint8; 1272 description 1273 "The ttl keyword is used to check for a specific 1274 IP time-to-live value in the header of 1275 a packet."; 1276 } 1278 leaf-list pkt-sec-cond-ipv4-protocol { 1279 type uint8; 1280 description 1281 "Internet Protocol version 4(IPv4) is the fourth 1282 version of the Internet Protocol (IP)."; 1283 } 1285 leaf-list pkt-sec-cond-ipv4-src { 1286 type inet:ipv4-address; 1287 description 1288 "Defines the IPv4 Source Address."; 1289 } 1291 leaf-list pkt-sec-cond-ipv4-dest { 1292 type inet:ipv4-address; 1293 description 1294 "Defines the IPv4 Destination Address."; 1295 } 1297 leaf pkt-sec-cond-ipv4-ipopts { 1298 type string; 1299 description 1300 "With the ipopts keyword you can check if 1301 a specific ip option is set. Ipopts has 1302 to be used at the beginning of a rule."; 1303 } 1305 leaf pkt-sec-cond-ipv4-sameip { 1306 type boolean; 1307 description 1308 "Every packet has a source IP-address and 1309 a destination IP-address. It can be that 1310 the source IP is the same as 1311 the destination IP."; 1312 } 1314 leaf-list pkt-sec-cond-ipv4-geoip { 1315 type string; 1316 description 1317 "The geoip keyword enables you to match on 1318 the source, destination or source and destination 1319 IP addresses of network traffic and to see to 1320 which country it belongs. To do this, Suricata 1321 uses GeoIP API with MaxMind database format."; 1322 } 1323 } 1325 container packet-security-ipv6-condition { 1326 description 1327 "The purpose of this Class is to represent packet 1328 IPv6 packet header information that can be used as 1329 part of a test to determine if the set of Policy 1330 Actions in this ECA Policy Rule should be executed 1331 or not."; 1333 leaf-list pkt-sec-cond-ipv6-dscp { 1334 type string; 1335 description 1336 "Differentiated Services Code Point (DSCP) 1337 of ipv6."; 1338 } 1340 leaf-list pkt-sec-cond-ipv6-ecn { 1341 type string; 1342 description 1343 "ECN allows end-to-end notification of network 1344 congestion without dropping packets."; 1345 } 1347 leaf-list pkt-sec-cond-ipv6-traffic-class { 1348 type uint8; 1349 description 1350 "The bits of this field hold two values. The 6 1351 most-significant bits are used for 1352 differentiated services, which is used to 1353 classify packets."; 1354 } 1356 leaf-list pkt-sec-cond-ipv6-flow-label { 1357 type uint32; 1358 description 1359 "The flow label when set to a non-zero value 1360 serves as a hint to routers and switches 1361 with multiple outbound paths that these 1362 packets should stay on the same path so that 1363 they will not be reordered."; 1364 } 1366 leaf-list pkt-sec-cond-ipv6-payload-length { 1367 type uint16; 1368 description 1369 "The size of the payload in octets, 1370 including any extension headers."; 1371 } 1373 leaf-list pkt-sec-cond-ipv6-next-header { 1374 type uint8; 1375 description 1376 "Specifies the type of the next header. 1377 This field usually specifies the transport 1378 layer protocol used by a packet's payload."; 1379 } 1381 leaf-list pkt-sec-cond-ipv6-hop-limit { 1382 type uint8; 1383 description 1384 "Replaces the time to live field of IPv4."; 1385 } 1387 leaf-list pkt-sec-cond-ipv6-src { 1388 type inet:ipv6-address; 1389 description 1390 "The IPv6 address of the sending node."; 1391 } 1393 leaf-list pkt-sec-cond-ipv6-dest { 1394 type inet:ipv6-address; 1395 description 1396 "The IPv6 address of the destination node(s)."; 1397 } 1398 } 1400 container packet-security-tcp-condition { 1401 description 1402 "The purpose of this Class is to represent packet 1403 TCP packet header information that can be used as 1404 part of a test to determine if the set of Policy 1405 Actions in this ECA Policy Rule should be executed 1406 or not."; 1408 leaf-list pkt-sec-cond-tcp-seq-num { 1409 type uint32; 1410 description 1411 "If the SYN flag is set (1), then this is the 1412 initial sequence number."; 1413 } 1415 leaf-list pkt-sec-cond-tcp-ack-num { 1416 type uint32; 1417 description 1418 "If the ACK flag is set then the value of this 1419 field is the next sequence number that the sender 1420 is expecting."; 1421 } 1423 leaf-list pkt-sec-cond-tcp-window-size { 1424 type uint16; 1425 description 1426 "The size of the receive window, which specifies 1427 the number of windows size units 1428 (by default,bytes) (beyond the segment 1429 identified by the sequence number in the 1430 acknowledgment field) that the sender of this 1431 segment is currently willing to recive."; 1432 } 1434 leaf-list pkt-sec-cond-tcp-flags { 1435 type uint8; 1436 description 1437 "This is a mandatory string attribute, and defines 1438 the nine Control bit flags (9 bits)."; 1439 } 1440 } 1442 container packet-security-udp-condition { 1443 description 1444 "The purpose of this Class is to represent packet UDP 1445 packet header information that can be used as part 1446 of a test to determine if the set of Policy Actions 1447 in this ECA Policy Rule should be executed or not."; 1449 leaf-list pkt-sec-cond-udp-length { 1450 type string; 1451 description 1452 "This is a mandatory string attribute, and defines 1453 the length in bytes of the UDP header and data 1454 (16 bits)."; 1455 } 1456 } 1458 container packet-security-icmp-condition { 1459 description 1460 "The internet control message protocol condition."; 1462 leaf-list pkt-sec-cond-icmp-type { 1463 type uint8; 1464 description 1465 "ICMP type, see Control messages."; 1466 } 1468 leaf-list pkt-sec-cond-icmp-code { 1469 type uint8; 1470 description 1471 "ICMP subtype, see Control messages."; 1472 } 1474 leaf-list pkt-sec-cond-icmp-seg-num { 1475 type uint32; 1476 description 1477 "The icmp Sequence Number."; 1478 } 1479 } 1480 } 1482 case packet-payload-condition { 1483 leaf packet-payload-manual { 1484 type string; 1485 description 1486 "This is manual for payload condition. 1487 Vendors can write instructions for payload condition 1488 that vendor made"; 1489 } 1490 leaf-list pkt-payload-content { 1491 type string; 1492 description 1493 "The content keyword is very important in 1494 signatures. Between the quotation marks you 1495 can write on what you would like the 1496 signature to match."; 1497 } 1498 } 1499 case target-condition { 1500 leaf target-manual { 1501 type string; 1502 description 1503 "This is manual for target condition. 1504 Vendors can write instructions for target condition 1505 that vendor made"; 1506 } 1508 container device-sec-context-cond { 1509 description 1510 "The device attribute that can identify a device, 1511 including the device type (i.e., router, switch, 1512 pc, ios, or android) and the device's owner as 1513 well."; 1515 leaf pc { 1516 type boolean; 1517 description 1518 "If type of a device is PC."; 1519 } 1521 leaf mobile-phone { 1522 type boolean; 1523 description 1524 "If type of a device is mobile-phone."; 1525 } 1527 leaf voip-volte-phone { 1528 type boolean; 1529 description 1530 "If type of a device is voip-volte-phone."; 1531 } 1533 leaf tablet { 1534 type boolean; 1535 description 1536 "If type of a device is tablet."; 1537 } 1539 leaf iot { 1540 type boolean; 1541 description 1542 "If type of a device is Internet of Things."; 1543 } 1545 leaf vehicle { 1546 type boolean; 1547 description 1548 "If type of a device is vehicle."; 1549 } 1550 } 1551 } 1552 case users-condition { 1553 leaf users-manual { 1554 type string; 1555 description 1556 "This is manual for user condition. 1557 Vendors can write instructions for user condition 1558 that vendor made"; 1559 } 1560 container user{ 1561 description 1562 "The user (or user group) information with which 1563 network flow is associated: The user has many 1564 attributes such as name, id, password, type, 1565 authentication mode and so on. Name/id is often 1566 used in the security policy to identify the user. 1567 Besides, NSF is aware of the IP address of the 1568 user provided by a unified user management system 1569 via network. Based on name-address association, 1570 NSF is able to enforce the security functions 1571 over the given user (or user group)"; 1573 choice user-name { 1574 description 1575 "The name of the user. 1576 This must be unique."; 1578 case tenant { 1579 description 1580 "Tenant information."; 1582 leaf tenant { 1583 type uint8; 1584 mandatory true; 1585 description 1586 "User's tenant information."; 1587 } 1588 } 1590 case vn-id { 1591 description 1592 "VN-ID information."; 1594 leaf vn-id { 1595 type uint8; 1596 mandatory true; 1597 description 1598 "User's VN-ID information."; 1599 } 1600 } 1601 } 1602 } 1603 container group { 1604 description 1605 "The user (or user group) information with which 1606 network flow is associated: The user has many 1607 attributes such as name, id, password, type, 1608 authentication mode and so on. Name/id is often 1609 used in the security policy to identify the user. 1610 Besides, NSF is aware of the IP address of the 1611 user provided by a unified user management system 1612 via network. Based on name-address association, 1613 NSF is able to enforce the security functions 1614 over the given user (or user group)"; 1616 choice group-name { 1617 description 1618 "The name of the user. 1619 This must be unique."; 1621 case tenant { 1622 description 1623 "Tenant information."; 1625 leaf tenant { 1626 type uint8; 1627 mandatory true; 1628 description 1629 "User's tenant information."; 1630 } 1631 } 1633 case vn-id { 1634 description 1635 "VN-ID information."; 1637 leaf vn-id { 1638 type uint8; 1639 mandatory true; 1640 description 1641 "User's VN-ID information."; 1642 } 1643 } 1644 } 1645 } 1647 } 1648 case context-condition { 1649 leaf context-manual { 1650 type string; 1651 description 1652 "This is manual for context condition. 1653 Vendors can write instructions for context condition 1654 that vendor made"; 1655 } 1657 } 1658 case gen-context-condition { 1659 leaf gen-context-manual { 1660 type string; 1661 description 1662 "This is manual for generic context condition. 1663 Vendors can write instructions for generic context 1664 condition that vendor made"; 1665 } 1667 container geographic-location { 1668 description 1669 "The location where network traffic is associated 1670 with. The region can be the geographic location 1671 such as country, province, and city, 1672 as well as the logical network location such as 1673 IP address, network section, and network domain."; 1675 leaf-list src-geographic-location { 1676 type uint32; 1677 description 1678 "This is mapped to ip address. We can acquire 1679 source region through ip address stored the 1680 database."; 1681 } 1682 leaf-list dest-geographic-location { 1683 type uint32; 1684 description 1685 "This is mapped to ip address. We can acquire 1686 destination region through ip address stored 1687 the database."; 1688 } 1689 } 1690 } 1691 } 1692 } 1693 container action { 1694 description 1695 "An action is used to control and monitor aspects of 1696 flow-based NSFs when the event and condition clauses 1697 are satisfied. NSFs provide security functions by 1698 executing various Actions. Examples of I2NSF Actions 1699 include providing intrusion detection and/or protection, 1700 web and flow filtering, and deep packet inspection 1701 for packets and flows."; 1703 choice action-type { 1704 description 1705 "Vendors can use YANG data model to configure rules 1706 by concreting this action type"; 1707 case ingress-action { 1708 leaf ingress-manual { 1709 type string; 1710 description 1711 "This is manual for ingress action. 1712 Vendors can write instructions for ingress action 1713 that vendor made"; 1714 } 1715 leaf ingress-action-type { 1716 type ingress-action; 1717 description 1718 "Ingress action type: permit, deny, and mirror."; 1719 } 1720 } 1721 case egress-action { 1722 leaf egress-manual { 1723 type string; 1724 description 1725 "This is manual for egress action. 1726 Vendors can write instructions for egress action 1727 that vendor made"; 1728 } 1729 leaf egress-action-type { 1730 type egress-action; 1731 description 1732 "Egress-action-type: invoke-signaling, 1733 tunnel-encapsulation, and forwarding."; 1734 } 1735 } 1736 case apply-profile { 1737 leaf profile-manual { 1738 type string; 1739 description 1740 "This is manual for apply profile action. 1741 Vendors can write instructions for apply 1742 profile action that vendor made"; 1743 } 1745 choice apply-profile-action-type { 1746 description 1747 "Advanced action types: Content Security Control 1748 and Attack Mitigation Control."; 1750 case content-security-control { 1751 description 1752 "Content security control is another category of 1753 security capabilities applied to application layer. 1754 Through detecting the contents carried over the 1755 traffic in application layer, these capabilities 1756 can realize various security purposes, such as 1757 defending against intrusion, inspecting virus, 1758 filtering malicious URL or junk email, and blocking 1759 illegal web access or data retrieval."; 1761 container content-security-control-types { 1762 description 1763 "Content Security types: Antivirus, IPS, IDS, 1764 url-filtering, data-filtering, mail-filtering, 1765 file-blocking, file-isolate, pkt-capture, 1766 application-control, and voip-volte."; 1768 leaf antivirus { 1769 type boolean; 1770 description 1771 "Additional inspection of antivirus."; 1772 } 1774 leaf ips { 1775 type boolean; 1776 description 1777 "Additional inspection of IPS."; 1778 } 1780 leaf ids { 1781 type boolean; 1782 description 1783 "Additional inspection of IDS."; 1784 } 1786 leaf url-filtering { 1787 type boolean; 1788 description 1789 "Additional inspection of URL filtering."; 1790 } 1792 leaf data-filtering { 1793 type boolean; 1794 description 1795 "Additional inspection of data filtering."; 1796 } 1798 leaf mail-filtering { 1799 type boolean; 1800 description 1801 "Additional inspection of mail filtering."; 1802 } 1804 leaf file-blocking { 1805 type boolean; 1806 description 1807 "Additional inspection of file blocking."; 1808 } 1810 leaf file-isolate { 1811 type boolean; 1812 description 1813 "Additional inspection of file isolate."; 1814 } 1816 leaf pkt-capture { 1817 type boolean; 1818 description 1819 "Additional inspection of packet capture."; 1820 } 1822 leaf application-control { 1823 type boolean; 1824 description 1825 "Additional inspection of app control."; 1826 } 1828 leaf voip-volte { 1829 type boolean; 1830 description 1831 "Additional inspection of VoIP/VoLTE."; 1832 } 1833 } 1834 } 1836 case attack-mitigation-control { 1837 description 1838 "This category of security capabilities is 1839 specially used to detect and mitigate various 1840 types of network attacks."; 1842 choice attack-mitigation-control-type { 1843 description 1844 "Attack-mitigation types: DDoS-attack and 1845 Single-packet attack."; 1847 case ddos-attack { 1848 description 1849 "A distributed-denial-of-service (DDoS) is 1850 where the attack source is more than one, 1851 often thousands of unique IP addresses."; 1853 container ddos-attack-type { 1854 description 1855 "DDoS-attack types: Network Layer 1856 DDoS Attacks and Application Layer 1857 DDoS Attacks."; 1859 container network-layer-ddos-attack { 1860 description 1861 "Network layer DDoS-attack."; 1862 container network-layer-ddos-attack-type { 1863 description 1864 "Network layer DDoS attack types: 1865 Syn Flood Attack, UDP Flood Attack, 1866 ICMP Flood Attack, IP Fragment Flood, 1867 IPv6 Related Attacks, and etc"; 1869 leaf syn-flood { 1870 type boolean; 1871 description 1872 "Additional Inspection of 1873 Syn Flood Attack."; 1874 } 1876 leaf udp-flood { 1877 type boolean; 1878 description 1879 "Additional Inspection of 1880 UDP Flood Attack."; 1881 } 1883 leaf icmp-flood { 1884 type boolean; 1885 description 1886 "Additional Inspection of 1887 ICMP Flood Attack."; 1888 } 1890 leaf ip-frag-flood { 1891 type boolean; 1892 description 1893 "Additional Inspection of 1894 IP Fragment Flood."; 1895 } 1896 leaf ipv6-related { 1897 type boolean; 1898 description 1899 "Additional Inspection of 1900 IPv6 Related Attacks."; 1901 } 1902 } 1903 } 1905 container app-layer-ddos-attack { 1906 description 1907 "Application layer DDoS-attack."; 1909 container app-ddos-attack-types { 1910 description 1911 "Application layer DDoS-attack types: 1912 Http Flood Attack, Https Flood Attack, 1913 DNS Flood Attack, and 1914 DNS Amplification Flood Attack, 1915 SSL DDoS Attack, and etc."; 1917 leaf http-flood { 1918 type boolean; 1919 description 1920 "Additional Inspection of 1921 Http Flood Attack."; 1922 } 1924 leaf https-flood { 1925 type boolean; 1926 description 1927 "Additional Inspection of 1928 Https Flood Attack."; 1929 } 1931 leaf dns-flood { 1932 type boolean; 1933 description 1934 "Additional Inspection of 1935 DNS Flood Attack."; 1936 } 1938 leaf dns-amp-flood { 1939 type boolean; 1940 description 1941 "Additional Inspection of 1942 DNS Amplification Flood Attack."; 1943 } 1944 leaf ssl-ddos { 1945 type boolean; 1946 description 1947 "Additional Inspection of 1948 SSL Flood Attack."; 1949 } 1950 } 1951 } 1952 } 1953 } 1955 case single-packet-attack { 1956 description 1957 "Single Packet Attacks."; 1958 container single-packet-attack-type { 1959 description 1960 "DDoS-attack types: Scanning Attack, 1961 Sniffing Attack, Malformed Packet Attack, 1962 Special Packet Attack, and etc."; 1964 container scan-and-sniff-attack { 1965 description 1966 "Scanning and Sniffing Attack."; 1967 container scan-and-sniff-attack-types { 1968 description 1969 "Scanning and sniffing attack types: 1970 IP Sweep attack, Port Scanning, 1971 and etc."; 1973 leaf ip-sweep { 1974 type boolean; 1975 description 1976 "Additional Inspection of 1977 IP Sweep Attack."; 1978 } 1980 leaf port-scanning { 1981 type boolean; 1982 description 1983 "Additional Inspection of 1984 Port Scanning Attack."; 1985 } 1986 } 1987 } 1989 container malformed-packet-attack { 1990 description 1991 "Malformed Packet Attack."; 1993 container malformed-packet-attack-types { 1994 description 1995 "Malformed packet attack types: 1996 Ping of Death Attack, Teardrop Attack, 1997 and etc."; 1999 leaf ping-of-death { 2000 type boolean; 2001 description 2002 "Additional Inspection of 2003 Ping of Death Attack."; 2004 } 2006 leaf teardrop { 2007 type boolean; 2008 description 2009 "Additional Inspection of 2010 Teardrop Attack."; 2011 } 2012 } 2013 } 2015 container special-packet-attack { 2016 description 2017 "special Packet Attack."; 2018 container special-packet-attack-types { 2019 description 2020 "Special packet attack types: 2021 Oversized ICMP Attack, Tracert Attack, 2022 and etc."; 2024 leaf oversized-icmp { 2025 type boolean; 2026 description 2027 "Additional Inspection of 2028 Oversize ICMP Attack."; 2029 } 2031 leaf tracert { 2032 type boolean; 2033 description 2034 "Additional Inspection of 2035 Tracrt Attack."; 2036 } 2037 } 2038 } 2039 } 2040 } 2042 } 2043 } 2044 } 2045 } 2046 } 2047 } 2048 } 2050 container resolution-strategy { 2051 description 2052 "The resolution strategies can be used to 2053 specify how to resolve conflicts that occur between 2054 the actions of the same or different policy rules that 2055 are matched and contained in this particular NSF"; 2057 choice resolution-strategy-type { 2058 description 2059 "Vendors can use YANG data model to configure rules"; 2061 case fmr { 2062 leaf first-matching-rule { 2063 type boolean; 2064 description 2065 "If the resolution strategy is first matching rule"; 2066 } 2067 } 2068 case lmr { 2069 leaf last-matching-rule { 2070 type boolean; 2071 description 2072 "If the resolution strategy is last matching rule"; 2073 } 2074 } 2076 } 2077 } 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 leaf default-action-type { 2087 type ingress-action; 2088 description 2089 "Ingress action type: permit, deny, and mirror."; 2090 } 2091 } 2092 } 2093 } 2094 } 2096 2098 Figure 7: YANG Data Module of I2NSF NSF-Facing-Interface 2100 7. Security Considerations 2102 This document introduces no additional security threats and follows 2103 the security requirements as stated in [i2nsf-framework]. 2105 8. Acknowledgments 2107 This work was supported by Institute for Information & communications 2108 Technology Promotion (IITP) grant funded by the Korea government 2109 (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence 2110 Technology Development for the Customized Security Service 2111 Provisioning). 2113 9. Contributors 2115 I2NSF is a group effort. I2NSF has had a number of contributing 2116 authors. The following are considered co-authors: 2118 o Hyoungshick Kim (Sungkyunkwan University) 2120 o Daeyoung Hyun (Sungkyunkwan University) 2122 o Dongjin Hong (Sungkyunkwan University) 2124 o Jung-Soo Park (ETRI) 2126 o Tae-Jin Ahn (Korea Telecom) 2128 o Se-Hui Lee (Korea Telecom) 2130 10. References 2132 10.1. Normative References 2134 [RFC2119] Bradner, S., "Key words for use in RFCs to 2135 Indicate Requirement Levels", BCP 14, 2136 RFC 2119, March 1997. 2138 [RFC6020] Bjorklund, M., "YANG - A Data Modeling 2139 Language for the Network Configuration 2140 Protocol (NETCONF)", RFC 6020, 2141 October 2010. 2143 10.2. Informative References 2145 [i2nsf-nsf-cap-im] Xia, L., Strassner, J., Basile, C., and D. 2146 Lopez, "Information Model of NSFs 2147 Capabilities", 2148 draft-ietf-i2nsf-capability-00 (work in 2149 progress), September 2017. 2151 [i2rs-rib-data-model] Wang, L., Ananthakrishnan, H., Chen, M., 2152 Dass, A., Kini, S., and N. Bahadur, "A YANG 2153 Data Model for Routing Information Base 2154 (RIB)", draft-ietf-i2rs-rib-data-model-08 2155 (work in progress), July 2017. 2157 [supa-policy-info-model] Strassner, J., Halpern, J., and S. Meer, 2158 "Generic Policy Information Model for 2159 Simplified Use of Policy Abstractions 2160 (SUPA)", draft-ietf-supa-generic-policy- 2161 info-model-03 (work in progress), May 2017. 2163 [i2nsf-framework] Lopez, D., Lopez, E., Dunbar, L., 2164 Strassner, J., and R. Kumar, "Framework for 2165 Interface to Network Security Functions", 2166 draft-ietf-i2nsf-framework-07 (work in 2167 progress), August 2017. 2169 Appendix A. Example: Extended VoIP-VoLTE Security Function Module 2171 This section gives a simple example of how VoIP-VoLTE Security 2172 Function module could be extended. 2174 module 2175 ex-voip-volte { 2176 namespace "http://example.com/voip-volte"; 2177 prefix "voip-volte"; 2179 import ietf-i2nsf-nsf-facing-interface{ 2180 prefix nsf; 2181 } 2183 augment "/nsf:generic-nsf/nsf:policy/nsf:rules/nsf:condition/" + 2184 "nsf:condition-type" { 2186 case voice-condition { 2187 leaf sip-header-method { 2188 type string; 2189 description 2190 "SIP header method."; 2191 } 2193 leaf sip-header-uri { 2194 type string; 2195 description 2196 "SIP header URI."; 2197 } 2199 leaf sip-header-from { 2200 type string; 2201 description 2202 "SIP header From."; 2203 } 2205 leaf sip-header-to { 2206 type string; 2207 description 2208 "SIP header To."; 2209 } 2211 leaf sip-header-expire-time { 2212 type yang:date-and-time; 2213 description 2214 "SIP header expire time."; 2215 } 2217 leaf sip-header-user-agent { 2218 type uint32; 2219 description 2220 "SIP header user agent."; 2221 } 2222 } 2223 } 2224 } 2226 Figure 8: Example: Extended VoIP-VoLTE Security Function Module 2228 Appendix B. Example: XML Configuration of NSF-Facing Interface Module 2230 This section gives an XML example for a configuration of NSF-Facing 2231 Interface module according to a requirement. 2233 B.1. Example: XML Configuration of Generic Network Security Function 2235 This section gives an XML example for a generic NSF configuration 2236 according to a requirement. 2238 Requirement: Prevent Facebook (e.g., 31.13.68.35) access during 2239 business hours (i.e., from 9AM to 6PM) to improve work efficiency of 2240 employees (e.g., from 221.159.112.1 to 221.159.112.9). 2242 Here is an XML example for a generic NSF configuration: 2244 2245 2246 2247 2248 2249 2250 2251 2253 2254 i2nsf-facebook-filter 2255 2256 09:00:00Z 2257 18:00:00Z 2258 2259 2260 facebook-block 2261 2262 2263 2264 221.159.112.1 2265 221.159.112.2 2266 221.159.112.3 2267 221.159.112.4 2268 221.159.112.5 2269 221.159.112.6 2270 221.159.112.7 2271 221.159.112.8 2272 221.159.112.9 2273 31.13.13.68 2274 2275 2276 2277 2278 reject 2279 2280 2281 2282 2283 2284 2285 2287 Figure 9: Example: Configuration XML for Generic Network Security 2288 Function 2290 B.2. Example: XML Configuration of Extended VoIP-VoLTE Security 2291 Function Module 2293 This section gives an XML example for an extended VoIP-VoLTE security 2294 function (See Figure 8) configuration according to a requirement. 2296 Requirement: Block the packets of SIP if the values of user agent are 2297 either eyebeam or friendyly-scanner. 2299 Here is an XML example for a VoIP-VoLTE security function 2300 configuration: 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 voip-volte 2312 2313 malicious-sip 2314 2315 eyebeam 2316 friendyly-scanner 2317 2318 2319 reject 2320 2321 2322 2323 2324 2325 2326 2328 Figure 10: Example: Configuration XML for Extended VoIP/VoLTE 2329 Security Function 2331 Appendix C. draft-kim-i2nsf-nsf-facing-interface-data-model-02 2333 The following changes are made from 2334 draft-kim-i2nsf-nsf-facing-interface-data-model-02: 2336 1. Objective Section is added to specify the objective of this YANG 2337 data model. 2339 2. Resolution Strategy is added to specify how to resolve policy 2340 rule conflicts that may occur among the actions of the same or 2341 different policy rules that are matched and contained in a 2342 particular NSF. 2344 3. Default Action is added to specify a predefined action when no 2345 other alternative action was matched by the currently executed 2346 I2NSF policy rule. 2348 4. This YANG data model is modified for vendors to extend the YANG 2349 data model if they need specific features for their NSFs. 2351 5. An example is added to extend the YANG data model about a 2352 specific NSF. 2354 6. Examples are added for XML configuration files of a generic NSF 2355 and an extended VoIP/VoLTE security function. 2357 Authors' Addresses 2359 Jinyong Tim Kim 2360 Department of Computer Engineering 2361 Sungkyunkwan University 2362 2066 Seobu-Ro, Jangan-Gu 2363 Suwon, Gyeonggi-Do 16419 2364 Republic of Korea 2366 Phone: +82 10 8273 0930 2367 EMail: timkim@skku.edu 2369 Jaehoon Paul Jeong 2370 Department of Software 2371 Sungkyunkwan University 2372 2066 Seobu-Ro, Jangan-Gu 2373 Suwon, Gyeonggi-Do 16419 2374 Republic of Korea 2376 Phone: +82 31 299 4957 2377 Fax: +82 31 290 7996 2378 EMail: pauljeong@skku.edu 2379 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2380 Jung-Soo Park 2381 Electronics and Telecommunications Research Institute 2382 218 Gajeong-Ro, Yuseong-Gu 2383 Daejeon 34129 2384 Republic of Korea 2386 Phone: +82 42 860 6514 2387 EMail: pjs@etri.re.kr 2389 Susan Hares 2390 Huawei 2391 7453 Hickory Hill 2392 Saline, MI 48176 2393 USA 2395 Phone: +1-734-604-0332 2396 EMail: shares@ndzh.com 2398 Liang Xia (Frank) 2399 Huawei 2400 101 Software Avenue, Yuhuatai District 2401 Nanjing, Jiangsu 2402 China 2404 Phone: 2405 EMail: Frank.xialiang@huawei.com