idnits 2.17.1 draft-ietf-i2nsf-nsf-facing-interface-dm-25.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 (13 April 2022) is 742 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-29 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-17 -- 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-17 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: 15 October 2022 J. Park 6 ETRI 7 S. Hares 8 Q. Lin 9 Huawei 10 13 April 2022 12 I2NSF Network Security Function-Facing Interface YANG Data Model 13 draft-ietf-i2nsf-nsf-facing-interface-dm-25 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 15 October 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] [GLOB] [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-04-13.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 Revised 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-04-13"{ 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 + '{0,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. Absolute paths are filenames/paths 2459 to be excluded and relative ones are interpreted as 2460 globs."; 2461 reference 2462 "GLOB: Linux Programmer's Manual - GLOB"; 2463 } 2464 } 2466 container payload { 2467 description 2468 "Condition for packet payload"; 2469 leaf description { 2470 type string; 2471 description 2472 "This is description for payload condition."; 2473 } 2474 leaf-list content { 2475 type binary; 2476 description 2477 "This is a condition for packet payload content. 2478 The payload content is the binary stream contained 2479 by a security attack such as backdoor attack. It is 2480 usually used for Deep Packet Inspection (DPI)."; 2482 } 2483 } 2485 container context { 2486 description 2487 "Condition for context"; 2488 leaf description { 2489 type string; 2490 description 2491 "This is description for context condition."; 2492 } 2494 container time { 2495 description 2496 "Time to determine when the policy should be applied"; 2497 leaf start-date-time { 2498 type yang:date-and-time; 2499 description 2500 "This is the start date and time for a security 2501 policy rule."; 2502 } 2504 leaf end-date-time { 2505 type yang:date-and-time; 2506 description 2507 "This is the end date and time for a policy rule. 2508 The policy rule will stop working after the 2509 specified end-date-time."; 2510 } 2512 container period { 2513 when 2514 "../frequency!='only-once'"; 2515 description 2516 "This represents the repetition time. In the case 2517 where the frequency is weekly, the days can be 2518 set."; 2519 leaf start-time { 2520 type time; 2521 description 2522 "This is a period's start time for an event."; 2523 } 2524 leaf end-time { 2525 type time; 2526 description 2527 "This is a period's end time for an event."; 2528 } 2529 leaf-list day { 2530 when 2531 "../../frequency='weekly'"; 2532 type day; 2533 min-elements 1; 2534 description 2535 "This represents the repeated day of every week 2536 (e.g., Monday and Tuesday). More than one day 2537 can be specified."; 2538 } 2539 leaf-list date { 2540 when 2541 "../../frequency='monthly'"; 2542 type int8 { 2543 range "1..31"; 2544 } 2545 min-elements 1; 2546 description 2547 "This represents the repeated date of every month. 2548 More than one date can be specified."; 2549 } 2550 leaf-list month { 2551 when 2552 "../../frequency='yearly'"; 2553 type string{ 2554 pattern '\d{2}-\d{2}'; 2555 } 2556 min-elements 1; 2557 description 2558 "This represents the repeated date and month of 2559 every year. More than one can be specified. 2560 A pattern used here is Month and Date (MM-DD)."; 2561 } 2562 } 2564 leaf frequency { 2565 type enumeration { 2566 enum only-once { 2567 description 2568 "This represents that the rule is immediately 2569 enforced only once and not repeated. The policy 2570 will continuously be active from the start-time 2571 to the end-time."; 2572 } 2573 enum daily { 2574 description 2575 "This represents that the rule is enforced on a 2576 daily basis. The policy will be repeated 2577 daily until the end-date."; 2579 } 2580 enum weekly { 2581 description 2582 "This represents that the rule is enforced on a 2583 weekly basis. The policy will be repeated 2584 weekly until the end-date. The repeated days 2585 can be specified."; 2586 } 2587 enum monthly { 2588 description 2589 "This represents that the rule is enforced on a 2590 monthly basis. The policy will be repeated 2591 monthly until the end-date."; 2592 } 2593 enum yearly { 2594 description 2595 "This represents that the rule is enforced on 2596 a yearly basis. The policy will be repeated 2597 yearly until the end-date."; 2598 } 2599 } 2600 default only-once; 2601 description 2602 "This represents how frequently the rule 2603 should be enforced."; 2604 } 2605 } 2607 container application { 2608 description 2609 "Condition for application"; 2610 leaf description { 2611 type string; 2612 description 2613 "This is description for application condition."; 2614 } 2615 leaf-list protocol { 2616 type identityref { 2617 base application-protocol; 2618 } 2619 description 2620 "The condition based on the application layer 2621 protocol"; 2622 } 2623 } 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."; 2673 } 2674 } 2675 list group { 2676 key "id"; 2677 description 2678 "The user group with which the traffic flow is 2679 associated can be identified by either a group ID 2680 or group name. The group-to-IP address and 2681 user-to-group mappings are assumed to be provided by 2682 the unified user management system via network."; 2683 leaf id { 2684 type uint32; 2685 description 2686 "The ID of the group."; 2687 } 2688 leaf name { 2689 type string; 2690 description 2691 "The name of the group."; 2692 } 2693 } 2694 } 2696 container geographic-location { 2697 description 2698 "The location which network traffic flow is associated 2699 with. The region can be the geographic location such 2700 as country, province, and city, as well as the logical 2701 network location such as IP address, network section, 2702 and network domain."; 2703 reference 2704 "draft-ietf-netmod-geo-location-11: A YANG Grouping for 2705 Geographic Locations"; 2707 leaf description { 2708 type string; 2709 description 2710 "This is the description for the geographic location 2711 condition. It is used to describe the conditions and 2712 instructions that should be implemented."; 2713 } 2715 leaf-list source { 2716 type string; 2717 description 2718 "The source is a geographic location mapped into an 2719 IP address. It matches the mapped IP address to the 2720 source IP address of the traffic flow."; 2721 reference 2722 "ISO 3166: Codes for the representation of 2723 names of countries and their subdivisions 2724 draft-ietf-netmod-geo-location-11: A YANG Grouping 2725 for Geographic Locations"; 2726 } 2728 leaf-list destination { 2729 type string; 2730 description 2731 "The destination is a geographic location mapped into 2732 an IP address. It matches the mapped IP address to 2733 the destination IP address of the traffic flow."; 2734 reference 2735 "ISO 3166: Codes for the representation of 2736 names of countries and their subdivisions 2737 draft-ietf-netmod-geo-location-11: A YANG Grouping 2738 for Geographic Locations"; 2739 } 2740 } 2741 } 2742 } 2744 container action { 2745 description 2746 "An action is used to control and monitor aspects of 2747 flow-based NSFs when the event and condition clauses 2748 are satisfied. NSFs provide security functions by 2749 executing various Actions. Examples of I2NSF Actions 2750 include providing intrusion detection and/or protection, 2751 web and flow filtering, and deep packet inspection 2752 for packets and flows."; 2753 reference 2754 "RFC 8329: Framework for Interface to Network Security 2755 Functions - I2NSF Flow Security Policy Structure 2756 draft-ietf-i2nsf-capability-data-model-26: 2757 I2NSF Capability YANG Data Model - Design Principles and 2758 ECA Policy Model Overview"; 2760 leaf description { 2761 type string; 2762 description 2763 "Description for an action clause."; 2764 } 2766 container packet-action { 2767 description 2768 "Action for packets"; 2769 reference 2770 "RFC 8329: Framework for Interface to Network Security 2771 Functions - I2NSF Flow Security Policy Structure 2772 draft-ietf-i2nsf-capability-data-model-26: 2773 I2NSF Capability YANG Data Model - Design Principles and 2774 ECA Policy Model Overview"; 2776 leaf ingress-action { 2777 type identityref { 2778 base ingress-action; 2779 } 2780 description 2781 "Ingress Action: pass, drop, reject, rate-limit, and 2782 mirror."; 2783 } 2785 leaf egress-action { 2786 type identityref { 2787 base egress-action; 2788 } 2789 description 2790 "Egress action: pass, drop, reject, rate-limit, mirror, 2791 invoke-signaling, tunnel-encapsulation, forwarding, 2792 redirection, and transformation."; 2793 } 2795 leaf log-action { 2796 type identityref { 2797 base log-action; 2798 } 2799 description 2800 "Log action: rule log and session log"; 2801 } 2803 } 2805 container flow-action { 2806 description 2807 "Action for flows"; 2808 reference 2809 "RFC 8329: Framework for Interface to Network Security 2810 Functions - I2NSF Flow Security Policy Structure 2811 draft-ietf-i2nsf-capability-data-model-26: 2812 I2NSF Capability YANG Data Model - Design Principles and 2813 ECA Policy Model Overview"; 2815 leaf ingress-action { 2816 type identityref { 2817 base ingress-action; 2818 } 2819 description 2820 "Action: pass, drop, reject, rate-limit, and mirror."; 2821 } 2823 leaf egress-action { 2824 type identityref { 2825 base egress-action; 2826 } 2827 description 2828 "Egress action: pass, drop, reject, rate-limit, mirror, 2829 invoke-signaling, tunnel-encapsulation, forwarding, 2830 redirection, and transformation."; 2831 } 2833 leaf log-action { 2834 type identityref { 2835 base log-action; 2836 } 2837 description 2838 "Log action: rule log and session log"; 2839 } 2840 } 2842 container advanced-action { 2843 description 2844 "If the packet needs to be additionally inspected, 2845 the packet is passed to advanced network 2846 security functions according to the profile. 2847 The profile means the types of NSFs where the packet 2848 will be forwarded in order to additionally 2849 inspect the packet. 2850 The advanced action activates Service Function 2851 Chaining (SFC) for further inspection of a packet."; 2852 reference 2853 "draft-ietf-i2nsf-capability-data-model-26: 2854 I2NSF Capability YANG Data Model - YANG Tree 2855 Diagram"; 2857 leaf-list content-security-control { 2858 type identityref { 2859 base content-security-control; 2860 } 2861 description 2862 "Content-security-control is the NSFs that 2863 inspect the payload of the packet. 2864 The profile for the types of NSFs for mitigation is 2865 divided into content security control and 2866 attack-mitigation-control. 2868 Content security control: ips, url filtering, 2869 antivirus, and voip-vocn-filter. This can be 2870 extended according to the provided NSFs."; 2871 reference 2872 "draft-ietf-i2nsf-capability-data-model-26: 2873 I2NSF Capability YANG Data Model - YANG Tree Diagram"; 2874 } 2876 leaf-list attack-mitigation-control { 2877 type identityref { 2878 base attack-mitigation-control; 2879 } 2880 description 2881 "Attack-mitigation-control is the NSFs that weaken 2882 the attacks related to a denial-of-service (DoS) 2883 and reconnaissance. 2884 The profile for the types of NSFs for mitigation is 2885 divided into content security control and 2886 attack-mitigation-control. 2887 Attack mitigation control: Anti-DDoS or DDoS 2888 mitigator. This can be extended according to the 2889 provided NSFs such as mitigators for ip sweep, 2890 port scanning, ping of death, teardrop, oversized 2891 icmp, and tracert."; 2892 reference 2893 "draft-ietf-i2nsf-capability-data-model-26: 2894 I2NSF Capability YANG Data Model - YANG Tree Diagram"; 2895 } 2896 } 2897 } 2898 } 2899 container rule-group { 2900 description 2901 "This is rule group"; 2903 list groups { 2904 key "group-name"; 2905 description 2906 "This is a group for rules"; 2908 leaf group-name { 2909 type string; 2910 description 2911 "This is the name of the group for rules"; 2912 } 2914 leaf-list rule-name { 2915 type leafref { 2916 path 2917 "../../../rules/name"; 2918 } 2919 description 2920 "The names of the rules to be grouped."; 2921 } 2923 leaf enable { 2924 type boolean; 2925 description 2926 "If true, the rule is enabled and enforced. 2927 If false, the rule is configured but disabled 2928 and not enforced."; 2929 } 2931 leaf description { 2932 type string; 2933 description 2934 "This is a description for rule-group"; 2935 } 2936 } 2937 } 2938 } 2939 } 2940 2942 Figure 5: YANG Data Module of I2NSF NSF-Facing-Interface 2944 5. XML Configuration Examples of Low-Level Security Policy Rules 2946 This section shows XML configuration examples of low-level security 2947 policy rules that are delivered from the Security Controller to NSFs 2948 over the NSF-Facing Interface. For security requirements, we assume 2949 that the NSFs (i.e., General firewall, Time-based firewall, URL 2950 filter, VoIP/VoCN filter, and HTTP and HTTPS flood mitigation) 2951 described in Appendix A of [I-D.ietf-i2nsf-capability-data-model] are 2952 registered with the I2NSF framework. With the registered NSFs, we 2953 show configuration examples for security policy rules of network 2954 security functions according to the following three security 2955 requirements: (i) Block Social Networking Service (SNS) access during 2956 business hours, (ii) Block malicious VoIP/VoCN packets coming to the 2957 company, and (iii) Mitigate HTTP and HTTPS flood attacks on company 2958 web server. 2960 5.1. Example Security Requirement 1: Block Social Networking Service 2961 (SNS) Access during Business Hours 2963 This section shows a configuration example for blocking SNS access 2964 during business hours in IPv4 networks or IPv6 networks. 2966 2968 sns_access 2969 2970 block_sns_access_during_operation_time_for_ipv4 2971 2972 2973 192.0.2.0/24 2974 2975 2976 2990 2991 2992 2993 2994 2995 url-filtering 2996 2997 2998 2999 3000 3002 Figure 6: Configuration XML for Time-based Firewall to Block SNS 3003 Access during Business Hours in IPv4 Networks 3005 3007 sns_access 3008 3009 block_sns_access_during_operation_time_for_ipv6 3010 3011 3012 2001:db8:1::/60 3013 3014 3015 3029 3030 3031 3032 3033 3034 url-filtering 3035 3036 3037 3038 3039 3041 Figure 7: Configuration XML for Time-based Firewall to Block SNS 3042 Access during Business Hours in IPv6 Networks 3044 3046 sns_access 3047 3048 block_sns_access_during_operation_time 3049 3050 3051 SNS_1 3052 SNS_2 3053 3054 3055 3056 3057 drop 3058 3059 3060 3061 3063 Figure 8: Configuration XML for Web Filter to Block SNS Access 3064 during Business Hours 3066 Figure 6 and Figure 7 show the configuration XML documents for a 3067 time-based firewall for IPv4 and IPv6, respectively. Figure 8 shows 3068 the configuration XML document for a web filter. The two NSFs 3069 combined to block SNS access during business hours in IPv4 networks 3070 (or IPv6 networks). For the security requirement, two NSFs (i.e., a 3071 time-based firewall and a web filter) were used because one NSF 3072 cannot meet the security requirement. The instances of XML documents 3073 for the time-based firewall and the web filter are as follows: Note 3074 that a detailed data model for the configuration of the advanced 3075 network security function (i.e., web filter) can be defined as an 3076 extension in future. 3078 Time-based Firewall is as follows: 3080 1. The name of the security policy is sns_access. 3082 2. The name of the rule is 3083 block_sns_access_during_operation_time_for_ipv4 and 3084 block_sns_access_during_operation_time_for_ipv6. 3086 3. The rule is started from 2021-03-11 at 9 a.m. to 2021-12-31 at 6 3087 p.m. 3089 4. The rule is operated weekly every weekday (i.e., Monday, Tuesday, 3090 Wednesday, Thursday, and Friday) during the business hours (i.e., 3091 from 9 a.m. to 6 p.m.). 3093 5. The rule inspects a source IPv4 address (i.e., 192.0.2.0/24). 3094 For the case of IPv6 networks, the rule inspects a source IPv6 3095 address (i.e., from 2001:db8:1::/60). 3097 6. If the outgoing packets match the rules above, the time-based 3098 firewall sends the packets to url filtering for additional 3099 inspection because the time-based firewall can not inspect 3100 contents of the packets for the SNS URL. 3102 Web Filter is as follows: 3104 1. The name of the security policy is sns_access. 3106 2. The name of the rule is block_SNS_1_and_SNS_2. 3108 3. The rule inspects URL address to block the access packets to the 3109 SNS_1 or the SNS_2. 3111 4. If the outgoing packets match the rules above, the packets are 3112 blocked. 3114 5.2. Example Security Requirement 2: Block Malicious VoIP/VoCN Packets 3115 Coming to a Company 3117 This section shows a configuration example for blocking malicious 3118 VoIP/VoCN packets coming to a company. 3120 3122 voip_vocn_inspection 3123 3124 block_malicious_voice_id 3125 3126 3127 192.0.2.0/24 3128 3129 3130 3131 5060 3132 5061 3133 3134 3135 3136 3137 3138 3139 voip-vocn-filtering 3140 3141 3142 3143 3144 3146 Figure 9: Configuration XML for General Firewall to Block 3147 Malicious VoIP/VoCN Packets Coming to a Company 3149 3151 voip_vocn_inspection 3152 3153 block_malicious_voice_id 3154 3155 3156 3157 user1@voip.malicious.example.com 3158 3159 3160 user2@voip.malicious.example.com 3161 3162 3163 3164 3165 3166 drop 3167 3168 3169 3170 3172 Figure 10: Configuration XML for VoIP/VoCN Filter to Block 3173 Malicious VoIP/VoCN Packets Coming to a Company 3175 Figure 9 and Figure 10 show the configuration XML documents for 3176 general firewall and VoIP/VoCN filter to block malicious VoIP/VoCN 3177 packets coming to a company. For the security requirement, two NSFs 3178 (i.e., a general firewall and a VoIP/VoCN filter) were used because 3179 one NSF can not meet the security requirement. The instances of XML 3180 documents for the general firewall and the VoIP/VoCN filter are as 3181 follows: Note that a detailed data model for the configuration of the 3182 advanced network security function (i.e., VoIP/VoCN filter) can be 3183 described as an extension in future. 3185 General Firewall is as follows: 3187 1. The name of the security policy is voip_vocn_inspection. 3189 2. The name of the rule is block_malicious_voice_id. 3191 3. The rule inspects a destination IPv4 address (i.e., from 3192 192.0.2.0/24). 3194 4. The rule inspects a port number (i.e., 5060 and 5061) to inspect 3195 VoIP/VoCN packet. 3197 5. If the incoming packets match the rules above, the general 3198 firewall sends the packets to VoIP/VoCN filter for additional 3199 inspection because the general firewall can not inspect contents 3200 of the VoIP/VoCN packets. 3202 VoIP/VoCN Filter is as follows: 3204 1. The name of the security policy is malicious_voice_id. 3206 2. The name of the rule is block_malicious_voice_id. 3208 3. The rule inspects the voice ID of the VoIP/VoCN packets to block 3209 the malicious VoIP/VoCN packets (i.e., 3210 user1@voip.malicious.example.com and 3211 user2@voip.malicious.example.com). 3213 4. If the incoming packets match the rules above, the packets are 3214 blocked. 3216 5.3. Example Security Requirement 3: Mitigate HTTP and HTTPS Flood 3217 Attacks on a Company Web Server 3219 This section shows a configuration example for mitigating HTTP and 3220 HTTPS flood attacks on a company web server. 3222 3224 flood_attack_mitigation 3225 3226 mitigate_http_and_https_flood_attack 3227 3228 3229 192.0.2.0/24 3230 3231 3232 3233 3234 80 3235 80 3236 3237 3238 443 3239 443 3240 3241 3242 3243 3244 3245 3246 3247 anti-ddos 3248 3249 3250 3251 3252 3254 Figure 11: Configuration XML for General Firewall to Mitigate 3255 HTTP and HTTPS Flood Attacks on a Company Web Server 3257 3259 flood_attack_mitigation 3260 3261 mitigate_http_and_https_flood_attack 3262 3263 3264 1000 3265 3266 3267 3268 3269 drop 3270 3271 3272 3273 3275 Figure 12: Configuration XML for Anti-DDoS to Mitigate HTTP and 3276 HTTPS Flood Attacks on a Company Web Server 3278 Figure 11 and Figure 12 show the configuration XML documents for 3279 general firewall and HTTP and HTTPS flood attack mitigation to 3280 mitigate HTTP and HTTPS flood attacks on a company web server. For 3281 the security requirement, two NSFs (i.e., a general firewall and a 3282 HTTP and HTTPS flood attack mitigation) were used because one NSF can 3283 not meet the security requirement. The instances of XML documents 3284 for the general firewall and HTTP and HTTPS flood attack mitigation 3285 are as follows: Note that a detailed data model for the configuration 3286 of the advanced network security function (i.e., HTTP and HTTPS flood 3287 attack mitigation) can be defined as an extension in future. 3289 General Firewall is as follows: 3291 1. The name of the security policy is flood_attack_mitigation. 3293 2. The name of the rule is mitigate_http_and_https_flood_attack. 3295 3. The rule inspects a destination IPv4 address (i.e., 192.0.2.0/24) 3296 to inspect the access packets coming into the company web server. 3298 4. The rule inspects a port number (i.e., 80 and 443) to inspect 3299 HTTP and HTTPS packet. 3301 5. If the packets match the rules above, the general firewall sends 3302 the packets to anti-DDoS for additional inspection because the 3303 general firewall can not control the amount of packets for HTTP 3304 and HTTPS packets. 3306 Anti DDoS for HTTP and HTTPS Flood Attack Mitigation is as follows: 3308 1. The name of the security policy is flood_attack_mitigation. 3310 2. The name of the rule is mitigate_http_and_https_flood_attack. 3312 3. The rule controls the HTTTP and HTTPS packets according to the 3313 amount of incoming packets (1000 packets per second). 3315 4. If the incoming packets match the rules above, the packets are 3316 blocked. 3318 6. IANA Considerations 3320 This document requests IANA to register the following URI in the 3321 "IETF XML Registry" [RFC3688]: 3323 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf 3324 Registrant Contact: The IESG. 3325 XML: N/A; the requested URI is an XML namespace. 3327 This document requests IANA to register the following YANG module in 3328 the "YANG Module Names" registry [RFC7950][RFC8525]: 3330 name: ietf-i2nsf-policy-rule-for-nsf 3331 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf 3332 prefix: nsfintf 3333 reference: RFC XXXX 3335 7. Security Considerations 3337 The YANG module specified in this document defines a data schema 3338 designed to be accessed through network management protocols such as 3339 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 3340 the secure transport layer, and the required secure transport is 3341 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 3342 and the required secure transport is TLS [RFC8446]. 3344 The NETCONF access control model [RFC8341] provides a means of 3345 restricting access to specific NETCONF or RESTCONF users to a 3346 preconfigured subset of all available NETCONF or RESTCONF protocol 3347 operations and content. 3349 There are a number of data nodes defined in this YANG module that are 3350 writable/creatable/deletable (i.e., config true, which is the 3351 default). These data nodes may be considered sensitive or vulnerable 3352 in some network environments. Write operations (e.g., edit-config) 3353 to these data nodes without proper protection can have a negative 3354 effect on network operations. These are the subtrees and data nodes 3355 and their sensitivity/vulnerability: 3357 * ietf-i2nsf-policy-rule-for-nsf: Writing to almost any element of 3358 this YANG module would directly impact on the configuration of 3359 NSFs, e.g., completely turning off security monitoring and 3360 mitigation capabilities; altering the scope of this monitoring and 3361 mitigation; creating an overwhelming logging volume to overwhelm 3362 downstream analytics or storage capacity; creating logging 3363 patterns which are confusing; or rendering useless trained 3364 statistics or artificial intelligence models. 3366 Some of the readable data nodes in this YANG module may be considered 3367 sensitive or vulnerable in some network environments. It is thus 3368 important to control read access (e.g., via get, get-config, or 3369 notification) to these data nodes. These are the subtrees and data 3370 nodes and their sensitivity/vulnerability: 3372 * ietf-i2nsf-policy-rule-for-nsf: The attacker may gather the 3373 security policy information of any target NSFs and misuse the 3374 security policy information for subsequent attacks. 3376 Policy rules identifying the specified users and user groups can be 3377 specified with "rules/condition/context/users". As with other data 3378 in this YANG module, this user information is provided by the 3379 Security Controller to the NSFs and is protected via the transport 3380 and access control mechanisms described above. 3382 8. Acknowledgments 3384 This document is a product by the I2NSF Working Group (WG) including 3385 WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This 3386 document took advantage of the review and comments from the following 3387 people: Roman Danyliw, Acee Lindem, Dan Romascanu (GenART), Yoshifumi 3388 Nishida (TSVART), Kyle Rose (SecDir), Joe Clarke (OpsDir), and Tom 3389 Petch. The authors sincerely appreciate their sincere efforts and 3390 kind help. 3392 This work was supported by Institute of Information & Communications 3393 Technology Planning & Evaluation (IITP) grant funded by the Korea 3394 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 3395 Security Intelligence Technology Development for the Customized 3396 Security Service Provisioning). This work was supported in part by 3397 the IITP (2020-0-00395, Standard Development of Blockchain based 3398 Network Management Automation Technology). 3400 9. Contributors 3402 The following are co-authors of this document: 3404 Patrick Lingga - Department of Electrical and Computer Engineering, 3405 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3406 16419, Republic of Korea, EMail: patricklink@skku.edu 3408 Hyoungshick Kim - Department of Computer Science and Engineering, 3409 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3410 16419, Republic of Korea, EMail: hyoung@skku.edu 3412 Daeyoung Hyun - Department of Computer Science and Engineering, 3413 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 3414 16419, Republic of Korea, EMail: dyhyun@skku.edu 3416 Dongjin Hong - Department of Electronic, Electrical and Computer 3417 Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, 3418 Gyeonggi-do 16419, Republic of Korea, EMail: dong.jin@skku.edu 3420 Liang Xia - Huawei, 101 Software Avenue, Nanjing, Jiangsu 210012, 3421 China, EMail: Frank.Xialiang@huawei.com 3423 Tae-Jin Ahn - Korea Telecom, 70 Yuseong-Ro, Yuseong-Gu, Daejeon, 3424 305-811, Republic of Korea, EMail: taejin.ahn@kt.com 3426 Se-Hui Lee - Korea Telecom, 70 Yuseong-Ro, Yuseong-Gu, Daejeon, 3427 305-811, Republic of Korea, EMail: sehuilee@kt.com 3429 10. References 3431 10.1. Normative References 3433 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3434 DOI 10.17487/RFC0768, August 1980, 3435 . 3437 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3438 DOI 10.17487/RFC0791, September 1981, 3439 . 3441 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3442 RFC 792, DOI 10.17487/RFC0792, September 1981, 3443 . 3445 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 3446 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 3447 1983, . 3449 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 3450 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 3451 . 3453 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 3454 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 3455 . 3457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3458 Requirement Levels", BCP 14, RFC 2119, 3459 DOI 10.17487/RFC2119, March 1997, 3460 . 3462 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 3463 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 3464 . 3466 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 3467 RFC 2595, DOI 10.17487/RFC2595, June 1999, 3468 . 3470 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3471 A., Peterson, J., Sparks, R., Handley, M., and E. 3472 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3473 DOI 10.17487/RFC3261, June 2002, 3474 . 3476 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3477 DOI 10.17487/RFC3688, January 2004, 3478 . 3480 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3481 Resource Identifier (URI): Generic Syntax", STD 66, 3482 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3483 . 3485 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 3486 Protocol Assigned Numbers", RFC 4250, 3487 DOI 10.17487/RFC4250, January 2006, 3488 . 3490 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3491 Congestion Control Protocol (DCCP)", RFC 4340, 3492 DOI 10.17487/RFC4340, March 2006, 3493 . 3495 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3496 Control Message Protocol (ICMPv6) for the Internet 3497 Protocol Version 6 (IPv6) Specification", STD 89, 3498 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3499 . 3501 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3502 DOI 10.17487/RFC5321, October 2008, 3503 . 3505 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 3506 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 3507 September 2009, . 3509 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 3510 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 3511 September 2009, . 3513 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3514 the Network Configuration Protocol (NETCONF)", RFC 6020, 3515 DOI 10.17487/RFC6020, October 2010, 3516 . 3518 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3519 and A. Bierman, Ed., "Network Configuration Protocol 3520 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3521 . 3523 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3524 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 3525 . 3527 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 3528 Cheshire, "Internet Assigned Numbers Authority (IANA) 3529 Procedures for the Management of the Service Name and 3530 Transport Protocol Port Number Registry", BCP 165, 3531 RFC 6335, DOI 10.17487/RFC6335, August 2011, 3532 . 3534 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3535 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3536 . 3538 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3539 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3540 . 3542 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3543 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3544 . 3546 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 3547 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 3548 the Constrained Application Protocol (CoAP)", RFC 8075, 3549 DOI 10.17487/RFC8075, February 2017, 3550 . 3552 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3553 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3554 May 2017, . 3556 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3557 (IPv6) Specification", STD 86, RFC 8200, 3558 DOI 10.17487/RFC8200, July 2017, 3559 . 3561 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 3562 Kumar, "Framework for Interface to Network Security 3563 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 3564 . 3566 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 3567 Boucadair, "PROBE: A Utility for Probing Interfaces", 3568 RFC 8335, DOI 10.17487/RFC8335, February 2018, 3569 . 3571 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3572 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3573 . 3575 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 3576 Access Control Model", STD 91, RFC 8341, 3577 DOI 10.17487/RFC8341, March 2018, 3578 . 3580 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 3581 and R. Wilton, "Network Management Datastore Architecture 3582 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 3583 . 3585 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 3586 Documents Containing YANG Data Models", BCP 216, RFC 8407, 3587 DOI 10.17487/RFC8407, October 2018, 3588 . 3590 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3591 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3592 . 3594 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 3595 "YANG Data Model for Network Access Control Lists (ACLs)", 3596 RFC 8519, DOI 10.17487/RFC8519, March 2019, 3597 . 3599 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 3600 and R. Wilton, "YANG Library", RFC 8525, 3601 DOI 10.17487/RFC8525, March 2019, 3602 . 3604 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message 3605 Access Protocol (IMAP) - Version 4rev2", RFC 9051, 3606 DOI 10.17487/RFC9051, August 2021, 3607 . 3609 [I-D.ietf-httpbis-http2bis] 3610 Thomson, M. and C. Benfield, "HTTP/2", Work in Progress, 3611 Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January 3612 2022, . 3615 [I-D.ietf-httpbis-messaging] 3616 Fielding, R. T., Nottingham, M., and J. Reschke, 3617 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 3618 httpbis-messaging-19, 12 September 2021, 3619 . 3622 [I-D.ietf-httpbis-semantics] 3623 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 3624 Semantics", Work in Progress, Internet-Draft, draft-ietf- 3625 httpbis-semantics-19, 12 September 2021, 3626 . 3629 [I-D.ietf-i2nsf-capability-data-model] 3630 Hares, S., Jeong, J. (., Kim, J. (., Moskowitz, R., and Q. 3631 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 3632 Internet-Draft, draft-ietf-i2nsf-capability-data-model-29, 3633 25 March 2022, . 3636 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 3637 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 3638 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 3639 Model", Work in Progress, Internet-Draft, draft-ietf- 3640 i2nsf-nsf-monitoring-data-model-17, 13 April 2022, 3641 . 3644 [I-D.ietf-tcpm-rfc793bis] 3645 Eddy, W. M., "Transmission Control Protocol (TCP) 3646 Specification", Work in Progress, Internet-Draft, draft- 3647 ietf-tcpm-rfc793bis-28, 7 March 2022, 3648 . 3651 [I-D.ietf-tsvwg-rfc4960-bis] 3652 Stewart, R. R., Tüxen, M., and K. E. E. Nielsen, "Stream 3653 Control Transmission Protocol", Work in Progress, 3654 Internet-Draft, draft-ietf-tsvwg-rfc4960-bis-19, 5 3655 February 2022, . 3658 10.2. Informative References 3660 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 3661 Denial-of-Service Considerations", RFC 4732, 3662 DOI 10.17487/RFC4732, December 2006, 3663 . 3665 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 3666 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 3667 . 3669 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 3670 Multiplexed and Secure Transport", RFC 9000, 3671 DOI 10.17487/RFC9000, May 2021, 3672 . 3674 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 3675 Jeong, J. (., Chung, C., Ahn, T., Kumar, R., and S. Hares, 3676 "I2NSF Consumer-Facing Interface YANG Data Model", Work in 3677 Progress, Internet-Draft, draft-ietf-i2nsf-consumer- 3678 facing-interface-dm-17, 23 March 2022, 3679 . 3682 [I-D.ietf-netmod-geo-location] 3683 Hopps, C., "A YANG Grouping for Geographic Locations", 3684 Work in Progress, Internet-Draft, draft-ietf-netmod-geo- 3685 location-11, 24 October 2021, 3686 . 3689 [GLOB] "Linux Programmer's Manual - GLOB", 13 August 2020, 3690 . 3692 [ISO-3166] "Codes for the representation of names of countries and 3693 their subdivisions", ISO 3166, September 2018, 3694 . 3696 [IEEE-802.3] 3697 Institute of Electrical and Electronics Engineers, "IEEE 3698 Standard for Ethernet", 2018, 3699 . 3701 Authors' Addresses 3703 Jinyong (Tim) Kim (editor) 3704 Department of Electronic, Electrical and Computer Engineering 3705 Sungkyunkwan University 3706 2066 Seobu-Ro, Jangan-Gu 3707 Suwon 3708 Gyeonggi-Do 3709 16419 3710 Republic of Korea 3711 Phone: +82 10 8273 0930 3712 Email: timkim@skku.edu 3714 Jaehoon (Paul) Jeong (editor) 3715 Department of Computer Science and Engineering 3716 Sungkyunkwan University 3717 2066 Seobu-Ro, Jangan-Gu 3718 Suwon 3719 Gyeonggi-Do 3720 16419 3721 Republic of Korea 3722 Phone: +82 31 299 4957 3723 Email: pauljeong@skku.edu 3724 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3725 Jung-Soo Park 3726 Electronics and Telecommunications Research Institute 3727 218 Gajeong-Ro, Yuseong-Gu 3728 Daejeon 3729 34129 3730 Republic of Korea 3731 Phone: +82 42 860 6514 3732 Email: pjs@etri.re.kr 3734 Susan Hares 3735 Huawei 3736 7453 Hickory Hill 3737 Saline, MI 48176 3738 United States of America 3739 Phone: +1-734-604-0332 3740 Email: shares@ndzh.com 3742 Qiushi Lin 3743 Huawei 3744 Huawei Industrial Base 3745 Shenzhen 3746 Guangdong 518129, 3747 China 3748 Email: linqiushi@huawei.com