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