idnits 2.17.1 draft-ietf-i2nsf-nsf-facing-interface-dm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 308 has weird spacing: '...content str...' == Line 408 has weird spacing: '... tenant uin...' == Line 414 has weird spacing: '... tenant uin...' -- The document date (March 5, 2018) is 2242 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 8329 Summary: 2 errors (**), 0 flaws (~~), 4 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: September 6, 2018 J. Park 6 ETRI 7 S. Hares 8 Q. Lin 9 Huawei 10 March 5, 2018 12 I2NSF Network Security Function-Facing Interface YANG Data Model 13 draft-ietf-i2nsf-nsf-facing-interface-dm-00 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 Interface to Network Security Functions (I2NSF). It 20 describes a data model for the features provided by generic security 21 functions. This data model provides generic components whose vendors 22 is well understood, so that the generic component can be used even if 23 it has some vendor specific functions. These generic functions 24 represent a point of interoperability, and can be provided by any 25 product that offers the required Capabilities. Also, if vendors need 26 additional features for its network security function, they can add 27 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 September 6, 2018. 52 Copyright Notice 54 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 73 4. The Structure and Objective of I2NSF Security Policy . . . . . 4 74 4.1. I2NSF Security Policy Rule . . . . . . . . . . . . . . . . 4 75 4.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . . 4 76 4.3. Condition Clause . . . . . . . . . . . . . . . . . . . . . 5 77 4.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 5 78 5. Data Model Structure . . . . . . . . . . . . . . . . . . . . . 5 79 5.1. I2NSF Security Policy Rule . . . . . . . . . . . . . . . . 5 80 5.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . . 7 81 5.3. Condition Clause . . . . . . . . . . . . . . . . . . . . . 7 82 5.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 10 83 6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 6.1. IETF NSF-Facing Interface YANG Data Module . . . . . . . . 11 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 87 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 43 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 44 91 Appendix A. Changes from 92 draft-kim-i2nsf-nsf-facing-interface-data-model-04 . 44 94 1. Introduction 96 This document defines a YANG [RFC6020] data model for the 97 configuration of security services with the information model for 98 Network Security Functions (NSF) facing interface in Interface to 99 Network Security Functions (I2NSF). It provides a specific 100 information model and the corresponding data models for generic 101 network security functions (i.e., network security functions), as 102 defined in [i2nsf-nsf-cap-im]. With these data model, I2NSF 103 controller can control the capabilities of NSFs. 105 The "Event-Condition-Action" (ECA) policy model is used as the basis 106 for the design of I2NSF Policy Rules. 108 The "ietf-i2nsf-nsf-facing-interface" YANG module defined in this 109 document provides the following features: 111 o configuration of I2NSF security policy rule for generic network 112 security function policy 114 o configuration of event clause for generic network security 115 function policy 117 o configuration of condition clause for generic network security 118 function policy 120 o configuration of action clause for generic network security 121 function policy 123 2. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 3. Terminology 131 This document uses the terminology described in 132 [i2nsf-nsf-cap-im][i2rs-rib-data-model][supa-policy-info-model]. 133 Especially, the following terms are from [supa-policy-info-model]: 135 o Data Model: A data model is a representation of concepts of 136 interest to an environment in a form that is dependent on data 137 repository, data definition language, query language, 138 implementation language, and protocol. 140 o Information Model: An information model is a representation of 141 concepts of interest to an environment in a form that is 142 independent of data repository, data definition language, query 143 language, implementation language, and protocol. 145 3.1. Tree Diagrams 147 A simplified graphical representation of the data model is used in 148 this document. The meaning of the symbols in these diagrams 149 [i2rs-rib-data-model] is as follows: 151 o Brackets "[" and "]" enclose list keys. 153 o Abbreviations before data node names: "rw" means configuration 154 (read-write) and "ro" state data (read-only). 156 o Symbols after data node names: "?" means an optional node and "*" 157 denotes a "list" and "leaf-list". 159 o Parentheses enclose choice and case nodes, and case nodes are also 160 marked with a colon (":"). 162 o Ellipsis ("...") stands for contents of subtrees that are not 163 shown. 165 4. The Structure and Objective of I2NSF Security Policy 167 4.1. I2NSF Security Policy Rule 169 This shows a policy rule for generic network security functions. The 170 object of a policy rule is defined as policy information and rule 171 information. This includes ECA Policy Rule such as Event Clause 172 Objects, Condition Clause Objects, Action Clause Objects, Resolution 173 Strategy, and Default Action. 175 4.2. Event Clause 177 This shows an event clause for generic network security functions. 178 An Event is any important occurrence in time of a change in the 179 system being managed, and/or in the environment of the system being 180 managed. When used in the context of I2NSF Policy Rules, it is used 181 to determine whether the Condition clause of the I2NSF Policy Rule 182 can be evaluated or not. The object of an event clauses is defined 183 as user security event, device security event, system security event, 184 and time security event. The objects of event clauses can be 185 extended according to specific vendor event features. 187 4.3. Condition Clause 189 This shows a condition clause for generic network security functions. 190 A condition is defined as a set of attributes, features, and/or 191 values that are to be compared with a set of known attributes, 192 features, and/or values in order to determine whether or not the set 193 of Actions in that (imperative) I2NSF Policy Rule can be executed or 194 not. These objects are defined as packet security condition, packet 195 payload security condition, target security condition, user security 196 condition, context condition, and generic context condition. The 197 objects of action clauses can be extended according to specific 198 vendor condition features. 200 4.4. Action Clause 202 This shows an action clause for generic network security functions. 203 An action is used to control and monitor aspects of flow-based NSFs 204 when the event and condition clauses are satisfied. NSFs provide 205 security functions by executing various Actions. The object of an 206 action clause is defined as ingress action, egress action, and apply 207 profile action. The objects of action clauses can be extended 208 according to specific vendor action features. 210 5. Data Model Structure 212 This section shows a data model structure tree of generic network 213 security functions that are defined in the [i2nsf-nsf-cap-im]. 215 o Consideration of ECA Policy Model by Aggregating the Event, 216 Condition, and Action Clauses Objects. 218 o Consideration of Capability Algebra. 220 o Consideration of NSFs Capability Categories (i.e., Network 221 Security, Content Security, and Attack Mitigation Capabilities). 223 o Definitions for Network Security Event Class, Network Security 224 Condition Class, and Network Security Action Class. 226 5.1. I2NSF Security Policy Rule 228 The data model for the identification of network security policy has 229 the following structure: 231 module: ietf-i2nsf-policy-rule-for-nsf 232 +--rw i2nsf-security-policy* [policy-name] 233 | +--rw policy-name string 234 | +--rw eca-policy-rules* [rule-id] 235 | | +--rw rule-id uint8 236 | | +--rw rule-description? string 237 | | +--rw rule-rev? uint8 238 | | +--rw rule-priority? uint8 239 | | +--rw policy-event-clause-agg-ptr* instance-identifier 240 | | +--rw policy-condition-clause-agg-ptr* instance-identifier 241 | | +--rw policy-action-clause-agg-ptr* instance-identifier 242 | | +--rw time-zone 243 | | +--rw absolute-time-zone 244 | | | +--rw time 245 | | | | +--rw start-time? yang:date-and-time 246 | | | | +--rw end-time? yang:date-and-time 247 | | | +--rw date 248 | | | | +--rw absolute-date* yang:date-and-time 249 | | +--rw periodic-time-zone 250 | | +--rw day 251 | | | +--rw sunday? boolean 252 | | | +--rw monday? boolean 253 | | | +--rw tuesday? boolean 254 | | | +--rw wednesday? boolean 255 | | | +--rw thursday? boolean 256 | | | +--rw friday? boolean 257 | | | +--rw saturday? boolean 258 | | +--rw month 259 | | +--rw january? boolean 260 | | +--rw february? boolean 261 | | +--rw march? boolean 262 | | +--rw april? boolean 263 | | +--rw may? boolean 264 | | +--rw june? boolean 265 | | +--rw july? boolean 266 | | +--rw august? boolean 267 | | +--rw september? boolean 268 | | +--rw october? boolean 269 | | +--rw november? boolean 270 | | +--rw december? boolean 271 | +--rw resolution-strategy 272 | | +--rw (resolution-strategy-type)? 273 | | +--:(fmr) 274 | | | +--rw first-matching-rule? boolean 275 | | +--:(lmr) 276 | | +--rw last-matching-rule? boolean 277 | +--rw default-action 278 | +--rw default-action-type? ingress-action 279 +--rw event-clause-container 280 | ... 281 +--rw condition-clause-container 282 | ... 284 +--rw action-clause-container 285 ... 287 Figure 1: Data Model Structure for Network Security Policy 288 Identification 290 5.2. Event Clause 292 The data model for event rule has the following structure: 294 module: ietf-i2nsf-policy-rule-for-nsf 295 +--rw i2nsf-security-policy* [policy-name] 296 | ... 297 | +--rw eca-policy-rules* [rule-id] 298 | ... 299 | +--rw resolution-strategy 300 | ... 301 | +--rw default-action 302 | ... 303 +--rw event-clause-container 304 | +--rw event-clause-list* [eca-object-id] 305 | +--rw entity-class? identityref 306 | +--rw eca-object-id string 307 | +--rw manual? string 308 | +--rw sec-event-content string 309 | +--rw sec-event-format sec-event-format 310 | +--rw sec-event-type string 311 +--rw condition-clause-container 312 | ... 313 +--rw action-clause-container 314 ... 316 Figure 2: Data Model Structure for Event Rule 318 These objects are defined as user security event, device security 319 event, system security event, and time security event. These objects 320 can be extended according to specific vendor event features. We will 321 add additional event objects for more generic network security 322 functions. 324 5.3. Condition Clause 326 The data model for condition rule has the following structure: 328 module: ietf-i2nsf-policy-rule-for-nsf 329 +--rw i2nsf-security-policy* [policy-name] 330 | ... 332 | +--rw eca-policy-rules* [rule-id] 333 | ... 334 | +--rw resolution-strategy 335 | ... 336 | +--rw default-action 337 | ... 338 +--rw event-clause-container 339 | ... 340 +--rw condition-clause-container 341 | +--rw condition-clause-list* [eca-object-id] 342 | +--rw entity-class? identityref 343 | +--rw eca-object-id string 344 | +--rw packet-security-condition 345 | | +--rw packet-manual? string 346 | | +--rw packet-security-mac-condition 347 | | | +--rw pkt-sec-cond-mac-dest* yang:phys-address 348 | | | +--rw pkt-sec-cond-mac-src* yang:phys-address 349 | | | +--rw pkt-sec-cond-mac-8021q* string 350 | | | +--rw pkt-sec-cond-mac-ether-type* string 351 | | | +--rw pkt-sec-cond-mac-tci* string 352 | | +--rw packet-security-ipv4-condition 353 | | | +--rw pkt-sec-cond-ipv4-header-length* uint8 354 | | | +--rw pkt-sec-cond-ipv4-tos* uint8 355 | | | +--rw pkt-sec-cond-ipv4-total-length* uint16 356 | | | +--rw pkt-sec-cond-ipv4-id* uint8 357 | | | +--rw pkt-sec-cond-ipv4-fragment* uint8 358 | | | +--rw pkt-sec-cond-ipv4-fragment-offset* uint16 359 | | | +--rw pkt-sec-cond-ipv4-ttl* uint8 360 | | | +--rw pkt-sec-cond-ipv4-protocol* uint8 361 | | | +--rw pkt-sec-cond-ipv4-src* inet:ipv4-address 362 | | | +--rw pkt-sec-cond-ipv4-dest* inet:ipv4-address 363 | | | +--rw pkt-sec-cond-ipv4-ipopts? string 364 | | | +--rw pkt-sec-cond-ipv4-sameip? boolean 365 | | | +--rw pkt-sec-cond-ipv4-geoip* string 366 | | +--rw packet-security-ipv6-condition 367 | | | +--rw pkt-sec-cond-ipv6-dscp* string 368 | | | +--rw pkt-sec-cond-ipv6-ecn* string 369 | | | +--rw pkt-sec-cond-ipv6-traffic-class* uint8 370 | | | +--rw pkt-sec-cond-ipv6-flow-label* uint32 371 | | | +--rw pkt-sec-cond-ipv6-payload-length* uint16 372 | | | +--rw pkt-sec-cond-ipv6-next-header* uint8 373 | | | +--rw pkt-sec-cond-ipv6-hop-limit* uint8 374 | | | +--rw pkt-sec-cond-ipv6-src* inet:ipv6-address 375 | | | +--rw pkt-sec-cond-ipv6-dest* inet:ipv6-address 376 | | +--rw packet-security-tcp-condition 377 | | | +--rw pkt-sec-cond-tcp-src-port* inet:port-number 378 | | | +--rw pkt-sec-cond-tcp-dest-port* inet:port-number 379 | | | +--rw pkt-sec-cond-tcp-seq-num* uint32 380 | | | +--rw pkt-sec-cond-tcp-ack-num* uint32 381 | | | +--rw pkt-sec-cond-tcp-window-size* uint16 382 | | | +--rw pkt-sec-cond-tcp-flags* uint8 383 | | +--rw packet-security-udp-condition 384 | | | +--rw pkt-sec-cond-udp-src-port* inet:port-number 385 | | | +--rw pkt-sec-cond-udp-dest-port* inet:port-number 386 | | | +--rw pkt-sec-cond-udp-length* string 387 | | +--rw packet-security-icmp-condition 388 | | +--rw pkt-sec-cond-icmp-type* uint8 389 | | +--rw pkt-sec-cond-icmp-code* uint8 390 | | +--rw pkt-sec-cond-icmp-seg-num* uint32 391 | +--rw packet-payload-condition 392 | | +--rw packet-payload-manual? string 393 | | +--rw pkt-payload-content* string 394 | +--rw target-condition 395 | | +--rw target-manual? string 396 | | +--rw device-sec-context-cond 397 | | +--rw pc? boolean 398 | | +--rw mobile-phone? boolean 399 | | +--rw voip-volte-phone? boolean 400 | | +--rw tablet? boolean 401 | | +--rw iot? boolean 402 | | +--rw vehicle? boolean 403 | +--rw users-condition 404 | | +--rw users-manual? string 405 | | +--rw user 406 | | | +--rw (user-name)? 407 | | | +--:(tenant) 408 | | | | +--rw tenant uint8 409 | | | +--:(vn-id) 410 | | | +--rw vn-id uint8 411 | | +--rw group 412 | | +--rw (group-name)? 413 | | +--:(tenant) 414 | | | +--rw tenant uint8 415 | | +--:(vn-id) 416 | | +--rw vn-id uint8 417 | +--rw context-condition 418 | | +--rw context-manual? string 419 | +--rw gen-context-condition 420 | +--rw gen-context-manual? string 421 | +--rw geographic-location 422 | +--rw src-geographic-location* uint32 423 | +--rw dest-geographic-location* uint32 424 +--rw action-clause-container 425 ... 427 Figure 3: Data Model Structure for Condition Rule 429 These objects are defined as packet security condition, packet 430 payload security condition, target security condition, user security 431 condition, context condition, and generic context condition. These 432 objects can be extended according to specific vendor condition 433 features. We will add additional condition objects for more generic 434 network security functions. 436 5.4. Action Clause 438 The data model for action rule has the following structure: 440 module: ietf-i2nsf-policy-rule-for-nsf 441 +--rw i2nsf-security-policy* [policy-name] 442 | ... 443 | +--rw eca-policy-rules* [rule-id] 444 | ... 445 | +--rw resolution-strategy 446 | ... 447 | +--rw default-action 448 | ... 449 +--rw event-clause-container 450 | ... 451 +--rw condition-clause-container 452 | ... 453 +--rw action-clause-container 454 +--rw action-clause-list* [eca-object-id] 455 +--rw entity-class? identityref 456 +--rw eca-object-id string 457 +--rw ingress-action 458 | +--rw ingress-manual? string 459 | +--rw ingress-action-type? ingress-action 460 +--rw egress-action 461 | +--rw egress-manual? string 462 | +--rw egress-action-type? egress-action 463 +--rw apply-profile 464 +--rw profile-manual? string 465 +--rw content-security-control 466 | +--rw content-security-control-types 467 | +--rw antivirus? boolean 468 | +--rw ips? boolean 469 | +--rw ids? boolean 470 | +--rw url-filtering? boolean 471 | +--rw data-filtering? boolean 472 | +--rw mail-filtering? boolean 473 | +--rw file-blocking? boolean 474 | +--rw file-isolate? boolean 475 | +--rw pkt-capture? boolean 476 | +--rw application-control? boolean 477 | +--rw voip-volte? boolean 478 +--rw attack-mitigation-control 479 +--rw ddos-attack 480 | +--rw ddos-attack-type 481 | +--rw network-layer-ddos-attack 482 | | +--rw network-layer-ddos-attack-type 483 | | +--rw syn-flood? boolean 484 | | +--rw udp-flood? boolean 485 | | +--rw icmp-flood? boolean 486 | | +--rw ip-frag-flood? boolean 487 | | +--rw ipv6-related? boolean 488 | +--rw app-layer-ddos-attack 489 | +--rw app-ddos-attack-types 490 | +--rw http-flood? boolean 491 | +--rw https-flood? boolean 492 | +--rw dns-flood? boolean 493 | +--rw dns-amp-flood? boolean 494 | +--rw ssl-ddos? boolean 495 +--rw single-packet-attack 496 +--rw single-packet-attack-type 497 +--rw scan-and-sniff-attack 498 | +--rw scan-and-sniff-attack-types 499 | +--rw ip-sweep? boolean 500 | +--rw port-scanning? boolean 501 +--rw malformed-packet-attack 502 | +--rw malformed-packet-attack-types 503 | +--rw ping-of-death? boolean 504 | +--rw teardrop? boolean 505 +--rw special-packet-attack 506 +--rw special-packet-attack-types 507 +--rw oversized-icmp? boolean 508 +--rw tracert? boolean 510 Figure 4: Data Model Structure for Action Rule 512 These objects are defined as ingress action, egress action, and apply 513 profile action. These objects can be extended according to specific 514 vendor action feature. We will add additional action objects for 515 more generic network security functions. 517 6. YANG Module 519 6.1. IETF NSF-Facing Interface YANG Data Module 521 This section introduces a YANG module for the information model of 522 network security functions, as defined in the [i2nsf-nsf-cap-im]. 524 file "ietf-i2nsf-policy-rule-for-nsf@2018-03-05.yang" 525 module ietf-i2nsf-policy-rule-for-nsf { 526 yang-version 1.1; 527 namespace 528 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"; 529 prefix 530 policy-rule-for-nsf; 532 import ietf-inet-types{ 533 prefix inet; 534 } 535 import ietf-yang-types{ 536 prefix yang; 537 } 539 organization 540 "IETF I2NSF (Interface to Network Security Functions) 541 Working Group"; 543 contact 544 "WG Web: 545 WG List: 547 WG Chair: Adrian Farrel 548 550 WG Chair: Linda Dunbar 551 553 Editor: Jingyong Tim Kim 554 556 Editor: Jaehoon Paul Jeong 557 559 Editor: Susan Hares 560 "; 562 description 563 "This module defines a YANG data module for network security 564 functions."; 565 revision "2018-03-05"{ 566 description "The fourth revision"; 567 reference 568 "draft-ietf-i2nsf-capability-00"; 569 } 571 typedef sec-event-format { 572 type enumeration { 573 enum unknown { 574 description 575 "If SecEventFormat is unknown"; 576 } 577 enum guid { 578 description 579 "If SecEventFormat is GUID 580 (Generic Unique IDentifier)"; 581 } 582 enum uuid { 583 description 584 "If SecEventFormat is UUID 585 (Universal Unique IDentifier)"; 586 } 587 enum uri { 588 description 589 "If SecEventFormat is URI 590 (Uniform Resource Identifier)"; 591 } 592 enum fqdn { 593 description 594 "If SecEventFormat is FQDN 595 (Fully Qualified Domain Name)"; 596 } 597 enum fqpn { 598 description 599 "If SecEventFormat is FQPN 600 (Fully Qualified Path Name)"; 601 } 602 } 603 description 604 "This is used for SecEventFormat."; 605 } 607 typedef ingress-action { 608 type enumeration { 609 enum pass { 610 description 611 "If ingress action is pass"; 612 } 613 enum drop { 614 description 615 "If ingress action is drop"; 616 } 617 enum reject { 618 description 619 "If ingress action is reject"; 620 } 621 enum alert { 622 description 623 "If ingress action is alert"; 624 } 625 enum mirror { 626 description 627 "If ingress action is mirror"; 628 } 629 } 630 description 631 "This is used for ingress action."; 632 } 634 typedef egress-action { 635 type enumeration { 636 enum invoke-signaling { 637 description 638 "If egress action is invoke signaling"; 639 } 640 enum tunnel-encapsulation { 641 description 642 "If egress action is tunnel encapsulation"; 643 } 644 enum forwarding { 645 description 646 "If egress action is forwarding"; 647 } 648 enum redirection { 649 description 650 "If egress action is redirection"; 651 } 652 } 653 description 654 "This is used for egress action."; 655 } 657 identity ECA-OBJECT-TYPE { 658 description "TBD"; 659 } 661 identity ECA-EVENT-TYPE { 662 base ECA-OBJECT-TYPE; 663 description "TBD"; 664 } 666 identity ECA-CONDITION-TYPE { 667 base ECA-OBJECT-TYPE; 668 description "TBD"; 670 } 672 identity ECA-ACTION-TYPE { 673 base ECA-OBJECT-TYPE; 674 description "TBD"; 675 } 677 identity EVENT-USER-TYPE { 678 base ECA-EVENT-TYPE; 679 description "TBD"; 680 } 682 identity EVENT-DEV-TYPE { 683 base ECA-EVENT-TYPE; 684 description "TBD"; 685 } 687 identity EVENT-SYS-TYPE { 688 base ECA-EVENT-TYPE; 689 description "TBD"; 690 } 692 identity EVENT-TIME-TYPE { 693 base ECA-EVENT-TYPE; 694 description "TBD"; 695 } 697 grouping i2nsf-eca-object-type { 698 leaf entity-class { 699 type identityref { 700 base ECA-OBJECT-TYPE; 701 } 702 description "TBD"; 703 } 704 leaf eca-object-id { 705 type string; 706 description "TBD"; 707 } 708 description "TBD"; 709 } 711 grouping i2nsf-event-type { 712 description "TBD"; 713 leaf manual { 714 type string; 715 description 716 "This is manual for event. 718 Vendors can write instructions for event 719 that vendor made"; 720 } 722 leaf sec-event-content { 723 type string; 724 mandatory true; 725 description 726 "This is a mandatory string that contains the content 727 of the SecurityEvent. The format of the content 728 is specified in the SecEventFormat class 729 attribute, and the type of event is defined in the 730 SecEventType class attribute. An example of the 731 SecEventContent attribute is a string hrAdmin, 732 with the SecEventFormat set to 1 (GUID) and the 733 SecEventType attribute set to 5 (new logon)."; 734 } 736 leaf sec-event-format { 737 type sec-event-format; 738 mandatory true; 739 description 740 "This is a mandatory uint 8 enumerated integer, which 741 is used to specify the data type of the 742 SecEventContent attribute. The content is 743 specified in the SecEventContent class attribute, 744 and the type of event is defined in the 745 SecEventType class attribute. An example of the 746 SecEventContent attribute is string hrAdmin, 747 with the SecEventFormat attribute set to 1 (GUID) 748 and the SecEventType attribute set to 5 749 (new logon)."; 750 } 752 leaf sec-event-type { 753 type string; 754 mandatory true; 755 description 756 "This is a mandatory uint 8 enumerated integer, which 757 is used to specify the type of event that involves 758 this user. The content and format are specified in 759 the SecEventContent and SecEventFormat class 760 attributes, respectively. An example of the 761 SecEventContent attribute is string hrAdmin, 762 with the SecEventFormat attribute set to 1 (GUID) 763 and the SecEventType attribute set to 5 764 (new logon)."; 765 } 767 } 769 list i2nsf-security-policy { 770 key "policy-name"; 771 description 772 "policy is a list 773 including a set of security rules according to certain logic, 774 i.e., their similarity or mutual relations, etc. The network 775 security policy is able to apply over both the unidirectional 776 and bidirectional traffic across the NSF."; 778 leaf policy-name { 779 type string; 780 mandatory true; 781 description 782 "The name of the policy. 783 This must be unique."; 784 } 786 list eca-policy-rules { 787 key "rule-id"; 788 description 789 "This is a rule for network security functions."; 791 leaf rule-id { 792 type uint8; 793 mandatory true; 794 description 795 "The id of the rule. 796 This must be unique."; 797 } 799 leaf rule-description { 800 type string; 801 description 802 "This description gives more information about 803 rules."; 804 } 806 leaf rule-rev { 807 type uint8; 808 description 809 "This shows rule version."; 810 } 812 leaf rule-priority { 813 type uint8; 814 description 815 "The priority keyword comes with a mandatory 816 numeric value which can range from 1 till 255."; 817 } 818 leaf-list policy-event-clause-agg-ptr { 819 type instance-identifier; 820 must 'derived-from-or-self (/event-clause-container/ 821 event-clause-list/entity-class, "ECA-EVENT-TYPE")'; 822 description 823 "TBD"; 824 } 825 leaf-list policy-condition-clause-agg-ptr { 826 type instance-identifier; 827 must 'derived-from-or-self (/condition-clause-container/ 828 condition-clause-list/entity-class, "ECA-CONDITION-TYPE")'; 829 description 830 "TBD"; 831 } 832 leaf-list policy-action-clause-agg-ptr { 833 type instance-identifier; 834 must 'derived-from-or-self (/action-clause-container/ 835 action-clause-list/entity-class, "ECA-ACTION-TYPE")'; 836 description 837 "TBD"; 838 } 840 container time-zone { 841 description 842 "This can be used to apply rules according to time-zone"; 843 container absolute-time-zone { 844 description 845 "This can be used to apply rules according to 846 absolute-time"; 847 container time { 848 description 849 "This can be used to apply rules according to time"; 850 leaf start-time { 851 type yang:date-and-time; 852 description 853 "This is start time for time zone"; 854 } 855 leaf end-time { 856 type yang:date-and-time; 857 description 858 "This is end time for time zone"; 859 } 860 } 861 container date { 862 description 863 "This can be used to apply rules according to date"; 864 leaf absolute-date { 865 type yang:date-and-time; 866 description 867 "This is absolute date for time zone"; 868 } 869 } 870 } 871 container periodic-time-zone { 872 description 873 "This can be used to apply rules according to 874 periodic-time-zone"; 875 container day { 876 description 877 "This can be used to apply rules according 878 to periodic day"; 879 leaf sunday { 880 type boolean; 881 description 882 "This is sunday for periodic day"; 883 } 884 leaf monday { 885 type boolean; 886 description 887 "This is monday for periodic day"; 888 } 889 leaf tuesday { 890 type boolean; 891 description 892 "This is tuesday for periodic day"; 893 } 894 leaf wednesday { 895 type boolean; 896 description 897 "This is wednesday for periodic day"; 898 } 899 leaf thursday { 900 type boolean; 901 description 902 "This is thursday for periodic day"; 903 } 904 leaf friday { 905 type boolean; 906 description 907 "This is friday for periodic day"; 908 } 909 leaf saturday { 910 type boolean; 911 description 912 "This is saturday for periodic day"; 913 } 914 } 915 container month { 916 description 917 "This can be used to apply rules according 918 to periodic month"; 919 leaf january { 920 type boolean; 921 description 922 "This is january for periodic month"; 923 } 924 leaf february { 925 type boolean; 926 description 927 "This is february for periodic month"; 928 } 929 leaf march { 930 type boolean; 931 description 932 "This is march for periodic month"; 933 } 934 leaf april { 935 type boolean; 936 description 937 "This is april for periodic month"; 938 } 939 leaf may { 940 type boolean; 941 description 942 "This is may for periodic month"; 943 } 944 leaf june { 945 type boolean; 946 description 947 "This is june for periodic month"; 948 } 949 leaf july { 950 type boolean; 951 description 952 "This is july for periodic month"; 953 } 954 leaf august { 955 type boolean; 956 description 957 "This is august for periodic month"; 959 } 960 leaf september { 961 type boolean; 962 description 963 "This is september for periodic month"; 964 } 965 leaf october { 966 type boolean; 967 description 968 "This is october for periodic month"; 969 } 970 leaf november { 971 type boolean; 972 description 973 "This is november for periodic month"; 974 } 975 leaf december { 976 type boolean; 977 description 978 "This is december for periodic month"; 979 } 980 } 981 } 982 } 983 } 985 container resolution-strategy { 986 description 987 "The resolution strategies can be used to 988 specify how to resolve conflicts that occur between 989 the actions of the same or different policy rules that 990 are matched and contained in this particular NSF"; 992 choice resolution-strategy-type { 993 description 994 "Vendors can use YANG data model to configure rules"; 996 case fmr { 997 leaf first-matching-rule { 998 type boolean; 999 description 1000 "If the resolution strategy is first matching rule"; 1001 } 1002 } 1003 case lmr { 1004 leaf last-matching-rule { 1005 type boolean; 1006 description 1007 "If the resolution strategy is last matching rule"; 1008 } 1009 } 1011 } 1012 } 1014 container default-action { 1015 description 1016 "This default action can be used to specify a predefined 1017 action when no other alternative action was matched 1018 by the currently executing I2NSF Policy Rule. An analogy 1019 is the use of a default statement in a C switch statement."; 1021 leaf default-action-type { 1022 type ingress-action; 1023 description 1024 "Ingress action type: permit, deny, and mirror."; 1025 } 1026 } 1027 } 1029 container event-clause-container { 1030 description "TBD"; 1031 list event-clause-list { 1032 key eca-object-id; 1033 uses i2nsf-eca-object-type { 1034 refine entity-class { 1035 default ECA-EVENT-TYPE; 1036 } 1037 } 1039 description 1040 " This is abstract. An event is defined as any important 1041 occurrence in time of a change in the system being 1042 managed, and/or in the environment of the system being 1043 managed. When used in the context of policy rules for 1044 a flow-based NSF, it is used to determine whether the 1045 Condition clause of the Policy Rule can be evaluated 1046 or not. Examples of an I2NSF event include time and 1047 user actions (e.g., logon, logoff, and actions that 1048 violate any ACL.)."; 1050 uses i2nsf-event-type; 1051 } 1053 } 1054 container condition-clause-container { 1055 description "TBD"; 1056 list condition-clause-list { 1057 key eca-object-id; 1058 uses i2nsf-eca-object-type { 1059 refine entity-class { 1060 default ECA-CONDITION-TYPE; 1061 } 1062 } 1063 description 1064 " This is abstract. A condition is defined as a set 1065 of attributes, features, and/or values that are to be 1066 compared with a set of known attributes, features, 1067 and/or values in order to determine whether or not the 1068 set of Actions in that (imperative) I2NSF Policy Rule 1069 can be executed or not. Examples of I2NSF Conditions 1070 include matching attributes of a packet or flow, and 1071 comparing the internal state of an NSF to a desired 1072 state."; 1074 container packet-security-condition { 1075 description 1076 "TBD"; 1077 leaf packet-manual { 1078 type string; 1079 description 1080 "This is manual for packet condition. 1081 Vendors can write instructions for packet condition 1082 that vendor made"; 1083 } 1085 container packet-security-mac-condition { 1086 description 1087 "The purpose of this Class is to represent packet MAC 1088 packet header information that can be used as part of 1089 a test to determine if the set of Policy Actions in 1090 this ECA Policy Rule should be execute or not."; 1092 leaf-list pkt-sec-cond-mac-dest { 1093 type yang:phys-address; 1094 description 1095 "The MAC destination address (6 octets long)."; 1096 } 1098 leaf-list pkt-sec-cond-mac-src { 1099 type yang:phys-address; 1100 description 1101 "The MAC source address (6 octets long)."; 1102 } 1104 leaf-list pkt-sec-cond-mac-8021q { 1105 type string; 1106 description 1107 "This is an optional string attribute, and defines 1108 The 802.1Q tab value (2 octets long)."; 1109 } 1111 leaf-list pkt-sec-cond-mac-ether-type { 1112 type string; 1113 description 1114 "The EtherType field (2 octets long). Values up to 1115 and including 1500 indicate the size of the 1116 payload in octets; values of 1536 and above 1117 define which protocol is encapsulated in the 1118 payload of the frame."; 1119 } 1121 leaf-list pkt-sec-cond-mac-tci { 1122 type string; 1123 description 1124 "This is an optional string attribute, and defines 1125 the Tag Control Information. This consists of a 3 1126 bit user priority field, a drop eligible indicator 1127 (1 bit), and a VLAN identifier (12 bits)."; 1128 } 1129 } 1131 container packet-security-ipv4-condition { 1132 description 1133 "The purpose of this Class is to represent IPv4 1134 packet header information that can be used as 1135 part of a test to determine if the set of Policy 1136 Actions in this ECA Policy Rule should be executed 1137 or not."; 1139 leaf-list pkt-sec-cond-ipv4-header-length { 1140 type uint8; 1141 description 1142 "The IPv4 packet header consists of 14 fields, 1143 of which 13 are required."; 1144 } 1146 leaf-list pkt-sec-cond-ipv4-tos { 1147 type uint8; 1148 description 1149 "The ToS field could specify a datagram's priority 1150 and request a route for low-delay, 1151 high-throughput, or highly-reliable service.."; 1152 } 1154 leaf-list pkt-sec-cond-ipv4-total-length { 1155 type uint16; 1156 description 1157 "This 16-bit field defines the entire packet size, 1158 including header and data, in bytes."; 1159 } 1161 leaf-list pkt-sec-cond-ipv4-id { 1162 type uint8; 1163 description 1164 "This field is an identification field and is 1165 primarily used for uniquely identifying 1166 the group of fragments of a single IP datagram."; 1167 } 1169 leaf-list pkt-sec-cond-ipv4-fragment { 1170 type uint8; 1171 description 1172 "IP fragmentation is an Internet Protocol (IP) 1173 process that breaks datagrams into smaller pieces 1174 (fragments), so that packets may be formed that 1175 can pass through a link with a smaller maximum 1176 transmission unit (MTU) than the original 1177 datagram size."; 1178 } 1180 leaf-list pkt-sec-cond-ipv4-fragment-offset { 1181 type uint16; 1182 description 1183 "Fragment offset field along with Don't Fragment 1184 and More Fragment flags in the IP protocol 1185 header are used for fragmentation and reassembly 1186 of IP datagrams."; 1187 } 1189 leaf-list pkt-sec-cond-ipv4-ttl { 1190 type uint8; 1191 description 1192 "The ttl keyword is used to check for a specific 1193 IP time-to-live value in the header of 1194 a packet."; 1195 } 1196 leaf-list pkt-sec-cond-ipv4-protocol { 1197 type uint8; 1198 description 1199 "Internet Protocol version 4(IPv4) is the fourth 1200 version of the Internet Protocol (IP)."; 1201 } 1203 leaf-list pkt-sec-cond-ipv4-src { 1204 type inet:ipv4-address; 1205 description 1206 "Defines the IPv4 Source Address."; 1207 } 1209 leaf-list pkt-sec-cond-ipv4-dest { 1210 type inet:ipv4-address; 1211 description 1212 "Defines the IPv4 Destination Address."; 1213 } 1215 leaf pkt-sec-cond-ipv4-ipopts { 1216 type string; 1217 description 1218 "With the ipopts keyword you can check if 1219 a specific ip option is set. Ipopts has 1220 to be used at the beginning of a rule."; 1221 } 1223 leaf pkt-sec-cond-ipv4-sameip { 1224 type boolean; 1225 description 1226 "Every packet has a source IP-address and 1227 a destination IP-address. It can be that 1228 the source IP is the same as 1229 the destination IP."; 1230 } 1232 leaf-list pkt-sec-cond-ipv4-geoip { 1233 type string; 1234 description 1235 "The geoip keyword enables you to match on 1236 the source, destination or source and destination 1237 IP addresses of network traffic and to see to 1238 which country it belongs. To do this, Suricata 1239 uses GeoIP API with MaxMind database format."; 1240 } 1241 } 1243 container packet-security-ipv6-condition { 1244 description 1245 "The purpose of this Class is to represent packet 1246 IPv6 packet header information that can be used as 1247 part of a test to determine if the set of Policy 1248 Actions in this ECA Policy Rule should be executed 1249 or not."; 1251 leaf-list pkt-sec-cond-ipv6-dscp { 1252 type string; 1253 description 1254 "Differentiated Services Code Point (DSCP) 1255 of ipv6."; 1256 } 1258 leaf-list pkt-sec-cond-ipv6-ecn { 1259 type string; 1260 description 1261 "ECN allows end-to-end notification of network 1262 congestion without dropping packets."; 1263 } 1265 leaf-list pkt-sec-cond-ipv6-traffic-class { 1266 type uint8; 1267 description 1268 "The bits of this field hold two values. The 6 1269 most-significant bits are used for 1270 differentiated services, which is used to 1271 classify packets."; 1272 } 1274 leaf-list pkt-sec-cond-ipv6-flow-label { 1275 type uint32; 1276 description 1277 "The flow label when set to a non-zero value 1278 serves as a hint to routers and switches 1279 with multiple outbound paths that these 1280 packets should stay on the same path so that 1281 they will not be reordered."; 1282 } 1284 leaf-list pkt-sec-cond-ipv6-payload-length { 1285 type uint16; 1286 description 1287 "The size of the payload in octets, 1288 including any extension headers."; 1289 } 1291 leaf-list pkt-sec-cond-ipv6-next-header { 1292 type uint8; 1293 description 1294 "Specifies the type of the next header. 1295 This field usually specifies the transport 1296 layer protocol used by a packet's payload."; 1297 } 1299 leaf-list pkt-sec-cond-ipv6-hop-limit { 1300 type uint8; 1301 description 1302 "Replaces the time to live field of IPv4."; 1303 } 1305 leaf-list pkt-sec-cond-ipv6-src { 1306 type inet:ipv6-address; 1307 description 1308 "The IPv6 address of the sending node."; 1309 } 1311 leaf-list pkt-sec-cond-ipv6-dest { 1312 type inet:ipv6-address; 1313 description 1314 "The IPv6 address of the destination node(s)."; 1315 } 1316 } 1318 container packet-security-tcp-condition { 1319 description 1320 "The purpose of this Class is to represent packet 1321 TCP packet header information that can be used as 1322 part of a test to determine if the set of Policy 1323 Actions in this ECA Policy Rule should be executed 1324 or not."; 1326 leaf-list pkt-sec-cond-tcp-src-port { 1327 type inet:port-number; 1328 description 1329 "This is a mandatory string attribute, and 1330 defines the Source Port number (16 bits)."; 1331 } 1333 leaf-list pkt-sec-cond-tcp-dest-port { 1334 type inet:port-number; 1335 description 1336 "This is a mandatory string attribute, and 1337 defines the Destination Port number (16 bits)."; 1338 } 1339 leaf-list pkt-sec-cond-tcp-seq-num { 1340 type uint32; 1341 description 1342 "If the SYN flag is set (1), then this is the 1343 initial sequence number."; 1344 } 1346 leaf-list pkt-sec-cond-tcp-ack-num { 1347 type uint32; 1348 description 1349 "If the ACK flag is set then the value of this 1350 field is the next sequence number that the sender 1351 is expecting."; 1352 } 1354 leaf-list pkt-sec-cond-tcp-window-size { 1355 type uint16; 1356 description 1357 "The size of the receive window, which specifies 1358 the number of windows size units 1359 (by default,bytes) (beyond the segment 1360 identified by the sequence number in the 1361 acknowledgment field) that the sender of this 1362 segment is currently willing to recive."; 1363 } 1365 leaf-list pkt-sec-cond-tcp-flags { 1366 type uint8; 1367 description 1368 "This is a mandatory string attribute, and defines 1369 the nine Control bit flags (9 bits)."; 1370 } 1371 } 1373 container packet-security-udp-condition { 1374 description 1375 "The purpose of this Class is to represent packet UDP 1376 packet header information that can be used as part 1377 of a test to determine if the set of Policy Actions 1378 in this ECA Policy Rule should be executed or not."; 1380 leaf-list pkt-sec-cond-udp-src-port { 1381 type inet:port-number; 1382 description 1383 "This is a mandatory string attribute, and 1384 defines the UDP Source Port number (16 bits)."; 1385 } 1386 leaf-list pkt-sec-cond-udp-dest-port { 1387 type inet:port-number; 1388 description 1389 "This is a mandatory string attribute, and 1390 defines the UDP Destination Port number (16 bits)."; 1391 } 1393 leaf-list pkt-sec-cond-udp-length { 1394 type string; 1395 description 1396 "This is a mandatory string attribute, and defines 1397 the length in bytes of the UDP header and data 1398 (16 bits)."; 1399 } 1400 } 1402 container packet-security-icmp-condition { 1403 description 1404 "The internet control message protocol condition."; 1406 leaf-list pkt-sec-cond-icmp-type { 1407 type uint8; 1408 description 1409 "ICMP type, see Control messages."; 1410 } 1412 leaf-list pkt-sec-cond-icmp-code { 1413 type uint8; 1414 description 1415 "ICMP subtype, see Control messages."; 1416 } 1418 leaf-list pkt-sec-cond-icmp-seg-num { 1419 type uint32; 1420 description 1421 "The icmp Sequence Number."; 1422 } 1423 } 1424 } 1426 container packet-payload-condition { 1427 description 1428 "TBD"; 1429 leaf packet-payload-manual { 1430 type string; 1431 description 1432 "This is manual for payload condition. 1433 Vendors can write instructions for payload condition 1434 that vendor made"; 1435 } 1436 leaf-list pkt-payload-content { 1437 type string; 1438 description 1439 "The content keyword is very important in 1440 signatures. Between the quotation marks you 1441 can write on what you would like the 1442 signature to match."; 1443 } 1444 } 1445 container target-condition { 1446 description 1447 "TBD"; 1448 leaf target-manual { 1449 type string; 1450 description 1451 "This is manual for target condition. 1452 Vendors can write instructions for target condition 1453 that vendor made"; 1454 } 1456 container device-sec-context-cond { 1457 description 1458 "The device attribute that can identify a device, 1459 including the device type (i.e., router, switch, 1460 pc, ios, or android) and the device's owner as 1461 well."; 1463 leaf pc { 1464 type boolean; 1465 description 1466 "If type of a device is PC."; 1467 } 1469 leaf mobile-phone { 1470 type boolean; 1471 description 1472 "If type of a device is mobile-phone."; 1473 } 1475 leaf voip-volte-phone { 1476 type boolean; 1477 description 1478 "If type of a device is voip-volte-phone."; 1479 } 1481 leaf tablet { 1482 type boolean; 1483 description 1484 "If type of a device is tablet."; 1485 } 1487 leaf iot { 1488 type boolean; 1489 description 1490 "If type of a device is Internet of Things."; 1491 } 1493 leaf vehicle { 1494 type boolean; 1495 description 1496 "If type of a device is vehicle."; 1497 } 1498 } 1499 } 1500 container users-condition { 1501 description 1502 "TBD"; 1503 leaf users-manual { 1504 type string; 1505 description 1506 "This is manual for user condition. 1507 Vendors can write instructions for user condition 1508 that vendor made"; 1509 } 1511 container user{ 1512 description 1513 "The user (or user group) information with which 1514 network flow is associated: The user has many 1515 attributes such as name, id, password, type, 1516 authentication mode and so on. Name/id is often 1517 used in the security policy to identify the user. 1518 Besides, NSF is aware of the IP address of the 1519 user provided by a unified user management system 1520 via network. Based on name-address association, 1521 NSF is able to enforce the security functions 1522 over the given user (or user group)"; 1524 choice user-name { 1525 description 1526 "The name of the user. 1527 This must be unique."; 1529 case tenant { 1530 description 1531 "Tenant information."; 1533 leaf tenant { 1534 type uint8; 1535 mandatory true; 1536 description 1537 "User's tenant information."; 1538 } 1539 } 1541 case vn-id { 1542 description 1543 "VN-ID information."; 1545 leaf vn-id { 1546 type uint8; 1547 mandatory true; 1548 description 1549 "User's VN-ID information."; 1550 } 1551 } 1552 } 1553 } 1554 container group { 1555 description 1556 "The user (or user group) information with which 1557 network flow is associated: The user has many 1558 attributes such as name, id, password, type, 1559 authentication mode and so on. Name/id is often 1560 used in the security policy to identify the user. 1561 Besides, NSF is aware of the IP address of the 1562 user provided by a unified user management system 1563 via network. Based on name-address association, 1564 NSF is able to enforce the security functions 1565 over the given user (or user group)"; 1567 choice group-name { 1568 description 1569 "The name of the user. 1570 This must be unique."; 1572 case tenant { 1573 description 1574 "Tenant information."; 1576 leaf tenant { 1577 type uint8; 1578 mandatory true; 1579 description 1580 "User's tenant information."; 1581 } 1582 } 1584 case vn-id { 1585 description 1586 "VN-ID information."; 1588 leaf vn-id { 1589 type uint8; 1590 mandatory true; 1591 description 1592 "User's VN-ID information."; 1593 } 1594 } 1595 } 1596 } 1598 } 1599 container context-condition { 1600 description 1601 "TBD"; 1602 leaf context-manual { 1603 type string; 1604 description 1605 "This is manual for context condition. 1606 Vendors can write instructions for context condition 1607 that vendor made"; 1608 } 1609 } 1610 container gen-context-condition { 1611 description 1612 "TBD"; 1613 leaf gen-context-manual { 1614 type string; 1615 description 1616 "This is manual for generic context condition. 1617 Vendors can write instructions for generic context 1618 condition that vendor made"; 1619 } 1621 container geographic-location { 1622 description 1623 "The location where network traffic is associated 1624 with. The region can be the geographic location 1625 such as country, province, and city, 1626 as well as the logical network location such as 1627 IP address, network section, and network domain."; 1629 leaf-list src-geographic-location { 1630 type uint32; 1631 description 1632 "This is mapped to ip address. We can acquire 1633 source region through ip address stored the 1634 database."; 1635 } 1636 leaf-list dest-geographic-location { 1637 type uint32; 1638 description 1639 "This is mapped to ip address. We can acquire 1640 destination region through ip address stored 1641 the database."; 1642 } 1643 } 1644 } 1645 } 1646 } 1647 container action-clause-container { 1648 description "TBD"; 1649 list action-clause-list { 1650 key eca-object-id; 1651 uses i2nsf-eca-object-type { 1652 refine entity-class { 1653 default ECA-ACTION-TYPE; 1654 } 1655 } 1656 description 1657 "An action is used to control and monitor aspects of 1658 flow-based NSFs when the event and condition clauses 1659 are satisfied. NSFs provide security functions by 1660 executing various Actions. Examples of I2NSF Actions 1661 include providing intrusion detection and/or protection, 1662 web and flow filtering, and deep packet inspection 1663 for packets and flows."; 1665 container ingress-action { 1666 description 1667 "TBD"; 1668 leaf ingress-manual { 1669 type string; 1670 description 1671 "This is manual for ingress action. 1673 Vendors can write instructions for ingress action 1674 that vendor made"; 1675 } 1676 leaf ingress-action-type { 1677 type ingress-action; 1678 description 1679 "Ingress action type: permit, deny, and mirror."; 1680 } 1681 } 1682 container egress-action { 1683 description 1684 "TBD"; 1685 leaf egress-manual { 1686 type string; 1687 description 1688 "This is manual for egress action. 1689 Vendors can write instructions for egress action 1690 that vendor made"; 1691 } 1692 leaf egress-action-type { 1693 type egress-action; 1694 description 1695 "Egress-action-type: invoke-signaling, 1696 tunnel-encapsulation, and forwarding."; 1697 } 1698 } 1699 container apply-profile { 1700 description 1701 "TBD"; 1702 leaf profile-manual { 1703 type string; 1704 description 1705 "This is manual for apply profile action. 1706 Vendors can write instructions for apply 1707 profile action that vendor made"; 1708 } 1710 container content-security-control { 1711 description 1712 "Content security control is another category of 1713 security capabilities applied to application layer. 1714 Through detecting the contents carried over the 1715 traffic in application layer, these capabilities 1716 can realize various security purposes, such as 1717 defending against intrusion, inspecting virus, 1718 filtering malicious URL or junk email, and blocking 1719 illegal web access or data retrieval."; 1721 container content-security-control-types { 1722 description 1723 "Content Security types: Antivirus, IPS, IDS, 1724 url-filtering, data-filtering, mail-filtering, 1725 file-blocking, file-isolate, pkt-capture, 1726 application-control, and voip-volte."; 1728 leaf antivirus { 1729 type boolean; 1730 description 1731 "Additional inspection of antivirus."; 1732 } 1734 leaf ips { 1735 type boolean; 1736 description 1737 "Additional inspection of IPS."; 1738 } 1740 leaf ids { 1741 type boolean; 1742 description 1743 "Additional inspection of IDS."; 1744 } 1746 leaf url-filtering { 1747 type boolean; 1748 description 1749 "Additional inspection of URL filtering."; 1750 } 1752 leaf data-filtering { 1753 type boolean; 1754 description 1755 "Additional inspection of data filtering."; 1756 } 1758 leaf mail-filtering { 1759 type boolean; 1760 description 1761 "Additional inspection of mail filtering."; 1762 } 1764 leaf file-blocking { 1765 type boolean; 1766 description 1767 "Additional inspection of file blocking."; 1768 } 1769 leaf file-isolate { 1770 type boolean; 1771 description 1772 "Additional inspection of file isolate."; 1773 } 1775 leaf pkt-capture { 1776 type boolean; 1777 description 1778 "Additional inspection of packet capture."; 1779 } 1781 leaf application-control { 1782 type boolean; 1783 description 1784 "Additional inspection of app control."; 1785 } 1787 leaf voip-volte { 1788 type boolean; 1789 description 1790 "Additional inspection of VoIP/VoLTE."; 1791 } 1792 } 1793 } 1795 container attack-mitigation-control { 1796 description 1797 "This category of security capabilities is 1798 specially used to detect and mitigate various 1799 types of network attacks."; 1801 container ddos-attack { 1802 description 1803 "A distributed-denial-of-service (DDoS) is 1804 where the attack source is more than one, 1805 often thousands of unique IP addresses."; 1807 container ddos-attack-type { 1808 description 1809 "DDoS-attack types: Network Layer 1810 DDoS Attacks and Application Layer 1811 DDoS Attacks."; 1813 container network-layer-ddos-attack { 1814 description 1815 "Network layer DDoS-attack."; 1816 container network-layer-ddos-attack-type { 1817 description 1818 "Network layer DDoS attack types: 1819 Syn Flood Attack, UDP Flood Attack, 1820 ICMP Flood Attack, IP Fragment Flood, 1821 IPv6 Related Attacks, and etc"; 1823 leaf syn-flood { 1824 type boolean; 1825 description 1826 "Additional Inspection of 1827 Syn Flood Attack."; 1828 } 1830 leaf udp-flood { 1831 type boolean; 1832 description 1833 "Additional Inspection of 1834 UDP Flood Attack."; 1835 } 1837 leaf icmp-flood { 1838 type boolean; 1839 description 1840 "Additional Inspection of 1841 ICMP Flood Attack."; 1842 } 1844 leaf ip-frag-flood { 1845 type boolean; 1846 description 1847 "Additional Inspection of 1848 IP Fragment Flood."; 1849 } 1851 leaf ipv6-related { 1852 type boolean; 1853 description 1854 "Additional Inspection of 1855 IPv6 Related Attacks."; 1856 } 1857 } 1858 } 1860 container app-layer-ddos-attack { 1861 description 1862 "Application layer DDoS-attack."; 1864 container app-ddos-attack-types { 1865 description 1866 "Application layer DDoS-attack types: 1867 Http Flood Attack, Https Flood Attack, 1868 DNS Flood Attack, and 1869 DNS Amplification Flood Attack, 1870 SSL DDoS Attack, and etc."; 1872 leaf http-flood { 1873 type boolean; 1874 description 1875 "Additional Inspection of 1876 Http Flood Attack."; 1877 } 1879 leaf https-flood { 1880 type boolean; 1881 description 1882 "Additional Inspection of 1883 Https Flood Attack."; 1884 } 1886 leaf dns-flood { 1887 type boolean; 1888 description 1889 "Additional Inspection of 1890 DNS Flood Attack."; 1891 } 1893 leaf dns-amp-flood { 1894 type boolean; 1895 description 1896 "Additional Inspection of 1897 DNS Amplification Flood Attack."; 1898 } 1900 leaf ssl-ddos { 1901 type boolean; 1902 description 1903 "Additional Inspection of 1904 SSL Flood Attack."; 1905 } 1906 } 1907 } 1908 } 1909 } 1911 container single-packet-attack { 1912 description 1913 "Single Packet Attacks."; 1914 container single-packet-attack-type { 1915 description 1916 "DDoS-attack types: Scanning Attack, 1917 Sniffing Attack, Malformed Packet Attack, 1918 Special Packet Attack, and etc."; 1920 container scan-and-sniff-attack { 1921 description 1922 "Scanning and Sniffing Attack."; 1923 container scan-and-sniff-attack-types { 1924 description 1925 "Scanning and sniffing attack types: 1926 IP Sweep attack, Port Scanning, 1927 and etc."; 1929 leaf ip-sweep { 1930 type boolean; 1931 description 1932 "Additional Inspection of 1933 IP Sweep Attack."; 1934 } 1936 leaf port-scanning { 1937 type boolean; 1938 description 1939 "Additional Inspection of 1940 Port Scanning Attack."; 1941 } 1942 } 1943 } 1945 container malformed-packet-attack { 1946 description 1947 "Malformed Packet Attack."; 1948 container malformed-packet-attack-types { 1949 description 1950 "Malformed packet attack types: 1951 Ping of Death Attack, Teardrop Attack, 1952 and etc."; 1954 leaf ping-of-death { 1955 type boolean; 1956 description 1957 "Additional Inspection of 1958 Ping of Death Attack."; 1959 } 1960 leaf teardrop { 1961 type boolean; 1962 description 1963 "Additional Inspection of 1964 Teardrop Attack."; 1965 } 1966 } 1967 } 1969 container special-packet-attack { 1970 description 1971 "special Packet Attack."; 1972 container special-packet-attack-types { 1973 description 1974 "Special packet attack types: 1975 Oversized ICMP Attack, Tracert Attack, 1976 and etc."; 1978 leaf oversized-icmp { 1979 type boolean; 1980 description 1981 "Additional Inspection of 1982 Oversize ICMP Attack."; 1983 } 1985 leaf tracert { 1986 type boolean; 1987 description 1988 "Additional Inspection of 1989 Tracrt Attack."; 1990 } 1991 } 1992 } 1993 } 1994 } 1995 } 1996 } 1997 } 1998 } 1999 } 2001 2003 Figure 5: YANG Data Module of I2NSF NSF-Facing-Interface 2005 7. Security Considerations 2007 This document introduces no additional security threats and SHOULD 2008 follow the security requirements as stated in [RFC8329]. 2010 8. Acknowledgments 2012 This work was supported by Institute for Information & communications 2013 Technology Promotion (IITP) grant funded by the Korea government 2014 (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence 2015 Technology Development for the Customized Security Service 2016 Provisioning). 2018 9. Contributors 2020 I2NSF is a group effort. I2NSF has had a number of contributing 2021 authors. The following are considered co-authors: 2023 o Hyoungshick Kim (Sungkyunkwan University) 2025 o Daeyoung Hyun (Sungkyunkwan University) 2027 o Dongjin Hong (Sungkyunkwan University) 2029 o Liang Xia (Huawei) 2031 o Tae-Jin Ahn (Korea Telecom) 2033 o Se-Hui Lee (Korea Telecom) 2035 10. References 2037 10.1. Normative References 2039 [RFC2119] Bradner, S., "Key words for use in RFCs to 2040 Indicate Requirement Levels", BCP 14, 2041 RFC 2119, March 1997. 2043 [RFC6020] Bjorklund, M., "YANG - A Data Modeling 2044 Language for the Network Configuration 2045 Protocol (NETCONF)", RFC 6020, 2046 October 2010. 2048 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., 2049 Strassner, J., and R. Kumar, "Framework for 2050 Interface to Network Security Functions", 2051 RFC 8329, February 2018. 2053 10.2. Informative References 2055 [i2nsf-nsf-cap-im] Xia, L., Strassner, J., Basile, C., and D. 2056 Lopez, "Information Model of NSFs 2057 Capabilities", 2058 draft-ietf-i2nsf-capability-00 (work in 2059 progress), September 2017. 2061 [i2rs-rib-data-model] Wang, L., Chen, M., Dass, A., 2062 Ananthakrishnan, H., Kini, S., and N. 2063 Bahadur, "A YANG Data Model for Routing 2064 Information Base (RIB)", 2065 draft-ietf-i2rs-rib-data-model-10 (work in 2066 progress), February 2018. 2068 [supa-policy-info-model] Strassner, J., Halpern, J., and S. Meer, 2069 "Generic Policy Information Model for 2070 Simplified Use of Policy Abstractions 2071 (SUPA)", draft-ietf-supa-generic-policy- 2072 info-model-03 (work in progress), May 2017. 2074 Appendix A. Changes from 2075 draft-kim-i2nsf-nsf-facing-interface-data-model-04 2077 The following changes are made from 2078 draft-kim-i2nsf-nsf-facing-interface-data-model-04: 2080 1. We replaced "Objectives" section with "The Structure and 2081 Objective of I2NSF Security Policy" in order to convey clearer 2082 meaning. 2084 2. We replaced the module name for this YANG data model in order to 2085 convey clearer meaning. 2087 3. We modified it to support not only absolute time zone but also 2088 periodic time zone. 2090 4. We added port number to the condition clause. 2092 5. We modified the choice-case structure into a container structure 2093 to allow for the selection of multiple catalogues for condition 2094 and action clauses. 2096 Authors' Addresses 2098 Jinyong Tim Kim 2099 Department of Computer Engineering 2100 Sungkyunkwan University 2101 2066 Seobu-Ro, Jangan-Gu 2102 Suwon, Gyeonggi-Do 16419 2103 Republic of Korea 2105 Phone: +82 10 8273 0930 2106 EMail: timkim@skku.edu 2108 Jaehoon Paul Jeong 2109 Department of Software 2110 Sungkyunkwan University 2111 2066 Seobu-Ro, Jangan-Gu 2112 Suwon, Gyeonggi-Do 16419 2113 Republic of Korea 2115 Phone: +82 31 299 4957 2116 Fax: +82 31 290 7996 2117 EMail: pauljeong@skku.edu 2118 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2120 Jung-Soo Park 2121 Electronics and Telecommunications Research Institute 2122 218 Gajeong-Ro, Yuseong-Gu 2123 Daejeon 34129 2124 Republic of Korea 2126 Phone: +82 42 860 6514 2127 EMail: pjs@etri.re.kr 2129 Susan Hares 2130 Huawei 2131 7453 Hickory Hill 2132 Saline, MI 48176 2133 USA 2135 Phone: +1-734-604-0332 2136 EMail: shares@ndzh.com 2137 Qiushi Lin 2138 Huawei 2139 Huawei Industrial Base 2140 Shenzhen, Guangdong 518129 2141 China 2143 Phone: 2144 EMail: linqiushi@huawei.com