idnits 2.17.1 draft-ietf-i2nsf-nsf-facing-interface-dm-22.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-i2nsf-capability-data-model]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 275 has weird spacing: '...w start ine...' == Line 282 has weird spacing: '...w start ine...' == Line 298 has weird spacing: '...w start ine...' == Line 305 has weird spacing: '...w start ine...' == Line 317 has weird spacing: '...er-port inet:...' == (24 more instances...) -- The document date (20 March 2022) is 768 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 8329 -- 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 (-32) exists of draft-ietf-i2nsf-capability-data-model-26 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-15 -- 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-16 Summary: 2 errors (**), 0 flaws (~~), 11 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: 21 September 2022 J. Park 6 ETRI 7 S. Hares 8 Q. Lin 9 Huawei 10 20 March 2022 12 I2NSF Network Security Function-Facing Interface YANG Data Model 13 draft-ietf-i2nsf-nsf-facing-interface-dm-22 15 Abstract 17 This document defines a YANG data model for configuring security 18 policy rules on Network Security Functions (NSF) in the Interface to 19 Network Security Functions (I2NSF) framework. The YANG data model in 20 this document corresponds to the data model in Capability data model 21 in the I2NSF framework [I-D.ietf-i2nsf-capability-data-model]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 21 September 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. General I2NSF Security Policy Rule . . . . . . . . . . . 3 60 3.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 12 63 4. YANG Data Model of NSF-Facing Interface . . . . . . . . . . . 14 64 4.1. YANG Module of NSF-Facing Interface . . . . . . . . . . . 14 65 5. XML Configuration Examples of Low-Level Security Policy 66 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 62 67 5.1. Example Security Requirement 1: Block Social Networking 68 Service (SNS) Access during Business Hours . . . . . . . 63 69 5.2. Example Security Requirement 2: Block Malicious VoIP/VoCN 70 Packets Coming to a Company . . . . . . . . . . . . . . . 66 71 5.3. Example Security Requirement 3: Mitigate HTTP and HTTPS 72 Flood Attacks on a Company Web Server . . . . . . . . . . 69 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 72 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 73 76 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 74 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 74 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 74 79 10.2. Informative References . . . . . . . . . . . . . . . . . 79 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 82 1. Introduction 84 This document defines a YANG [RFC6020][RFC7950] data model for 85 security policy rule configuration of Network Security Functions 86 (NSF). The YANG data model in this document is based on the data 87 model described in [I-D.ietf-i2nsf-capability-data-model] for the 88 NSF-Facing Interface in the Interface to Network Security Functions 89 (I2NSF) architecture [RFC8329]. The YANG data model in this document 90 focuses on security policy configuration for the NSFs discussed in 91 [I-D.ietf-i2nsf-capability-data-model], i.e., generic NSF (operate on 92 packet header for layer 2, layer3, and layer 4) and advanced NSF 93 (Intrusion Prevention System, URL-Filtering, anti-DDoS, Antivirus, 94 and VoIP/VoCN Filter). Note: VoIP is an abbreviation for Voice over 95 Internet Protocol and VoCN is an abbreviation for Voice over Cellular 96 Network, such as Voice over LTE or 5G. 98 This YANG data model uses an "Event-Condition-Action" (ECA) policy 99 model that is used as the basis for the design of I2NSF Policy 100 described in [RFC8329] and [I-D.ietf-i2nsf-capability-data-model]. 102 The "ietf-i2nsf-policy-rule-for-nsf" YANG module defined in this 103 document provides the configuration of the following features. 105 * A security policy rule of a network security function. 107 * An event clause of a generic network security function. 109 * A condition clause of a generic network security function. 111 * An action clause of a generic network security function. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 This document uses the terminology described in [RFC8329]. 123 This document follows the guidelines of [RFC8407], uses the common 124 YANG types defined in [RFC6991], and adopts the Network Management 125 Datastore Architecture (NMDA) [RFC8342]. The meaning of the symbols 126 in tree diagrams is defined in [RFC8340]. 128 3. YANG Tree Diagram 130 This section shows a YANG tree diagram of policy for network security 131 functions. [I-D.ietf-i2nsf-capability-data-model]. 133 3.1. General I2NSF Security Policy Rule 135 This section shows a YANG tree diagram for a general I2NSF security 136 policy rule for generic network security functions. 138 module: ietf-i2nsf-policy-rule-for-nsf 139 +--rw i2nsf-security-policy* [name] 140 +--rw name string 141 +--rw language? string 142 +--rw priority-usage? identityref 143 +--rw resolution-strategy? identityref 144 +--rw default-action? identityref 145 +--rw rules* [name] 146 | +--rw name string 147 | +--rw description? string 148 | +--rw priority? uint8 149 | +--rw enable? boolean 150 | +--rw long-connection 151 | | +--rw enable? boolean 152 | | +--rw duration? uint32 153 | +--rw event 154 | | ... 155 | +--rw condition 156 | | ... 157 | +--rw action 158 | ... 159 +--rw rule-group 160 +--rw groups* [group-name] 161 +--rw group-name string 162 +--rw rule-name* -> ../../../rules/name 163 +--rw enable? boolean 164 +--rw description? string 166 Figure 1: YANG Tree Diagram for Network Security Policy 168 A security policy is used by one virtual instance of an NSF/device as 169 a set of security rules to protect assets from major risk factors 170 that threaten the system. There can be multiple security policies in 171 a single NSF to provide the necessary protection. The security 172 policy includes its name, language tag, priority usage, resolution 173 strategy, default action, and rules. 175 The language field indicates the language tag that is used for the 176 natural language text that is included in all of the 'description' 177 attributes. The language field is encoded following the rules in 178 Section 2.1 of [RFC5646]. The default language tag is "en-US". 180 A resolution strategy is used to decide how to resolve conflicts that 181 occur between the actions of the same or different policy rules that 182 are matched and contained in a particular NSF. The resolution 183 strategy is defined as First Matching Rule (FMR), Last Matching Rule 184 (LMR), Prioritized Matching Rule (PMR) with Errors (PMRE), and 185 Prioritized Matching Rule with No Errors (PMRN). The resolution 186 strategy can be extended according to specific vendor action 187 features. The resolution strategy is described in detail in 188 [I-D.ietf-i2nsf-capability-data-model]. 190 A default action is used to execute I2NSF policy rule when no rule 191 matches a packet. The default action can be pass, drop, reject, 192 rate-limit, or mirror actions. The default action can be extended 193 according to specific vendor action features. The default action is 194 described in detail in [I-D.ietf-i2nsf-capability-data-model]. 196 The rules include rule name, rule description, rule priority, rule 197 enable, event, condition, and action. 199 3.2. Event Clause 201 This section shows a YANG tree diagram for an event clause for a 202 general I2NSF security policy rule for generic network security 203 functions. 205 module: ietf-i2nsf-policy-rule-for-nsf 206 +--rw i2nsf-security-policy* [name] 207 ... 208 +--rw rules* [name] 209 | ... 210 | +--rw event 211 | | +--rw description? string 212 | | +--rw system-event* identityref 213 | | +--rw system-alarm* identityref 214 | +--rw condition 215 | | ... 216 | +--rw action 217 | ... 218 +--rw rule-group 219 ... 221 Figure 2: YANG Tree Diagram for an Event Clause 223 An event clause is any important occurrence at a specific time of a 224 change in the system being managed, and/or in the environment of the 225 system being managed. An event clause is used to trigger the 226 evaluation of the condition clause of the I2NSF Policy Rule. The 227 event clause is defined as a system event, system alarm 228 [I-D.ietf-i2nsf-nsf-monitoring-data-model], and time. The event 229 clause can be extended according to specific vendor event features. 230 The event clause is described in detail in 231 [I-D.ietf-i2nsf-capability-data-model]. 233 3.3. Condition Clause 235 This section shows a YANG tree diagram for a condition clause for a 236 general I2NSF security policy rule for generic network security 237 functions. 239 module: ietf-i2nsf-policy-rule-for-nsf 240 +--rw i2nsf-security-policy* [name] 241 ... 242 +--rw rules* [name] 243 | ... 244 | +--rw event 245 | | ... 246 | +--rw condition 247 | | +--rw description? string 248 | | +--rw layer-2* [destination-mac-address source-mac-address 249 ethertype] 250 | | | +--rw description? string 251 | | | +--rw destination-mac-address yang:mac-address 252 | | | +--rw destination-mac-address-mask? yang:mac-address 253 | | | +--rw source-mac-address yang:mac-address 254 | | | +--rw source-mac-address-mask? yang:mac-address 255 | | | +--rw ethertype eth:ethertype 256 | | +--rw (layer-3)? 257 | | | +--:(ipv4) 258 | | | | +--rw ipv4 259 | | | | +--rw description? string 260 | | | | +--rw dscp? inet:dscp 261 | | | | +--rw ecn? uint8 262 | | | | +--rw length? uint16 263 | | | | +--rw ttl? uint8 264 | | | | +--rw protocol? uint8 265 | | | | +--rw ihl? uint8 266 | | | | +--rw flags? bits 267 | | | | +--rw offset? uint16 268 | | | | +--rw identification? uint16 269 | | | | +--rw (destination-network)? 270 | | | | | +--:(destination-ipv4-network) 271 | | | | | | +--rw destination-ipv4-network? 272 inet:ipv4-prefix 273 | | | | | +--:(destination-ipv4-range) 274 | | | | | +--rw destination-ipv4-range* [start end] 275 | | | | | +--rw start inet:ipv4-address-no-zone 276 | | | | | +--rw end inet:ipv4-address-no-zone 277 | | | | +--rw (source-network)? 278 | | | | +--:(source-ipv4-network) 279 | | | | | +--rw source-ipv4-network? inet:ipv4-prefix 280 | | | | +--:(source-ipv4-range) 281 | | | | +--rw source-ipv4-range* [start end] 282 | | | | +--rw start inet:ipv4-address-no-zone 283 | | | | +--rw end inet:ipv4-address-no-zone 284 | | | +--:(ipv6) 285 | | | +--rw ipv6 286 | | | +--rw description? string 287 | | | +--rw dscp? inet:dscp 288 | | | +--rw ecn? uint8 289 | | | +--rw length? uint16 290 | | | +--rw ttl? uint8 291 | | | +--rw protocol? uint8 292 | | | +--rw (destination-network)? 293 | | | | +--:(destination-ipv6-network) 294 | | | | | +--rw destination-ipv6-network? 295 inet:ipv6-prefix 296 | | | | +--:(destination-ipv6-range) 297 | | | | +--rw destination-ipv6-range* [start end] 298 | | | | +--rw start inet:ipv6-address-no-zone 299 | | | | +--rw end inet:ipv6-address-no-zone 300 | | | +--rw (source-network)? 301 | | | | +--:(source-ipv6-network) 302 | | | | | +--rw source-ipv6-network? inet:ipv6-prefix 303 | | | | +--:(source-ipv6-range) 304 | | | | +--rw source-ipv6-range* [start end] 305 | | | | +--rw start inet:ipv6-address-no-zone 306 | | | | +--rw end inet:ipv6-address-no-zone 307 | | | +--rw flow-label? inet:ipv6-flow-label 308 | | +--rw (layer-4)? 309 | | | +--:(tcp) 310 | | | | +--rw tcp 311 | | | | +--rw description? string 312 | | | | +--rw source-port-number 313 | | | | | +--rw (source-port)? 314 | | | | | +--:(range-or-operator) 315 | | | | | | +--rw (port-range-or-operator)? 316 | | | | | | +--:(range) 317 | | | | | | | +--rw lower-port inet:port-number 318 | | | | | | | +--rw upper-port inet:port-number 319 | | | | | | +--:(operator) 320 | | | | | | +--rw operator? operator 321 | | | | | | +--rw port inet:port-number 322 | | | | | +--:(port-list) 323 | | | | | +--rw port-numbers* [start end] 324 | | | | | +--rw start inet:port-number 325 | | | | | +--rw end inet:port-number 326 | | | | +--rw destination-port-number 327 | | | | | +--rw (destination-port)? 328 | | | | | +--:(range-or-operator) 329 | | | | | | +--rw (port-range-or-operator)? 330 | | | | | | +--:(range) 331 | | | | | | | +--rw lower-port inet:port-number 332 | | | | | | | +--rw upper-port inet:port-number 333 | | | | | | +--:(operator) 334 | | | | | | +--rw operator? operator 335 | | | | | | +--rw port inet:port-number 336 | | | | | +--:(port-list) 337 | | | | | +--rw port-numbers* [start end] 338 | | | | | +--rw start inet:port-number 339 | | | | | +--rw end inet:port-number 340 | | | | +--rw sequence-number? uint32 341 | | | | +--rw acknowledgement-number? uint32 342 | | | | +--rw data-offset? uint8 343 | | | | +--rw reserved? uint8 344 | | | | +--rw flags? bits 345 | | | | +--rw window-size? uint16 346 | | | | +--rw urgent-pointer? uint16 347 | | | | +--rw options? binary 348 | | | +--:(udp) 349 | | | | +--rw udp 350 | | | | +--rw description? string 351 | | | | +--rw source-port-number 352 | | | | | +--rw (source-port)? 353 | | | | | +--:(range-or-operator) 354 | | | | | | +--rw (port-range-or-operator)? 355 | | | | | | +--:(range) 356 | | | | | | | +--rw lower-port inet:port-number 357 | | | | | | | +--rw upper-port inet:port-number 358 | | | | | | +--:(operator) 359 | | | | | | +--rw operator? operator 360 | | | | | | +--rw port inet:port-number 361 | | | | | +--:(port-list) 362 | | | | | +--rw port-numbers* [start end] 363 | | | | | +--rw start inet:port-number 364 | | | | | +--rw end inet:port-number 365 | | | | +--rw destination-port-number 366 | | | | | +--rw (destination-port)? 367 | | | | | +--:(range-or-operator) 368 | | | | | | +--rw (port-range-or-operator)? 369 | | | | | | +--:(range) 370 | | | | | | | +--rw lower-port inet:port-number 371 | | | | | | | +--rw upper-port inet:port-number 372 | | | | | | +--:(operator) 373 | | | | | | +--rw operator? operator 374 | | | | | | +--rw port inet:port-number 375 | | | | | +--:(port-list) 376 | | | | | +--rw port-numbers* [start end] 377 | | | | | +--rw start inet:port-number 378 | | | | | +--rw end inet:port-number 379 | | | | +--rw length? uint16 380 | | | +--:(sctp) 381 | | | | +--rw sctp 382 | | | | +--rw description? string 383 | | | | +--rw source-port-number 384 | | | | | +--rw (source-port)? 385 | | | | | +--:(range-or-operator) 386 | | | | | | +--rw (port-range-or-operator)? 387 | | | | | | +--:(range) 388 | | | | | | | +--rw lower-port inet:port-number 389 | | | | | | | +--rw upper-port inet:port-number 390 | | | | | | +--:(operator) 391 | | | | | | +--rw operator? operator 392 | | | | | | +--rw port inet:port-number 393 | | | | | +--:(port-list) 394 | | | | | +--rw port-numbers* [start end] 395 | | | | | +--rw start inet:port-number 396 | | | | | +--rw end inet:port-number 397 | | | | +--rw destination-port-number 398 | | | | | +--rw (destination-port)? 399 | | | | | +--:(range-or-operator) 400 | | | | | | +--rw (port-range-or-operator)? 401 | | | | | | +--:(range) 402 | | | | | | | +--rw lower-port inet:port-number 403 | | | | | | | +--rw upper-port inet:port-number 404 | | | | | | +--:(operator) 405 | | | | | | +--rw operator? operator 406 | | | | | | +--rw port inet:port-number 407 | | | | | +--:(port-list) 408 | | | | | +--rw port-numbers* [start end] 409 | | | | | +--rw start inet:port-number 410 | | | | | +--rw end inet:port-number 411 | | | | +--rw chunk-type* uint8 412 | | | | +--rw chunk-length? uint16 413 | | | +--:(dccp) 414 | | | | +--rw dccp 415 | | | | +--rw description? string 416 | | | | +--rw source-port-number 417 | | | | | +--rw (source-port)? 418 | | | | | +--:(range-or-operator) 419 | | | | | | +--rw (port-range-or-operator)? 420 | | | | | | +--:(range) 421 | | | | | | | +--rw lower-port inet:port-number 422 | | | | | | | +--rw upper-port inet:port-number 423 | | | | | | +--:(operator) 424 | | | | | | +--rw operator? operator 425 | | | | | | +--rw port inet:port-number 426 | | | | | +--:(port-list) 427 | | | | | +--rw port-numbers* [start end] 428 | | | | | +--rw start inet:port-number 429 | | | | | +--rw end inet:port-number 430 | | | | +--rw destination-port-number 431 | | | | | +--rw (destination-port)? 432 | | | | | +--:(range-or-operator) 433 | | | | | | +--rw (port-range-or-operator)? 434 | | | | | | +--:(range) 435 | | | | | | | +--rw lower-port inet:port-number 436 | | | | | | | +--rw upper-port inet:port-number 437 | | | | | | +--:(operator) 438 | | | | | | +--rw operator? operator 439 | | | | | | +--rw port inet:port-number 440 | | | | | +--:(port-list) 441 | | | | | +--rw port-numbers* [start end] 442 | | | | | +--rw start inet:port-number 443 | | | | | +--rw end inet:port-number 444 | | | | +--rw service-code* uint32 445 | | | | +--rw type* uint8 446 | | | | +--rw data-offset? uint8 447 | | | +--:(icmp) 448 | | | +--rw icmp 449 | | | +--rw description? string 450 | | | +--rw version? enumeration 451 | | | +--rw type? uint8 452 | | | +--rw code? uint8 453 | | | +--rw rest-of-header? binary 454 | | +--rw url-category 455 | | | +--rw description? string 456 | | | +--rw pre-defined* string 457 | | | +--rw user-defined* string 458 | | +--rw voice 459 | | | +--rw description? string 460 | | | +--rw source-voice-id* string 461 | | | +--rw destination-voice-id* string 462 | | | +--rw user-agent* string 463 | | +--rw ddos 464 | | | +--rw description? string 465 | | | +--rw alert-packet-rate? uint32 466 | | | +--rw alert-flow-rate? uint32 467 | | | +--rw alert-byte-rate? uint32 468 | | +--rw anti-virus 469 | | | +--rw profile* string 470 | | | +--rw exception-files* string 471 | | +--rw payload 472 | | | +--rw description? string 473 | | | +--rw content* binary 474 | | +--rw context 475 | | +--rw description? string 476 | | +--rw time 477 | | | +--rw start-date-time? yang:date-and-time 478 | | | +--rw end-date-time? yang:date-and-time 479 | | | +--rw period 480 | | | | +--rw start-time? time 481 | | | | +--rw end-time? time 482 | | | | +--rw day* day 483 | | | | +--rw date* int8 484 | | | | +--rw month* string 485 | | | +--rw frequency? enumeration 486 | | +--rw application 487 | | | +--rw description? string 488 | | | +--rw protocol* identityref 489 | | +--rw device-type 490 | | | +--rw description? string 491 | | | +--rw device* identityref 492 | | +--rw users 493 | | | +--rw description? string 494 | | | +--rw user* [id] 495 | | | | +--rw id uint32 496 | | | | +--rw name? string 497 | | | +--rw group* [id] 498 | | | +--rw id uint32 499 | | | +--rw name? string 500 | | +--rw geographic-location 501 | | +--rw description? string 502 | | +--rw source* string 503 | | +--rw destination* string 504 | +--rw action 505 | ... 506 +--rw rule-group 507 ... 509 Figure 3: YANG Tree Diagram for a Condition Clause 511 A condition clause is defined as a set of attributes, features, and/ 512 or values that are to be compared with a set of known attributes, 513 features, and/or values in order to determine whether the set of 514 actions in that (imperative) I2NSF policy rule can be executed or 515 not. A condition clause works with 'AND' logic, where all fields set 516 in the condition MUST match the packet or flow for the condition to 517 be evaluated as 'TRUE'. A condition clause is classified as a 518 condition of generic network security functions, advanced network 519 security functions, or context. A condition clause of generic 520 network security functions is defined as IPv4 condition, IPv6 521 condition, TCP condition, UDP condition, SCTP condition, DCCP 522 condition, or ICMP (ICMPv4 and ICMPv6) condition. 524 Note that the data model in this document does not focus on only IP 525 addresses, but focuses on all the fields of IPv4 and IPv6 headers. 526 The IPv4 and IPv6 headers have similarity with some different fields. 527 In this case, it is better to handle separately the IPv4 and IPv6 528 headers such that the different fields can be used to handle IPv4 and 529 IPv6 packets. Also, note that the YANG data model in this document 530 is based on the YANG Data Model for Network Access Control Lists 531 (ACLs) [RFC8519] that does not support IPv6 extension headers 532 including various options, the support of IPv6 extension headers is 533 left as future work. 535 The data model provides transport layer condition for TCP, UDP, SCTP, 536 and DCCP. With ICMPv4 and ICMPv6 are included as a choice for layer 537 4 as the header fields in ICMP are above the network layer. Note 538 that QUIC protocol [RFC9000] is excluded in the data model as it is 539 not considered in the initial I2NSF documents [RFC8329]. The QUIC 540 traffic should not be treated as UDP traffic and will be considered 541 in the future I2NSF documents. 543 A condition clause of advanced network security functions is defined 544 as url category condition, voice condition, DDoS condition, or 545 payload condition. A condition clause of context is defined as 546 application condition, target condition, users condition, and 547 geography condition. 549 Note that this document deals only with conditions of several 550 advanced network security functions such as url filter (i.e., web 551 filter), VoIP/VoCN security, and DDoS-attack mitigator. A condition 552 clause of other advanced network security functions such as Intrusion 553 Prevention System (IPS) and Data Loss Prevention (DLP) can be defined 554 as an extension in future. A condition clause can be extended 555 according to specific vendor condition features. A condition clause 556 is described in detail in [I-D.ietf-i2nsf-capability-data-model]. 558 3.4. Action Clause 560 This section shows a YANG tree diagram for an action clause for a 561 general I2NSF security policy rule for generic network security 562 functions. 564 module: ietf-i2nsf-policy-rule-for-nsf 565 +--rw i2nsf-security-policy* [name] 566 ... 567 +--rw rules* [name] 568 | ... 569 | +--rw event 570 | ... 571 | +--rw condition 572 | ... 573 | +--rw action 574 | +--rw description? string 575 | +--rw packet-action 576 | | +--rw ingress-action? identityref 577 | | +--rw egress-action? identityref 578 | | +--rw log-action? identityref 579 | +--rw flow-action 580 | | +--rw ingress-action? identityref 581 | | +--rw egress-action? identityref 582 | | +--rw log-action? identityref 583 | +--rw advanced-action 584 | +--rw content-security-control* identityref 585 | +--rw attack-mitigation-control* identityref 586 +--rw rule-group 587 ... 589 Figure 4: YANG Tree Diagram for an Action Clause 591 An action is used to control and monitor aspects of flow-based NSFs 592 when the policy rule event and condition clauses are satisfied. NSFs 593 provide security services by executing various actions. The action 594 clause is defined as ingress action, egress action, or log action for 595 packet action, flow action, and advanced action for additional 596 inspection. The packet action is an action for an individual packet 597 such as an IP datagram as a stateless process that uses the packet's 598 header and payload. The flow action is an action of a traffic flow 599 such as the packets of a TCP session (e.g., an HTTP/HTTPS session) as 600 a stateful process that uses the traffic flow information such as 601 5-tuple information, packet counts, and byte counts. The advanced 602 action is an action for an advanced security service (e.g., url 603 filter, DDoS-attack mitigator, and VoIP/VoCN filter) for either a 604 packet or a traffic flow according to the intention of such an 605 advanced security service. The action clause can be extended 606 according to specific vendor action features. The action clause is 607 described in detail in [I-D.ietf-i2nsf-capability-data-model]. 609 Note that an empty event clause means that the event boolean will 610 always evaluate to true and starts the evaluation of the condition 611 clause, while an empty condition clause means that the condition 612 boolean will always evaluate to false. 614 4. YANG Data Model of NSF-Facing Interface 616 The main objective of this data model is to provide both an 617 information model and the corresponding YANG data model of I2NSF NSF- 618 Facing Interface. This interface can be used to deliver control and 619 management messages between Security Controller and NSFs for the 620 I2NSF low-level security policies. 622 This data model is designed to support the I2NSF framework that can 623 be extended according to the security needs. In other words, the 624 model design is independent of the content and meaning of specific 625 policies as well as the implementation approach. 627 With the YANG data model of I2NSF NSF-Facing Interface, this document 628 suggests use cases for security policy rules such as time-based 629 firewall, web filter, VoIP/VoCN security service, and DDoS-attack 630 mitigation in Section 5. 632 4.1. YANG Module of NSF-Facing Interface 634 This section describes a YANG module of NSF-Facing Interface. This 635 document provides identities in the data model for the configuration 636 of an NSF. The identity has the same concept with the corresponding 637 identity in [I-D.ietf-i2nsf-consumer-facing-interface-dm]. This YANG 638 module imports from [RFC6991] and [RFC8519]. It makes references to 639 [RFC0768] [RFC0791] [RFC0792] [RFC0854] [RFC0959] [RFC1939] [RFC2132] 640 [RFC2595] [RFC3261] [RFC3986] [RFC4250] [RFC4340] [RFC4443] [RFC4732] 641 [RFC4987] [RFC5321] [RFC5595] [RFC5646] [RFC6335] [RFC8075] [RFC8200] 642 [RFC8329] [RFC8335] [RFC9051] [IEEE-802.3] [ISO-3166] 643 [I-D.ietf-httpbis-http2bis] [I-D.ietf-httpbis-messaging] 644 [I-D.ietf-httpbis-semantics] [I-D.ietf-netmod-geo-location]. 645 [I-D.ietf-i2nsf-capability-data-model] 646 [I-D.ietf-i2nsf-nsf-monitoring-data-model] [I-D.ietf-tcpm-rfc793bis] 647 [I-D.ietf-tsvwg-rfc4960-bis] 649 file "ietf-i2nsf-policy-rule-for-nsf@2022-03-20.yang" 650 module ietf-i2nsf-policy-rule-for-nsf { 651 yang-version 1.1; 652 namespace 653 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"; 654 prefix 655 nsfintf; 657 import ietf-inet-types { 658 prefix inet; 659 reference 660 "Section 4 of RFC 6991"; 661 } 662 import ietf-yang-types { 663 prefix yang; 664 reference 665 "Section 3 of RFC 6991"; 666 } 667 import ietf-packet-fields { 668 prefix packet-fields; 669 reference 670 "Section 4.2 of RFC 8519"; 671 } 673 organization 674 "IETF I2NSF (Interface to Network Security Functions) 675 Working Group"; 677 contact 678 "WG Web: 679 WG List: 681 Editor: Jinyong Tim Kim 682 684 Editor: Jaehoon Paul Jeong 685 "; 687 description 688 "This module is a YANG module for Network Security Functions 689 (NSF)-Facing Interface. 691 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 692 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 693 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 694 document are to be interpreted as described in BCP 14 695 (RFC 2119) (RFC 8174) when, and only when, they appear 696 in all capitals, as shown here. 698 Copyright (c) 2022 IETF Trust and the persons identified as 699 authors of the code. All rights reserved. 701 Redistribution and use in source and binary forms, with or 702 without modification, is permitted pursuant to, and subject to 703 the license terms contained in, the Simplified BSD License set 704 forth in Section 4.c of the IETF Trust's Legal Provisions 705 Relating to IETF Documents 706 (https://trustee.ietf.org/license-info). 708 This version of this YANG module is part of RFC XXXX 709 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 710 for full legal notices."; 712 revision "2022-03-20"{ 713 description "The latest revision."; 714 reference 715 "RFC XXXX: I2NSF Network Security Function-Facing Interface 716 YANG Data Model"; 717 } 719 /* 720 * Identities 721 */ 723 identity priority-usage { 724 description 725 "Base identity for priority usage type to define the type of 726 priority to be implemented in a security policy rule, such 727 as priority by order and priority by number."; 728 } 730 identity priority-by-order { 731 base priority-usage; 732 description 733 "This indicates that the priority of a security policy rule 734 follows the order of the configuration. The earlier the 735 configuration is, the higher the priority is."; 736 } 738 identity priority-by-number { 739 base priority-usage; 740 description 741 "This indicates the priority of a security policy rule follows 742 the number or value of the configuration. The higher the value 743 is, the higher the priority is."; 744 } 746 identity event { 747 description 748 "Base identity for policy events."; 749 reference 750 "draft-ietf-i2nsf-nsf-monitoring-data-model-15: I2NSF NSF 751 Monitoring Interface YANG Data Model - Event"; 752 } 753 identity system-event { 754 base event; 755 description 756 "Base Identity for system events. System event (also called 757 alert) is defined as a warning about any changes of 758 configuration, any access violation, the information of 759 sessions and traffic flows."; 760 reference 761 "draft-ietf-i2nsf-nsf-monitoring-data-model-15: I2NSF NSF 762 Monitoring Interface YANG Data Model - System event"; 763 } 765 identity system-alarm { 766 base event; 767 description 768 "Base identity for system alarms. System alarm is defined as a 769 warning related to service degradation in system hardware."; 770 reference 771 "draft-ietf-i2nsf-nsf-monitoring-data-model-15: I2NSF NSF 772 Monitoring Interface YANG Data Model - System alarm"; 773 } 775 identity access-violation { 776 base system-event; 777 description 778 "Access-violation system event is an event when a user tries 779 to access (read, write, create, or delete) any information or 780 execute commands above their privilege (i.e., not-conformant 781 with the access profile)."; 782 reference 783 "draft-ietf-i2nsf-nsf-monitoring-data-model-15: I2NSF NSF 784 Monitoring Interface YANG Data Model - System event for access 785 violation"; 786 } 788 identity configuration-change { 789 base system-event; 790 description 791 "The configuration-change system event is an event when a user 792 adds a new configuration or modify an existing configuration 793 (write configuration)."; 794 reference 795 "draft-ietf-i2nsf-nsf-monitoring-data-model-15: I2NSF NSF 796 Monitoring Interface YANG Data Model - System event for 797 configuration change"; 798 } 800 identity memory-alarm { 801 base system-alarm; 802 description 803 "Memory is the hardware to store information temporarily or for 804 a short period, i.e., Random Access Memory (RAM). A 805 memory-alarm is emitted when the memory usage is exceeding 806 the threshold."; 807 reference 808 "draft-ietf-i2nsf-nsf-monitoring-data-model-15: I2NSF NSF 809 Monitoring Interface YANG Data Model - System alarm for 810 memory"; 811 } 813 identity cpu-alarm { 814 base system-alarm; 815 description 816 "CPU is the Central Processing Unit that executes basic 817 operations of the system. A cpu-alarm is emitted when the CPU 818 usage is exceeding a threshold."; 819 reference 820 "draft-ietf-i2nsf-nsf-monitoring-data-model-15: I2NSF NSF 821 Monitoring Interface YANG Data Model - System alarm for CPU"; 822 } 824 identity disk-alarm { 825 base system-alarm; 826 description 827 "Disk or storage is the hardware to store information for a 828 long period, i.e., Hard Disk and Solid-State Drive. A 829 disk-alarm is emitted when the disk usage is exceeding a 830 threshold."; 831 reference 832 "draft-ietf-i2nsf-nsf-monitoring-data-model-15: I2NSF NSF 833 Monitoring Interface YANG Data Model - System alarm for disk"; 834 } 836 identity hardware-alarm { 837 base system-alarm; 838 description 839 "A hardware alarm is emitted when a hardware failure (e.g., 840 CPU, memory, disk, or interface) is detected. A hardware 841 failure is a malfunction within the electronic circuits or 842 electromechanical components of the hardware that makes it 843 unusable."; 844 reference 845 "draft-ietf-i2nsf-nsf-monitoring-data-model-15: I2NSF NSF 846 Monitoring Interface YANG Data Model - System alarm for 847 hardware"; 848 } 849 identity interface-alarm { 850 base system-alarm; 851 description 852 "Interface is the network interface for connecting a device 853 with the network. The interface-alarm is emitted when the 854 state of the interface is changed."; 855 reference 856 "draft-ietf-i2nsf-nsf-monitoring-data-model-15: I2NSF NSF 857 Monitoring Interface YANG Data Model - System alarm for 858 interface"; 859 } 861 identity device-type { 862 description 863 "Base identity for types of device. This identity is used for 864 type of the device for the source or destination of a packet 865 or traffic flow. Note that the device type of either a source 866 or destination can be known with the help of DHCP 867 Fingerprinting and the interaction between an NSF and a DHCP 868 server."; 869 reference 870 "draft-ietf-i2nsf-capability-data-model-26: I2NSF Capability 871 YANG Data Model 872 RFC 2132: DHCP Options and BOOTP Vendor Extensions - Vendor 873 Specific Information including device type, manufacturer, 874 and operating system as DHCP fingerprinting information"; 875 } 877 identity computer { 878 base device-type; 879 description 880 "Identity for computer such as personal computer (PC) 881 and server."; 882 } 884 identity mobile-phone { 885 base device-type; 886 description 887 "Identity for mobile-phone such as smartphone and 888 cellphone"; 889 } 891 identity voip-vocn-phone { 892 base device-type; 893 description 894 "Identity for VoIP (Voice over Internet Protocol) or VoCN 895 (Voice over Cellular Network, such as Voice over LTE or 5G) 896 phone"; 897 } 899 identity tablet { 900 base device-type; 901 description 902 "Identity for tablet devices"; 903 } 905 identity network-infrastructure-device { 906 base device-type; 907 description 908 "Identity for network infrastructure devices 909 such as switch, router, and access point"; 910 } 912 identity iot-device { 913 base device-type; 914 description 915 "Identity for Internet of Things (IoT) devices 916 such as sensors, actuators, and low-power 917 low-capacity computing devices"; 918 } 920 identity ot { 921 base device-type; 922 description 923 "Identity for Operational Technology (OT) devices (also 924 known as industrial control systems) that interact 925 with the physical environment and detect or cause direct 926 change through the monitoring and control of devices, 927 processes, and events such as programmable logic 928 controllers (PLCs), digital oscilloscopes, building 929 management systems (BMS), and fire control systems"; 930 } 932 identity vehicle { 933 base device-type; 934 description 935 "Identity for transportation vehicles that connect to and 936 share data through the Internet over Vehicle-to-Everything 937 (V2X) communications."; 938 } 940 identity advanced-nsf { 941 description 942 "Base identity for advanced Network Security Function (NSF) 943 capability. This can be used for advanced NSFs such as 944 Anti-DDoS Attack, IPS, URL-Filtering, Antivirus, 945 and VoIP/VoCN Filter."; 946 reference 947 "draft-ietf-i2nsf-capability-data-model-26: 948 I2NSF Capability YANG Data Model"; 949 } 951 identity content-security-control { 952 base advanced-nsf; 953 description 954 "Base identity for content security control. Content security 955 control is an NSF that evaluates the payload of a packet, 956 such as Intrusion Prevention System (IPS), URL Filter, 957 Antivirus, and VoIP/VoCN Filter."; 958 reference 959 "draft-ietf-i2nsf-capability-data-model-26: 960 I2NSF Capability YANG Data Model"; 961 } 963 identity ips { 964 base content-security-control; 965 description 966 "IPS (Intrusion Prevention System) prevents malicious activity 967 within a network"; 968 } 970 identity url-filtering { 971 base content-security-control; 972 description 973 "URL filtering limits access by comparing the web traffic's 974 URL with the URLs for web filtering in a database"; 975 } 977 identity anti-virus { 978 base content-security-control; 979 description 980 "Antivirus to protect the network by detecting and 981 removing viruses or malwares."; 982 } 984 identity voip-vocn-filtering { 985 base content-security-control; 986 description 987 "VoIP (Voice over Internet Protocol) and VoCN (Voice over 988 Cellular Network, such as Voice over LTE or 5G) security 989 service that filters out the packets or flows of malicious 990 users with a deny-list of malicious users in a database"; 991 } 992 identity attack-mitigation-control { 993 base advanced-nsf; 994 description 995 "Base identity for attack mitigation control. Attack mitigation 996 control is an NSF that mitigates an attack such as 997 anti-DDoS (i.e., DDoS-mitigator)."; 998 reference 999 "draft-ietf-i2nsf-capability-data-model-26: 1000 I2NSF Capability YANG Data Model"; 1001 } 1003 identity anti-ddos { 1004 base attack-mitigation-control; 1005 description 1006 "Anti-DDoS or DDoS Mitigator to protect a server or network 1007 from a DDoS attack. The mitigation approach is up to the 1008 implementation."; 1009 reference 1010 "RFC 4732: Internet Denial-of-Service Considerations - DoS 1011 Mitigation Strategies 1012 RFC 4987: TCP SYN Flooding Attacks and Common Mitigations - 1013 Common Defenses"; 1014 } 1016 identity action { 1017 description 1018 "Base identity for action."; 1019 } 1021 identity ingress-action { 1022 base action; 1023 description 1024 "Base identity for ingress action. The action to handle the 1025 network traffic that is entering the secured network."; 1026 reference 1027 "draft-ietf-i2nsf-capability-data-model-26: 1028 I2NSF Capability YANG Data Model - Ingress Action"; 1029 } 1031 identity egress-action { 1032 base action; 1033 description 1034 "Base identity for egress action. The action to handle the 1035 network traffic that is exiting the secured network."; 1036 reference 1037 "draft-ietf-i2nsf-capability-data-model-26: 1038 I2NSF Capability YANG Data Model - Egress Action"; 1039 } 1040 identity default-action { 1041 base action; 1042 description 1043 "Base identity for default action. The default action of the 1044 NSF when no rule matches the packet or flow."; 1045 reference 1046 "draft-ietf-i2nsf-capability-data-model-26: 1047 I2NSF Capability YANG Data Model - Default Action"; 1048 } 1050 identity pass { 1051 base ingress-action; 1052 base egress-action; 1053 base default-action; 1054 description 1055 "The pass action allows traffic that matches 1056 the rule to proceed through the NSF to reach the 1057 destination."; 1058 reference 1059 "draft-ietf-i2nsf-capability-data-model-26: 1060 I2NSF Capability YANG Data Model - Actions and 1061 Default Action"; 1062 } 1064 identity drop { 1065 base ingress-action; 1066 base egress-action; 1067 base default-action; 1068 description 1069 "The drop action denies the traffic that 1070 matches the rule. The drop action should do a silent drop, 1071 which does not give any response to the source."; 1072 reference 1073 "draft-ietf-i2nsf-capability-data-model-26: 1074 I2NSF Capability YANG Data Model - Actions and 1075 Default Action"; 1076 } 1078 identity reject { 1079 base ingress-action; 1080 base egress-action; 1081 base default-action; 1082 description 1083 "The reject action denies a packet to go through the NSF 1084 entering or exiting the internal network and sends a response 1085 back to the source. The response depends on the packet and 1086 implementation. For example, a TCP packet is rejected with 1087 TCP RST response or a UDP packet may be rejected with an 1088 ICMPv4 response message with Type 3 Code 3 or ICMPv6 response 1089 message Type 1 Code 4 (i.e., Destination Unreachable: 1090 Destination port unreachable)."; 1091 } 1093 identity mirror { 1094 base ingress-action; 1095 base egress-action; 1096 base default-action; 1097 description 1098 "The mirror action copies a packet and sends the packet's copy 1099 to the monitoring entity while still allowing the packet or 1100 flow to go through the NSF."; 1101 reference 1102 "draft-ietf-i2nsf-capability-data-model-26: 1103 I2NSF Capability YANG Data Model - Actions and 1104 Default Action"; 1105 } 1107 identity rate-limit { 1108 base ingress-action; 1109 base egress-action; 1110 base default-action; 1111 description 1112 "The rate limit action limits the number of packets or flows 1113 that can go through the NSF by dropping packets or flows 1114 (randomly or systematically). The drop mechanism, e.g., silent 1115 drop and unreachable drop (i.e., reject), is up to the 1116 implementation"; 1117 reference 1118 "draft-ietf-i2nsf-capability-data-model-26: 1119 I2NSF Capability YANG Data Model - Actions and 1120 Default Action"; 1121 } 1123 identity log-action { 1124 base action; 1125 description 1126 "Base identity for log action"; 1127 } 1129 identity rule-log { 1130 base log-action; 1131 description 1132 "Log the policy rule that has been triggered by a packet or 1133 flow."; 1134 } 1135 identity session-log { 1136 base log-action; 1137 description 1138 "A session is a connection (i.e., traffic flow) of a data plane 1139 that includes source and destination information of IP 1140 addresses and transport port numbers with the protocol used. 1141 Log the session that triggered a policy rule."; 1142 } 1144 identity invoke-signaling { 1145 base egress-action; 1146 description 1147 "The invoke-signaling action is used to convey information of 1148 the event triggering this action to a monitoring entity."; 1149 } 1151 identity tunnel-encapsulation { 1152 base egress-action; 1153 description 1154 "The tunnel encapsulation action is used to encapsulate the 1155 packet to be tunneled across the network to enable a secure 1156 connection."; 1157 } 1159 identity forwarding { 1160 base egress-action; 1161 description 1162 "The forwarding action is used to relay the packet from one 1163 network segment to another node in the network."; 1164 } 1166 identity transformation { 1167 base egress-action; 1168 description 1169 "The transformation action is used to transform a packet by 1170 modifying it (e.g., HTTP-to-CoAP packet translation). 1171 Note that a subset of transformation (e.g., HTTP-to-CoAP) is 1172 handled in this YANG module, rather than all the existing 1173 transformations. Specific algorithmic transformations can be 1174 executed by a middlebox (e.g., NSF) for a given transformation 1175 name."; 1176 reference 1177 "RFC 8075: Guidelines for Mapping Implementations: HTTP to the 1178 Constrained Application Protocol (CoAP) - Translation between 1179 HTTP and CoAP."; 1180 } 1182 identity resolution-strategy { 1183 description 1184 "Base identity for resolution strategy"; 1185 reference 1186 "draft-ietf-i2nsf-capability-data-model-26: 1187 I2NSF Capability YANG Data Model - Resolution Strategy"; 1188 } 1190 identity fmr { 1191 base resolution-strategy; 1192 description 1193 "Conflict resolution with First Matching Rule (FMR)."; 1194 reference 1195 "draft-ietf-i2nsf-capability-data-model-26: 1196 I2NSF Capability YANG Data Model - Resolution Strategy"; 1197 } 1199 identity lmr { 1200 base resolution-strategy; 1201 description 1202 "Conflict resolution with Last Matching Rule (LMR)"; 1203 reference 1204 "draft-ietf-i2nsf-capability-data-model-26: 1205 I2NSF Capability YANG Data Model - Resolution Strategy"; 1206 } 1208 identity pmre { 1209 base resolution-strategy; 1210 description 1211 "Conflict resolution with Prioritized Matching Rule with 1212 Errors (PMRE)"; 1213 reference 1214 "draft-ietf-i2nsf-capability-data-model-26: 1215 I2NSF Capability YANG Data Model - Resolution Strategy"; 1216 } 1218 identity pmrn { 1219 base resolution-strategy; 1220 description 1221 "Conflict resolution with Prioritized Matching Rule with 1222 No Errors (PMRN)"; 1223 reference 1224 "draft-ietf-i2nsf-capability-data-model-26: 1225 I2NSF Capability YANG Data Model - Resolution Strategy"; 1226 } 1228 identity application-protocol { 1229 description 1230 "Base identity for Application protocol. Note that a subset of 1231 application protocols (e.g., HTTP, HTTPS, FTP, POP3, and 1232 IMAP) are handled in this YANG module, rather than all 1233 the existing application protocols."; 1234 } 1236 identity http { 1237 base application-protocol; 1238 description 1239 "The identity for Hypertext Transfer Protocol version 1.1 1240 (HTTP/1.1)."; 1241 reference 1242 "draft-ietf-httpbis-semantics-19: HTTP Semantics 1243 draft-ietf-httpbis-messaging-19: HTTP/1.1"; 1244 } 1246 identity https { 1247 base application-protocol; 1248 description 1249 "The identity for Hypertext Transfer Protocol version 1.1 1250 (HTTP/1.1) over TLS."; 1251 reference 1252 "draft-ietf-httpbis-semantics-19: HTTP Semantics 1253 draft-ietf-httpbis-messaging-19: HTTP/1.1"; 1254 } 1256 identity http2 { 1257 base application-protocol; 1258 description 1259 "The identity for Hypertext Transfer Protocol version 2 1260 (HTTP/2)."; 1261 reference 1262 "draft-ietf-httpbis-http2bis-07: HTTP/2"; 1263 } 1265 identity https2 { 1266 base application-protocol; 1267 description 1268 "The identity for Hypertext Transfer Protocol version 2 1269 (HTTP/2) over TLS."; 1270 reference 1271 "draft-ietf-httpbis-http2bis-07: HTTP/2"; 1272 } 1274 identity ftp { 1275 base application-protocol; 1276 description 1277 "The identity for File Transfer Protocol."; 1278 reference 1279 "RFC 959: File Transfer Protocol (FTP)"; 1280 } 1282 identity ssh { 1283 base application-protocol; 1284 description 1285 "The identity for Secure Shell (SSH) protocol."; 1286 reference 1287 "RFC 4250: The Secure Shell (SSH) Protocol"; 1288 } 1290 identity telnet { 1291 base application-protocol; 1292 description 1293 "The identity for telnet."; 1294 reference 1295 "RFC 854: Telnet Protocol"; 1296 } 1298 identity smtp { 1299 base application-protocol; 1300 description 1301 "The identity for Simple Mail Transfer Protocol."; 1302 reference 1303 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 1304 } 1306 identity pop3 { 1307 base application-protocol; 1308 description 1309 "The identity for Post Office Protocol 3 (POP3)."; 1310 reference 1311 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 1312 } 1314 identity pop3s { 1315 base application-protocol; 1316 description 1317 "The identity for Post Office Protocol 3 (POP3) over TLS"; 1318 reference 1319 "RFC 1939: Post Office Protocol - Version 3 (POP3) 1320 RFC 2595: Using TLS with IMAP, POP3 and ACAP"; 1321 } 1323 identity imap { 1324 base application-protocol; 1325 description 1326 "The identity for Internet Message Access Protocol (IMAP)."; 1328 reference 1329 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 1330 4rev2"; 1331 } 1333 identity imaps { 1334 base application-protocol; 1335 description 1336 "The identity for Internet Message Access Protocol (IMAP) over 1337 TLS"; 1338 reference 1339 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 1340 4rev2"; 1341 } 1343 /* 1344 * Typedefs 1345 */ 1347 typedef time { 1348 type string { 1349 pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' 1350 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 1351 } 1352 description 1353 "The time type represents an instance of time of zero-duration 1354 in the specified timezone that recurs every day."; 1355 } 1357 typedef day { 1358 type enumeration { 1359 enum monday { 1360 description 1361 "This represents Monday."; 1362 } 1363 enum tuesday { 1364 description 1365 "This represents Tuesday."; 1366 } 1367 enum wednesday { 1368 description 1369 "This represents Wednesday"; 1370 } 1371 enum thursday { 1372 description 1373 "This represents Thursday."; 1374 } 1375 enum friday { 1376 description 1377 "This represents Friday."; 1378 } 1379 enum saturday { 1380 description 1381 "This represents Saturday."; 1382 } 1383 enum sunday { 1384 description 1385 "This represents Sunday."; 1386 } 1387 } 1388 description 1389 "The type for representing the day of the week."; 1390 } 1392 /* 1393 * Groupings 1394 */ 1396 grouping port-range { 1397 leaf start { 1398 type inet:port-number; 1399 description 1400 "A start port number for a range match."; 1401 } 1402 leaf end { 1403 type inet:port-number; 1404 must '. >= ../start' { 1405 error-message 1406 "An end port number MUST be equal to or greater than a 1407 start port number."; 1408 } 1409 description 1410 "An end port number for a range match."; 1411 } 1412 description 1413 "A range match for port numbers. If only one value is needed, 1414 then set both start and end to the same value."; 1415 reference 1416 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 1417 (TCP) Specification - Port Number 1418 RFC 768: User Datagram Protocol - Port Number 1419 draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission 1420 Protocol - Port Number 1421 RFC 4340: Datagram Congestion Control Protocol (DCCP) 1422 - Port Number"; 1423 } 1424 grouping ipv4-range { 1425 description 1426 "A range match for IPv4 addresses. If only one value is 1427 needed, then set both start and end to the same value. 1428 The end IPv4 address MUST be equal to or greater than the 1429 start IPv4 address."; 1430 leaf start { 1431 type inet:ipv4-address-no-zone; 1432 description 1433 "A start IPv4 address for a range match."; 1434 } 1435 leaf end { 1436 type inet:ipv4-address-no-zone; 1437 description 1438 "An end IPv4 address for a range match."; 1439 } 1440 reference 1441 "RFC 791: Internet Protocol - IPv4 address"; 1442 } 1444 grouping ipv6-range { 1445 description 1446 "A range match for IPv6 addresses. If only one value is 1447 needed, then set both start and end to the same value. 1448 The end IPv6 address MUST be equal to or greater than the 1449 start IPv6 address."; 1450 leaf start { 1451 type inet:ipv6-address-no-zone; 1452 description 1453 "A start IPv6 address for a range match."; 1454 } 1456 leaf end { 1457 type inet:ipv6-address-no-zone; 1458 description 1459 "An end IPv6 address for a range match."; 1460 } 1461 reference 1462 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1463 Specification - IPv6 address"; 1464 } 1466 /* 1467 * Data nodes 1468 */ 1470 list i2nsf-security-policy { 1471 key "name"; 1473 description 1474 "Container for security policy 1475 including a set of security rules according to certain logic, 1476 i.e., their similarity or mutual relations, etc. The network 1477 security policy can be applied to both the unidirectional 1478 and bidirectional traffic across the NSF. 1479 The I2NSF security policies use the Event-Condition-Action 1480 (ECA) policy model "; 1482 reference 1483 "RFC 8329: Framework for Interface to Network Security 1484 Functions - I2NSF Flow Security Policy Structure 1485 draft-ietf-i2nsf-capability-data-model-26: 1486 I2NSF Capability YANG Data Model - Design Principles and 1487 ECA Policy Model Overview"; 1489 leaf name { 1490 type string; 1491 description 1492 "The name of the security policy. 1493 This must be unique."; 1494 } 1496 leaf language { 1497 type string { 1498 pattern '(([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})' 1499 + '{,2})?|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?' 1500 + '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}' 1501 + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za-wy-z]' 1502 + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]' 1503 + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|' 1504 + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-' 1505 + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-' 1506 + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-' 1507 + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]' 1508 + '|[Ii]-[Hh][Aa][Kk]|' 1509 + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|' 1510 + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|' 1511 + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|' 1512 + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|' 1513 + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|' 1514 + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-' 1515 + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-' 1516 + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-' 1517 + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|' 1518 + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-' 1519 + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|' 1520 + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-' 1521 + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-' 1522 + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))'; 1523 } 1524 default "en-US"; 1525 description 1526 "The value in this field indicates the language tag 1527 used for all of the 'leaf description' described in the 1528 'i2nsf-security-policy'. This field is mandatory only when 1529 one or more of the 'leaf description' is used. 1531 The attribute is encoded following the rules in Section 2.1 1532 in RFC 5646. The default language tag is 'en-US'"; 1533 reference 1534 "RFC 5646: Tags for Identifying Languages"; 1535 } 1537 leaf priority-usage { 1538 type identityref { 1539 base priority-usage; 1540 } 1541 default priority-by-order; 1542 description 1543 "Priority usage type for security policy rule: 1544 priority by order and priority by number"; 1545 } 1547 leaf resolution-strategy { 1548 type identityref { 1549 base resolution-strategy; 1550 } 1551 default fmr; 1552 description 1553 "The resolution strategies that can be used to 1554 specify how to resolve conflicts that occur between 1555 actions of the same or different policy rules that 1556 are matched and contained in this particular NSF"; 1558 reference 1559 "draft-ietf-i2nsf-capability-data-model-26: 1560 I2NSF Capability YANG Data Model - Resolution strategy"; 1561 } 1563 leaf default-action { 1564 type identityref { 1565 base default-action; 1566 } 1567 default mirror; 1568 description 1569 "This default action can be used to specify a predefined 1570 action when no other alternative action was matched 1571 by the currently executing I2NSF Policy Rule. An analogy 1572 is the use of a default statement in a C switch statement."; 1573 reference 1574 "draft-ietf-i2nsf-capability-data-model-26: 1575 I2NSF Capability YANG Data Model - Default Action"; 1576 } 1578 list rules { 1579 key "name"; 1580 description 1581 "This is a rule for network security functions."; 1583 leaf name { 1584 type string; 1585 description 1586 "The name of the rule."; 1587 } 1589 leaf description { 1590 type string; 1591 description 1592 "This description gives more information about 1593 rules."; 1594 } 1596 leaf priority { 1597 type uint8 { 1598 range "1..255"; 1599 } 1600 description 1601 "The priority for the rule comes with a mandatory 1602 numeric value which can range from 1 up to 255. 1603 Note that a higher number means a higher priority"; 1604 } 1606 leaf enable { 1607 type boolean; 1608 description 1609 "If true, the rule is enabled and enforced. 1610 If false, the rule is configured but disabled and not 1611 enforced."; 1612 } 1614 container long-connection { 1615 description 1616 "A container for long connection. A long connection is a 1617 connection that is maintained after the socket connection 1618 is established, regardless of whether it is used for data 1619 traffic or not."; 1621 leaf enable { 1622 type boolean; 1623 description 1624 "If true, the rule is enabled and enforced. 1625 If false, the rule is configured but disabled 1626 and not enforced."; 1627 } 1629 leaf duration { 1630 when "../enable = 'true'"; 1631 type uint32; 1632 units "second"; 1633 description 1634 "This is the maximum inactive connection duration of a 1635 long connection before a connection is declared as 1636 expired."; 1637 } 1638 } 1640 container event { 1641 description 1642 "An event is defined as any important 1643 occurrence in time of a change in the system being 1644 managed, and/or in the environment of the system being 1645 managed. When used in the context of policy rules for 1646 a flow-based NSF, it is used to determine whether the 1647 Condition clause of the Policy Rule can be evaluated 1648 or not. Examples of an I2NSF event include time and 1649 user actions (e.g., logon, logoff, and actions that 1650 violate any ACL.)."; 1652 reference 1653 "RFC 8329: Framework for Interface to Network Security 1654 Functions - I2NSF Flow Security Policy Structure 1655 draft-ietf-i2nsf-capability-data-model-26: 1656 I2NSF Capability YANG Data Model - Design Principles and 1657 ECA Policy Model Overview 1658 draft-ietf-i2nsf-nsf-monitoring-data-model-15: I2NSF 1659 NSF Monitoring Interface YANG Data Model - Alarms, 1660 Events, Logs, and Counters"; 1662 leaf description { 1663 type string; 1664 description 1665 "Description for an event clause"; 1666 } 1668 leaf-list system-event { 1669 type identityref { 1670 base system-event; 1671 } 1672 description 1673 "The security policy rule according to 1674 system events."; 1675 } 1677 leaf-list system-alarm { 1678 type identityref { 1679 base system-alarm; 1680 } 1681 description 1682 "The security policy rule according to 1683 system alarms."; 1684 } 1685 } 1687 container condition { 1688 description 1689 "A condition is defined as a set 1690 of attributes, features, and/or values that are to be 1691 compared with a set of known attributes, features, 1692 and/or values in order to determine whether the 1693 set of Actions in that (imperative) I2NSF Policy Rule 1694 can be executed or not. Examples of I2NSF Conditions 1695 include matching attributes of a packet or flow, and 1696 comparing the internal state of an NSF to a desired 1697 state. 1698 The condition works with 'AND' logic, where all 1699 fields set in a condition MUST match the packet or flow 1700 for the condition to be evaluated as 'TRUE'"; 1701 reference 1702 "RFC 8329: Framework for Interface to Network Security 1703 Functions - I2NSF Flow Security Policy Structure 1704 draft-ietf-i2nsf-capability-data-model-26: 1705 I2NSF Capability YANG Data Model - Design Principles and 1706 ECA Policy Model Overview"; 1708 leaf description { 1709 type string; 1710 description 1711 "Description for a condition clause."; 1712 } 1714 list layer-2 { 1715 key "destination-mac-address source-mac-address ethertype"; 1716 description 1717 "The purpose of this container is to represent layer 2 1718 packet header information to determine the set of policy 1719 actions in this ECA policy rule should be executed or 1720 not."; 1721 reference 1722 "IEEE 802.3: IEEE Standard for Ethernet"; 1724 leaf description { 1725 type string; 1726 description 1727 "The ethernet condition description"; 1728 } 1730 uses packet-fields:acl-eth-header-fields; 1731 } 1733 choice layer-3 { 1734 case ipv4 { 1735 container ipv4 { 1736 description 1737 "The purpose of this container is to represent 1738 IPv4 packet header information to determine if 1739 the set of policy actions in this ECA policy rule 1740 should be executed or not."; 1741 reference 1742 "RFC 791: Internet Protocol"; 1744 leaf description { 1745 type string; 1746 description 1747 "This is description for IPv4 condition."; 1748 } 1750 uses packet-fields:acl-ip-header-fields; 1751 uses packet-fields:acl-ipv4-header-fields { 1752 augment destination-network { 1753 case destination-ipv4-range { 1754 list destination-ipv4-range { 1755 key "start end"; 1756 uses ipv4-range; 1757 description 1758 "The list of IPv4 addresses specified with 1759 a start IPv4 address and an end IPv4 1760 address. If only one value is needed, then 1761 set both start and end to the same value. 1762 Note that the 'end' IPv4 address MUST be 1763 equal to or greater than the 'start' IPv4 1764 address."; 1765 } 1766 } 1767 description 1768 "IPv4 destination network denoted as IPv4 1769 addresses"; 1770 } 1771 augment source-network { 1772 case source-ipv4-range { 1773 list source-ipv4-range { 1774 key "start end"; 1775 uses ipv4-range; 1776 description 1777 "The list of IPv4 addresses specified with 1778 a start IPv4 address and an end IPv4 1779 address. If only one value is needed, then 1780 set both start and end to the same value. 1781 Note that the 'end' IPv4 address MUST be 1782 equal or greater than the 'start' IPv4 1783 address."; 1784 } 1785 } 1786 description 1787 "IPv4 source network denoted as IPv4 1788 addresses"; 1789 } 1790 } 1791 } 1792 } 1793 case ipv6 { 1794 container ipv6 { 1795 description 1796 "The purpose of this container is to represent IPv6 1797 packet header information to determine if the set 1798 of policy actions in this ECA policy rule should 1799 be executed or not."; 1801 reference 1802 "RFC 8200: Internet Protocol, Version 6 (IPv6) 1803 Specification"; 1805 leaf description { 1806 type string; 1807 description 1808 "This is description for IPv6 condition."; 1809 } 1811 uses packet-fields:acl-ip-header-fields; 1812 uses packet-fields:acl-ipv6-header-fields { 1813 augment destination-network { 1814 case destination-ipv6-range { 1815 list destination-ipv6-range { 1816 key "start end"; 1817 uses ipv6-range; 1818 description 1819 "The list of IPv6 addresses specified with 1820 a start IPv6 address and an end IPv6 1821 address. If only one value is needed, then 1822 set both start and end to the same value. 1823 Note that the 'end' IPv6 address MUST be 1824 equal to or greater than the 'start' IPv6 1825 address."; 1826 } 1827 } 1828 description 1829 "IPv6 destination network denoted as IPv6 1830 addresses"; 1831 } 1832 augment source-network { 1833 case source-ipv6-range { 1834 list source-ipv6-range { 1835 key "start end"; 1836 uses ipv6-range; 1837 description 1838 "The list of IPv6 addresses specified with 1839 a start IPv6 address and an end IPv6 1840 address. If only one value is needed, then 1841 set both start and end to the same value. 1842 Note that the 'end' IPv6 address MUST be 1843 equal to or greater than the 'start' IPv6 1844 address."; 1845 } 1846 } 1847 description 1848 "IPv6 source network denoted as IPv6 1849 addresses"; 1850 } 1851 } 1852 } 1853 } 1854 description 1855 "Choice of either IPv4 or IPv6 as layer-3 protocol"; 1856 } 1858 choice layer-4 { 1859 case tcp { 1860 container tcp { 1861 description 1862 "The purpose of this container is to represent 1863 TCP packet header information to determine 1864 if the set of policy actions in this ECA policy 1865 rule should be executed or not."; 1866 reference 1867 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 1868 Protocol (TCP) Specification"; 1870 leaf description { 1871 type string; 1872 description 1873 "This is description for tcp condition."; 1874 } 1876 container source-port-number { 1877 choice source-port { 1878 case range-or-operator { 1879 uses packet-fields:port-range-or-operator; 1880 description 1881 "Source port definition from range or operator. 1882 Can be used when a single port range to be 1883 specified."; 1884 } 1885 case port-list { 1886 list port-numbers { 1887 key "start end"; 1888 uses port-range; 1889 description 1890 "List of source port numbers."; 1891 } 1892 description 1893 "Source port definition from list of port 1894 numbers. In the case of multiple port ranges 1895 needed to be specified."; 1896 } 1897 description 1898 "The choice of source port definition using 1899 range/operator or a choice to use list of port 1900 numbers."; 1901 } 1902 description 1903 "The security policy rule according to 1904 tcp source port number."; 1905 reference 1906 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 1907 Protocol (TCP) Specification - Port Number"; 1908 } 1910 container destination-port-number { 1911 choice destination-port { 1912 case range-or-operator { 1913 uses packet-fields:port-range-or-operator; 1914 description 1915 "Destination port definition from range or 1916 operator. 1917 Can be used when a single port range to be 1918 specified."; 1919 } 1920 case port-list { 1921 list port-numbers { 1922 key "start end"; 1923 uses port-range; 1924 description 1925 "List of destination port numbers."; 1926 } 1927 description 1928 "Destination port definition from list of port 1929 numbers. 1930 In the case of multiple port ranges needed to 1931 be specified."; 1932 } 1933 description 1934 "The choice of destination port definition using 1935 range/operator or a choice to use list of port 1936 numbers."; 1937 } 1938 description 1939 "The security policy rule according to 1940 tcp destination port number."; 1941 reference 1942 "draft-ietf-tcpm-rfc793bis-25: Transmission Control 1943 Protocol (TCP) Specification - Port Number"; 1944 } 1946 uses packet-fields:acl-tcp-header-fields; 1947 } 1948 } 1949 case udp { 1950 container udp { 1951 description 1952 "The purpose of this container is to represent 1953 UDP packet header information to determine 1954 if the set of policy actions in this ECA policy 1955 rule should be executed or not."; 1956 reference 1957 "RFC 768: User Datagram Protocol"; 1959 leaf description { 1960 type string; 1961 description 1962 "This is description for udp condition."; 1963 } 1965 container source-port-number { 1966 choice source-port { 1967 case range-or-operator { 1968 uses packet-fields:port-range-or-operator; 1969 description 1970 "Source port definition from range or operator. 1971 Can be used when a single port range to be 1972 specified."; 1973 } 1974 case port-list { 1975 list port-numbers { 1976 key "start end"; 1977 uses port-range; 1978 description 1979 "List of source port numbers."; 1980 } 1981 description 1982 "Source port definition from list of port 1983 numbers. In the case of multiple port ranges 1984 needed to be specified."; 1985 } 1986 description 1987 "The choice of source port definition using 1988 range/operator or a choice to use list of port 1989 numbers."; 1990 } 1991 description 1992 "The security policy rule according to 1993 udp source port number."; 1994 reference 1995 "RFC 768: User Datagram Protocol - Port Number"; 1996 } 1997 container destination-port-number { 1998 choice destination-port { 1999 case range-or-operator { 2000 uses packet-fields:port-range-or-operator; 2001 description 2002 "Destination port definition from range or 2003 operator. 2004 Can be used when a single port range to be 2005 specified."; 2006 } 2007 case port-list { 2008 list port-numbers { 2009 key "start end"; 2010 uses port-range; 2011 description 2012 "List of destination port numbers."; 2013 } 2014 description 2015 "Destination port definition from list of port 2016 numbers. 2017 In the case of multiple port ranges needed to 2018 be specified."; 2019 } 2020 description 2021 "The choice of destination port definition using 2022 range/operator or a choice to use list of port 2023 numbers."; 2024 } 2025 description 2026 "The security policy rule according to 2027 udp destination port number."; 2028 reference 2029 "RFC 768: User Datagram Protocol - Port Number"; 2030 } 2032 uses packet-fields:acl-udp-header-fields; 2033 } 2034 } 2036 case sctp { 2037 container sctp { 2038 description 2039 "The purpose of this container is to represent 2040 SCTP packet header information to determine 2041 if the set of policy actions in this ECA policy 2042 rule should be executed or not."; 2044 leaf description { 2045 type string; 2046 description 2047 "This is description for sctp condition."; 2048 } 2050 container source-port-number { 2051 choice source-port { 2052 case range-or-operator { 2053 uses packet-fields:port-range-or-operator; 2054 description 2055 "Source port definition from range or operator. 2056 Can be used when a single port range to be 2057 specified."; 2058 } 2059 case port-list { 2060 list port-numbers { 2061 key "start end"; 2062 uses port-range; 2063 description 2064 "List of source port numbers."; 2065 } 2066 description 2067 "Source port definition from list of port 2068 numbers. In the case of multiple port ranges 2069 needed to be specified."; 2070 } 2071 description 2072 "The choice of source port definition using 2073 range/operator or a choice to use list of port 2074 numbers."; 2075 } 2076 description 2077 "The security policy rule according to 2078 sctp source port number."; 2079 reference 2080 "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control 2081 Transmission Protocol - Port number"; 2082 } 2084 container destination-port-number { 2085 choice destination-port { 2086 case range-or-operator { 2087 uses packet-fields:port-range-or-operator; 2088 description 2089 "Destination port definition from range or 2090 operator. 2091 Can be used when a single port range to be 2092 specified."; 2094 } 2095 case port-list { 2096 list port-numbers { 2097 key "start end"; 2098 uses port-range; 2099 description 2100 "List of destination port numbers."; 2101 } 2102 description 2103 "Destination port definition from list of port 2104 numbers. 2105 In the case of multiple port ranges needed to 2106 be specified."; 2107 } 2108 description 2109 "The choice of destination port definition using 2110 range/operator or a choice to use list of port 2111 numbers."; 2112 } 2113 description 2114 "The security policy rule according to 2115 sctp destination port number."; 2116 reference 2117 "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control 2118 Transmission Protocol - Port Number"; 2119 } 2121 leaf-list chunk-type { 2122 type uint8; 2123 description 2124 "The security policy rule according to 2125 sctp chunk type ID Value."; 2126 reference 2127 "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control 2128 Transmission Protocol - Chunk Type"; 2129 } 2131 leaf chunk-length { 2132 type uint16 { 2133 range "4..max"; 2134 } 2135 description 2136 "The security policy rule according to the length 2137 of the chunk in sctp. This value represents the 2138 size of the chunk in bytes, including the Chunk 2139 Type, Chunk Flags, Chunk Length, and Chunk Value 2140 fields."; 2141 reference 2142 "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control 2143 Transmission Protocol - Chunk Length"; 2144 } 2145 } 2146 } 2148 case dccp { 2149 container dccp { 2150 description 2151 "The purpose of this container is to represent 2152 DCCP packet header information to determine 2153 if the set of policy actions in this ECA policy 2154 rule should be executed or not."; 2155 leaf description { 2156 type string; 2157 description 2158 "This is description for dccp condition."; 2159 } 2161 container source-port-number { 2162 choice source-port { 2163 case range-or-operator { 2164 uses packet-fields:port-range-or-operator; 2165 description 2166 "Source port definition from range or operator. 2167 Can be used when a single port range to be 2168 specified."; 2169 } 2170 case port-list { 2171 list port-numbers { 2172 key "start end"; 2173 uses port-range; 2174 description 2175 "List of source port numbers."; 2176 } 2177 description 2178 "Source port definition from list of port 2179 numbers. In the case of multiple port ranges 2180 needed to be specified."; 2181 } 2182 description 2183 "The choice of source port definition using 2184 range/operator or a choice to use list of port 2185 numbers."; 2186 } 2187 description 2188 "The security policy rule according to 2189 dccp source port number."; 2191 reference 2192 "RFC 4340: Datagram Congestion Control Protocol 2193 (DCCP) - Port number"; 2194 } 2196 container destination-port-number { 2197 choice destination-port { 2198 case range-or-operator { 2199 uses packet-fields:port-range-or-operator; 2200 description 2201 "Destination port definition from range or 2202 operator. 2203 Can be used when a single port range to be 2204 specified."; 2205 } 2206 case port-list { 2207 list port-numbers { 2208 key "start end"; 2209 uses port-range; 2210 description 2211 "List of destination port numbers."; 2212 } 2213 description 2214 "Destination port definition from list of port 2215 numbers. In the case of multiple port ranges 2216 needed to be specified."; 2217 } 2218 description 2219 "The choice of destination port definition using 2220 range/operator or a choice to use list of port 2221 numbers."; 2222 } 2223 description 2224 "The security policy rule according to 2225 dccp destination port number."; 2226 reference 2227 "RFC 4340: Datagram Congestion Control Protocol 2228 (DCCP) - Port number"; 2229 } 2231 leaf-list service-code { 2232 type uint32; 2233 description 2234 "The security policy rule according to 2235 dccp service code."; 2236 reference 2237 "RFC 4340: Datagram Congestion Control Protocol 2238 (DCCP) - Service Codes 2240 RFC 5595: The Datagram Congestion Control Protocol 2241 (DCCP) Service Codes 2242 RFC 6335: Internet Assigned Numbers Authority 2243 (IANA) Procedures for the Management of 2244 the Service Name and Transport Protocol 2245 Port Number Registry - Service Code"; 2246 } 2248 leaf-list type { 2249 type uint8 { 2250 range "0..15"; 2251 } 2252 description 2253 "The security policy rule according to the 4 bits 2254 of dccp type header field for dccp packet types 2255 such as DCCP-Request, DCCP-Response, DCCP-Data, 2256 DCCP-Ack, and DCCP-DataAck."; 2257 reference 2258 "RFC 4340: Datagram Congestion Control Protocol 2259 (DCCP) - Packet Types"; 2260 } 2262 leaf data-offset { 2263 type uint8; 2264 description 2265 "The security policy rule according to the offset 2266 from 2267 the start of the packet's DCCP header to the start 2268 of its application data area, in 32-bit word."; 2269 reference 2270 "RFC 4340: Datagram Congestion Control Protocol 2271 (DCCP) - Data Offset"; 2272 } 2273 } 2274 } 2275 case icmp { 2276 container icmp { 2277 description 2278 "The purpose of this container is to represent 2279 ICMPv4 and ICMPv6 packet header information to 2280 determine if the set of policy actions in this ECA 2281 policy rule should be executed or not."; 2282 reference 2283 "RFC 792: Internet Control Message Protocol 2284 RFC 8335: PROBE: A Utility for Probing Interfaces"; 2286 leaf description { 2287 type string; 2288 description 2289 "This is description for icmp condition."; 2290 } 2292 leaf version { 2293 type enumeration { 2294 enum icmpv4 { 2295 value "1"; 2296 description 2297 "The ICMPv4 Protocol as defined in RFC 792"; 2298 } 2299 enum icmpv6 { 2300 value "2"; 2301 description 2302 "The ICMPv6 Protocol as defined in RFC 4443"; 2303 } 2304 } 2305 description 2306 "The ICMP version to be matched. This value 2307 affected the type and code values."; 2308 reference 2309 "RFC 792: Internet Control Message Protocol 2310 RFC 4443: Internet Control Message Protocol 2311 (ICMPv6) for the Internet Protocol 2312 Version 6 (IPv6) Specification"; 2313 } 2315 uses packet-fields:acl-icmp-header-fields; 2316 } 2317 } 2318 description 2319 "Choice of TCP, UDP, SCTP, DCCP, and ICMP as a layer-4 2320 protocol."; 2321 } 2323 container url-category { 2324 description 2325 "Condition for url category"; 2326 leaf description { 2327 type string; 2328 description 2329 "This is description for the condition of a URL's 2330 category such as SNS sites, game sites, ecommerce 2331 sites, company sites, and university sites."; 2332 } 2334 leaf-list pre-defined { 2335 type string; 2336 description 2337 "This is pre-defined-category. To specify the name of 2338 URL database."; 2339 } 2340 leaf-list user-defined { 2341 type string; 2342 description 2343 "This user-defined-category. To allow a user's manual 2344 addition of URLs for URL filtering."; 2345 reference 2346 "RFC 3986: Uniform Resource Identifier (URI): Generic 2347 Syntax"; 2348 } 2349 } 2351 container voice { 2352 description 2353 "For the VoIP/VoCN security system, a VoIP/ 2354 VoCN security system can monitor each 2355 VoIP/VoCN flow and manage VoIP/VoCN 2356 security rules controlled by a centralized 2357 server for VoIP/VoCN security service 2358 (called VoIP IPS). The VoIP/VoCN security 2359 system controls each switch for the 2360 VoIP/VoCN call flow management by 2361 manipulating the rules that can be added, 2362 deleted, or modified dynamically."; 2363 reference 2364 "RFC 3261: SIP: Session Initiation Protocol"; 2366 leaf description { 2367 type string; 2368 description 2369 "This is description for voice condition."; 2370 } 2372 leaf-list source-voice-id { 2373 type string; 2374 description 2375 "The security policy rule according to 2376 a source voice ID for VoIP and VoCN."; 2377 } 2379 leaf-list destination-voice-id { 2380 type string; 2381 description 2382 "The security policy rule according to 2383 a destination voice ID for VoIP and VoCN."; 2385 } 2387 leaf-list user-agent { 2388 type string; 2389 description 2390 "The security policy rule according to 2391 a user agent for VoIP and VoCN."; 2392 } 2393 } 2395 container ddos { 2396 description 2397 "Condition for DDoS attack."; 2399 leaf description { 2400 type string; 2401 description 2402 "This is description for ddos condition."; 2403 } 2405 leaf alert-packet-rate { 2406 type uint32; 2407 units "pps"; 2408 description 2409 "The alert rate of flood detection for 2410 packets per second (PPS) of an IP address. 2411 If the PPS of an IP address exceeds 2412 the alert rate threshold, an alert 2413 will be generated."; 2414 } 2416 leaf alert-flow-rate { 2417 type uint32; 2418 description 2419 "The alert rate of flood detection for the 2420 flow creating requests (e.g., new TCP connection 2421 establishment) per second of an IP address as 2422 either a source node or a destination node. If 2423 the flows per second of an IP address exceeds 2424 the alert rate threshold, an alert will be 2425 generated."; 2426 } 2428 leaf alert-byte-rate { 2429 type uint32; 2430 units "Bps"; 2431 description 2432 "The alert rate of flood detection for 2433 bytes per second (Bps) of an IP address. 2434 If the bytes per second of an IP address 2435 exceeds the alert rate threshold, an alert 2436 will be generated."; 2437 } 2438 } 2440 container anti-virus { 2441 description 2442 "Condition for antivirus"; 2444 leaf-list profile { 2445 type string; 2446 description 2447 "The security profile for antivirus. This is used to 2448 update the security profile for improving the 2449 security. The security profile is used to scan 2450 the viruses."; 2451 } 2453 leaf-list exception-files { 2454 type string; 2455 description 2456 "The type or name of the files to be excluded by the 2457 antivirus. This can be used to keep the known 2458 harmless files. 2459 If the value starts with a regular expression (e.g., 2460 '*.exe'), the antivirus should interpret it as a 2461 file pattern/type to be excluded. 2462 If the value does not start with a dot (e.g., 2463 'example.exe'), the antivirus should interpret it as 2464 a file name/path to be excluded."; 2465 } 2466 } 2468 container payload { 2469 description 2470 "Condition for packet payload"; 2471 leaf description { 2472 type string; 2473 description 2474 "This is description for payload condition."; 2475 } 2476 leaf-list content { 2477 type binary; 2478 description 2479 "This is a condition for packet payload content. 2480 The payload content is the binary stream contained 2481 by a security attack such as backdoor attack. It is 2482 usually used for Deep Packet Inspection (DPI)."; 2483 } 2484 } 2486 container context { 2487 description 2488 "Condition for context"; 2489 leaf description { 2490 type string; 2491 description 2492 "This is description for context condition."; 2493 } 2495 container time { 2496 description 2497 "Time to determine when the policy should be applied"; 2498 leaf start-date-time { 2499 type yang:date-and-time; 2500 description 2501 "This is the start date and time for a security 2502 policy rule."; 2503 } 2505 leaf end-date-time { 2506 type yang:date-and-time; 2507 description 2508 "This is the end date and time for a policy rule. 2509 The policy rule will stop working after the 2510 specified end-date-time."; 2511 } 2513 container period { 2514 when 2515 "../frequency!='only-once'"; 2516 description 2517 "This represents the repetition time. In the case 2518 where the frequency is weekly, the days can be 2519 set."; 2520 leaf start-time { 2521 type time; 2522 description 2523 "This is a period's start time for an event."; 2524 } 2525 leaf end-time { 2526 type time; 2527 description 2528 "This is a period's end time for an event."; 2530 } 2531 leaf-list day { 2532 when 2533 "../../frequency='weekly'"; 2534 type day; 2535 min-elements 1; 2536 description 2537 "This represents the repeated day of every week 2538 (e.g., Monday and Tuesday). More than one day 2539 can be specified."; 2540 } 2541 leaf-list date { 2542 when 2543 "../../frequency='monthly'"; 2544 type int8 { 2545 range "1..31"; 2546 } 2547 min-elements 1; 2548 description 2549 "This represents the repeated date of every month. 2550 More than one date can be specified."; 2551 } 2552 leaf-list month { 2553 when 2554 "../../frequency='yearly'"; 2555 type string{ 2556 pattern '\d{2}-\d{2}'; 2557 } 2558 min-elements 1; 2559 description 2560 "This represents the repeated date and month of 2561 every year. More than one can be specified. 2562 A pattern used here is Month and Date (MM-DD)."; 2563 } 2564 } 2566 leaf frequency { 2567 type enumeration { 2568 enum only-once { 2569 description 2570 "This represents that the rule is immediately 2571 enforced only once and not repeated. The policy 2572 will continuously be active from the start-time 2573 to the end-time."; 2574 } 2575 enum daily { 2576 description 2577 "This represents that the rule is enforced on a 2578 daily basis. The policy will be repeated 2579 daily until the end-date."; 2580 } 2581 enum weekly { 2582 description 2583 "This represents that the rule is enforced on a 2584 weekly basis. The policy will be repeated 2585 weekly until the end-date. The repeated days 2586 can be specified."; 2587 } 2588 enum monthly { 2589 description 2590 "This represents that the rule is enforced on a 2591 monthly basis. The policy will be repeated 2592 monthly until the end-date."; 2593 } 2594 enum yearly { 2595 description 2596 "This represents that the rule is enforced on 2597 a yearly basis. The policy will be repeated 2598 yearly until the end-date."; 2599 } 2600 } 2601 default only-once; 2602 description 2603 "This represents how frequently the rule 2604 should be enforced."; 2605 } 2606 } 2608 container application { 2609 description 2610 "Condition for application"; 2611 leaf description { 2612 type string; 2613 description 2614 "This is description for application condition."; 2615 } 2616 leaf-list protocol { 2617 type identityref { 2618 base application-protocol; 2619 } 2620 description 2621 "The condition based on the application layer 2622 protocol"; 2623 } 2624 } 2625 container device-type { 2626 description 2627 "Condition for type of the destination device"; 2628 leaf description { 2629 type string; 2630 description 2631 "This is description for destination device type 2632 condition. Vendors can write instructions for the 2633 condition that vendor made"; 2634 } 2636 leaf-list device { 2637 type identityref { 2638 base device-type; 2639 } 2640 description 2641 "The device attribute that can identify a device, 2642 including the device type (i.e., router, switch, 2643 pc, ios, or android) and the device's owner as 2644 well."; 2645 } 2646 } 2648 container users { 2649 description 2650 "Condition for users"; 2651 leaf description { 2652 type string; 2653 description 2654 "This is the description for users' condition."; 2655 } 2656 list user { 2657 key "id"; 2658 description 2659 "The user with which the traffic flow is associated 2660 can be identified by either a user ID or username. 2661 The user-to-IP address mapping is assumed to be 2662 provided by the unified user management system via 2663 network."; 2664 leaf id { 2665 type uint32; 2666 description 2667 "The ID of the user."; 2668 } 2669 leaf name { 2670 type string; 2671 description 2672 "The name of the user."; 2674 } 2675 } 2676 list group { 2677 key "id"; 2678 description 2679 "The user group with which the traffic flow is 2680 associated can be identified by either a group ID 2681 or group name. The group-to-IP address and 2682 user-to-group mappings are assumed to be provided by 2683 the unified user management system via network."; 2684 leaf id { 2685 type uint32; 2686 description 2687 "The ID of the group."; 2688 } 2689 leaf name { 2690 type string; 2691 description 2692 "The name of the group."; 2693 } 2694 } 2695 } 2697 container geographic-location { 2698 description 2699 "The location which network traffic flow is associated 2700 with. The region can be the geographic location such 2701 as country, province, and city, as well as the logical 2702 network location such as IP address, network section, 2703 and network domain."; 2704 reference 2705 "draft-ietf-netmod-geo-location-11: A YANG Grouping for 2706 Geographic Locations"; 2708 leaf description { 2709 type string; 2710 description 2711 "This is the description for the geographic location 2712 condition. It is used to describe the conditions and 2713 instructions that should be implemented."; 2714 } 2716 leaf-list source { 2717 type string; 2718 description 2719 "The source is a geographic location mapped into an 2720 IP address. It matches the mapped IP address to the 2721 source IP address of the traffic flow."; 2723 reference 2724 "ISO 3166: Codes for the representation of 2725 names of countries and their subdivisions 2726 draft-ietf-netmod-geo-location-11: A YANG Grouping 2727 for Geographic Locations"; 2728 } 2730 leaf-list destination { 2731 type string; 2732 description 2733 "The destination is a geographic location mapped into 2734 an IP address. It matches the mapped IP address to 2735 the destination IP address of the traffic flow."; 2736 reference 2737 "ISO 3166: Codes for the representation of 2738 names of countries and their subdivisions 2739 draft-ietf-netmod-geo-location-11: A YANG Grouping 2740 for Geographic Locations"; 2741 } 2742 } 2743 } 2744 } 2746 container action { 2747 description 2748 "An action is used to control and monitor aspects of 2749 flow-based NSFs when the event and condition clauses 2750 are satisfied. NSFs provide security functions by 2751 executing various Actions. Examples of I2NSF Actions 2752 include providing intrusion detection and/or protection, 2753 web and flow filtering, and deep packet inspection 2754 for packets and flows."; 2755 reference 2756 "RFC 8329: Framework for Interface to Network Security 2757 Functions - I2NSF Flow Security Policy Structure 2758 draft-ietf-i2nsf-capability-data-model-26: 2759 I2NSF Capability YANG Data Model - Design Principles and 2760 ECA Policy Model Overview"; 2762 leaf description { 2763 type string; 2764 description 2765 "Description for an action clause."; 2766 } 2768 container packet-action { 2769 description 2770 "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-26: 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-26: 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 } 2826 leaf egress-action { 2827 type identityref { 2828 base egress-action; 2829 } 2830 description 2831 "Egress action: pass, drop, reject, rate-limit, mirror, 2832 invoke-signaling, tunnel-encapsulation, forwarding, 2833 redirection, and transformation."; 2834 } 2836 leaf log-action { 2837 type identityref { 2838 base log-action; 2839 } 2840 description 2841 "Log action: rule log and session log"; 2842 } 2843 } 2845 container advanced-action { 2846 description 2847 "If the packet needs to be additionally inspected, 2848 the packet is passed to advanced network 2849 security functions according to the profile. 2850 The profile means the types of NSFs where the packet 2851 will be forwarded in order to additionally 2852 inspect the packet. 2853 The advanced action activates Service Function 2854 Chaining (SFC) for further inspection of a packet."; 2855 reference 2856 "draft-ietf-i2nsf-capability-data-model-26: 2857 I2NSF Capability YANG Data Model - YANG Tree 2858 Diagram"; 2860 leaf-list content-security-control { 2861 type identityref { 2862 base content-security-control; 2863 } 2864 description 2865 "Content-security-control is the NSFs that 2866 inspect the payload of the packet. 2867 The profile for the types of NSFs for mitigation is 2868 divided into content security control and 2869 attack-mitigation-control. 2870 Content security control: ips, url filtering, 2871 antivirus, and voip-vocn-filter. This can be 2872 extended according to the provided NSFs."; 2873 reference 2874 "draft-ietf-i2nsf-capability-data-model-26: 2875 I2NSF Capability YANG Data Model - YANG Tree Diagram"; 2876 } 2878 leaf-list attack-mitigation-control { 2879 type identityref { 2880 base attack-mitigation-control; 2881 } 2882 description 2883 "Attack-mitigation-control is the NSFs that weaken 2884 the attacks related to a denial-of-service (DoS) 2885 and reconnaissance. 2886 The profile for the types of NSFs for mitigation is 2887 divided into content security control and 2888 attack-mitigation-control. 2889 Attack mitigation control: Anti-DDoS or DDoS 2890 mitigator. This can be extended according to the 2891 provided NSFs such as mitigators for ip sweep, 2892 port scanning, ping of death, teardrop, oversized 2893 icmp, and tracert."; 2894 reference 2895 "draft-ietf-i2nsf-capability-data-model-26: 2896 I2NSF Capability YANG Data Model - YANG Tree Diagram"; 2897 } 2898 } 2899 } 2900 } 2901 container rule-group { 2902 description 2903 "This is rule group"; 2905 list groups { 2906 key "group-name"; 2907 description 2908 "This is a group for rules"; 2910 leaf group-name { 2911 type string; 2912 description 2913 "This is the name of the group for rules"; 2914 } 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-policy-rule-for-nsf 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-policy-rule-for-nsf 3332 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf 3333 prefix: nsfintf 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-policy-rule-for-nsf: 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-policy-rule-for-nsf: 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. Acknowledgments 3385 This document is a product by the I2NSF Working Group (WG) including 3386 WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This 3387 document took advantage of the review and comments from the following 3388 people: Roman Danyliw, Acee Lindem, Dan Romascanu (GenART), Yoshifumi 3389 Nishida (TSVART), Kyle Rose (SecDir), Joe Clarke (OpsDir), and Tom 3390 Petch. The authors sincerely appreciate their sincere efforts and 3391 kind help. 3393 This work was supported by Institute of Information & Communications 3394 Technology Planning & Evaluation (IITP) grant funded by the Korea 3395 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 3396 Security Intelligence Technology Development for the Customized 3397 Security Service Provisioning). This work was supported in part by 3398 the IITP (2020-0-00395, Standard Development of Blockchain based 3399 Network Management Automation Technology). 3401 9. Contributors 3403 The following are co-authors of this document: 3405 Patrick Lingga - Department of Electrical and Computer Engineering, 3406 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3407 16419, Republic of Korea, EMail: patricklink@skku.edu 3409 Hyoungshick Kim - Department of Computer Science and Engineering, 3410 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3411 16419, Republic of Korea, EMail: hyoung@skku.edu 3413 Daeyoung Hyun - Department of Computer Science and Engineering, 3414 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3415 16419, Republic of Korea, EMail: dyhyun@skku.edu 3417 Dongjin Hong - Department of Electronic, Electrical and Computer 3418 Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, 3419 Gyeonggi-do 16419, Republic of Korea, EMail: dong.jin@skku.edu 3421 Liang Xia - Huawei, 101 Software Avenue, Nanjing, Jiangsu 210012, 3422 China, EMail: Frank.Xialiang@huawei.com 3424 Tae-Jin Ahn - Korea Telecom, 70 Yuseong-Ro, Yuseong-Gu, Daejeon, 3425 305-811, Republic of Korea, EMail: taejin.ahn@kt.com 3427 Se-Hui Lee - Korea Telecom, 70 Yuseong-Ro, Yuseong-Gu, Daejeon, 3428 305-811, Republic of Korea, EMail: sehuilee@kt.com 3430 10. References 3432 10.1. Normative References 3434 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3435 DOI 10.17487/RFC0768, August 1980, 3436 . 3438 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3439 DOI 10.17487/RFC0791, September 1981, 3440 . 3442 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3443 RFC 792, DOI 10.17487/RFC0792, September 1981, 3444 . 3446 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 3447 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 3448 1983, . 3450 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 3451 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 3452 . 3454 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 3455 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 3456 . 3458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3459 Requirement Levels", BCP 14, RFC 2119, 3460 DOI 10.17487/RFC2119, March 1997, 3461 . 3463 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 3464 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 3465 . 3467 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 3468 RFC 2595, DOI 10.17487/RFC2595, June 1999, 3469 . 3471 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3472 A., Peterson, J., Sparks, R., Handley, M., and E. 3473 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3474 DOI 10.17487/RFC3261, June 2002, 3475 . 3477 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3478 DOI 10.17487/RFC3688, January 2004, 3479 . 3481 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3482 Resource Identifier (URI): Generic Syntax", STD 66, 3483 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3484 . 3486 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 3487 Protocol Assigned Numbers", RFC 4250, 3488 DOI 10.17487/RFC4250, January 2006, 3489 . 3491 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3492 Congestion Control Protocol (DCCP)", RFC 4340, 3493 DOI 10.17487/RFC4340, March 2006, 3494 . 3496 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3497 Control Message Protocol (ICMPv6) for the Internet 3498 Protocol Version 6 (IPv6) Specification", STD 89, 3499 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3500 . 3502 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3503 DOI 10.17487/RFC5321, October 2008, 3504 . 3506 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 3507 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 3508 September 2009, . 3510 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 3511 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 3512 September 2009, . 3514 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3515 the Network Configuration Protocol (NETCONF)", RFC 6020, 3516 DOI 10.17487/RFC6020, October 2010, 3517 . 3519 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3520 and A. Bierman, Ed., "Network Configuration Protocol 3521 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3522 . 3524 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3525 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 3526 . 3528 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 3529 Cheshire, "Internet Assigned Numbers Authority (IANA) 3530 Procedures for the Management of the Service Name and 3531 Transport Protocol Port Number Registry", BCP 165, 3532 RFC 6335, DOI 10.17487/RFC6335, August 2011, 3533 . 3535 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3536 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3537 . 3539 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3540 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3541 . 3543 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3544 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3545 . 3547 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 3548 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 3549 the Constrained Application Protocol (CoAP)", RFC 8075, 3550 DOI 10.17487/RFC8075, February 2017, 3551 . 3553 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3554 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3555 May 2017, . 3557 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3558 (IPv6) Specification", STD 86, RFC 8200, 3559 DOI 10.17487/RFC8200, July 2017, 3560 . 3562 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 3563 Kumar, "Framework for Interface to Network Security 3564 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 3565 . 3567 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 3568 Boucadair, "PROBE: A Utility for Probing Interfaces", 3569 RFC 8335, DOI 10.17487/RFC8335, February 2018, 3570 . 3572 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3573 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3574 . 3576 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 3577 Access Control Model", STD 91, RFC 8341, 3578 DOI 10.17487/RFC8341, March 2018, 3579 . 3581 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 3582 and R. Wilton, "Network Management Datastore Architecture 3583 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 3584 . 3586 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 3587 Documents Containing YANG Data Models", BCP 216, RFC 8407, 3588 DOI 10.17487/RFC8407, October 2018, 3589 . 3591 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3592 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3593 . 3595 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 3596 "YANG Data Model for Network Access Control Lists (ACLs)", 3597 RFC 8519, DOI 10.17487/RFC8519, March 2019, 3598 . 3600 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 3601 and R. Wilton, "YANG Library", RFC 8525, 3602 DOI 10.17487/RFC8525, March 2019, 3603 . 3605 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message 3606 Access Protocol (IMAP) - Version 4rev2", RFC 9051, 3607 DOI 10.17487/RFC9051, August 2021, 3608 . 3610 [I-D.ietf-httpbis-http2bis] 3611 Thomson, M. and C. Benfield, "HTTP/2", Work in Progress, 3612 Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January 3613 2022, . 3616 [I-D.ietf-httpbis-messaging] 3617 Fielding, R. T., Nottingham, M., and J. Reschke, 3618 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 3619 httpbis-messaging-19, 12 September 2021, 3620 . 3623 [I-D.ietf-httpbis-semantics] 3624 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 3625 Semantics", Work in Progress, Internet-Draft, draft-ietf- 3626 httpbis-semantics-19, 12 September 2021, 3627 . 3630 [I-D.ietf-i2nsf-capability-data-model] 3631 Hares, S., Jeong, J. (., Kim, J. (., Moskowitz, R., and Q. 3632 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 3633 Internet-Draft, draft-ietf-i2nsf-capability-data-model-26, 3634 10 February 2022, . 3637 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 3638 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 3639 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 3640 Model", Work in Progress, Internet-Draft, draft-ietf- 3641 i2nsf-nsf-monitoring-data-model-15, 15 February 2022, 3642 . 3645 [I-D.ietf-tcpm-rfc793bis] 3646 Eddy, W. M., "Transmission Control Protocol (TCP) 3647 Specification", Work in Progress, Internet-Draft, draft- 3648 ietf-tcpm-rfc793bis-28, 7 March 2022, 3649 . 3652 [I-D.ietf-tsvwg-rfc4960-bis] 3653 Stewart, R. R., Tüxen, M., and K. E. E. Nielsen, "Stream 3654 Control Transmission Protocol", Work in Progress, 3655 Internet-Draft, draft-ietf-tsvwg-rfc4960-bis-19, 5 3656 February 2022, . 3659 10.2. Informative References 3661 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 3662 Denial-of-Service Considerations", RFC 4732, 3663 DOI 10.17487/RFC4732, December 2006, 3664 . 3666 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 3667 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 3668 . 3670 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 3671 Multiplexed and Secure Transport", RFC 9000, 3672 DOI 10.17487/RFC9000, May 2021, 3673 . 3675 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 3676 Jeong, J. (., Chung, C., Ahn, T., Kumar, R., and S. Hares, 3677 "I2NSF Consumer-Facing Interface YANG Data Model", Work in 3678 Progress, Internet-Draft, draft-ietf-i2nsf-consumer- 3679 facing-interface-dm-16, 28 January 2022, 3680 . 3683 [I-D.ietf-netmod-geo-location] 3684 Hopps, C., "A YANG Grouping for Geographic Locations", 3685 Work in Progress, Internet-Draft, draft-ietf-netmod-geo- 3686 location-11, 24 October 2021, 3687 . 3690 [ISO-3166] "Codes for the representation of names of countries and 3691 their subdivisions", ISO 3166, September 2018, 3692 . 3694 [IEEE-802.3] 3695 Institute of Electrical and Electronics Engineers, "IEEE 3696 Standard for Ethernet", 2018, 3697 . 3699 Authors' Addresses 3701 Jinyong (Tim) Kim (editor) 3702 Department of Electronic, Electrical and Computer Engineering 3703 Sungkyunkwan University 3704 2066 Seobu-Ro, Jangan-Gu 3705 Suwon 3706 Gyeonggi-Do 3707 16419 3708 Republic of Korea 3709 Phone: +82 10 8273 0930 3710 Email: timkim@skku.edu 3712 Jaehoon (Paul) Jeong (editor) 3713 Department of Computer Science and Engineering 3714 Sungkyunkwan University 3715 2066 Seobu-Ro, Jangan-Gu 3716 Suwon 3717 Gyeonggi-Do 3718 16419 3719 Republic of Korea 3720 Phone: +82 31 299 4957 3721 Email: pauljeong@skku.edu 3722 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3723 Jung-Soo Park 3724 Electronics and Telecommunications Research Institute 3725 218 Gajeong-Ro, Yuseong-Gu 3726 Daejeon 3727 34129 3728 Republic of Korea 3729 Phone: +82 42 860 6514 3730 Email: pjs@etri.re.kr 3732 Susan Hares 3733 Huawei 3734 7453 Hickory Hill 3735 Saline, MI 48176 3736 United States of America 3737 Phone: +1-734-604-0332 3738 Email: shares@ndzh.com 3740 Qiushi Lin 3741 Huawei 3742 Huawei Industrial Base 3743 Shenzhen 3744 Guangdong 518129, 3745 China 3746 Email: linqiushi@huawei.com