idnits 2.17.1 draft-ietf-i2nsf-nsf-facing-interface-dm-17.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 324 has weird spacing: '...er-port ine...' == Line 325 has weird spacing: '...er-port ine...' == Line 331 has weird spacing: '...w start ine...' == Line 338 has weird spacing: '...er-port ine...' == Line 339 has weird spacing: '...er-port ine...' == (20 more instances...) -- The document date (22 January 2022) is 823 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) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-rfc793bis-25 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-tcpm-rfc793bis' == Outdated reference: A later version (-32) exists of draft-ietf-i2nsf-capability-data-model-22 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-12 == Outdated reference: A later version (-31) exists of draft-ietf-i2nsf-consumer-facing-interface-dm-15 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group J. Kim, Ed. 3 Internet-Draft J. Jeong, Ed. 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: 26 July 2022 J. Park 6 ETRI 7 S. Hares 8 Q. Lin 9 Huawei 10 22 January 2022 12 I2NSF Network Security Function-Facing Interface YANG Data Model 13 draft-ietf-i2nsf-nsf-facing-interface-dm-17 15 Abstract 17 This document defines a YANG data model for configuring security 18 policy rules on Network Security Functions (NSF) in the Interface to 19 Network Security Functions (I2NSF) framework. The YANG data model in 20 this document corresponds to the information model for NSF-Facing 21 Interface in the I2NSF framework. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 26 July 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. General I2NSF Security Policy Rule . . . . . . . . . . . 3 60 3.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 12 63 4. YANG Data Model of NSF-Facing Interface . . . . . . . . . . . 14 64 4.1. YANG Module of NSF-Facing Interface . . . . . . . . . . . 14 65 5. XML Configuration Examples of Low-Level Security Policy 66 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 57 67 5.1. Example Security Requirement 1: Block Social Networking 68 Service (SNS) Access during Business Hours . . . . . . . 57 69 5.2. Example Security Requirement 2: Block Malicious VoIP/VoLTE 70 Packets Coming to a Company . . . . . . . . . . . . . . . 61 71 5.3. Example Security Requirement 3: Mitigate HTTP and HTTPS 72 Flood Attacks on a Company Web Server . . . . . . . . . . 63 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 66 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 67 76 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 67 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 68 79 10.2. Informative References . . . . . . . . . . . . . . . . . 72 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 82 1. Introduction 84 This document defines a YANG [RFC6020][RFC7950] data model for 85 security policy rule configuration of Network Security Functions 86 (NSF). The YANG data model in this document is based on the 87 information and data model in [I-D.ietf-i2nsf-capability-data-model] 88 for the NSF-Facing Interface in the Interface to Network Security 89 Functions (I2NSF) architecture [RFC8329]. The YANG data model in 90 this document focuses on security policy configuration for the NSFs 91 discussed in [I-D.ietf-i2nsf-capability-data-model], i.e., generic 92 NSF (operate on packet header for layer 2, layer3, and layer 4) and 93 advanced NSF (Intrusion Prevention System, URL-Filtering, anti-DDoS, 94 Antivirus, and VoIP/VoLTE Filter). 96 This YANG data model uses an "Event-Condition-Action" (ECA) policy 97 model that is used as the basis for the design of I2NSF Policy 98 described in [RFC8329] and [I-D.ietf-i2nsf-capability-data-model]. 100 The "ietf-i2nsf-policy-rule-for-nsf" YANG module defined in this 101 document provides the configuration of the following features. 103 * A security policy rule of a network security function. 105 * An event clause of a generic network security function. 107 * A condition clause of a generic network security function. 109 * An action clause of a generic network security function. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 This document uses the terminology described in [RFC8329]. 121 This document follows the guidelines of [RFC8407], uses the common 122 YANG types defined in [RFC6991], and adopts the Network Management 123 Datastore Architecture (NMDA). The meaning of the symbols in tree 124 diagrams is defined in [RFC8340]. 126 3. YANG Tree Diagram 128 This section shows a YANG tree diagram of policy for network security 129 functions. [I-D.ietf-i2nsf-capability-data-model]. 131 3.1. General I2NSF Security Policy Rule 133 This section shows a YANG tree diagram for a general I2NSF security 134 policy rule for generic network security functions. 136 module: ietf-i2nsf-policy-rule-for-nsf 137 +--rw i2nsf-security-policy* [name] 138 +--rw name string 139 +--rw priority-usage? identityref 140 +--rw resolution-strategy? identityref 141 +--rw default-action? identityref 142 +--rw rules* [name] 143 | +--rw name string 144 | +--rw description? string 145 | +--rw priority? uint8 146 | +--rw enable? boolean 147 | +--rw session-aging-time? uint16 148 | +--rw long-connection 149 | | +--rw enable? boolean 150 | | +--rw duration? uint16 151 | +--rw event 152 | | ... 153 | +--rw condition 154 | | ... 155 | +--rw action 156 | ... 157 +--rw rule-group 158 +--rw groups* [name] 159 +--rw name string 160 +--rw rule-name* -> ../../../rules/name 161 +--rw enable? boolean 162 +--rw description? string 164 Figure 1: YANG Tree Diagram for Network Security Policy 166 A security policy is used by one virtual instance of an NSF/device as 167 a set of security rules to protect assets from major risk factors 168 that threaten the system. There can be multiple security policies in 169 a single NSF to provide the necessary protection. The security 170 policy includes its name, priority usage, resolution strategy, 171 default action, and rules. 173 A resolution strategy is used to decide how to resolve conflicts that 174 occur between the actions of the same or different policy rules that 175 are matched and contained in a particular NSF. The resolution 176 strategy is defined as First Matching Rule (FMR), Last Matching Rule 177 (LMR), Prioritized Matching Rule (PMR) with Errors (PMRE), and 178 Prioritized Matching Rule with No Errors (PMRN). The resolution 179 strategy can be extended according to specific vendor action 180 features. The resolution strategy is described in detail in 181 [I-D.ietf-i2nsf-capability-data-model]. 183 A default action is used to execute I2NSF policy rule when no rule 184 matches a packet. The default action is defined as pass, drop, rate- 185 limit, and mirror. The default action can be extended according to 186 specific vendor action features. The default action is described in 187 detail in [I-D.ietf-i2nsf-capability-data-model]. 189 The rules include rule name, rule description, rule priority, rule 190 enable, event, condition, and action. 192 3.2. Event Clause 194 This section shows a YANG tree diagram for an event clause for a 195 general I2NSF security policy rule for generic network security 196 functions. 198 module: ietf-i2nsf-policy-rule-for-nsf 199 +--rw i2nsf-security-policy* [name] 200 ... 201 +--rw rules* [name] 202 | ... 203 | +--rw event 204 | | +--rw description? string 205 | | +--rw time 206 | | | +--rw start-date-time? yang:date-and-time 207 | | | +--rw end-date-time? yang:date-and-time 208 | | | +--rw period 209 | | | | +--rw start-time? time 210 | | | | +--rw end-time? time 211 | | | | +--rw day* day 212 | | | | +--rw date* int8 213 | | | | +--rw month* string 214 | | | +--rw frequency? enumeration 215 | | +--rw event-clauses 216 | | +--rw system-event* identityref 217 | | +--rw system-alarm* identityref 218 | +--rw condition 219 | ... 220 | +--rw action 221 | ... 222 +--rw rule-group 223 ... 225 module: ietf-i2nsf-policy-rule-for-nsf 226 +--rw i2nsf-security-policy* [name] 227 ... 228 +--rw rules* [name] 229 | ... 230 | +--rw event 231 | | +--rw description? string 232 | | +--rw time 233 | | | +--rw start-date-time? yang:date-and-time 234 | | | +--rw end-date-time? yang:date-and-time 235 | | | +--rw period 236 | | | | +--rw start-time? time 237 | | | | +--rw end-time? time 238 | | | | +--rw day* day 239 | | | | +--rw date* int8 240 | | | | +--rw month* string 241 | | | +--rw frequency? enumeration 242 | | +--rw event-clauses 243 | | +--rw system-event* identityref 244 | | +--rw system-alarm* identityref 245 | +--rw condition 246 | | ... 247 | +--rw action 248 | ... 249 +--rw rule-group 250 ... 252 Figure 2: YANG Tree Diagram for an Event Clause 254 An event clause is any important occurrence at a specific time of a 255 change in the system being managed, and/or in the environment of the 256 system being managed. An event clause is used to trigger the 257 evaluation of the condition clause of the I2NSF Policy Rule. The 258 event clause is defined as a system event, system alarm 259 [I-D.ietf-i2nsf-nsf-monitoring-data-model] and time. The event 260 clause can be extended according to specific vendor event features. 261 The event clause is described in detail in 262 [I-D.ietf-i2nsf-capability-data-model]. 264 3.3. Condition Clause 266 This section shows a YANG tree diagram for a condition clause for a 267 general I2NSF security policy rule for generic network security 268 functions. 270 module: ietf-i2nsf-policy-rule-for-nsf 271 +--rw i2nsf-security-policy* [name] 272 ... 273 +--rw rules* [name] 274 | ... 275 | +--rw event 276 | ... 277 | +--rw condition 278 | | +--rw description? string 279 | | +--rw ethernet 280 | | | +--rw description? string 281 | | | +--rw destination-mac-address? yang:mac-address 282 | | | +--rw destination-mac-address-mask? yang:mac-address 283 | | | +--rw source-mac-address? yang:mac-address 284 | | | +--rw source-mac-address-mask? yang:mac-address 285 | | | +--rw ethertype? eth:ethertype 286 | | +--rw ipv4 287 | | | +--rw description? string 288 | | | +--rw dscp? inet:dscp 289 | | | +--rw ecn? uint8 290 | | | +--rw length? uint16 291 | | | +--rw ttl? uint8 292 | | | +--rw protocol? uint8 293 | | | +--rw ihl? uint8 294 | | | +--rw flags? bits 295 | | | +--rw offset? uint16 296 | | | +--rw identification? uint16 297 | | | +--rw (destination-network)? 298 | | | | +--:(destination-ipv4-network) 299 | | | | +--rw destination-ipv4-network? inet:ipv4-prefix 300 | | | +--rw (source-network)? 301 | | | +--:(source-ipv4-network) 302 | | | +--rw source-ipv4-network? inet:ipv4-prefix 303 | | +--rw ipv6 304 | | | +--rw description? string 305 | | | +--rw dscp? inet:dscp 306 | | | +--rw ecn? uint8 307 | | | +--rw length? uint16 308 | | | +--rw ttl? uint8 309 | | | +--rw protocol? uint8 310 | | | +--rw (destination-network)? 311 | | | | +--:(destination-ipv6-network) 312 | | | | +--rw destination-ipv6-network? inet:ipv6-prefix 313 | | | +--rw (source-network)? 314 | | | | +--:(source-ipv6-network) 315 | | | | +--rw source-ipv6-network? inet:ipv6-prefix 316 | | | +--rw flow-label? inet:ipv6-flow-label 317 | | +--rw tcp 318 | | | +--rw description? string 319 | | | +--rw source-port-number 320 | | | | +--rw (source-port)? 321 | | | | +--:(range-or-operator) 322 | | | | | +--rw (port-range-or-operator)? 323 | | | | | +--:(range) 324 | | | | | | +--rw lower-port inet:port-number 325 | | | | | | +--rw upper-port inet:port-number 326 | | | | | +--:(operator) 327 | | | | | +--rw operator? operator 328 | | | | | +--rw port inet:port-number 329 | | | | +--:(port-list) 330 | | | | +--rw port-numbers* [start] 331 | | | | +--rw start inet:port-number 332 | | | | +--rw end? inet:port-number 333 | | | +--rw destination-port-number 334 | | | | +--rw (destination-port)? 335 | | | | +--:(range-or-operator) 336 | | | | | +--rw (port-range-or-operator)? 337 | | | | | +--:(range) 338 | | | | | | +--rw lower-port inet:port-number 339 | | | | | | +--rw upper-port inet:port-number 340 | | | | | +--:(operator) 341 | | | | | +--rw operator? operator 342 | | | | | +--rw port inet:port-number 343 | | | | +--:(port-list) 344 | | | | +--rw port-numbers* [start] 345 | | | | +--rw start inet:port-number 346 | | | | +--rw end? inet:port-number 347 | | | +--rw sequence-number? uint32 348 | | | +--rw acknowledgement-number? uint32 349 | | | +--rw data-offset? uint8 350 | | | +--rw reserved? uint8 351 | | | +--rw flags? bits 352 | | | +--rw window-size? uint16 353 | | | +--rw urgent-pointer? uint16 354 | | | +--rw options? binary 355 | | +--rw udp 356 | | | +--rw description? string 357 | | | +--rw source-port-number 358 | | | | +--rw (source-port)? 359 | | | | +--:(range-or-operator) 360 | | | | | +--rw (port-range-or-operator)? 361 | | | | | +--:(range) 362 | | | | | | +--rw lower-port inet:port-number 363 | | | | | | +--rw upper-port inet:port-number 364 | | | | | +--:(operator) 365 | | | | | +--rw operator? operator 366 | | | | | +--rw port inet:port-number 367 | | | | +--:(port-list) 368 | | | | +--rw port-numbers* [start] 369 | | | | +--rw start inet:port-number 370 | | | | +--rw end? inet:port-number 371 | | | +--rw destination-port-number 372 | | | | +--rw (destination-port)? 373 | | | | +--:(range-or-operator) 374 | | | | | +--rw (port-range-or-operator)? 375 | | | | | +--:(range) 376 | | | | | | +--rw lower-port inet:port-number 377 | | | | | | +--rw upper-port inet:port-number 378 | | | | | +--:(operator) 379 | | | | | +--rw operator? operator 380 | | | | | +--rw port inet:port-number 381 | | | | +--:(port-list) 382 | | | | +--rw port-numbers* [start] 383 | | | | +--rw start inet:port-number 384 | | | | +--rw end? inet:port-number 385 | | | +--rw length? uint16 386 | | +--rw sctp 387 | | | +--rw description? string 388 | | | +--rw source-port-number 389 | | | | +--rw (source-port)? 390 | | | | +--:(range-or-operator) 391 | | | | | +--rw (port-range-or-operator)? 392 | | | | | +--:(range) 393 | | | | | | +--rw lower-port inet:port-number 394 | | | | | | +--rw upper-port inet:port-number 395 | | | | | +--:(operator) 396 | | | | | +--rw operator? operator 397 | | | | | +--rw port inet:port-number 398 | | | | +--:(port-list) 399 | | | | +--rw port-numbers* [start] 400 | | | | +--rw start inet:port-number 401 | | | | +--rw end? inet:port-number 402 | | | +--rw destination-port-number 403 | | | | +--rw (destination-port)? 404 | | | | +--:(range-or-operator) 405 | | | | | +--rw (port-range-or-operator)? 406 | | | | | +--:(range) 407 | | | | | | +--rw lower-port inet:port-number 408 | | | | | | +--rw upper-port inet:port-number 409 | | | | | +--:(operator) 410 | | | | | +--rw operator? operator 411 | | | | | +--rw port inet:port-number 412 | | | | +--:(port-list) 413 | | | | +--rw port-numbers* [start] 414 | | | | +--rw start inet:port-number 415 | | | | +--rw end? inet:port-number 416 | | | +--rw chunk-type* uint8 417 | | +--rw dccp 418 | | | +--rw description? string 419 | | | +--rw source-port-number 420 | | | | +--rw (source-port)? 421 | | | | +--:(range-or-operator) 422 | | | | | +--rw (port-range-or-operator)? 423 | | | | | +--:(range) 424 | | | | | | +--rw lower-port inet:port-number 425 | | | | | | +--rw upper-port inet:port-number 426 | | | | | +--:(operator) 427 | | | | | +--rw operator? operator 428 | | | | | +--rw port inet:port-number 429 | | | | +--:(port-list) 430 | | | | +--rw port-numbers* [start] 431 | | | | +--rw start inet:port-number 432 | | | | +--rw end? inet:port-number 433 | | | +--rw destination-port-number 434 | | | | +--rw (destination-port)? 435 | | | | +--:(range-or-operator) 436 | | | | | +--rw (port-range-or-operator)? 437 | | | | | +--:(range) 438 | | | | | | +--rw lower-port inet:port-number 439 | | | | | | +--rw upper-port inet:port-number 440 | | | | | +--:(operator) 441 | | | | | +--rw operator? operator 442 | | | | | +--rw port inet:port-number 443 | | | | +--:(port-list) 444 | | | | +--rw port-numbers* [start] 445 | | | | +--rw start inet:port-number 446 | | | | +--rw end? inet:port-number 447 | | | +--rw service-code* uint32 448 | | | +--rw type* uint8 449 | | +--rw icmp* [version] 450 | | | +--rw description? string 451 | | | +--rw version enumeration 452 | | | +--rw type? uint8 453 | | | +--rw code? uint8 454 | | | +--rw rest-of-header? binary 455 | | +--rw url-category 456 | | | +--rw description? string 457 | | | +--rw pre-defined* string 458 | | | +--rw user-defined* string 459 | | +--rw voice 460 | | | +--rw description? string 461 | | | +--rw source-voice-id* string 462 | | | +--rw destination-voice-id* string 463 | | | +--rw user-agent* string 464 | | +--rw ddos 465 | | | +--rw description? string 466 | | | +--rw alert-packet-rate? uint32 467 | | | +--rw alert-flow-rate? uint32 468 | | | +--rw alert-byte-rate? uint32 469 | | +--rw anti-virus 470 | | | +--rw profile* string 471 | | | +--rw exception-files* string 472 | | +--rw payload 473 | | | +--rw description? string 474 | | | +--rw content* string 475 | | +--rw context 476 | | +--rw description? string 477 | | +--rw application 478 | | | +--rw description? string 479 | | | +--rw object* string 480 | | | +--rw group* string 481 | | | +--rw label* string 482 | | | +--rw category 483 | | | +--rw application-category* [name subcategory] 484 | | | +--rw name string 485 | | | +--rw subcategory string 486 | | +--rw device-type 487 | | | +--rw description? string 488 | | | +--rw device* identityref 489 | | +--rw users 490 | | | +--rw description? string 491 | | | +--rw user* [id] 492 | | | | +--rw id uint32 493 | | | | +--rw name? string 494 | | | +--rw group* [id] 495 | | | | +--rw id uint32 496 | | | | +--rw name? string 497 | | | +--rw security-group? string 498 | | +--rw geographic-location 499 | | +--rw description? string 500 | | +--rw source* string 501 | | +--rw destination* string 502 | +--rw action 503 | ... 504 +--rw rule-group 505 ... 507 Figure 3: YANG Tree Diagram for a Condition Clause 509 A condition clause is defined as a set of attributes, features, and/ 510 or values that are to be compared with a set of known attributes, 511 features, and/or values in order to determine whether or not the set 512 of actions in that (imperative) I2NSF policy rule can be executed or 513 not. A condition clause is classified as a condition of generic 514 network security functions, advanced network security functions, or 515 context. A condition clause of generic network security functions is 516 defined as IPv4 condition, IPv6 condition, TCP condition, UDP 517 condition, SCTP condition, DCCP condition, and ICMP (ICMPv4 and 518 ICMPv6) condition. 520 Note that the data model in this document does not focus on only IP 521 addresses, but focuses on all the fields of IPv4 and IPv6 headers. 522 The IPv4 and IPv6 headers have similarity with some different fields. 523 In this case, it is better to handle separately the IPv4 and IPv6 524 headers such that the different fields can be used to handle IPv4 and 525 IPv6 packets. 527 A condition clause of advanced network security functions is defined 528 as url category condition, voice condition, DDoS condition, or 529 payload condition. A condition clause of context is defined as 530 application condition, target condition, users condition, and 531 geography condition. 533 Note that this document deals only with conditions of several 534 advanced network security functions such as url filter (i.e., web 535 filter), VoIP/VoLTE security, and DDoS-attack mitigator. A condition 536 clause of other advanced network security functions such as Intrusion 537 Prevention System (IPS) and Data Loss Prevention (DLP) can be defined 538 as an extension in future. A condition clause can be extended 539 according to specific vendor condition features. A condition clause 540 is described in detail in [I-D.ietf-i2nsf-capability-data-model]. 542 3.4. Action Clause 544 This section shows a YANG tree diagram for an action clause for a 545 general I2NSF security policy rule for generic network security 546 functions. 548 module: ietf-i2nsf-policy-rule-for-nsf 549 +--rw i2nsf-security-policy* [name] 550 ... 551 +--rw rules* [name] 552 | ... 553 | +--rw event 554 | ... 555 | +--rw condition 556 | ... 557 | +--rw action 558 | +--rw description? string 559 | +--rw packet-action 560 | | +--rw ingress-action? identityref 561 | | +--rw egress-action? identityref 562 | | +--rw log-action? identityref 563 | +--rw flow-action 564 | | +--rw ingress-action? identityref 565 | | +--rw egress-action? identityref 566 | | +--rw log-action? identityref 567 | +--rw advanced-action 568 | +--rw content-security-control* identityref 569 | +--rw attack-mitigation-control* identityref 570 +--rw rule-group 571 ... 573 Figure 4: YANG Tree Diagram for an Action Clause 575 An action is used to control and monitor aspects of flow-based NSFs 576 when the policy rule event and condition clauses are satisfied. NSFs 577 provide security services by executing various actions. The action 578 clause is defined as ingress action, egress action, or log action for 579 packet action, flow action, and advanced action for additional 580 inspection. The packet action is an action for an individual packet 581 such as an IP datagram as a stateless process that uses the packet's 582 header and payload. The flow action is an action of a traffic flow 583 such as the packets of a TCP session (e.g., an HTTP/HTTPS session) as 584 a stateful process that uses the traffic flow information such as 585 5-tuple information, packet counts, and byte counts. The advanced 586 action is an action for an advanced security service (e.g., url 587 filter, DDoS-attack mitigator, and VoIP/VoLTE filter) for either a 588 packet or a traffic flow according to the intention of such an 589 advanced security service. The action clause can be extended 590 according to specific vendor action features. The action clause is 591 described in detail in [I-D.ietf-i2nsf-capability-data-model]. 593 4. YANG Data Model of NSF-Facing Interface 595 The main objective of this data model is to provide both an 596 information model and the corresponding YANG data model of I2NSF NSF- 597 Facing Interface. This interface can be used to deliver control and 598 management messages between Security Controller and NSFs for the 599 I2NSF low-level security policies. 601 This data model is designed to support the I2NSF framework that can 602 be extended according to the security needs. In other words, the 603 model design is independent of the content and meaning of specific 604 policies as well as the implementation approach. 606 With the YANG data model of I2NSF NSF-Facing Interface, this document 607 suggests use cases for security policy rules such as time-based 608 firewall, web filter, VoIP/VoLTE security service, and DDoS-attack 609 mitigation in Section 5. 611 4.1. YANG Module of NSF-Facing Interface 613 This section describes a YANG module of NSF-Facing Interface. This 614 document provides identities in the data model for the configuration 615 of an NSF. The identity has the same concept with the corresponding 616 identity in [I-D.ietf-i2nsf-consumer-facing-interface-dm]. This YANG 617 module imports from [RFC6991] and [RFC8519]. It makes references to 618 [RFC0768] [RFC0791] [RFC0792] [RFC3261] [RFC4340] [RFC4443] [RFC4732] 619 [RFC4987] [RFC4960] [RFC5595] [RFC6335] [RFC8075] [RFC8200] [RFC8329] 620 [RFC8335] [IEEE-802.3] [ISO-3166] [I-D.ietf-tcpm-rfc793bis] 621 [I-D.ietf-i2nsf-capability-data-model] 622 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 623 [I-D.ietf-netmod-geo-location]. 625 file "ietf-i2nsf-policy-rule-for-nsf@2022-01-22.yang" 626 module ietf-i2nsf-policy-rule-for-nsf { 627 yang-version 1.1; 628 namespace 629 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"; 630 prefix 631 nsfintf; 633 import ietf-inet-types{ 634 prefix inet; 635 reference 636 "Section 4 of RFC 6991"; 637 } 638 import ietf-yang-types { 639 prefix yang; 640 reference 641 "Section 3 of RFC 6991"; 642 } 643 import ietf-packet-fields { 644 prefix packet-fields; 645 reference 646 "Section 4.2 of RFC 8519"; 647 } 649 organization 650 "IETF I2NSF (Interface to Network Security Functions) 651 Working Group"; 653 contact 654 "WG Web: 655 WG List: 657 Editor: Jinyong Tim Kim 658 660 Editor: Jaehoon Paul Jeong 661 "; 663 description 664 "This module is a YANG module for Network Security Functions 665 (NSF)-Facing Interface. 667 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 668 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 669 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 670 document are to be interpreted as described in BCP 14 671 (RFC 2119) (RFC 8174) when, and only when, they appear 672 in all capitals, as shown here. 674 Copyright (c) 2021 IETF Trust and the persons identified as 675 authors of the code. All rights reserved. 677 Redistribution and use in source and binary forms, with or 678 without modification, is permitted pursuant to, and subject to 679 the license terms contained in, the Simplified BSD License set 680 forth in Section 4.c of the IETF Trust's Legal Provisions 681 Relating to IETF Documents 682 (https://trustee.ietf.org/license-info). 684 This version of this YANG module is part of RFC XXXX 685 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 686 for full legal notices."; 688 revision "2022-01-22"{ 689 description "The latest revision."; 690 reference 691 "RFC XXXX: I2NSF Network Security Function-Facing Interface 692 YANG Data Model"; 693 } 695 /* 696 * Identities 697 */ 699 identity priority-usage { 700 description 701 "Base identity for priority usage type to define the type of 702 priority to be implemented in a security policy rule, such 703 as priority by order and priority by number."; 704 } 706 identity priority-by-order { 707 base priority-usage; 708 description 709 "Identity for priority by order. This indicates the 710 priority of a security policy rule follows the order of the 711 configuration. The earlier the configuration is, the higher 712 the priority is."; 713 } 715 identity priority-by-number { 716 base priority-usage; 717 description 718 "Identity for priority by number. This indicates the priority 719 of a security policy rule follows the number or value of the 720 configuration. The higher the value is, the higher the 721 priority is."; 722 } 724 identity event { 725 description 726 "Base identity for policy events."; 727 reference 728 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 729 Monitoring YANG Data Model - Event"; 730 } 732 identity system-event { 733 base event; 734 description 735 "Identity for system events. System event (called alert) is 736 defined as a warning about any changes of configuration, any 737 access violation, the information of sessions and traffic 738 flows."; 739 reference 740 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 741 Monitoring YANG Data Model - System event"; 742 } 744 identity system-alarm { 745 base event; 746 description 747 "Identity for system alarms. System alarm is defined as a 748 warning related to service degradation in system hardware."; 749 reference 750 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 751 Monitoring YANG Data Model - System alarm"; 752 } 754 identity access-violation { 755 base system-event; 756 description 757 "Identity for access-violation. Access-violation system 758 event is an event when a user tries to access (read, write, 759 create, or delete) any information or execute commands above 760 their privilege."; 761 reference 762 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 763 Monitoring YANG Data Model - System event for access 764 violation"; 765 } 767 identity configuration-change { 768 base system-event; 769 description 770 "Identity for configuration change. Configuration change is 771 a system event when a new configuration is added or an 772 existing configuration is modified."; 773 reference 774 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 775 Monitoring YANG Data Model - System event for configuration 776 change"; 777 } 779 identity memory-alarm { 780 base system-alarm; 781 description 782 "Identity for memory alarm. Memory is the hardware to store 783 information temporarily or for a short period, i.e., Random 784 Access Memory (RAM). A memory-alarm is emitted when the RAM 785 usage exceeds the threshold."; 786 reference 787 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 788 Monitoring YANG Data Model - System alarm for memory"; 789 } 791 identity cpu-alarm { 792 base system-alarm; 793 description 794 "Identity for CPU alarm. CPU is the Central Processing Unit 795 that executes basic operations of the system. A cpu-alarm 796 is emitted when the CPU usage exceeds the threshold."; 797 reference 798 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 799 Monitoring YANG Data Model - System alarm for CPU"; 800 } 802 identity disk-alarm { 803 base system-alarm; 804 description 805 "Identity for disk alarm. Disk is the hardware to store 806 information for a long period, i.e., Hard Disk and Solid-State 807 Drive. A disk-alarm is emitted when the Disk usage exceeds 808 the threshold."; 809 reference 810 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 811 Monitoring YANG Data Model - System alarm for disk"; 812 } 814 identity hardware-alarm { 815 base system-alarm; 816 description 817 "Identity for hardware alarm. A hardware alarm is emitted 818 when a problem of hardware, e.g., CPU, memory, disk, or 819 interface, problem is detected."; 820 reference 821 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 822 Monitoring YANG Data Model - System alarm for hardware"; 823 } 825 identity interface-alarm { 826 base system-alarm; 827 description 828 "Identity for interface alarm. Interface is the network 829 interface for connecting a device with the network. The 830 interface-alarm is emitted when the state of the interface 831 is changed."; 832 reference 833 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 834 Monitoring YANG Data Model - System alarm for interface"; 835 } 837 identity device-type { 838 description 839 "Base identity for types of device. This identity is used for 840 type of the device for the destination of a packet or traffic 841 flow."; 842 reference 843 "draft-ietf-i2nsf-capability-data-model-22: 844 I2NSF Capability YANG Data Model"; 845 } 847 identity computer { 848 base device-type; 849 description 850 "Identity for computer such as personal computer (PC) 851 and server."; 852 } 854 identity mobile-phone { 855 base device-type; 856 description 857 "Identity for mobile-phone such as smartphone and 858 cellphone"; 859 } 861 identity voip-volte-phone { 862 base device-type; 863 description 864 "Identity for voip-volte-phone"; 865 } 867 identity tablet { 868 base device-type; 869 description 870 "Identity for tablet devices"; 871 } 873 identity network-infrastructure-device { 874 base device-type; 875 description 876 "Identity for network infrastructure devices 877 such as switch, router, and access point"; 878 } 880 identity iot-device { 881 base device-type; 882 description 883 "Identity for IoT (Internet of Things) devices"; 884 } 886 identity ot { 887 base device-type; 888 description 889 "Identity for Operational Technology devices"; 890 } 892 identity vehicle { 893 base device-type; 894 description 895 "Identity for vehicle that connects to and shares 896 data through the Internet"; 897 } 899 identity advanced-nsf { 900 description 901 "Base identity for advanced Network Security Function (NSF) 902 capability. This can be used for advanced NSFs such as 903 Anti-DDoS Attack, IPS, URL-Filtering, Antivirus, 904 and VoIP/VoLTE Filter."; 905 reference 906 "draft-ietf-i2nsf-capability-data-model-22: 907 I2NSF Capability YANG Data Model"; 908 } 910 identity content-security-control { 911 base advanced-nsf; 912 description 913 "Base identity for content security control. Content security 914 control is an NSF that evaluates the payload of a packet, 915 such as Intrusion Prevention System (IPS), URL Filter, 916 Antivirus, and VoIP/VoLTE Filter."; 917 reference 918 "draft-ietf-i2nsf-capability-data-model-22: 919 I2NSF Capability YANG Data Model"; 920 } 922 identity ips { 923 base content-security-control; 924 description 925 "Identity for IPS (Intrusion Prevention System) 926 that prevents malicious activity within a network"; 927 } 928 identity url-filtering { 929 base content-security-control; 930 description 931 "Identity for url filtering that limits access by comparing the 932 web traffic's URL with the URLs for web filtering in a 933 database"; 934 } 936 identity anti-virus { 937 base content-security-control; 938 description 939 "Identity for antivirus to protect the network by detecting and 940 removing viruses or malwares."; 941 } 943 identity voip-volte-filter { 944 base content-security-control; 945 description 946 "Identity for VoIP/VoLTE security service that filters out the 947 packets or flows of malicious users with a deny list of 948 malicious users in a database"; 949 } 951 identity attack-mitigation-control { 952 base advanced-nsf; 953 description 954 "Base identity for attack mitigation control. Attack mitigation 955 control is an NSF that mitigates an attack such as 956 anti-DDoS (i.e., DDoS-mitigator)."; 957 reference 958 "draft-ietf-i2nsf-capability-data-model-22: 959 I2NSF Capability YANG Data Model"; 960 } 962 identity anti-ddos { 963 base attack-mitigation-control; 964 description 965 "Identity for advanced NSF Anti-DDoS or DDoS Mitigator to 966 protect a server or network from a DDoS attack. The mitigation 967 approach is up to the implementation."; 968 reference 969 "RFC 4732: Internet Denial-of-Service Considerations - DoS 970 Mitigation Strategies 971 RFC 4987: TCP SYN Flooding Attacks and Common Mitigations - 972 Common Defenses"; 973 } 975 identity action { 976 description 977 "Base identity for action."; 978 } 980 identity ingress-action { 981 base action; 982 description 983 "Base identity for ingress action. The action to handle the 984 network traffic that is entering the secured network."; 985 reference 986 "draft-ietf-i2nsf-capability-data-model-22: 987 I2NSF Capability YANG Data Model - Ingress Action"; 988 } 990 identity egress-action { 991 base action; 992 description 993 "Base identity for egress action. The action to handle the 994 network traffic that is exiting the secured network."; 995 reference 996 "draft-ietf-i2nsf-capability-data-model-22: 997 I2NSF Capability YANG Data Model - Egress Action"; 998 } 1000 identity default-action { 1001 base action; 1002 description 1003 "Base identity for default action. The default action of the 1004 NSF when no rule matches the packet or flow."; 1005 reference 1006 "draft-ietf-i2nsf-capability-data-model-22: 1007 I2NSF Capability YANG Data Model - Default Action"; 1008 } 1010 identity pass { 1011 base ingress-action; 1012 base egress-action; 1013 base default-action; 1014 description 1015 "Identity for pass. The pass action allows traffic that matches 1016 the rule to proceed through the NSF to reach the 1017 destination."; 1018 reference 1019 "draft-ietf-i2nsf-capability-data-model-22: 1020 I2NSF Capability YANG Data Model - Actions and 1021 Default Action"; 1022 } 1023 identity drop { 1024 base ingress-action; 1025 base egress-action; 1026 base default-action; 1027 description 1028 "Identity for drop. The drop action denies the traffic that 1029 matches the rule. The drop action should do a silent drop, 1030 which does not give any response to the source."; 1031 reference 1032 "draft-ietf-i2nsf-capability-data-model-22: 1033 I2NSF Capability YANG Data Model - Actions and 1034 Default Action"; 1035 } 1037 identity reject { 1038 base ingress-action; 1039 base egress-action; 1040 base default-action; 1041 description 1042 "Identity for reject action capability. The reject action 1043 denies packet to go through the NSF entering or exiting the 1044 internal network and send a response back to the source. 1045 The response depends on the packet and implementation. 1046 For example, a TCP packet is rejected with TCP RST response 1047 or a UDP packet may be rejected with an ICMP response message 1048 with Type 3 Code 3, i.e., Destination Unreachable: Destination 1049 port unreachable."; 1050 } 1052 identity mirror { 1053 base ingress-action; 1054 base egress-action; 1055 base default-action; 1056 description 1057 "Identity for mirror. The mirror action copies a packet and 1058 sends the packet's copy to the monitoring entity while still 1059 allowing the packet or flow to go through the NSF."; 1060 reference 1061 "draft-ietf-i2nsf-capability-data-model-22: 1062 I2NSF Capability YANG Data Model - Actions and 1063 Default Action"; 1064 } 1066 identity rate-limit { 1067 base ingress-action; 1068 base egress-action; 1069 base default-action; 1070 description 1071 "Identity for rate limiting action. The rate limit action 1072 limits the number of packets or flows that can go through the 1073 NSF by dropping packets or flows (randomly or 1074 systematically). The drop mechanism, e.g., silent drop and 1075 unreachable drop (i.e., reject), is up to the implementation"; 1076 reference 1077 "draft-ietf-i2nsf-capability-data-model-22: 1078 I2NSF Capability YANG Data Model - Actions and 1079 Default Action"; 1080 } 1082 identity log-action { 1083 base action; 1084 description 1085 "Base identity for log action"; 1086 } 1088 identity rule-log { 1089 base log-action; 1090 description 1091 "Identity for rule log. Log the received packet or flow based 1092 on the rule."; 1093 } 1095 identity session-log { 1096 base log-action; 1097 description 1098 "Identity for session log. Log the tasks that is performed 1099 during a session."; 1100 } 1102 identity invoke-signaling { 1103 base egress-action; 1104 description 1105 "Identity for invoke signaling. This action conveys 1106 information of the event triggering this action to a 1107 monitoring entity."; 1108 } 1110 identity tunnel-encapsulation { 1111 base egress-action; 1112 description 1113 "Identity for tunnel encapsulation. This action encapsulates 1114 the packet to be tunneled across the network to enable 1115 a secure connection."; 1116 } 1118 identity forwarding { 1119 base egress-action; 1120 description 1121 "Identity for forwarding. This action forwards the packet to 1122 another node in the network."; 1123 } 1125 identity transformation { 1126 base egress-action; 1127 description 1128 "Identity for transformation. This action transforms the 1129 packet by modifying its protocol header such as HTTP-to-CoAP 1130 translation."; 1131 reference 1132 "RFC 8075: Guidelines for Mapping Implementations: HTTP to the 1133 Constrained Application Protocol (CoAP) - Translation between 1134 HTTP and CoAP."; 1135 } 1137 identity redirection { 1138 base egress-action; 1139 description 1140 "Identity for redirection. This action redirects the packet to 1141 another destination."; 1142 } 1144 identity resolution-strategy { 1145 description 1146 "Base identity for resolution strategy"; 1147 reference 1148 "draft-ietf-i2nsf-capability-data-model-22: 1149 I2NSF Capability YANG Data Model - Resolution Strategy"; 1150 } 1152 identity fmr { 1153 base resolution-strategy; 1154 description 1155 "Identity for First Matching Rule (FMR)"; 1156 reference 1157 "draft-ietf-i2nsf-capability-data-model-22: 1158 I2NSF Capability YANG Data Model - Resolution Strategy"; 1159 } 1161 identity lmr { 1162 base resolution-strategy; 1163 description 1164 "Identity for Last Matching Rule (LMR)"; 1165 reference 1166 "draft-ietf-i2nsf-capability-data-model-22: 1168 I2NSF Capability YANG Data Model - Resolution Strategy"; 1169 } 1171 identity pmr { 1172 base resolution-strategy; 1173 description 1174 "Identity for Prioritized Matching Rule (PMR)"; 1175 reference 1176 "draft-ietf-i2nsf-capability-data-model-22: 1177 I2NSF Capability YANG Data Model - Resolution Strategy"; 1178 } 1180 identity pmre { 1181 base resolution-strategy; 1182 description 1183 "Identity for Prioritized Matching Rule 1184 with Errors (PMRE)"; 1185 reference 1186 "draft-ietf-i2nsf-capability-data-model-22: 1187 I2NSF Capability YANG Data Model - Resolution Strategy"; 1188 } 1190 identity pmrn { 1191 base resolution-strategy; 1192 description 1193 "Identity for Prioritized Matching Rule with No Errors (PMRN)"; 1194 reference 1195 "draft-ietf-i2nsf-capability-data-model-22: 1196 I2NSF Capability YANG Data Model - Resolution Strategy"; 1197 } 1199 identity application-protocol { 1200 description 1201 "Base identity for Application protocol"; 1202 } 1204 identity http { 1205 base application-protocol; 1206 description 1207 "The identity for Hypertext Transfer Protocol."; 1208 reference 1209 "RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1210 Syntax and Routing 1211 RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1212 and Content"; 1213 } 1215 identity https { 1216 base application-protocol; 1217 description 1218 "The identity for Hypertext Transfer Protocol Secure."; 1219 reference 1220 "RFC 2818: HTTP over TLS (HTTPS) 1221 RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1222 Syntax and Routing 1223 RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1224 and Content"; 1225 } 1227 identity ftp { 1228 base application-protocol; 1229 description 1230 "The identity for File Transfer Protocol."; 1231 reference 1232 "RFC 959: File Transfer Protocol (FTP)"; 1233 } 1235 identity ssh { 1236 base application-protocol; 1237 description 1238 "The identity for Secure Shell (SSH) protocol."; 1239 reference 1240 "RFC 4250: The Secure Shell (SSH) Protocol"; 1241 } 1243 identity telnet { 1244 base application-protocol; 1245 description 1246 "The identity for telnet."; 1247 reference 1248 "RFC 854: Telnet Protocol"; 1249 } 1251 identity smtp { 1252 base application-protocol; 1253 description 1254 "The identity for Simple Mail Transfer Protocol."; 1255 reference 1256 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1257 } 1259 identity pop3 { 1260 base application-protocol; 1261 description 1262 "The identity for Post Office Protocol 3. This includes 1263 POP3 over TLS"; 1265 reference 1266 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1267 } 1269 identity imap { 1270 base application-protocol; 1271 description 1272 "The identity for Internet Message Access Protocol. This 1273 includes IMAP over TLS"; 1274 reference 1275 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 1276 4rev2"; 1277 } 1279 /* 1280 * Typedefs 1281 */ 1283 typedef time { 1284 type string { 1285 pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' 1286 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 1287 } 1288 description 1289 "The time type represents an instance of time of zero-duration 1290 that recurs every day."; 1291 } 1293 typedef day { 1294 type enumeration { 1295 enum monday { 1296 description 1297 "This represents Monday."; 1298 } 1299 enum tuesday { 1300 description 1301 "This represents Tuesday."; 1302 } 1303 enum wednesday { 1304 description 1305 "This represents Wednesday"; 1306 } 1307 enum thursday { 1308 description 1309 "This represents Thursday."; 1310 } 1311 enum friday { 1312 description 1313 "This represents Friday."; 1314 } 1315 enum saturday { 1316 description 1317 "This represents Saturday."; 1318 } 1319 enum sunday { 1320 description 1321 "This represents Sunday."; 1322 } 1323 } 1324 description 1325 "The type for representing the day of the week."; 1326 } 1328 /* 1329 * Groupings 1330 */ 1332 grouping port-range { 1333 leaf start { 1334 type inet:port-number; 1335 description 1336 "Starting port number for a range match."; 1337 } 1338 leaf end { 1339 type inet:port-number; 1340 must '. >= ../start' { 1341 error-message 1342 "The end port number MUST be equal to or greater than the 1343 start port number."; 1344 } 1345 description 1346 "Ending port number for a range match."; 1347 } 1348 description 1349 "Range match for the port numbers. If only one value is needed, 1350 then set both start and end to the same value."; 1351 reference 1352 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1353 (TCP) Specification - Port Number 1354 RFC 768: User Datagram Protocol - Port Number 1355 RFC 4960: Stream Control Transmission Protocol - Port Number 1356 RFC 4340: Datagram Congestion Control Protocol (DCCP) 1357 - Port Number"; 1358 } 1360 /* 1361 * Data nodes 1362 */ 1364 list i2nsf-security-policy { 1366 key "name"; 1368 description 1369 "Container for security policy 1370 including a set of security rules according to certain logic, 1371 i.e., their similarity or mutual relations, etc. The network 1372 security policy can be applied to both the unidirectional 1373 and bidirectional traffic across the NSF. 1374 The I2NSF security policies use the Event-Condition-Action 1375 (ECA) policy model "; 1377 reference 1378 "RFC 8329: Framework for Interface to Network Security 1379 Functions - I2NSF Flow Security Policy Structure 1380 draft-ietf-i2nsf-capability-data-model-22: 1381 I2NSF Capability YANG Data Model - Design Principles and 1382 ECA Policy Model Overview"; 1384 leaf name { 1385 type string; 1386 description 1387 "The name of the security policy. 1388 This must be unique."; 1389 } 1391 leaf priority-usage { 1392 type identityref { 1393 base priority-usage; 1394 } 1395 default priority-by-order; 1396 description 1397 "Priority usage type for security policy rule: 1398 priority by order and priority by number"; 1399 } 1401 leaf resolution-strategy { 1402 type identityref { 1403 base resolution-strategy; 1404 } 1405 default fmr; 1406 description 1407 "The resolution strategies that can be used to 1408 specify how to resolve conflicts that occur between 1409 actions of the same or different policy rules that 1410 are matched and contained in this particular NSF"; 1412 reference 1413 "draft-ietf-i2nsf-capability-data-model-22: 1414 I2NSF Capability YANG Data Model - Resolution strategy"; 1415 } 1417 leaf default-action { 1418 type identityref { 1419 base default-action; 1420 } 1421 default mirror; 1422 description 1423 "This default action can be used to specify a predefined 1424 action when no other alternative action was matched 1425 by the currently executing I2NSF Policy Rule. An analogy 1426 is the use of a default statement in a C switch statement."; 1427 reference 1428 "draft-ietf-i2nsf-capability-data-model-22: 1429 I2NSF Capability YANG Data Model - Default Action"; 1430 } 1432 list rules { 1433 key "name"; 1434 description 1435 "This is a rule for network security functions."; 1437 leaf name { 1438 type string; 1439 description 1440 "The name of the rule."; 1441 } 1443 leaf description { 1444 type string; 1445 description 1446 "This description gives more information about 1447 rules."; 1448 } 1450 leaf priority { 1451 type uint8 { 1452 range "1..255"; 1453 } 1454 description 1455 "The priority for the rule comes with a mandatory 1456 numeric value which can range from 1 up to 255. 1458 Note that a higher number means a higher priority"; 1459 } 1461 leaf enable { 1462 type boolean; 1463 description 1464 "If true, the rule is enabled and enforced. 1465 If false, the rule is configured but disabled and not 1466 enforced."; 1467 } 1469 leaf session-aging-time { 1470 type uint16; 1471 units "second"; 1472 description 1473 "This is session aging time."; 1474 } 1476 container long-connection { 1477 description 1478 "A container for long connection. A long connection is a 1479 connection that is maintained after the socket connection 1480 is established, regardless of whether it is used for data 1481 traffic or not."; 1483 leaf enable { 1484 type boolean; 1485 description 1486 "If true, the rule is enabled and enforced. 1487 If false, the rule is configured but disabled 1488 and not enforced."; 1489 } 1491 leaf duration { 1492 type uint16; 1493 units "second"; 1494 description 1495 "This is the duration of the long-connection."; 1496 } 1497 } 1499 container event { 1500 description 1501 "An event is defined as any important 1502 occurrence in time of a change in the system being 1503 managed, and/or in the environment of the system being 1504 managed. When used in the context of policy rules for 1505 a flow-based NSF, it is used to determine whether the 1506 Condition clause of the Policy Rule can be evaluated 1507 or not. Examples of an I2NSF event include time and 1508 user actions (e.g., logon, logoff, and actions that 1509 violate any ACL.)."; 1511 reference 1512 "RFC 8329: Framework for Interface to Network Security 1513 Functions - I2NSF Flow Security Policy Structure 1514 draft-ietf-i2nsf-capability-data-model-22: 1515 I2NSF Capability YANG Data Model - Design Principles and 1516 ECA Policy Model Overview 1517 draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF 1518 NSF Monitoring YANG Data Model - Alarms, Events, Logs, 1519 and Counters"; 1521 leaf description { 1522 type string; 1523 description 1524 "Description for an event clause"; 1525 } 1527 container time { 1528 description 1529 "Time to determine when the policy should be applied"; 1530 leaf start-date-time { 1531 type yang:date-and-time; 1532 description 1533 "This is the start date and time for a security policy 1534 rule."; 1535 } 1537 leaf end-date-time { 1538 type yang:date-and-time; 1539 description 1540 "This is the end date and time for a policy rule. The 1541 policy rule will stop working after the specified 1542 end-date-time."; 1543 } 1545 container period { 1546 when 1547 "../frequency!='only-once'"; 1548 description 1549 "This represents the repetition time. In the case 1550 where the frequency is weekly, the days can be set."; 1551 leaf start-time { 1552 type time; 1553 description 1554 "This is a period's start time for an event."; 1555 } 1556 leaf end-time { 1557 type time; 1558 description 1559 "This is a period's end time for an event."; 1560 } 1561 leaf-list day { 1562 when 1563 "../../frequency='weekly'"; 1564 type day; 1565 min-elements 1; 1566 description 1567 "This represents the repeated day of every week 1568 (e.g., Monday and Tuesday). More than one day can 1569 be specified."; 1570 } 1571 leaf-list date { 1572 when 1573 "../../frequency='monthly'"; 1574 type int8 { 1575 range "1..31"; 1576 } 1577 min-elements 1; 1578 description 1579 "This represents the repeated date of every month. 1580 More than one date can be specified."; 1581 } 1582 leaf-list month { 1583 when 1584 "../../frequency='yearly'"; 1585 type string{ 1586 pattern '\d{2}-\d{2}'; 1587 } 1588 min-elements 1; 1589 description 1590 "This represents the repeated date and month of every 1591 year. More than one can be specified. A pattern 1592 used here is Month and Date (MM-DD)."; 1593 } 1594 } 1596 leaf frequency { 1597 type enumeration { 1598 enum only-once { 1599 description 1600 "This represents that the rule is immediately 1601 enforcedonly once and not repeated. The policy 1602 will continuously be active from the start-time 1603 to the end-time."; 1604 } 1605 enum daily { 1606 description 1607 "This represents that the rule is enforced on a 1608 daily basis. The policy will be repeated 1609 daily until the end-date."; 1610 } 1611 enum weekly { 1612 description 1613 "This represents that the rule is enforced on a 1614 weekly basis. The policy will be repeated weekly 1615 until the end-date. The repeated days can be 1616 specified."; 1617 } 1618 enum monthly { 1619 description 1620 "This represents that the rule is enforced on a 1621 monthly basis. The policy will be repeated monthly 1622 until the end-date."; 1623 } 1624 enum yearly { 1625 description 1626 "This represents that the rule is enforced on 1627 a yearly basis. The policy will be repeated 1628 yearly until the end-date."; 1629 } 1630 } 1631 default only-once; 1632 description 1633 "This represents how frequently the rule 1634 should be enforced."; 1635 } 1636 } 1638 container event-clauses { 1639 description 1640 "Event Clause - either a system event or 1641 system alarm"; 1642 reference 1643 "RFC 8329: Framework for Interface to Network Security 1644 Functions - I2NSF Flow Security Policy Structure 1645 draft-ietf-i2nsf-capability-data-model-22: 1646 I2NSF Capability YANG Data Model - Design Principles and 1647 ECA Policy Model Overview 1648 draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF 1649 NSF Monitoring YANG Data Model - Alarms, Events, Logs, 1650 and Counters"; 1652 leaf-list system-event { 1653 type identityref { 1654 base system-event; 1655 } 1656 description 1657 "The security policy rule according to 1658 system events."; 1659 } 1661 leaf-list system-alarm { 1662 type identityref { 1663 base system-alarm; 1664 } 1665 description 1666 "The security policy rule according to 1667 system alarms."; 1668 } 1669 } 1670 } 1672 container condition { 1673 description 1674 "A condition is defined as a set 1675 of attributes, features, and/or values that are to be 1676 compared with a set of known attributes, features, 1677 and/or values in order to determine whether or not the 1678 set of Actions in that (imperative) I2NSF Policy Rule 1679 can be executed or not. Examples of I2NSF Conditions 1680 include matching attributes of a packet or flow, and 1681 comparing the internal state of an NSF to a desired 1682 state."; 1683 reference 1684 "RFC 8329: Framework for Interface to Network Security 1685 Functions - I2NSF Flow Security Policy Structure 1686 draft-ietf-i2nsf-capability-data-model-22: 1687 I2NSF Capability YANG Data Model - Design Principles and 1688 ECA Policy Model Overview"; 1690 leaf description { 1691 type string; 1692 description 1693 "Description for a condition clause."; 1694 } 1696 container ethernet { 1697 description 1698 "The purpose of this container is to represent layer 2 1699 packet header information to determine the set of policy 1700 actions in this ECA policy rule should be executed or 1701 not."; 1702 reference 1703 "IEEE 802.3: IEEE Standard for Ethernet"; 1705 leaf description { 1706 type string; 1707 description 1708 "The ethernet condition description"; 1709 } 1711 uses packet-fields:acl-eth-header-fields; 1712 } 1714 container ipv4 { 1715 description 1716 "The purpose of this container is to represent IPv4 1717 packet header information to determine if the set 1718 of policy actions in this ECA policy rule should be 1719 executed or not."; 1720 reference 1721 "RFC 791: Internet Protocol"; 1723 leaf description { 1724 type string; 1725 description 1726 "ipv4 condition textual description."; 1727 } 1729 uses packet-fields:acl-ip-header-fields; 1730 uses packet-fields:acl-ipv4-header-fields; 1731 } 1733 container ipv6 { 1734 description 1735 "The purpose of this container is to represent 1736 IPv6 packet header information to determine 1737 if the set of policy actions in this ECA policy 1738 rule should be executed or not."; 1739 reference 1740 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1741 Specification"; 1743 leaf description { 1744 type string; 1745 description 1746 "This is description for ipv6 condition."; 1747 } 1749 uses packet-fields:acl-ip-header-fields; 1750 uses packet-fields:acl-ipv6-header-fields; 1751 } 1753 container tcp { 1754 description 1755 "The purpose of this container is to represent 1756 TCP packet header information to determine 1757 if the set of policy actions in this ECA policy 1758 rule should be executed or not."; 1759 reference 1760 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 1761 Protocol (TCP) Specification"; 1763 leaf description { 1764 type string; 1765 description 1766 "This is description for tcp condition."; 1767 } 1769 container source-port-number { 1770 choice source-port { 1771 case range-or-operator { 1772 uses packet-fields:port-range-or-operator; 1773 description 1774 "Source port definition from range or operator. 1775 Can be used when a single port range to be 1776 specified."; 1777 } 1778 case port-list { 1779 list port-numbers { 1780 key "start"; 1781 uses port-range; 1782 description 1783 "List of source port numbers."; 1784 } 1785 description 1786 "Source port definition from list of port numbers. 1787 In the case of multiple port ranges needed to be 1788 specified."; 1789 } 1790 description 1791 "The choice of source port definition using 1792 range/operator or a choice to use list of port 1793 numbers."; 1794 } 1795 description 1796 "The security policy rule according to 1797 tcp source port number."; 1798 reference 1799 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 1800 Protocol (TCP) Specification - Port Number"; 1801 } 1803 container destination-port-number { 1804 choice destination-port { 1805 case range-or-operator { 1806 uses packet-fields:port-range-or-operator; 1807 description 1808 "Destination port definition from range or 1809 operator. 1810 Can be used when a single port range to be 1811 specified."; 1812 } 1813 case port-list { 1814 list port-numbers { 1815 key "start"; 1816 uses port-range; 1817 description 1818 "List of destination port numbers."; 1819 } 1820 description 1821 "Destination port definition from list of port 1822 numbers. 1823 In the case of multiple port ranges needed to be 1824 specified."; 1825 } 1826 description 1827 "The choice of destination port definition using 1828 range/operator or a choice to use list of port 1829 numbers."; 1830 } 1831 description 1832 "The security policy rule according to 1833 tcp destination port number."; 1834 reference 1835 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 1836 Protocol (TCP) Specification - Port Number"; 1837 } 1839 uses packet-fields:acl-tcp-header-fields; 1841 } 1843 container udp { 1844 description 1845 "The purpose of this container is to represent 1846 UDP packet header information to determine 1847 if the set of policy actions in this ECA policy 1848 rule should be executed or not."; 1849 reference 1850 "RFC 768: User Datagram Protocol"; 1852 leaf description { 1853 type string; 1854 description 1855 "This is description for udp condition."; 1856 } 1858 container source-port-number { 1859 choice source-port { 1860 case range-or-operator { 1861 uses packet-fields:port-range-or-operator; 1862 description 1863 "Source port definition from range or operator. 1864 Can be used when a single port range to be 1865 specified."; 1866 } 1867 case port-list { 1868 list port-numbers { 1869 key "start"; 1870 uses port-range; 1871 description 1872 "List of source port numbers."; 1873 } 1874 description 1875 "Source port definition from list of port numbers. 1876 In the case of multiple port ranges needed to be 1877 specified."; 1878 } 1879 description 1880 "The choice of source port definition using 1881 range/operator or a choice to use list of port 1882 numbers."; 1883 } 1884 description 1885 "The security policy rule according to 1886 udp source port number."; 1887 reference 1888 "RFC 768: User Datagram Protocol - Port Number"; 1890 } 1892 container destination-port-number { 1893 choice destination-port { 1894 case range-or-operator { 1895 uses packet-fields:port-range-or-operator; 1896 description 1897 "Destination port definition from range or 1898 operator. 1899 Can be used when a single port range to be 1900 specified."; 1901 } 1902 case port-list { 1903 list port-numbers { 1904 key "start"; 1905 uses port-range; 1906 description 1907 "List of destination port numbers."; 1908 } 1909 description 1910 "Destination port definition from list of port 1911 numbers. 1912 In the case of multiple port ranges needed to be 1913 specified."; 1914 } 1915 description 1916 "The choice of destination port definition using 1917 range/operator or a choice to use list of port 1918 numbers."; 1919 } 1920 description 1921 "The security policy rule according to 1922 udp destination port number."; 1923 reference 1924 "RFC 768: User Datagram Protocol - Port Number"; 1925 } 1927 uses packet-fields:acl-udp-header-fields; 1928 } 1930 container sctp { 1931 description 1932 "The purpose of this container is to represent 1933 SCTP packet header information to determine 1934 if the set of policy actions in this ECA policy 1935 rule should be executed or not."; 1937 leaf description { 1938 type string; 1939 description 1940 "This is description for sctp condition."; 1941 } 1943 container source-port-number { 1944 choice source-port { 1945 case range-or-operator { 1946 uses packet-fields:port-range-or-operator; 1947 description 1948 "Source port definition from range or operator. 1949 Can be used when a single port range to be 1950 specified."; 1951 } 1952 case port-list { 1953 list port-numbers { 1954 key "start"; 1955 uses port-range; 1956 description 1957 "List of source port numbers."; 1958 } 1959 description 1960 "Source port definition from list of port numbers. 1961 In the case of multiple port ranges needed to be 1962 specified."; 1963 } 1964 description 1965 "The choice of source port definition using 1966 range/operator or a choice to use list of port 1967 numbers."; 1968 } 1969 description 1970 "The security policy rule according to 1971 sctp source port number."; 1972 reference 1973 "RFC 4960: Stream Control Transmission Protocol 1974 - Port number"; 1975 } 1977 container destination-port-number { 1978 choice destination-port { 1979 case range-or-operator { 1980 uses packet-fields:port-range-or-operator; 1981 description 1982 "Destination port definition from range or 1983 operator. 1984 Can be used when a single port range to be 1985 specified."; 1987 } 1988 case port-list { 1989 list port-numbers { 1990 key "start"; 1991 uses port-range; 1992 description 1993 "List of destination port numbers."; 1994 } 1995 description 1996 "Destination port definition from list of port 1997 numbers. 1998 In the case of multiple port ranges needed to be 1999 specified."; 2000 } 2001 description 2002 "The choice of destination port definition using 2003 range/operator or a choice to use list of port 2004 numbers."; 2005 } 2006 description 2007 "The security policy rule according to 2008 sctp destination port number."; 2009 reference 2010 "RFC 4960: Stream Control Transmission Protocol 2011 - Port Number"; 2012 } 2014 leaf-list chunk-type { 2015 type uint8; 2016 description 2017 "The security policy rule according to 2018 sctp chunk type ID Value."; 2019 reference 2020 "RFC 4960: Stream Control Transmission Protocol 2021 - Chunk Type"; 2022 } 2023 } 2025 container dccp { 2026 description 2027 "The purpose of this container is to represent 2028 DCCP packet header information to determine 2029 if the set of policy actions in this ECA policy 2030 rule should be executed or not."; 2031 leaf description { 2032 type string; 2033 description 2034 "This is description for dccp condition."; 2036 } 2038 container source-port-number { 2039 choice source-port { 2040 case range-or-operator { 2041 uses packet-fields:port-range-or-operator; 2042 description 2043 "Source port definition from range or operator. 2044 Can be used when a single port range to be 2045 specified."; 2046 } 2047 case port-list { 2048 list port-numbers { 2049 key "start"; 2050 uses port-range; 2051 description 2052 "List of source port numbers."; 2053 } 2054 description 2055 "Source port definition from list of port numbers. 2056 In the case of multiple port ranges needed to be 2057 specified."; 2058 } 2059 description 2060 "The choice of source port definition using 2061 range/operator or a choice to use list of port 2062 numbers."; 2063 } 2064 description 2065 "The security policy rule according to 2066 dccp source port number."; 2067 reference 2068 "RFC 4340: Datagram Congestion Control Protocol (DCCP) 2069 - Port number"; 2070 } 2072 container destination-port-number { 2073 choice destination-port { 2074 case range-or-operator { 2075 uses packet-fields:port-range-or-operator; 2076 description 2077 "Destination port definition from range or 2078 operator. 2079 Can be used when a single port range to be 2080 specified."; 2081 } 2082 case port-list { 2083 list port-numbers { 2084 key "start"; 2085 uses port-range; 2086 description 2087 "List of destination port numbers."; 2088 } 2089 description 2090 "Destination port definition from list of port 2091 numbers. 2092 In the case of multiple port ranges needed to be 2093 specified."; 2094 } 2095 description 2096 "The choice of destination port definition using 2097 range/operator or a choice to use list of port 2098 numbers."; 2099 } 2100 description 2101 "The security policy rule according to 2102 dccp destination port number."; 2103 reference 2104 "RFC 4340: Datagram Congestion Control Protocol (DCCP) 2105 - Port number"; 2106 } 2108 leaf-list service-code { 2109 type uint32; 2110 description 2111 "The security policy rule according to 2112 dccp service code."; 2113 reference 2114 "RFC 4340: Datagram Congestion Control Protocol (DCCP) 2115 - Service Codes 2116 RFC 5595: The Datagram Congestion Control Protocol 2117 (DCCP) Service Codes 2118 RFC 6335: Internet Assigned Numbers Authority (IANA) 2119 Procedures for the Management of the Service 2120 Name and Transport Protocol Port Number 2121 Registry - Service Code"; 2122 } 2124 leaf-list type { 2125 type uint8 { 2126 range "0..15"; 2127 } 2128 description 2129 "The security policy rule according to the 4 bits of 2130 dccp type header field for dccp packet types such as 2131 DCCP-Request, DCCP-Response, DCCP-Data, DCCP-Ack, and 2132 DCCP-DataAck."; 2133 reference 2134 "RFC 4340: Datagram Congestion Control Protocol (DCCP) 2135 - Packet Types"; 2136 } 2137 } 2139 list icmp { 2140 key "version"; 2141 description 2142 "The purpose of this container is to represent 2143 ICMP packet header information to determine 2144 if the set of policy actions in this ECA policy 2145 rule should be executed or not."; 2146 reference 2147 "RFC 792: Internet Control Message Protocol 2148 RFC 8335: PROBE: A Utility for Probing Interfaces"; 2150 leaf description { 2151 type string; 2152 description 2153 "This is description for icmp condition."; 2154 } 2156 leaf version { 2157 type enumeration { 2158 enum icmpv4 { 2159 value "1"; 2160 description 2161 "The ICMPv4 Protocol as defined in RFC 792"; 2162 } 2163 enum icmpv6 { 2164 value "2"; 2165 description 2166 "The ICMPv6 Protocol as defined in RFC 4443"; 2167 } 2168 } 2169 description 2170 "The ICMP version to be matched. This value 2171 affected the type and code values."; 2172 reference 2173 "RFC 792: Internet Control Message Protocol 2174 RFC 4443: Internet Control Message Protocol (ICMPv6) 2175 for the Internet Protocol Version 6 (IPv6) 2176 Specification"; 2177 } 2179 uses packet-fields:acl-icmp-header-fields; 2181 } 2183 container url-category { 2184 description 2185 "Condition for url category"; 2186 leaf description { 2187 type string; 2188 description 2189 "This is description for the condition of a URL's 2190 category such as SNS sites, game sites, ecommerce 2191 sites, company sites, and university sites."; 2192 } 2194 leaf-list pre-defined { 2195 type string; 2196 description 2197 "This is pre-defined-category. To specify the name of 2198 URL database."; 2199 } 2200 leaf-list user-defined { 2201 type string; 2202 description 2203 "This user-defined-category. To allow a users manual 2204 addition of URLs for URL filtering."; 2205 } 2206 } 2208 container voice { 2209 description 2210 "For the VoIP/VoLTE security system, a VoIP/ 2211 VoLTE security system can monitor each 2212 VoIP/VoLTE flow and manage VoIP/VoLTE 2213 security rules controlled by a centralized 2214 server for VoIP/VoLTE security service 2215 (called VoIP IPS). The VoIP/VoLTE security 2216 system controls each switch for the 2217 VoIP/VoLTE call flow management by 2218 manipulating the rules that can be added, 2219 deleted, or modified dynamically."; 2220 reference 2221 "RFC 3261: SIP: Session Initiation Protocol"; 2223 leaf description { 2224 type string; 2225 description 2226 "This is description for voice condition."; 2227 } 2228 leaf-list source-voice-id { 2229 type string; 2230 description 2231 "The security policy rule according to 2232 a source voice ID for VoIP and VoLTE."; 2233 } 2235 leaf-list destination-voice-id { 2236 type string; 2237 description 2238 "The security policy rule according to 2239 a destination voice ID for VoIP and VoLTE."; 2240 } 2242 leaf-list user-agent { 2243 type string; 2244 description 2245 "The security policy rule according to 2246 an user agent for VoIP and VoLTE."; 2247 } 2248 } 2250 container ddos { 2251 description 2252 "Condition for DDoS attack."; 2254 leaf description { 2255 type string; 2256 description 2257 "This is description for ddos condition."; 2258 } 2260 leaf alert-packet-rate { 2261 type uint32; 2262 units "pps"; 2263 description 2264 "The alert rate of flood detection for 2265 packets per second (PPS) of an IP address. 2266 If the PPS of an IP address exceeds 2267 the alert rate threshold, an alert 2268 will be generated."; 2269 } 2271 leaf alert-flow-rate { 2272 type uint32; 2273 description 2274 "The alert rate of flood detection for 2275 flows per second of an IP address. 2277 If the flows per second of an IP address 2278 exceeds the alert rate threshold, an alert 2279 will be generated."; 2280 } 2282 leaf alert-byte-rate { 2283 type uint32; 2284 units "Bps"; 2285 description 2286 "The alert rate of flood detection for 2287 bytes per second (Bps) of an IP address. 2288 If the bytes per second of an IP address 2289 exceeds the alert rate threshold, an alert 2290 will be generated."; 2291 } 2292 } 2294 container anti-virus { 2295 description 2296 "Condition for antivirus"; 2298 leaf-list profile { 2299 type string; 2300 description 2301 "The security profile for antivirus. This is used to 2302 update the security profile for improving the 2303 security. The security profile is used to scan 2304 the viruses."; 2305 } 2307 leaf-list exception-files { 2308 type string; 2309 description 2310 "The type or name of the files to be excluded by the 2311 anti-virus. This can be used to keep the known 2312 harmless files."; 2313 } 2314 } 2316 container payload { 2317 description 2318 "Condition for packet payload"; 2319 leaf description { 2320 type string; 2321 description 2322 "This is description for payload condition."; 2323 } 2324 leaf-list content { 2325 type string; 2326 description 2327 "This is a condition for packet payload content."; 2328 } 2329 } 2331 container context { 2332 description 2333 "Condition for context"; 2334 leaf description { 2335 type string; 2336 description 2337 "This is description for context condition."; 2338 } 2340 container application { 2341 description 2342 "Condition for application"; 2343 leaf description { 2344 type string; 2345 description 2346 "This is description for application condition."; 2347 } 2348 leaf-list protocol { 2349 type identityref { 2350 base application-protocol; 2351 } 2352 description 2353 "The condition based on the application layer 2354 protocol"; 2355 } 2356 } 2358 container device-type { 2359 description 2360 "Condition for type of the destination device"; 2361 leaf description { 2362 type string; 2363 description 2364 "This is description for destination device type 2365 condition. Vendors can write instructions for the 2366 condition that vendor made"; 2367 } 2369 leaf-list device { 2370 type identityref { 2371 base device-type; 2372 } 2373 description 2374 "The device attribute that can identify a device, 2375 including the device type (i.e., router, switch, 2376 pc, ios, or android) and the device's owner as 2377 well."; 2378 } 2379 } 2381 container users { 2382 description 2383 "Condition for users"; 2384 leaf description { 2385 type string; 2386 description 2387 "This is the description for users' condition."; 2388 } 2389 list user { 2390 key "id"; 2391 description 2392 "The user with which the traffic flow is associated 2393 can be identified by either a user id or user name. 2394 The user-to-IP address mapping is assumed to be 2395 provided by the unified user management system via 2396 network."; 2397 leaf id { 2398 type uint32; 2399 description 2400 "The ID of the user."; 2401 } 2402 leaf name { 2403 type string; 2404 description 2405 "The name of the user."; 2406 } 2407 } 2408 list group { 2409 key "id"; 2410 description 2411 "The user group with which the traffic flow is 2412 associated can be identified by either a group id 2413 or group name. The group-to-IP address and 2414 user-to-group mappings are assumed to be provided by 2415 the unified user management system via network."; 2416 leaf id { 2417 type uint32; 2418 description 2419 "The ID of the group."; 2420 } 2421 leaf name { 2422 type string; 2423 description 2424 "The name of the group."; 2425 } 2426 } 2428 leaf security-group { 2429 type string; 2430 description 2431 "security-group."; 2432 } 2433 } 2435 container geographic-location { 2436 description 2437 "The location which network traffic flow is associated 2438 with. The region can be the geographic location such 2439 as country, province, and city, as well as the logical 2440 network location such as IP address, network section, 2441 and network domain."; 2442 reference 2443 "draft-ietf-netmod-geo-location-11: A YANG Grouping for 2444 Geographic Locations"; 2446 leaf description { 2447 type string; 2448 description 2449 "This is the description for the geographic location 2450 condition. It is used to describe the conditions and 2451 instructions that should be implemented."; 2452 } 2454 leaf-list source { 2455 type string; 2456 description 2457 "The source is a geographic location mapped into an 2458 IP address. It matches the mapped IP address to the 2459 source IP address of the traffic flow."; 2460 reference 2461 "ISO 3166: Codes for the representation of 2462 names of countries and their subdivisions 2463 draft-ietf-netmod-geo-location-11: A YANG Grouping 2464 for Geographic Locations"; 2465 } 2467 leaf-list destination { 2468 type string; 2469 description 2470 "The destination is a geographic location mapped into 2471 an IP address. It matches the mapped IP address to 2472 the destination IP address of the traffic flow."; 2473 reference 2474 "ISO 3166: Codes for the representation of 2475 names of countries and their subdivisions 2476 draft-ietf-netmod-geo-location-11: A YANG Grouping 2477 for Geographic Locations"; 2478 } 2479 } 2480 } 2481 } 2483 container action { 2484 description 2485 "An action is used to control and monitor aspects of 2486 flow-based NSFs when the event and condition clauses 2487 are satisfied. NSFs provide security functions by 2488 executing various Actions. Examples of I2NSF Actions 2489 include providing intrusion detection and/or protection, 2490 web and flow filtering, and deep packet inspection 2491 for packets and flows."; 2492 reference 2493 "RFC 8329: Framework for Interface to Network Security 2494 Functions - I2NSF Flow Security Policy Structure 2495 draft-ietf-i2nsf-capability-data-model-22: 2496 I2NSF Capability YANG Data Model - Design Principles and 2497 ECA Policy Model Overview"; 2499 leaf description { 2500 type string; 2501 description 2502 "Description for an action clause."; 2503 } 2505 container packet-action { 2506 description 2507 "Action for packets"; 2508 reference 2509 "RFC 8329: Framework for Interface to Network Security 2510 Functions - I2NSF Flow Security Policy Structure 2511 draft-ietf-i2nsf-capability-data-model-22: 2512 I2NSF Capability YANG Data Model - Design Principles and 2513 ECA Policy Model Overview"; 2515 leaf ingress-action { 2516 type identityref { 2517 base ingress-action; 2518 } 2519 description 2520 "Ingress Action: pass, drop, rate-limit, and 2521 mirror."; 2522 } 2524 leaf egress-action { 2525 type identityref { 2526 base egress-action; 2527 } 2528 description 2529 "Egress action: pass, drop, rate-limit, mirror, 2530 invoke-signaling, tunnel-encapsulation, forwarding, 2531 and redirection."; 2532 } 2534 leaf log-action { 2535 type identityref { 2536 base log-action; 2537 } 2538 description 2539 "Log action: rule log and session log"; 2540 } 2542 } 2544 container flow-action { 2545 description 2546 "Action for flows"; 2547 reference 2548 "RFC 8329: Framework for Interface to Network Security 2549 Functions - I2NSF Flow Security Policy Structure 2550 draft-ietf-i2nsf-capability-data-model-22: 2551 I2NSF Capability YANG Data Model - Design Principles and 2552 ECA Policy Model Overview"; 2554 leaf ingress-action { 2555 type identityref { 2556 base ingress-action; 2557 } 2558 description 2559 "Action: pass, drop, rate-limit, and mirror."; 2560 } 2562 leaf egress-action { 2563 type identityref { 2564 base egress-action; 2566 } 2567 description 2568 "Egress action: pass, drop, rate-limit, mirror, 2569 invoke-signaling, tunnel-encapsulation, forwarding, 2570 and redirection."; 2571 } 2573 leaf log-action { 2574 type identityref { 2575 base log-action; 2576 } 2577 description 2578 "Log action: rule log and session log"; 2579 } 2580 } 2582 container advanced-action { 2583 description 2584 "If the packet needs to be additionally inspected, 2585 the packet is passed to advanced network 2586 security functions according to the profile. 2587 The profile means the types of NSFs where the packet 2588 will be forwarded in order to additionally 2589 inspect the packet. 2590 The advanced action activates Service Function 2591 Chaining (SFC) for further inspection of a packet."; 2592 reference 2593 "draft-ietf-i2nsf-capability-data-model-22: 2594 I2NSF Capability YANG Data Model - YANG Tree 2595 Diagram"; 2597 leaf-list content-security-control { 2598 type identityref { 2599 base content-security-control; 2600 } 2601 description 2602 "Content-security-control is the NSFs that 2603 inspect the payload of the packet. 2604 The profile for the types of NSFs for mitigation is 2605 divided into content security control and 2606 attack-mitigation-control. 2607 Content security control: ips, url filtering, 2608 anti-virus, and voip-volte-filter. This can be 2609 extended according to the provided NSFs."; 2610 reference 2611 "draft-ietf-i2nsf-capability-data-model-22: 2612 I2NSF Capability YANG Data Model - YANG Tree Diagram"; 2613 } 2614 leaf-list attack-mitigation-control { 2615 type identityref { 2616 base attack-mitigation-control; 2617 } 2618 description 2619 "Attack-mitigation-control is the NSFs that weaken 2620 the attacks related to a denial of service 2621 and reconnaissance. 2622 The profile for the types of NSFs for mitigation is 2623 divided into content security control and 2624 attack-mitigation-control. 2625 Attack mitigation control: Anti-DDoS or DDoS 2626 mitigator. This can be extended according to the 2627 provided NSFs such as mitigators for ip sweep, 2628 port scanning, ping of death, teardrop, oversized 2629 icmp, and tracert."; 2630 reference 2631 "draft-ietf-i2nsf-capability-data-model-22: 2632 I2NSF Capability YANG Data Model - YANG Tree Diagram"; 2633 } 2634 } 2635 } 2636 } 2637 container rule-group { 2638 description 2639 "This is rule group"; 2641 list groups { 2642 key "name"; 2643 description 2644 "This is a group for rules"; 2646 leaf name { 2647 type string; 2648 description 2649 "This is the name of the group for rules"; 2650 } 2652 leaf-list rule-name { 2653 type leafref { 2654 path 2655 "../../../rules/name"; 2656 } 2657 description 2658 "The names of the rules to be grouped."; 2659 } 2661 leaf enable { 2662 type boolean; 2663 description 2664 "If true, the rule is enabled and enforced. 2665 If false, the rule is configured but disabled 2666 and not enforced."; 2667 } 2669 leaf description { 2670 type string; 2671 description 2672 "This is a description for rule-group"; 2673 } 2674 } 2675 } 2676 } 2677 } 2678 2680 Figure 5: YANG Data Module of I2NSF NSF-Facing-Interface 2682 5. XML Configuration Examples of Low-Level Security Policy Rules 2684 This section shows XML configuration examples of low-level security 2685 policy rules that are delivered from the Security Controller to NSFs 2686 over the NSF-Facing Interface. For security requirements, we assume 2687 that the NSFs (i.e., General firewall, Time-based firewall, URL 2688 filter, VoIP/VoLTE filter, and http and https flood mitigation) 2689 described in Appendix A of [I-D.ietf-i2nsf-capability-data-model] are 2690 registered with the I2NSF framework. With the registered NSFs, we 2691 show configuration examples for security policy rules of network 2692 security functions according to the following three security 2693 requirements: (i) Block Social Networking Service (SNS) access during 2694 business hours, (ii) Block malicious VoIP/VoLTE packets coming to the 2695 company, and (iii) Mitigate http and https flood attacks on company 2696 web server. 2698 5.1. Example Security Requirement 1: Block Social Networking Service 2699 (SNS) Access during Business Hours 2701 This section shows a configuration example for blocking SNS access 2702 during business hours in IPv4 networks or IPv6 networks. 2704 2706 sns_access 2707 2708 block_sns_access_during_operation_time 2709 2710 2724 2725 2726 2727 192.0.2.0/24 2728 2729 2730 2731 2732 2733 url-filtering 2734 2735 2736 2737 2738 2740 Figure 6: Configuration XML for Time-based Firewall to Block SNS 2741 Access during Business Hours in IPv4 Networks 2743 2745 sns_access 2746 2747 block_sns_access_during_operation_time 2748 2749 2763 2764 2765 2766 2001:db8:0:1::0/120 2767 2768 2769 2770 2771 2772 url-filtering 2773 2774 2775 2776 2777 2779 Figure 7: Configuration XML for Time-based Firewall to Block SNS 2780 Access during Business Hours in IPv6 Networks 2782 2784 sns_access 2785 2786 block_sns_access_during_operation_time 2787 2788 2789 SNS_1 2790 SNS_2 2791 2792 2793 2794 2795 drop 2796 2797 2798 2799 2801 Figure 8: Configuration XML for Web Filter to Block SNS Access 2802 during Business Hours 2804 Figure 6 (or Figure 7) and Figure 8 show the configuration XML 2805 documents for time-based firewall and web filter to block SNS access 2806 during business hours in IPv4 networks (or IPv6 networks). For the 2807 security requirement, two NSFs (i.e., a time-based firewall and a web 2808 filter) were used because one NSF cannot meet the security 2809 requirement. The instances of XML documents for the time-based 2810 firewall and the web filter are as follows: Note that a detailed data 2811 model for the configuration of the advanced network security function 2812 (i.e., web filter) can be defined as an extension in future. 2814 Time-based Firewall is as follows: 2816 1. The name of the security policy is sns_access. 2818 2. The name of the rule is block_sns_access_during_operation_time. 2820 3. The rule is started from 2021-03-11 at 9 a.m. to 2021-12-31 at 6 2821 p.m. 2823 4. The rule is operated weekly every weekday (i.e., Monday, Tuesday, 2824 Wednesday, Thursday, and Friday) during the business hours (i.e., 2825 from 9 a.m. to 6 p.m.) . 2827 5. The rule inspects a source IPv4 address (i.e., 192.0.2.0/24). 2828 For the case of IPv6 networks, the rule inspects a source IPv6 2829 address (i.e., from 2001:db8:0:1::0/120). 2831 6. If the outgoing packets match the rules above, the time-based 2832 firewall sends the packets to url filtering for additional 2833 inspection because the time-based firewall can not inspect 2834 contents of the packets for the SNS URL. 2836 Web Filter is as follows: 2838 1. The name of the security policy is sns_access. 2840 2. The name of the rule is block_SNS_1_and_SNS_2. 2842 3. The rule inspects URL address to block the access packets to the 2843 SNS_1 or the SNS_2. 2845 4. If the outgoing packets match the rules above, the packets are 2846 blocked. 2848 5.2. Example Security Requirement 2: Block Malicious VoIP/VoLTE Packets 2849 Coming to a Company 2851 This section shows a configuration example for blocking malicious 2852 VoIP/VoLTE packets coming to a company. 2854 2856 voip_volte_inspection 2857 2858 block_malicious_voice_id 2859 2860 2861 192.0.2.0/24 2862 2863 2864 2865 5060 2866 5061 2867 2868 2869 2870 2871 2872 2873 voip-volte-filter 2874 2875 2876 2877 2878 2879 Figure 9: Configuration XML for General Firewall to Block 2880 Malicious VoIP/VoLTE Packets Coming to a Company 2882 2884 voip_volte_inspection 2885 2886 block_malicious_voice_id 2887 2888 2889 2890 user1@voip.malicious.example.com 2891 2892 2893 user2@voip.malicious.example.com 2894 2895 2896 2897 2898 2899 drop 2900 2901 2902 2903 2905 Figure 10: Configuration XML for VoIP/VoLTE Filter to Block 2906 Malicious VoIP/VoLTE Packets Coming to a Company 2908 Figure 9 and Figure 10 show the configuration XML documents for 2909 general firewall and VoIP/VoLTE filter to block malicious VoIP/VoLTE 2910 packets coming to a company. For the security requirement, two NSFs 2911 (i.e., a general firewall and a VoIP/VoLTE filter) were used because 2912 one NSF can not meet the security requirement. The instances of XML 2913 documents for the general firewall and the VoIP/VoLTE filter are as 2914 follows: Note that a detailed data model for the configuration of the 2915 advanced network security function (i.e., VoIP/VoLTE filter) can be 2916 described as an extension in future. 2918 General Firewall is as follows: 2920 1. The name of the security policy is voip_volte_inspection. 2922 2. The name of the rule is block_malicious_voip_volte_packets. 2924 3. The rule inspects a destination IPv4 address (i.e., from 2925 192.0.2.0/24). 2927 4. The rule inspects a port number (i.e., 5060 and 5061) to inspect 2928 VoIP/VoLTE packet. 2930 5. If the incoming packets match the rules above, the general 2931 firewall sends the packets to VoIP/VoLTE filter for additional 2932 inspection because the general firewall can not inspect contents 2933 of the VoIP/VoLTE packets. 2935 VoIP/VoLTE Filter is as follows: 2937 1. The name of the security policy is malicious_voice_id. 2939 2. The name of the rule is block_malicious_voice_id. 2941 3. The rule inspects the voice id of the VoIP/VoLTE packets to block 2942 the malicious VoIP/VoLTE packets (i.e., 2943 user1@voip.malicious.example.com and 2944 user2@voip.malicious.example.com). 2946 4. If the incoming packets match the rules above, the packets are 2947 blocked. 2949 5.3. Example Security Requirement 3: Mitigate HTTP and HTTPS Flood 2950 Attacks on a Company Web Server 2952 This section shows a configuration example for mitigating http and 2953 https flood attacks on a company web server. 2955 2957 flood_attack_mitigation 2958 2959 mitigate_http_and_https_flood_attack 2960 2961 2962 192.0.2.0/24 2963 2964 2965 2966 2967 80 2968 80 2969 2970 2971 443 2972 443 2973 2974 2975 2976 2977 2978 2979 2980 anti-ddos 2981 2982 2983 2984 2985 2987 Figure 11: Configuration XML for General Firewall to Mitigate 2988 HTTP and HTTPS Flood Attacks on a Company Web Server 2990 2992 flood_attack_mitigation 2993 2994 mitigate_http_and_https_flood_attack 2995 2996 2997 1000 2998 2999 3000 3001 3002 drop 3003 3004 3005 3006 3008 Figure 12: Configuration XML for Anti-DDoS to Mitigate HTTP and 3009 HTTPS Flood Attacks on a Company Web Server 3011 Figure 11 and Figure 12 show the configuration XML documents for 3012 general firewall and http and https flood attack mitigation to 3013 mitigate http and https flood attacks on a company web server. For 3014 the security requirement, two NSFs (i.e., a general firewall and a 3015 http and https flood attack mitigation) were used because one NSF can 3016 not meet the security requirement. The instances of XML documents 3017 for the general firewall and http and https flood attack mitigation 3018 are as follows: Note that a detailed data model for the configuration 3019 of the advanced network security function (i.e., http and https flood 3020 attack mitigation) can be defined as an extension in future. 3022 General Firewall is as follows: 3024 1. The name of the security policy is flood_attack_mitigation. 3026 2. The name of the rule is mitigate_http_and_https_flood_attack. 3028 3. The rule inspects a destination IPv4 address (i.e., 192.0.2.0/24) 3029 to inspect the access packets coming into the company web server. 3031 4. The rule inspects a port number (i.e., 80 and 443) to inspect 3032 http and https packet. 3034 5. If the packets match the rules above, the general firewall sends 3035 the packets to anti-DDoS for additional inspection because the 3036 general firewall can not control the amount of packets for http 3037 and https packets. 3039 Anti DDoS for HTTP and HTTPS Flood Attack Mitigation is as follows: 3041 1. The name of the security policy is flood_attack_mitigation. 3043 2. The name of the rule is mitigate_http_and_https_flood_attack. 3045 3. The rule controls the http and https packets according to the 3046 amount of incoming packets (1000 packets per second). 3048 4. If the incoming packets match the rules above, the packets are 3049 blocked. 3051 6. IANA Considerations 3053 This document requests IANA to register the following URI in the 3054 "IETF XML Registry" [RFC3688]: 3056 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf 3057 Registrant Contact: The IESG. 3058 XML: N/A; the requested URI is an XML namespace. 3060 This document requests IANA to register the following YANG module in 3061 the "YANG Module Names" registry [RFC7950][RFC8525]: 3063 name: ietf-i2nsf-policy-rule-for-nsf 3064 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf 3065 prefix: nsfintf 3066 reference: RFC XXXX 3068 7. Security Considerations 3070 The YANG module specified in this document defines a data schema 3071 designed to be accessed through network management protocols such as 3072 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 3073 the secure transport layer, and the required secure transport is 3074 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 3075 and the required secure transport is TLS [RFC8446]. 3077 The NETCONF access control model [RFC8341] provides a means of 3078 restricting access to specific NETCONF or RESTCONF users to a 3079 preconfigured subset of all available NETCONF or RESTCONF protocol 3080 operations and content. 3082 There are a number of data nodes defined in this YANG module that are 3083 writable/creatable/deletable (i.e., config true, which is the 3084 default). These data nodes may be considered sensitive or vulnerable 3085 in some network environments. Write operations (e.g., edit-config) 3086 to these data nodes without proper protection can have a negative 3087 effect on network operations. These are the subtrees and data nodes 3088 and their sensitivity/vulnerability: 3090 * ietf-i2nsf-policy-rule-for-nsf: Writing to almost any element of 3091 this YANG module would directly impact on the configuration of 3092 NSFs, e.g., completely turning off security monitoring and 3093 mitigation capabilities; altering the scope of this monitoring and 3094 mitigation; creating an overwhelming logging volume to overwhelm 3095 downstream analytics or storage capacity; creating logging 3096 patterns which are confusing; or rendering useless trained 3097 statistics or artificial intelligence models. 3099 Some of the readable data nodes in this YANG module may be considered 3100 sensitive or vulnerable in some network environments. It is thus 3101 important to control read access (e.g., via get, get-config, or 3102 notification) to these data nodes. These are the subtrees and data 3103 nodes and their sensitivity/vulnerability: 3105 * ietf-i2nsf-policy-rule-for-nsf: The attacker may gather the 3106 security policy information of any target NSFs and misuse the 3107 security policy information for subsequent attacks. 3109 Policy rules identifying the specified users and user groups can be 3110 specified with "rules/condition/context/users". As with other data 3111 in this YANG module, this user information is provided by the 3112 Security Controller to the NSFs and is protected via the transport 3113 and access control mechanisms described above. 3115 8. Acknowledgments 3117 This work was supported by Institute of Information & Communications 3118 Technology Planning & Evaluation (IITP) grant funded by the Korea 3119 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 3120 Security Intelligence Technology Development for the Customized 3121 Security Service Provisioning). This work was supported in part by 3122 the IITP (2020-0-00395, Standard Development of Blockchain based 3123 Network Management Automation Technology). 3125 9. Contributors 3127 This document is made by the group effort of I2NSF working group. 3128 Many people actively contributed to this document, such as Acee 3129 Lindem and Roman Danyliw. The authors sincerely appreciate their 3130 contributions. 3132 The following are co-authors of this document: 3134 Patrick Lingga Department of Electrical and Computer Engineering 3135 Sungkyunkwan University 2066 Seobu-ro Jangan-gu Suwon, Gyeonggi-do 3136 16419 Republic of Korea EMail: patricklink@skku.edu 3138 Hyoungshick Kim Department of Computer Science and Engineering 3139 Sungkyunkwan University 2066 Seobu-ro Jangan-gu Suwon, Gyeonggi-do 3140 16419 Republic of Korea EMail: hyoung@skku.edu 3142 Daeyoung Hyun Department of Computer Science and Engineering 3143 Sungkyunkwan University 2066 Seobu-ro Jangan-gu Suwon, Gyeonggi-do 3144 16419 Republic of Korea EMail: dyhyun@skku.edu 3146 Dongjin Hong Department of Electronic, Electrical and Computer 3147 Engineering Sungkyunkwan University 2066 Seobu-ro Jangan-gu Suwon, 3148 Gyeonggi-do 16419 Republic of Korea EMail: dong.jin@skku.edu 3150 Liang Xia Huawei 101 Software Avenue Nanjing, Jiangsu 210012 China 3151 EMail: Frank.Xialiang@huawei.com 3153 Tae-Jin Ahn Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 3154 Republic of Korea EMail: taejin.ahn@kt.com 3156 Se-Hui Lee Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 3157 Republic of Korea EMail: sehuilee@kt.com 3159 10. References 3161 10.1. Normative References 3163 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3164 DOI 10.17487/RFC0768, August 1980, 3165 . 3167 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3168 DOI 10.17487/RFC0791, September 1981, 3169 . 3171 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3172 RFC 792, DOI 10.17487/RFC0792, September 1981, 3173 . 3175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3176 Requirement Levels", BCP 14, RFC 2119, 3177 DOI 10.17487/RFC2119, March 1997, 3178 . 3180 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3181 A., Peterson, J., Sparks, R., Handley, M., and E. 3182 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3183 DOI 10.17487/RFC3261, June 2002, 3184 . 3186 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3187 DOI 10.17487/RFC3688, January 2004, 3188 . 3190 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3191 Congestion Control Protocol (DCCP)", RFC 4340, 3192 DOI 10.17487/RFC4340, March 2006, 3193 . 3195 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3196 Control Message Protocol (ICMPv6) for the Internet 3197 Protocol Version 6 (IPv6) Specification", STD 89, 3198 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3199 . 3201 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 3202 RFC 4960, DOI 10.17487/RFC4960, September 2007, 3203 . 3205 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 3206 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 3207 September 2009, . 3209 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3210 the Network Configuration Protocol (NETCONF)", RFC 6020, 3211 DOI 10.17487/RFC6020, October 2010, 3212 . 3214 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3215 and A. Bierman, Ed., "Network Configuration Protocol 3216 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3217 . 3219 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3220 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 3221 . 3223 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 3224 Cheshire, "Internet Assigned Numbers Authority (IANA) 3225 Procedures for the Management of the Service Name and 3226 Transport Protocol Port Number Registry", BCP 165, 3227 RFC 6335, DOI 10.17487/RFC6335, August 2011, 3228 . 3230 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3231 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3232 . 3234 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3235 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3236 . 3238 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3239 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3240 . 3242 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 3243 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 3244 the Constrained Application Protocol (CoAP)", RFC 8075, 3245 DOI 10.17487/RFC8075, February 2017, 3246 . 3248 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3249 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3250 May 2017, . 3252 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3253 (IPv6) Specification", STD 86, RFC 8200, 3254 DOI 10.17487/RFC8200, July 2017, 3255 . 3257 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 3258 Boucadair, "PROBE: A Utility for Probing Interfaces", 3259 RFC 8335, DOI 10.17487/RFC8335, February 2018, 3260 . 3262 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3263 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3264 . 3266 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 3267 Access Control Model", STD 91, RFC 8341, 3268 DOI 10.17487/RFC8341, March 2018, 3269 . 3271 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 3272 Documents Containing YANG Data Models", BCP 216, RFC 8407, 3273 DOI 10.17487/RFC8407, October 2018, 3274 . 3276 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3277 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3278 . 3280 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 3281 "YANG Data Model for Network Access Control Lists (ACLs)", 3282 RFC 8519, DOI 10.17487/RFC8519, March 2019, 3283 . 3285 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 3286 and R. Wilton, "YANG Library", RFC 8525, 3287 DOI 10.17487/RFC8525, March 2019, 3288 . 3290 [I-D.ietf-tcpm-rfc793bis] 3291 Eddy, W. M., "Transmission Control Protocol (TCP) 3292 Specification", Work in Progress, Internet-Draft, draft- 3293 ietf-tcpm-rfc793bis-25, 7 September 2021, 3294 . 3297 [I-D.ietf-i2nsf-capability-data-model] 3298 Hares, S., Jeong, J. (., Kim, J. (., Moskowitz, R., and Q. 3299 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 3300 Internet-Draft, draft-ietf-i2nsf-capability-data-model-22, 3301 22 January 2022, . 3304 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 3305 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 3306 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 3307 Model", Work in Progress, Internet-Draft, draft-ietf- 3308 i2nsf-nsf-monitoring-data-model-12, 17 November 2021, 3309 . 3312 [I-D.ietf-netmod-geo-location] 3313 Hopps, C., "A YANG Grouping for Geographic Locations", 3314 Work in Progress, Internet-Draft, draft-ietf-netmod-geo- 3315 location-11, 24 October 2021, 3316 . 3319 10.2. Informative References 3321 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 3322 Denial-of-Service Considerations", RFC 4732, 3323 DOI 10.17487/RFC4732, December 2006, 3324 . 3326 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 3327 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 3328 . 3330 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 3331 Kumar, "Framework for Interface to Network Security 3332 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 3333 . 3335 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 3336 Jeong, J. (., Chung, C., Ahn, T., Kumar, R., and S. Hares, 3337 "I2NSF Consumer-Facing Interface YANG Data Model", Work in 3338 Progress, Internet-Draft, draft-ietf-i2nsf-consumer- 3339 facing-interface-dm-15, 15 September 2021, 3340 . 3343 [ISO-3166] "Codes for the representation of names of countries and 3344 their subdivisions", ISO 3166, September 2018, 3345 . 3347 [IEEE-802.3] 3348 Institute of Electrical and Electronics Engineers, "IEEE 3349 Standard for Ethernet", 2018, 3350 . 3352 Authors' Addresses 3354 Jinyong (Tim) Kim (editor) 3355 Department of Electronic, Electrical and Computer Engineering 3356 Sungkyunkwan University 3357 2066 Seobu-Ro, Jangan-Gu 3358 Suwon 3359 Gyeonggi-Do 3360 16419 3361 Republic of Korea 3363 Phone: +82 10 8273 0930 3364 Email: timkim@skku.edu 3365 Jaehoon (Paul) Jeong (editor) 3366 Department of Computer Science and Engineering 3367 Sungkyunkwan University 3368 2066 Seobu-Ro, Jangan-Gu 3369 Suwon 3370 Gyeonggi-Do 3371 16419 3372 Republic of Korea 3374 Phone: +82 31 299 4957 3375 Email: pauljeong@skku.edu 3376 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3378 Jung-Soo Park 3379 Electronics and Telecommunications Research Institute 3380 218 Gajeong-Ro, Yuseong-Gu 3381 Daejeon 3382 34129 3383 Republic of Korea 3385 Phone: +82 42 860 6514 3386 Email: pjs@etri.re.kr 3388 Susan Hares 3389 Huawei 3390 7453 Hickory Hill 3391 Saline, MI 48176 3392 United States of America 3394 Phone: +1-734-604-0332 3395 Email: shares@ndzh.com 3397 Qiushi Lin 3398 Huawei 3399 Huawei Industrial Base 3400 Shenzhen 3401 Guangdong 518129, 3402 China 3404 Email: linqiushi@huawei.com