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