One document matched: draft-bajko-mext-sod-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC3775 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>
<!ENTITY RFC5555 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5555.xml'>
<!ENTITY RFC4877 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4877.xml'>
<!ENTITY I-D.ietf-mext-mip6-tls PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mext-mip6-tls.xml'>
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocappendix="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
docName="draft-bajko-mext-sod-02"
ipr="trust200902"
>
<front>
<title abbrev="Mobile IPv6: Security on demand">Security on Demand
for Mobile IPv6 and Dual-stack Mobile IPv6</title>
<author initials="G" surname="Bajko" fullname="Gabor Bajko">
<organization>Nokia</organization>
<address>
<postal>
<street>323 Fairchild drive 6</street>
<city>Mountain view</city>
<region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>gabor.bajko@nokia.com</email>
</address>
</author>
<author initials="B" surname="Patil"
fullname="Basavaraj Patil">
<organization>Nokia</organization>
<address>
<postal>
<street>6021 Connection drive</street>
<city>Irving</city>
<region>TX</region>
<code>75039</code>
<country>USA</country>
</postal>
<email>basavaraj.patil@nokia.com</email>
</address>
</author>
<author fullname="Teemu Savolainen" initials="T" surname="Savolainen">
<organization>Nokia</organization>
<address>
<postal>
<street>Hermainkatu 12 D</street>
<city>Tampere</city>
<region>FI</region>
<code>33720</code>
<country>Finland</country>
</postal>
<email>teemu.savolainen@nokia.com</email>
</address>
</author>
<date year="2011" />
<area>Internet</area>
<workgroup>Individual Submission</workgroup>
<keyword>Mobile IPv6</keyword>
<keyword>Dual stack Mobile IPv6</keyword>
<keyword>Security</keyword>
<keyword>Mobility</keyword>
<abstract>
<t>
Mobile IPv6 and Dual-stack Mobile IPv6 protocols require the
signaling messages between the mobile node and home agent to be
secured. However security for
the user plane/traffic is optional and is a choice left to the mobile node.
This document proposes extensions to Mobile IPv6 signaling which
enables the user plane traffic to be secured on a need or on-demand basis. The
mobile node or the home agent can request at any time security for
the user plane traffic. Security for user plane traffic can be
triggered as a result of policy or, mobility or, at the user's choice.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Mobile IPv6 <xref target="RFC3775" /> and Dual-stack Mobile
IPv6 <xref target="RFC5555" /> provide
the option to secure the user plane data between the Mobile Node
(MN) and and the Home Agent (HA) when needed. The user plane traffic
between the MN and HA is secured via an IPsec security association
(SA) which is established between them specifically for the purpose
of user plane data. IPsec is used for securing the user plane
traffic when the security between the MN and HA is based on IPsec.
However security between the MN and HA could also be enabled via
other protocols. The MEXT WG is evaluating on an experimental basis
various alternatives to IPsec such as the one specified in
<xref target="I-D.ietf-mext-mip6-tls"/>.
</t>
<t>
As per the current specifications for MIP6 and DSMIP6, security of
the user plane traffic is optional. When the MN is attached to 3G/4G
network such as HSPA, LTE or EV-DO, the MN may not require security
for the user plane traffic since these networks already provide
ciphering over the air-interface and deploy hop-by-hop security,
which makes these networks secure. However the MN may attach to less
secure or unsecured accesses such as wireless lan (WLAN) or it may
roam in countries where the user may prefer the data between the MN
and the HA to be encrypted (even when using cellular accesses).
There is no solution in the protocol specification today which
provides the capability to trigger the security for the user plane
traffic on a need basis.
</t>
<t>
The problem that is being addressed is the triggering of security
for user plane traffic between the MN and HA on a need basis. Policy
information at the MN or information provided to the MN via other
means at the time of attachment may assist the MN to determine if
security needs to be enabled for user plane traffic. The user may
also consciously decide to enable security when attached to certain
networks. Furthermore, the operator of HA may have policies that
define when user plane security is to be used. This document
describes a mechanism which can enable security for user plane
traffic on-demand or need.
</t>
<t>
An obvious implementation alternative would be to encrypt user plane
traffic always (as is commonly done with VPN use-cases), but that
would unnecessarily consume resources on the HA. For the HA operator
there is clear economic incentive to encrypt user-plane data only
when necessary.
The MIP6/DSMIP6 protocols only provide a means to secure the user
plane traffic but do not provide any mechanisms by which the
security is triggered as a result of mobility or the MN attaching
via different access networks.
</t>
<t>
As per the current MIP6 <xref target="RFC3775" />
specification, only the MN has the
ability to enable security for user-plane traffic. The HA has no
ability to force the MN to secure user traffic.
</t>
</section>
<section title="When to apply Security to user plane traffic">
<t>
An MN MUST have security for the control plane messages. Hence all
signaling between the MN and HA are secured. The MN establishes an
IPsec SA between itself and the assigned HA prior to sending a
Binding Update. However, the MN is not required to establish an SA
for securing the user plane traffic. It is up to the MN whether it
establishes SAs for the control plane and user plane at the same
time or if it only establishes the control plane SA. The MN may
choose to establish the SA for user plane traffic at any time
<xref target="RFC4877" />.
</t>
<t>
When the MN attaches to an access network, it is usually able to
determine if the access network is viewed as trusted or untrusted.
The MN can make this determination, for example, based on the PLMN
ID of the cellular network; or wifi_SSID/MAC_address of a wifi
network; or location information provided by the MN, or user input.
The MN has either a stored policy about trusted and untrusted access
networks or it may be provided with such information from policy
stores such as the ANDSF <xref target="23.402" /> or AAA server at the time of
network attachment. An interface exists generally between the policy
store such as AAA or ANDSF and the Home Agent (HA).
If the MN is attached to an access network which is viewed as
trusted or where encryption is not allowed, the MN chooses not to
secure the user plane traffic.
</t>
<t>
If the MN is attached to an access network which is not trusted, the
MN may want to secure its user plane traffic. The HA may also be
able to determine from the source address of the binding update (BU)
message the access network to which the MN is currently attached.
Based on this information, the HA may require that the user plane
traffic be encrypted on the MN-HA link.
</t>
<t>
The MN or HA can determine when to use security for the user plane
traffic using static policies or dynamic policies which can be
obtained at the time of network attachment; or e.g. which are
provisioned and maintained on a smartcard (eg, a UICC or SIM). 3GPP
policy stores such as the ANDSF can also provide information about
the access networks to which an MN is attached. Location of the MN
can also be used as input.
</t>
</section>
<section title="Triggering user plane traffic security">
<t>
This document proposes extensions to MIPv6/DSMIPv6 protocol,
allowing the MN to signal to the HA its preference for user plane
traffic security, and for the HA to override that preference based
on the policy settings.
</t>
<t>
One of the reserved bits of the Binding Update
<xref target="RFC3775" /> message is
defined to be the 'Security' flag "S", and one of the reserved bits
of the Binding Acknowledgement <xref target="RFC3775" />
message is also defined to
be the 'Security' flag "S".
</t>
<t>
The MN sends a binding update with the "S" flag set to 0, when
indicating that the user plane traffic will not be encrypted. The HA
processes the binding update message from the MN and sends a
response acknowledging the request and setting the flag for user
plane traffic security to Null indicating to the MN that the traffic
on the link between the MN and HA will not be encrypted.
</t>
<t>
The MN sends a binding update with the "S" flag set to 1, when
indicating that prefers the user plane traffic be encrypted. The HA
processes the binding update message from the MN and sends a
response acknowledging the request and setting the flag for user
plane traffic security to 1, indicating to the MN that the traffic
on the link between the MN and HA will be encrypted.
</t>
<t>
The HA MAY always overwrite the MN's security preference on the user
plane traffic indicated in the Binding Update message, by setting
the "S" flag in the Binding Acknowledgement to a different value.
The MN SHALL always follow the indication in the Binding
Acknowledgement to set the security of the MN to HA user plane
traffic.
</t>
</section>
<section title = "Extensions to Mobile IPv6">
<section title = "Extensions to Binding Update and Binding Acknowledgement">
<t>
This section defines the new "S" flag for the Binding Update and the
corresponding Binding Acknowledgement message:
<figure title="S flag in BU"
anchor="fig:S flag in Binding Update">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|S| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
</t>
<t>
<list style="hanging">
<t hangText="S">
When set, this flag indicates MN prefers to turn on user plane
traffic encryption. When clear, MN prefers not to use security for
user plane data.
</t>
</list>
</t>
<t>
The corresponding Binding Acknowledgement Message looks as
follows:
<figure title="S flag in BAck"
anchor="fig:S flag in Binding Acknowledgment">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
</t>
<t>
<list style="hanging">
<t hangText="S">
When set, this flag indicates HA acknowledges, or strongly
recommends, use of user plane encryption. When clear, HA does not
support or allow use of user plane encryption.
</t>
</list>
</t>
</section>
<section title="New binding Update Mobility Options">
<t>
A new mobility Options for carrying location of the MN is defined to
be used in a Binding Update message with the following
format:
<figure title="MN location"
anchor="fig: Location info in BU">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |N| Reserved | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
</t>
<t>
Type: tbd
</t>
<t>
N set to 1 indicates that the data contains a location in XML
format as defined in RFC5139, N set to zero indicates that the
data part contains an http URI pointing to a resource where the
MN uploaded its location
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document will require actions on the part of IANA to
assign values for the new binding update mobility option.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
This I-D introduces extensions to Mobile IPv6 signaling messages.
There is no impact to the security model and architecture that is
currently specified for MIP6 <xref target="RFC3775"
/>. The extensions specified in
this document do not introduce any new vulnerabilities of threats to
the security architecture of Mobile IPv6.
</t>
</section>
<section title="Summary">
<t>
Security for the user plane traffic between the MN and Home agent
can be switched on or off as a result of policy, location or, request by the
user. The ability to control and trigger the security for the user plane
traffic rests with the MN as well as the HA with the HA having the final say.
</t>
</section>
<section title="Acknowledgments">
<t>
The authors acknowledge the reviews by Julien Laganier, Jouni
Korhonen, Stefano Faccin and Kent Leung. Their comments and
suggestions will be incorporated in the next revision.
</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor='23.402'>
<front>
<title>3GPP TS 23.402, Architecture enhancements for non-3GPP
accesses,
</title>
<author><organization>3rd generation partnership project (3GPP)
</organization> </author>
</front>
<format type='MSW'
target='http://www.3gpp.org/ftp/Specs/latest/Rel-9/23_series/23402-930.zip' />
</reference>
</references>
<references title="Normative References">
&RFC3775;
&RFC5555;
&RFC4877;
&I-D.ietf-mext-mip6-tls;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:57:26 |