idnits 2.17.1 draft-ietf-i2nsf-nsf-facing-interface-dm-18.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 (26 January 2022) is 820 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: 30 July 2022 J. Park 6 ETRI 7 S. Hares 8 Q. Lin 9 Huawei 10 26 January 2022 12 I2NSF Network Security Function-Facing Interface YANG Data Model 13 draft-ietf-i2nsf-nsf-facing-interface-dm-18 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 30 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, or 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-26.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-26"{ 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 760 above their privilege (i.e., not-conformant with the 761 access profile)."; 762 reference 763 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 764 Monitoring YANG Data Model - System event for access 765 violation"; 766 } 768 identity configuration-change { 769 base system-event; 770 description 771 "Identity for configuration change. Configuration change is 772 a system event when a new configuration is added or an 773 existing configuration is modified."; 774 reference 775 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 776 Monitoring YANG Data Model - System event for configuration 777 change"; 778 } 780 identity memory-alarm { 781 base system-alarm; 782 description 783 "Identity for memory alarm. Memory is the hardware to store 784 information temporarily or for a short period, i.e., Random 785 Access Memory (RAM). A memory-alarm is emitted when the memory 786 usage is exceeding the threshold."; 787 reference 788 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 789 Monitoring YANG Data Model - System alarm for memory"; 790 } 792 identity cpu-alarm { 793 base system-alarm; 794 description 795 "Identity for CPU alarm. CPU is the Central Processing Unit 796 that executes basic operations of the system. A cpu-alarm 797 is emitted when the CPU usage is exceeding the threshold."; 798 reference 799 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 800 Monitoring YANG Data Model - System alarm for CPU"; 801 } 803 identity disk-alarm { 804 base system-alarm; 805 description 806 "Identity for disk alarm. Disk is the hardware to store 807 information for a long period, i.e., Hard Disk and Solid-State 808 Drive. A disk-alarm is emitted when the disk usage is 809 exceeding the threshold."; 810 reference 811 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 812 Monitoring YANG Data Model - System alarm for disk"; 813 } 815 identity hardware-alarm { 816 base system-alarm; 817 description 818 "Identity for hardware alarm. A hardware alarm is emitted 819 when a problem of hardware (e.g., CPU, memory, disk, or 820 interface) is detected."; 821 reference 822 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 823 Monitoring YANG Data Model - System alarm for hardware"; 824 } 826 identity interface-alarm { 827 base system-alarm; 828 description 829 "Identity for interface alarm. Interface is the network 830 interface for connecting a device with the network. The 831 interface-alarm is emitted when the state of the interface 832 is changed."; 834 reference 835 "draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF NSF 836 Monitoring YANG Data Model - System alarm for interface"; 837 } 839 identity device-type { 840 description 841 "Base identity for types of device. This identity is used for 842 type of the device for the destination of a packet or traffic 843 flow."; 844 reference 845 "draft-ietf-i2nsf-capability-data-model-22: 846 I2NSF Capability YANG Data Model"; 847 } 849 identity computer { 850 base device-type; 851 description 852 "Identity for computer such as personal computer (PC) 853 and server."; 854 } 856 identity mobile-phone { 857 base device-type; 858 description 859 "Identity for mobile-phone such as smartphone and 860 cellphone"; 861 } 863 identity voip-volte-phone { 864 base device-type; 865 description 866 "Identity for voip-volte-phone"; 867 } 869 identity tablet { 870 base device-type; 871 description 872 "Identity for tablet devices"; 873 } 875 identity network-infrastructure-device { 876 base device-type; 877 description 878 "Identity for network infrastructure devices 879 such as switch, router, and access point"; 880 } 881 identity iot-device { 882 base device-type; 883 description 884 "Identity for IoT (Internet of Things) devices"; 885 } 887 identity ot { 888 base device-type; 889 description 890 "Identity for Operational Technology (OT) devices (also 891 known as industrial control systems) that interact 892 with the physical environment and detect or cause direct 893 change through the monitoring and control of devices, 894 processes, and events such as programmable logic 895 controllers (PLCs), digital oscilloscopes, building 896 management systems (BMS), and fire control systems"; 897 } 899 identity vehicle { 900 base device-type; 901 description 902 "Identity for transportation vehicles that connect to and 903 shares data through the Internet over Vehicle-to-Everything 904 (V2X) communications."; 905 } 907 identity advanced-nsf { 908 description 909 "Base identity for advanced Network Security Function (NSF) 910 capability. This can be used for advanced NSFs such as 911 Anti-DDoS Attack, IPS, URL-Filtering, Antivirus, 912 and VoIP/VoLTE Filter."; 913 reference 914 "draft-ietf-i2nsf-capability-data-model-22: 915 I2NSF Capability YANG Data Model"; 916 } 918 identity content-security-control { 919 base advanced-nsf; 920 description 921 "Base identity for content security control. Content security 922 control is an NSF that evaluates the payload of a packet, 923 such as Intrusion Prevention System (IPS), URL Filter, 924 Antivirus, and VoIP/VoLTE Filter."; 925 reference 926 "draft-ietf-i2nsf-capability-data-model-22: 927 I2NSF Capability YANG Data Model"; 928 } 929 identity ips { 930 base content-security-control; 931 description 932 "Identity for IPS (Intrusion Prevention System) 933 that prevents malicious activity within a network"; 934 } 936 identity url-filtering { 937 base content-security-control; 938 description 939 "Identity for url filtering that limits access by comparing the 940 web traffic's URL with the URLs for web filtering in a 941 database"; 942 } 944 identity anti-virus { 945 base content-security-control; 946 description 947 "Identity for antivirus to protect the network by detecting and 948 removing viruses or malwares."; 949 } 951 identity voip-volte-filter { 952 base content-security-control; 953 description 954 "Identity for VoIP/VoLTE security service that filters out the 955 packets or flows of malicious users with a deny list of 956 malicious users in a database"; 957 } 959 identity attack-mitigation-control { 960 base advanced-nsf; 961 description 962 "Base identity for attack mitigation control. Attack mitigation 963 control is an NSF that mitigates an attack such as 964 anti-DDoS (i.e., DDoS-mitigator)."; 965 reference 966 "draft-ietf-i2nsf-capability-data-model-22: 967 I2NSF Capability YANG Data Model"; 968 } 970 identity anti-ddos { 971 base attack-mitigation-control; 972 description 973 "Identity for advanced NSF Anti-DDoS or DDoS Mitigator to 974 protect a server or network from a DDoS attack. The mitigation 975 approach is up to the implementation."; 976 reference 977 "RFC 4732: Internet Denial-of-Service Considerations - DoS 978 Mitigation Strategies 979 RFC 4987: TCP SYN Flooding Attacks and Common Mitigations - 980 Common Defenses"; 981 } 983 identity action { 984 description 985 "Base identity for action."; 986 } 988 identity ingress-action { 989 base action; 990 description 991 "Base identity for ingress action. The action to handle the 992 network traffic that is entering the secured network."; 993 reference 994 "draft-ietf-i2nsf-capability-data-model-22: 995 I2NSF Capability YANG Data Model - Ingress Action"; 996 } 998 identity egress-action { 999 base action; 1000 description 1001 "Base identity for egress action. The action to handle the 1002 network traffic that is exiting the secured network."; 1003 reference 1004 "draft-ietf-i2nsf-capability-data-model-22: 1005 I2NSF Capability YANG Data Model - Egress Action"; 1006 } 1008 identity default-action { 1009 base action; 1010 description 1011 "Base identity for default action. The default action of the 1012 NSF when no rule matches the packet or flow."; 1013 reference 1014 "draft-ietf-i2nsf-capability-data-model-22: 1015 I2NSF Capability YANG Data Model - Default Action"; 1016 } 1018 identity pass { 1019 base ingress-action; 1020 base egress-action; 1021 base default-action; 1022 description 1023 "Identity for pass. The pass action allows traffic that matches 1024 the rule to proceed through the NSF to reach the 1025 destination."; 1026 reference 1027 "draft-ietf-i2nsf-capability-data-model-22: 1028 I2NSF Capability YANG Data Model - Actions and 1029 Default Action"; 1030 } 1032 identity drop { 1033 base ingress-action; 1034 base egress-action; 1035 base default-action; 1036 description 1037 "Identity for drop. The drop action denies the traffic that 1038 matches the rule. The drop action should do a silent drop, 1039 which does not give any response to the source."; 1040 reference 1041 "draft-ietf-i2nsf-capability-data-model-22: 1042 I2NSF Capability YANG Data Model - Actions and 1043 Default Action"; 1044 } 1046 identity reject { 1047 base ingress-action; 1048 base egress-action; 1049 base default-action; 1050 description 1051 "Identity for reject action capability. The reject action 1052 denies packet to go through the NSF entering or exiting the 1053 internal network and send a response back to the source. 1054 The response depends on the packet and implementation. 1055 For example, a TCP packet is rejected with TCP RST response 1056 or a UDP packet may be rejected with an ICMP response message 1057 with Type 3 Code 3, i.e., Destination Unreachable: Destination 1058 port unreachable."; 1059 } 1061 identity mirror { 1062 base ingress-action; 1063 base egress-action; 1064 base default-action; 1065 description 1066 "Identity for mirror. The mirror action copies a packet and 1067 sends the packet's copy to the monitoring entity while still 1068 allowing the packet or flow to go through the NSF."; 1069 reference 1070 "draft-ietf-i2nsf-capability-data-model-22: 1071 I2NSF Capability YANG Data Model - Actions and 1072 Default Action"; 1074 } 1076 identity rate-limit { 1077 base ingress-action; 1078 base egress-action; 1079 base default-action; 1080 description 1081 "Identity for rate limiting action. The rate limit action 1082 limits the number of packets or flows that can go through the 1083 NSF by dropping packets or flows (randomly or 1084 systematically). The drop mechanism, e.g., silent drop and 1085 unreachable drop (i.e., reject), is up to the implementation"; 1086 reference 1087 "draft-ietf-i2nsf-capability-data-model-22: 1088 I2NSF Capability YANG Data Model - Actions and 1089 Default Action"; 1090 } 1092 identity log-action { 1093 base action; 1094 description 1095 "Base identity for log action"; 1096 } 1098 identity rule-log { 1099 base log-action; 1100 description 1101 "Identity for rule log. Log the received packet or flow based 1102 on the rule."; 1103 } 1105 identity session-log { 1106 base log-action; 1107 description 1108 "Identity for session log. Log the tasks that is performed 1109 during a session."; 1110 } 1112 identity invoke-signaling { 1113 base egress-action; 1114 description 1115 "Identity for invoke signaling. The invoke signaling action 1116 is used to convey information of the event triggering this 1117 action to a monitoring entity."; 1118 } 1120 identity tunnel-encapsulation { 1121 base egress-action; 1122 description 1123 "Identity for tunnel encapsulation. The tunnel encapsulation 1124 action is used to encapsulate the packet to be tunneled across 1125 the network to enable a secure connection."; 1126 } 1128 identity forwarding { 1129 base egress-action; 1130 description 1131 "Identity for forwarding. The forwarding action is used to 1132 relay the packet from one network segment to another node 1133 in the network."; 1134 } 1136 identity transformation { 1137 base egress-action; 1138 description 1139 "Identity for transformation. The transformation action is used 1140 to transform the packet by modifying its protocol header such 1141 as HTTP-to-CoAP translation."; 1142 reference 1143 "RFC 8075: Guidelines for Mapping Implementations: HTTP to the 1144 Constrained Application Protocol (CoAP) - Translation between 1145 HTTP and CoAP."; 1146 } 1148 identity redirection { 1149 base egress-action; 1150 description 1151 "Identity for redirection. This action redirects the packet to 1152 another destination."; 1153 } 1155 identity resolution-strategy { 1156 description 1157 "Base identity for resolution strategy"; 1158 reference 1159 "draft-ietf-i2nsf-capability-data-model-22: 1160 I2NSF Capability YANG Data Model - Resolution Strategy"; 1161 } 1163 identity fmr { 1164 base resolution-strategy; 1165 description 1166 "Identity for First Matching Rule (FMR)"; 1167 reference 1168 "draft-ietf-i2nsf-capability-data-model-22: 1169 I2NSF Capability YANG Data Model - Resolution Strategy"; 1171 } 1173 identity lmr { 1174 base resolution-strategy; 1175 description 1176 "Identity for Last Matching Rule (LMR)"; 1177 reference 1178 "draft-ietf-i2nsf-capability-data-model-22: 1179 I2NSF Capability YANG Data Model - Resolution Strategy"; 1180 } 1182 identity pmr { 1183 base resolution-strategy; 1184 description 1185 "Identity for Prioritized Matching Rule (PMR)"; 1186 reference 1187 "draft-ietf-i2nsf-capability-data-model-22: 1188 I2NSF Capability YANG Data Model - Resolution Strategy"; 1189 } 1191 identity pmre { 1192 base resolution-strategy; 1193 description 1194 "Identity for Prioritized Matching Rule 1195 with Errors (PMRE)"; 1196 reference 1197 "draft-ietf-i2nsf-capability-data-model-22: 1198 I2NSF Capability YANG Data Model - Resolution Strategy"; 1199 } 1201 identity pmrn { 1202 base resolution-strategy; 1203 description 1204 "Identity for Prioritized Matching Rule with No Errors (PMRN)"; 1205 reference 1206 "draft-ietf-i2nsf-capability-data-model-22: 1207 I2NSF Capability YANG Data Model - Resolution Strategy"; 1208 } 1210 identity application-protocol { 1211 description 1212 "Base identity for Application protocol"; 1213 } 1215 identity http { 1216 base application-protocol; 1217 description 1218 "The identity for Hypertext Transfer Protocol."; 1220 reference 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 https { 1228 base application-protocol; 1229 description 1230 "The identity for Hypertext Transfer Protocol Secure."; 1231 reference 1232 "RFC 2818: HTTP over TLS (HTTPS) 1233 RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message 1234 Syntax and Routing 1235 RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics 1236 and Content"; 1237 } 1239 identity ftp { 1240 base application-protocol; 1241 description 1242 "The identity for File Transfer Protocol."; 1243 reference 1244 "RFC 959: File Transfer Protocol (FTP)"; 1245 } 1247 identity ssh { 1248 base application-protocol; 1249 description 1250 "The identity for Secure Shell (SSH) protocol."; 1251 reference 1252 "RFC 4250: The Secure Shell (SSH) Protocol"; 1253 } 1255 identity telnet { 1256 base application-protocol; 1257 description 1258 "The identity for telnet."; 1259 reference 1260 "RFC 854: Telnet Protocol"; 1261 } 1263 identity smtp { 1264 base application-protocol; 1265 description 1266 "The identity for Simple Mail Transfer Protocol."; 1267 reference 1268 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1269 } 1271 identity pop3 { 1272 base application-protocol; 1273 description 1274 "The identity for Post Office Protocol 3. This includes 1275 POP3 over TLS"; 1276 reference 1277 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1278 } 1280 identity imap { 1281 base application-protocol; 1282 description 1283 "The identity for Internet Message Access Protocol. This 1284 includes IMAP over TLS"; 1285 reference 1286 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 1287 4rev2"; 1288 } 1290 /* 1291 * Typedefs 1292 */ 1294 typedef time { 1295 type string { 1296 pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' 1297 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 1298 } 1299 description 1300 "The time type represents an instance of time of zero-duration 1301 that recurs every day."; 1302 } 1304 typedef day { 1305 type enumeration { 1306 enum monday { 1307 description 1308 "This represents Monday."; 1309 } 1310 enum tuesday { 1311 description 1312 "This represents Tuesday."; 1313 } 1314 enum wednesday { 1315 description 1316 "This represents Wednesday"; 1317 } 1318 enum thursday { 1319 description 1320 "This represents Thursday."; 1321 } 1322 enum friday { 1323 description 1324 "This represents Friday."; 1325 } 1326 enum saturday { 1327 description 1328 "This represents Saturday."; 1329 } 1330 enum sunday { 1331 description 1332 "This represents Sunday."; 1333 } 1334 } 1335 description 1336 "The type for representing the day of the week."; 1337 } 1339 /* 1340 * Groupings 1341 */ 1343 grouping port-range { 1344 leaf start { 1345 type inet:port-number; 1346 description 1347 "Starting port number for a range match."; 1348 } 1349 leaf end { 1350 type inet:port-number; 1351 must '. >= ../start' { 1352 error-message 1353 "The end port number MUST be equal to or greater than the 1354 start port number."; 1355 } 1356 description 1357 "Ending port number for a range match."; 1358 } 1359 description 1360 "Range match for the port numbers. If only one value is needed, 1361 then set both start and end to the same value."; 1362 reference 1363 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1364 (TCP) Specification - Port Number 1365 RFC 768: User Datagram Protocol - Port Number 1366 RFC 4960: Stream Control Transmission Protocol - Port Number 1367 RFC 4340: Datagram Congestion Control Protocol (DCCP) 1368 - Port Number"; 1369 } 1371 /* 1372 * Data nodes 1373 */ 1375 list i2nsf-security-policy { 1377 key "name"; 1379 description 1380 "Container for security policy 1381 including a set of security rules according to certain logic, 1382 i.e., their similarity or mutual relations, etc. The network 1383 security policy can be applied to both the unidirectional 1384 and bidirectional traffic across the NSF. 1385 The I2NSF security policies use the Event-Condition-Action 1386 (ECA) policy model "; 1388 reference 1389 "RFC 8329: Framework for Interface to Network Security 1390 Functions - I2NSF Flow Security Policy Structure 1391 draft-ietf-i2nsf-capability-data-model-22: 1392 I2NSF Capability YANG Data Model - Design Principles and 1393 ECA Policy Model Overview"; 1395 leaf name { 1396 type string; 1397 description 1398 "The name of the security policy. 1399 This must be unique."; 1400 } 1402 leaf priority-usage { 1403 type identityref { 1404 base priority-usage; 1405 } 1406 default priority-by-order; 1407 description 1408 "Priority usage type for security policy rule: 1409 priority by order and priority by number"; 1410 } 1411 leaf resolution-strategy { 1412 type identityref { 1413 base resolution-strategy; 1414 } 1415 default fmr; 1416 description 1417 "The resolution strategies that can be used to 1418 specify how to resolve conflicts that occur between 1419 actions of the same or different policy rules that 1420 are matched and contained in this particular NSF"; 1422 reference 1423 "draft-ietf-i2nsf-capability-data-model-22: 1424 I2NSF Capability YANG Data Model - Resolution strategy"; 1425 } 1427 leaf default-action { 1428 type identityref { 1429 base default-action; 1430 } 1431 default mirror; 1432 description 1433 "This default action can be used to specify a predefined 1434 action when no other alternative action was matched 1435 by the currently executing I2NSF Policy Rule. An analogy 1436 is the use of a default statement in a C switch statement."; 1437 reference 1438 "draft-ietf-i2nsf-capability-data-model-22: 1439 I2NSF Capability YANG Data Model - Default Action"; 1440 } 1442 list rules { 1443 key "name"; 1444 description 1445 "This is a rule for network security functions."; 1447 leaf name { 1448 type string; 1449 description 1450 "The name of the rule."; 1451 } 1453 leaf description { 1454 type string; 1455 description 1456 "This description gives more information about 1457 rules."; 1458 } 1459 leaf priority { 1460 type uint8 { 1461 range "1..255"; 1462 } 1463 description 1464 "The priority for the rule comes with a mandatory 1465 numeric value which can range from 1 up to 255. 1466 Note that a higher number means a higher priority"; 1467 } 1469 leaf enable { 1470 type boolean; 1471 description 1472 "If true, the rule is enabled and enforced. 1473 If false, the rule is configured but disabled and not 1474 enforced."; 1475 } 1477 leaf session-aging-time { 1478 type uint16; 1479 units "second"; 1480 description 1481 "This is session aging time."; 1482 } 1484 container long-connection { 1485 description 1486 "A container for long connection. A long connection is a 1487 connection that is maintained after the socket connection 1488 is established, regardless of whether it is used for data 1489 traffic or not."; 1491 leaf enable { 1492 type boolean; 1493 description 1494 "If true, the rule is enabled and enforced. 1495 If false, the rule is configured but disabled 1496 and not enforced."; 1497 } 1499 leaf duration { 1500 type uint16; 1501 units "second"; 1502 description 1503 "This is the duration of the long-connection."; 1504 } 1505 } 1506 container event { 1507 description 1508 "An event is defined as any important 1509 occurrence in time of a change in the system being 1510 managed, and/or in the environment of the system being 1511 managed. When used in the context of policy rules for 1512 a flow-based NSF, it is used to determine whether the 1513 Condition clause of the Policy Rule can be evaluated 1514 or not. Examples of an I2NSF event include time and 1515 user actions (e.g., logon, logoff, and actions that 1516 violate any ACL.)."; 1518 reference 1519 "RFC 8329: Framework for Interface to Network Security 1520 Functions - I2NSF Flow Security Policy Structure 1521 draft-ietf-i2nsf-capability-data-model-22: 1522 I2NSF Capability YANG Data Model - Design Principles and 1523 ECA Policy Model Overview 1524 draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF 1525 NSF Monitoring YANG Data Model - Alarms, Events, Logs, 1526 and Counters"; 1528 leaf description { 1529 type string; 1530 description 1531 "Description for an event clause"; 1532 } 1534 container time { 1535 description 1536 "Time to determine when the policy should be applied"; 1537 leaf start-date-time { 1538 type yang:date-and-time; 1539 description 1540 "This is the start date and time for a security policy 1541 rule."; 1542 } 1544 leaf end-date-time { 1545 type yang:date-and-time; 1546 description 1547 "This is the end date and time for a policy rule. The 1548 policy rule will stop working after the specified 1549 end-date-time."; 1550 } 1552 container period { 1553 when 1554 "../frequency!='only-once'"; 1555 description 1556 "This represents the repetition time. In the case 1557 where the frequency is weekly, the days can be set."; 1558 leaf start-time { 1559 type time; 1560 description 1561 "This is a period's start time for an event."; 1562 } 1563 leaf end-time { 1564 type time; 1565 description 1566 "This is a period's end time for an event."; 1567 } 1568 leaf-list day { 1569 when 1570 "../../frequency='weekly'"; 1571 type day; 1572 min-elements 1; 1573 description 1574 "This represents the repeated day of every week 1575 (e.g., Monday and Tuesday). More than one day can 1576 be specified."; 1577 } 1578 leaf-list date { 1579 when 1580 "../../frequency='monthly'"; 1581 type int8 { 1582 range "1..31"; 1583 } 1584 min-elements 1; 1585 description 1586 "This represents the repeated date of every month. 1587 More than one date can be specified."; 1588 } 1589 leaf-list month { 1590 when 1591 "../../frequency='yearly'"; 1592 type string{ 1593 pattern '\d{2}-\d{2}'; 1594 } 1595 min-elements 1; 1596 description 1597 "This represents the repeated date and month of every 1598 year. More than one can be specified. A pattern 1599 used here is Month and Date (MM-DD)."; 1600 } 1601 } 1602 leaf frequency { 1603 type enumeration { 1604 enum only-once { 1605 description 1606 "This represents that the rule is immediately 1607 enforcedonly once and not repeated. The policy 1608 will continuously be active from the start-time 1609 to the end-time."; 1610 } 1611 enum daily { 1612 description 1613 "This represents that the rule is enforced on a 1614 daily basis. The policy will be repeated 1615 daily until the end-date."; 1616 } 1617 enum weekly { 1618 description 1619 "This represents that the rule is enforced on a 1620 weekly basis. The policy will be repeated weekly 1621 until the end-date. The repeated days can be 1622 specified."; 1623 } 1624 enum monthly { 1625 description 1626 "This represents that the rule is enforced on a 1627 monthly basis. The policy will be repeated monthly 1628 until the end-date."; 1629 } 1630 enum yearly { 1631 description 1632 "This represents that the rule is enforced on 1633 a yearly basis. The policy will be repeated 1634 yearly until the end-date."; 1635 } 1636 } 1637 default only-once; 1638 description 1639 "This represents how frequently the rule 1640 should be enforced."; 1641 } 1642 } 1644 container event-clauses { 1645 description 1646 "Event Clause - either a system event or 1647 system alarm"; 1648 reference 1649 "RFC 8329: Framework for Interface to Network Security 1650 Functions - I2NSF Flow Security Policy Structure 1651 draft-ietf-i2nsf-capability-data-model-22: 1652 I2NSF Capability YANG Data Model - Design Principles and 1653 ECA Policy Model Overview 1654 draft-ietf-i2nsf-nsf-monitoring-data-model-13: I2NSF 1655 NSF Monitoring YANG Data Model - Alarms, Events, Logs, 1656 and Counters"; 1658 leaf-list system-event { 1659 type identityref { 1660 base system-event; 1661 } 1662 description 1663 "The security policy rule according to 1664 system events."; 1665 } 1667 leaf-list system-alarm { 1668 type identityref { 1669 base system-alarm; 1670 } 1671 description 1672 "The security policy rule according to 1673 system alarms."; 1674 } 1675 } 1676 } 1678 container condition { 1679 description 1680 "A condition is defined as a set 1681 of attributes, features, and/or values that are to be 1682 compared with a set of known attributes, features, 1683 and/or values in order to determine whether or not the 1684 set of Actions in that (imperative) I2NSF Policy Rule 1685 can be executed or not. Examples of I2NSF Conditions 1686 include matching attributes of a packet or flow, and 1687 comparing the internal state of an NSF to a desired 1688 state."; 1689 reference 1690 "RFC 8329: Framework for Interface to Network Security 1691 Functions - I2NSF Flow Security Policy Structure 1692 draft-ietf-i2nsf-capability-data-model-22: 1693 I2NSF Capability YANG Data Model - Design Principles and 1694 ECA Policy Model Overview"; 1696 leaf description { 1697 type string; 1698 description 1699 "Description for a condition clause."; 1700 } 1702 container ethernet { 1703 description 1704 "The purpose of this container is to represent layer 2 1705 packet header information to determine the set of policy 1706 actions in this ECA policy rule should be executed or 1707 not."; 1708 reference 1709 "IEEE 802.3: IEEE Standard for Ethernet"; 1711 leaf description { 1712 type string; 1713 description 1714 "The ethernet condition description"; 1715 } 1717 uses packet-fields:acl-eth-header-fields; 1718 } 1720 container ipv4 { 1721 description 1722 "The purpose of this container is to represent IPv4 1723 packet header information to determine if the set 1724 of policy actions in this ECA policy rule should be 1725 executed or not."; 1726 reference 1727 "RFC 791: Internet Protocol"; 1729 leaf description { 1730 type string; 1731 description 1732 "ipv4 condition textual description."; 1733 } 1735 uses packet-fields:acl-ip-header-fields; 1736 uses packet-fields:acl-ipv4-header-fields; 1737 } 1739 container ipv6 { 1740 description 1741 "The purpose of this container is to represent 1742 IPv6 packet header information to determine 1743 if the set of policy actions in this ECA policy 1744 rule should be executed or not."; 1745 reference 1746 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1747 Specification"; 1749 leaf description { 1750 type string; 1751 description 1752 "This is description for ipv6 condition."; 1753 } 1755 uses packet-fields:acl-ip-header-fields; 1756 uses packet-fields:acl-ipv6-header-fields; 1757 } 1759 container tcp { 1760 description 1761 "The purpose of this container is to represent 1762 TCP packet header information to determine 1763 if the set of policy actions in this ECA policy 1764 rule should be executed or not."; 1765 reference 1766 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 1767 Protocol (TCP) Specification"; 1769 leaf description { 1770 type string; 1771 description 1772 "This is description for tcp condition."; 1773 } 1775 container source-port-number { 1776 choice source-port { 1777 case range-or-operator { 1778 uses packet-fields:port-range-or-operator; 1779 description 1780 "Source port definition from range or operator. 1781 Can be used when a single port range to be 1782 specified."; 1783 } 1784 case port-list { 1785 list port-numbers { 1786 key "start"; 1787 uses port-range; 1788 description 1789 "List of source port numbers."; 1790 } 1791 description 1792 "Source port definition from list of port numbers. 1794 In the case of multiple port ranges needed to be 1795 specified."; 1796 } 1797 description 1798 "The choice of source port definition using 1799 range/operator or a choice to use list of port 1800 numbers."; 1801 } 1802 description 1803 "The security policy rule according to 1804 tcp source port number."; 1805 reference 1806 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 1807 Protocol (TCP) Specification - Port Number"; 1808 } 1810 container destination-port-number { 1811 choice destination-port { 1812 case range-or-operator { 1813 uses packet-fields:port-range-or-operator; 1814 description 1815 "Destination port definition from range or 1816 operator. 1817 Can be used when a single port range to be 1818 specified."; 1819 } 1820 case port-list { 1821 list port-numbers { 1822 key "start"; 1823 uses port-range; 1824 description 1825 "List of destination port numbers."; 1826 } 1827 description 1828 "Destination port definition from list of port 1829 numbers. 1830 In the case of multiple port ranges needed to be 1831 specified."; 1832 } 1833 description 1834 "The choice of destination port definition using 1835 range/operator or a choice to use list of port 1836 numbers."; 1837 } 1838 description 1839 "The security policy rule according to 1840 tcp destination port number."; 1841 reference 1842 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 1843 Protocol (TCP) Specification - Port Number"; 1844 } 1846 uses packet-fields:acl-tcp-header-fields; 1848 } 1850 container udp { 1851 description 1852 "The purpose of this container is to represent 1853 UDP packet header information to determine 1854 if the set of policy actions in this ECA policy 1855 rule should be executed or not."; 1856 reference 1857 "RFC 768: User Datagram Protocol"; 1859 leaf description { 1860 type string; 1861 description 1862 "This is description for udp condition."; 1863 } 1865 container source-port-number { 1866 choice source-port { 1867 case range-or-operator { 1868 uses packet-fields:port-range-or-operator; 1869 description 1870 "Source port definition from range or operator. 1871 Can be used when a single port range to be 1872 specified."; 1873 } 1874 case port-list { 1875 list port-numbers { 1876 key "start"; 1877 uses port-range; 1878 description 1879 "List of source port numbers."; 1880 } 1881 description 1882 "Source port definition from list of port numbers. 1883 In the case of multiple port ranges needed to be 1884 specified."; 1885 } 1886 description 1887 "The choice of source port definition using 1888 range/operator or a choice to use list of port 1889 numbers."; 1891 } 1892 description 1893 "The security policy rule according to 1894 udp source port number."; 1895 reference 1896 "RFC 768: User Datagram Protocol - Port Number"; 1897 } 1899 container destination-port-number { 1900 choice destination-port { 1901 case range-or-operator { 1902 uses packet-fields:port-range-or-operator; 1903 description 1904 "Destination port definition from range or 1905 operator. 1906 Can be used when a single port range to be 1907 specified."; 1908 } 1909 case port-list { 1910 list port-numbers { 1911 key "start"; 1912 uses port-range; 1913 description 1914 "List of destination port numbers."; 1915 } 1916 description 1917 "Destination port definition from list of port 1918 numbers. 1919 In the case of multiple port ranges needed to be 1920 specified."; 1921 } 1922 description 1923 "The choice of destination port definition using 1924 range/operator or a choice to use list of port 1925 numbers."; 1926 } 1927 description 1928 "The security policy rule according to 1929 udp destination port number."; 1930 reference 1931 "RFC 768: User Datagram Protocol - Port Number"; 1932 } 1934 uses packet-fields:acl-udp-header-fields; 1935 } 1937 container sctp { 1938 description 1939 "The purpose of this container is to represent 1940 SCTP packet header information to determine 1941 if the set of policy actions in this ECA policy 1942 rule should be executed or not."; 1944 leaf description { 1945 type string; 1946 description 1947 "This is description for sctp condition."; 1948 } 1950 container source-port-number { 1951 choice source-port { 1952 case range-or-operator { 1953 uses packet-fields:port-range-or-operator; 1954 description 1955 "Source port definition from range or operator. 1956 Can be used when a single port range to be 1957 specified."; 1958 } 1959 case port-list { 1960 list port-numbers { 1961 key "start"; 1962 uses port-range; 1963 description 1964 "List of source port numbers."; 1965 } 1966 description 1967 "Source port definition from list of port numbers. 1968 In the case of multiple port ranges needed to be 1969 specified."; 1970 } 1971 description 1972 "The choice of source port definition using 1973 range/operator or a choice to use list of port 1974 numbers."; 1975 } 1976 description 1977 "The security policy rule according to 1978 sctp source port number."; 1979 reference 1980 "RFC 4960: Stream Control Transmission Protocol 1981 - Port number"; 1982 } 1984 container destination-port-number { 1985 choice destination-port { 1986 case range-or-operator { 1987 uses packet-fields:port-range-or-operator; 1988 description 1989 "Destination port definition from range or 1990 operator. 1991 Can be used when a single port range to be 1992 specified."; 1993 } 1994 case port-list { 1995 list port-numbers { 1996 key "start"; 1997 uses port-range; 1998 description 1999 "List of destination port numbers."; 2000 } 2001 description 2002 "Destination port definition from list of port 2003 numbers. 2004 In the case of multiple port ranges needed to be 2005 specified."; 2006 } 2007 description 2008 "The choice of destination port definition using 2009 range/operator or a choice to use list of port 2010 numbers."; 2011 } 2012 description 2013 "The security policy rule according to 2014 sctp destination port number."; 2015 reference 2016 "RFC 4960: Stream Control Transmission Protocol 2017 - Port Number"; 2018 } 2020 leaf-list chunk-type { 2021 type uint8; 2022 description 2023 "The security policy rule according to 2024 sctp chunk type ID Value."; 2025 reference 2026 "RFC 4960: Stream Control Transmission Protocol 2027 - Chunk Type"; 2028 } 2029 } 2031 container dccp { 2032 description 2033 "The purpose of this container is to represent 2034 DCCP packet header information to determine 2035 if the set of policy actions in this ECA policy 2036 rule should be executed or not."; 2037 leaf description { 2038 type string; 2039 description 2040 "This is description for dccp condition."; 2041 } 2043 container source-port-number { 2044 choice source-port { 2045 case range-or-operator { 2046 uses packet-fields:port-range-or-operator; 2047 description 2048 "Source port definition from range or operator. 2049 Can be used when a single port range to be 2050 specified."; 2051 } 2052 case port-list { 2053 list port-numbers { 2054 key "start"; 2055 uses port-range; 2056 description 2057 "List of source port numbers."; 2058 } 2059 description 2060 "Source port definition from list of port numbers. 2061 In the case of multiple port ranges needed to be 2062 specified."; 2063 } 2064 description 2065 "The choice of source port definition using 2066 range/operator or a choice to use list of port 2067 numbers."; 2068 } 2069 description 2070 "The security policy rule according to 2071 dccp source port number."; 2072 reference 2073 "RFC 4340: Datagram Congestion Control Protocol (DCCP) 2074 - Port number"; 2075 } 2077 container destination-port-number { 2078 choice destination-port { 2079 case range-or-operator { 2080 uses packet-fields:port-range-or-operator; 2081 description 2082 "Destination port definition from range or 2083 operator. 2084 Can be used when a single port range to be 2085 specified."; 2086 } 2087 case port-list { 2088 list port-numbers { 2089 key "start"; 2090 uses port-range; 2091 description 2092 "List of destination port numbers."; 2093 } 2094 description 2095 "Destination port definition from list of port 2096 numbers. 2097 In the case of multiple port ranges needed to be 2098 specified."; 2099 } 2100 description 2101 "The choice of destination port definition using 2102 range/operator or a choice to use list of port 2103 numbers."; 2104 } 2105 description 2106 "The security policy rule according to 2107 dccp destination port number."; 2108 reference 2109 "RFC 4340: Datagram Congestion Control Protocol (DCCP) 2110 - Port number"; 2111 } 2113 leaf-list service-code { 2114 type uint32; 2115 description 2116 "The security policy rule according to 2117 dccp service code."; 2118 reference 2119 "RFC 4340: Datagram Congestion Control Protocol (DCCP) 2120 - Service Codes 2121 RFC 5595: The Datagram Congestion Control Protocol 2122 (DCCP) Service Codes 2123 RFC 6335: Internet Assigned Numbers Authority (IANA) 2124 Procedures for the Management of the Service 2125 Name and Transport Protocol Port Number 2126 Registry - Service Code"; 2127 } 2129 leaf-list type { 2130 type uint8 { 2131 range "0..15"; 2132 } 2133 description 2134 "The security policy rule according to the 4 bits of 2135 dccp type header field for dccp packet types such as 2136 DCCP-Request, DCCP-Response, DCCP-Data, DCCP-Ack, and 2137 DCCP-DataAck."; 2138 reference 2139 "RFC 4340: Datagram Congestion Control Protocol (DCCP) 2140 - Packet Types"; 2141 } 2142 } 2144 list icmp { 2145 key "version"; 2146 description 2147 "The purpose of this container is to represent 2148 ICMP packet header information to determine 2149 if the set of policy actions in this ECA policy 2150 rule should be executed or not."; 2151 reference 2152 "RFC 792: Internet Control Message Protocol 2153 RFC 8335: PROBE: A Utility for Probing Interfaces"; 2155 leaf description { 2156 type string; 2157 description 2158 "This is description for icmp condition."; 2159 } 2161 leaf version { 2162 type enumeration { 2163 enum icmpv4 { 2164 value "1"; 2165 description 2166 "The ICMPv4 Protocol as defined in RFC 792"; 2167 } 2168 enum icmpv6 { 2169 value "2"; 2170 description 2171 "The ICMPv6 Protocol as defined in RFC 4443"; 2172 } 2173 } 2174 description 2175 "The ICMP version to be matched. This value 2176 affected the type and code values."; 2177 reference 2178 "RFC 792: Internet Control Message Protocol 2179 RFC 4443: Internet Control Message Protocol (ICMPv6) 2180 for the Internet Protocol Version 6 (IPv6) 2181 Specification"; 2182 } 2184 uses packet-fields:acl-icmp-header-fields; 2185 } 2187 container url-category { 2188 description 2189 "Condition for url category"; 2190 leaf description { 2191 type string; 2192 description 2193 "This is description for the condition of a URL's 2194 category such as SNS sites, game sites, ecommerce 2195 sites, company sites, and university sites."; 2196 } 2198 leaf-list pre-defined { 2199 type string; 2200 description 2201 "This is pre-defined-category. To specify the name of 2202 URL database."; 2203 } 2204 leaf-list user-defined { 2205 type string; 2206 description 2207 "This user-defined-category. To allow a users manual 2208 addition of URLs for URL filtering."; 2209 } 2210 } 2212 container voice { 2213 description 2214 "For the VoIP/VoLTE security system, a VoIP/ 2215 VoLTE security system can monitor each 2216 VoIP/VoLTE flow and manage VoIP/VoLTE 2217 security rules controlled by a centralized 2218 server for VoIP/VoLTE security service 2219 (called VoIP IPS). The VoIP/VoLTE security 2220 system controls each switch for the 2221 VoIP/VoLTE call flow management by 2222 manipulating the rules that can be added, 2223 deleted, or modified dynamically."; 2224 reference 2225 "RFC 3261: SIP: Session Initiation Protocol"; 2227 leaf description { 2228 type string; 2229 description 2230 "This is description for voice condition."; 2231 } 2233 leaf-list source-voice-id { 2234 type string; 2235 description 2236 "The security policy rule according to 2237 a source voice ID for VoIP and VoLTE."; 2238 } 2240 leaf-list destination-voice-id { 2241 type string; 2242 description 2243 "The security policy rule according to 2244 a destination voice ID for VoIP and VoLTE."; 2245 } 2247 leaf-list user-agent { 2248 type string; 2249 description 2250 "The security policy rule according to 2251 an user agent for VoIP and VoLTE."; 2252 } 2253 } 2255 container ddos { 2256 description 2257 "Condition for DDoS attack."; 2259 leaf description { 2260 type string; 2261 description 2262 "This is description for ddos condition."; 2263 } 2265 leaf alert-packet-rate { 2266 type uint32; 2267 units "pps"; 2268 description 2269 "The alert rate of flood detection for 2270 packets per second (PPS) of an IP address. 2271 If the PPS of an IP address exceeds 2272 the alert rate threshold, an alert 2273 will be generated."; 2274 } 2275 leaf alert-flow-rate { 2276 type uint32; 2277 description 2278 "The alert rate of flood detection for 2279 flows per second of an IP address. 2280 If the flows per second of an IP address 2281 exceeds the alert rate threshold, an alert 2282 will be generated."; 2283 } 2285 leaf alert-byte-rate { 2286 type uint32; 2287 units "Bps"; 2288 description 2289 "The alert rate of flood detection for 2290 bytes per second (Bps) of an IP address. 2291 If the bytes per second of an IP address 2292 exceeds the alert rate threshold, an alert 2293 will be generated."; 2294 } 2295 } 2297 container anti-virus { 2298 description 2299 "Condition for antivirus"; 2301 leaf-list profile { 2302 type string; 2303 description 2304 "The security profile for antivirus. This is used to 2305 update the security profile for improving the 2306 security. The security profile is used to scan 2307 the viruses."; 2308 } 2310 leaf-list exception-files { 2311 type string; 2312 description 2313 "The type or name of the files to be excluded by the 2314 anti-virus. This can be used to keep the known 2315 harmless files."; 2316 } 2317 } 2319 container payload { 2320 description 2321 "Condition for packet payload"; 2322 leaf description { 2323 type string; 2324 description 2325 "This is description for payload condition."; 2326 } 2327 leaf-list content { 2328 type string; 2329 description 2330 "This is a condition for packet payload content."; 2331 } 2332 } 2334 container context { 2335 description 2336 "Condition for context"; 2337 leaf description { 2338 type string; 2339 description 2340 "This is description for context condition."; 2341 } 2343 container application { 2344 description 2345 "Condition for application"; 2346 leaf description { 2347 type string; 2348 description 2349 "This is description for application condition."; 2350 } 2351 leaf-list protocol { 2352 type identityref { 2353 base application-protocol; 2354 } 2355 description 2356 "The condition based on the application layer 2357 protocol"; 2358 } 2359 } 2361 container device-type { 2362 description 2363 "Condition for type of the destination device"; 2364 leaf description { 2365 type string; 2366 description 2367 "This is description for destination device type 2368 condition. Vendors can write instructions for the 2369 condition that vendor made"; 2370 } 2371 leaf-list device { 2372 type identityref { 2373 base device-type; 2374 } 2375 description 2376 "The device attribute that can identify a device, 2377 including the device type (i.e., router, switch, 2378 pc, ios, or android) and the device's owner as 2379 well."; 2380 } 2381 } 2383 container users { 2384 description 2385 "Condition for users"; 2386 leaf description { 2387 type string; 2388 description 2389 "This is the description for users' condition."; 2390 } 2391 list user { 2392 key "id"; 2393 description 2394 "The user with which the traffic flow is associated 2395 can be identified by either a user id or user name. 2396 The user-to-IP address mapping is assumed to be 2397 provided by the unified user management system via 2398 network."; 2399 leaf id { 2400 type uint32; 2401 description 2402 "The ID of the user."; 2403 } 2404 leaf name { 2405 type string; 2406 description 2407 "The name of the user."; 2408 } 2409 } 2410 list group { 2411 key "id"; 2412 description 2413 "The user group with which the traffic flow is 2414 associated can be identified by either a group id 2415 or group name. The group-to-IP address and 2416 user-to-group mappings are assumed to be provided by 2417 the unified user management system via network."; 2418 leaf id { 2419 type uint32; 2420 description 2421 "The ID of the group."; 2422 } 2423 leaf name { 2424 type string; 2425 description 2426 "The name of the group."; 2427 } 2428 } 2430 leaf security-group { 2431 type string; 2432 description 2433 "security-group."; 2434 } 2435 } 2437 container geographic-location { 2438 description 2439 "The location which network traffic flow is associated 2440 with. The region can be the geographic location such 2441 as country, province, and city, as well as the logical 2442 network location such as IP address, network section, 2443 and network domain."; 2444 reference 2445 "draft-ietf-netmod-geo-location-11: A YANG Grouping for 2446 Geographic Locations"; 2448 leaf description { 2449 type string; 2450 description 2451 "This is the description for the geographic location 2452 condition. It is used to describe the conditions and 2453 instructions that should be implemented."; 2454 } 2456 leaf-list source { 2457 type string; 2458 description 2459 "The source is a geographic location mapped into an 2460 IP address. It matches the mapped IP address to the 2461 source IP address of the traffic flow."; 2462 reference 2463 "ISO 3166: Codes for the representation of 2464 names of countries and their subdivisions 2465 draft-ietf-netmod-geo-location-11: A YANG Grouping 2466 for Geographic Locations"; 2468 } 2470 leaf-list destination { 2471 type string; 2472 description 2473 "The destination is a geographic location mapped into 2474 an IP address. It matches the mapped IP address to 2475 the destination IP address of the traffic flow."; 2476 reference 2477 "ISO 3166: Codes for the representation of 2478 names of countries and their subdivisions 2479 draft-ietf-netmod-geo-location-11: A YANG Grouping 2480 for Geographic Locations"; 2481 } 2482 } 2483 } 2484 } 2486 container action { 2487 description 2488 "An action is used to control and monitor aspects of 2489 flow-based NSFs when the event and condition clauses 2490 are satisfied. NSFs provide security functions by 2491 executing various Actions. Examples of I2NSF Actions 2492 include providing intrusion detection and/or protection, 2493 web and flow filtering, and deep packet inspection 2494 for packets and flows."; 2495 reference 2496 "RFC 8329: Framework for Interface to Network Security 2497 Functions - I2NSF Flow Security Policy Structure 2498 draft-ietf-i2nsf-capability-data-model-22: 2499 I2NSF Capability YANG Data Model - Design Principles and 2500 ECA Policy Model Overview"; 2502 leaf description { 2503 type string; 2504 description 2505 "Description for an action clause."; 2506 } 2508 container packet-action { 2509 description 2510 "Action for packets"; 2511 reference 2512 "RFC 8329: Framework for Interface to Network Security 2513 Functions - I2NSF Flow Security Policy Structure 2514 draft-ietf-i2nsf-capability-data-model-22: 2515 I2NSF Capability YANG Data Model - Design Principles and 2516 ECA Policy Model Overview"; 2518 leaf ingress-action { 2519 type identityref { 2520 base ingress-action; 2521 } 2522 description 2523 "Ingress Action: pass, drop, rate-limit, and 2524 mirror."; 2525 } 2527 leaf egress-action { 2528 type identityref { 2529 base egress-action; 2530 } 2531 description 2532 "Egress action: pass, drop, rate-limit, mirror, 2533 invoke-signaling, tunnel-encapsulation, forwarding, 2534 and redirection."; 2535 } 2537 leaf log-action { 2538 type identityref { 2539 base log-action; 2540 } 2541 description 2542 "Log action: rule log and session log"; 2543 } 2545 } 2547 container flow-action { 2548 description 2549 "Action for flows"; 2550 reference 2551 "RFC 8329: Framework for Interface to Network Security 2552 Functions - I2NSF Flow Security Policy Structure 2553 draft-ietf-i2nsf-capability-data-model-22: 2554 I2NSF Capability YANG Data Model - Design Principles and 2555 ECA Policy Model Overview"; 2557 leaf ingress-action { 2558 type identityref { 2559 base ingress-action; 2560 } 2561 description 2562 "Action: pass, drop, rate-limit, and mirror."; 2563 } 2564 leaf egress-action { 2565 type identityref { 2566 base egress-action; 2567 } 2568 description 2569 "Egress action: pass, drop, rate-limit, mirror, 2570 invoke-signaling, tunnel-encapsulation, forwarding, 2571 and redirection."; 2572 } 2574 leaf log-action { 2575 type identityref { 2576 base log-action; 2577 } 2578 description 2579 "Log action: rule log and session log"; 2580 } 2581 } 2583 container advanced-action { 2584 description 2585 "If the packet needs to be additionally inspected, 2586 the packet is passed to advanced network 2587 security functions according to the profile. 2588 The profile means the types of NSFs where the packet 2589 will be forwarded in order to additionally 2590 inspect the packet. 2591 The advanced action activates Service Function 2592 Chaining (SFC) for further inspection of a packet."; 2593 reference 2594 "draft-ietf-i2nsf-capability-data-model-22: 2595 I2NSF Capability YANG Data Model - YANG Tree 2596 Diagram"; 2598 leaf-list content-security-control { 2599 type identityref { 2600 base content-security-control; 2601 } 2602 description 2603 "Content-security-control is the NSFs that 2604 inspect the payload of the packet. 2605 The profile for the types of NSFs for mitigation is 2606 divided into content security control and 2607 attack-mitigation-control. 2608 Content security control: ips, url filtering, 2609 anti-virus, and voip-volte-filter. This can be 2610 extended according to the provided NSFs."; 2611 reference 2612 "draft-ietf-i2nsf-capability-data-model-22: 2613 I2NSF Capability YANG Data Model - YANG Tree Diagram"; 2614 } 2616 leaf-list attack-mitigation-control { 2617 type identityref { 2618 base attack-mitigation-control; 2619 } 2620 description 2621 "Attack-mitigation-control is the NSFs that weaken 2622 the attacks related to a denial of service 2623 and reconnaissance. 2624 The profile for the types of NSFs for mitigation is 2625 divided into content security control and 2626 attack-mitigation-control. 2627 Attack mitigation control: Anti-DDoS or DDoS 2628 mitigator. This can be extended according to the 2629 provided NSFs such as mitigators for ip sweep, 2630 port scanning, ping of death, teardrop, oversized 2631 icmp, and tracert."; 2632 reference 2633 "draft-ietf-i2nsf-capability-data-model-22: 2634 I2NSF Capability YANG Data Model - YANG Tree Diagram"; 2635 } 2636 } 2637 } 2638 } 2639 container rule-group { 2640 description 2641 "This is rule group"; 2643 list groups { 2644 key "name"; 2645 description 2646 "This is a group for rules"; 2648 leaf name { 2649 type string; 2650 description 2651 "This is the name of the group for rules"; 2652 } 2654 leaf-list rule-name { 2655 type leafref { 2656 path 2657 "../../../rules/name"; 2658 } 2659 description 2660 "The names of the rules to be grouped."; 2661 } 2663 leaf enable { 2664 type boolean; 2665 description 2666 "If true, the rule is enabled and enforced. 2667 If false, the rule is configured but disabled 2668 and not enforced."; 2669 } 2671 leaf description { 2672 type string; 2673 description 2674 "This is a description for rule-group"; 2675 } 2676 } 2677 } 2678 } 2679 } 2680 2682 Figure 5: YANG Data Module of I2NSF NSF-Facing-Interface 2684 5. XML Configuration Examples of Low-Level Security Policy Rules 2686 This section shows XML configuration examples of low-level security 2687 policy rules that are delivered from the Security Controller to NSFs 2688 over the NSF-Facing Interface. For security requirements, we assume 2689 that the NSFs (i.e., General firewall, Time-based firewall, URL 2690 filter, VoIP/VoLTE filter, and http and https flood mitigation) 2691 described in Appendix A of [I-D.ietf-i2nsf-capability-data-model] are 2692 registered with the I2NSF framework. With the registered NSFs, we 2693 show configuration examples for security policy rules of network 2694 security functions according to the following three security 2695 requirements: (i) Block Social Networking Service (SNS) access during 2696 business hours, (ii) Block malicious VoIP/VoLTE packets coming to the 2697 company, and (iii) Mitigate http and https flood attacks on company 2698 web server. 2700 5.1. Example Security Requirement 1: Block Social Networking Service 2701 (SNS) Access during Business Hours 2703 This section shows a configuration example for blocking SNS access 2704 during business hours in IPv4 networks or IPv6 networks. 2706 2708 sns_access 2709 2710 block_sns_access_during_operation_time 2711 2712 2726 2727 2728 2729 192.0.2.0/24 2730 2731 2732 2733 2734 2735 url-filtering 2736 2737 2738 2739 2740 2742 Figure 6: Configuration XML for Time-based Firewall to Block SNS 2743 Access during Business Hours in IPv4 Networks 2745 2747 sns_access 2748 2749 block_sns_access_during_operation_time 2750 2751 2765 2766 2767 2768 2001:db8:0:1::0/120 2769 2770 2771 2772 2773 2774 url-filtering 2775 2776 2777 2778 2779 2781 Figure 7: Configuration XML for Time-based Firewall to Block SNS 2782 Access during Business Hours in IPv6 Networks 2784 2786 sns_access 2787 2788 block_sns_access_during_operation_time 2789 2790 2791 SNS_1 2792 SNS_2 2793 2794 2795 2796 2797 drop 2798 2799 2800 2801 2803 Figure 8: Configuration XML for Web Filter to Block SNS Access 2804 during Business Hours 2806 Figure 6 (or Figure 7) and Figure 8 show the configuration XML 2807 documents for time-based firewall and web filter to block SNS access 2808 during business hours in IPv4 networks (or IPv6 networks). For the 2809 security requirement, two NSFs (i.e., a time-based firewall and a web 2810 filter) were used because one NSF cannot meet the security 2811 requirement. The instances of XML documents for the time-based 2812 firewall and the web filter are as follows: Note that a detailed data 2813 model for the configuration of the advanced network security function 2814 (i.e., web filter) can be defined as an extension in future. 2816 Time-based Firewall is as follows: 2818 1. The name of the security policy is sns_access. 2820 2. The name of the rule is block_sns_access_during_operation_time. 2822 3. The rule is started from 2021-03-11 at 9 a.m. to 2021-12-31 at 6 2823 p.m. 2825 4. The rule is operated weekly every weekday (i.e., Monday, Tuesday, 2826 Wednesday, Thursday, and Friday) during the business hours (i.e., 2827 from 9 a.m. to 6 p.m.) . 2829 5. The rule inspects a source IPv4 address (i.e., 192.0.2.0/24). 2830 For the case of IPv6 networks, the rule inspects a source IPv6 2831 address (i.e., from 2001:db8:0:1::0/120). 2833 6. If the outgoing packets match the rules above, the time-based 2834 firewall sends the packets to url filtering for additional 2835 inspection because the time-based firewall can not inspect 2836 contents of the packets for the SNS URL. 2838 Web Filter is as follows: 2840 1. The name of the security policy is sns_access. 2842 2. The name of the rule is block_SNS_1_and_SNS_2. 2844 3. The rule inspects URL address to block the access packets to the 2845 SNS_1 or the SNS_2. 2847 4. If the outgoing packets match the rules above, the packets are 2848 blocked. 2850 5.2. Example Security Requirement 2: Block Malicious VoIP/VoLTE Packets 2851 Coming to a Company 2853 This section shows a configuration example for blocking malicious 2854 VoIP/VoLTE packets coming to a company. 2856 2858 voip_volte_inspection 2859 2860 block_malicious_voice_id 2861 2862 2863 192.0.2.0/24 2864 2865 2866 2867 5060 2868 5061 2869 2870 2871 2872 2873 2874 2875 voip-volte-filter 2876 2877 2878 2879 2880 2881 Figure 9: Configuration XML for General Firewall to Block 2882 Malicious VoIP/VoLTE Packets Coming to a Company 2884 2886 voip_volte_inspection 2887 2888 block_malicious_voice_id 2889 2890 2891 2892 user1@voip.malicious.example.com 2893 2894 2895 user2@voip.malicious.example.com 2896 2897 2898 2899 2900 2901 drop 2902 2903 2904 2905 2907 Figure 10: Configuration XML for VoIP/VoLTE Filter to Block 2908 Malicious VoIP/VoLTE Packets Coming to a Company 2910 Figure 9 and Figure 10 show the configuration XML documents for 2911 general firewall and VoIP/VoLTE filter to block malicious VoIP/VoLTE 2912 packets coming to a company. For the security requirement, two NSFs 2913 (i.e., a general firewall and a VoIP/VoLTE filter) were used because 2914 one NSF can not meet the security requirement. The instances of XML 2915 documents for the general firewall and the VoIP/VoLTE filter are as 2916 follows: Note that a detailed data model for the configuration of the 2917 advanced network security function (i.e., VoIP/VoLTE filter) can be 2918 described as an extension in future. 2920 General Firewall is as follows: 2922 1. The name of the security policy is voip_volte_inspection. 2924 2. The name of the rule is block_malicious_voip_volte_packets. 2926 3. The rule inspects a destination IPv4 address (i.e., from 2927 192.0.2.0/24). 2929 4. The rule inspects a port number (i.e., 5060 and 5061) to inspect 2930 VoIP/VoLTE packet. 2932 5. If the incoming packets match the rules above, the general 2933 firewall sends the packets to VoIP/VoLTE filter for additional 2934 inspection because the general firewall can not inspect contents 2935 of the VoIP/VoLTE packets. 2937 VoIP/VoLTE Filter is as follows: 2939 1. The name of the security policy is malicious_voice_id. 2941 2. The name of the rule is block_malicious_voice_id. 2943 3. The rule inspects the voice id of the VoIP/VoLTE packets to block 2944 the malicious VoIP/VoLTE packets (i.e., 2945 user1@voip.malicious.example.com and 2946 user2@voip.malicious.example.com). 2948 4. If the incoming packets match the rules above, the packets are 2949 blocked. 2951 5.3. Example Security Requirement 3: Mitigate HTTP and HTTPS Flood 2952 Attacks on a Company Web Server 2954 This section shows a configuration example for mitigating http and 2955 https flood attacks on a company web server. 2957 2959 flood_attack_mitigation 2960 2961 mitigate_http_and_https_flood_attack 2962 2963 2964 192.0.2.0/24 2965 2966 2967 2968 2969 80 2970 80 2971 2972 2973 443 2974 443 2975 2976 2977 2978 2979 2980 2981 2982 anti-ddos 2983 2984 2985 2986 2987 2989 Figure 11: Configuration XML for General Firewall to Mitigate 2990 HTTP and HTTPS Flood Attacks on a Company Web Server 2992 2994 flood_attack_mitigation 2995 2996 mitigate_http_and_https_flood_attack 2997 2998 2999 1000 3000 3001 3002 3003 3004 drop 3005 3006 3007 3008 3010 Figure 12: Configuration XML for Anti-DDoS to Mitigate HTTP and 3011 HTTPS Flood Attacks on a Company Web Server 3013 Figure 11 and Figure 12 show the configuration XML documents for 3014 general firewall and http and https flood attack mitigation to 3015 mitigate http and https flood attacks on a company web server. For 3016 the security requirement, two NSFs (i.e., a general firewall and a 3017 http and https flood attack mitigation) were used because one NSF can 3018 not meet the security requirement. The instances of XML documents 3019 for the general firewall and http and https flood attack mitigation 3020 are as follows: Note that a detailed data model for the configuration 3021 of the advanced network security function (i.e., http and https flood 3022 attack mitigation) can be defined as an extension in future. 3024 General Firewall is as follows: 3026 1. The name of the security policy is flood_attack_mitigation. 3028 2. The name of the rule is mitigate_http_and_https_flood_attack. 3030 3. The rule inspects a destination IPv4 address (i.e., 192.0.2.0/24) 3031 to inspect the access packets coming into the company web server. 3033 4. The rule inspects a port number (i.e., 80 and 443) to inspect 3034 http and https packet. 3036 5. If the packets match the rules above, the general firewall sends 3037 the packets to anti-DDoS for additional inspection because the 3038 general firewall can not control the amount of packets for http 3039 and https packets. 3041 Anti DDoS for HTTP and HTTPS Flood Attack Mitigation is as follows: 3043 1. The name of the security policy is flood_attack_mitigation. 3045 2. The name of the rule is mitigate_http_and_https_flood_attack. 3047 3. The rule controls the http and https packets according to the 3048 amount of incoming packets (1000 packets per second). 3050 4. If the incoming packets match the rules above, the packets are 3051 blocked. 3053 6. IANA Considerations 3055 This document requests IANA to register the following URI in the 3056 "IETF XML Registry" [RFC3688]: 3058 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf 3059 Registrant Contact: The IESG. 3060 XML: N/A; the requested URI is an XML namespace. 3062 This document requests IANA to register the following YANG module in 3063 the "YANG Module Names" registry [RFC7950][RFC8525]: 3065 name: ietf-i2nsf-policy-rule-for-nsf 3066 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf 3067 prefix: nsfintf 3068 reference: RFC XXXX 3070 7. Security Considerations 3072 The YANG module specified in this document defines a data schema 3073 designed to be accessed through network management protocols such as 3074 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 3075 the secure transport layer, and the required secure transport is 3076 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 3077 and the required secure transport is TLS [RFC8446]. 3079 The NETCONF access control model [RFC8341] provides a means of 3080 restricting access to specific NETCONF or RESTCONF users to a 3081 preconfigured subset of all available NETCONF or RESTCONF protocol 3082 operations and content. 3084 There are a number of data nodes defined in this YANG module that are 3085 writable/creatable/deletable (i.e., config true, which is the 3086 default). These data nodes may be considered sensitive or vulnerable 3087 in some network environments. Write operations (e.g., edit-config) 3088 to these data nodes without proper protection can have a negative 3089 effect on network operations. These are the subtrees and data nodes 3090 and their sensitivity/vulnerability: 3092 * ietf-i2nsf-policy-rule-for-nsf: Writing to almost any element of 3093 this YANG module would directly impact on the configuration of 3094 NSFs, e.g., completely turning off security monitoring and 3095 mitigation capabilities; altering the scope of this monitoring and 3096 mitigation; creating an overwhelming logging volume to overwhelm 3097 downstream analytics or storage capacity; creating logging 3098 patterns which are confusing; or rendering useless trained 3099 statistics or artificial intelligence models. 3101 Some of the readable data nodes in this YANG module may be considered 3102 sensitive or vulnerable in some network environments. It is thus 3103 important to control read access (e.g., via get, get-config, or 3104 notification) to these data nodes. These are the subtrees and data 3105 nodes and their sensitivity/vulnerability: 3107 * ietf-i2nsf-policy-rule-for-nsf: The attacker may gather the 3108 security policy information of any target NSFs and misuse the 3109 security policy information for subsequent attacks. 3111 Policy rules identifying the specified users and user groups can be 3112 specified with "rules/condition/context/users". As with other data 3113 in this YANG module, this user information is provided by the 3114 Security Controller to the NSFs and is protected via the transport 3115 and access control mechanisms described above. 3117 8. Acknowledgments 3119 This work was supported by Institute of Information & Communications 3120 Technology Planning & Evaluation (IITP) grant funded by the Korea 3121 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 3122 Security Intelligence Technology Development for the Customized 3123 Security Service Provisioning). This work was supported in part by 3124 the IITP (2020-0-00395, Standard Development of Blockchain based 3125 Network Management Automation Technology). 3127 9. Contributors 3129 This document is made by the group effort of I2NSF working group. 3130 Many people actively contributed to this document, such as Acee 3131 Lindem and Roman Danyliw. The authors sincerely appreciate their 3132 contributions. 3134 The following are co-authors of this document: 3136 Patrick Lingga Department of Electrical and Computer Engineering 3137 Sungkyunkwan University 2066 Seobu-ro Jangan-gu Suwon, Gyeonggi-do 3138 16419 Republic of Korea EMail: patricklink@skku.edu 3140 Hyoungshick Kim Department of Computer Science and Engineering 3141 Sungkyunkwan University 2066 Seobu-ro Jangan-gu Suwon, Gyeonggi-do 3142 16419 Republic of Korea EMail: hyoung@skku.edu 3144 Daeyoung Hyun Department of Computer Science and Engineering 3145 Sungkyunkwan University 2066 Seobu-ro Jangan-gu Suwon, Gyeonggi-do 3146 16419 Republic of Korea EMail: dyhyun@skku.edu 3148 Dongjin Hong Department of Electronic, Electrical and Computer 3149 Engineering Sungkyunkwan University 2066 Seobu-ro Jangan-gu Suwon, 3150 Gyeonggi-do 16419 Republic of Korea EMail: dong.jin@skku.edu 3152 Liang Xia Huawei 101 Software Avenue Nanjing, Jiangsu 210012 China 3153 EMail: Frank.Xialiang@huawei.com 3155 Tae-Jin Ahn Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 3156 Republic of Korea EMail: taejin.ahn@kt.com 3158 Se-Hui Lee Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 3159 Republic of Korea EMail: sehuilee@kt.com 3161 10. References 3163 10.1. Normative References 3165 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3166 DOI 10.17487/RFC0768, August 1980, 3167 . 3169 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3170 DOI 10.17487/RFC0791, September 1981, 3171 . 3173 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3174 RFC 792, DOI 10.17487/RFC0792, September 1981, 3175 . 3177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3178 Requirement Levels", BCP 14, RFC 2119, 3179 DOI 10.17487/RFC2119, March 1997, 3180 . 3182 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3183 A., Peterson, J., Sparks, R., Handley, M., and E. 3184 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3185 DOI 10.17487/RFC3261, June 2002, 3186 . 3188 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3189 DOI 10.17487/RFC3688, January 2004, 3190 . 3192 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3193 Congestion Control Protocol (DCCP)", RFC 4340, 3194 DOI 10.17487/RFC4340, March 2006, 3195 . 3197 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3198 Control Message Protocol (ICMPv6) for the Internet 3199 Protocol Version 6 (IPv6) Specification", STD 89, 3200 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3201 . 3203 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 3204 RFC 4960, DOI 10.17487/RFC4960, September 2007, 3205 . 3207 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 3208 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 3209 September 2009, . 3211 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3212 the Network Configuration Protocol (NETCONF)", RFC 6020, 3213 DOI 10.17487/RFC6020, October 2010, 3214 . 3216 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3217 and A. Bierman, Ed., "Network Configuration Protocol 3218 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3219 . 3221 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3222 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 3223 . 3225 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 3226 Cheshire, "Internet Assigned Numbers Authority (IANA) 3227 Procedures for the Management of the Service Name and 3228 Transport Protocol Port Number Registry", BCP 165, 3229 RFC 6335, DOI 10.17487/RFC6335, August 2011, 3230 . 3232 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3233 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3234 . 3236 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3237 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3238 . 3240 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3241 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3242 . 3244 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 3245 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 3246 the Constrained Application Protocol (CoAP)", RFC 8075, 3247 DOI 10.17487/RFC8075, February 2017, 3248 . 3250 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3251 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3252 May 2017, . 3254 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3255 (IPv6) Specification", STD 86, RFC 8200, 3256 DOI 10.17487/RFC8200, July 2017, 3257 . 3259 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 3260 Boucadair, "PROBE: A Utility for Probing Interfaces", 3261 RFC 8335, DOI 10.17487/RFC8335, February 2018, 3262 . 3264 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3265 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3266 . 3268 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 3269 Access Control Model", STD 91, RFC 8341, 3270 DOI 10.17487/RFC8341, March 2018, 3271 . 3273 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 3274 Documents Containing YANG Data Models", BCP 216, RFC 8407, 3275 DOI 10.17487/RFC8407, October 2018, 3276 . 3278 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3279 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3280 . 3282 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 3283 "YANG Data Model for Network Access Control Lists (ACLs)", 3284 RFC 8519, DOI 10.17487/RFC8519, March 2019, 3285 . 3287 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 3288 and R. Wilton, "YANG Library", RFC 8525, 3289 DOI 10.17487/RFC8525, March 2019, 3290 . 3292 [I-D.ietf-tcpm-rfc793bis] 3293 Eddy, W. M., "Transmission Control Protocol (TCP) 3294 Specification", Work in Progress, Internet-Draft, draft- 3295 ietf-tcpm-rfc793bis-25, 7 September 2021, 3296 . 3299 [I-D.ietf-i2nsf-capability-data-model] 3300 Hares, S., Jeong, J. (., Kim, J. (., Moskowitz, R., and Q. 3301 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 3302 Internet-Draft, draft-ietf-i2nsf-capability-data-model-22, 3303 22 January 2022, . 3306 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 3307 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 3308 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 3309 Model", Work in Progress, Internet-Draft, draft-ietf- 3310 i2nsf-nsf-monitoring-data-model-12, 17 November 2021, 3311 . 3314 [I-D.ietf-netmod-geo-location] 3315 Hopps, C., "A YANG Grouping for Geographic Locations", 3316 Work in Progress, Internet-Draft, draft-ietf-netmod-geo- 3317 location-11, 24 October 2021, 3318 . 3321 10.2. Informative References 3323 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 3324 Denial-of-Service Considerations", RFC 4732, 3325 DOI 10.17487/RFC4732, December 2006, 3326 . 3328 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 3329 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 3330 . 3332 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 3333 Kumar, "Framework for Interface to Network Security 3334 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 3335 . 3337 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 3338 Jeong, J. (., Chung, C., Ahn, T., Kumar, R., and S. Hares, 3339 "I2NSF Consumer-Facing Interface YANG Data Model", Work in 3340 Progress, Internet-Draft, draft-ietf-i2nsf-consumer- 3341 facing-interface-dm-15, 15 September 2021, 3342 . 3345 [ISO-3166] "Codes for the representation of names of countries and 3346 their subdivisions", ISO 3166, September 2018, 3347 . 3349 [IEEE-802.3] 3350 Institute of Electrical and Electronics Engineers, "IEEE 3351 Standard for Ethernet", 2018, 3352 . 3354 Authors' Addresses 3356 Jinyong (Tim) Kim (editor) 3357 Department of Electronic, Electrical and Computer Engineering 3358 Sungkyunkwan University 3359 2066 Seobu-Ro, Jangan-Gu 3360 Suwon 3361 Gyeonggi-Do 3362 16419 3363 Republic of Korea 3365 Phone: +82 10 8273 0930 3366 Email: timkim@skku.edu 3367 Jaehoon (Paul) Jeong (editor) 3368 Department of Computer Science and Engineering 3369 Sungkyunkwan University 3370 2066 Seobu-Ro, Jangan-Gu 3371 Suwon 3372 Gyeonggi-Do 3373 16419 3374 Republic of Korea 3376 Phone: +82 31 299 4957 3377 Email: pauljeong@skku.edu 3378 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3380 Jung-Soo Park 3381 Electronics and Telecommunications Research Institute 3382 218 Gajeong-Ro, Yuseong-Gu 3383 Daejeon 3384 34129 3385 Republic of Korea 3387 Phone: +82 42 860 6514 3388 Email: pjs@etri.re.kr 3390 Susan Hares 3391 Huawei 3392 7453 Hickory Hill 3393 Saline, MI 48176 3394 United States of America 3396 Phone: +1-734-604-0332 3397 Email: shares@ndzh.com 3399 Qiushi Lin 3400 Huawei 3401 Huawei Industrial Base 3402 Shenzhen 3403 Guangdong 518129, 3404 China 3406 Email: linqiushi@huawei.com