idnits 2.17.1 draft-ietf-i2nsf-nsf-facing-interface-dm-02.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 312 has weird spacing: '...content str...' == Line 408 has weird spacing: '...ategory str...' == Line 423 has weird spacing: '... tenant uin...' == Line 429 has weird spacing: '... tenant uin...' -- The document date (November 4, 2018) is 1994 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 (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group J. Kim 3 Internet-Draft J. Jeong 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: May 8, 2019 J. Park 6 ETRI 7 S. Hares 8 Q. Lin 9 Huawei 10 November 4, 2018 12 I2NSF Network Security Function-Facing Interface YANG Data Model 13 draft-ietf-i2nsf-nsf-facing-interface-dm-02 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 vendors with generic components 22 that they understand well, so these generic components can be used 23 even if they have some vendor specific functions. These generic 24 functions represent a point of interoperability, and can be provided 25 by any product that offers the required capabilities. Also, if they 26 need additional features for their network security functions, the 27 vendors can easily add the features by extending the YANG data model 28 in this document. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 8, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 68 4. The Structure and Objective of I2NSF Security Policy . . . . 4 69 4.1. I2NSF Security Policy Rule . . . . . . . . . . . . . . . 4 70 4.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 4 71 4.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 4 72 4.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 5 73 5. Data Model Structure . . . . . . . . . . . . . . . . . . . . 5 74 5.1. I2NSF Security Policy Rule . . . . . . . . . . . . . . . 5 75 5.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 7 76 5.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 8 77 5.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 10 78 6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 6.1. IETF NSF-Facing Interface YANG Data Module . . . . . . . 12 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 47 83 8.2. Informative References . . . . . . . . . . . . . . . . . 47 84 Appendix A. Changes from draft-ietf-i2nsf-nsf-facing-interface- 85 dm-01 . . . . . . . . . . . . . . . . . . . . . . . 48 86 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 48 87 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 48 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 90 1. Introduction 92 This document defines a YANG [RFC6020] data model for the 93 configuration of security services with the information model for 94 Network Security Functions (NSF) facing interface in Interface to 95 Network Security Functions (I2NSF). It provides a specific 96 information model and the corresponding data models for generic 97 network security functions (i.e., network security functions), as 98 defined in [i2nsf-nsf-cap-im]. With these data model, I2NSF 99 controller can control the capabilities of NSFs. 101 The "Event-Condition-Action" (ECA) policy model is used as the basis 102 for the design of I2NSF Policy Rules. 104 The "ietf-i2nsf-nsf-facing-interface" YANG module defined in this 105 document provides the following features: 107 o Configuration of I2NSF security policy rule for generic network 108 security function policy; 110 o Configuration of event clause for generic network security 111 function policy; 113 o Configuration of condition clause for generic network security 114 function policy; 116 o Configuration of action clause for generic network security 117 function policy. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. Terminology 127 This document uses the terminology described in 128 [i2nsf-nsf-cap-im][RFC8431][supa-policy-info-model]. Especially, the 129 following terms are from [supa-policy-info-model]: 131 o Data Model: A data model is a representation of concepts of 132 interest to an environment in a form that is dependent on data 133 repository, data definition language, query language, 134 implementation language, and protocol. 136 o Information Model: An information model is a representation of 137 concepts of interest to an environment in a form that is 138 independent of data repository, data definition language, query 139 language, implementation language, and protocol. 141 3.1. Tree Diagrams 143 A simplified graphical representation of the data model is used in 144 this document. The meaning of the symbols in these diagrams 145 [RFC8431] is as follows: 147 o Brackets "[" and "]" enclose list keys. 149 o Abbreviations before data node names: "rw" means configuration 150 (read-write) and "ro" state data (read-only). 152 o Symbols after data node names: "?" means an optional node and "*" 153 denotes a "list" and "leaf-list". 155 o Parentheses enclose choice and case nodes, and case nodes are also 156 marked with a colon (":"). 158 o Ellipsis ("...") stands for contents of subtrees that are not 159 shown. 161 4. The Structure and Objective of I2NSF Security Policy 163 4.1. I2NSF Security Policy Rule 165 This shows a policy rule for generic network security functions. The 166 object of a policy rule is defined as policy information and rule 167 information. This includes ECA Policy Rule such as Event Clause 168 Objects, Condition Clause Objects, Action Clause Objects, Resolution 169 Strategy, and Default Action. 171 4.2. Event Clause 173 This shows an event clause for generic network security functions. 174 An Event is any important occurrence in time of a change in the 175 system being managed, and/or in the environment of the system being 176 managed. When used in the context of I2NSF Policy Rules, it is used 177 to determine whether the Condition clause of the I2NSF Policy Rule 178 can be evaluated or not. The object of an event clauses is defined 179 as user security event, device security event, system security event, 180 and time security event. The objects of event clauses can be 181 extended according to specific vendor event features. 183 4.3. Condition Clause 185 This shows a condition clause for generic network security functions. 186 A condition is defined as a set of attributes, features, and/or 187 values that are to be compared with a set of known attributes, 188 features, and/or values in order to determine whether or not the set 189 of Actions in that (imperative) I2NSF Policy Rule can be executed or 190 not. These objects are defined as packet security condition, packet 191 payload security condition, target security condition, user security 192 condition, context condition, and generic context condition. The 193 objects of action clauses can be extended according to specific 194 vendor condition features. 196 4.4. Action Clause 198 This shows an action clause for generic network security functions. 199 An action is used to control and monitor aspects of flow-based NSFs 200 when the event and condition clauses are satisfied. NSFs provide 201 security functions by executing various Actions. The object of an 202 action clause is defined as ingress action, egress action, and apply 203 profile action. The objects of action clauses can be extended 204 according to specific vendor action features. 206 5. Data Model Structure 208 This section shows a data model structure tree of generic network 209 security functions that are defined in the [i2nsf-nsf-cap-im]. Note 210 that a detailed data model for the configuration of the advanced 211 network security functions is described in [i2nsf-advanced-nsf-dm]. 212 The section discusses the following subjects: 214 o Consideration of ECA Policy Model by aggregating the Event, 215 Condition, and Action Clause Objects; 217 o Consideration of Capability Algebra; 219 o Consideration of NSFs Capability Categories (i.e., Network 220 Security, Content Security, and Attack Mitigation Capabilities); 222 o Definition for Network Security Event Class, Network Security 223 Condition Class, and Network Security Action Class. 225 5.1. I2NSF Security Policy Rule 227 The data model for the identification of network security policy has 228 the following structure: 230 module: ietf-i2nsf-policy-rule-for-nsf 231 +--rw i2nsf-security-policy 232 +--rw system-policy* [system-policy-name] 233 +--rw system-policy-name string 234 +--rw priority-usage priority-usage-type 235 +--rw rules* [rule-name] 236 | +--rw rule-name string 237 | +--rw rule-description? string 238 | +--rw rule-priority? uint8 239 | +--rw enable? boolean 240 | +--rw session-aging-time? uint16 241 | +--rw long-connection 242 | | +--rw enable? boolean 243 | | +--rw during? uint16 244 | +--rw time-zone 245 | | +--rw absolute-time-zone 246 | | | +--rw time 247 | | | | +--rw start-time? yang:date-and-time 248 | | | | +--rw end-time? yang:date-and-time 249 | | | +--rw date 250 | | | +--rw absolute-date? yang:date-and-time 251 | | +--rw periodic-time-zone 252 | | +--rw day 253 | | | +--rw sunday? boolean 254 | | | +--rw monday? boolean 255 | | | +--rw tuesday? boolean 256 | | | +--rw wednesday? boolean 257 | | | +--rw thursday? boolean 258 | | | +--rw friday? boolean 259 | | | +--rw saturday? boolean 260 | | +--rw month 261 | | +--rw january? boolean 262 | | +--rw february? boolean 263 | | +--rw march? boolean 264 | | +--rw april? boolean 265 | | +--rw may? boolean 266 | | +--rw june? boolean 267 | | +--rw july? boolean 268 | | +--rw august? boolean 269 | | +--rw september? boolean 270 | | +--rw october? boolean 271 | | +--rw november? boolean 272 | | +--rw december? boolean 273 | +--rw event-clause-container 274 | | ... 275 | +--rw condition-clause-container 276 | | ... 277 | +--rw action-clause-container 278 | ... 279 +--rw resolution-strategy 280 | +--rw (resolution-strategy-type)? 281 | +--:(fmr) 282 | | +--rw first-matching-rule? boolean 283 | +--:(lmr) 284 | +--rw last-matching-rule? boolean 285 +--rw default-action 286 | +--rw default-action-type? boolean 287 +--rw rule-group 288 +--rw groups* [group-name] 289 +--rw group-name string 290 +--rw rule-range 291 | +--rw start-rule? string 292 | +--rw end-rule? string 293 +--rw enable? boolean 294 +--rw description? string 296 Figure 1: Data Model Structure for Network Security Policy 297 Identification 299 5.2. Event Clause 301 The data model for event rule has the following structure: 303 module: ietf-i2nsf-policy-rule-for-nsf 304 +--rw i2nsf-security-policy 305 +--rw system-policy* [system-policy-name] 306 ... 307 | +--rw event-clause-container 308 | | +--rw event-clause-list* [eca-object-id] 309 | | +--rw entity-class? identityref 310 | | +--rw eca-object-id string 311 | | +--rw description? string 312 | | +--rw sec-event-content string 313 | | +--rw sec-event-format sec-event-format 314 | | +--rw sec-event-type string 315 | +--rw condition-clause-container 316 | | ... 317 | +--rw action-clause-container 318 | ... 319 +--rw resolution-strategy 320 | ... 321 +--rw default-action 322 | ... 323 +--rw rule-group 324 ... 326 Figure 2: Data Model Structure for Event Rule 328 These objects are defined as user security event, device security 329 event, system security event, and time security event. These objects 330 can be extended according to specific vendor event features. We will 331 add additional event objects for more generic network security 332 functions. 334 5.3. Condition Clause 336 The data model for condition rule has the following structure: 338 module: ietf-i2nsf-policy-rule-for-nsf 339 +--rw i2nsf-security-policy 340 +--rw system-policy* [system-policy-name] 341 ... 342 | +--rw event-clause-container 343 | | ... 344 | +--rw condition-clause-container 345 | | +--rw condition-clause-list* [eca-object-id] 346 | | +--rw entity-class? identityref 347 | | +--rw eca-object-id string 348 | | +--rw packet-security-condition 349 | | | +--rw packet-description? string 350 | | | +--rw packet-security-mac-condition 351 | | | | +--rw pkt-sec-cond-mac-dest* yang:phys-address 352 | | | | +--rw pkt-sec-cond-mac-src* yang:phys-address 353 | | | | +--rw pkt-sec-cond-mac-8021q* string 354 | | | | +--rw pkt-sec-cond-mac-ether-type* string 355 | | | | +--rw pkt-sec-cond-mac-tci* string 356 | | | +--rw packet-security-ipv4-condition 357 | | | | +--rw pkt-sec-cond-ipv4-header-length* uint8 358 | | | | +--rw pkt-sec-cond-ipv4-tos* uint8 359 | | | | +--rw pkt-sec-cond-ipv4-total-length* uint16 360 | | | | +--rw pkt-sec-cond-ipv4-id* uint8 361 | | | | +--rw pkt-sec-cond-ipv4-fragment* uint8 362 | | | | +--rw pkt-sec-cond-ipv4-fragment-offset* uint16 363 | | | | +--rw pkt-sec-cond-ipv4-ttl* uint8 364 | | | | +--rw pkt-sec-cond-ipv4-protocol* uint8 365 | | | | +--rw pkt-sec-cond-ipv4-src* inet:ipv4-address 366 | | | | +--rw pkt-sec-cond-ipv4-dest* inet:ipv4-address 367 | | | | +--rw pkt-sec-cond-ipv4-ipopts? string 368 | | | | +--rw pkt-sec-cond-ipv4-sameip? boolean 369 | | | | +--rw pkt-sec-cond-ipv4-geoip* string 370 | | | +--rw packet-security-ipv6-condition 371 | | | | +--rw pkt-sec-cond-ipv6-dscp* string 372 | | | | +--rw pkt-sec-cond-ipv6-ecn* string 373 | | | | +--rw pkt-sec-cond-ipv6-traffic-class* uint8 374 | | | | +--rw pkt-sec-cond-ipv6-flow-label* uint32 375 | | | | +--rw pkt-sec-cond-ipv6-payload-length* uint16 376 | | | | +--rw pkt-sec-cond-ipv6-next-header* uint8 377 | | | | +--rw pkt-sec-cond-ipv6-hop-limit* uint8 378 | | | | +--rw pkt-sec-cond-ipv6-src* inet:ipv6-address 379 | | | | +--rw pkt-sec-cond-ipv6-dest* inet:ipv6-address 380 | | | +--rw packet-security-tcp-condition 381 | | | | +--rw pkt-sec-cond-tcp-src-port* inet:port-number 382 | | | | +--rw pkt-sec-cond-tcp-dest-port* inet:port-number 383 | | | | +--rw pkt-sec-cond-tcp-seq-num* uint32 384 | | | | +--rw pkt-sec-cond-tcp-ack-num* uint32 385 | | | | +--rw pkt-sec-cond-tcp-window-size* uint16 386 | | | | +--rw pkt-sec-cond-tcp-flags* uint8 387 | | | +--rw packet-security-udp-condition 388 | | | | +--rw pkt-sec-cond-udp-src-port* inet:port-number 389 | | | | +--rw pkt-sec-cond-udp-dest-port* inet:port-number 390 | | | | +--rw pkt-sec-cond-udp-length* string 391 | | | +--rw packet-security-icmp-condition 392 | | | +--rw pkt-sec-cond-icmp-type* uint8 393 | | | +--rw pkt-sec-cond-icmp-code* uint8 394 | | | +--rw pkt-sec-cond-icmp-seg-num* uint32 395 | | +--rw packet-payload-condition 396 | | | +--rw packet-payload-description? string 397 | | | +--rw pkt-payload-content* string 398 | | +--rw acl-number? uint32 399 | | +--rw application-condition 400 | | | +--rw application-description? string 401 | | | +--rw application-object* string 402 | | | +--rw application-group* string 403 | | | +--rw application-label* string 404 | | | +--rw category 405 | | | +--rw application-category* 406 | | | [name application-subcategory] 407 | | | +--rw name string 408 | | | +--rw application-subcategory string 409 | | +--rw target-condition 410 | | | +--rw target-description? string 411 | | | +--rw device-sec-context-cond 412 | | | +--rw pc? boolean 413 | | | +--rw mobile-phone? boolean 414 | | | +--rw voip-volte-phone? boolean 415 | | | +--rw tablet? boolean 416 | | | +--rw iot? boolean 417 | | | +--rw vehicle? boolean 418 | | +--rw users-condition 419 | | | +--rw users-description? string 420 | | | +--rw user 421 | | | | +--rw (user-name)? 422 | | | | +--:(tenant) 423 | | | | | +--rw tenant uint8 424 | | | | +--:(vn-id) 425 | | | | +--rw vn-id uint8 426 | | | +--rw group 427 | | | | +--rw (group-name)? 428 | | | | +--:(tenant) 429 | | | | | +--rw tenant uint8 430 | | | | +--:(vn-id) 431 | | | | +--rw vn-id uint8 432 | | | +--rw security-grup string 433 | | +--rw url-category-condition 434 | | | +--rw url-category-description? string 435 | | | +--rw pre-defined-category* string 436 | | | +--rw user-defined-category* string 437 | | +--rw context-condition 438 | | | +--rw context-description? string 439 | | +--rw gen-context-condition 440 | | +--rw gen-context-description? string 441 | | +--rw geographic-location 442 | | +--rw src-geographic-location* uint32 443 | | +--rw dest-geographic-location* uint32 444 | +--rw action-clause-container 445 | ... 446 +--rw resolution-strategy 447 | ... 448 +--rw default-action 449 | ... 450 +--rw rule-group 451 ... 453 Figure 3: Data Model Structure for Condition Rule 455 These objects are defined as packet security condition, packet 456 payload security condition, target security condition, user security 457 condition, context condition, and generic context condition. These 458 objects can be extended according to specific vendor condition 459 features. We will add additional condition objects for more generic 460 network security functions. 462 5.4. Action Clause 464 The data model for action rule has the following structure: 466 module: ietf-i2nsf-policy-rule-for-nsf 467 +--rw i2nsf-security-policy 468 +--rw system-policy* [system-policy-name] 469 ... 470 | +--rw event-clause-container 471 | | ... 472 | +--rw condition-clause-container 473 | | ... 474 | +--rw action-clause-container 475 | +--rw action-clause-list* [eca-object-id] 476 | +--rw entity-class? identityref 477 | +--rw eca-object-id string 478 | +--rw rule-log? boolean 479 | +--rw session-log? boolean 480 | +--rw ingress-action 481 | | +--rw ingress-description? string 482 | | +--rw ingress-action-type? ingress-action 483 | +--rw egress-action 484 | | +--rw egress-description? string 485 | | +--rw egress-action-type? egress-action 486 | +--rw apply-profile 487 | +--rw profile-description? string 488 | +--rw content-security-control 489 | | +--rw content-security-control-types 490 | | +--rw antivirus? string 491 | | +--rw ips? string 492 | | +--rw ids? string 493 | | +--rw url-filtering? string 494 | | +--rw data-filtering? string 495 | | +--rw mail-filtering? string 496 | | +--rw file-blocking? string 497 | | +--rw file-isolate? string 498 | | +--rw pkt-capture? string 499 | | +--rw application-control? string 500 | | +--rw voip-volte? string 501 | +--rw attack-mitigation-control 502 | +--rw ddos-attack 503 | | +--rw ddos-attack-type 504 | | +--rw network-layer-ddos-attack 505 | | | +--rw network-layer-ddos-attack-type 506 | | | +--rw syn-flood? string 507 | | | +--rw udp-flood? string 508 | | | +--rw icmp-flood? string 509 | | | +--rw ip-frag-flood? string 510 | | | +--rw ipv6-related? string 511 | | +--rw app-layer-ddos-attack 512 | | +--rw app-ddos-attack-types 513 | | +--rw http-flood? string 514 | | +--rw https-flood? string 515 | | +--rw dns-flood? string 516 | | +--rw dns-amp-flood? string 517 | | +--rw ssl-ddos? string 518 | +--rw single-packet-attack 519 | +--rw single-packet-attack-type 520 | +--rw scan-and-sniff-attack 521 | | +--rw scan-and-sniff-attack-types 522 | | +--rw ip-sweep? string 523 | | +--rw port-scanning? string 524 | +--rw malformed-packet-attack 525 | | +--rw malformed-packet-attack-types 526 | | +--rw ping-of-death? string 527 | | +--rw teardrop? string 528 | +--rw special-packet-attack 529 | +--rw special-packet-attack-types 530 | +--rw oversized-icmp? string 531 | +--rw tracert? string 532 +--rw resolution-strategy 533 | ... 534 +--rw default-action 535 | ... 536 +--rw rule-group 537 ... 539 Figure 4: Data Model Structure for Action Rule 541 These objects are defined as ingress action, egress action, and apply 542 profile action. These objects can be extended according to specific 543 vendor action feature. We will add additional action objects for 544 more generic network security functions. 546 6. YANG Module 548 6.1. IETF NSF-Facing Interface YANG Data Module 550 This section introduces a YANG module for the information model of 551 network security functions, as defined in the [i2nsf-nsf-cap-im]. 553 file "ietf-i2nsf-policy-rule-for-nsf@2018-11-04.yang" 555 module ietf-i2nsf-policy-rule-for-nsf { 556 yang-version 1.1; 557 namespace 558 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"; 559 prefix 560 policy-rule-for-nsf; 562 import ietf-inet-types{ 563 prefix inet; 564 } 565 import ietf-yang-types{ 566 prefix yang; 567 } 569 organization 570 "IETF I2NSF (Interface to Network Security Functions) 571 Working Group"; 573 contact 574 "WG Web: 575 WG List: 577 WG Chair: Adrian Farrel 578 580 WG Chair: Linda Dunbar 581 583 Editor: Jingyong Tim Kim 584 586 Editor: Jaehoon Paul Jeong 587 589 Editor: Susan Hares 590 "; 592 description 593 "This module defines a YANG data module for network security 594 functions."; 595 revision "2018-11-04"{ 596 description "The fourth revision"; 597 reference 598 "draft-ietf-i2nsf-capability-04"; 599 } 601 typedef sec-event-format { 602 type enumeration { 603 enum unknown { 604 description 605 "If SecEventFormat is unknown"; 606 } 607 enum guid { 608 description 609 "If SecEventFormat is GUID 610 (Generic Unique IDentifier)"; 611 } 612 enum uuid { 613 description 614 "If SecEventFormat is UUID 615 (Universal Unique IDentifier)"; 616 } 617 enum uri { 618 description 619 "If SecEventFormat is URI 620 (Uniform Resource Identifier)"; 621 } 622 enum fqdn { 623 description 624 "If SecEventFormat is FQDN 625 (Fully Qualified Domain Name)"; 626 } 627 enum fqpn { 628 description 629 "If SecEventFormat is FQPN 630 (Fully Qualified Path Name)"; 631 } 632 } 633 description 634 "This is used for SecEventFormat."; 635 } 637 typedef priority-usage-type { 638 type enumeration { 639 enum priority-by-order { 640 description 641 "If priority type is order"; 642 } 643 enum priority-by-number { 644 description 645 "If priority type is number"; 646 } 647 } 648 description 649 "This is used for priority type."; 650 } 652 typedef ingress-action { 653 type enumeration { 654 enum pass { 655 description 656 "If ingress action is pass"; 657 } 658 enum drop { 659 description 660 "If ingress action is drop"; 661 } 662 enum reject { 663 description 664 "If ingress action is reject"; 665 } 666 enum alert { 667 description 668 "If ingress action is alert"; 669 } 670 enum mirror { 671 description 672 "If ingress action is mirror"; 673 } 674 } 675 description 676 "This is used for ingress action."; 677 } 679 typedef egress-action { 680 type enumeration { 681 enum invoke-signaling { 682 description 683 "If egress action is invoke signaling"; 684 } 685 enum tunnel-encapsulation { 686 description 687 "If egress action is tunnel encapsulation"; 688 } 689 enum forwarding { 690 description 691 "If egress action is forwarding"; 692 } 693 enum redirection { 694 description 695 "If egress action is redirection"; 696 } 697 } 698 description 699 "This is used for egress action."; 700 } 702 identity ECA-OBJECT-TYPE { 703 description "TBD"; 704 } 706 identity ECA-EVENT-TYPE { 707 base ECA-OBJECT-TYPE; 708 description "TBD"; 709 } 711 identity ECA-CONDITION-TYPE { 712 base ECA-OBJECT-TYPE; 713 description "TBD"; 714 } 715 identity ECA-ACTION-TYPE { 716 base ECA-OBJECT-TYPE; 717 description "TBD"; 718 } 720 identity EVENT-USER-TYPE { 721 base ECA-EVENT-TYPE; 722 description "TBD"; 723 } 725 identity EVENT-DEV-TYPE { 726 base ECA-EVENT-TYPE; 727 description "TBD"; 728 } 730 identity EVENT-SYS-TYPE { 731 base ECA-EVENT-TYPE; 732 description "TBD"; 733 } 735 identity EVENT-TIME-TYPE { 736 base ECA-EVENT-TYPE; 737 description "TBD"; 738 } 740 grouping i2nsf-eca-object-type { 741 leaf entity-class { 742 type identityref { 743 base ECA-OBJECT-TYPE; 744 } 745 description "TBD"; 746 } 747 leaf eca-object-id { 748 type string; 749 description "TBD"; 750 } 751 description "TBD"; 752 } 754 grouping i2nsf-event-type { 755 description "TBD"; 756 leaf description { 757 type string; 758 description 759 "This is description for event. 760 Vendors can write instructions for event 761 that vendor made"; 763 } 765 leaf sec-event-content { 766 type string; 767 mandatory true; 768 description 769 "This is a mandatory string that contains the content 770 of the SecurityEvent. The format of the content 771 is specified in the SecEventFormat class 772 attribute, and the type of event is defined in the 773 SecEventType class attribute. An example of the 774 SecEventContent attribute is a string hrAdmin, 775 with the SecEventFormat set to 1 (GUID) and the 776 SecEventType attribute set to 5 (new logon)."; 777 } 779 leaf sec-event-format { 780 type sec-event-format; 781 mandatory true; 782 description 783 "This is a mandatory uint 8 enumerated integer, which 784 is used to specify the data type of the 785 SecEventContent attribute. The content is 786 specified in the SecEventContent class attribute, 787 and the type of event is defined in the 788 SecEventType class attribute. An example of the 789 SecEventContent attribute is string hrAdmin, 790 with the SecEventFormat attribute set to 1 (GUID) 791 and the SecEventType attribute set to 5 792 (new logon)."; 793 } 795 leaf sec-event-type { 796 type string; 797 mandatory true; 798 description 799 "This is a mandatory uint 8 enumerated integer, which 800 is used to specify the type of event that involves 801 this user. The content and format are specified in 802 the SecEventContent and SecEventFormat class 803 attributes, respectively. An example of the 804 SecEventContent attribute is string hrAdmin, 805 with the SecEventFormat attribute set to 1 (GUID) 806 and the SecEventType attribute set to 5 807 (new logon)."; 808 } 810 } 811 container i2nsf-security-policy { 812 description 813 "policy is a container 814 including a set of security rules according to certain logic, 815 i.e., their similarity or mutual relations, etc. The network 816 security policy is able to apply over both the unidirectional 817 and bidirectional traffic across the NSF."; 819 list system-policy { 820 key "system-policy-name"; 821 description 822 "The system-policy represents there could be multiple system 823 policies in one NSF, and each system policy is used by 824 one virtual instance of the NSF/device."; 826 leaf system-policy-name { 827 type string; 828 mandatory true; 829 description 830 "The name of the policy. 831 This must be unique."; 832 } 834 leaf priority-usage { 835 type priority-usage-type; 836 mandatory true; 837 description 838 "This is priority type."; 839 } 841 list rules { 842 key "rule-name"; 843 description 844 "This is a rule for network security functions."; 846 leaf rule-name { 847 type string; 848 mandatory true; 849 description 850 "The id of the rule. 851 This must be unique."; 852 } 854 leaf rule-description { 855 type string; 856 description 857 "This description gives more information about 858 rules."; 859 } 861 leaf rule-priority { 862 type uint8; 863 description 864 "The priority keyword comes with a mandatory 865 numeric value which can range from 1 till 255."; 866 } 868 leaf enable { 869 type boolean; 870 description 871 "True is enable. 872 False is not enbale."; 873 } 875 leaf session-aging-time { 876 type uint16; 877 description 878 "This is session aging time."; 879 } 881 container long-connection { 882 description 883 "This is long-connection"; 885 leaf enable { 886 type boolean; 887 description 888 "True is enable. 889 False is not enbale."; 890 } 892 leaf during { 893 type uint16; 894 description 895 "This is during time."; 896 } 897 } 899 container time-zone { 900 description 901 "This can be used to apply rules according to time-zone"; 902 container absolute-time-zone { 903 description 904 "This can be used to apply rules according to 905 absolute-time"; 906 container time { 907 description 908 "This can be used to apply rules according to time"; 909 leaf start-time { 910 type yang:date-and-time; 911 description 912 "This is start time for time zone"; 913 } 914 leaf end-time { 915 type yang:date-and-time; 916 description 917 "This is end time for time zone"; 918 } 919 } 920 container date { 921 description 922 "This can be used to apply rules according to date"; 923 leaf absolute-date { 924 type yang:date-and-time; 925 description 926 "This is absolute date for time zone"; 927 } 928 } 929 } 930 container periodic-time-zone { 931 description 932 "This can be used to apply rules according to 933 periodic-time-zone"; 934 container day { 935 description 936 "This can be used to apply rules according 937 to periodic day"; 938 leaf sunday { 939 type boolean; 940 description 941 "This is sunday for periodic day"; 942 } 943 leaf monday { 944 type boolean; 945 description 946 "This is monday for periodic day"; 947 } 948 leaf tuesday { 949 type boolean; 950 description 951 "This is tuesday for periodic day"; 952 } 953 leaf wednesday { 954 type boolean; 955 description 956 "This is wednesday for periodic day"; 957 } 958 leaf thursday { 959 type boolean; 960 description 961 "This is thursday for periodic day"; 962 } 963 leaf friday { 964 type boolean; 965 description 966 "This is friday for periodic day"; 967 } 968 leaf saturday { 969 type boolean; 970 description 971 "This is saturday for periodic day"; 972 } 973 } 974 container month { 975 description 976 "This can be used to apply rules according 977 to periodic month"; 978 leaf january { 979 type boolean; 980 description 981 "This is january for periodic month"; 982 } 983 leaf february { 984 type boolean; 985 description 986 "This is february for periodic month"; 987 } 988 leaf march { 989 type boolean; 990 description 991 "This is march for periodic month"; 992 } 993 leaf april { 994 type boolean; 995 description 996 "This is april for periodic month"; 997 } 998 leaf may { 999 type boolean; 1000 description 1001 "This is may for periodic month"; 1002 } 1003 leaf june { 1004 type boolean; 1005 description 1006 "This is june for periodic month"; 1007 } 1008 leaf july { 1009 type boolean; 1010 description 1011 "This is july for periodic month"; 1012 } 1013 leaf august { 1014 type boolean; 1015 description 1016 "This is august for periodic month"; 1017 } 1018 leaf september { 1019 type boolean; 1020 description 1021 "This is september for periodic month"; 1022 } 1023 leaf october { 1024 type boolean; 1025 description 1026 "This is october for periodic month"; 1027 } 1028 leaf november { 1029 type boolean; 1030 description 1031 "This is november for periodic month"; 1032 } 1033 leaf december { 1034 type boolean; 1035 description 1036 "This is december for periodic month"; 1037 } 1038 } 1039 } 1040 } 1042 container event-clause-container { 1043 description "TBD"; 1044 list event-clause-list { 1045 key eca-object-id; 1046 uses i2nsf-eca-object-type { 1047 refine entity-class { 1048 default ECA-EVENT-TYPE; 1050 } 1051 } 1053 description 1054 " This is abstract. An event is defined as any important 1055 occurrence in time of a change in the system being 1056 managed, and/or in the environment of the system being 1057 managed. When used in the context of policy rules for 1058 a flow-based NSF, it is used to determine whether the 1059 Condition clause of the Policy Rule can be evaluated 1060 or not. Examples of an I2NSF event include time and 1061 user actions (e.g., logon, logoff, and actions that 1062 violate any ACL.)."; 1064 uses i2nsf-event-type; 1065 } 1066 } 1067 container condition-clause-container { 1068 description "TBD"; 1069 list condition-clause-list { 1070 key eca-object-id; 1071 uses i2nsf-eca-object-type { 1072 refine entity-class { 1073 default ECA-CONDITION-TYPE; 1074 } 1075 } 1076 description 1077 " This is abstract. A condition is defined as a set 1078 of attributes, features, and/or values that are to be 1079 compared with a set of known attributes, features, 1080 and/or values in order to determine whether or not the 1081 set of Actions in that (imperative) I2NSF Policy Rule 1082 can be executed or not. Examples of I2NSF Conditions 1083 include matching attributes of a packet or flow, and 1084 comparing the internal state of an NSF to a desired 1085 state."; 1087 container packet-security-condition { 1088 description 1089 "TBD"; 1090 leaf packet-description { 1091 type string; 1092 description 1093 "This is description for packet condition. 1094 Vendors can write instructions for packet condition 1095 that vendor made"; 1096 } 1097 container packet-security-mac-condition { 1098 description 1099 "The purpose of this Class is to represent packet MAC 1100 packet header information that can be used as part of 1101 a test to determine if the set of Policy Actions in 1102 this ECA Policy Rule should be execute or not."; 1104 leaf-list pkt-sec-cond-mac-dest { 1105 type yang:phys-address; 1106 description 1107 "The MAC destination address (6 octets long)."; 1108 } 1110 leaf-list pkt-sec-cond-mac-src { 1111 type yang:phys-address; 1112 description 1113 "The MAC source address (6 octets long)."; 1114 } 1116 leaf-list pkt-sec-cond-mac-8021q { 1117 type string; 1118 description 1119 "This is an optional string attribute, and defines 1120 The 802.1Q tab value (2 octets long)."; 1121 } 1123 leaf-list pkt-sec-cond-mac-ether-type { 1124 type string; 1125 description 1126 "The EtherType field (2 octets long). Values up to 1127 and including 1500 indicate the size of the 1128 payload in octets; values of 1536 and above 1129 define which protocol is encapsulated in the 1130 payload of the frame."; 1131 } 1133 leaf-list pkt-sec-cond-mac-tci { 1134 type string; 1135 description 1136 "This is an optional string attribute, and defines 1137 the Tag Control Information. This consists of a 3 1138 bit user priority field, a drop eligible indicator 1139 (1 bit), and a VLAN identifier (12 bits)."; 1140 } 1141 } 1143 container packet-security-ipv4-condition { 1144 description 1145 "The purpose of this Class is to represent IPv4 1146 packet header information that can be used as 1147 part of a test to determine if the set of Policy 1148 Actions in this ECA Policy Rule should be executed 1149 or not."; 1151 leaf-list pkt-sec-cond-ipv4-header-length { 1152 type uint8; 1153 description 1154 "The IPv4 packet header consists of 14 fields, 1155 of which 13 are required."; 1156 } 1158 leaf-list pkt-sec-cond-ipv4-tos { 1159 type uint8; 1160 description 1161 "The ToS field could specify a datagram's priority 1162 and request a route for low-delay, 1163 high-throughput, or highly-reliable service.."; 1164 } 1166 leaf-list pkt-sec-cond-ipv4-total-length { 1167 type uint16; 1168 description 1169 "This 16-bit field defines the entire packet size, 1170 including header and data, in bytes."; 1171 } 1173 leaf-list pkt-sec-cond-ipv4-id { 1174 type uint8; 1175 description 1176 "This field is an identification field and is 1177 primarily used for uniquely identifying 1178 the group of fragments of a single IP datagram."; 1179 } 1181 leaf-list pkt-sec-cond-ipv4-fragment { 1182 type uint8; 1183 description 1184 "IP fragmentation is an Internet Protocol (IP) 1185 process that breaks datagrams into smaller pieces 1186 (fragments), so that packets may be formed that 1187 can pass through a link with a smaller maximum 1188 transmission unit (MTU) than the original 1189 datagram size."; 1190 } 1192 leaf-list pkt-sec-cond-ipv4-fragment-offset { 1193 type uint16; 1194 description 1195 "Fragment offset field along with Don't Fragment 1196 and More Fragment flags in the IP protocol 1197 header are used for fragmentation and reassembly 1198 of IP datagrams."; 1199 } 1201 leaf-list pkt-sec-cond-ipv4-ttl { 1202 type uint8; 1203 description 1204 "The ttl keyword is used to check for a specific 1205 IP time-to-live value in the header of 1206 a packet."; 1207 } 1209 leaf-list pkt-sec-cond-ipv4-protocol { 1210 type uint8; 1211 description 1212 "Internet Protocol version 4(IPv4) is the fourth 1213 version of the Internet Protocol (IP)."; 1214 } 1216 leaf-list pkt-sec-cond-ipv4-src { 1217 type inet:ipv4-address; 1218 description 1219 "Defines the IPv4 Source Address."; 1220 } 1222 leaf-list pkt-sec-cond-ipv4-dest { 1223 type inet:ipv4-address; 1224 description 1225 "Defines the IPv4 Destination Address."; 1226 } 1228 leaf pkt-sec-cond-ipv4-ipopts { 1229 type string; 1230 description 1231 "With the ipopts keyword you can check if 1232 a specific ip option is set. Ipopts has 1233 to be used at the beginning of a rule."; 1234 } 1236 leaf pkt-sec-cond-ipv4-sameip { 1237 type boolean; 1238 description 1239 "Every packet has a source IP-address and 1240 a destination IP-address. It can be that 1241 the source IP is the same as 1242 the destination IP."; 1243 } 1245 leaf-list pkt-sec-cond-ipv4-geoip { 1246 type string; 1247 description 1248 "The geoip keyword enables you to match on 1249 the source, destination or source and destination 1250 IP addresses of network traffic and to see to 1251 which country it belongs. To do this, Suricata 1252 uses GeoIP API with MaxMind database format."; 1253 } 1254 } 1256 container packet-security-ipv6-condition { 1257 description 1258 "The purpose of this Class is to represent packet 1259 IPv6 packet header information that can be used as 1260 part of a test to determine if the set of Policy 1261 Actions in this ECA Policy Rule should be executed 1262 or not."; 1264 leaf-list pkt-sec-cond-ipv6-dscp { 1265 type string; 1266 description 1267 "Differentiated Services Code Point (DSCP) 1268 of ipv6."; 1269 } 1271 leaf-list pkt-sec-cond-ipv6-ecn { 1272 type string; 1273 description 1274 "ECN allows end-to-end notification of network 1275 congestion without dropping packets."; 1276 } 1278 leaf-list pkt-sec-cond-ipv6-traffic-class { 1279 type uint8; 1280 description 1281 "The bits of this field hold two values. The 6 1282 most-significant bits are used for 1283 differentiated services, which is used to 1284 classify packets."; 1285 } 1287 leaf-list pkt-sec-cond-ipv6-flow-label { 1288 type uint32; 1289 description 1290 "The flow label when set to a non-zero value 1291 serves as a hint to routers and switches 1292 with multiple outbound paths that these 1293 packets should stay on the same path so that 1294 they will not be reordered."; 1295 } 1297 leaf-list pkt-sec-cond-ipv6-payload-length { 1298 type uint16; 1299 description 1300 "The size of the payload in octets, 1301 including any extension headers."; 1302 } 1304 leaf-list pkt-sec-cond-ipv6-next-header { 1305 type uint8; 1306 description 1307 "Specifies the type of the next header. 1308 This field usually specifies the transport 1309 layer protocol used by a packet's payload."; 1310 } 1312 leaf-list pkt-sec-cond-ipv6-hop-limit { 1313 type uint8; 1314 description 1315 "Replaces the time to live field of IPv4."; 1316 } 1318 leaf-list pkt-sec-cond-ipv6-src { 1319 type inet:ipv6-address; 1320 description 1321 "The IPv6 address of the sending node."; 1322 } 1324 leaf-list pkt-sec-cond-ipv6-dest { 1325 type inet:ipv6-address; 1326 description 1327 "The IPv6 address of the destination node(s)."; 1328 } 1329 } 1331 container packet-security-tcp-condition { 1332 description 1333 "The purpose of this Class is to represent packet 1334 TCP packet header information that can be used as 1335 part of a test to determine if the set of Policy 1336 Actions in this ECA Policy Rule should be executed 1337 or not."; 1339 leaf-list pkt-sec-cond-tcp-src-port { 1340 type inet:port-number; 1341 description 1342 "This is a mandatory string attribute, and 1343 defines the Source Port number (16 bits)."; 1344 } 1346 leaf-list pkt-sec-cond-tcp-dest-port { 1347 type inet:port-number; 1348 description 1349 "This is a mandatory string attribute, and 1350 defines the Destination Port number (16 bits)."; 1351 } 1353 leaf-list pkt-sec-cond-tcp-seq-num { 1354 type uint32; 1355 description 1356 "If the SYN flag is set (1), then this is the 1357 initial sequence number."; 1358 } 1360 leaf-list pkt-sec-cond-tcp-ack-num { 1361 type uint32; 1362 description 1363 "If the ACK flag is set then the value of this 1364 field is the next sequence number that the sender 1365 is expecting."; 1366 } 1368 leaf-list pkt-sec-cond-tcp-window-size { 1369 type uint16; 1370 description 1371 "The size of the receive window, which specifies 1372 the number of windows size units 1373 (by default,bytes) (beyond the segment 1374 identified by the sequence number in the 1375 acknowledgment field) that the sender of this 1376 segment is currently willing to recive."; 1377 } 1379 leaf-list pkt-sec-cond-tcp-flags { 1380 type uint8; 1381 description 1382 "This is a mandatory string attribute, and defines 1383 the nine Control bit flags (9 bits)."; 1384 } 1386 } 1388 container packet-security-udp-condition { 1389 description 1390 "The purpose of this Class is to represent packet UDP 1391 packet header information that can be used as part 1392 of a test to determine if the set of Policy Actions 1393 in this ECA Policy Rule should be executed or not."; 1395 leaf-list pkt-sec-cond-udp-src-port { 1396 type inet:port-number; 1397 description 1398 "This is a mandatory string attribute, and 1399 defines the UDP Source Port number (16 bits)."; 1400 } 1402 leaf-list pkt-sec-cond-udp-dest-port { 1403 type inet:port-number; 1404 description 1405 "This is a mandatory string attribute, and 1406 defines the UDP Destination Port number (16 bits)."; 1407 } 1409 leaf-list pkt-sec-cond-udp-length { 1410 type string; 1411 description 1412 "This is a mandatory string attribute, and defines 1413 the length in bytes of the UDP header and data 1414 (16 bits)."; 1415 } 1416 } 1418 container packet-security-icmp-condition { 1419 description 1420 "The internet control message protocol condition."; 1422 leaf-list pkt-sec-cond-icmp-type { 1423 type uint8; 1424 description 1425 "ICMP type, see Control messages."; 1426 } 1428 leaf-list pkt-sec-cond-icmp-code { 1429 type uint8; 1430 description 1431 "ICMP subtype, see Control messages."; 1432 } 1433 leaf-list pkt-sec-cond-icmp-seg-num { 1434 type uint32; 1435 description 1436 "The icmp Sequence Number."; 1437 } 1438 } 1439 } 1441 container packet-payload-condition { 1442 description 1443 "TBD"; 1444 leaf packet-payload-description { 1445 type string; 1446 description 1447 "This is description for payload condition. 1448 Vendors can write instructions for payload condition 1449 that vendor made"; 1450 } 1451 leaf-list pkt-payload-content { 1452 type string; 1453 description 1454 "The content keyword is very important in 1455 signatures. Between the quotation marks you 1456 can write on what you would like the 1457 signature to match."; 1458 } 1459 } 1461 leaf acl-number { 1462 type uint32; 1463 description 1464 "This is acl-number."; 1465 } 1467 container application-condition { 1468 description 1469 "TBD"; 1470 leaf application-description { 1471 type string; 1472 description 1473 "This is description for application condition."; 1474 } 1475 leaf-list application-object { 1476 type string; 1477 description 1478 "This is application object."; 1479 } 1480 leaf-list application-group { 1481 type string; 1482 description 1483 "This is application group."; 1484 } 1485 leaf-list application-label { 1486 type string; 1487 description 1488 "This is application label."; 1489 } 1490 container category { 1491 description 1492 "TBD"; 1493 list application-category { 1494 key "name application-subcategory"; 1495 description 1496 "TBD"; 1497 leaf name { 1498 type string; 1499 description 1500 "This is name for application category."; 1501 } 1502 leaf application-subcategory { 1503 type string; 1504 description 1505 "This is application subcategory."; 1506 } 1507 } 1508 } 1509 } 1511 container target-condition { 1512 description 1513 "TBD"; 1514 leaf target-description { 1515 type string; 1516 description 1517 "This is description for target condition. 1518 Vendors can write instructions for target condition 1519 that vendor made"; 1520 } 1522 container device-sec-context-cond { 1523 description 1524 "The device attribute that can identify a device, 1525 including the device type (i.e., router, switch, 1526 pc, ios, or android) and the device's owner as 1527 well."; 1529 leaf pc { 1530 type boolean; 1531 description 1532 "If type of a device is PC."; 1533 } 1535 leaf mobile-phone { 1536 type boolean; 1537 description 1538 "If type of a device is mobile-phone."; 1539 } 1541 leaf voip-volte-phone { 1542 type boolean; 1543 description 1544 "If type of a device is voip-volte-phone."; 1545 } 1547 leaf tablet { 1548 type boolean; 1549 description 1550 "If type of a device is tablet."; 1551 } 1553 leaf iot { 1554 type boolean; 1555 description 1556 "If type of a device is Internet of Things."; 1557 } 1559 leaf vehicle { 1560 type boolean; 1561 description 1562 "If type of a device is vehicle."; 1563 } 1564 } 1565 } 1566 container users-condition { 1567 description 1568 "TBD"; 1569 leaf users-description { 1570 type string; 1571 description 1572 "This is description for user condition. 1573 Vendors can write instructions for user condition 1574 that vendor made"; 1575 } 1576 container user{ 1577 description 1578 "The user (or user group) information with which 1579 network flow is associated: The user has many 1580 attributes such as name, id, password, type, 1581 authentication mode and so on. Name/id is often 1582 used in the security policy to identify the user. 1583 Besides, NSF is aware of the IP address of the 1584 user provided by a unified user management system 1585 via network. Based on name-address association, 1586 NSF is able to enforce the security functions 1587 over the given user (or user group)"; 1589 choice user-name { 1590 description 1591 "The name of the user. 1592 This must be unique."; 1594 case tenant { 1595 description 1596 "Tenant information."; 1598 leaf tenant { 1599 type uint8; 1600 mandatory true; 1601 description 1602 "User's tenant information."; 1603 } 1604 } 1606 case vn-id { 1607 description 1608 "VN-ID information."; 1610 leaf vn-id { 1611 type uint8; 1612 mandatory true; 1613 description 1614 "User's VN-ID information."; 1615 } 1616 } 1617 } 1618 } 1619 container group { 1620 description 1621 "The user (or user group) information with which 1622 network flow is associated: The user has many 1623 attributes such as name, id, password, type, 1624 authentication mode and so on. Name/id is often 1625 used in the security policy to identify the user. 1626 Besides, NSF is aware of the IP address of the 1627 user provided by a unified user management system 1628 via network. Based on name-address association, 1629 NSF is able to enforce the security functions 1630 over the given user (or user group)"; 1632 choice group-name { 1633 description 1634 "The name of the user. 1635 This must be unique."; 1637 case tenant { 1638 description 1639 "Tenant information."; 1641 leaf tenant { 1642 type uint8; 1643 mandatory true; 1644 description 1645 "User's tenant information."; 1646 } 1647 } 1649 case vn-id { 1650 description 1651 "VN-ID information."; 1653 leaf vn-id { 1654 type uint8; 1655 mandatory true; 1656 description 1657 "User's VN-ID information."; 1658 } 1659 } 1660 } 1661 } 1662 leaf security-grup { 1663 type string; 1664 mandatory true; 1665 description 1666 "security-grup."; 1667 } 1668 } 1670 container url-category-condition { 1671 description 1672 "TBD"; 1673 leaf url-category-description { 1674 type string; 1675 description 1676 "This is description for url category condition. 1677 Vendors can write instructions for context condition 1678 that vendor made"; 1679 } 1681 leaf-list pre-defined-category { 1682 type string; 1683 description 1684 "This is pre-defined-category."; 1685 } 1686 leaf-list user-defined-category { 1687 type string; 1688 description 1689 "This user-defined-category."; 1690 } 1691 } 1693 container context-condition { 1694 description 1695 "TBD"; 1696 leaf context-description { 1697 type string; 1698 description 1699 "This is description for context condition. 1700 Vendors can write instructions for context condition 1701 that vendor made"; 1702 } 1703 } 1705 container gen-context-condition { 1706 description 1707 "TBD"; 1708 leaf gen-context-description { 1709 type string; 1710 description 1711 "This is description for generic context condition. 1712 Vendors can write instructions for generic context 1713 condition that vendor made"; 1714 } 1716 container geographic-location { 1717 description 1718 "The location where network traffic is associated 1719 with. The region can be the geographic location 1720 such as country, province, and city, 1721 as well as the logical network location such as 1722 IP address, network section, and network domain."; 1724 leaf-list src-geographic-location { 1725 type uint32; 1726 description 1727 "This is mapped to ip address. We can acquire 1728 source region through ip address stored the 1729 database."; 1730 } 1731 leaf-list dest-geographic-location { 1732 type uint32; 1733 description 1734 "This is mapped to ip address. We can acquire 1735 destination region through ip address stored 1736 the database."; 1737 } 1738 } 1739 } 1740 } 1741 } 1742 container action-clause-container { 1743 description "TBD"; 1744 list action-clause-list { 1745 key eca-object-id; 1746 uses i2nsf-eca-object-type { 1747 refine entity-class { 1748 default ECA-ACTION-TYPE; 1749 } 1750 } 1751 description 1752 "An action is used to control and monitor aspects of 1753 flow-based NSFs when the event and condition clauses 1754 are satisfied. NSFs provide security functions by 1755 executing various Actions. Examples of I2NSF Actions 1756 include providing intrusion detection and/or protection, 1757 web and flow filtering, and deep packet inspection 1758 for packets and flows."; 1760 leaf rule-log { 1761 type boolean; 1762 description 1763 "True is enable 1764 False is not enable."; 1765 } 1766 leaf session-log { 1767 type boolean; 1768 description 1769 "True is enable 1770 False is not enable."; 1771 } 1772 container ingress-action { 1773 description 1774 "TBD"; 1775 leaf ingress-description { 1776 type string; 1777 description 1778 "This is description for ingress action. 1779 Vendors can write instructions for ingress action 1780 that vendor made"; 1781 } 1782 leaf ingress-action-type { 1783 type ingress-action; 1784 description 1785 "Ingress action type: permit, deny, and mirror."; 1786 } 1787 } 1788 container egress-action { 1789 description 1790 "TBD"; 1791 leaf egress-description { 1792 type string; 1793 description 1794 "This is description for egress action. 1795 Vendors can write instructions for egress action 1796 that vendor made"; 1797 } 1798 leaf egress-action-type { 1799 type egress-action; 1800 description 1801 "Egress-action-type: invoke-signaling, 1802 tunnel-encapsulation, and forwarding."; 1803 } 1804 } 1806 container apply-profile { 1807 description 1808 "TBD"; 1809 leaf profile-description { 1810 type string; 1811 description 1812 "This is description for apply profile action. 1813 Vendors can write instructions for apply 1814 profile action that vendor made"; 1815 } 1816 container content-security-control { 1817 description 1818 "Content security control is another category of 1819 security capabilities applied to application layer. 1820 Through detecting the contents carried over the 1821 traffic in application layer, these capabilities 1822 can realize various security purposes, such as 1823 defending against intrusion, inspecting virus, 1824 filtering malicious URL or junk email, and blocking 1825 illegal web access or data retrieval."; 1827 container content-security-control-types { 1828 description 1829 "Content Security types: Antivirus, IPS, IDS, 1830 url-filtering, data-filtering, mail-filtering, 1831 file-blocking, file-isolate, pkt-capture, 1832 application-control, and voip-volte."; 1834 leaf antivirus { 1835 type string; 1836 description 1837 "Additional inspection of antivirus."; 1838 } 1840 leaf ips { 1841 type string; 1842 description 1843 "Additional inspection of IPS."; 1844 } 1846 leaf ids { 1847 type string; 1848 description 1849 "Additional inspection of IDS."; 1850 } 1852 leaf url-filtering { 1853 type string; 1854 description 1855 "Additional inspection of URL filtering."; 1856 } 1858 leaf data-filtering { 1859 type string; 1860 description 1861 "Additional inspection of data filtering."; 1862 } 1863 leaf mail-filtering { 1864 type string; 1865 description 1866 "Additional inspection of mail filtering."; 1867 } 1869 leaf file-blocking { 1870 type string; 1871 description 1872 "Additional inspection of file blocking."; 1873 } 1875 leaf file-isolate { 1876 type string; 1877 description 1878 "Additional inspection of file isolate."; 1879 } 1881 leaf pkt-capture { 1882 type string; 1883 description 1884 "Additional inspection of packet capture."; 1885 } 1887 leaf application-control { 1888 type string; 1889 description 1890 "Additional inspection of app control."; 1891 } 1893 leaf voip-volte { 1894 type string; 1895 description 1896 "Additional inspection of VoIP/VoLTE."; 1897 } 1898 } 1899 } 1901 container attack-mitigation-control { 1902 description 1903 "This category of security capabilities is 1904 specially used to detect and mitigate various 1905 types of network attacks."; 1907 container ddos-attack { 1908 description 1909 "A distributed-denial-of-service (DDoS) is 1910 where the attack source is more than one, 1911 often thousands of unique IP addresses."; 1913 container ddos-attack-type { 1914 description 1915 "DDoS-attack types: Network Layer 1916 DDoS Attacks and Application Layer 1917 DDoS Attacks."; 1919 container network-layer-ddos-attack { 1920 description 1921 "Network layer DDoS-attack."; 1922 container network-layer-ddos-attack-type { 1923 description 1924 "Network layer DDoS attack types: 1925 Syn Flood Attack, UDP Flood Attack, 1926 ICMP Flood Attack, IP Fragment Flood, 1927 IPv6 Related Attacks, and etc"; 1929 leaf syn-flood { 1930 type string; 1931 description 1932 "Additional Inspection of 1933 Syn Flood Attack."; 1934 } 1936 leaf udp-flood { 1937 type string; 1938 description 1939 "Additional Inspection of 1940 UDP Flood Attack."; 1941 } 1943 leaf icmp-flood { 1944 type string; 1945 description 1946 "Additional Inspection of 1947 ICMP Flood Attack."; 1948 } 1950 leaf ip-frag-flood { 1951 type string; 1952 description 1953 "Additional Inspection of 1954 IP Fragment Flood."; 1955 } 1957 leaf ipv6-related { 1958 type string; 1959 description 1960 "Additional Inspection of 1961 IPv6 Related Attacks."; 1962 } 1963 } 1964 } 1966 container app-layer-ddos-attack { 1967 description 1968 "Application layer DDoS-attack."; 1970 container app-ddos-attack-types { 1971 description 1972 "Application layer DDoS-attack types: 1973 Http Flood Attack, Https Flood Attack, 1974 DNS Flood Attack, and 1975 DNS Amplification Flood Attack, 1976 SSL DDoS Attack, and etc."; 1978 leaf http-flood { 1979 type string; 1980 description 1981 "Additional Inspection of 1982 Http Flood Attack."; 1983 } 1985 leaf https-flood { 1986 type string; 1987 description 1988 "Additional Inspection of 1989 Https Flood Attack."; 1990 } 1992 leaf dns-flood { 1993 type string; 1994 description 1995 "Additional Inspection of 1996 DNS Flood Attack."; 1997 } 1999 leaf dns-amp-flood { 2000 type string; 2001 description 2002 "Additional Inspection of 2003 DNS Amplification Flood Attack."; 2004 } 2006 leaf ssl-ddos { 2007 type string; 2008 description 2009 "Additional Inspection of 2010 SSL Flood Attack."; 2011 } 2012 } 2013 } 2014 } 2015 } 2017 container single-packet-attack { 2018 description 2019 "Single Packet Attacks."; 2020 container single-packet-attack-type { 2021 description 2022 "DDoS-attack types: Scanning Attack, 2023 Sniffing Attack, Malformed Packet Attack, 2024 Special Packet Attack, and etc."; 2026 container scan-and-sniff-attack { 2027 description 2028 "Scanning and Sniffing Attack."; 2029 container scan-and-sniff-attack-types { 2030 description 2031 "Scanning and sniffing attack types: 2032 IP Sweep attack, Port Scanning, 2033 and etc."; 2035 leaf ip-sweep { 2036 type string; 2037 description 2038 "Additional Inspection of 2039 IP Sweep Attack."; 2040 } 2042 leaf port-scanning { 2043 type string; 2044 description 2045 "Additional Inspection of 2046 Port Scanning Attack."; 2047 } 2048 } 2049 } 2051 container malformed-packet-attack { 2052 description 2053 "Malformed Packet Attack."; 2054 container malformed-packet-attack-types { 2055 description 2056 "Malformed packet attack types: 2057 Ping of Death Attack, Teardrop Attack, 2058 and etc."; 2060 leaf ping-of-death { 2061 type string; 2062 description 2063 "Additional Inspection of 2064 Ping of Death Attack."; 2065 } 2067 leaf teardrop { 2068 type string; 2069 description 2070 "Additional Inspection of 2071 Teardrop Attack."; 2072 } 2073 } 2074 } 2076 container special-packet-attack { 2077 description 2078 "special Packet Attack."; 2079 container special-packet-attack-types { 2080 description 2081 "Special packet attack types: 2082 Oversized ICMP Attack, Tracert Attack, 2083 and etc."; 2085 leaf oversized-icmp { 2086 type string; 2087 description 2088 "Additional Inspection of 2089 Oversize ICMP Attack."; 2090 } 2092 leaf tracert { 2093 type string; 2094 description 2095 "Additional Inspection of 2096 Tracrt Attack."; 2097 } 2098 } 2099 } 2100 } 2101 } 2102 } 2104 } 2105 } 2106 } 2108 } 2109 container resolution-strategy { 2110 description 2111 "The resolution strategies can be used to 2112 specify how to resolve conflicts that occur between 2113 the actions of the same or different policy rules that 2114 are matched and contained in this particular NSF"; 2116 choice resolution-strategy-type { 2117 description 2118 "Vendors can use YANG data model to configure rules"; 2120 case fmr { 2121 leaf first-matching-rule { 2122 type boolean; 2123 description 2124 "If the resolution strategy is first matching rule"; 2125 } 2126 } 2127 case lmr { 2128 leaf last-matching-rule { 2129 type boolean; 2130 description 2131 "If the resolution strategy is last matching rule"; 2132 } 2133 } 2135 } 2136 } 2138 container default-action { 2139 description 2140 "This default action can be used to specify a predefined 2141 action when no other alternative action was matched 2142 by the currently executing I2NSF Policy Rule. An analogy 2143 is the use of a default statement in a C switch statement."; 2145 leaf default-action-type { 2146 type boolean; 2147 description 2148 "True is permit 2149 False is deny."; 2150 } 2152 } 2154 container rule-group { 2155 description 2156 "This is rule group"; 2158 list groups { 2159 key "group-name"; 2160 description 2161 "This is a group for rules"; 2163 leaf group-name { 2164 type string; 2165 description 2166 "This is a group for rules"; 2167 } 2169 container rule-range { 2170 description 2171 "This is a rule range."; 2173 leaf start-rule { 2174 type string; 2175 description 2176 "This is a start rule"; 2177 } 2178 leaf end-rule { 2179 type string; 2180 description 2181 "This is a end rule"; 2182 } 2183 } 2184 leaf enable { 2185 type boolean; 2186 description 2187 "This is enable 2188 False is not enable."; 2189 } 2190 leaf description { 2191 type string; 2192 description 2193 "This is a desription for rule-group"; 2194 } 2195 } 2196 } 2197 } 2198 } 2199 } 2201 2203 Figure 5: YANG Data Module of I2NSF NSF-Facing-Interface 2205 7. Security Considerations 2207 This document introduces no additional security threats and SHOULD 2208 follow the security requirements as stated in [RFC8329]. 2210 8. References 2212 8.1. Normative References 2214 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2215 Requirement Levels", BCP 14, RFC 2119, March 1997. 2217 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 2218 Network Configuration Protocol (NETCONF)", RFC 6020, 2219 October 2010. 2221 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2222 Kumar, "Framework for Interface to Network Security 2223 Functions", RFC 8329, February 2018. 2225 [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 2226 S., and N. Bahadur, "A YANG Data Model for Routing 2227 Information Base (RIB)", RFC RFC8431, September 2018. 2229 8.2. Informative References 2231 [i2nsf-advanced-nsf-dm] 2232 Pan, W. and L. Xia, "Configuration of Advanced Security 2233 Functions with I2NSF Security Controller", draft-dong- 2234 i2nsf-asf-config-01 (work in progress), October 2018. 2236 [i2nsf-nsf-cap-im] 2237 Xia, L., Strassner, J., Basile, C., and D. Lopez, 2238 "Information Model of NSFs Capabilities", draft-ietf- 2239 i2nsf-capability-04 (work in progress), October 2018. 2241 [supa-policy-info-model] 2242 Strassner, J., Halpern, J., and S. Meer, "Generic Policy 2243 Information Model for Simplified Use of Policy 2244 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 2245 model-03 (work in progress), May 2017. 2247 Appendix A. Changes from draft-ietf-i2nsf-nsf-facing-interface-dm-01 2249 The following changes are made from draft-ietf-i2nsf-nsf-facing- 2250 interface-dm-01: 2252 o We added system policy which represents there could be multiple 2253 system policies in one NSF, and each system policy is used by one 2254 virtual instance of the NSF/device. This is a very general 2255 feature for all the NSFs/devices. 2257 o We changed policy name to system policy name for system policy. 2259 o We deleted policy-event-clause-agg-ptr, policy-condition-clause- 2260 agg-ptr, and policy-action-clause-agg-ptr. 2262 o We added priority-usage which represents priority of policies by 2263 order or number. 2265 Appendix B. Acknowledgments 2267 This work was supported by Institute for Information & communications 2268 Technology Promotion (IITP) grant funded by the Korea government 2269 (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence 2270 Technology Development for the Customized Security Service 2271 Provisioning). 2273 Appendix C. Contributors 2275 This document is made by the group effort of I2NSF working group. 2276 Many people actively contributed to this document. The following are 2277 considered co-authors: 2279 o Hyoungshick Kim (Sungkyunkwan University) 2281 o Daeyoung Hyun (Sungkyunkwan University) 2283 o Dongjin Hong (Sungkyunkwan University) 2285 o Liang Xia (Huawei) 2287 o Tae-Jin Ahn (Korea Telecom) 2289 o Se-Hui Lee (Korea Telecom) 2291 Authors' Addresses 2293 Jinyong Tim Kim 2294 Department of Computer Engineering 2295 Sungkyunkwan University 2296 2066 Seobu-Ro, Jangan-Gu 2297 Suwon, Gyeonggi-Do 16419 2298 Republic of Korea 2300 Phone: +82 10 8273 0930 2301 EMail: timkim@skku.edu 2303 Jaehoon Paul Jeong 2304 Department of Software 2305 Sungkyunkwan University 2306 2066 Seobu-Ro, Jangan-Gu 2307 Suwon, Gyeonggi-Do 16419 2308 Republic of Korea 2310 Phone: +82 31 299 4957 2311 Fax: +82 31 290 7996 2312 EMail: pauljeong@skku.edu 2313 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 2315 Jung-Soo Park 2316 Electronics and Telecommunications Research Institute 2317 218 Gajeong-Ro, Yuseong-Gu 2318 Daejeon 34129 2319 Republic of Korea 2321 Phone: +82 42 860 6514 2322 EMail: pjs@etri.re.kr 2324 Susan Hares 2325 Huawei 2326 7453 Hickory Hill 2327 Saline, MI 48176 2328 USA 2330 Phone: +1-734-604-0332 2331 EMail: shares@ndzh.com 2332 Qiushi Lin 2333 Huawei 2334 Huawei Industrial Base 2335 Shenzhen, Guangdong 518129 2336 China 2338 EMail: linqiushi@huawei.com