Multiple Interfaces Security Requirements for Offload
draft-mglt-mif-security-requirements-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Daniel Migault , Carl Williams | ||
| Last updated | 2012-03-01 | ||
| Stream | (None) | ||
| Formats | plain text xml pdf ps htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mglt-mif-security-requirements-00
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]