Internet Engineering Task Force (IETF) S. Hares Request for Comments: 8192 Huawei Category: Informational D. Lopez ISSN: 2070-1721 Telefonica I+D M. Zarny vArmour C. Jacquenet France Telecom R. Kumar Juniper Networks J. Jeong Sungkyunkwan University July 2017 Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases
AbstractThis document sets out the problem statement for Interface to Network Security Functions (I2NSF) and outlines some companion use cases. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8192.
Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Challenges Facing Security Service Providers . . . . . . 6 3.1.1. Diverse Types of Security Functions . . . . . . . . . 6 3.1.2. Diverse Interfaces to Control and Monitor NSFs . . . 8 3.1.3. More Distributed NSFs and vNSFs . . . . . . . . . . . 8 3.1.4. More Demand to Control NSFs Dynamically . . . . . . . 9 3.1.5. Demand for Multi-tenancy to Control and Monitor NSFs 9 3.1.6. Lack of Characterization of NSFs and Capability Exchange . . . . . . . . . . . . . . . . . . . . . . 9 3.1.7. Lack of Mechanism for NSFs to Utilize External Profiles . . . . . . . . . . . . . . . . . . . . . . 10 3.1.8. Lack of Mechanisms to Accept External Alerts to Trigger Automatic Rule and Configuration Changes . . 10 3.1.9. Lack of Mechanism for Dynamic Key Distribution to NSFs . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Challenges Facing Customers . . . . . . . . . . . . . . . 12 3.2.1. NSFs from Heterogeneous Administrative Domains . . . 12 3.2.2. Today's Vendor-Specific Control Requests . . . . . . 13 3.2.3. Difficulty for Customers to Monitor the Execution of Desired Policies . . . . . . . . . . . . . . . . . . 14 3.3. Lack of Standard Interface to Inject Feedback to NSF . . 15 3.4. Lack of Standard Interface for Capability Negotiation . . 15 3.5. Difficulty in Validating Policies across Multiple Domains 15 3.6. Software-Defined Networks . . . . . . . . . . . . . . . . 16 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Basic Framework . . . . . . . . . . . . . . . . . . . . . 17 4.2. Access Networks . . . . . . . . . . . . . . . . . . . . . 18 4.3. Cloud Data Center Scenario . . . . . . . . . . . . . . . 21 4.3.1. On-Demand Virtual Firewall Deployment . . . . . . . . 21 4.3.2. Firewall Policy Deployment Automation . . . . . . . . 22 4.3.3. Client-Specific Security Policy in Cloud VPNs . . . . 22 4.3.4. Internal Network Monitoring . . . . . . . . . . . . . 23 4.4. Preventing DDoS, Malware, and Botnet Attacks . . . . . . 23 4.5. Regulatory and Compliance Security Policies . . . . . . . 24 5. Management Considerations . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Informative References . . . . . . . . . . . . . . . . . . . 25 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
I2NSF-ANALYSIS]. The growing challenges and complexity in maintaining a secure infrastructure, complying with regulatory requirements, and controlling costs are enticing enterprises into consuming network security functions hosted by service providers. The hosted security service is especially attractive to small- and medium-size enterprises which suffer from a lack of security experts to continuously monitor networks, acquire new skills, and propose immediate mitigations to ever increasing sets of security attacks. According to [Gartner], the demand for hosted (or cloud-based) security services is growing. Small- and medium-size businesses (SMBs) are increasingly adopting cloud-based security services to replace on-premises security tools, while larger enterprises are deploying a mix of traditional and cloud-based security services. To meet the demand, more and more service providers are providing hosted security solutions to deliver cost-effective managed security services to enterprise customers. The hosted security services are primarily targeted at enterprises (especially small and medium ones) but could also be provided to any kind of mass-market customer. As a result, the Network Security Functions (NSFs) are provided and consumed in a large variety of environments. Users of NSFs may consume network security services hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both. This document also briefly describes the following use cases summarized by [I2NSF-USECASES]: o I2NSF Access Use Cases [OAM-USECASE], o I2NSF Data Center Use Cases [DC-USECASE], and o Integrated Security with Access Network Use Case [ACCESS-USECASE].
RFC2904] ACL: Access Control List Bespoke security management: Security management that is made to fit a particular customer. DC: Data Center FW: Firewall IDS: Intrusion Detection System IPS: Intrusion Protection System I2NSF: Interface to Network Security Functions NSF: Network Security Function. An NSF is a function that is used to ensure integrity, confidentiality, or availability of network communication; to detect unwanted network activity; or to block, or at least mitigate, the effects of unwanted activity. Flow-based NSF: An NSF that inspects network flows according to a security policy. Flow-based security also means that packets are inspected in the order they are received and without altering packets due to the inspection process (e.g., Medium Access Control (MAC) rewrites, TTL decrement action, or NAT inspection or changes). (Note: Some existing firewalls store packets and look at the packets in logical order, which is not the order these are received in time. This document restricts flow-based NSF to this definition.) Security service provider: A provider of security services to the customers (end users or enterprises) using NSF equipment purchased from vendors or created by the service provider. SDN: Software-Defined Networking. (See [RFC7426] for architecture and terminology or [RFC7149] for a service provider view.) vCPE: virtual Customer Premises Equipment vEPC: virtual Evolved Packet Core [EPC-3GPP] vNSF: Virtual NSF. An NSF that is deployed as a distributed virtual resource.
vPE: virtual Provider Edge VPN: Virtual Private Network
Security Functions in a Demilitarized Zone (DMZ): Examples of this function are firewall/ACLs, IDS/IPS, one or all of AAA services, NAT, forwarding proxies, and application filtering. These functions may be physically on-premise in a server provider's network at the DMZ spots or located in a "virtual" DMZ. Centralized or Distributed Security Functions: The security functions could be deployed in a centralized fashion for ease of management and network design or in a distributed fashion for scaled requirement. No matter how a security function is deployed and provisioned, it is desirable to have the same interface to provision security policies; otherwise, the job of security administration is more complex, requiring knowledge of firewall and network design. Internal Security Analysis and Reporting: Examples of this function are security logs, event correlation, and forensic analysis. Internal Data and Content Protection: Examples of this function are encryption, authorization, and public/private key management for internal databases. Security Gateways and VPN Concentrators: Examples of these functions are IPsec gateways, secure VPN concentrators that handle bridging secure VPNs, and secure VPN controllers for data flows. Given the diversity of security functions, the contexts in which these functions can be deployed, and the constant evolution of these functions, standardizing all aspects of security functions is challenging and probably not feasible. Fortunately, it is not necessary to standardize all aspects. For example, from an I2NSF perspective, there is no need to standardize how every firewall's filtering is created or applied. Some features in a specific vendor's filtering may be unique to the vendor's product, so it is not necessary to standardize these features. What is needed is a standardized interface to control and monitor the rule sets that NSFs use to treat packets traversing through these NSFs. Thus, standardizing interfaces will provide an impetus for standardizing established security functions. I2NSF may specify some filters, but these filters will be linked to specific common functionality developed by I2NSF in information models or data models.
FIREWALLS]) must include a mechanism to provide monitoring feedback in order to determine the intrusion has been stopped. Therefore, it is necessary to have a mechanism to monitor and provide execution status of NSFs to security and compliance management tools. Such mechanisms exist in vendor-specific network security interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs. ETSI-NFV] creates new management challenges for security policies to be enforced by distributed vNSFs. A vNSF has higher risk of changes to the state of network connection, interfaces, or traffic, as their hosting Virtual Machines (VMs) are being created, moved, or decommissioned.
SDN-SECURITY]), more clients, applications, or application controllers need to dynamically update their security policies that are enforced by NSFs. The security service providers have to dynamically update their decision-making process (e.g., in terms of NSF resource allocation and invocation) upon receiving security- related requests from their clients.
3.1.8. Lack of Mechanisms to Accept External Alerts to Trigger Automatic Rule and Configuration ChangesNSFs can ask the I2NSF security controller to alter specific rules and/or configurations. For example, a Distributed Denial of Service (DDoS) alert could trigger a change to the routing system to send traffic to a traffic scrubbing service to mitigate the DDoS. The DDoS protection has two parts: a) the configuration of signaling of open threats and b) DDoS mitigation. The DOTS controller manages the signaling part of DDoS. I2NSF controller(s) would control any changes to affected policies (e.g., forwarding and routing, filtering, etc.). By monitoring the network alerts regarding DDoS attacks (e.g., from DOTS servers or clients), the I2NSF controller(s) can feed an alerts analytics engine that could recognize attacks so the I2NSF can enforce the appropriate policies. DDoS mitigation is enhanced if the provider's network security controller can monitor, analyze, and investigate the abnormal events and provide information to the customer or change the network configuration automatically. [CAP-INTERFACE] provides details on how monitoring aspects of the flow-based Network Security Functions (NSFs) can use the I2NSF interfaces to receive traffic reports and enforce appropriate policies.
The keys may be used for message authentication and integrity in order to protect data flows. In addition, keys may be used to secure the protocols and messages in the core routing infrastructure (see [RFC4948]). As of now, there is not much focus on an abstraction for keying information that describes the interface between protocols, operators, and automated key management. An example of a solution may provide some insight into why the lack of a mechanism is a problem. If a device had an abstract key table maintained by security services, it could use these keys for routing and security devices. What does this take? Conceptually, there must be an interface defined for routing/ signaling protocols that can a) make requests for automated key management when it is being used and b) notify the protocols when keys become available in the key table. One potential use of such an interface is to manage IPsec security associations on Software- Defined Networks. An abstract key service will work under the following conditions: 1. I2NSF needs to design the key table abstraction, the interface between key management protocols and routing/other protocols, and possibly security protocols at other layers. 2. For each routing/other protocol, I2NSF needs to define the mapping between how the protocol represents key material and the protocol-independent key table abstraction. If several protocols share common mechanisms for authentication (e.g., TCP Authentication Option [RFC5925]), then the same mapping may be used for all usages of that mechanism. 3. Automated key management needs to support both pairwise keys and group keys via the abstract key service provided by items 1 and 2. I2NSF controllers within the NSF that are required to exchange data with NSFs may exchange data with individual NSFs using individual pairwise keys or with a group of NSFs simultaneously using an IP group address secured by a group security key(s).
Figure 1, the customer would have to learn about the particular provider's firewall/IPS interface and send the request in the provider's required format.
+------------+ | Security | | Management | | System | +----||------+ || Proprietary || or I2NSF Standard Video: || Port 10 +--------+ --------| FW/IPS |------------- Encrypted +--------+ Video Flow Figure 1: Example of Non-standard vs. Standard Interface In contrast, as Figure 1 shows, if a firewall/IPS interface standard exists, the customer would be able to send the request to a security management system, and the security management would send it via a I2NSF standard interface. Service providers could now utilize the same standard interface to represent firewall/IPS services implemented using products from many vendors.
provide customers an evaluation about the current security systems and to quickly plan for future security policies using "what-if" scenarios based on today's information. CTA]. The standard interface to provide security profiles to the NSF should interwork with the formats that exchange security profiles between organizations. One objective of the I2NSF work is to provide this type of standard interface to security profiles. Section 3.6) examine what happens in two specific network scenarios: a) multi-domain control of security devices hosted on virtual and non-virtual NSFs and b) Software-Defined Networking.
Hosted security service may instantiate NSFs in virtual machines that are sometimes widely distributed in the network and sometimes are combined together in one device to perform a set of tasks for delivering a service. Hosted security services may be connected within a single service provider or via multiple service providers. Ensuring that the security service purchased by the customer adheres to customer policy requires that the central controller(s) for this service monitor and validate this service across multiple networks on NSFs (some of which may be virtual networks on virtual machines). To set up this cross-domain service, the security controller must be able to communicate with NSFs and/or controllers within its domain and across domains to negotiate for the services needed. Without standard interfaces and security policy data models, the enforcement of a customer-driven security policy remains challenging because of the inherent complexity created by combining the invocation of several vendor-specific security functions into a multi-vendor, heterogeneous environment across multiple domains. Each vendor-specific function may require specific configuration procedures and operational tasks. Ensuring the consistent enforcement of the policies at various domains is also challenging. Standard data models are likely to contribute to solving that issue.
Figure 2: +----------+ +-------+ | | +-------+ | | Interface 1 |Security | Interface 2 | NSF(s)| |Client <--------------> <------------------> | | | |Controller| | | +-------+ | | +-------+ +----------+ Figure 2: Interaction between Entities Interface 1 is used for receiving security requirements from a client and translating them into commands that NSFs can understand and execute. The security controller also passes back NSF security reports (e.g., statistics) to the client that the security controller has gathered from NSFs. Interface 2 is used for interacting with NSFs according to commands (e.g., enact/revoke a security policy or distribute a policy) and collecting status information about NSFs. Client devices or applications can require the security controller to add, delete, or update rules in the security service function for their specific traffic. When users want to get the executing status of a security service, they can request NSF status from the client. The security controller will collect NSF information through Interface 2, consolidate it, and give feedback to the client through Interface 1. This interface can
be used to collect not only individual service information, but also aggregated data suitable for tasks like infrastructure security assessment. Customers may require validating NSF availability, provenance, and execution. This validation process, especially relevant to vNSFs, includes at least: Integrity of the NSF: Ensuring that the NSF is not compromised; Isolation: Ensuring the execution of the NSF is self-contained for privacy requirements in multi-tenancy scenarios; and Provenance of the NSF: Customers may need to be provided with strict guarantees about the origin of the NSF, its status (e.g., available, idle, down, and others), and feedback mechanisms so that a customer may be able to check that a given NSF or set of NSFs properly conform to the customer's requirements and subsequent configuration tasks. In order to achieve this, the security controller may collect security measurements and share them with an independent and trusted third party (via Interface 1) in order to allow for attestation of NSF functions using the third-party added information. This implies that there may be the following two types of clients using Interface 1: the end user and the trusted, independent third party. The I2NSF work may determine that Interface 1 creates two sub-interfaces to support these two types of clients. Figure 3 shows how different types of customers connect through virtual access nodes (vCPE, vPE, and vEPC) to an NSF. The vCPE described in use case #7 in [NFVUC] requires a model of access virtualization that includes mobile and residential access networks where the operator may offload security services from the customer's local environment (e.g., device or terminal) to its own infrastructure.
These use cases define the interaction between the operator and the vNSFs through automated interfaces that support the business communications between customer and provider or between two business entities. Customer + Access + PoP / Data Center | | +--------+ | ,-----+--. |Network | | ,' | `-|Operator| +-------------+ | /+----+ | |Mgmt Sys| | Residential |-+------/-+vCPE+----+ +--------+ +-------------+ | / +----+ | \ | : | / | \ | | +----------+ | ; +----+ | +----+ | |Enterprise|---+---+----+ vPE+--+----+ NSF| | +----------+ | : +----+ | +----+ | | : | / | +--------+ | : +----+ | / ; | Mobile |-+-----\--+vEPC+----+ / +--------+ | \ +----+ | Service / | `--. | Provider / | `----+---------.. + + ^^ || Service Provider encompasses everything in circle vCPE - virtual customer premises equipment vPE - virtual provider edge vEPC - virtual evolved packet core PoP - point of presence Figure 3: NSF and Actors Different access clients may have different service requests: Residential: service requests for parental control, content management, and threat management. Threat content management may include identifying and blocking malicious activities from web contents, mail, or files downloaded. Threat management may include identifying and blocking botnets or malware. Enterprise: service requests for enterprise flow security policies and managed security services.
Flow security policies identify and block malicious activities during access to (or isolation from) web sites or social media applications. Managed security services for an enterprise may include detection and mitigation of external and internal threats. External threats can include application or phishing attacks, malware, botnet, DDoS, and others. Service Provider: service requests for policies that protect service provider networks against various threats (including DDoS, botnets, and malware). Such policies are meant to securely and reliably deliver contents (e.g., data, voice, and video) to various customers, including residential, mobile, and corporate customers. These security policies are also enforced to guarantee isolation between multiple tenants, regardless of the nature of the corresponding connectivity services. Mobile: service requests from interfaces that monitor and ensure user quality of experience, content management, parental controls, and external threat management. Content management for the mobile device includes identifying and blocking malicious activities from web contents, mail, and files uploaded/downloaded. Threat management for infrastructure includes detecting and removing malicious programs such as botnet, malware, and other programs that create DDoS attacks). Some access customers may not care about which NSFs are utilized to achieve the services they requested. In this case, provider network orchestration systems can internally select the NSFs (or vNSFs) to enforce the security policies requested by the clients. Other access customers, especially some enterprise customers, may want to contract separately for dedicated NSFs (most likely vNSFs) for direct control purposes. In this case, here are the steps to associate vNSFs to specific customers: vNSF Deployment: The deployment process consists of instantiating an NSF on an NFV Infrastructure (NFVI), within the NSP administrative domain(s) or with other external domain(s). This is a required step before a customer can subscribe to a security service supported in the vNSF. vNSF Customer Provisioning: Once a vNSF is deployed, any customer can subscribe to it. The provisioning life cycle includes the following: * Customer enrollment and cancellation of the subscription to a vNSF.
* Configuration of the vNSF, based on specific configurations or derived from common security policies defined by the NSP. * Retrieval of the vNSF functionalities, extracted from a manifest or a descriptor. The NSP management systems can demand this information to offer detailed information through the commercial channels to the customer.
firewalls to suit each client's security policy requirements, which can be numerous. What is needed is the ability to dynamically deploy virtual firewalls for each client's set of servers based on established security policies and underlying network topologies. Figure 4 shows an example topology of virtual firewalls within a data center. ---+-----------------------------+----- | | +---+ +-+-+ |vFW| |vFW| +---+ +-+-+ | Client #1 | Client #2 ---+-------+--- ---+-------+--- +-+-+ +-+-+ +-+-+ +-+-+ |VM | |VM | |VM | |VM | +---+ +---+ +---+ +---+ Figure 4: NSF in Data Centers
to dynamically view (let alone change) what, where, and how security policies are implemented on their provider-operated clouds. Indeed, no standards-based framework exists to allow clients to retrieve/ manage security policies in a consistent manner across different providers. As described above, the dynamic key management is critical for securing the VPN and the distribution of policies.
PCI-DSS] for the payment industry or the Health Insurance Portability and Accountability Act [HIPAA] for the healthcare industry, must be able to isolate various kinds of traffic. They must also show records of their security policies whenever audited. The I2NSF client-side interface could be used to provision regulatory and compliance-related security policies. The security controller would keep track of when and where a specific policy is applied and if there is any policy violation; this information can be provided in the event of an audit as proof that traffic is isolated between specific endpoints, in full compliance with the required regulations.
The traffic flow security policies specified by customers can conflict with providers' internal traffic flow security policies. This conflict can be resolved in one of two ways: a) installed policies can restrict traffic if either the customer traffic flow security policies or the provider's internal security policies restrict traffic, or b) installed policies can only restrict traffic if both the customer traffic flow security policies and the provider's internal traffic flow security policies restrict data. Either choice could cause potential problems. It is crucial for the management system to flag these conflicts to the customers and to the service provider. It is important to proper AAA [RFC2904] to authorize access to the network and access to the I2NSF management stream. Enforcing the appropriate privacy is key to all IETF protocols (see [RFC6973]) and is especially important for IETF security management protocols since they are deployed to protect the network. In some circumstances, security management protocols may be utilized to protect an individual's home, phone, or other personal data. In this case, any solution should carefully consider whether combining management streams abides by the recommendations of [RFC6973] for data minimization, user participation, and security. [ACCESS-USECASE] Wang, K. and X. Zhuang, "Integrated Security with Access Network Use Case", Work in Progress, draft-qi-i2nsf-access-network-usecase-02, March 2015. [CAP-INTERFACE] Zhou, C., Xia, L., Boucadair, M., and J. Xiong, "The Capability Interface for Monitoring Network Security Functions (NSF) in I2NSF", Work in Progress, draft-zhou-i2nsf-capability-interface-monitoring-00, October 2015. [CTA] "Cyber Threat Alliance", <http://cyberthreatalliance.org>. [DC-USECASE] Zarny, M., Majee, S., Leymann, N., and L. Dunbar, "I2NSF Data Center Use Cases", Work in Progress, draft-zarny-i2nsf-data-center-use-cases-00, October 2014. [EPC-3GPP] Firmin, F., "The Evolved Packet Core", January 2017.
[ETSI-NFV] ETSI, "Network Functions Virtualisation (NFV); Architectural Framework", ETSI GS NFV 002 V1.2.1, December 2014. [FIREWALLS] Baker, F. and P. Hoffman, "On Firewalls in Internet Security", Work in Progress, draft-ietf-opsawg-firewalls-01, October 2012. [Gartner] Messmer, E., "Gartner: Cloud-based security as a service set to take off", October 2013. [HIPAA] US Congress, "Health Insurance Portability and Accountability Act of 1996 (Public Law 104-191)", August 1996, <https://www.hhs.gov/hipaa/>. [I2NSF-ANALYSIS] Hares, S., Moskowitz, R., and D. Zhang, "Analysis of Existing work for I2NSF", Work in Progress, draft-ietf-i2nsf-gap-analysis-03, March 2017. [I2NSF-USECASES] Pastor, A., Lopez, D., Wang, K., Zhuang, X., Qi, M., Zarny, M., Majee, S., Leymann, N., Dunbar, L., and M. Georgiades, "Use Cases and Requirements for an Interface to Network Security Functions", Work in Progress, draft-pastor-i2nsf-merged-use-cases-00, June 2015. [NFVUC] ETSI, "Network Functions Virtualization (NFV); Use Cases", ETSI GR NFV 001 V1.2.1, May 2017. [OAM-USECASE] Pastor, A. and D. Lopez, "Access Use Cases for an Open OAM Interface to Virtualized Security Services", Work in Progress, draft-pastor-i2nsf-access-usecases-00, October 2014. [PCI-DSS] PCI Security Standards Council, "Payment Card Industry (PCI) Data Security Standard -- Requirements and Security Assessment Procedures", PCS DSS v3.2, April 2016, <https://www.pcisecuritystandards.org/pci_security/>. [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and D. Spence, "AAA Authorization Framework", RFC 2904, DOI 10.17487/RFC2904, August 2000, <http://www.rfc-editor.org/info/rfc2904>.
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, DOI 10.17487/RFC4948, August 2007, <http://www.rfc-editor.org/info/rfc4948>. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>. [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>. [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <http://www.rfc-editor.org/info/rfc7149>. [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <http://www.rfc-editor.org/info/rfc7426>. [SDN-SECURITY] Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, "Software-Defined Networking Based Security Services using Interface to Network Security Functions", Work in Progress, draft-jeong-i2nsf-sdn-security-services-05, July 2016.
Diego R. Lopez Telefonica I+D Don Ramon de la Cruz, 82 Madrid 28006 Spain Email: firstname.lastname@example.org Myo Zarny vArmour 800 El Camino Real, Suite 3000 Mountain View, CA 94040 United States of America Email: email@example.com Christian Jacquenet France Telecom Rennes, 35000 France Email: Christian.firstname.lastname@example.org Rakesh Kumar Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America Email: email@example.com Jaehoon Paul Jeong Department of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Fax: +82 31 290 7996 Email: firstname.lastname@example.org URI: http://iotlab.skku.edu/people-jaehoon-jeong.php