idnits 2.17.1 draft-jeong-i2nsf-applicability-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 17, 2017) is 2447 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong 3 Internet-Draft S. Hyun 4 Intended status: Informational Sungkyunkwan University 5 Expires: January 18, 2018 T. Ahn 6 Korea Telecom 7 S. Hares 8 Huawei 9 D. Lopez 10 Telefonica I+D 11 July 17, 2017 13 Applicability of Interfaces to Network Security Functions to Networked 14 Security Services 15 draft-jeong-i2nsf-applicability-01 17 Abstract 19 This document describes the applicability of Interface to Network 20 Security Functions (I2NSF) to networked security services in Network 21 Functions Virtualization (NFV) environments, such as firewall, deep 22 packet inspection, and attack mitigation. 24 Status of This Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on January 18, 2018. 47 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 4 67 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. Firewall: Centralized Firewall System . . . . . . . . . . 6 69 5.2. Deep Packet Inspection: Centralized VoIP/VoLTE 70 Security System . . . . . . . . . . . . . . . . . . . . . 7 71 5.3. Attack Mitigation: Centralized DDoS-attack Mitigation 72 System . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 78 Appendix A. Changes from draft-jeong-i2nsf-applicability-00 . . . 13 80 1. Introduction 82 Interface to Network Security Functions (I2NSF) proposes a standard 83 framework and standard interfaces for networked security services in 84 Network Functions Virtualization (NFV) environments. The I2NSF 85 enables multiple security-vendor products to be used cost-effectively 86 in the NFV environment by utilizing the capabilties of such products 87 and the virtualization of security functions in the NFV platform. 89 This document describes the applicability of I2NSF to networked 90 security services with use cases, such as firewall, Deep Packet 91 Inspection (DPI), and Distributed Denial of Service (DDoS) attack 92 mitigation. 94 2. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 3. Terminology 102 This document uses the terminology described in [RFC7149], 103 [ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture], 104 [ITU-T.X.1252], [ITU-T.X.800], [i2nsf-framework], 105 [consumer-facing-inf-im], [consumer-facing-inf-dm], 106 [i2nsf-nsf-cap-im], [nsf-facing-inf-dm], [registration-inf-im], 107 [registration-inf-dm], and [nsf-triggered-steering]. In addition, 108 the following terms are defined below: 110 o Software-Defined Networking: A set of techniques that enables to 111 directly program, orchestrate, control, and manage network 112 resources, which facilitates the design, delivery and operation of 113 network services in a dynamic and scalable manner [ITU-T.Y.3300]. 115 o Firewall: A firewall that is a device or service at the junction 116 of two network segments that inspects every packet that attempts 117 to cross the boundary. It also rejects any packet that does not 118 satisfy certain criteria for disallowed port numbers or IP 119 addresses. 121 o Centralized Firewall System: A centralized firewall that can 122 establish and distribute access control policy rules into network 123 resources for efficient firewall management. These rules can be 124 managed dynamically by a centralized server for firewall. SDN can 125 work as a network-based firewall system through a standard 126 interface between an SDN switch and a firewall function as a 127 vitual network function (VNF). 129 o Centralized VoIP/VoLTE Security System: A centralized security 130 system that handles the security issues related to VoIP and VoLTE 131 services. SDN can work as a network-based security system through 132 a standard interface between an SDN switch and a VoIP/VoLTE 133 security function as a VNF. 135 o Centralized DDoS-attack Mitigation System: A centralized mitigator 136 that can establish and distribute access control policy rules into 137 network resources for efficient DDoS-attack mitigation. These 138 rules can be managed dynamically by a centralized server for DDoS- 139 attack mitigation. SDN can work as a network-based mitigation 140 system through a standard interface between an SDN switch and a 141 DDoS-attack mitigation function as a VNF. 143 4. I2NSF Framework 145 This section describes an extended I2NSF framework with SDN for I2NSF 146 applicability and use cases, such as firewall system, deep packet 147 inspection system, and DDoS-attack mitigation system. 149 Figure 1 shows an I2NSF framework with SDN networks to support 150 networked security services [i2nsf-framework]. As shown in Figure 1, 151 I2NSF User can use security services by delivering their high-level 152 security policies to Security Controller via Consumer-Facing 153 Interface [consumer-facing-inf-im][consumer-facing-inf-dm]. 155 Security Controller can translate the high-level security policies 156 (received from I2NSF User via Consumer-Facing Interface) into low- 157 level security policies for the corresponding NSFs. These low-level 158 security policies are sent to NSFs via NSF-Facing Interface 159 [i2nsf-nsf-cap-im][nsf-facing-inf-dm]. 161 Security Controller asks NSFs to perform low-level security services 162 via NSF-Facing Interface. The NSFs run as Virtual Network Functions 163 (VNFs) on top of virtual machines through Network Functions 164 Virtualization (NFV) [ETSI-NFV]. Security Controller also asks 165 Switch Controller to perform their required security services on 166 switches under the supervision of Switch Controller (i.e., SDN 167 Controller). In addition, Security Controller uses Registration 168 Interface [registration-inf-im][registration-inf-dm] to communicate 169 with Developer's Management Aystem for registering (or deregistering) 170 the developer's NSFs into (or from) the NFV system using the I2NSF 171 framework. 173 Consumer-Facing Interface between I2NSF User and Security Controller 174 can be implemented by RESTCONF [RFC8040], which is a protocol based 175 on HTTP for configuring data defined in YANG [RFC6020], using the 176 datastore concepts defined in Network Configuration Protocol 177 (NETCONF) [RFC6241]. YANG data models can describe high-level 178 security services for the sake of I2NSF User. A data model in 179 [consumer-facing-inf-dm] can be used for the I2NSF Consumer-Facing 180 Interface. 182 +------------+ 183 | I2NSF User | 184 +------------+ 185 ^ 186 | Consumer-Facing Interface 187 v 188 +-------------------+ Registration +-----------------------+ 189 |Security Controller|<-------------------->|Developer's Mgnt System| 190 +-------------------+ Interface +-----------------------+ 191 ^ ^ 192 | | NSF-Facing Interface 193 | v 194 | +----------------+ +---------------+ +-----------------------+ 195 | | NSF-1 |-| NSF-2 |...| NSF-n | 196 | | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)| 197 | +----------------+ +---------------+ +-----------------------+ 198 | 199 | NSF-Facing Interface 200 v SDN Network 201 +-------------------------------------------------------------------+ 202 | +-----------------+ | 203 | |Switch Controller| | 204 | +-----------------+ | 205 | ^ | 206 | | SDN Southbound Interface | 207 | v | 208 | +--------+ +--------+ +--------+ | 209 | |Switch 1|-|Switch 2|......|Switch m| | 210 | +--------+ +--------+ +--------+ | 211 +-------------------------------------------------------------------+ 213 Figure 1: An I2NSF Framework with SDN Networks 215 NSF-Facing Interface between Security Controller and NSFs can be 216 implemented by NETCONF [RFC6241] for configuring data defined in YANG 217 [RFC6020]. YANG data models can describe low-level security services 218 for the sake of NSFs. A data model in [nsf-facing-inf-dm] can be 219 used for the I2NSF NSF-Facing Interface. 221 Registration Interface between Security Controller and Developer's 222 Management System can be implemented by RESTCONF [RFC8040] for 223 configuring data defined in YANG [RFC6020]. YANG data models can 224 describe the NSF capabilities of networked security services. A data 225 model in [registration-inf-dm] can be used for the I2NSF Registration 226 Interface. 228 Also, the I2NSF framework can enforce mutliple chained NSFs for the 229 low-level security policies with a service function chaining (SFC) 230 for the I2NSF architecture in [nsf-triggered-steering]. 232 5. Use Cases 234 This section introduces three use cases for cloud-based security 235 services: (i) firewall system, (ii) deep packet inspection system, 236 and (iii) attack mitigation system. 238 5.1. Firewall: Centralized Firewall System 240 For the centralized firewall system, a centralized network firewall 241 can manage each network resource and firewall rules can be managed 242 flexibly by a centralized server for firewall (called Firewall). The 243 centralized network firewall controls each switch for the network 244 resource management and the firewall rules can be added or deleted 245 dynamically. 247 The procedure of firewall operations in the centralized firewall 248 system is as follows: 250 1. Switch forwards an unknown flow's packet to Switch Controller. 252 2. Switch Controller forwards the unknown flow's packet to an 253 appropriate security service application, such as Firewall. 255 3. Firewall analyzes the headers and contents of the packet. 257 4. If Firewall regards the packet as a malware's packet with a 258 suspicious pattern, it reports the malware's packet to Switch 259 Controller. 261 5. Switch Controller installs new rules (e.g., drop packets with the 262 suspicious pattern) into switches. 264 6. The malware's packets are dropped by switches. 266 For the above centralized firewall system, the existing SDN protocols 267 can be used through standard interfaces between the firewall 268 application and switches [RFC7149][ITU-T.Y.3300][ONF-OpenFlow] 269 [ONF-SDN-Architecture]. 271 Legacy firewalls have some challenges such as the expensive cost, 272 performance, management of access control, establishment of policy, 273 and packet-based access mechanism. The proposed framework can 274 resolve the challenges through the above centralized firewall system 275 based on SDN as follows: 277 o Cost: The cost of adding firewalls to network resources such as 278 routers, gateways, and switches is substantial due to the reason 279 that we need to add firewall on each network resource. To solve 280 this, each network resource can be managed centrally such that a 281 single firewall is manipulated by a centralized server. 283 o Performance: The performance of firewalls is often slower than the 284 link speed of network interfaces. Every network resource for 285 firewall needs to check firewall rules according to network 286 conditions. Firewalls can be adaptively deployed among network 287 switches, depending on network conditions in the framework. 289 o The management of access control: Since there may be hundreds of 290 network resources in an administered network, the dynamic 291 management of access control for security services like firewall 292 is a challenge. In the framework, firewall rules can be 293 dynamically added for new malware. 295 o The establishment of policy: Policy should be established for each 296 network resource. However, it is difficult to describe what flows 297 are permitted or denied for firewall within a specific 298 organization network under management. Thus, a centralized view 299 is helpful to determine security policies for such a network. 301 o Packet-based access mechanism: Packet-based access mechanism is 302 not enough for firewall in practice since the basic unit of access 303 control is usually users or applications. Therefore, application 304 level rules can be defined and added to the firewall system 305 through the centralized server. 307 5.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System 309 For the centralized VoIP/VoLTE security system, a centralized VoIP/ 310 VoLTE security system can monitor each VoIP/VoLTE flow and manage 311 VoIP/VoLTE security rules controlled by a centralized server for 312 VoIP/VoLTE security service (called VoIP IPS). The VoIP/VoLTE 313 security system controls each switch for the VoIP/VoLTE call flow 314 management by manipulating the rules that can be added, deleted or 315 modified dynamically. 317 The procedure of VoIP/VoLTE security operations in the centralized 318 VoIP/VoLTE security system is as follows: 320 1. A switch forwards an unknown call flow's signal packet (e.g., SIP 321 packet) to Switch Controller. Also, if the packet belongs to a 322 matched flow's packet related to SIP (called matched SIP packet), 323 Switch forwards the packet to Switch Controller so that the 324 packet can be checked by an NSF for VoIP (i.e., VoIP IPS) via 325 Switch Controller, which monitors the behavior of its SIP call. 327 2. Switch Controller forwards the unknown flow's packet or the 328 matched SIP packet to an appropriate security service function, 329 such as VoIP IPS. 331 3. VoIP IPS analyzes the headers and contents of the signal packet, 332 such as IP address, calling number, and session description 333 [RFC4566]. 335 4. If VoIP IPS regards the packet as a spoofed packet by hackers or 336 a scanning packet searching for VoIP/VoLTE devices, it requests 337 the Switch Controller to block that packet and the subsequent 338 packets that have the same call-id. 340 5. Switch Controller installs new rules (e.g., drop packets) into 341 switches. 343 6. The illegal packets are dropped by switches. 345 For the above centralized VoIP/VoLTE security system, the existing 346 SDN protocols can be used through standard interfaces between the 347 VoIP IPS application and switches [RFC7149][ITU-T.Y.3300] 348 [ONF-OpenFlow][ONF-SDN-Architecture]. 350 Legacy hardware based VoIP IPSes have some challenges, such as 351 provisioning time, the granularity of security, expensive cost, and 352 the establishment of policy. The proposed framework can resolve the 353 challenges through the above centralized VoIP/VoLTE security system 354 based on SDN as follows: 356 o Provisioning: The provisioning time of setting up a legacy VoIP 357 IPS to network is substantial because it takes from some hours to 358 some days. By managing the network resources centrally, VoIP IPS 359 can provide more agility in provisioning both virtual and physical 360 network resources from a central location. 362 o The granularity of security: The security rules of a legacy VoIP 363 IPS are compounded considering the granularity of security. The 364 proposed framework can provide more granular security by 365 centralizing security control into a switch controller. The VoIP 366 IPS can effectively manage security rules throughout the network. 368 o Cost: The cost of adding VoIP IPS to network resources, such as 369 routers, gateways, and switches is substantial due to the reason 370 that we need to add VoIP IPS on each network resource. To solve 371 this, each network resource can be managed centrally such that a 372 single VoIP IPS is manipulated by a centralized server. 374 o The establishment of policy: Policy should be established for each 375 network resource. However, it is difficult to describe what flows 376 are permitted or denied for VoIP IPS within a specific 377 organization network under management. Thus, a centralized view 378 is helpful to determine security policies for such a network. 380 5.3. Attack Mitigation: Centralized DDoS-attack Mitigation System 382 For the centralized DDoS-attack mitigation system, a centralized 383 DDoS-attack mitigation can manage each network resource and 384 manipulate rules to each switch through a centralized server for 385 DDoS-attack mitigation (called DDoS-attack Mitigator). The 386 centralized DDoS-attack mitigation system defends servers against 387 DDoS attacks outside private network, that is, from public network. 389 Servers are categorized into stateless servers (e.g., DNS servers) 390 and stateful servers (e.g., web servers). For DDoS-attack 391 mitigation, traffic flows in switches are dynamically configured by 392 traffic flow forwarding path management according to the category of 393 servers [AVANT-GUARD]. Such a managenent should consider the load 394 balance among the switches for the defense against DDoS attacks. 396 The procedure of DDoS-attack mitigation operations in the centralized 397 DDoS-attack mitigation system is as follows: 399 1. Switch periodically reports an inter-arrival pattern of a flow's 400 packets to Switch Controller. 402 2. Switch Controller forwards the flow's inter-arrival pattern to an 403 appropriate security service application, such as DDoS-attack 404 Mitigator. 406 3. DDoS-attack Mitigator analyzes the reported pattern for the flow. 408 4. If DDoS-attack Mitigator regards the pattern as a DDoS attack, it 409 computes a packet dropping probability corresponding to 410 suspiciousness level and reports this DDoS-attack flow to Switch 411 Controller. 413 5. Switch Controller installs new rules into switches (e.g., forward 414 packets with the suspicious inter-arrival pattern with a dropping 415 probability). 417 6. The suspicious flow's packets are randomly dropped by switches 418 with the dropping probability. 420 For the above centralized DDoS-attack mitigation system, the existing 421 SDN protocols can be used through standard interfaces between the 422 DDoS-attack mitigator application and switches [RFC7149] 423 [ITU-T.Y.3300][ONF-OpenFlow][ONF-SDN-Architecture]. 425 The centralized DDoS-attack mitigation system has challenges similar 426 to the centralized firewall system. The proposed framework can 427 resolve the challenges through the above centralized DDoS-attack 428 mitigation system based on SDN as follows: 430 o Cost: The cost of adding DDoS-attack mitigators to network 431 resources such as routers, gateways, and switches is substantial 432 due to the reason that we need to add DDoS-attack mitigator on 433 each network resource. To solve this, each network resource can 434 be managed centrally such that a single DDoS-attack mitigator is 435 manipulated by a centralized server. 437 o Performance: The performance of DDoS-attack mitigators is often 438 slower than the link speed of network interfaces. The checking of 439 DDoS attacks may reduce the performance of the network interfaces. 440 DDoS-attack mitigators can be adaptively deployed among network 441 switches, depending on network conditions in the framework. 443 o The management of network resources: Since there may be hundreds 444 of network resources in an administered network, the dynamic 445 management of network resources for performance (e.g., load 446 balancing) is a challenge for DDoS-attack mitigation. In the 447 framework, as dynamic network resource management, traffic flow 448 forwarding path management can handle the load balancing of 449 network switches [AVANT-GUARD]. With this management, the current 450 and near-future workload can be spread among the network switches 451 for DDoS-attack mitigation. In addition, DDoS-attack mitigation 452 rules can be dynamically added for new DDoS attacks. 454 o The establishment of policy: Policy should be established for each 455 network resource. However, it is difficult to describe what flows 456 are permitted or denied for new DDoS-attacks (e.g., DNS reflection 457 attack) within a specific organization network under management. 458 Thus, a centralized view is helpful to determine security policies 459 for such a network. 461 So far this document has described the procedure and impact of the 462 three use cases for networked security services using the I2NSF 463 framework with SDN networks. To support these use cases in the 464 proposed data-driven security service framework, YANG data models 465 described in [consumer-facing-inf-dm], [nsf-facing-inf-dm], and 466 [registration-inf-dm] can be used as Consumer-Facing Interface, NSF- 467 Facing Interface, and Registration Interface, respectively, along 468 with RESTCONF [RFC8040] and NETCONF [RFC6241]. 470 6. Security Considerations 472 The I2NSF framework with SDN networks in this document is derived 473 from the I2NSF framework [i2nsf-framework], so the security 474 considerations of the I2NSF framework should be included in this 475 document. Therefore, proper secure communication channels should be 476 used the delivery of control or management messages among the 477 components in the proposed framework. 479 This document shares all the security issues of SDN that are 480 specified in the "Security Considerations" section of [ITU-T.Y.3300]. 482 7. Acknowledgements 484 This work was supported by Institute for Information & communications 485 Technology Promotion (IITP) grant funded by the Korea government 486 (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence 487 Technology Development for the Customized Security Service 488 Provisioning). 490 This document has greatly benefited from inputs by Hyoungshick Kim, 491 Jung-Soo Park, Se-Hui Lee, Jinyong Kim, Daeyoung Hyun, and Dongjin 492 Hong. 494 8. References 496 8.1. Normative References 498 [RFC2119] Bradner, S., "Key words for use in RFCs to 499 Indicate Requirement Levels", BCP 14, 500 RFC 2119, March 1997. 502 [i2nsf-framework] Lopez, D., Lopez, E., Dunbar, L., 503 Strassner, J., and R. Kumar, "Framework for 504 Interface to Network Security Functions", 505 draft-ietf-i2nsf-framework-05 (work in 506 progress), May 2017. 508 [RFC6020] Bjorklund, M., "YANG - A Data Modeling 509 Language for the Network Configuration 510 Protocol (NETCONF)", RFC 6020, 511 October 2010. 513 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., 514 and A. Bierman, "Network Configuration 515 Protocol (NETCONF)", RFC 6241, June 2011. 517 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, 518 "RESTCONF Protocol", RFC 8040, 519 January 2017. 521 8.2. Informative References 523 [consumer-facing-inf-im] Kumar, R., Lohiya, A., Qi, D., Bitar, N., 524 Palislamovic, S., and L. Xia, "Information 525 model for Client-Facing Interface to 526 Security Controller", draft-kumar-i2nsf- 527 client-facing-interface-im-02 (work in 528 progress), April 2017. 530 [consumer-facing-inf-dm] Jeong, J., Kim, E., Ahn, T., Kumar, R., and 531 S. Hares, "I2NSF Consumer-Facing Interface 532 YANG Data Model", draft-jeong-i2nsf- 533 consumer-facing-interface-dm-02 (work in 534 progress), July 2017. 536 [i2nsf-nsf-cap-im] Xia, L., Strassner, J., Basile, C., and D. 537 Lopez, "Information Model of NSFs 538 Capabilities", 539 draft-xibassnez-i2nsf-capability-01 (work 540 in progress), March 2017. 542 [nsf-facing-inf-dm] Kim, J., Jeong, J., Park, J., Hares, S., 543 and L. Xia, "I2NSF Network Security 544 Functions-Facing Interface YANG Data 545 Model", draft-kim-i2nsf-nsf-facing- 546 interface-data-model-02 , July 2017. 548 [registration-inf-im] Hyun, S., Jeong, J., Woo, S., Yeo, Y., and 549 J. Park, "I2NSF Registration Interface 550 Information Model", draft-hyun-i2nsf- 551 registration-interface-im-02 (work in 552 progress), July 2017. 554 [registration-inf-dm] Hyun, S., Jeong, J., Yeo, Y., Woo, S., and 555 J. Park, "I2NSF Registration Interface YANG 556 Data Model", 557 draft-hyun-i2nsf-registration-dm-01 (work 558 in progress), July 2017. 560 [nsf-triggered-steering] Hyun, S., Jeong, J., Park, J., and S. 562 Hares, "NSF-triggered Traffic Steering 563 Framework", 564 draft-hyun-i2nsf-nsf-triggered-steering-03 565 (work in progress), July 2017. 567 [RFC7149] Boucadair, M. and C. Jacquenet, "Software- 568 Defined Networking: A Perspective from 569 within a Service Provider Environment", 570 RFC 7149, March 2014. 572 [ITU-T.Y.3300] Recommendation ITU-T Y.3300, "Framework of 573 Software-Defined Networking", June 2014. 575 [ONF-OpenFlow] ONF, "OpenFlow Switch Specification 576 (Version 1.4.0)", October 2013. 578 [ONF-SDN-Architecture] ONF, "SDN Architecture", June 2014. 580 [ITU-T.X.1252] Recommendation ITU-T X.1252, "Baseline 581 Identity Management Terms and Definitions", 582 April 2010. 584 [ITU-T.X.800] Recommendation ITU-T X.800, "Security 585 Architecture for Open Systems 586 Interconnection for CCITT Applications", 587 March 1991. 589 [AVANT-GUARD] Shin, S., Yegneswaran, V., Porras, P., and 590 G. Gu, "AVANT-GUARD: Scalable and Vigilant 591 Switch Flow Management in Software-Defined 592 Networks", ACM CCS, November 2013. 594 [ETSI-NFV] ETSI GS NFV 002 V1.1.1, "Network Functions 595 Virtualisation (NFV); Architectural 596 Framework", October 2013. 598 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, 599 "SDP: Session Description Protocol", 600 RFC 4566, July 2006. 602 Appendix A. Changes from draft-jeong-i2nsf-applicability-00 604 The following changes have been made from 605 draft-jeong-i2nsf-applicability-00: 607 o Figure 1 is modified such that Security Controller and Switch 608 Controller are directly connected with each other via NSF-Facing 609 Interface for the security policy configuration. 611 Authors' Addresses 613 Jaehoon Paul Jeong 614 Department of Software 615 Sungkyunkwan University 616 2066 Seobu-Ro, Jangan-Gu 617 Suwon, Gyeonggi-Do 16419 618 Republic of Korea 620 Phone: +82 31 299 4957 621 Fax: +82 31 290 7996 622 EMail: pauljeong@skku.edu 623 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 625 Sangwon Hyun 626 Department of Software 627 Sungkyunkwan University 628 2066 Seobu-Ro, Jangan-Gu 629 Suwon, Gyeonggi-Do 16419 630 Republic of Korea 632 Phone: +82 31 290 7222 633 Fax: +82 31 299 6673 634 EMail: swhyun77@skku.edu 635 URI: http://imtl.skku.ac.kr/ 637 Tae-Jin Ahn 638 Korea Telecom 639 70 Yuseong-Ro, Yuseong-Gu 640 Daejeon 305-811 641 Republic of Korea 643 Phone: +82 42 870 8409 644 EMail: taejin.ahn@kt.com 646 Susan Hares 647 Huawei 648 7453 Hickory Hill 649 Saline, MI 48176 650 USA 652 Phone: +1-734-604-0332 653 EMail: shares@ndzh.com 654 Diego R. Lopez 655 Telefonica I+D 656 Jose Manuel Lara, 9 657 Seville, 41013 658 Spain 660 Phone: +34 682 051 091 661 EMail: diego.r.lopez@telefonica.com