One document matched: draft-mglt-mif-security-requirements-00.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:/tmp/CGI11956.1"?><?rfc linefile="1:/tmp/CGI11956.1"?>
<!-- automatically generated by xml2rfc v1.33 on 2008-07-10T15:43:43Z -->
<!-- automatically generated by xml2rfc v1.33 on 2008-07-10T15:43:43Z -->
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4301 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'>
<!ENTITY rfc5246 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY rfc5238 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5238.xml'>
<!ENTITY rfc4555 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4555.xml'>
<!ENTITY rfc5998 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5998.xml'>
<!ENTITY rfc3748 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
<!ENTITY rfc4017 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4017.xml'>
<!ENTITY rfc4187 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4187.xml'>
<!ENTITY rfc4186 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4186.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-mglt-mif-security-requirements-00.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Securing Multiple Interfaces">Multiple Interfaces Security Requirements for Offload</title>
<author fullname='Daniel Migault' initials='D.M' surname="Migault" >
<organization>Francetelecom - Orange</organization>
<address>
<postal>
<street>38 rue du General Leclerc</street>
<city>92794 Issy-les-Moulineaux Cedex 9</city>
<country>France</country>
</postal>
<phone>+33 1 45 29 60 52</phone>
<email>mglt.ietf@gmail.com</email>
</address>
</author>
<author fullname='Carl Williams' initials='C.W' surname="Williams" >
<organization>MCSR Labs</organization>
<address>
<postal>
<street></street>
<city>Philadelphia, PA 19103</city>
<country>USA</country>
</postal>
<phone> 650-279-5903</phone>
<email>carlw@mcsr-labs.org</email>
</address>
</author>
<date month="March" year="2012"/>
<area>INTERNET</area>
<workgroup>MIF Working Group</workgroup>
<abstract>
<t> 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.</t>
<t>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. </t>
</abstract>
</front>
<middle>
<section title="Requirements notation">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Introduction" anchor="introduction">
<t>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.</t>
<t>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).</t>
<t>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.</t>
<t>In addition to the offload policies, services MAY behave differently during offload. One example described in <xref target="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 and experimentations show that this increases offloaded data up to 29%, and saves 20% of the battery.</t>
<t>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.</t>
<t>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.</t>
<t>In an offload situation, the End User is expected to be able to perform:
<list style="hanging" hangIndent="6">
<t hangText="-">Offload Mobility between a trusted network (for example RAN) to an untrusted Network (for example WLAN)</t>
<t hangText="-">Offload Mobility from one WLAN access Point to another WLAN Access Point.</t>
<t hangText="-">Offload Multihoming for WLAN Access Point Fail over</t>
<t hangText="-">Offload Multihoming for simultaneous use of multiple Interfaces</t>
</list>
</t>
<t>This draft concerns both Multihoming and Security. As such Offload Mobility operations are out of scope of the draft.</t>
</section>
<section title="Offload Security Requirements" anchor="security-requirements">
<t>From section <xref target="introduction"/> this section lists the security requirements. </t>
<t>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.
<list style="hanging" hangIndent="6">
<t hangText="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</t>
<t hangText="Security Layer: "> Offload Security SHOULD NOT require modification of the code of a running service </t>
<t hangText="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.</t>
<t hangText="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.</t>
</list>
</t>
<t>Then follows the Multihoming related Security Requirements:
<list style="hanging" hangIndent="6">
<t hangText="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.</t>
<t hangText="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.</t>
</list>
</t>
</section>
<section title="Problem Statement" anchor="problem-statement">
<t>Comparing TLS <xref target="RFC5246"/> /DTLS <xref target="RFC5238"/> and IPsec with the generic Security Requirements of section <xref target="security-requirements"/> shows that IPsec <xref target="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 <xref target="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 <xref target="RFC5998"/> provides an EAP framework making authentication mechanisms <xref target="RFC4186"/> <xref target="RFC4187"/> on RAN possible on WLAN. In the remainder of this draft we will consider IPsec only.</t>
<t>Multihoming Security Requirements are partly handled by IPsec MOBIKE <xref target="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.</t>
<t>A a result Security Requirements are:
<list style="hanging" hangIndent="6">
<t hangText="- ">Extend MOBIKE Failover for communication protected with the IPsec Transport Mode</t>
<t hangText="- ">Extend MOBIKE UPDATE for communication protected with the IPsec Transport Mode</t>
<t hangText="- ">Extend MOBIKE Multihoming for simulatenous use of multiple interfaces for both IPsec Transport and Tunnel Mode </t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>The whole draft is about security.</t>
</section>
<section title="IANA Considerations">
<t>There is no IANA consideration here.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc4301;
&rfc5246;
&rfc5238;
&rfc4555;
&rfc5998;
&rfc3748;
</references>
<references title = 'Informative Reference'>
&rfc4186;
&rfc4187;
<!--
&mobikex;
&msctp;
&mm-requirements;
-->
<reference anchor="Lee">
<front>
<title>Mobile data offloading: how much can WiFi deliver?</title>
<author initials="K" surname="Lee" fullname="K. Lee"/>
<author initials="I" surname="Rhee" fullname="I. Rhee"/>
<author initials="J" surname="Lee" fullname="J. Lee"/>
<author initials="Y" surname="Yi" fullname="Y. Yi"/>
<author initials="S" surname="Chong" fullname="S. Chong"/>
<date month="oct" year="2010" />
</front>
<seriesInfo name="SIGCOMM" value="ACM" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:21:24 |