idnits 2.17.1 draft-ietf-i2nsf-registration-interface-dm-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 30 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 477 has weird spacing: '...average uint1...' == Line 481 has weird spacing: '...average uint1...' == Line 484 has weird spacing: '...average uint...' == Line 500 has weird spacing: '...rw port ine...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 29, 2020) is 1298 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) == Unused Reference: 'RFC6087' is defined on line 851, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 883, but no explicit reference was found in the text == Outdated reference: A later version (-32) exists of draft-ietf-i2nsf-capability-data-model-08 ** Downref: Normative reference to an Informational RFC: RFC 3849 ** Downref: Normative reference to an Informational RFC: RFC 5737 ** Obsolete normative reference: RFC 6087 (Obsoleted by RFC 8407) ** Downref: Normative reference to an Informational RFC: RFC 7348 ** Downref: Normative reference to an Informational RFC: RFC 8329 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-03 == Outdated reference: A later version (-14) exists of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-10 Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group S. Hyun, Ed. 3 Internet-Draft Myongji University 4 Intended status: Standards Track J. Jeong, Ed. 5 Expires: March 2, 2021 T. Roh 6 S. Wi 7 Sungkyunkwan University 8 J. Park 9 ETRI 10 August 29, 2020 12 I2NSF Registration Interface YANG Data Model 13 draft-ietf-i2nsf-registration-interface-dm-09 15 Abstract 17 This document defines an information model and a YANG data model for 18 Registration Interface between Security Controller and Developer's 19 Management System (DMS) in the Interface to Network Security 20 Functions (I2NSF) framework to register Network Security Functions 21 (NSF) of the DMS with the Security Controller. The objective of 22 these information and data models is to support NSF capability 23 registration and query via I2NSF Registration Interface. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 2, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 4 64 5.1. NSF Capability Registration . . . . . . . . . . . . . . . 5 65 5.1.1. NSF Capability Information . . . . . . . . . . . . . 6 66 5.1.2. NSF Access Information . . . . . . . . . . . . . . . 8 67 5.2. NSF Capability Query . . . . . . . . . . . . . . . . . . 8 68 6. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 8 70 6.1.1. Definition of Symbols in Tree Diagrams . . . . . . . 9 71 6.1.2. I2NSF Registration Interface . . . . . . . . . . . . 9 72 6.1.3. NSF Capability Information . . . . . . . . . . . . . 11 73 6.1.4. NSF Access Information . . . . . . . . . . . . . . . 12 74 6.2. YANG Data Modules . . . . . . . . . . . . . . . . . . . . 12 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 79 9.2. Informative References . . . . . . . . . . . . . . . . . 21 80 Appendix A. XML Examples of I2NSF Registration Interface Data 81 Model . . . . . . . . . . . . . . . . . . . . . . . 22 82 A.1. Example 1: Registration for the Capabilities of a General 83 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 22 84 A.2. Example 2: Registration for the Capabilities of a Time- 85 based Firewall . . . . . . . . . . . . . . . . . . . . . 25 86 A.3. Example 3: Registration for the Capabilities of a Web 87 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 29 88 A.4. Example 4: Registration for the Capabilities of a 89 VoIP/VoLTE Filter . . . . . . . . . . . . . . . . . . . . 32 90 A.5. Example 5: Registration for the Capabilities of an HTTP 91 and HTTPS Flood Mitigator . . . . . . . . . . . . . . . . 35 92 A.6. Example 6: Query for the Capabilities of a Time-based 93 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 38 94 Appendix B. NSF Lifecycle Management in NFV Environments . . . . 41 95 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 41 96 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 41 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 99 1. Introduction 101 A number of Network Security Functions (NSF) may exist in the 102 Interface to Network Security Functions (I2NSF) framework [RFC8329]. 103 Since each of these NSFs likely has different security capabilities 104 from each other, it is important to register the security 105 capabilities of the NSF with the security controller. In addition, 106 it is required to search NSFs of some required security capabilities 107 on demand. As an example, if additional security capabilities are 108 required to serve some security service request(s) from an I2NSF 109 user, the security controller should be able to request the DMS for 110 NSFs that have the required security capabilities. 112 This document describes an information model (see Section 5) and a 113 YANG [RFC7950] data model (see Section 6) for the I2NSF Registration 114 Interface [RFC8329] between the security controller and the 115 developer's management system (DMS) to support NSF capability 116 registration and query via the registration interface. It also 117 describes the operations which should be performed by the security 118 controller and the DMS via the Registration Interface using the 119 defined model. 121 2. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 [RFC2119] when, and only when, they appear in all capitals, as shown 127 here. 129 3. Terminology 131 This document uses the following terms defined in [RFC8329] and 132 [I-D.ietf-i2nsf-capability-data-model]. 134 o Network Security Function (NSF): A function that is responsible 135 for a specific treatment of received packets. A Network Security 136 Function can act at various layers of a protocol stack (e.g., at 137 the network layer or other OSI layers). Sample Network Security 138 Service Functions are as follows: Firewall, Intrusion Prevention/ 139 Detection System (IPS/IDS), Deep Packet Inspection (DPI), 140 Application Visibility and Control (AVC), network virus and 141 malware scanning, sandbox, Data Loss Prevention (DLP), Distributed 142 Denial of Service (DDoS) mitigation and TLS proxy. 144 o Data Model: A data model is a representation of concepts of 145 interest to an environment in a form that is dependent on data 146 repository, data definition language, query language, 147 implementation language, and protocol. 149 o Information Model: An information model is a representation of 150 concepts of interest to an environment in a form that is 151 independent of data repository, data definition language, query 152 language, implementation language, and protocol. 154 o YANG: This document follows the guidelines of [RFC8407], uses the 155 common YANG types defined in [RFC6991], and adopts the Network 156 Management Datastore Architecture (NMDA). The meaning of the 157 symbols in tree diagrams is defined in [RFC8340]. 159 4. Objectives 161 o Registering NSFs to I2NSF framework: Developer's Management System 162 (DMS) in I2NSF framework is typically run by an NSF vendor, and 163 uses Registration Interface to provide NSFs developed by the NSF 164 vendor to Security Controller. DMS registers NSFs and their 165 capabilities to I2NSF framework through Registration Interface. 166 For the registered NSFs, Security Controller maintains a catalog 167 of the capabilities of those NSFs. 169 o Updating the capabilities of registered NSFs: After an NSF is 170 registered into Security Controller, some modifications on the 171 capability of the NSF may be required later. In this case, DMS 172 uses Registration Interface to update the capability of the NSF, 173 and this update should be reflected in the catalog of NSFs. 175 o Asking DMS about some required capabilities: In cases that some 176 security capabilities are required to serve the security service 177 request from an I2NSF user, Security Controller searches through 178 the registered NSFs to find ones that can provide the required 179 capabilities. But Security Controller might fail to find any NSFs 180 having the required capabilities among the registered NSFs. In 181 this case, Security Controller needs to request DMS for additional 182 NSF(s) that can provide the required security capabilities via 183 Registration Interface. 185 5. Information Model 187 The I2NSF registration interface is used by Security Controller and 188 Developer's Management System (DMS) in I2NSF framework. The 189 following summarizes the operations done through the registration 190 interface: 192 1) DMS registers NSFs and their capabilities to Security Controller 193 via the registration interface. DMS also uses the registration 194 interface to update the capabilities of the NSFs registered 195 previously. 197 2) In case that Security Controller fails to find some required 198 capabilities from any registered NSF that can provide , Security 199 Controller queries DMS about NSF(s) having the required 200 capabilities via the registration interface. 202 Figure 1 shows the information model of the I2NSF registration 203 interface, which consists of two submodels: NSF capability 204 registration and NSF capability query. Each submodel is used for the 205 operations listed above. The remainder of this section will provide 206 in-depth explanations of each submodel. 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | I2NSF Registration Interface Information Model | 210 | | 211 | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 212 | | NSF Capability | | NSF Capability | | 213 | | Registration | | Query | | 214 | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 1: I2NSF Registration Interface Information Model 219 5.1. NSF Capability Registration 221 This submodel is used by DMS to register an NSF with Security 222 Controller. Figure 2 shows how this submodel is constructed. The 223 most important part in Figure 2 is the NSF capability, and this 224 specifies the set of capabilities that the NSF to be registered can 225 offer. The NSF Name contains a unique name of this NSF with the 226 specified set of capabilities. When registering the NSF, DMS 227 additionally includes the network access information of the NSF which 228 is required to enable network communications with the NSF. 230 The following will further explain the NSF capability information and 231 the NSF access information in more detail. 233 +-+-+-+-+-+-+-+-+-+ 234 | NSF Capability | 235 | Registration | 236 +-+-+-+-+^+-+-+-+-+ 237 | 238 +---------------------+--------------------+ 239 | | | 240 | | | 241 +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 242 | NSF | | NSF Capability| | NSF Access | 243 | Name | | Information | | Information | 244 +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 246 Figure 2: NSF Capability Registration Sub-Model 248 5.1.1. NSF Capability Information 250 NSF Capability Information basically describes the security 251 capabilities of an NSF. In Figure 3, we show capability objects of 252 an NSF. Following the information model of NSF capabilities defined 253 in [I-D.ietf-i2nsf-capability-data-model], we share the same I2NSF 254 security capabilities: Time Capabilities, Event Capabilities, 255 Condition Capabilities, Action Capabilities, Resolution Strategy 256 Capabilities, Default Action Capabilities, and IPsec Method 257 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. Also, NSF Capability 258 Information additionally contains the performance capabilities of an 259 NSF as shown in Figure 3. 261 +-+-+-+-+-+-+-+-+-+ 262 | NSF Capability | 263 | Information | 264 +-+-+-+-^-+-+-+-+-+ 265 | 266 | 267 +----------------------+----------------------+ 268 | | 269 | | 270 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 271 | I2NSF | | Performance | 272 | Capabilities | | Capabilities | 273 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 274 | 275 +------+--------------+-----------------+-----------------+-------+ 276 | | | | | 277 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | 278 | Time | | Event | | Condition | | Action | | 279 | Capabilities| | Capabilities| | Capabilities| | Capabilities| | 280 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | 281 | 282 +---------------------+---------------------+-------+ 283 | | | 284 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ 285 | Resolution | | Default | | IPsec | 286 | Strategy | | Action | | Method | 287 | Capabilities| | Capabilities| +-+-+-+-+-+-+ 288 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 290 Figure 3: NSF Capability Information 292 5.1.1.1. Performance Capabilities 294 This information represents the processing capability of an NSF. 295 Assuming that the current workload status of each NSF is being 296 collected through NSF monitoring 297 [I-D.ietf-i2nsf-nsf-monitoring-data-model], this capability 298 information of the NSF can be used to determine whether the NSF is in 299 congestion by comparing it with the current workload of the NSF. 300 Moreover, this information can specify an available amount of each 301 type of resource, such as processing power which are available on the 302 NSF. (The registration interface can control the usages and 303 limitations of the created instance and make the appropriate request 304 according to the status.) As illustrated in Figure 4, this 305 information consists of two items: Processing and Bandwidth. 306 Processing information describes the NSF's available processing 307 power. Bandwidth describes the information about available network 308 amount in two cases, outbound, inbound. These two information can be 309 used for the NSF's instance request. 311 +-+-+-+-+-+-+-+-+-+ 312 | Performance | 313 | Capabilities | 314 +-+-+-+-^-+-+-+-+-+ 315 | 316 +----------------------------+ 317 | | 318 | | 319 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 320 | Processing | | Bandwidth | 321 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 323 Figure 4: Performance Capability Overview 325 5.1.2. NSF Access Information 327 NSF Access Information contains the followings that are required to 328 communicate with an NSF: IPv4 address, IPv6 address, port number, and 329 supported transport protocol(s) (e.g., Virtual Extensible LAN (VXLAN) 330 [RFC7348], Generic Protocol Extension for VXLAN (VXLAN-GPE) 331 [I-D.ietf-nvo3-vxlan-gpe], Generic Route Encapsulation (GRE), 332 Ethernet etc.). In this document, NSF Access Information is used to 333 identify a specific NSF instance (i.e. NSF Access Information is the 334 signature(unique identifier) of an NSF instance in the overall 335 system). 337 5.2. NSF Capability Query 339 Security Controller may require some additional capabilities to serve 340 the security service request from an I2NSF user, but none of the 341 registered NSFs has the required capabilities. In this case, 342 Security Controller makes a description of the required capabilities 343 by using the NSF capability information sub-model in Section 5.1.1, 344 and sends DMS a query about which NSF(s) can provide these 345 capabilities. 347 6. Data Model 349 6.1. YANG Tree Diagram 351 This section provides the YANG Tree diagram of the I2NSF registration 352 interface. 354 6.1.1. Definition of Symbols in Tree Diagrams 356 A simplified graphical representation of the data model is used in 357 this section. The meaning of the symbols used in the following 358 diagrams [RFC8431] is as follows: 360 Brackets "[" and "]" enclose list keys. 362 Abbreviations before data node names: "rw" means configuration 363 (read-write) and "ro" state data (read-only). 365 Symbols after data node names: "?" means an optional node and "*" 366 denotes a "list" and "leaf-list". 368 Parentheses enclose choice and case nodes, and case nodes are also 369 marked with a colon (":"). 371 Ellipsis ("...") stands for contents of subtrees that are not 372 shown. 374 6.1.2. I2NSF Registration Interface 376 module : ietf-i2nsf-reg-interface 377 +--rw nsf-capability-registration 378 | uses nsf-registrations 380 rpcs : 381 +---x i2nsf-capability-query 382 | uses nsf-capability-query 384 Figure 5: YANG Tree of I2NSF Registration Interface 386 The I2NSF registration interface is used for the following purposes. 387 Developer's Management System (DMS) registers NSFs and their 388 capabilities into Security Controller via the registration interface. 389 In case that Security Controller fails to find any NSF among the 390 registered NSFs which can provide some required capabilities, 391 Security Controller uses the registration interface to query DMS 392 about NSF(s) having the required capabilities. The following 393 sections describe the YANG data models to support these operations. 395 6.1.2.1. NSF Capability Registration 397 This section expands the i2nsf-nsf-registrations in Figure 5. 399 NSF Capability Registration 400 +--rw nsf-registrations 401 +--rw nsf-information* [capability-name] 402 +--rw capability-name string 403 +--rw nsf-capability-info 404 | uses nsf-capability-info 405 +--rw security-capability 406 | uses ietf-i2nsf-capability 407 +--rw performance-capability 408 | uses performance-capability 409 +--rw nsf-access-info 410 | uses nsf-access-info 411 +--rw capability-name 412 +--rw ip 413 +--rw port 415 Figure 6: YANG Tree of NSF Capability Registration Module 417 When registering an NSF to Security Controller, DMS uses this module 418 to describe what capabilities the NSF can offer. DMS includes the 419 network access information of the NSF which is required to make a 420 network connection with the NSF as well as the capability description 421 of the NSF. 423 6.1.2.2. NSF Capability Query 425 This section expands the nsf-capability-query in Figure 5. 427 I2NSF Capability Query 428 +---x nsf-capability-query 429 +---w input 430 | +---w query-nsf-capability 431 | | uses ietf-i2nsf-capability 432 +--ro output 433 +--ro nsf-access-info 434 | uses nsf-access-info 435 +--rw capability-name 436 +--rw ip 437 +--rw port 439 Figure 7: YANG Tree of NSF Capability Query Module 441 Security Controller may require some additional capabilities to 442 provide the security service requested by an I2NSF user, but none of 443 the registered NSFs has the required capabilities. In this case, 444 Security Controller makes a description of the required capabilities 445 using this module and then queries DMS about which NSF(s) can provide 446 these capabilities. Use NETCONF RPCs to send a NSF capability query. 448 Input data is query-i2nsf-capability-info and output data is nsf- 449 access-info. In Figure 7, the ietf-i2nsf-capability refers to the 450 module defined in [I-D.ietf-i2nsf-capability-data-model]. 452 6.1.3. NSF Capability Information 454 This section expands the nsf-capability-info in Figure 6 and 455 Figure 7. 457 NSF Capability Information 458 +--rw nsf-capability-info 459 +--rw security-capability 460 | uses ietf-i2nsf-capability 461 +--rw performance-capability 462 | uses nsf-performance-capability 464 Figure 8: YANG Tree of I2NSF NSF Capability Information 466 In Figure 8, the ietf-i2nsf-capability refers to the module defined 467 in [I-D.ietf-i2nsf-capability-data-model]. The performance- 468 capability is used to specify the performance capability of an NSF. 470 6.1.3.1. NSF Performance Capability 472 This section expands the nsf-performance-capability in Figure 8. 474 NSF Performance Capability 475 +--rw nsf-performance-capability 476 +--rw processing 477 | +--rw processing-average uint16 478 | +--rw processing-peak uint16 479 +--rw bandwidth 480 | +--rw outbound 481 | | +--rw outbound-average uint16 482 | | +--rw outbound-peak uint16 483 | +--rw inbound 484 | | +--rw inbound-average uint16 485 | | +--rw inbound-peak uint16 487 Figure 9: YANG Tree of I2NSF NSF Performance Capability 489 This module is used to specify the performance capabilities of an NSF 490 when registering or initiating the NSF. 492 6.1.4. NSF Access Information 494 This section expands the nsf-access-info in Figure 6. 496 NSF Access Information 497 +--rw nsf-access-info 498 +--rw capability-name string 499 +--rw ip inet:ip-address 500 +--rw port inet:port-number 502 Figure 10: YANG Tree of I2NSF NSF Access Informantion 504 This module contains the network access information of an NSF that is 505 required to enable network communications with the NSF. The field of 506 ip can have either an IPv4 address or an IPv6 address. 508 6.2. YANG Data Modules 510 This section provides a YANG module of the data model for the 511 registration interface between Security Controller and Developer's 512 Management System, as defined in Section 5. 514 This YANG module imports from [RFC6991], and makes a reference to 515 [I-D.ietf-i2nsf-capability-data-model]. 517 file "ietf-i2nsf-reg-interface@2020-08-29.yang" 519 module ietf-i2nsf-reg-interface { 520 yang-version 1.1; 522 namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"; 524 prefix nsfreg; 526 // RFC Ed.: replace occurences of XXXX with actual RFC number and 527 // remove this note 529 import ietf-inet-types { 530 prefix inet; 531 reference "RFC 6991"; 532 } 533 import ietf-i2nsf-capability { 534 prefix cap; 535 // RFC Ed.: replace YYYY with actual RFC number of 536 // draft-ietf-i2nsf-capability-data-model and remove this note. 537 reference "RFC YYYY: I2NSF Capability YANG Data Model"; 538 } 539 organization 540 "IETF I2NSF (Interface to Network Security Functions) 541 Working Group"; 543 contact 544 "WG Web: 545 WG List: 547 Editor: Sangwon Hyun 548 550 Editor: Jaehoon Paul Jeong 551 "; 553 description 554 "This module defines a YANG data model for I2NSF 555 Registration Interface. 557 Copyright (c) 2020 IETF Trust and the persons 558 identified as authors of the code. All rights reserved. 560 Redistribution and use in source and binary forms, with or 561 without modification, is permitted pursuant to, and subject 562 to the license terms contained in, the Simplified BSD License 563 set forth in Section 4.c of the IETF Trust's Legal Provisions 564 Relating to IETF Documents 565 (http://trustee.ietf.org/license-info). 567 This version of this YANG module is part of RFC XXXX; see 568 the RFC itself for full legal notices."; 570 // RFC Ed.: replace XXXX with actual RFC number and remove 571 // this note 573 revision "2020-08-29" { 574 description "Initial revision"; 575 reference 576 "RFC XXXX: I2NSF Registration Interface YANG Data Model"; 577 // RFC Ed.: replace XXXX with actual RFC number and remove 578 // this note 579 } 581 grouping nsf-performance-capability { 582 description 583 "Description of the performance capabilities of an NSF"; 585 container processing { 586 description 587 "Processing power of an NSF in the unit of GHz (gigahertz)"; 589 leaf processing-average { 590 type uint16; 591 units "GHz"; 592 description 593 "Average processing power"; 594 } 595 leaf processing-peak { 596 type uint16; 597 units "GHz"; 598 description 599 "Peak processing power"; 600 } 601 } 602 container bandwidth { 603 description 604 "Network bandwidth available on an NSF 605 in the unit of Mbps (megabits per second)"; 607 container outbound { 608 description 609 "Outbound network bandwidth"; 610 leaf outbound-average { 611 type uint32; 612 units "Mbps"; 613 description 614 "Average outbound bandwidth"; 615 } 616 leaf outbound-peak { 617 type uint32; 618 units "Mbps"; 619 description 620 "Peak outbound bandwidth"; 621 } 622 } 623 container inbound { 624 description 625 "Inbound network bandwidth"; 626 leaf inbound-average { 627 type uint32; 628 units "Mbps"; 629 description 630 "Average inbound bandwidth"; 631 } 632 leaf inbound-peak { 633 type uint32; 634 units "Mbps"; 635 description 636 "Peak inbound bandwidth"; 637 } 638 } 639 } 640 } 642 grouping nsf-capability-info { 643 description 644 "Capability description of an NSF"; 645 container security-capability { 646 description 647 "Description of the security capabilities of an NSF"; 648 uses cap:nsf-capabilities; 649 // RFC Ed.: replace YYYY with actual RFC number of 650 // draft-ietf-i2nsf-capability-data-model and remove this note. 651 reference "RFC YYYY: I2NSF Capability YANG Data Model"; 652 } 653 container performance-capability { 654 description 655 "Description of the performance capabilities of an NSF"; 656 uses nsf-performance-capability; 657 } 658 } 660 grouping nsf-access-info { 661 description 662 "Information required to access an NSF"; 663 leaf capability-name { 664 type string; 665 description 666 "Unique name of this NSF's capability"; 667 } 668 leaf ip { 669 type inet:ip-address; 670 description 671 "Either an IPv4 address or an IPv6 address of this NSF"; 672 } 673 leaf port { 674 type inet:port-number; 675 description 676 "Port available on this NSF"; 677 } 678 } 680 container nsf-registrations { 681 description 682 "Information of an NSF that DMS registers 683 to Security Controller"; 684 list nsf-information { 685 key "capability-name"; 686 description 687 "Required information for registration"; 688 leaf capability-name { 689 type string; 690 mandatory true; 691 description 692 "Unique name of this registered NSF"; 693 } 694 container nsf-capability-info { 695 description 696 "Capability description of this NSF"; 697 uses nsf-capability-info; 698 } 699 container nsf-access-info { 700 description 701 "Network access information of this NSF"; 702 uses nsf-access-info; 703 } 704 } 705 } 707 rpc nsf-capability-query { 708 description 709 "Description of the capabilities that the 710 Security Controller requests to the DMS"; 711 input { 712 container query-nsf-capability { 713 description 714 "Description of the capabilities to request"; 715 uses cap:nsf-capabilities; 716 // RFC Ed.: replace YYYY with actual RFC number of 717 // draft-ietf-i2nsf-capability-data-model and remove this note. 718 reference "RFC YYYY: I2NSF Capability YANG Data Model"; 719 } 720 } 721 output { 722 container nsf-access-info { 723 description 724 "Network access information of an NSF 725 with the requested capabilities"; 726 uses nsf-access-info; 727 } 728 } 729 } 730 } 732 734 Figure 11: Registration Interface YANG Data Model 736 7. IANA Considerations 738 This document requests IANA to register the following URI in the 739 "IETF XML Registry" [RFC3688]: 741 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface 742 Registrant Contact: The IESG. 743 XML: N/A; the requested URI is an XML namespace. 745 This document requests IANA to register the following YANG module in 746 the "YANG Module Names" registry [RFC7950][RFC8525]: 748 Name: ietf-i2nsf-reg-interface 749 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface 750 Prefix: nsfreg 751 Reference: RFC XXXX 753 // RFC Ed.: replace XXXX with actual RFC number and remove 754 // this note 756 8. Security Considerations 758 The YANG module specified in this document defines a data schema 759 designed to be accessed through network management protocols such as 760 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 761 the secure transport layer, and the required secure transport is 762 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 763 and the required secure transport is TLS [RFC8446]. 765 The NETCONF access control model [RFC8341] provides a means of 766 restricting access to specific NETCONF or RESTCONF users to a 767 preconfigured subset of all available NETCONF or RESTCONF protocol 768 operations and content. 770 There are a number of data nodes defined in this YANG module that are 771 writable/creatable/deletable (i.e., config true, which is the 772 default). These data nodes may be considered sensitive or vulnerable 773 in some network environments. Write operations (e.g., edit-config) 774 to these data nodes without proper protection can have a negative 775 effect on network operations. These are the subtrees and data nodes 776 and their sensitivity/vulnerability: 778 o nsf-registrations: The attacker may exploit this to register a 779 compromised or malicious NSF instead of a legitimate NSF with the 780 Security Controller. 782 o nsf-performance-capability: The attacker may provide incorrect 783 information of the performance capability of any target NSF by 784 illegally modifying this. 786 o nsf-capability-info: The attacker may provide incorrect 787 information of the security capability of any target NSF by 788 illegally modifying this. 790 o nsf-access-info: The attacker may provide incorrect network access 791 information of any target NSF by illegally modifying this. 793 Some of the readable data nodes in this YANG module may be considered 794 sensitive or vulnerable in some network environments. It is thus 795 important to control read access (e.g., via get, get-config, or 796 notification) to these data nodes. These are the subtrees and data 797 nodes and their sensitivity/vulnerability: 799 o nsf-registrations: The attacker may try to gather some sensitive 800 information of a registered NSF by sniffing this. 802 o nsf-performance-capability: The attacker may gather the 803 performance capability information of any target NSF and misuse 804 the information for subsequent attacks. 806 o nsf-capability-info: The attacker may gather the security 807 capability information of any target NSF and misuse the 808 information for subsequent attacks. 810 o nsf-access-info: The attacker may gather the network access 811 information of any target NSF and misuse the information for 812 subsequent attacks. 814 The RPC operation in this YANG module may be considered sensitive or 815 vulnerable in some network environments. It is thus important to 816 control access to this operation. The following is the operation and 817 its sensitivity/vulnerability: 819 o nsf-capability-query: The attacker may exploit this RPC operation 820 to deteriorate the availability of the DMS and/or gather the 821 information of some interested NSFs from the DMS. 823 9. References 825 9.1. Normative References 827 [I-D.ietf-i2nsf-capability-data-model] 828 Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin, 829 "I2NSF Capability YANG Data Model", draft-ietf-i2nsf- 830 capability-data-model-08 (work in progress), August 2020. 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, 834 DOI 10.17487/RFC2119, March 1997, 835 . 837 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 838 DOI 10.17487/RFC3688, January 2004, 839 . 841 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 842 Reserved for Documentation", RFC 3849, 843 DOI 10.17487/RFC3849, July 2004, 844 . 846 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 847 Reserved for Documentation", RFC 5737, 848 DOI 10.17487/RFC5737, January 2010, 849 . 851 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 852 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 853 January 2011, . 855 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 856 and A. Bierman, Ed., "Network Configuration Protocol 857 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 858 . 860 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 861 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 862 . 864 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 865 RFC 6991, DOI 10.17487/RFC6991, July 2013, 866 . 868 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 869 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 870 eXtensible Local Area Network (VXLAN): A Framework for 871 Overlaying Virtualized Layer 2 Networks over Layer 3 872 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 873 . 875 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 876 RFC 7950, DOI 10.17487/RFC7950, August 2016, 877 . 879 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 880 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 881 . 883 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 884 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 885 May 2017, . 887 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 888 Kumar, "Framework for Interface to Network Security 889 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 890 . 892 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 893 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 894 . 896 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 897 Access Control Model", STD 91, RFC 8341, 898 DOI 10.17487/RFC8341, March 2018, 899 . 901 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 902 Documents Containing YANG Data Models", BCP 216, RFC 8407, 903 DOI 10.17487/RFC8407, October 2018, 904 . 906 [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 907 S., and N. Bahadur, "A YANG Data Model for the Routing 908 Information Base (RIB)", RFC 8431, DOI 10.17487/RFC8431, 909 September 2018, . 911 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 912 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 913 . 915 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 916 and R. Wilton, "YANG Library", RFC 8525, 917 DOI 10.17487/RFC8525, March 2019, 918 . 920 9.2. Informative References 922 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 923 Jeong, J., Chung, C., Hares, S., Xia, L., and H. Birkholz, 924 "I2NSF NSF Monitoring YANG Data Model", draft-ietf-i2nsf- 925 nsf-monitoring-data-model-03 (work in progress), May 2020. 927 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] 928 Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia, 929 "Software-Defined Networking (SDN)-based IPsec Flow 930 Protection", draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 931 (work in progress), June 2020. 933 [I-D.ietf-nvo3-vxlan-gpe] 934 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 935 Extension for VXLAN (VXLAN-GPE)", draft-ietf-nvo3-vxlan- 936 gpe-10 (work in progress), July 2020. 938 [nfv-framework] 939 "Network Functions Virtualisation (NFV); Architectureal 940 Framework", ETSI GS NFV 002 ETSI GS NFV 002 V1.1.1, 941 October 2013. 943 Appendix A. XML Examples of I2NSF Registration Interface Data Model 945 This section describes XML examples of the I2NSF Registration 946 Interface data model under the assumption of registering several 947 types of NSFs and querying NSF capability. 949 A.1. Example 1: Registration for the Capabilities of a General Firewall 951 This section shows an XML example for registering the capabilities of 952 a general firewall in either IPv4 networks [RFC5737] or IPv6 networks 953 [RFC3849]. 955 958 959 general_firewall_capability 960 961 962 963 964 cap:ipv4-protocol 965 cap:exact-ipv4-address 966 cap:range-ipv4-address 967 cap:exact-tcp-port-num 968 cap:range-tcp-port-num 969 970 971 972 cap:pass 973 cap:drop 974 cap:alert 975 cap:pass 976 cap:drop 977 cap:alert 978 979 cap:ikeless 980 981 982 983 1000 984 5000 985 986 987 988 1000 989 5000 990 991 992 1000 993 5000 994 995 996 997 998 999 general_firewall 1000 192.0.2.11 1001 3000 1002 1003 1004 1006 Figure 12: Configuration XML for Registration of a General Firewall 1007 in an IPv4 Network 1009 Figure 12 shows the configuration XML for registering a general 1010 firewall in an IPv4 network [RFC5737] and its capabilities as 1011 follows. 1013 1. The instance name of the NSF is general_firewall. 1015 2. The NSF can inspect a protocol, an exact IPv4 address, and a 1016 range of IPv4 addresses for IPv4 packets. 1018 3. The NSF can inspect an exact port number and a range of port 1019 numbers for TCP packets. 1021 4. The NSF can determine whether the packets are allowed to pass, 1022 drop, or alert. 1024 5. The NSF can support IPsec not through IKEv2, but through a 1025 Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 1027 6. The NSF can have processing power and bandwidth. 1029 7. The IPv4 address of the NSF is 192.0.2.11. 1031 8. The port of the NSF is 3000. 1033 1036 1037 general_firewall_capability 1038 1039 1040 1041 1042 cap:ipv6-protocol 1043 cap:exact-ipv6-address 1044 cap:range-ipv6-address 1045 cap:exact-tcp-port-num 1046 cap:range-tcp-port-num 1047 1048 1049 1050 cap:pass 1051 cap:drop 1052 cap:alert 1053 cap:pass 1054 cap:drop 1055 cap:alert 1056 1057 cap:ikeless 1058 1059 1060 1061 1000 1062 5000 1063 1064 1065 1066 1000 1067 5000 1068 1069 1070 1000 1071 5000 1072 1073 1074 1075 1076 1077 general_firewall 1078 2001:DB8:0:1::11 1079 3000 1080 1081 1082 1084 Figure 13: Configuration XML for Registration of a General Firewall 1085 in an IPv6 Network 1087 In addition, Figure 13 shows the configuration XML for registering a 1088 general firewall in an IPv6 network [RFC3849] and its capabilities as 1089 follows. 1091 1. The instance name of the NSF is general_firewall. 1093 2. The NSF can inspect a protocol, an exact IPv6 address, and a 1094 range of IPv6 addresses for IPv6 packets. 1096 3. The NSF can inspect an exact port number and a range of port 1097 numbers for TCP packets. 1099 4. The NSF can determine whether the packets are allowed to pass, 1100 drop, or alert. 1102 5. The NSF can support IPsec not through IKEv2, but through a 1103 Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 1105 6. The NSF can have processing power and bandwidth. 1107 7. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1109 8. The port of the NSF is 3000. 1111 A.2. Example 2: Registration for the Capabilities of a Time-based 1112 Firewall 1114 This section shows an XML example for registering the capabilities of 1115 a time-based firewall in either IPv4 networks [RFC5737] or IPv6 1116 networks [RFC3849]. 1118 1121 1122 time_based_firewall_capability 1123 1124 1125 absolute-time 1126 periodic-time 1127 1128 1129 cap:ipv4-protocol 1130 cap:exact-ipv4-address 1131 cap:range-ipv4-address 1132 cap:exact-tcp-port-num 1133 cap:range-tcp-port-num 1134 1136 1137 1138 cap:pass 1139 cap:drop 1140 cap:alert 1141 cap:pass 1142 cap:drop 1143 cap:alert 1144 1145 cap:ike 1146 1147 1148 1149 1000 1150 5000 1151 1152 1153 1154 1000 1155 5000 1156 1157 1158 1000 1159 5000 1160 1161 1162 1163 1164 1165 time_based_firewall 1166 192.0.2.11 1167 3000 1168 1169 1170 1172 Figure 14: Configuration XML for Registration of a Time-based 1173 Firewall in an IPv4 Network 1175 Figure 14 shows the configuration XML for registering a time-based 1176 firewall in an IPv4 network [RFC5737] and its capabilities as 1177 follows. 1179 1. The instance name of the NSF is time_based_firewall. 1181 2. The NSF can enforce the security policy rule according to 1182 absolute time and periodic time. 1184 3. The NSF can inspect a protocol, an exact IPv4 address, and a 1185 range of IPv4 addresses for IPv4 packets. 1187 4. The NSF can determine whether the packets are allowed to pass, 1188 drop, or alert. 1190 5. The NSF can support IPsec through IKEv2 1191 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 1193 6. The NSF can have processing power and bandwidth. 1195 7. The IPv4 address of the NSF is 192.0.2.11. 1197 8. The port of the NSF is 3000. 1199 1202 1203 time_based_firewall_capability 1204 1205 1206 absolute-time 1207 periodic-time 1208 1209 1210 cap:ipv6-protocol 1211 cap:exact-ipv6-address 1212 cap:range-ipv6-address 1213 cap:exact-tcp-port-num 1214 cap:range-tcp-port-num 1215 1216 1217 1218 cap:pass 1219 cap:drop 1220 cap:alert 1221 cap:pass 1222 cap:drop 1223 cap:alert 1224 1225 cap:ike 1226 1227 1228 1229 1000 1230 5000 1231 1232 1233 1234 1000 1235 5000 1236 1237 1238 1000 1239 5000 1240 1241 1242 1243 1244 1245 time_based_firewall 1246 2001:DB8:0:1::11 1247 3000 1248 1249 1250 1252 Figure 15: Configuration XML for Registration of a Time-based 1253 Firewall in an IPv6 Network 1255 In addition, Figure 15 shows the configuration XML for registering a 1256 time-based firewall in an IPv6 network [RFC3849] and its capabilities 1257 as follows. 1259 1. The instance name of the NSF is time_based_firewall. 1261 2. The NSF can enforce the security policy rule according to 1262 absolute time and periodic time. 1264 3. The NSF can inspect a protocol, an exact IPv6 address, and a 1265 range of IPv6 addresses for IPv6 packets. 1267 4. The NSF can determine whether the packets are allowed to pass, 1268 drop, or alert. 1270 5. The NSF can support IPsec through IKEv2 1271 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 1273 6. The NSF can have processing power and bandwidth. 1275 7. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1277 8. The port of the NSF is 3000. 1279 A.3. Example 3: Registration for the Capabilities of a Web Filter 1281 This section shows an XML example for registering the capabilities of 1282 a web filter in either IPv4 networks [RFC5737] or IPv6 networks 1283 [RFC3849]. 1285 1288 1289 web_filter 1290 1291 1292 1293 1294 cap:user-defined 1295 1296 1297 1298 cap:pass 1299 cap:drop 1300 cap:alert 1301 cap:pass 1302 cap:drop 1303 cap:alert 1304 1305 cap:ikeless 1306 1307 1308 1309 1000 1310 5000 1311 1312 1313 1314 1000 1315 5000 1316 1317 1318 1000 1319 5000 1320 1321 1322 1323 1324 1325 web_filter 1326 192.0.2.11 1327 3000 1328 1329 1330 1332 Figure 16: Configuration XML for Registration of a Web Filter in an 1333 IPv4 Network 1335 Figure 16 shows the configuration XML for registering a web filter in 1336 an IPv4 network [RFC5737] and its capabilities are as follows. 1338 1. The instance name of the NSF is web_filter. 1340 2. The NSF can inspect URL for HTTP and HTTPS packets. 1342 3. The NSF can determine whether the packets are allowed to pass, 1343 drop, or alert. 1345 4. The NSF can support IPsec not through IKEv2, but through a 1346 Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 1348 5. The NSF can have processing power and bandwidth. 1350 6. The IPv4 address of the NSF is 192.0.2.11. 1352 7. The port of the NSF is 3000. 1354 1357 1358 web_filter 1359 1360 1361 1362 1363 cap:user-defined 1364 1365 1366 1367 cap:pass 1368 cap:drop 1369 cap:alert 1370 cap:pass 1371 cap:drop 1372 cap:alert 1373 1374 cap:ikeless 1376 1377 1378 1379 1000 1380 5000 1381 1382 1383 1384 1000 1385 5000 1386 1387 1388 1000 1389 5000 1390 1391 1392 1393 1394 1395 web_filter 1396 2001:DB8:0:1::11 1397 3000 1398 1399 1400 1402 Figure 17: Configuration XML for Registration of a Web Filter in an 1403 IPv6 Network 1405 In addition, Figure 17 shows the configuration XML for registering a 1406 web filter in an IPv6 network [RFC3849] and its capabilities are as 1407 follows. 1409 1. The instance name of the NSF is web_filter. 1411 2. The NSF can inspect URL for HTTP and HTTPS packets. 1413 3. The NSF can determine whether the packets are allowed to pass, 1414 drop, or alert. 1416 4. The NSF can support IPsec not through IKEv2, but through a 1417 Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 1419 5. The NSF can have processing power and bandwidth. 1421 6. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1423 7. The port of the NSF is 3000. 1425 A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE 1426 Filter 1428 This section shows an XML example for registering the capabilities of 1429 a VoIP/VoLTE filter in either IPv4 networks [RFC5737] or IPv6 1430 networks [RFC3849]. 1432 1435 1436 voip_volte_filter 1437 1438 1439 1440 1441 cap:voice-id 1442 1443 1444 1445 cap:pass 1446 cap:drop 1447 cap:alert 1448 cap:pass 1449 cap:drop 1450 cap:alert 1451 1452 cap:ikeless 1453 1454 1455 1456 1000 1457 5000 1458 1459 1460 1461 1000 1462 5000 1463 1464 1465 1000 1466 5000 1467 1468 1469 1470 1471 1472 voip_volte_filter 1473 192.0.2.11 1474 3000 1475 1476 1477 1479 Figure 18: Configuration XML for Registration of a VoIP/VoLTE Filter 1480 in an IPv4 Network 1482 Figure 18 shows the configuration XML for registering a VoIP/VoLTE 1483 filter in an IPv4 network [RFC5737] and its capabilities are as 1484 follows. 1486 1. The instance name of the NSF is voip_volte_filter. 1488 2. The NSF can inspect a voice id for VoIP/VoLTE packets. 1490 3. The NSF can determine whether the packets are allowed to pass, 1491 drop, or alert. 1493 4. The NSF can support IPsec not through IKEv2, but through a 1494 Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 1496 5. The NSF can have processing power and bandwidth. 1498 6. The IPv4 address of the NSF is 192.0.2.11. 1500 7. The port of the NSF is 3000. 1502 1505 1506 voip_volte_filter 1507 1508 1509 1510 1511 cap:voice-id 1512 1513 1514 1515 cap:pass 1516 cap:drop 1517 cap:alert 1518 cap:pass 1519 cap:drop 1520 cap:alert 1522 1523 cap:ikeless 1524 1525 1526 1527 1000 1528 5000 1529 1530 1531 1532 1000 1533 5000 1534 1535 1536 1000 1537 5000 1538 1539 1540 1541 1542 1543 voip_volte_filter 1544 2001:DB8:0:1::11 1545 3000 1546 1547 1548 1550 Figure 19: Configuration XML for Registration of a VoIP/VoLTE Filter 1551 in an IPv6 Network 1553 Figure 19 shows the configuration XML for registering a VoIP/VoLTE 1554 filter in an IPv6 network [RFC3849] and its capabilities are as 1555 follows. 1557 1. The instance name of the NSF is voip_volte_filter. 1559 2. The NSF can inspect a voice id for VoIP/VoLTE packets. 1561 3. The NSF can determine whether the packets are allowed to pass, 1562 drop, or alert. 1564 4. The NSF can support IPsec not through IKEv2, but through a 1565 Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 1567 5. The NSF can have processing power and bandwidth. 1569 6. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1571 7. The port of the NSF is 3000. 1573 A.5. Example 5: Registration for the Capabilities of an HTTP and HTTPS 1574 Flood Mitigator 1576 This section shows an XML example for registering the capabilities of 1577 an HTTP and HTTPS flood mitigator in either IPv4 networks [RFC5737] 1578 or IPv6 networks [RFC3849]. 1580 1583 1584 1585 http_and_https_flood_mitigator 1586 1587 1588 1589 1590 1591 1592 cap:http-flood-action 1593 1594 1595 cap:https-flood-action 1596 1597 1598 1599 1600 cap:pass 1601 cap:drop 1602 cap:alert 1603 cap:pass 1604 cap:drop 1605 cap:alert 1606 1607 cap:ike 1608 1609 1610 1611 1000 1612 5000 1613 1614 1615 1616 1000 1617 5000 1618 1619 1620 1000 1621 5000 1622 1623 1624 1625 1626 1627 1628 http_and_https_flood_mitigation 1629 1630 192.0.2.11 1631 3000 1632 1633 1634 1636 Figure 20: Configuration XML for Registration of an HTTP and HTTPS 1637 Flood Mitigator in an IPv4 Network 1639 Figure 20 shows the configuration XML for registering an HTTP and 1640 HTTPS flood mitigator in an IPv4 network [RFC5737] and its 1641 capabilities are as follows. 1643 1. The instance name of the NSF is http_and_https_flood_mitigator. 1645 2. The NSF can control the amount of packets for HTTP and HTTPS 1646 packets. 1648 3. The NSF can determine whether the packets are allowed to pass, 1649 drop, or alert. 1651 4. The NSF can support IPsec through IKEv2 1652 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 1654 5. The NSF can have processing power and bandwidth. 1656 6. The IPv4 address of the NSF is 192.0.2.11. 1658 7. The port of the NSF is 3000. 1660 1663 1664 1665 http_and_https_flood_mitigator 1666 1667 1668 1669 1670 1671 1672 cap:http-flood-action 1673 1674 1675 cap:https-flood-action 1676 1677 1678 1679 1680 cap:pass 1681 cap:drop 1682 cap:alert 1683 cap:pass 1684 cap:drop 1685 cap:alert 1686 1687 cap:ike 1688 1689 1690 1691 1000 1692 5000 1693 1694 1695 1696 1000 1697 5000 1698 1699 1700 1000 1701 5000 1702 1703 1704 1705 1706 1707 1708 http_and_https_flood_mitigation 1709 1710 2001:DB8:0:1::11 1711 3000 1712 1713 1714 1715 Figure 21: Configuration XML for Registration of an HTTP and HTTPS 1716 Flood Mitigator in an IPv6 Network 1718 In addition, Figure 21 shows the configuration XML for registering an 1719 HTTP and HTTPS flood mitigator in an IPv6 network [RFC3849] and its 1720 capabilities are as follows. 1722 1. The instance name of the NSF is http_and_https_flood_mitigator. 1724 2. The NSF can control the amount of packets for HTTP and HTTPS 1725 packets. 1727 3. The NSF can determine whether the packets are allowed to pass, 1728 drop, or alert. 1730 4. The NSF can support IPsec through IKEv2 1731 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 1733 5. The NSF can have processing power and bandwidth. 1735 6. The IPv6 address of the NSF is 2001:DB8:0:1::11. 1737 7. The port of the NSF is 3000. 1739 A.6. Example 6: Query for the Capabilities of a Time-based Firewall 1741 This section shows an XML example for querying the capabilities of a 1742 time-based firewall in either IPv4 networks [RFC5737] or IPv6 1743 networks [RFC3849]. 1745 1747 1750 1751 absolute-time 1752 periodic-time 1753 1754 1755 cap:ipv4-protocol 1756 cap:exact-ipv4-address 1757 cap:range-ipv4-address 1758 1759 1760 1761 cap:pass 1762 cap:drop 1763 cap:alert 1764 cap:pass 1765 cap:drop 1766 cap:alert 1767 1768 cap:ikeless 1769 1770 1771 1773 1775 1777 time-based-firewall 1778 192.0.2.11 1779 3000 1780 1781 1783 Figure 22: Configuration XML for Query of a Time-based Firewall in an 1784 IPv4 Network 1786 Figure 22 shows the XML configuration for querying the capabilities 1787 of a time-based firewall in an IPv4 network [RFC5737]. The access 1788 information of the announced time-based firewall has the IPv4 address 1789 of 192.0.2.11 and the port number of 3000. 1791 1793 1796 1797 absolute-time 1798 periodic-time 1799 1800 1801 cap:ipv6-protocol 1802 cap:exact-ipv6-address 1803 cap:range-ipv6-address 1804 1805 1806 1807 cap:pass 1808 cap:drop 1809 cap:alert 1810 cap:pass 1811 cap:drop 1812 cap:alert 1813 1814 cap:ikeless 1815 1816 1817 1819 1821 1823 time-based-firewall 1824 2001:DB8:0:1::11 1825 3000 1826 1827 1829 Figure 23: Configuration XML for Query of a Time-based Firewall in an 1830 IPv6 Network 1832 In addition, Figure 23 shows the XML configuration for querying the 1833 capabilities of a time-based firewall in an IPv6 network [RFC3849]. 1834 The access information of the announced time-based firewall has the 1835 IPv6 address of 2001:DB8:0:1::11 and the port number of 3000. 1837 Appendix B. NSF Lifecycle Management in NFV Environments 1839 Network Functions Virtualization (NFV) can be used to implement I2NSF 1840 framework. In NFV environments, NSFs are deployed as virtual network 1841 functions (VNFs). Security Controller can be implemented as an 1842 Element Management (EM) of the NFV architecture, and is connected 1843 with the VNF Manager (VNFM) via the Ve-Vnfm interface 1844 [nfv-framework]. Security Controller can use this interface for the 1845 purpose of the lifecycle management of NSFs. If some NSFs need to be 1846 instantiated to enforce security policies in the I2NSF framework, 1847 Security Controller could request the VNFM to instantiate them 1848 through the Ve-Vnfm interface. Or if an NSF, running as a VNF, is 1849 not used by any traffic flows for a time period, Security Controller 1850 may request deinstantiating it through the interface for efficient 1851 resource utilization. 1853 Appendix C. Acknowledgments 1855 This work was supported by Institute of Information & Communications 1856 Technology Planning & Evaluation (IITP) grant funded by the Korea 1857 MSIT (Ministry of Science and ICT) (No. 2016-0-00078, Cloud Based 1858 Security Intelligence Technology Development for the Customized 1859 Security Service Provisioning). 1861 Appendix D. Contributors 1863 This document is made by the group effort of I2NSF working group. 1864 Many people actively contributed to this document, such as Reshad 1865 Rahman. The authors sincerely appreciate their contributions. 1867 The following are co-authors of this document: 1869 Jinyong Tim Kim 1870 Department of Electronic, Electrical and Computer Engineering 1871 Sungkyunkwan University 1872 2066 Seo-ro Jangan-gu 1873 Suwon, Gyeonggi-do 16419 1874 Republic of Korea 1876 EMail: timkim@skku.edu 1878 Chaehong Chung 1879 Department of Electronic, Electrical and Computer Engineering 1880 Sungkyunkwan University 1881 2066 Seo-ro Jangan-gu 1882 Suwon, Gyeonggi-do 16419 1883 Republic of Korea 1884 EMail: darkhong@skku.edu 1886 Susan Hares 1887 Huawei 1888 7453 Hickory Hill 1889 Saline, MI 48176 1890 USA 1892 EMail: shares@ndzh.com 1894 Diego R. Lopez 1895 Telefonica I+D 1896 Jose Manuel Lara, 9 1897 Seville, 41013 1898 Spain 1900 EMail: diego.r.lopez@telefonica.com 1902 Authors' Addresses 1904 Sangwon Hyun (editor) 1905 Department of Computer Engineering 1906 Myongji University 1907 116 Myongji-ro, Cheoin-gu 1908 Yongin, Gyeonggi-do 17058 1909 Republic of Korea 1911 EMail: shyun@mju.ac.kr 1913 Jaehoon Paul Jeong (editor) 1914 Department of Computer Science and Engineering 1915 Sungkyunkwan University 1916 2066 Seobu-Ro, Jangan-Gu 1917 Suwon, Gyeonggi-Do 16419 1918 Republic of Korea 1920 Phone: +82 31 299 4957 1921 Fax: +82 31 290 7996 1922 EMail: pauljeong@skku.edu 1923 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1924 Taekyun Roh 1925 Department of Electronic, Electrical and Computer Engineering 1926 Sungkyunkwan University 1927 2066 Seobu-Ro, Jangan-Gu 1928 Suwon, Gyeonggi-Do 16419 1929 Republic of Korea 1931 Phone: +82 31 290 7222 1932 Fax: +82 31 299 6673 1933 EMail: tkroh0198@skku.edu 1935 Sarang Wi 1936 Department of Electronic, Electrical and Computer Engineering 1937 Sungkyunkwan University 1938 2066 Seobu-Ro, Jangan-Gu 1939 Suwon, Gyeonggi-Do 16419 1940 Republic of Korea 1942 Phone: +82 31 290 7222 1943 Fax: +82 31 299 6673 1944 EMail: dnl9795@skku.edu 1946 Jung-Soo Park 1947 Electronics and Telecommunications Research Institute 1948 218 Gajeong-Ro, Yuseong-Gu 1949 Daejeon 305-700 1950 Republic of Korea 1952 Phone: +82 42 860 6514 1953 EMail: pjs@etri.re.kr