MIF Working Group D. Migault Internet-Draft Francetelecom - Orange Intended status: Standards Track C. Williams Expires: September 2, 2012 MCSR Labs March 1, 2012 Multiple Interfaces Security Requirements for Offload draft-mglt-mif-security-requirements-00.txt Abstract Current Radio Access Network (RAN) infrastructure will not be able to deal with the next future traffic increase. As such traffic is being offloaded on alternate networks like WLAN. Contrary to RAN, WLAN MAY not be trusted networks, so the End User has to secure offloaded communications. Current offload architectures consist in tunneling the End User traffic to a Security Gateway. Alternatively, ISPs MAY provide End-to-End security and connect directly the End User to the Server. Because WLAN network are not managed by ISPs, WLAN Access Points MAY not be reliable making End User willing to benefit from multiple connections. This draft presents the Security Requirements for an offloaded End User with multiple interfaces. From the Security Requirements, the draft explains why IPsec is the most appropriated security protocol, and points the Multihoming feature current IKEv2 Extension MOBIKE are lacking. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 2, 2012. Copyright Notice Migault & Williams Expires September 2, 2012 [Page 1] Internet-Draft Securing Multiple Interfaces March 2012 Copyright (c) 2012 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. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Offload Security Requirements . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative Reference . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Migault & Williams Expires September 2, 2012 [Page 2] Internet-Draft Securing Multiple Interfaces March 2012 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction ISP main motivation is to provide services to its End Users. This means providing the infrastructure that supports the mobile data traffic generated by its End Users as well as the best Quality of Service. Current ISP RAN architecture will not be able to support next future mobile data. The most effective way to deal with that traffic is to take advantage of deployed WLAN and offload the RAN traffic to WLAN. This architecture requires the End User to deal with at least two different interfaces connected to two distinct networks that provides different level of Trust and different level of Quality of Service. For example, IWLAN is the proposed offload architecture by 3GPP. The End User connected to a WLAN set up an IPsec tunnel with the ISP Tunnel Terminating Gateway (TTG), and forwards its traffic. Communications with an ISP service hosted application are forwarded to the Gateway GPRS Support Node (GGSN), otherwise Internet communications are forwarded to the Packet Data Gateway (PGD). However, this IWLAN architecture offloads the whole traffic of the End User, and ignores services specificities. For example, services are good candidates for offloading their traffic - like hight bandwidth ISP service hosted. Other services MAY not be offloaded and use only RAN - either for confidentiality or Quality of Service Motivations. A third category of services MAY not be offloaded and redirected to the ISP CORE Network, but instead should go directly on the Internet. As such, there are different offload policies based on the services. In fact the Security Gateway introduces some latencies, and possibly routing indirections that MAY affect some Real Time Applications. In addition to the offload policies, services MAY behave differently during offload. One example described in [Lee] is the "on-the-spot" strategy that takes advantage of WLAN higher bandwidth to reduce the overall downloading time and thus save battery. With the "on-the- spot" strategy, if no WLAN is accessible, the application interrupts the download until a WLAN is accessible - instead of switching to the RAN. Of course, if after a pre-defined delay, no WLAN has been found, then the application switches to the RAN. This strategy especially targets services that do not have real time requirements Migault & Williams Expires September 2, 2012 [Page 3] Internet-Draft Securing Multiple Interfaces March 2012 and experimentations show that this increases offloaded data up to 29%, and saves 20% of the battery. As a results applications MAY have different interests toward offload which makes ISPs consider not only offloading the whole End User traffic, but also apply offloading policies on a per-service basis. In an offload situation, security and other service based features such as transport policies MAY be adapted. Then security and other services based features MAY depend on the network, the End User is attached to. For example, WLAN managed by the ISP MAY not modify consequently the level of trust compared to RAN. On the other hand a WLAN provided by a third entity MAY be considered as untrusted. ISPs have a good knowledge of the Quality and level of trust of network the End User is attached to and so are good candidates for proposing an offload service for their own application or as service for third party services. In an offload situation, the End User is expected to be able to perform: - Offload Mobility between a trusted network (for example RAN) to an untrusted Network (for example WLAN) - Offload Mobility from one WLAN access Point to another WLAN Access Point. - Offload Multihoming for WLAN Access Point Fail over - Offload Multihoming for simultaneous use of multiple Interfaces This draft concerns both Multihoming and Security. As such Offload Mobility operations are out of scope of the draft. 3. Offload Security Requirements From section Section 2 this section lists the security requirements. A first list of requirements provides generic requirements that defines the granularity the Offload Security protocols SHOULD base their policy on, the layer secured by the Offload Security, the network architectures the Security Layer will be integrated to, as well as the authentication methods that SHOULD be supported. Granularity: Offload Security policies are established according to various criteria such as sub network and IP addresses to identify the network, ports and protocols to identify the service Migault & Williams Expires September 2, 2012 [Page 4] Internet-Draft Securing Multiple Interfaces March 2012 Security Layer: Offload Security SHOULD NOT require modification of the code of a running service Architecture: Offload Security MUST fit architectures with a Security Gateway that secure a global traffic, as well as architectures with a direct connection between the End User and the Service. Authentication: Offload Security MAY provide authentication mechanisms from the WLAN that are similar to those provided on the RAN. This would provide the opportunity for End User to access their service directly from the WLAN rather being authenticated by the RAN and then offloaded on the WLAN. Then follows the Multihoming related Security Requirements: Failover: WLAN Access Point MAY not be maintained by the ISP, and so MAY be unreliable. When the End User is connected to a service or to a Security Gateway using a Primary IP address, the End User MUST be able to provide a list of Alternate IP addresses which MAY be used in case the Primary IP address is not reachable. Alternate IP addresses are provided for a given communication, a Primary IP addresses is replaced by an Alternate IP address, and Primary and Alternate are not used simultaneously for the same communication. Simultaneous Interfaces: Another way to get around WLAN unreliability is that the End User is connected simultaneously to various WLAN Access Points. This makes the End User to split its traffic between various WLAN Access Points, limiting the impact of an Access Point Failure. More specifically, this would in the worst case require restarting a subset of the applications rather than all the applications. How the End User splits its traffic is out of scope of the draft. The End User can assign various services to different WLAN Access Points, or splits flows of a given service between the different WLAN Access Points. The advantage of having multiple simultaneous connections to various WLAN Access Points, is that the End User can measure and estimate the best path, and manage its traffic according to its measurements. As such, the Security Requirements for Offload Multihoming with Simultaneous Interfaces are: 1) When the End User has established a secure communication with the server, it MUST be able to ADD an Interface to that communication. 2) When the End User detects that one WLAN provides better connectivity, it MUST be able to switch the traffic from one Interface to another. 3) Then when the End User is not anymore attached to one WLAN, it MUST be able to advertise the Server, the interface is not valid anymore and to REMOVE it. Migault & Williams Expires September 2, 2012 [Page 5] Internet-Draft Securing Multiple Interfaces March 2012 4. Problem Statement Comparing TLS [RFC5246] /DTLS [RFC5238] and IPsec with the generic Security Requirements of section Section 3 shows that IPsec [RFC4301] is advised to Offload Security. TLS/DTLS does not provide other granularity than a service granularity (port). In other words, DTLS/ TLS provides a secure version of a given service. Then TLS/DTLS main drawback is that it requires code modifications, and thus makes ISP Offload service hard to be deployed for third party. Furthermore, TLS/DTLS has mainly been designed for End-to-End connectivity, and MAY not fit all requirements of a Security Gateway Architecture. At last TLS/DTLS does not provide EAP [RFC3748] framework for authentication. On the other hand, IPsec addresses all the security requirements. IPsec defines Security Policies according to various Traffic Selectors that includes subnetworks, IP addresses, ports, and upper layer protocols. Then it secures the IP layer in the kernel, which does not impact the service, and thus makes possible an ISP to provide a Secured Offload for a third party service. IPsec has two modes: the Transport mode for End-to-End connectivity and the Tunnel mode to secure the link between the End User and a Security Gateway. At last IPsec [RFC5998] provides an EAP framework making authentication mechanisms [RFC4186] [RFC4187] on RAN possible on WLAN. In the remainder of this draft we will consider IPsec only. Multihoming Security Requirements are partly handled by IPsec MOBIKE [RFC4555] extension. MOBIKE has been designed for the Tunnel mode only, and provides Mobility and Multihoming Failover for a connection protected with the Tunnel Mode. More specifically, with MOBIKE, IKEv2 can exchange Alternate IP addresses. Once the application detects the primary interface is not available it MAY switch running IPsec tunnel connections on the Alternate IP addresses by UPDATING the Security Associations. However, MOBIKE does not provide Multihoming Failover for communication protected with the Transport Mode. Furthermore, MOBIKE does not provide mechanisms for the use of simultaneous Interfaces. MOBIKE has been designed to UPDATE Security Association, which makes possible to change the outer IP address of the IPsec Tunnel. In conjunction of mechanisms for the use of simultaneous Interfaces, UPDATE can be used for traffic management with Tunnel mode. This traffic management facility is available for the Tunnel Mode and has to be extended to the Transport Mode. A a result Security Requirements are: - Extend MOBIKE Failover for communication protected with the IPsec Transport Mode Migault & Williams Expires September 2, 2012 [Page 6] Internet-Draft Securing Multiple Interfaces March 2012 - Extend MOBIKE UPDATE for communication protected with the IPsec Transport Mode - Extend MOBIKE Multihoming for simulatenous use of multiple interfaces for both IPsec Transport and Tunnel Mode 5. Security Considerations The whole draft is about security. 6. IANA Considerations There is no IANA consideration here. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension for EAP-Only Authentication in IKEv2", RFC 5998, September 2010. 7.2. Informative Reference [Lee] Lee, K., Rhee, I., Lee, J., Yi, Y., and S. Chong, "Mobile data offloading: how much can WiFi deliver?", SIGCOMM ACM, Migault & Williams Expires September 2, 2012 [Page 7] Internet-Draft Securing Multiple Interfaces March 2012 oct 2010. [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP- SIM)", RFC 4186, January 2006. [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006. Authors' Addresses Daniel Migault Francetelecom - Orange 38 rue du General Leclerc 92794 Issy-les-Moulineaux Cedex 9 France Phone: +33 1 45 29 60 52 Email: mglt.ietf@gmail.com Carl Williams MCSR Labs Philadelphia, PA 19103 USA Phone: 650-279-5903 Email: carlw@mcsr-labs.org Migault & Williams Expires September 2, 2012 [Page 8]