idnits 2.17.1 draft-ietf-i2nsf-nsf-facing-interface-dm-29.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 280 has weird spacing: '...w start ine...' == Line 287 has weird spacing: '...w start ine...' == Line 303 has weird spacing: '...w start ine...' == Line 310 has weird spacing: '...w start ine...' == Line 322 has weird spacing: '...er-port inet:...' == (24 more instances...) -- The document date (1 June 2022) is 688 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) == Missing Reference: '0-9' is mentioned on line 3706, but not defined == Missing Reference: 'A-Za-z0-9' is mentioned on line 3706, but not defined ** Downref: Normative reference to an Informational RFC: RFC 8329 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-messaging' -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-semantics' == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-19 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-tcpm-rfc793bis' == Outdated reference: A later version (-31) exists of draft-ietf-i2nsf-consumer-facing-interface-dm-20 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 4 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: 3 December 2022 J. Park 6 ETRI 7 S. Hares 8 Q. Lin 9 Huawei 10 1 June 2022 12 I2NSF Network Security Function-Facing Interface YANG Data Model 13 draft-ietf-i2nsf-nsf-facing-interface-dm-29 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 is for the NSF-Facing Interface between a Security 21 Controller and NSFs in the I2NSF framework. It is built on the basis 22 of the YANG data model in the I2NSF Capability YANG Data Model 23 document for the I2NSF framework. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 3 December 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. General I2NSF Security Policy Rule . . . . . . . . . . . 3 62 3.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 5 63 3.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 6 64 3.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 12 65 4. YANG Data Model of NSF-Facing Interface . . . . . . . . . . . 14 66 4.1. YANG Module of NSF-Facing Interface . . . . . . . . . . . 14 67 5. XML Configuration Examples of Low-Level Security Policy 68 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 62 69 5.1. Example Security Requirement 1: Block Social Networking 70 Service (SNS) Access during Business Hours . . . . . . . 62 71 5.2. Example Security Requirement 2: Block Malicious VoIP/VoCN 72 Packets Coming to a Company . . . . . . . . . . . . . . . 66 73 5.3. Example Security Requirement 3: Mitigate HTTP and HTTPS 74 Flood Attacks on a Company Web Server . . . . . . . . . . 69 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 72 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 73 79 8.2. Informative References . . . . . . . . . . . . . . . . . 78 80 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 79 81 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 79 82 Appendix C. Changes from 83 draft-ietf-i2nsf-nsf-facing-interface-dm-28 . . . . . . . 80 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 86 1. Introduction 88 This document defines a YANG [RFC6020][RFC7950] data model for 89 security policy rule configuration of Network Security Functions 90 (NSF). The YANG data model in this document is based on the data 91 model described in [I-D.ietf-i2nsf-capability-data-model] for the 92 NSF-Facing Interface in the Interface to Network Security Functions 93 (I2NSF) architecture [RFC8329]. The YANG data model in this document 94 focuses on security policy configuration for the NSFs discussed in 96 [I-D.ietf-i2nsf-capability-data-model], i.e., generic NSF (operate on 97 packet header for layer 2, layer3, and layer 4) and advanced NSF 98 (Intrusion Prevention System, URL-Filtering, anti-DDoS, Antivirus, 99 and VoIP/VoCN Filter). Note: VoIP is an abbreviation for Voice over 100 Internet Protocol and VoCN is an abbreviation for Voice over Cellular 101 Network, such as Voice over LTE or 5G. 103 This YANG data model uses an "Event-Condition-Action" (ECA) policy 104 model that is used as the basis for the design of I2NSF Policy 105 described in [RFC8329] and [I-D.ietf-i2nsf-capability-data-model]. 107 The "ietf-i2nsf-nsf-facing-interface" YANG module defined in this 108 document provides the configuration of the following features. 110 * A security policy rule of a network security function. 112 * An event clause of a generic network security function. 114 * A condition clause of a generic network security function. 116 * An action clause of a generic network security function. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 This document uses the terminology described in [RFC8329]. 128 This document follows the guidelines of [RFC8407], uses the common 129 YANG types defined in [RFC6991], and adopts the Network Management 130 Datastore Architecture (NMDA) [RFC8342]. The meaning of the symbols 131 in tree diagrams is defined in [RFC8340]. 133 3. YANG Tree Diagram 135 This section shows a YANG tree diagram of policy for network security 136 functions. 138 3.1. General I2NSF Security Policy Rule 140 This section shows a YANG tree diagram for a general I2NSF security 141 policy rule for generic network security functions. 143 module: ietf-i2nsf-nsf-facing-interface 144 +--rw i2nsf-security-policy* [name] 145 +--rw name string 146 +--rw language? string 147 +--rw priority-usage? identityref 148 +--rw resolution-strategy? identityref 149 +--rw default-action? identityref 150 +--rw rules* [name] 151 | +--rw name string 152 | +--rw description? string 153 | +--rw priority? uint8 154 | +--rw enable? boolean 155 | +--rw long-connection 156 | | +--rw enable? boolean 157 | | +--rw duration? uint32 158 | +--rw event 159 | | ... 160 | +--rw condition 161 | | ... 162 | +--rw action 163 | ... 164 +--rw rule-group 165 +--rw groups* [group-name] 166 +--rw group-name string 167 +--rw rule-name* -> ../../../rules/name 168 +--rw enable? boolean 169 +--rw description? string 171 Figure 1: YANG Tree Diagram for Network Security Policy 173 A security policy is used by one virtual instance of an NSF/device as 174 a set of security rules to protect assets from major risk factors 175 that threaten the system. There can be multiple security policies in 176 a single NSF to provide the necessary protection. The security 177 policy includes its name, language tag, priority usage, resolution 178 strategy, default action, and rules. 180 The language field indicates the language tag that is used for the 181 natural language text that is included in all of the 'description' 182 attributes. The language field is encoded following the rules in 183 Section 2.1 of [RFC5646]. The default language tag is "en-US". 185 A resolution strategy is used to decide how to resolve conflicts that 186 occur between the actions of the same or different policy rules that 187 are matched and contained in a particular NSF. The resolution 188 strategy is defined as First Matching Rule (FMR), Last Matching Rule 189 (LMR), Prioritized Matching Rule (PMR) with Errors (PMRE), and 190 Prioritized Matching Rule with No Errors (PMRN). The resolution 191 strategy can be extended according to specific vendor action 192 features. The resolution strategy is described in detail in 193 [I-D.ietf-i2nsf-capability-data-model]. 195 A default action is used to execute I2NSF policy rule when no rule 196 matches a packet. The default action can be pass, drop, reject, 197 rate-limit, or mirror actions. The default action can be extended 198 according to specific vendor action features. The default action is 199 described in detail in [I-D.ietf-i2nsf-capability-data-model]. 201 The rules include rule name, rule description, rule priority, rule 202 enable, event, condition, and action. 204 3.2. Event Clause 206 This section shows a YANG tree diagram for an event clause for a 207 general I2NSF security policy rule for generic network security 208 functions. 210 module: ietf-i2nsf-nsf-facing-interface 211 +--rw i2nsf-security-policy* [name] 212 ... 213 +--rw rules* [name] 214 | ... 215 | +--rw event 216 | | +--rw description? string 217 | | +--rw system-event* identityref 218 | | +--rw system-alarm* identityref 219 | +--rw condition 220 | | ... 221 | +--rw action 222 | ... 223 +--rw rule-group 224 ... 226 Figure 2: YANG Tree Diagram for an Event Clause 228 An event clause is any important occurrence at a specific time of a 229 change in the system being managed, and/or in the environment of the 230 system being managed. An event clause is used to trigger the 231 evaluation of the condition clause of the I2NSF Policy Rule. The 232 event clause is defined as a system event, system alarm 233 [I-D.ietf-i2nsf-nsf-monitoring-data-model], and time. The event 234 clause can be extended according to specific vendor event features. 235 The event clause is described in detail in 236 [I-D.ietf-i2nsf-capability-data-model]. 238 3.3. Condition Clause 240 This section shows a YANG tree diagram for a condition clause for a 241 general I2NSF security policy rule for generic network security 242 functions. 244 module: ietf-i2nsf-nsf-facing-interface 245 +--rw i2nsf-security-policy* [name] 246 ... 247 +--rw rules* [name] 248 | ... 249 | +--rw event 250 | | ... 251 | +--rw condition 252 | | +--rw description? string 253 | | +--rw layer-2* [destination-mac-address source-mac-address 254 ethertype] 255 | | | +--rw description? string 256 | | | +--rw destination-mac-address yang:mac-address 257 | | | +--rw destination-mac-address-mask? yang:mac-address 258 | | | +--rw source-mac-address yang:mac-address 259 | | | +--rw source-mac-address-mask? yang:mac-address 260 | | | +--rw ethertype eth:ethertype 261 | | +--rw (layer-3)? 262 | | | +--:(ipv4) 263 | | | | +--rw ipv4 264 | | | | +--rw description? string 265 | | | | +--rw dscp? inet:dscp 266 | | | | +--rw ecn? uint8 267 | | | | +--rw length? uint16 268 | | | | +--rw ttl? uint8 269 | | | | +--rw protocol? uint8 270 | | | | +--rw ihl? uint8 271 | | | | +--rw flags? bits 272 | | | | +--rw offset? uint16 273 | | | | +--rw identification? uint16 274 | | | | +--rw (destination-network)? 275 | | | | | +--:(destination-ipv4-network) 276 | | | | | | +--rw destination-ipv4-network? 277 inet:ipv4-prefix 278 | | | | | +--:(destination-ipv4-range) 279 | | | | | +--rw destination-ipv4-range* [start end] 280 | | | | | +--rw start inet:ipv4-address-no-zone 281 | | | | | +--rw end inet:ipv4-address-no-zone 282 | | | | +--rw (source-network)? 283 | | | | +--:(source-ipv4-network) 284 | | | | | +--rw source-ipv4-network? inet:ipv4-prefix 285 | | | | +--:(source-ipv4-range) 286 | | | | +--rw source-ipv4-range* [start end] 287 | | | | +--rw start inet:ipv4-address-no-zone 288 | | | | +--rw end inet:ipv4-address-no-zone 289 | | | +--:(ipv6) 290 | | | +--rw ipv6 291 | | | +--rw description? string 292 | | | +--rw dscp? inet:dscp 293 | | | +--rw ecn? uint8 294 | | | +--rw length? uint16 295 | | | +--rw ttl? uint8 296 | | | +--rw protocol? uint8 297 | | | +--rw (destination-network)? 298 | | | | +--:(destination-ipv6-network) 299 | | | | | +--rw destination-ipv6-network? 300 inet:ipv6-prefix 301 | | | | +--:(destination-ipv6-range) 302 | | | | +--rw destination-ipv6-range* [start end] 303 | | | | +--rw start inet:ipv6-address-no-zone 304 | | | | +--rw end inet:ipv6-address-no-zone 305 | | | +--rw (source-network)? 306 | | | | +--:(source-ipv6-network) 307 | | | | | +--rw source-ipv6-network? inet:ipv6-prefix 308 | | | | +--:(source-ipv6-range) 309 | | | | +--rw source-ipv6-range* [start end] 310 | | | | +--rw start inet:ipv6-address-no-zone 311 | | | | +--rw end inet:ipv6-address-no-zone 312 | | | +--rw flow-label? inet:ipv6-flow-label 313 | | +--rw (layer-4)? 314 | | | +--:(tcp) 315 | | | | +--rw tcp 316 | | | | +--rw description? string 317 | | | | +--rw source-port-number 318 | | | | | +--rw (source-port)? 319 | | | | | +--:(range-or-operator) 320 | | | | | | +--rw (port-range-or-operator)? 321 | | | | | | +--:(range) 322 | | | | | | | +--rw lower-port inet:port-number 323 | | | | | | | +--rw upper-port inet:port-number 324 | | | | | | +--:(operator) 325 | | | | | | +--rw operator? operator 326 | | | | | | +--rw port inet:port-number 327 | | | | | +--:(port-list) 328 | | | | | +--rw port-numbers* [start end] 329 | | | | | +--rw start inet:port-number 330 | | | | | +--rw end inet:port-number 331 | | | | +--rw destination-port-number 332 | | | | | +--rw (destination-port)? 333 | | | | | +--:(range-or-operator) 334 | | | | | | +--rw (port-range-or-operator)? 335 | | | | | | +--:(range) 336 | | | | | | | +--rw lower-port inet:port-number 337 | | | | | | | +--rw upper-port inet:port-number 338 | | | | | | +--:(operator) 339 | | | | | | +--rw operator? operator 340 | | | | | | +--rw port inet:port-number 341 | | | | | +--:(port-list) 342 | | | | | +--rw port-numbers* [start end] 343 | | | | | +--rw start inet:port-number 344 | | | | | +--rw end inet:port-number 345 | | | | +--rw sequence-number? uint32 346 | | | | +--rw acknowledgement-number? uint32 347 | | | | +--rw data-offset? uint8 348 | | | | +--rw reserved? uint8 349 | | | | +--rw flags? bits 350 | | | | +--rw window-size? uint16 351 | | | | +--rw urgent-pointer? uint16 352 | | | | +--rw options? binary 353 | | | +--:(udp) 354 | | | | +--rw udp 355 | | | | +--rw description? string 356 | | | | +--rw source-port-number 357 | | | | | +--rw (source-port)? 358 | | | | | +--:(range-or-operator) 359 | | | | | | +--rw (port-range-or-operator)? 360 | | | | | | +--:(range) 361 | | | | | | | +--rw lower-port inet:port-number 362 | | | | | | | +--rw upper-port inet:port-number 363 | | | | | | +--:(operator) 364 | | | | | | +--rw operator? operator 365 | | | | | | +--rw port inet:port-number 366 | | | | | +--:(port-list) 367 | | | | | +--rw port-numbers* [start end] 368 | | | | | +--rw start inet:port-number 369 | | | | | +--rw end inet:port-number 370 | | | | +--rw destination-port-number 371 | | | | | +--rw (destination-port)? 372 | | | | | +--:(range-or-operator) 373 | | | | | | +--rw (port-range-or-operator)? 374 | | | | | | +--:(range) 375 | | | | | | | +--rw lower-port inet:port-number 376 | | | | | | | +--rw upper-port inet:port-number 377 | | | | | | +--:(operator) 378 | | | | | | +--rw operator? operator 379 | | | | | | +--rw port inet:port-number 380 | | | | | +--:(port-list) 381 | | | | | +--rw port-numbers* [start end] 382 | | | | | +--rw start inet:port-number 383 | | | | | +--rw end inet:port-number 384 | | | | +--rw length? uint16 385 | | | +--:(sctp) 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 end] 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 end] 414 | | | | | +--rw start inet:port-number 415 | | | | | +--rw end inet:port-number 416 | | | | +--rw chunk-type* uint8 417 | | | | +--rw chunk-length? uint16 418 | | | +--:(dccp) 419 | | | | +--rw dccp 420 | | | | +--rw description? string 421 | | | | +--rw source-port-number 422 | | | | | +--rw (source-port)? 423 | | | | | +--:(range-or-operator) 424 | | | | | | +--rw (port-range-or-operator)? 425 | | | | | | +--:(range) 426 | | | | | | | +--rw lower-port inet:port-number 427 | | | | | | | +--rw upper-port inet:port-number 428 | | | | | | +--:(operator) 429 | | | | | | +--rw operator? operator 430 | | | | | | +--rw port inet:port-number 431 | | | | | +--:(port-list) 432 | | | | | +--rw port-numbers* [start end] 433 | | | | | +--rw start inet:port-number 434 | | | | | +--rw end inet:port-number 435 | | | | +--rw destination-port-number 436 | | | | | +--rw (destination-port)? 437 | | | | | +--:(range-or-operator) 438 | | | | | | +--rw (port-range-or-operator)? 439 | | | | | | +--:(range) 440 | | | | | | | +--rw lower-port inet:port-number 441 | | | | | | | +--rw upper-port inet:port-number 442 | | | | | | +--:(operator) 443 | | | | | | +--rw operator? operator 444 | | | | | | +--rw port inet:port-number 445 | | | | | +--:(port-list) 446 | | | | | +--rw port-numbers* [start end] 447 | | | | | +--rw start inet:port-number 448 | | | | | +--rw end inet:port-number 449 | | | | +--rw service-code* uint32 450 | | | | +--rw type* uint8 451 | | | | +--rw data-offset? uint8 452 | | | +--:(icmp) 453 | | | +--rw icmp 454 | | | +--rw description? string 455 | | | +--rw version? enumeration 456 | | | +--rw type? uint8 457 | | | +--rw code? uint8 458 | | | +--rw rest-of-header? binary 459 | | +--rw url-category 460 | | | +--rw description? string 461 | | | +--rw pre-defined* string 462 | | | +--rw user-defined* string 463 | | +--rw voice 464 | | | +--rw description? string 465 | | | +--rw source-voice-id* string 466 | | | +--rw destination-voice-id* string 467 | | | +--rw user-agent* string 468 | | +--rw ddos 469 | | | +--rw description? string 470 | | | +--rw alert-packet-rate? uint32 471 | | | +--rw alert-flow-rate? uint32 472 | | | +--rw alert-byte-rate? uint32 473 | | +--rw anti-virus 474 | | | +--rw profile* string 475 | | | +--rw exception-files* string 476 | | +--rw payload 477 | | | +--rw description? string 478 | | | +--rw content* binary 479 | | +--rw context 480 | | +--rw description? string 481 | | +--rw time 482 | | | +--rw start-date-time? yang:date-and-time 483 | | | +--rw end-date-time? yang:date-and-time 484 | | | +--rw period 485 | | | | +--rw start-time? time 486 | | | | +--rw end-time? time 487 | | | | +--rw day* day 488 | | | | +--rw date* int8 489 | | | | +--rw month* string 490 | | | +--rw frequency? enumeration 491 | | +--rw application 492 | | | +--rw description? string 493 | | | +--rw protocol* identityref 494 | | +--rw device-type 495 | | | +--rw description? string 496 | | | +--rw device* identityref 497 | | +--rw users 498 | | | +--rw description? string 499 | | | +--rw user* [id] 500 | | | | +--rw id uint32 501 | | | | +--rw name? string 502 | | | +--rw group* [id] 503 | | | +--rw id uint32 504 | | | +--rw name? string 505 | | +--rw geographic-location 506 | | +--rw description? string 507 | | +--rw source* string 508 | | +--rw destination* string 509 | +--rw action 510 | ... 511 +--rw rule-group 512 ... 514 Figure 3: YANG Tree Diagram for a Condition Clause 516 A condition clause is defined as a set of attributes, features, and/ 517 or values that are to be compared with a set of known attributes, 518 features, and/or values in order to determine whether the set of 519 actions in that (imperative) I2NSF policy rule can be executed or 520 not. A condition clause works with 'AND' logic, where all fields set 521 in the condition MUST match the packet or flow for the condition to 522 be evaluated as 'TRUE'. A condition clause is classified as a 523 condition of generic network security functions, advanced network 524 security functions, or context. A condition clause of generic 525 network security functions is defined as IPv4 condition, IPv6 526 condition, TCP condition, UDP condition, SCTP condition, DCCP 527 condition, or ICMP (ICMPv4 and ICMPv6) condition. 529 Note that the data model in this document does not focus on only IP 530 addresses, but focuses on all the fields of IPv4 and IPv6 headers. 531 The IPv4 and IPv6 headers have similarity with some different fields. 532 In this case, it is better to handle separately the IPv4 and IPv6 533 headers such that the different fields can be used to handle IPv4 and 534 IPv6 packets. Also, note that the YANG data model in this document 535 is based on the YANG Data Model for Network Access Control Lists 536 (ACLs) [RFC8519] that does not support IPv6 extension headers 537 including various options, the support of IPv6 extension headers is 538 left as future work. 540 The data model provides transport layer condition for TCP, UDP, SCTP, 541 and DCCP. With ICMPv4 and ICMPv6 are included as a choice for layer 542 4 as the header fields in ICMP are above the network layer. Note 543 that QUIC protocol [RFC9000] is excluded in the data model as it is 544 not considered in the initial I2NSF documents [RFC8329]. The QUIC 545 traffic should not be treated as UDP traffic and will be considered 546 in the future I2NSF documents. 548 A condition clause of advanced network security functions is defined 549 as url category condition, voice condition, DDoS condition, or 550 payload condition. A condition clause of context is defined as 551 application condition, target condition, users condition, and 552 geography condition. 554 Note that this document deals only with conditions of several 555 advanced network security functions such as url filter (i.e., web 556 filter), VoIP/VoCN security, and DDoS-attack mitigator. A condition 557 clause of other advanced network security functions such as Intrusion 558 Prevention System (IPS) and Data Loss Prevention (DLP) can be defined 559 as an extension in future. A condition clause can be extended 560 according to specific vendor condition features. A condition clause 561 is described in detail in [I-D.ietf-i2nsf-capability-data-model]. 563 3.4. Action Clause 565 This section shows a YANG tree diagram for an action clause for a 566 general I2NSF security policy rule for generic network security 567 functions. 569 module: ietf-i2nsf-nsf-facing-interface 570 +--rw i2nsf-security-policy* [name] 571 ... 572 +--rw rules* [name] 573 | ... 574 | +--rw event 575 | ... 576 | +--rw condition 577 | ... 578 | +--rw action 579 | +--rw description? string 580 | +--rw packet-action 581 | | +--rw ingress-action? identityref 582 | | +--rw egress-action? identityref 583 | | +--rw log-action? identityref 584 | +--rw flow-action 585 | | +--rw ingress-action? identityref 586 | | +--rw egress-action? identityref 587 | | +--rw log-action? identityref 588 | +--rw advanced-action 589 | +--rw content-security-control* identityref 590 | +--rw attack-mitigation-control* identityref 591 +--rw rule-group 592 ... 594 Figure 4: YANG Tree Diagram for an Action Clause 596 An action is used to control and monitor aspects of flow-based NSFs 597 when the policy rule event and condition clauses are satisfied. NSFs 598 provide security services by executing various actions. The action 599 clause is defined as ingress action, egress action, or log action for 600 packet action, flow action, and advanced action for additional 601 inspection. The packet action is an action for an individual packet 602 such as an IP datagram as a stateless process that uses the packet's 603 header and payload. The flow action is an action of a traffic flow 604 such as the packets of a TCP session (e.g., an HTTP/HTTPS session) as 605 a stateful process that uses the traffic flow information such as 606 5-tuple information, packet counts, and byte counts. The advanced 607 action is an action for an advanced security service (e.g., url 608 filter, DDoS-attack mitigator, and VoIP/VoCN filter) for either a 609 packet or a traffic flow according to the intention of such an 610 advanced security service. The action clause can be extended 611 according to specific vendor action features. The action clause is 612 described in detail in [I-D.ietf-i2nsf-capability-data-model]. 614 Note that an empty event clause means that the event boolean will 615 always evaluate to true and starts the evaluation of the condition 616 clause, while an empty condition clause means that the condition 617 boolean will always evaluate to false. 619 4. YANG Data Model of NSF-Facing Interface 621 The main objective of this document is to provide the YANG data model 622 of the I2NSF NSF-Facing Interface. This interface can be used to 623 deliver control and management messages between a Security Controller 624 and NSFs for the I2NSF low-level security policies. 626 This data model is designed to support the I2NSF framework that can 627 be extended according to the security needs. In other words, the 628 model design is independent of the content and meaning of specific 629 policies as well as the implementation approach. 631 With the YANG data model of I2NSF NSF-Facing Interface, this document 632 suggests use cases for security policy rules such as time-based 633 firewall, web filter, VoIP/VoCN security service, and DDoS-attack 634 mitigation in Section 5. 636 4.1. YANG Module of NSF-Facing Interface 638 This section describes a YANG module of NSF-Facing Interface. This 639 document provides identities in the data model for the configuration 640 of an NSF. The identity has the same concept with the corresponding 641 identity in [I-D.ietf-i2nsf-consumer-facing-interface-dm]. This YANG 642 module imports from [RFC6991] and [RFC8519]. It makes references to 643 [RFC0768] [RFC0791] [RFC0792] [RFC0854] [RFC0959] [RFC1939] [RFC2132] 644 [RFC2595] [RFC3261] [RFC3986] [RFC4250] [RFC4340] [RFC4443] [RFC4732] 645 [RFC4987] [RFC5321] [RFC5595] [RFC5646] [RFC6335] [RFC8075] [RFC8200] 646 [RFC8329] [RFC8335] [RFC9051] [RFC9179] [GLOB] [IEEE-802.3] 647 [ISO-3166] [I-D.ietf-httpbis-http2bis] [I-D.ietf-httpbis-messaging] 648 [I-D.ietf-httpbis-semantics] [I-D.ietf-i2nsf-capability-data-model] 649 [I-D.ietf-i2nsf-nsf-monitoring-data-model] [I-D.ietf-tcpm-rfc793bis] 650 [I-D.ietf-tsvwg-rfc4960-bis] 652 file "ietf-i2nsf-nsf-facing-interface@2022-06-01.yang" 653 module ietf-i2nsf-nsf-facing-interface { 654 yang-version 1.1; 655 namespace 656 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-facing-interface"; 657 prefix 658 i2nsfnfi; 660 import ietf-inet-types { 661 prefix inet; 662 reference 663 "Section 4 of RFC 6991"; 664 } 665 import ietf-yang-types { 666 prefix yang; 667 reference 668 "Section 3 of RFC 6991"; 669 } 670 import ietf-packet-fields { 671 prefix packet-fields; 672 reference 673 "Section 4.2 of RFC 8519"; 674 } 676 organization 677 "IETF I2NSF (Interface to Network Security Functions) 678 Working Group"; 680 contact 681 "WG Web: 682 WG List: 684 Editor: Jinyong Tim Kim 685 687 Editor: Jaehoon Paul Jeong 688 "; 690 description 691 "This module is a YANG module for Network Security Functions 692 (NSF)-Facing Interface. 694 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 695 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 696 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 697 document are to be interpreted as described in BCP 14 698 (RFC 2119) (RFC 8174) when, and only when, they appear 699 in all capitals, as shown here. 701 Copyright (c) 2022 IETF Trust and the persons identified as 702 authors of the code. All rights reserved. 704 Redistribution and use in source and binary forms, with or 705 without modification, is permitted pursuant to, and subject to 706 the license terms contained in, the Revised BSD License set 707 forth in Section 4.c of the IETF Trust's Legal Provisions 708 Relating to IETF Documents 709 (https://trustee.ietf.org/license-info). 711 This version of this YANG module is part of RFC XXXX 712 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 713 for full legal notices."; 715 revision "2022-06-01"{ 716 description "The latest revision."; 717 reference 718 "RFC XXXX: I2NSF Network Security Function-Facing Interface 719 YANG Data Model"; 720 } 722 /* 723 * Identities 724 */ 726 identity priority-usage { 727 description 728 "Base identity for priority usage type to define the type of 729 priority to be implemented in a security policy rule, such 730 as priority by order and priority by number."; 731 } 733 identity priority-by-order { 734 base priority-usage; 735 description 736 "This indicates that the priority of a security policy rule 737 follows the order of the configuration. The earlier the 738 configuration is, the higher the priority is."; 739 } 741 identity priority-by-number { 742 base priority-usage; 743 description 744 "This indicates the priority of a security policy rule follows 745 the number or value of the configuration. The higher the value 746 is, the higher the priority is."; 747 } 749 identity event { 750 description 751 "Base identity for policy events."; 752 reference 753 "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF 754 Monitoring Interface YANG Data Model - Event"; 755 } 757 identity system-event { 758 base event; 759 description 760 "Base Identity for system events. System event (also called 761 alert) is defined as a warning about any changes of 762 configuration, any access violation, the information of 763 sessions and traffic flows."; 764 reference 765 "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF 766 Monitoring Interface YANG Data Model - System event"; 767 } 769 identity system-alarm { 770 base event; 771 description 772 "Base identity for system alarms. System alarm is defined as a 773 warning related to service degradation in system hardware."; 774 reference 775 "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF 776 Monitoring Interface YANG Data Model - System alarm"; 777 } 779 identity access-violation { 780 base system-event; 781 description 782 "Access-violation system event is an event when a user tries 783 to access (read, write, create, or delete) any information or 784 execute commands above their privilege (i.e., not-conformant 785 with the access profile)."; 786 reference 787 "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF 788 Monitoring Interface YANG Data Model - System event for access 789 violation"; 790 } 792 identity configuration-change { 793 base system-event; 794 description 795 "The configuration-change system event is an event when a user 796 adds a new configuration or modify an existing configuration 797 (write configuration)."; 798 reference 799 "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF 800 Monitoring Interface YANG Data Model - System event for 801 configuration change"; 802 } 804 identity memory-alarm { 805 base system-alarm; 806 description 807 "Memory is the hardware to store information temporarily or for 808 a short period, i.e., Random Access Memory (RAM). A 809 memory-alarm is emitted when the memory usage is exceeding 810 the threshold."; 811 reference 812 "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF 813 Monitoring Interface YANG Data Model - System alarm for 814 memory"; 815 } 817 identity cpu-alarm { 818 base system-alarm; 819 description 820 "CPU is the Central Processing Unit that executes basic 821 operations of the system. A cpu-alarm is emitted when the CPU 822 usage is exceeding a threshold."; 823 reference 824 "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF 825 Monitoring Interface YANG Data Model - System alarm for CPU"; 826 } 828 identity disk-alarm { 829 base system-alarm; 830 description 831 "Disk or storage is the hardware to store information for a 832 long period, i.e., Hard Disk and Solid-State Drive. A 833 disk-alarm is emitted when the disk usage is exceeding a 834 threshold."; 835 reference 836 "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF 837 Monitoring Interface YANG Data Model - System alarm for disk"; 838 } 840 identity hardware-alarm { 841 base system-alarm; 842 description 843 "A hardware alarm is emitted when a hardware failure (e.g., 844 CPU, memory, disk, or interface) is detected. A hardware 845 failure is a malfunction within the electronic circuits or 846 electromechanical components of the hardware that makes it 847 unusable."; 848 reference 849 "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF 850 Monitoring Interface YANG Data Model - System alarm for 851 hardware"; 852 } 854 identity interface-alarm { 855 base system-alarm; 856 description 857 "Interface is the network interface for connecting a device 858 with the network. The interface-alarm is emitted when the 859 state of the interface is changed."; 860 reference 861 "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF 862 Monitoring Interface YANG Data Model - System alarm for 863 interface"; 864 } 866 identity device-type { 867 description 868 "Base identity for types of device. This identity is used for 869 type of the device for the source or destination of a packet 870 or traffic flow. Note that the device type of either a source 871 or destination can be known with the help of DHCP 872 Fingerprinting and the interaction between an NSF and a DHCP 873 server."; 874 reference 875 "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability 876 YANG Data Model 877 RFC 2132: DHCP Options and BOOTP Vendor Extensions - Vendor 878 Specific Information including device type, manufacturer, 879 and operating system as DHCP fingerprinting information"; 880 } 882 identity computer { 883 base device-type; 884 description 885 "Identity for computer such as personal computer (PC) 886 and server."; 887 } 889 identity mobile-phone { 890 base device-type; 891 description 892 "Identity for mobile-phone such as smartphone and 893 cellphone"; 894 } 896 identity voip-vocn-phone { 897 base device-type; 898 description 899 "Identity for VoIP (Voice over Internet Protocol) or VoCN 900 (Voice over Cellular Network, such as Voice over LTE or 5G) 901 phone"; 903 } 905 identity tablet { 906 base device-type; 907 description 908 "Identity for tablet devices"; 909 } 911 identity network-infrastructure-device { 912 base device-type; 913 description 914 "Identity for network infrastructure devices 915 such as switch, router, and access point"; 916 } 918 identity iot-device { 919 base device-type; 920 description 921 "Identity for Internet of Things (IoT) devices 922 such as sensors, actuators, and low-power 923 low-capacity computing devices"; 924 } 926 identity ot { 927 base device-type; 928 description 929 "Identity for Operational Technology (OT) devices (also 930 known as industrial control systems) that interact 931 with the physical environment and detect or cause direct 932 change through the monitoring and control of devices, 933 processes, and events such as programmable logic 934 controllers (PLCs), digital oscilloscopes, building 935 management systems (BMS), and fire control systems"; 936 } 938 identity vehicle { 939 base device-type; 940 description 941 "Identity for transportation vehicles that connect to and 942 share data through the Internet over Vehicle-to-Everything 943 (V2X) communications."; 944 } 946 identity advanced-nsf { 947 description 948 "Base identity for advanced Network Security Function (NSF) 949 capability. This can be used for advanced NSFs such as 950 Anti-DDoS Attack, IPS, URL-Filtering, Antivirus, 951 and VoIP/VoCN Filter."; 952 reference 953 "draft-ietf-i2nsf-capability-data-model-32: 954 I2NSF Capability YANG Data Model"; 955 } 957 identity content-security-control { 958 base advanced-nsf; 959 description 960 "Base identity for content security control. Content security 961 control is an NSF that evaluates the payload of a packet, 962 such as Intrusion Prevention System (IPS), URL Filter, 963 Antivirus, and VoIP/VoCN Filter."; 964 reference 965 "draft-ietf-i2nsf-capability-data-model-32: 966 I2NSF Capability YANG Data Model"; 967 } 969 identity ips { 970 base content-security-control; 971 description 972 "IPS (Intrusion Prevention System) prevents malicious activity 973 within a network"; 974 } 976 identity url-filtering { 977 base content-security-control; 978 description 979 "URL filtering limits access by comparing the web traffic's 980 URL with the URLs for web filtering in a database"; 981 } 983 identity anti-virus { 984 base content-security-control; 985 description 986 "Antivirus to protect the network by detecting and 987 removing viruses or malwares."; 988 } 990 identity voip-vocn-filtering { 991 base content-security-control; 992 description 993 "VoIP (Voice over Internet Protocol) and VoCN (Voice over 994 Cellular Network, such as Voice over LTE or 5G) security 995 service that filters out the packets or flows of malicious 996 users with a deny-list of malicious users in a database"; 997 } 998 identity attack-mitigation-control { 999 base advanced-nsf; 1000 description 1001 "Base identity for attack mitigation control. Attack mitigation 1002 control is an NSF that mitigates an attack such as 1003 anti-DDoS (i.e., DDoS-mitigator)."; 1004 reference 1005 "draft-ietf-i2nsf-capability-data-model-32: 1006 I2NSF Capability YANG Data Model"; 1007 } 1009 identity anti-ddos { 1010 base attack-mitigation-control; 1011 description 1012 "Anti-DDoS or DDoS Mitigator to protect a server or network 1013 from a DDoS attack. The mitigation approach is up to the 1014 implementation."; 1015 reference 1016 "RFC 4732: Internet Denial-of-Service Considerations - DoS 1017 Mitigation Strategies 1018 RFC 4987: TCP SYN Flooding Attacks and Common Mitigations - 1019 Common Defenses"; 1020 } 1022 identity action { 1023 description 1024 "Base identity for action."; 1025 } 1027 identity ingress-action { 1028 base action; 1029 description 1030 "Base identity for ingress action. The action to handle the 1031 network traffic that is entering the secured network."; 1032 reference 1033 "draft-ietf-i2nsf-capability-data-model-32: 1034 I2NSF Capability YANG Data Model - Ingress Action"; 1035 } 1037 identity egress-action { 1038 base action; 1039 description 1040 "Base identity for egress action. The action to handle the 1041 network traffic that is exiting the secured network."; 1042 reference 1043 "draft-ietf-i2nsf-capability-data-model-32: 1044 I2NSF Capability YANG Data Model - Egress Action"; 1045 } 1046 identity default-action { 1047 base action; 1048 description 1049 "Base identity for default action. The default action of the 1050 NSF when no rule matches the packet or flow."; 1051 reference 1052 "draft-ietf-i2nsf-capability-data-model-32: 1053 I2NSF Capability YANG Data Model - Default Action"; 1054 } 1056 identity pass { 1057 base ingress-action; 1058 base egress-action; 1059 base default-action; 1060 description 1061 "The pass action allows traffic that matches 1062 the rule to proceed through the NSF to reach the 1063 destination."; 1064 reference 1065 "draft-ietf-i2nsf-capability-data-model-32: 1066 I2NSF Capability YANG Data Model - Actions and 1067 Default Action"; 1068 } 1070 identity drop { 1071 base ingress-action; 1072 base egress-action; 1073 base default-action; 1074 description 1075 "The drop action denies the traffic that 1076 matches the rule. The drop action should do a silent drop, 1077 which does not give any response to the source."; 1078 reference 1079 "draft-ietf-i2nsf-capability-data-model-32: 1080 I2NSF Capability YANG Data Model - Actions and 1081 Default Action"; 1082 } 1084 identity reject { 1085 base ingress-action; 1086 base egress-action; 1087 base default-action; 1088 description 1089 "The reject action denies a packet to go through the NSF 1090 entering or exiting the internal network and sends a response 1091 back to the source. The response depends on the packet and 1092 implementation. For example, a TCP packet is rejected with 1093 TCP RST response or a UDP packet may be rejected with an 1094 ICMPv4 response message with Type 3 Code 3 or ICMPv6 response 1095 message Type 1 Code 4 (i.e., Destination Unreachable: 1096 Destination port unreachable)."; 1097 } 1099 identity mirror { 1100 base ingress-action; 1101 base egress-action; 1102 base default-action; 1103 description 1104 "The mirror action copies a packet and sends the packet's copy 1105 to the monitoring entity while still allowing the packet or 1106 flow to go through the NSF."; 1107 reference 1108 "draft-ietf-i2nsf-capability-data-model-32: 1109 I2NSF Capability YANG Data Model - Actions and 1110 Default Action"; 1111 } 1113 identity rate-limit { 1114 base ingress-action; 1115 base egress-action; 1116 base default-action; 1117 description 1118 "The rate limit action limits the number of packets or flows 1119 that can go through the NSF by dropping packets or flows 1120 (randomly or systematically). The drop mechanism, e.g., silent 1121 drop and unreachable drop (i.e., reject), is up to the 1122 implementation"; 1123 reference 1124 "draft-ietf-i2nsf-capability-data-model-32: 1125 I2NSF Capability YANG Data Model - Actions and 1126 Default Action"; 1127 } 1129 identity log-action { 1130 base action; 1131 description 1132 "Base identity for log action"; 1133 } 1135 identity rule-log { 1136 base log-action; 1137 description 1138 "Log the policy rule that has been triggered by a packet or 1139 flow."; 1140 } 1141 identity session-log { 1142 base log-action; 1143 description 1144 "A session is a connection (i.e., traffic flow) of a data plane 1145 that includes source and destination information of IP 1146 addresses and transport port numbers with the protocol used. 1147 Log the session that triggered a policy rule."; 1148 } 1150 identity invoke-signaling { 1151 base egress-action; 1152 description 1153 "The invoke-signaling action is used to convey information of 1154 the event triggering this action to a monitoring entity."; 1155 } 1157 identity tunnel-encapsulation { 1158 base egress-action; 1159 description 1160 "The tunnel encapsulation action is used to encapsulate the 1161 packet to be tunneled across the network to enable a secure 1162 connection."; 1163 } 1165 identity forwarding { 1166 base egress-action; 1167 description 1168 "The forwarding action is used to relay the packet from one 1169 network segment to another node in the network."; 1170 } 1172 identity transformation { 1173 base egress-action; 1174 description 1175 "The transformation action is used to transform a packet by 1176 modifying it (e.g., HTTP-to-CoAP packet translation). 1177 Note that a subset of transformation (e.g., HTTP-to-CoAP) is 1178 handled in this YANG module, rather than all the existing 1179 transformations. Specific algorithmic transformations can be 1180 executed by a middlebox (e.g., NSF) for a given transformation 1181 name."; 1182 reference 1183 "RFC 8075: Guidelines for Mapping Implementations: HTTP to the 1184 Constrained Application Protocol (CoAP) - Translation between 1185 HTTP and CoAP."; 1186 } 1188 identity resolution-strategy { 1189 description 1190 "Base identity for resolution strategy"; 1191 reference 1192 "draft-ietf-i2nsf-capability-data-model-32: 1193 I2NSF Capability YANG Data Model - Resolution Strategy"; 1194 } 1196 identity fmr { 1197 base resolution-strategy; 1198 description 1199 "Conflict resolution with First Matching Rule (FMR)."; 1200 reference 1201 "draft-ietf-i2nsf-capability-data-model-32: 1202 I2NSF Capability YANG Data Model - Resolution Strategy"; 1203 } 1205 identity lmr { 1206 base resolution-strategy; 1207 description 1208 "Conflict resolution with Last Matching Rule (LMR)"; 1209 reference 1210 "draft-ietf-i2nsf-capability-data-model-32: 1211 I2NSF Capability YANG Data Model - Resolution Strategy"; 1212 } 1214 identity pmre { 1215 base resolution-strategy; 1216 description 1217 "Conflict resolution with Prioritized Matching Rule with 1218 Errors (PMRE)"; 1219 reference 1220 "draft-ietf-i2nsf-capability-data-model-32: 1221 I2NSF Capability YANG Data Model - Resolution Strategy"; 1222 } 1224 identity pmrn { 1225 base resolution-strategy; 1226 description 1227 "Conflict resolution with Prioritized Matching Rule with 1228 No Errors (PMRN)"; 1229 reference 1230 "draft-ietf-i2nsf-capability-data-model-32: 1231 I2NSF Capability YANG Data Model - Resolution Strategy"; 1232 } 1234 identity application-protocol { 1235 description 1236 "Base identity for Application protocol. Note that a subset of 1237 application protocols (e.g., HTTP, HTTPS, FTP, POP3, and 1238 IMAP) are handled in this YANG module, rather than all 1239 the existing application protocols."; 1240 } 1242 identity http { 1243 base application-protocol; 1244 description 1245 "The identity for Hypertext Transfer Protocol version 1.1 1246 (HTTP/1.1)."; 1247 reference 1248 "draft-ietf-httpbis-semantics-19: HTTP Semantics 1249 draft-ietf-httpbis-messaging-19: HTTP/1.1"; 1250 } 1252 identity https { 1253 base application-protocol; 1254 description 1255 "The identity for Hypertext Transfer Protocol version 1.1 1256 (HTTP/1.1) over TLS."; 1257 reference 1258 "draft-ietf-httpbis-semantics-19: HTTP Semantics 1259 draft-ietf-httpbis-messaging-19: HTTP/1.1"; 1260 } 1262 identity http2 { 1263 base application-protocol; 1264 description 1265 "The identity for Hypertext Transfer Protocol version 2 1266 (HTTP/2)."; 1267 reference 1268 "draft-ietf-httpbis-http2bis-07: HTTP/2"; 1269 } 1271 identity https2 { 1272 base application-protocol; 1273 description 1274 "The identity for Hypertext Transfer Protocol version 2 1275 (HTTP/2) over TLS."; 1276 reference 1277 "draft-ietf-httpbis-http2bis-07: HTTP/2"; 1278 } 1280 identity ftp { 1281 base application-protocol; 1282 description 1283 "The identity for File Transfer Protocol."; 1284 reference 1285 "RFC 959: File Transfer Protocol (FTP)"; 1286 } 1288 identity ssh { 1289 base application-protocol; 1290 description 1291 "The identity for Secure Shell (SSH) protocol."; 1292 reference 1293 "RFC 4250: The Secure Shell (SSH) Protocol"; 1294 } 1296 identity telnet { 1297 base application-protocol; 1298 description 1299 "The identity for telnet."; 1300 reference 1301 "RFC 854: Telnet Protocol"; 1302 } 1304 identity smtp { 1305 base application-protocol; 1306 description 1307 "The identity for Simple Mail Transfer Protocol."; 1308 reference 1309 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1310 } 1312 identity pop3 { 1313 base application-protocol; 1314 description 1315 "The identity for Post Office Protocol 3 (POP3)."; 1316 reference 1317 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1318 } 1320 identity pop3s { 1321 base application-protocol; 1322 description 1323 "The identity for Post Office Protocol 3 (POP3) over TLS"; 1324 reference 1325 "RFC 1939: Post Office Protocol - Version 3 (POP3) 1326 RFC 2595: Using TLS with IMAP, POP3 and ACAP"; 1327 } 1329 identity imap { 1330 base application-protocol; 1331 description 1332 "The identity for Internet Message Access Protocol (IMAP)."; 1334 reference 1335 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 1336 4rev2"; 1337 } 1339 identity imaps { 1340 base application-protocol; 1341 description 1342 "The identity for Internet Message Access Protocol (IMAP) over 1343 TLS"; 1344 reference 1345 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 1346 4rev2"; 1347 } 1349 /* 1350 * Typedefs 1351 */ 1353 typedef time { 1354 type string { 1355 pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' 1356 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 1357 } 1358 description 1359 "The time type represents an instance of time of zero-duration 1360 in the specified timezone that recurs every day."; 1361 } 1363 typedef day { 1364 type enumeration { 1365 enum monday { 1366 description 1367 "This represents Monday."; 1368 } 1369 enum tuesday { 1370 description 1371 "This represents Tuesday."; 1372 } 1373 enum wednesday { 1374 description 1375 "This represents Wednesday"; 1376 } 1377 enum thursday { 1378 description 1379 "This represents Thursday."; 1380 } 1381 enum friday { 1382 description 1383 "This represents Friday."; 1384 } 1385 enum saturday { 1386 description 1387 "This represents Saturday."; 1388 } 1389 enum sunday { 1390 description 1391 "This represents Sunday."; 1392 } 1393 } 1394 description 1395 "The type for representing the day of the week."; 1396 } 1398 /* 1399 * Groupings 1400 */ 1402 grouping port-range { 1403 leaf start { 1404 type inet:port-number; 1405 description 1406 "A start port number for a range match."; 1407 } 1408 leaf end { 1409 type inet:port-number; 1410 must '. >= ../start' { 1411 error-message 1412 "An end port number MUST be equal to or greater than a 1413 start port number."; 1414 } 1415 description 1416 "An end port number for a range match."; 1417 } 1418 description 1419 "A range match for port numbers. If only one value is needed, 1420 then set both start and end to the same value."; 1421 reference 1422 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1423 (TCP) Specification - Port Number 1424 RFC 768: User Datagram Protocol - Port Number 1425 draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission 1426 Protocol - Port Number 1427 RFC 4340: Datagram Congestion Control Protocol (DCCP) 1428 - Port Number"; 1429 } 1430 grouping ipv4-range { 1431 description 1432 "A range match for IPv4 addresses. If only one value is 1433 needed, then set both start and end to the same value. 1434 The end IPv4 address MUST be equal to or greater than the 1435 start IPv4 address."; 1436 leaf start { 1437 type inet:ipv4-address-no-zone; 1438 description 1439 "A start IPv4 address for a range match."; 1440 } 1441 leaf end { 1442 type inet:ipv4-address-no-zone; 1443 description 1444 "An end IPv4 address for a range match."; 1445 } 1446 reference 1447 "RFC 791: Internet Protocol - IPv4 address"; 1448 } 1450 grouping ipv6-range { 1451 description 1452 "A range match for IPv6 addresses. If only one value is 1453 needed, then set both start and end to the same value. 1454 The end IPv6 address MUST be equal to or greater than the 1455 start IPv6 address."; 1456 leaf start { 1457 type inet:ipv6-address-no-zone; 1458 description 1459 "A start IPv6 address for a range match."; 1460 } 1462 leaf end { 1463 type inet:ipv6-address-no-zone; 1464 description 1465 "An end IPv6 address for a range match."; 1466 } 1467 reference 1468 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1469 Specification - IPv6 address"; 1470 } 1472 /* 1473 * Data nodes 1474 */ 1476 list i2nsf-security-policy { 1477 key "name"; 1479 description 1480 "Container for security policy 1481 including a set of security rules according to certain logic, 1482 i.e., their similarity or mutual relations, etc. The network 1483 security policy can be applied to both the unidirectional 1484 and bidirectional traffic across the NSF. 1485 The I2NSF security policies use the Event-Condition-Action 1486 (ECA) policy model "; 1488 reference 1489 "RFC 8329: Framework for Interface to Network Security 1490 Functions - I2NSF Flow Security Policy Structure 1491 draft-ietf-i2nsf-capability-data-model-32: 1492 I2NSF Capability YANG Data Model - Design Principles and 1493 ECA Policy Model Overview"; 1495 leaf name { 1496 type string; 1497 description 1498 "The name of the security policy. 1499 This must be unique."; 1500 } 1502 leaf language { 1503 type string { 1504 pattern '((([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})' 1505 + '{0,2})?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?' 1506 + '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}' 1507 + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WYZa-wyz]' 1508 + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]' 1509 + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|' 1510 + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-' 1511 + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-' 1512 + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-' 1513 + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]' 1514 + '|[Ii]-[Hh][Aa][Kk]|' 1515 + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|' 1516 + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|' 1517 + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|' 1518 + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|' 1519 + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|' 1520 + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-' 1521 + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-' 1522 + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-' 1523 + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|' 1524 + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-' 1525 + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|' 1526 + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-' 1527 + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-' 1528 + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))'; 1529 } 1530 default "en-US"; 1531 description 1532 "The value in this field indicates the language tag 1533 used for all of the 'leaf description' described in the 1534 'i2nsf-security-policy'. This field is mandatory only when 1535 one or more of the 'leaf description' is used. 1537 The attribute is encoded following the rules in Section 2.1 1538 in RFC 5646. The default language tag is 'en-US'"; 1539 reference 1540 "RFC 5646: Tags for Identifying Languages"; 1541 } 1543 leaf priority-usage { 1544 type identityref { 1545 base priority-usage; 1546 } 1547 default priority-by-order; 1548 description 1549 "Priority usage type for security policy rule: 1550 priority by order and priority by number"; 1551 } 1553 leaf resolution-strategy { 1554 type identityref { 1555 base resolution-strategy; 1556 } 1557 default fmr; 1558 description 1559 "The resolution strategies that can be used to 1560 specify how to resolve conflicts that occur between 1561 actions of the same or different policy rules that 1562 are matched and contained in this particular NSF"; 1564 reference 1565 "draft-ietf-i2nsf-capability-data-model-32: 1566 I2NSF Capability YANG Data Model - Resolution strategy"; 1567 } 1569 leaf default-action { 1570 type identityref { 1571 base default-action; 1572 } 1573 default mirror; 1574 description 1575 "This default action can be used to specify a predefined 1576 action when no other alternative action was matched 1577 by the currently executing I2NSF Policy Rule. An analogy 1578 is the use of a default statement in a C switch statement."; 1579 reference 1580 "draft-ietf-i2nsf-capability-data-model-32: 1581 I2NSF Capability YANG Data Model - Default Action"; 1582 } 1584 list rules { 1585 key "name"; 1586 description 1587 "This is a rule for network security functions."; 1589 leaf name { 1590 type string; 1591 description 1592 "The name of the rule."; 1593 } 1595 leaf description { 1596 type string; 1597 description 1598 "This description gives more information about 1599 rules."; 1600 } 1602 leaf priority { 1603 type uint8 { 1604 range "1..255"; 1605 } 1606 description 1607 "The priority for the rule comes with a mandatory 1608 numeric value which can range from 1 up to 255. 1609 Note that a higher number means a higher priority"; 1610 } 1612 leaf enable { 1613 type boolean; 1614 description 1615 "If true, the rule is enabled and enforced. 1616 If false, the rule is configured but disabled and not 1617 enforced."; 1618 } 1620 container long-connection { 1621 description 1622 "A container for long connection. A long connection is a 1623 connection that is maintained after the socket connection 1624 is established, regardless of whether it is used for data 1625 traffic or not."; 1627 leaf enable { 1628 type boolean; 1629 description 1630 "If true, the rule is enabled and enforced. 1631 If false, the rule is configured but disabled 1632 and not enforced."; 1633 } 1635 leaf duration { 1636 when "../enable = 'true'"; 1637 type uint32; 1638 units "second"; 1639 description 1640 "This is the maximum inactive connection duration of a 1641 long connection before a connection is declared as 1642 expired."; 1643 } 1644 } 1646 container event { 1647 description 1648 "An event is defined as any important 1649 occurrence in time of a change in the system being 1650 managed, and/or in the environment of the system being 1651 managed. When used in the context of policy rules for 1652 a flow-based NSF, it is used to determine whether the 1653 Condition clause of the Policy Rule can be evaluated 1654 or not. Examples of an I2NSF event include time and 1655 user actions (e.g., logon, logoff, and actions that 1656 violate any ACL.)."; 1658 reference 1659 "RFC 8329: Framework for Interface to Network Security 1660 Functions - I2NSF Flow Security Policy Structure 1661 draft-ietf-i2nsf-capability-data-model-32: 1662 I2NSF Capability YANG Data Model - Design Principles and 1663 ECA Policy Model Overview 1664 draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF 1665 NSF Monitoring Interface YANG Data Model - Alarms, 1666 Events, Logs, and Counters"; 1668 leaf description { 1669 type string; 1670 description 1671 "Description for an event clause"; 1672 } 1674 leaf-list system-event { 1675 type identityref { 1676 base system-event; 1677 } 1678 description 1679 "The security policy rule according to 1680 system events."; 1681 } 1683 leaf-list system-alarm { 1684 type identityref { 1685 base system-alarm; 1686 } 1687 description 1688 "The security policy rule according to 1689 system alarms."; 1690 } 1691 } 1693 container condition { 1694 description 1695 "A condition is defined as a set 1696 of attributes, features, and/or values that are to be 1697 compared with a set of known attributes, features, 1698 and/or values in order to determine whether the 1699 set of Actions in that (imperative) I2NSF Policy Rule 1700 can be executed or not. Examples of I2NSF Conditions 1701 include matching attributes of a packet or flow, and 1702 comparing the internal state of an NSF to a desired 1703 state. 1704 The condition works with 'AND' logic, where all 1705 fields set in a condition MUST match the packet or flow 1706 for the condition to be evaluated as 'TRUE'"; 1707 reference 1708 "RFC 8329: Framework for Interface to Network Security 1709 Functions - I2NSF Flow Security Policy Structure 1710 draft-ietf-i2nsf-capability-data-model-32: 1711 I2NSF Capability YANG Data Model - Design Principles and 1712 ECA Policy Model Overview"; 1714 leaf description { 1715 type string; 1716 description 1717 "Description for a condition clause."; 1718 } 1720 list layer-2 { 1721 key "destination-mac-address source-mac-address ethertype"; 1722 description 1723 "The purpose of this container is to represent layer 2 1724 packet header information to determine the set of policy 1725 actions in this ECA policy rule should be executed or 1726 not."; 1727 reference 1728 "IEEE 802.3: IEEE Standard for Ethernet"; 1730 leaf description { 1731 type string; 1732 description 1733 "The ethernet condition description"; 1734 } 1736 uses packet-fields:acl-eth-header-fields; 1737 } 1739 choice layer-3 { 1740 case ipv4 { 1741 container ipv4 { 1742 description 1743 "The purpose of this container is to represent 1744 IPv4 packet header information to determine if 1745 the set of policy actions in this ECA policy rule 1746 should be executed or not."; 1747 reference 1748 "RFC 791: Internet Protocol"; 1750 leaf description { 1751 type string; 1752 description 1753 "This is description for IPv4 condition."; 1754 } 1756 uses packet-fields:acl-ip-header-fields; 1757 uses packet-fields:acl-ipv4-header-fields { 1758 augment destination-network { 1759 case destination-ipv4-range { 1760 list destination-ipv4-range { 1761 key "start end"; 1762 uses ipv4-range; 1763 description 1764 "The list of IPv4 addresses specified with 1765 a start IPv4 address and an end IPv4 1766 address. If only one value is needed, then 1767 set both start and end to the same value. 1768 Note that the 'end' IPv4 address MUST be 1769 equal to or greater than the 'start' IPv4 1770 address."; 1771 } 1772 } 1773 description 1774 "IPv4 destination network denoted as IPv4 1775 addresses"; 1776 } 1777 augment source-network { 1778 case source-ipv4-range { 1779 list source-ipv4-range { 1780 key "start end"; 1781 uses ipv4-range; 1782 description 1783 "The list of IPv4 addresses specified with 1784 a start IPv4 address and an end IPv4 1785 address. If only one value is needed, then 1786 set both start and end to the same value. 1787 Note that the 'end' IPv4 address MUST be 1788 equal or greater than the 'start' IPv4 1789 address."; 1790 } 1791 } 1792 description 1793 "IPv4 source network denoted as IPv4 1794 addresses"; 1795 } 1796 } 1797 } 1798 } 1799 case ipv6 { 1800 container ipv6 { 1801 description 1802 "The purpose of this container is to represent IPv6 1803 packet header information to determine if the set 1804 of policy actions in this ECA policy rule should 1805 be executed or not."; 1807 reference 1808 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1809 Specification"; 1811 leaf description { 1812 type string; 1813 description 1814 "This is description for IPv6 condition."; 1815 } 1817 uses packet-fields:acl-ip-header-fields; 1818 uses packet-fields:acl-ipv6-header-fields { 1819 augment destination-network { 1820 case destination-ipv6-range { 1821 list destination-ipv6-range { 1822 key "start end"; 1823 uses ipv6-range; 1824 description 1825 "The list of IPv6 addresses specified with 1826 a start IPv6 address and an end IPv6 1827 address. If only one value is needed, then 1828 set both start and end to the same value. 1829 Note that the 'end' IPv6 address MUST be 1830 equal to or greater than the 'start' IPv6 1831 address."; 1832 } 1833 } 1834 description 1835 "IPv6 destination network denoted as IPv6 1836 addresses"; 1837 } 1838 augment source-network { 1839 case source-ipv6-range { 1840 list source-ipv6-range { 1841 key "start end"; 1842 uses ipv6-range; 1843 description 1844 "The list of IPv6 addresses specified with 1845 a start IPv6 address and an end IPv6 1846 address. If only one value is needed, then 1847 set both start and end to the same value. 1848 Note that the 'end' IPv6 address MUST be 1849 equal to or greater than the 'start' IPv6 1850 address."; 1851 } 1852 } 1853 description 1854 "IPv6 source network denoted as IPv6 1855 addresses"; 1856 } 1857 } 1858 } 1859 } 1860 description 1861 "Choice of either IPv4 or IPv6 as layer-3 protocol"; 1862 } 1864 choice layer-4 { 1865 case tcp { 1866 container tcp { 1867 description 1868 "The purpose of this container is to represent 1869 TCP packet header information to determine 1870 if the set of policy actions in this ECA policy 1871 rule should be executed or not."; 1872 reference 1873 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 1874 Protocol (TCP) Specification"; 1876 leaf description { 1877 type string; 1878 description 1879 "This is description for tcp condition."; 1880 } 1882 container source-port-number { 1883 choice source-port { 1884 case range-or-operator { 1885 uses packet-fields:port-range-or-operator; 1886 description 1887 "Source port definition from range or operator. 1888 Can be used when a single port range to be 1889 specified."; 1890 } 1891 case port-list { 1892 list port-numbers { 1893 key "start end"; 1894 uses port-range; 1895 description 1896 "List of source port numbers."; 1897 } 1898 description 1899 "Source port definition from list of port 1900 numbers. In the case of multiple port ranges 1901 needed to be specified."; 1902 } 1903 description 1904 "The choice of source port definition using 1905 range/operator or a choice to use list of port 1906 numbers."; 1907 } 1908 description 1909 "The security policy rule according to 1910 tcp source port number."; 1911 reference 1912 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 1913 Protocol (TCP) Specification - Port Number"; 1914 } 1916 container destination-port-number { 1917 choice destination-port { 1918 case range-or-operator { 1919 uses packet-fields:port-range-or-operator; 1920 description 1921 "Destination port definition from range or 1922 operator. 1923 Can be used when a single port range to be 1924 specified."; 1925 } 1926 case port-list { 1927 list port-numbers { 1928 key "start end"; 1929 uses port-range; 1930 description 1931 "List of destination port numbers."; 1932 } 1933 description 1934 "Destination port definition from list of port 1935 numbers. 1936 In the case of multiple port ranges needed to 1937 be specified."; 1938 } 1939 description 1940 "The choice of destination port definition using 1941 range/operator or a choice to use list of port 1942 numbers."; 1943 } 1944 description 1945 "The security policy rule according to 1946 tcp destination port number."; 1947 reference 1948 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 1949 Protocol (TCP) Specification - Port Number"; 1950 } 1952 uses packet-fields:acl-tcp-header-fields; 1953 } 1954 } 1955 case udp { 1956 container udp { 1957 description 1958 "The purpose of this container is to represent 1959 UDP packet header information to determine 1960 if the set of policy actions in this ECA policy 1961 rule should be executed or not."; 1962 reference 1963 "RFC 768: User Datagram Protocol"; 1965 leaf description { 1966 type string; 1967 description 1968 "This is description for udp condition."; 1969 } 1971 container source-port-number { 1972 choice source-port { 1973 case range-or-operator { 1974 uses packet-fields:port-range-or-operator; 1975 description 1976 "Source port definition from range or operator. 1977 Can be used when a single port range to be 1978 specified."; 1979 } 1980 case port-list { 1981 list port-numbers { 1982 key "start end"; 1983 uses port-range; 1984 description 1985 "List of source port numbers."; 1986 } 1987 description 1988 "Source port definition from list of port 1989 numbers. In the case of multiple port ranges 1990 needed to be specified."; 1991 } 1992 description 1993 "The choice of source port definition using 1994 range/operator or a choice to use list of port 1995 numbers."; 1996 } 1997 description 1998 "The security policy rule according to 1999 udp source port number."; 2000 reference 2001 "RFC 768: User Datagram Protocol - Port Number"; 2002 } 2003 container destination-port-number { 2004 choice destination-port { 2005 case range-or-operator { 2006 uses packet-fields:port-range-or-operator; 2007 description 2008 "Destination port definition from range or 2009 operator. 2010 Can be used when a single port range to be 2011 specified."; 2012 } 2013 case port-list { 2014 list port-numbers { 2015 key "start end"; 2016 uses port-range; 2017 description 2018 "List of destination port numbers."; 2019 } 2020 description 2021 "Destination port definition from list of port 2022 numbers. 2023 In the case of multiple port ranges needed to 2024 be specified."; 2025 } 2026 description 2027 "The choice of destination port definition using 2028 range/operator or a choice to use list of port 2029 numbers."; 2030 } 2031 description 2032 "The security policy rule according to 2033 udp destination port number."; 2034 reference 2035 "RFC 768: User Datagram Protocol - Port Number"; 2036 } 2038 uses packet-fields:acl-udp-header-fields; 2039 } 2040 } 2042 case sctp { 2043 container sctp { 2044 description 2045 "The purpose of this container is to represent 2046 SCTP packet header information to determine 2047 if the set of policy actions in this ECA policy 2048 rule should be executed or not."; 2050 leaf description { 2051 type string; 2052 description 2053 "This is description for sctp condition."; 2054 } 2056 container source-port-number { 2057 choice source-port { 2058 case range-or-operator { 2059 uses packet-fields:port-range-or-operator; 2060 description 2061 "Source port definition from range or operator. 2062 Can be used when a single port range to be 2063 specified."; 2064 } 2065 case port-list { 2066 list port-numbers { 2067 key "start end"; 2068 uses port-range; 2069 description 2070 "List of source port numbers."; 2071 } 2072 description 2073 "Source port definition from list of port 2074 numbers. In the case of multiple port ranges 2075 needed to be specified."; 2076 } 2077 description 2078 "The choice of source port definition using 2079 range/operator or a choice to use list of port 2080 numbers."; 2081 } 2082 description 2083 "The security policy rule according to 2084 sctp source port number."; 2085 reference 2086 "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control 2087 Transmission Protocol - Port number"; 2088 } 2090 container destination-port-number { 2091 choice destination-port { 2092 case range-or-operator { 2093 uses packet-fields:port-range-or-operator; 2094 description 2095 "Destination port definition from range or 2096 operator. 2097 Can be used when a single port range to be 2098 specified."; 2100 } 2101 case port-list { 2102 list port-numbers { 2103 key "start end"; 2104 uses port-range; 2105 description 2106 "List of destination port numbers."; 2107 } 2108 description 2109 "Destination port definition from list of port 2110 numbers. 2111 In the case of multiple port ranges needed to 2112 be specified."; 2113 } 2114 description 2115 "The choice of destination port definition using 2116 range/operator or a choice to use list of port 2117 numbers."; 2118 } 2119 description 2120 "The security policy rule according to 2121 sctp destination port number."; 2122 reference 2123 "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control 2124 Transmission Protocol - Port Number"; 2125 } 2127 leaf-list chunk-type { 2128 type uint8; 2129 description 2130 "The security policy rule according to 2131 sctp chunk type ID Value."; 2132 reference 2133 "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control 2134 Transmission Protocol - Chunk Type"; 2135 } 2137 leaf chunk-length { 2138 type uint16 { 2139 range "4..max"; 2140 } 2141 description 2142 "The security policy rule according to the length 2143 of the chunk in sctp. This value represents the 2144 size of the chunk in bytes, including the Chunk 2145 Type, Chunk Flags, Chunk Length, and Chunk Value 2146 fields."; 2147 reference 2148 "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control 2149 Transmission Protocol - Chunk Length"; 2150 } 2151 } 2152 } 2154 case dccp { 2155 container dccp { 2156 description 2157 "The purpose of this container is to represent 2158 DCCP packet header information to determine 2159 if the set of policy actions in this ECA policy 2160 rule should be executed or not."; 2161 leaf description { 2162 type string; 2163 description 2164 "This is description for dccp condition."; 2165 } 2167 container source-port-number { 2168 choice source-port { 2169 case range-or-operator { 2170 uses packet-fields:port-range-or-operator; 2171 description 2172 "Source port definition from range or operator. 2173 Can be used when a single port range to be 2174 specified."; 2175 } 2176 case port-list { 2177 list port-numbers { 2178 key "start end"; 2179 uses port-range; 2180 description 2181 "List of source port numbers."; 2182 } 2183 description 2184 "Source port definition from list of port 2185 numbers. In the case of multiple port ranges 2186 needed to be specified."; 2187 } 2188 description 2189 "The choice of source port definition using 2190 range/operator or a choice to use list of port 2191 numbers."; 2192 } 2193 description 2194 "The security policy rule according to 2195 dccp source port number."; 2197 reference 2198 "RFC 4340: Datagram Congestion Control Protocol 2199 (DCCP) - Port number"; 2200 } 2202 container destination-port-number { 2203 choice destination-port { 2204 case range-or-operator { 2205 uses packet-fields:port-range-or-operator; 2206 description 2207 "Destination port definition from range or 2208 operator. 2209 Can be used when a single port range to be 2210 specified."; 2211 } 2212 case port-list { 2213 list port-numbers { 2214 key "start end"; 2215 uses port-range; 2216 description 2217 "List of destination port numbers."; 2218 } 2219 description 2220 "Destination port definition from list of port 2221 numbers. In the case of multiple port ranges 2222 needed to be specified."; 2223 } 2224 description 2225 "The choice of destination port definition using 2226 range/operator or a choice to use list of port 2227 numbers."; 2228 } 2229 description 2230 "The security policy rule according to 2231 dccp destination port number."; 2232 reference 2233 "RFC 4340: Datagram Congestion Control Protocol 2234 (DCCP) - Port number"; 2235 } 2237 leaf-list service-code { 2238 type uint32; 2239 description 2240 "The security policy rule according to 2241 dccp service code."; 2242 reference 2243 "RFC 4340: Datagram Congestion Control Protocol 2244 (DCCP) - Service Codes 2246 RFC 5595: The Datagram Congestion Control Protocol 2247 (DCCP) Service Codes 2248 RFC 6335: Internet Assigned Numbers Authority 2249 (IANA) Procedures for the Management of 2250 the Service Name and Transport Protocol 2251 Port Number Registry - Service Code"; 2252 } 2254 leaf-list type { 2255 type uint8 { 2256 range "0..15"; 2257 } 2258 description 2259 "The security policy rule according to the 4 bits 2260 of dccp type header field for dccp packet types 2261 such as DCCP-Request, DCCP-Response, DCCP-Data, 2262 DCCP-Ack, and DCCP-DataAck."; 2263 reference 2264 "RFC 4340: Datagram Congestion Control Protocol 2265 (DCCP) - Packet Types"; 2266 } 2268 leaf data-offset { 2269 type uint8; 2270 description 2271 "The security policy rule according to the offset 2272 from 2273 the start of the packet's DCCP header to the start 2274 of its application data area, in 32-bit word."; 2275 reference 2276 "RFC 4340: Datagram Congestion Control Protocol 2277 (DCCP) - Data Offset"; 2278 } 2279 } 2280 } 2281 case icmp { 2282 container icmp { 2283 description 2284 "The purpose of this container is to represent 2285 ICMPv4 and ICMPv6 packet header information to 2286 determine if the set of policy actions in this ECA 2287 policy rule should be executed or not."; 2288 reference 2289 "RFC 792: Internet Control Message Protocol 2290 RFC 8335: PROBE: A Utility for Probing Interfaces"; 2292 leaf description { 2293 type string; 2294 description 2295 "This is description for icmp condition."; 2296 } 2298 leaf version { 2299 type enumeration { 2300 enum icmpv4 { 2301 value "1"; 2302 description 2303 "The ICMPv4 Protocol as defined in RFC 792"; 2304 } 2305 enum icmpv6 { 2306 value "2"; 2307 description 2308 "The ICMPv6 Protocol as defined in RFC 4443"; 2309 } 2310 } 2311 description 2312 "The ICMP version to be matched. This value 2313 affected the type and code values."; 2314 reference 2315 "RFC 792: Internet Control Message Protocol 2316 RFC 4443: Internet Control Message Protocol 2317 (ICMPv6) for the Internet Protocol 2318 Version 6 (IPv6) Specification"; 2319 } 2321 uses packet-fields:acl-icmp-header-fields; 2322 } 2323 } 2324 description 2325 "Choice of TCP, UDP, SCTP, DCCP, and ICMP as a layer-4 2326 protocol."; 2327 } 2329 container url-category { 2330 description 2331 "Condition for url category"; 2332 leaf description { 2333 type string; 2334 description 2335 "This is description for the condition of a URL's 2336 category such as SNS sites, game sites, ecommerce 2337 sites, company sites, and university sites."; 2338 } 2340 leaf-list pre-defined { 2341 type string; 2342 description 2343 "This is pre-defined-category. To specify the name of 2344 URL database."; 2345 } 2346 leaf-list user-defined { 2347 type string; 2348 description 2349 "This user-defined-category. To allow a user's manual 2350 addition of URLs for URL filtering."; 2351 reference 2352 "RFC 3986: Uniform Resource Identifier (URI): Generic 2353 Syntax"; 2354 } 2355 } 2357 container voice { 2358 description 2359 "For the VoIP/VoCN security system, a VoIP/ 2360 VoCN security system can monitor each 2361 VoIP/VoCN flow and manage VoIP/VoCN 2362 security rules controlled by a centralized 2363 server for VoIP/VoCN security service 2364 (called VoIP IPS). The VoIP/VoCN security 2365 system controls each switch for the 2366 VoIP/VoCN call flow management by 2367 manipulating the rules that can be added, 2368 deleted, or modified dynamically."; 2369 reference 2370 "RFC 3261: SIP: Session Initiation Protocol"; 2372 leaf description { 2373 type string; 2374 description 2375 "This is description for voice condition."; 2376 } 2378 leaf-list source-voice-id { 2379 type string; 2380 description 2381 "The security policy rule according to 2382 a source voice ID for VoIP and VoCN."; 2383 } 2385 leaf-list destination-voice-id { 2386 type string; 2387 description 2388 "The security policy rule according to 2389 a destination voice ID for VoIP and VoCN."; 2391 } 2393 leaf-list user-agent { 2394 type string; 2395 description 2396 "The security policy rule according to 2397 a user agent for VoIP and VoCN."; 2398 } 2399 } 2401 container ddos { 2402 description 2403 "Condition for DDoS attack."; 2405 leaf description { 2406 type string; 2407 description 2408 "This is description for ddos condition."; 2409 } 2411 leaf alert-packet-rate { 2412 type uint32; 2413 units "pps"; 2414 description 2415 "The alert rate of flood detection for 2416 packets per second (PPS) of an IP address. 2417 If the PPS of an IP address exceeds 2418 the alert rate threshold, an alert 2419 will be generated."; 2420 } 2422 leaf alert-flow-rate { 2423 type uint32; 2424 description 2425 "The alert rate of flood detection for the 2426 flow creating requests (e.g., new TCP connection 2427 establishment) per second of an IP address as 2428 either a source node or a destination node. If 2429 the flows per second of an IP address exceeds 2430 the alert rate threshold, an alert will be 2431 generated."; 2432 } 2434 leaf alert-byte-rate { 2435 type uint32; 2436 units "Bps"; 2437 description 2438 "The alert rate of flood detection for 2439 bytes per second (Bps) of an IP address. 2440 If the bytes per second of an IP address 2441 exceeds the alert rate threshold, an alert 2442 will be generated."; 2443 } 2444 } 2446 container anti-virus { 2447 description 2448 "Condition for antivirus"; 2450 leaf-list profile { 2451 type string; 2452 description 2453 "The security profile for antivirus. This is used to 2454 update the security profile for improving the 2455 security. The security profile is used to scan 2456 the viruses."; 2457 } 2459 leaf-list exception-files { 2460 type string; 2461 description 2462 "The type or name of the files to be excluded by the 2463 antivirus. This can be used to keep the known 2464 harmless files. Absolute paths are filenames/paths 2465 to be excluded and relative ones are interpreted as 2466 globs."; 2467 reference 2468 "GLOB: Linux Programmer's Manual - GLOB"; 2469 } 2470 } 2472 container payload { 2473 description 2474 "Condition for packet payload"; 2475 leaf description { 2476 type string; 2477 description 2478 "This is description for payload condition."; 2479 } 2480 leaf-list content { 2481 type binary; 2482 description 2483 "This is a condition for packet payload content. 2484 The payload content is the binary stream contained 2485 by a security attack such as backdoor attack. It is 2486 usually used for Deep Packet Inspection (DPI)."; 2488 } 2489 } 2491 container context { 2492 description 2493 "Condition for context"; 2494 leaf description { 2495 type string; 2496 description 2497 "This is description for context condition."; 2498 } 2500 container time { 2501 description 2502 "Time to determine when the policy should be applied"; 2503 leaf start-date-time { 2504 type yang:date-and-time; 2505 description 2506 "This is the start date and time for a security 2507 policy rule."; 2508 } 2510 leaf end-date-time { 2511 type yang:date-and-time; 2512 description 2513 "This is the end date and time for a policy rule. 2514 The policy rule will stop working after the 2515 specified end-date-time."; 2516 } 2518 container period { 2519 when 2520 "../frequency!='only-once'"; 2521 description 2522 "This represents the repetition time. In the case 2523 where the frequency is weekly, the days can be 2524 set."; 2525 leaf start-time { 2526 type time; 2527 description 2528 "This is a period's start time for an event."; 2529 } 2530 leaf end-time { 2531 type time; 2532 description 2533 "This is a period's end time for an event."; 2534 } 2535 leaf-list day { 2536 when 2537 "../../frequency='weekly'"; 2538 type day; 2539 min-elements 1; 2540 description 2541 "This represents the repeated day of every week 2542 (e.g., Monday and Tuesday). More than one day 2543 can be specified."; 2544 } 2545 leaf-list date { 2546 when 2547 "../../frequency='monthly'"; 2548 type int8 { 2549 range "1..31"; 2550 } 2551 min-elements 1; 2552 description 2553 "This represents the repeated date of every month. 2554 More than one date can be specified."; 2555 } 2556 leaf-list month { 2557 when 2558 "../../frequency='yearly'"; 2559 type string{ 2560 pattern '\d{2}-\d{2}'; 2561 } 2562 min-elements 1; 2563 description 2564 "This represents the repeated date and month of 2565 every year. More than one can be specified. 2566 A pattern used here is Month and Date (MM-DD)."; 2567 } 2568 } 2570 leaf frequency { 2571 type enumeration { 2572 enum only-once { 2573 description 2574 "This represents that the rule is immediately 2575 enforced only once and not repeated. The policy 2576 will continuously be active from the start-time 2577 to the end-time."; 2578 } 2579 enum daily { 2580 description 2581 "This represents that the rule is enforced on a 2582 daily basis. The policy will be repeated 2583 daily until the end-date."; 2585 } 2586 enum weekly { 2587 description 2588 "This represents that the rule is enforced on a 2589 weekly basis. The policy will be repeated 2590 weekly until the end-date. The repeated days 2591 can be specified."; 2592 } 2593 enum monthly { 2594 description 2595 "This represents that the rule is enforced on a 2596 monthly basis. The policy will be repeated 2597 monthly until the end-date."; 2598 } 2599 enum yearly { 2600 description 2601 "This represents that the rule is enforced on 2602 a yearly basis. The policy will be repeated 2603 yearly until the end-date."; 2604 } 2605 } 2606 default only-once; 2607 description 2608 "This represents how frequently the rule 2609 should be enforced."; 2610 } 2611 } 2613 container application { 2614 description 2615 "Condition for application"; 2616 leaf description { 2617 type string; 2618 description 2619 "This is description for application condition."; 2620 } 2621 leaf-list protocol { 2622 type identityref { 2623 base application-protocol; 2624 } 2625 description 2626 "The condition based on the application layer 2627 protocol"; 2628 } 2629 } 2631 container device-type { 2632 description 2633 "Condition for type of the destination device"; 2634 leaf description { 2635 type string; 2636 description 2637 "This is description for destination device type 2638 condition. Vendors can write instructions for the 2639 condition that vendor made"; 2640 } 2642 leaf-list device { 2643 type identityref { 2644 base device-type; 2645 } 2646 description 2647 "The device attribute that can identify a device, 2648 including the device type (i.e., router, switch, 2649 pc, ios, or android) and the device's owner as 2650 well."; 2651 } 2652 } 2654 container users { 2655 description 2656 "Condition for users"; 2657 leaf description { 2658 type string; 2659 description 2660 "This is the description for users' condition."; 2661 } 2662 list user { 2663 key "id"; 2664 description 2665 "The user with which the traffic flow is associated 2666 can be identified by either a user ID or username. 2667 The user-to-IP address mapping is assumed to be 2668 provided by the unified user management system via 2669 network."; 2670 leaf id { 2671 type uint32; 2672 description 2673 "The ID of the user."; 2674 } 2675 leaf name { 2676 type string; 2677 description 2678 "The name of the user."; 2679 } 2680 } 2681 list group { 2682 key "id"; 2683 description 2684 "The user group with which the traffic flow is 2685 associated can be identified by either a group ID 2686 or group name. The group-to-IP address and 2687 user-to-group mappings are assumed to be provided by 2688 the unified user management system via network."; 2689 leaf id { 2690 type uint32; 2691 description 2692 "The ID of the group."; 2693 } 2694 leaf name { 2695 type string; 2696 description 2697 "The name of the group."; 2698 } 2699 } 2700 } 2702 container geographic-location { 2703 description 2704 "The location which network traffic flow is associated 2705 with. The region can be the geographic location such 2706 as country, province, and city, as well as the logical 2707 network location such as IP address, network section, 2708 and network domain."; 2709 reference 2710 "RFC 9179: A YANG Grouping for Geographic Locations"; 2712 leaf description { 2713 type string; 2714 description 2715 "This is the description for the geographic location 2716 condition. It is used to describe the conditions and 2717 instructions that should be implemented."; 2718 } 2720 leaf-list source { 2721 type string; 2722 description 2723 "The source is a geographic location mapped into an 2724 IP address. It matches the mapped IP address to the 2725 source IP address of the traffic flow."; 2726 reference 2727 "ISO 3166: Codes for the representation of 2728 names of countries and their subdivisions 2729 RFC 9179: A YANG Grouping for Geographic Locations"; 2730 } 2732 leaf-list destination { 2733 type string; 2734 description 2735 "The destination is a geographic location mapped into 2736 an IP address. It matches the mapped IP address to 2737 the destination IP address of the traffic flow."; 2738 reference 2739 "ISO 3166: Codes for the representation of 2740 names of countries and their subdivisions 2741 RFC 9179: A YANG Grouping for Geographic Locations"; 2742 } 2743 } 2744 } 2745 } 2747 container action { 2748 description 2749 "An action is used to control and monitor aspects of 2750 flow-based NSFs when the event and condition clauses 2751 are satisfied. NSFs provide security functions by 2752 executing various Actions. Examples of I2NSF Actions 2753 include providing intrusion detection and/or protection, 2754 web and flow filtering, and deep packet inspection 2755 for packets and flows."; 2756 reference 2757 "RFC 8329: Framework for Interface to Network Security 2758 Functions - I2NSF Flow Security Policy Structure 2759 draft-ietf-i2nsf-capability-data-model-32: 2760 I2NSF Capability YANG Data Model - Design Principles and 2761 ECA Policy Model Overview"; 2763 leaf description { 2764 type string; 2765 description 2766 "Description for an action clause."; 2767 } 2769 container packet-action { 2770 description 2771 "Action for packets"; 2772 reference 2773 "RFC 8329: Framework for Interface to Network Security 2774 Functions - I2NSF Flow Security Policy Structure 2775 draft-ietf-i2nsf-capability-data-model-32: 2776 I2NSF Capability YANG Data Model - Design Principles and 2777 ECA Policy Model Overview"; 2779 leaf ingress-action { 2780 type identityref { 2781 base ingress-action; 2782 } 2783 description 2784 "Ingress Action: pass, drop, reject, rate-limit, and 2785 mirror."; 2786 } 2788 leaf egress-action { 2789 type identityref { 2790 base egress-action; 2791 } 2792 description 2793 "Egress action: pass, drop, reject, rate-limit, mirror, 2794 invoke-signaling, tunnel-encapsulation, forwarding, 2795 redirection, and transformation."; 2796 } 2798 leaf log-action { 2799 type identityref { 2800 base log-action; 2801 } 2802 description 2803 "Log action: rule log and session log"; 2804 } 2806 } 2808 container flow-action { 2809 description 2810 "Action for flows"; 2811 reference 2812 "RFC 8329: Framework for Interface to Network Security 2813 Functions - I2NSF Flow Security Policy Structure 2814 draft-ietf-i2nsf-capability-data-model-32: 2815 I2NSF Capability YANG Data Model - Design Principles and 2816 ECA Policy Model Overview"; 2818 leaf ingress-action { 2819 type identityref { 2820 base ingress-action; 2821 } 2822 description 2823 "Action: pass, drop, reject, rate-limit, and mirror."; 2824 } 2825 leaf egress-action { 2826 type identityref { 2827 base egress-action; 2828 } 2829 description 2830 "Egress action: pass, drop, reject, rate-limit, mirror, 2831 invoke-signaling, tunnel-encapsulation, forwarding, 2832 redirection, and transformation."; 2833 } 2835 leaf log-action { 2836 type identityref { 2837 base log-action; 2838 } 2839 description 2840 "Log action: rule log and session log"; 2841 } 2842 } 2844 container advanced-action { 2845 description 2846 "If the packet needs to be additionally inspected, 2847 the packet is passed to advanced network 2848 security functions according to the profile. 2849 The profile means the types of NSFs where the packet 2850 will be forwarded in order to additionally 2851 inspect the packet. 2852 The advanced action activates Service Function 2853 Chaining (SFC) for further inspection of a packet."; 2854 reference 2855 "draft-ietf-i2nsf-capability-data-model-32: 2856 I2NSF Capability YANG Data Model - YANG Tree 2857 Diagram"; 2859 leaf-list content-security-control { 2860 type identityref { 2861 base content-security-control; 2862 } 2863 description 2864 "Content-security-control is the NSFs that 2865 inspect the payload of the packet. 2866 The profile for the types of NSFs for mitigation is 2867 divided into content security control and 2868 attack-mitigation-control. 2869 Content security control: ips, url filtering, 2870 antivirus, and voip-vocn-filter. This can be 2871 extended according to the provided NSFs."; 2872 reference 2873 "draft-ietf-i2nsf-capability-data-model-32: 2874 I2NSF Capability YANG Data Model - YANG Tree Diagram"; 2875 } 2877 leaf-list attack-mitigation-control { 2878 type identityref { 2879 base attack-mitigation-control; 2880 } 2881 description 2882 "Attack-mitigation-control is the NSFs that weaken 2883 the attacks related to a denial-of-service (DoS) 2884 and reconnaissance. 2885 The profile for the types of NSFs for mitigation is 2886 divided into content security control and 2887 attack-mitigation-control. 2888 Attack mitigation control: Anti-DDoS or DDoS 2889 mitigator. This can be extended according to the 2890 provided NSFs such as mitigators for ip sweep, 2891 port scanning, ping of death, teardrop, oversized 2892 icmp, and tracert."; 2893 reference 2894 "draft-ietf-i2nsf-capability-data-model-32: 2895 I2NSF Capability YANG Data Model - YANG Tree Diagram"; 2896 } 2897 } 2898 } 2899 } 2900 container rule-group { 2901 description 2902 "This is rule group"; 2904 list groups { 2905 key "group-name"; 2906 description 2907 "This is a group for rules"; 2909 leaf group-name { 2910 type string; 2911 description 2912 "This is the name of the group for rules"; 2913 } 2915 leaf-list rule-name { 2916 type leafref { 2917 path 2918 "../../../rules/name"; 2919 } 2920 description 2921 "The names of the rules to be grouped."; 2922 } 2924 leaf enable { 2925 type boolean; 2926 description 2927 "If true, the rule is enabled and enforced. 2928 If false, the rule is configured but disabled 2929 and not enforced."; 2930 } 2932 leaf description { 2933 type string; 2934 description 2935 "This is a description for rule-group"; 2936 } 2937 } 2938 } 2939 } 2940 } 2941 2943 Figure 5: YANG Data Module of I2NSF NSF-Facing-Interface 2945 5. XML Configuration Examples of Low-Level Security Policy Rules 2947 This section shows XML configuration examples of low-level security 2948 policy rules that are delivered from the Security Controller to NSFs 2949 over the NSF-Facing Interface. For security requirements, we assume 2950 that the NSFs (i.e., General firewall, Time-based firewall, URL 2951 filter, VoIP/VoCN filter, and HTTP and HTTPS flood mitigation) 2952 described in Appendix A of [I-D.ietf-i2nsf-capability-data-model] are 2953 registered with the I2NSF framework. With the registered NSFs, we 2954 show configuration examples for security policy rules of network 2955 security functions according to the following three security 2956 requirements: (i) Block Social Networking Service (SNS) access during 2957 business hours, (ii) Block malicious VoIP/VoCN packets coming to the 2958 company, and (iii) Mitigate HTTP and HTTPS flood attacks on company 2959 web server. 2961 5.1. Example Security Requirement 1: Block Social Networking Service 2962 (SNS) Access during Business Hours 2964 This section shows a configuration example for blocking SNS access 2965 during business hours in IPv4 networks or IPv6 networks. 2967 2969 sns_access 2970 2971 block_sns_access_during_operation_time_for_ipv4 2972 2973 2974 192.0.2.0/24 2975 2976 2977 2991 2992 2993 2994 2995 2996 url-filtering 2997 2998 2999 3000 3001 3003 Figure 6: Configuration XML for Time-based Firewall to Block SNS 3004 Access during Business Hours in IPv4 Networks 3006 3008 sns_access 3009 3010 block_sns_access_during_operation_time_for_ipv6 3011 3012 3013 2001:db8:1::/60 3014 3015 3016 3030 3031 3032 3033 3034 3035 url-filtering 3036 3037 3038 3039 3040 3042 Figure 7: Configuration XML for Time-based Firewall to Block SNS 3043 Access during Business Hours in IPv6 Networks 3045 3047 sns_access 3048 3049 block_sns_access_during_operation_time 3050 3051 3052 SNS_1 3053 SNS_2 3054 3055 3056 3057 3058 drop 3059 3060 3061 3062 3064 Figure 8: Configuration XML for Web Filter to Block SNS Access 3065 during Business Hours 3067 Figure 6 and Figure 7 show the configuration XML documents for a 3068 time-based firewall for IPv4 and IPv6, respectively. Figure 8 shows 3069 the configuration XML document for a web filter. The two NSFs 3070 combined to block SNS access during business hours in IPv4 networks 3071 (or IPv6 networks). For the security requirement, two NSFs (i.e., a 3072 time-based firewall and a web filter) were used because one NSF 3073 cannot meet the security requirement. The instances of XML documents 3074 for the time-based firewall and the web filter are as follows: Note 3075 that a detailed data model for the configuration of the advanced 3076 network security function (i.e., web filter) can be defined as an 3077 extension in future. 3079 Time-based Firewall is as follows: 3081 1. The name of the security policy is sns_access. 3083 2. The name of the rule is 3084 block_sns_access_during_operation_time_for_ipv4 and 3085 block_sns_access_during_operation_time_for_ipv6. 3087 3. The rule is started from 2021-03-11 at 9 a.m. to 2021-12-31 at 6 3088 p.m. 3090 4. The rule is operated weekly every weekday (i.e., Monday, Tuesday, 3091 Wednesday, Thursday, and Friday) during the business hours (i.e., 3092 from 9 a.m. to 6 p.m.). 3094 5. The rule inspects a source IPv4 address (i.e., 192.0.2.0/24). 3095 For the case of IPv6 networks, the rule inspects a source IPv6 3096 address (i.e., from 2001:db8:1::/60). 3098 6. If the outgoing packets match the rules above, the time-based 3099 firewall sends the packets to url filtering for additional 3100 inspection because the time-based firewall can not inspect 3101 contents of the packets for the SNS URL. 3103 Web Filter is as follows: 3105 1. The name of the security policy is sns_access. 3107 2. The name of the rule is block_SNS_1_and_SNS_2. 3109 3. The rule inspects URL address to block the access packets to the 3110 SNS_1 or the SNS_2. 3112 4. If the outgoing packets match the rules above, the packets are 3113 blocked. 3115 5.2. Example Security Requirement 2: Block Malicious VoIP/VoCN Packets 3116 Coming to a Company 3118 This section shows a configuration example for blocking malicious 3119 VoIP/VoCN packets coming to a company. 3121 3123 voip_vocn_inspection 3124 3125 block_malicious_voice_id 3126 3127 3128 192.0.2.0/24 3129 3130 3131 3132 5060 3133 5061 3134 3135 3136 3137 3138 3139 3140 voip-vocn-filtering 3141 3142 3143 3144 3145 3147 Figure 9: Configuration XML for General Firewall to Block 3148 Malicious VoIP/VoCN Packets Coming to a Company 3150 3152 voip_vocn_inspection 3153 3154 block_malicious_voice_id 3155 3156 3157 3158 user1@voip.malicious.example.com 3159 3160 3161 user2@voip.malicious.example.com 3162 3163 3164 3165 3166 3167 drop 3168 3169 3170 3171 3173 Figure 10: Configuration XML for VoIP/VoCN Filter to Block 3174 Malicious VoIP/VoCN Packets Coming to a Company 3176 Figure 9 and Figure 10 show the configuration XML documents for 3177 general firewall and VoIP/VoCN filter to block malicious VoIP/VoCN 3178 packets coming to a company. For the security requirement, two NSFs 3179 (i.e., a general firewall and a VoIP/VoCN filter) were used because 3180 one NSF can not meet the security requirement. The instances of XML 3181 documents for the general firewall and the VoIP/VoCN filter are as 3182 follows: Note that a detailed data model for the configuration of the 3183 advanced network security function (i.e., VoIP/VoCN filter) can be 3184 described as an extension in future. 3186 General Firewall is as follows: 3188 1. The name of the security policy is voip_vocn_inspection. 3190 2. The name of the rule is block_malicious_voice_id. 3192 3. The rule inspects a destination IPv4 address (i.e., from 3193 192.0.2.0/24). 3195 4. The rule inspects a port number (i.e., 5060 and 5061) to inspect 3196 VoIP/VoCN packet. 3198 5. If the incoming packets match the rules above, the general 3199 firewall sends the packets to VoIP/VoCN filter for additional 3200 inspection because the general firewall can not inspect contents 3201 of the VoIP/VoCN packets. 3203 VoIP/VoCN Filter is as follows: 3205 1. The name of the security policy is malicious_voice_id. 3207 2. The name of the rule is block_malicious_voice_id. 3209 3. The rule inspects the voice ID of the VoIP/VoCN packets to block 3210 the malicious VoIP/VoCN packets (i.e., 3211 user1@voip.malicious.example.com and 3212 user2@voip.malicious.example.com). 3214 4. If the incoming packets match the rules above, the packets are 3215 blocked. 3217 5.3. Example Security Requirement 3: Mitigate HTTP and HTTPS Flood 3218 Attacks on a Company Web Server 3220 This section shows a configuration example for mitigating HTTP and 3221 HTTPS flood attacks on a company web server. 3223 3225 flood_attack_mitigation 3226 3227 mitigate_http_and_https_flood_attack 3228 3229 3230 192.0.2.0/24 3231 3232 3233 3234 3235 80 3236 80 3237 3238 3239 443 3240 443 3241 3242 3243 3244 3245 3246 3247 3248 anti-ddos 3249 3250 3251 3252 3253 3255 Figure 11: Configuration XML for General Firewall to Mitigate 3256 HTTP and HTTPS Flood Attacks on a Company Web Server 3258 3260 flood_attack_mitigation 3261 3262 mitigate_http_and_https_flood_attack 3263 3264 3265 1000 3266 3267 3268 3269 3270 drop 3271 3272 3273 3274 3276 Figure 12: Configuration XML for Anti-DDoS to Mitigate HTTP and 3277 HTTPS Flood Attacks on a Company Web Server 3279 Figure 11 and Figure 12 show the configuration XML documents for 3280 general firewall and HTTP and HTTPS flood attack mitigation to 3281 mitigate HTTP and HTTPS flood attacks on a company web server. For 3282 the security requirement, two NSFs (i.e., a general firewall and a 3283 HTTP and HTTPS flood attack mitigation) were used because one NSF can 3284 not meet the security requirement. The instances of XML documents 3285 for the general firewall and HTTP and HTTPS flood attack mitigation 3286 are as follows: Note that a detailed data model for the configuration 3287 of the advanced network security function (i.e., HTTP and HTTPS flood 3288 attack mitigation) can be defined as an extension in future. 3290 General Firewall is as follows: 3292 1. The name of the security policy is flood_attack_mitigation. 3294 2. The name of the rule is mitigate_http_and_https_flood_attack. 3296 3. The rule inspects a destination IPv4 address (i.e., 192.0.2.0/24) 3297 to inspect the access packets coming into the company web server. 3299 4. The rule inspects a port number (i.e., 80 and 443) to inspect 3300 HTTP and HTTPS packet. 3302 5. If the packets match the rules above, the general firewall sends 3303 the packets to anti-DDoS for additional inspection because the 3304 general firewall can not control the amount of packets for HTTP 3305 and HTTPS packets. 3307 Anti DDoS for HTTP and HTTPS Flood Attack Mitigation is as follows: 3309 1. The name of the security policy is flood_attack_mitigation. 3311 2. The name of the rule is mitigate_http_and_https_flood_attack. 3313 3. The rule controls the HTTTP and HTTPS packets according to the 3314 amount of incoming packets (1000 packets per second). 3316 4. If the incoming packets match the rules above, the packets are 3317 blocked. 3319 6. IANA Considerations 3321 This document requests IANA to register the following URI in the 3322 "IETF XML Registry" [RFC3688]: 3324 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-facing-interface 3325 Registrant Contact: The IESG. 3326 XML: N/A; the requested URI is an XML namespace. 3328 This document requests IANA to register the following YANG module in 3329 the "YANG Module Names" registry [RFC7950][RFC8525]: 3331 name: ietf-i2nsf-nsf-facing-interface 3332 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-facing-interface 3333 prefix: i2nsfnfi 3334 reference: RFC XXXX 3336 7. Security Considerations 3338 The YANG module specified in this document defines a data schema 3339 designed to be accessed through network management protocols such as 3340 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 3341 the secure transport layer, and the required secure transport is 3342 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 3343 and the required secure transport is TLS [RFC8446]. 3345 The NETCONF access control model [RFC8341] provides a means of 3346 restricting access to specific NETCONF or RESTCONF users to a 3347 preconfigured subset of all available NETCONF or RESTCONF protocol 3348 operations and content. 3350 There are a number of data nodes defined in this YANG module that are 3351 writable/creatable/deletable (i.e., config true, which is the 3352 default). These data nodes may be considered sensitive or vulnerable 3353 in some network environments. Write operations (e.g., edit-config) 3354 to these data nodes without proper protection can have a negative 3355 effect on network operations. These are the subtrees and data nodes 3356 and their sensitivity/vulnerability: 3358 * ietf-i2nsf-nsf-facing-interface: Writing to almost any element of 3359 this YANG module would directly impact on the configuration of 3360 NSFs, e.g., completely turning off security monitoring and 3361 mitigation capabilities; altering the scope of this monitoring and 3362 mitigation; creating an overwhelming logging volume to overwhelm 3363 downstream analytics or storage capacity; creating logging 3364 patterns which are confusing; or rendering useless trained 3365 statistics or artificial intelligence models. 3367 Some of the readable data nodes in this YANG module may be considered 3368 sensitive or vulnerable in some network environments. It is thus 3369 important to control read access (e.g., via get, get-config, or 3370 notification) to these data nodes. These are the subtrees and data 3371 nodes and their sensitivity/vulnerability: 3373 * ietf-i2nsf-nsf-facing-interface: The attacker may gather the 3374 security policy information of any target NSFs and misuse the 3375 security policy information for subsequent attacks. 3377 Policy rules identifying the specified users and user groups can be 3378 specified with "rules/condition/context/users". As with other data 3379 in this YANG module, this user information is provided by the 3380 Security Controller to the NSFs and is protected via the transport 3381 and access control mechanisms described above. 3383 8. References 3385 8.1. Normative References 3387 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3388 DOI 10.17487/RFC0768, August 1980, 3389 . 3391 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3392 DOI 10.17487/RFC0791, September 1981, 3393 . 3395 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3396 RFC 792, DOI 10.17487/RFC0792, September 1981, 3397 . 3399 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 3400 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 3401 1983, . 3403 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 3404 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 3405 . 3407 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 3408 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 3409 . 3411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3412 Requirement Levels", BCP 14, RFC 2119, 3413 DOI 10.17487/RFC2119, March 1997, 3414 . 3416 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 3417 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 3418 . 3420 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 3421 RFC 2595, DOI 10.17487/RFC2595, June 1999, 3422 . 3424 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3425 A., Peterson, J., Sparks, R., Handley, M., and E. 3426 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3427 DOI 10.17487/RFC3261, June 2002, 3428 . 3430 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3431 DOI 10.17487/RFC3688, January 2004, 3432 . 3434 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3435 Resource Identifier (URI): Generic Syntax", STD 66, 3436 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3437 . 3439 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 3440 Protocol Assigned Numbers", RFC 4250, 3441 DOI 10.17487/RFC4250, January 2006, 3442 . 3444 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3445 Congestion Control Protocol (DCCP)", RFC 4340, 3446 DOI 10.17487/RFC4340, March 2006, 3447 . 3449 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3450 Control Message Protocol (ICMPv6) for the Internet 3451 Protocol Version 6 (IPv6) Specification", STD 89, 3452 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3453 . 3455 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3456 DOI 10.17487/RFC5321, October 2008, 3457 . 3459 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 3460 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 3461 September 2009, . 3463 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 3464 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 3465 September 2009, . 3467 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3468 the Network Configuration Protocol (NETCONF)", RFC 6020, 3469 DOI 10.17487/RFC6020, October 2010, 3470 . 3472 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3473 and A. Bierman, Ed., "Network Configuration Protocol 3474 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3475 . 3477 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3478 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 3479 . 3481 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 3482 Cheshire, "Internet Assigned Numbers Authority (IANA) 3483 Procedures for the Management of the Service Name and 3484 Transport Protocol Port Number Registry", BCP 165, 3485 RFC 6335, DOI 10.17487/RFC6335, August 2011, 3486 . 3488 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3489 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3490 . 3492 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3493 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3494 . 3496 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3497 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3498 . 3500 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 3501 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 3502 the Constrained Application Protocol (CoAP)", RFC 8075, 3503 DOI 10.17487/RFC8075, February 2017, 3504 . 3506 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3507 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3508 May 2017, . 3510 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3511 (IPv6) Specification", STD 86, RFC 8200, 3512 DOI 10.17487/RFC8200, July 2017, 3513 . 3515 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 3516 Kumar, "Framework for Interface to Network Security 3517 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 3518 . 3520 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 3521 Boucadair, "PROBE: A Utility for Probing Interfaces", 3522 RFC 8335, DOI 10.17487/RFC8335, February 2018, 3523 . 3525 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3526 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3527 . 3529 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 3530 Access Control Model", STD 91, RFC 8341, 3531 DOI 10.17487/RFC8341, March 2018, 3532 . 3534 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 3535 and R. Wilton, "Network Management Datastore Architecture 3536 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 3537 . 3539 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 3540 Documents Containing YANG Data Models", BCP 216, RFC 8407, 3541 DOI 10.17487/RFC8407, October 2018, 3542 . 3544 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3545 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3546 . 3548 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 3549 "YANG Data Model for Network Access Control Lists (ACLs)", 3550 RFC 8519, DOI 10.17487/RFC8519, March 2019, 3551 . 3553 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 3554 and R. Wilton, "YANG Library", RFC 8525, 3555 DOI 10.17487/RFC8525, March 2019, 3556 . 3558 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message 3559 Access Protocol (IMAP) - Version 4rev2", RFC 9051, 3560 DOI 10.17487/RFC9051, August 2021, 3561 . 3563 [I-D.ietf-httpbis-http2bis] 3564 Thomson, M. and C. Benfield, "HTTP/2", Work in Progress, 3565 Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January 3566 2022, . 3569 [I-D.ietf-httpbis-messaging] 3570 Fielding, R. T., Nottingham, M., and J. Reschke, 3571 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 3572 httpbis-messaging-19, 12 September 2021, 3573 . 3576 [I-D.ietf-httpbis-semantics] 3577 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 3578 Semantics", Work in Progress, Internet-Draft, draft-ietf- 3579 httpbis-semantics-19, 12 September 2021, 3580 . 3583 [I-D.ietf-i2nsf-capability-data-model] 3584 Hares, S., Jeong, J. P., Kim, J. T., Moskowitz, R., and Q. 3585 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 3586 Internet-Draft, draft-ietf-i2nsf-capability-data-model-32, 3587 23 May 2022, . 3590 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 3591 Jeong, J. P., Lingga, P., Hares, S., Xia, L. F., and H. 3592 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 3593 Model", Work in Progress, Internet-Draft, draft-ietf- 3594 i2nsf-nsf-monitoring-data-model-19, 23 May 2022, 3595 . 3598 [I-D.ietf-tcpm-rfc793bis] 3599 Eddy, W. M., "Transmission Control Protocol (TCP) 3600 Specification", Work in Progress, Internet-Draft, draft- 3601 ietf-tcpm-rfc793bis-28, 7 March 2022, 3602 . 3605 [I-D.ietf-tsvwg-rfc4960-bis] 3606 Stewart, R. R., Tüxen, M., and K. E. E. Nielsen, "Stream 3607 Control Transmission Protocol", Work in Progress, 3608 Internet-Draft, draft-ietf-tsvwg-rfc4960-bis-19, 5 3609 February 2022, . 3612 8.2. Informative References 3614 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 3615 Denial-of-Service Considerations", RFC 4732, 3616 DOI 10.17487/RFC4732, December 2006, 3617 . 3619 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 3620 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 3621 . 3623 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 3624 Multiplexed and Secure Transport", RFC 9000, 3625 DOI 10.17487/RFC9000, May 2021, 3626 . 3628 [RFC9179] Hopps, C., "A YANG Grouping for Geographic Locations", 3629 RFC 9179, DOI 10.17487/RFC9179, February 2022, 3630 . 3632 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 3633 Jeong, J. P., Chung, C., Ahn, T., Kumar, R., and S. Hares, 3634 "I2NSF Consumer-Facing Interface YANG Data Model", Work in 3635 Progress, Internet-Draft, draft-ietf-i2nsf-consumer- 3636 facing-interface-dm-20, 23 May 2022, 3637 . 3640 [GLOB] "Linux Programmer's Manual - GLOB", 13 August 2020, 3641 . 3643 [ISO-3166] "Codes for the representation of names of countries and 3644 their subdivisions", ISO 3166, September 2018, 3645 . 3647 [IEEE-802.3] 3648 Institute of Electrical and Electronics Engineers, "IEEE 3649 Standard for Ethernet", 2018, 3650 . 3652 Appendix A. Acknowledgments 3654 This document is a product by the I2NSF Working Group (WG) including 3655 WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This 3656 document took advantage of the review and comments from the following 3657 people: Roman Danyliw, Acee Lindem, Dan Romascanu (GenART), Yoshifumi 3658 Nishida (TSVART), Kyle Rose (SecDir), Joe Clarke (OpsDir), and Tom 3659 Petch. The authors sincerely appreciate their sincere efforts and 3660 kind help. 3662 This work was supported by Institute of Information & Communications 3663 Technology Planning & Evaluation (IITP) grant funded by the Korea 3664 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 3665 Security Intelligence Technology Development for the Customized 3666 Security Service Provisioning). This work was supported in part by 3667 the IITP (2020-0-00395, Standard Development of Blockchain based 3668 Network Management Automation Technology). 3670 Appendix B. Contributors 3672 The following are co-authors of this document: 3674 Patrick Lingga - Department of Electrical and Computer Engineering, 3675 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3676 16419, Republic of Korea, EMail: patricklink@skku.edu 3677 Hyoungshick Kim - Department of Computer Science and Engineering, 3678 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3679 16419, Republic of Korea, EMail: hyoung@skku.edu 3681 Daeyoung Hyun - Department of Computer Science and Engineering, 3682 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3683 16419, Republic of Korea, EMail: dyhyun@skku.edu 3685 Dongjin Hong - Department of Electronic, Electrical and Computer 3686 Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, 3687 Gyeonggi-do 16419, Republic of Korea, EMail: dong.jin@skku.edu 3689 Liang Xia - Huawei, 101 Software Avenue, Nanjing, Jiangsu 210012, 3690 China, EMail: Frank.Xialiang@huawei.com 3692 Tae-Jin Ahn - Korea Telecom, 70 Yuseong-Ro, Yuseong-Gu, Daejeon, 3693 305-811, Republic of Korea, EMail: taejin.ahn@kt.com 3695 Se-Hui Lee - Korea Telecom, 70 Yuseong-Ro, Yuseong-Gu, Daejeon, 3696 305-811, Republic of Korea, EMail: sehuilee@kt.com 3698 Appendix C. Changes from draft-ietf-i2nsf-nsf-facing-interface-dm-28 3700 The following changes are made from draft-ietf-i2nsf-nsf-facing- 3701 interface-dm-28: 3703 * This version updated a 'leaf language' pattern by adding extra 3704 parentheses around "[A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za- 3705 z]{3}){0,2})?" and removing a range character '-' between 3706 characters 'Y' and 'Z' in "|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za- 3707 wy-z]" as 'Y' is alphabetically adjacent to 'Z'. 3709 Authors' Addresses 3711 Jinyong Tim Kim (editor) 3712 Department of Electronic, Electrical and Computer Engineering 3713 Sungkyunkwan University 3714 2066 Seobu-Ro, Jangan-Gu 3715 Suwon 3716 Gyeonggi-Do 3717 16419 3718 Republic of Korea 3719 Phone: +82 10 8273 0930 3720 Email: timkim@skku.edu 3721 Jaehoon Paul Jeong (editor) 3722 Department of Computer Science and Engineering 3723 Sungkyunkwan University 3724 2066 Seobu-Ro, Jangan-Gu 3725 Suwon 3726 Gyeonggi-Do 3727 16419 3728 Republic of Korea 3729 Phone: +82 31 299 4957 3730 Email: pauljeong@skku.edu 3731 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3733 Jung-Soo Park 3734 Electronics and Telecommunications Research Institute 3735 218 Gajeong-Ro, Yuseong-Gu 3736 Daejeon 3737 34129 3738 Republic of Korea 3739 Phone: +82 42 860 6514 3740 Email: pjs@etri.re.kr 3742 Susan Hares 3743 Huawei 3744 7453 Hickory Hill 3745 Saline, MI 48176 3746 United States of America 3747 Phone: +1-734-604-0332 3748 Email: shares@ndzh.com 3750 Qiushi Lin 3751 Huawei 3752 Huawei Industrial Base 3753 Shenzhen 3754 Guangdong 518129, 3755 China 3756 Email: linqiushi@huawei.com