One document matched: draft-ietf-mobileip-mipv6-ha-ipsec-03.html
<html><head><title>Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents</title>
<STYLE type='text/css'>
.title { color: #990000; font-size: 22px; line-height: 22px; font-weight: bold; text-align: right;
font-family: helvetica, arial, sans-serif }
.filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right;
font-family: helvetica, arial, sans-serif }
p.copyright { color: #000000; font-size: 10px;
font-family: verdana, charcoal, helvetica, arial, sans-serif }
p { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
ol { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
pre { margin-left: 3em; color: #333333 }
ul.toc { color: #000000; line-height: 16px;
font-family: verdana, charcoal, helvetica, arial, sans-serif }
H3 { color: #333333; font-size: 16px; line-height: 16px; font-family: helvetica, arial, sans-serif }
H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, sans-serif }
TD.header { color: #ffffff; font-size: 10px; font-family: arial, helvetica, san-serif; valign: top }
TD.author-text { color: #000000; font-size: 10px;
font-family: verdana, charcoal, helvetica, arial, sans-serif }
TD.author { color: #000000; font-weight: bold; margin-left: 4em; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif }
A:link { color: #990000; font-weight: bold;
font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
A:visited { color: #333333; font-weight: bold;
font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
A:name { color: #333333; font-weight: bold;
font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
.link2 { color:#ffffff; font-weight: bold; text-decoration: none;
font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
font-size: 9px }
.RFC { color:#666666; font-weight: bold; text-decoration: none;
font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
font-size: 9px }
.hotText { color:#ffffff; font-weight: normal; text-decoration: none;
font-family: charcoal, monaco, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
font-size: 9px }
</style>
</head>
<body bgcolor="#ffffff" text="#000000" alink="#000000" vlink="#666666" link="#990000">
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<table width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table width="100%" border="0" cellpadding="2" cellspacing="1">
<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Network Working Group</td><td width="33%" bgcolor="#666666" class="header">J. Arkko</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Internet-Draft</td><td width="33%" bgcolor="#666666" class="header">Ericsson</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Expires: August 19, 2003</td><td width="33%" bgcolor="#666666" class="header">V. Devarapalli</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">Nokia Research Center</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">F. Dupont</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">ENST Bretagne</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">February 18, 2003</td></tr>
</table></td></tr></table>
<div align="right"><font face="monaco, MS Sans Serif" color="#990000" size="+3"><b><br><span class="title">Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents</span></b></font></div>
<div align="right"><font face="monaco, MS Sans Serif" color="#666666" size="+2"><b><span class="filename">draft-ietf-mobileip-mipv6-ha-ipsec-03.txt</span></b></font></div>
<font face="verdana, helvetica, arial, sans-serif" size="2">
<h3>Status of this Memo</h3>
<p>
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet-Drafts.</p>
<p>
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."</p>
<p>
The list of current Internet-Drafts can be accessed at
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
<p>
This Internet-Draft will expire on August 19, 2003.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (C) The Internet Society (2003). All Rights Reserved.</p>
<h3>Abstract</h3>
<p>Mobile IPv6 uses IPsec to protect signaling between the home agent and
the mobile node. Mobile IPv6 base document defines the main requirements
these nodes must follow. This document discusses these requirements in more
depth, illustrates the used packet formats, describes suitable
configuration procedures, and shows how implementations can process
the packets in the right order.
</p><a name="toc"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<h3>Table of Contents</h3>
<pre><font size="+1">
<b><a href="#anchor1">1.</a> Introduction</b>
<b><a href="#anchor2">2.</a> Terminology</b>
<b><a href="#wire-formats">3.</a> Packet Formats</b>
<b><a href="#anchor3">3.1</a> Binding Updates and Acknowledgements</b>
<b><a href="#anchor4">3.2</a> Return Routability Signaling</b>
<b><a href="#anchor5">3.3</a> Prefix Discovery</b>
<b><a href="#anchor6">3.4</a> Payload Packets</b>
<b><a href="#reqts">4.</a> Requirements</b>
<b><a href="#anchor7">4.1</a> Mandatory Support</b>
<b><a href="#anchor8">4.2</a> Policy Requirements</b>
<b><a href="#ipsec-proc-req">4.3</a> IPsec Protocol Processing</b>
<b><a href="#anchor9">4.4</a> Dynamic Keying</b>
<b><a href="#conf">5.</a> Example Configurations</b>
<b><a href="#conf-format">5.1</a> Format</b>
<b><a href="#conf-manual">5.2</a> Manual Configuration</b>
<b><a href="#anchor10">5.2.1</a> Binding Updates and Acknowledgements</b>
<b><a href="#anchor11">5.2.2</a> Return Routability Signaling</b>
<b><a href="#anchor12">5.2.3</a> Prefix Discovery</b>
<b><a href="#anchor13">5.2.4</a> Payload Packets</b>
<b><a href="#conf-dynamic">5.3</a> Dynamic Keying</b>
<b><a href="#anchor14">5.3.1</a> Binding Updates and Acknowledgements</b>
<b><a href="#anchor15">5.3.2</a> Return Routability Signaling</b>
<b><a href="#anchor16">5.3.3</a> Prefix Discovery</b>
<b><a href="#anchor17">5.3.4</a> Payload Packets</b>
<b><a href="#steps">6.</a> Processing Steps within a Node</b>
<b><a href="#steps-bu-to-ha">6.1</a> Binding Update to the Home Agent</b>
<b><a href="#steps-bu-from-mn">6.2</a> Binding Update from the Mobile Node</b>
<b><a href="#steps-ba-to-mn">6.3</a> Binding Acknowledgement to the Mobile Node</b>
<b><a href="#steps-ba-from-ha">6.4</a> Binding Acknowledgement from the Home Agent</b>
<b><a href="#steps-hoti-to-ha">6.5</a> Home Test Init to the Home Agent</b>
<b><a href="#steps-hoti-from-mn">6.6</a> Home Test Init from the Mobile Node</b>
<b><a href="#steps-hot-to-mn">6.7</a> Home Test to the Mobile Node</b>
<b><a href="#steps-hot-from-ha">6.8</a> Home Test from the Home Agent</b>
<b><a href="#anchor18">6.9</a> Prefix Solicitation Message to the Home Agent</b>
<b><a href="#anchor19">6.10</a> Prefix Solicitation Message from the Mobile Node</b>
<b><a href="#anchor20">6.11</a> Prefix Advertisement Message to the Mobile Node</b>
<b><a href="#anchor21">6.12</a> Prefix Advertisement Message from the Home Agent</b>
<b><a href="#anchor22">6.13</a> Payload Packet to the Home Agent</b>
<b><a href="#anchor23">6.14</a> Payload Packet from the Mobile Node</b>
<b><a href="#anchor24">6.15</a> Payload Packet to the Mobile Node</b>
<b><a href="#anchor25">6.16</a> Payload Packet from the Home Agent</b>
<b><a href="#anchor26">6.17</a> Establishing New Security Associations</b>
<b><a href="#anchor27">6.18</a> Rekeying Security Associations</b>
<b><a href="#anchor28">6.19</a> Movements and Dynamic Keying</b>
<b><a href="#anchor29">7.</a> Implementation Considerations</b>
<b><a href="#anchor30">8.</a> Security Considerations</b>
<b><a href="#rfc.references1">§</a> Normative References</b>
<b><a href="#rfc.references2">§</a> Informative References</b>
<b><a href="#rfc.authors">§</a> Authors' Addresses</b>
<b><a href="#anchor31">A.</a> Acknowledgements</b>
<b><a href="#anchor32">B.</a> Changes from Previous Version</b>
<b><a href="#rfc.copyright">§</a> Intellectual Property and Copyright Statements</b>
</font></pre></ul>
<br clear="all">
<a name="anchor1"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.1"></a><h3>1. Introduction</h3>
<p>This document illustrates the use of IPsec in securing control traffic
relating to <a href="#I-D.ietf-mobileip-ipv6" title="Perkins, C., Johnson, D. and J. Arkko, Mobility Support in IPv6, February 2003.">Mobile IPv6</a>[8]. In
Mobile IPv6, a mobile node is always expected to be addressable at its
home address, whether it is currently attached to its home link or is
away from home. The "home address" is an IP address assigned to the
mobile node within its home subnet prefix on its home link. While a
mobile node is at home, packets addressed to its home address are
routed to the mobile node's home link.
</p>
<p>While a mobile node is attached to some foreign link away from
home, it is also addressable at a care-of addresses. A care-of address
is an IP address associated with a mobile node that has the subnet
prefix of a particular foreign link. The association between a mobile
node's home address and care-of address is known as a "binding" for
the mobile node. While away from home, a mobile node registers its
primary care-of address with a router on its home link, requesting
this router to function as the "home agent" for the mobile node. The
mobile node performs this binding registration by sending a "Binding
Update" message to the home agent. The home agent replies to the
mobile node by returning a "Binding Acknowledgement" message.
</p>
<p>Any other nodes communicating with a mobile node are referred to as
"correspondent nodes". Mobile nodes can provide information about
their current location to correspondent nodes, again using Binding
Updates and Acknowledgements. Additionally, return routability test is
performed between the mobile node, home agent, and the correspondent
node in order to authorize the establishment of the binding.
Packets between the mobile node and the correspondent node are either
tunneled via the home agent, or sent directly if a binding exists in
the correspondent node for the current location of the mobile node.
</p>
<p>Mobile IPv6 tunnels payload packets between the mobile node and the
home agent in both directions. This tunneling uses <a href="#RFC2473" title="Conta, A. and S. Deering, Generic Packet Tunneling in IPv6 Specification, December 1998.">IPv6 encapsulation</a>[7]. Where these tunnels need
to be secured, they are replaced by <a href="#RFC2401" title="Kent, S. and R. Atkinson, Security Architecture for the Internet Protocol, November 1998.">IPsec
tunnels</a>[2].
</p>
<p>Mobile IPv6 also provides support for the reconfiguration of the
home network. Here the home subnet prefixes may change over
time. Mobile nodes can learn new information about home subnet
prefixes through the "prefix discovery" mechanism.
</p>
<p>This document discusses security mechanisms for the control traffic
between the mobile node and the home agent. If this traffic is not
protected, mobile nodes and correspondent nodes are vulnerable to
Man-in-the-Middle, Hijacking, Confidentiality, Impersonation, and
Denial-of-Service attacks. Any third parties are also vulnerable to
Denial-of-Service attacks. These threats are discussed in more detail
in Section 15.1 of the <a href="#I-D.ietf-mobileip-ipv6" title="Perkins, C., Johnson, D. and J. Arkko, Mobility Support in IPv6, February 2003.">Mobile
IPv6 base specification</a>[8].
</p>
<p>In order to avoid these attacks, the base specification uses <a href="#RFC2401" title="Kent, S. and R. Atkinson, Security Architecture for the Internet Protocol, November 1998.">IPsec</a>[2] to protect control traffic between the
home agent and the mobile node. This control traffic consists of
various messages carried by the Mobility Header protocol in <a href="#RFC2460" title="Deering, S. and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, December 1998.">IPv6</a>[6]. The traffic takes the following
forms:
</p>
<ul class="text">
<li>Binding Update and Acknowledgement messages exchanged between the
mobile node and the home agent, as described in Sections 10.3.1, 10.3.2, 11.7.1,
and 11.7.3 of the <a href="#I-D.ietf-mobileip-ipv6" title="Perkins, C., Johnson, D. and J. Arkko, Mobility Support in IPv6, February 2003.">base specification</a>[8].
</li>
<li>Return routability messages Home Test Init and Home Test that
pass through the home agent on their way to a correspondent node, as
described in Section 10.4.6 of the <a href="#I-D.ietf-mobileip-ipv6" title="Perkins, C., Johnson, D. and J. Arkko, Mobility Support in IPv6, February 2003.">base specification</a>[8].
</li>
<li>ICMPv6 messages exchanged between the mobile node and the home
agent for the purposes of prefix discovery, as described in Sections
10.6 and 11.4 of the <a href="#I-D.ietf-mobileip-ipv6" title="Perkins, C., Johnson, D. and J. Arkko, Mobility Support in IPv6, February 2003.">base
specification</a>[8].
</li>
</ul><p>
<p>The nodes may also optionally protect payload traffic passing
through the home agent, as described in Section 5.3 of the <a href="#I-D.ietf-mobileip-ipv6" title="Perkins, C., Johnson, D. and J. Arkko, Mobility Support in IPv6, February 2003.">base specification</a>[8]. If
multicast group membership control protocols or stateful address
autoconfiguration protocols are supported, payload data protection
support is required.
</p>
<p>The control traffic between the mobile node and the home agent
requires message authentication, integrity, correct ordering and
replay protection. The mobile node and the home agent must have a
security association to protect this traffic. Furthermore, great
care is needed when using <a href="#RFC2409" title="Harkins, D. and D. Carrel, The Internet Key Exchange (IKE), November 1998.">IKE</a>[5] to
establish security associations to Mobile IPv6 home agents. The right
kind of addresses must be used for transporting IKE.
This is necessary to avoid circular dependencies in which the use
of a Binding Update triggers the need for an IKE exchange that
cannot complete prior to the Binding Update having been completed.
</p>
<p>The mobile IPv6 base document defines the main requirements
the mobile nodes and home agents must follow when securing the
above traffic. This document discusses these requirements in more
depth, illustrates the used packet formats, describes suitable
configuration procedures, and shows how implementations can process
the packets in the right order.
</p>
<p>We begin our description by showing the required wire formats
for the protected packets in <a href="#wire-formats">Packet Formats</a>.
<a href="#reqts">Requirements</a> describes rules which associated Mobile IPv6, IPsec, and
IKE implementations must observe.
<a href="#conf">Example Configurations</a> discusses how IPsec can be configured to use either
manual or automatically established security associations. <a href="#steps">Processing Steps within a Node</a> shows
examples of how packets are processed within the nodes.
</p>
<p>All implementations of Mobile IPv6 mobile node and home agent MUST
support at least the formats described in <a href="#wire-formats">Packet Formats</a> and
obey the rules in <a href="#reqts">Requirements</a>. The configuration and
processing sections are informative, and should only be considered as
one possible way of providing the required functionality.
</p>
<a name="anchor2"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.2"></a><h3>2. Terminology</h3>
<p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="#RFC2119" title="Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997.">RFC 2119</a>[1].
</p>
<a name="wire-formats"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.3"></a><h3>3. Packet Formats</h3>
<a name="rfc.section.3.1"></a><h4><a name="anchor3">3.1</a> Binding Updates and Acknowledgements</h4>
<p>When the mobile node is away from its home, the BUs sent by it to the
home agent MUST support at least the following headers in the following
order:
</p></font><pre>
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header
Mobility header
Binding Update
Alternative Care-of Address option (care-of address)
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>Note that the Alternative Care-of Address option is used to ensure that
the care-of address is protected by ESP. The home agent considers the
address within this option as the current care-of address for the mobile
node.
</p>
<p>The Binding Acknowledgements sent back to the mobile node when it is away
from home MUST
have at least the following headers in the following order:
</p></font><pre>
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header
Mobility header
Binding Acknowledgement
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>When the mobile node is at home, the above rules are different as the
mobile node can use its home address as a source address. This typically
happens for the de-registration Binding Update when the mobile is returning
home. In this situation,
the Binding Updates MUST support at least the following headers in the following
order:
</p></font><pre>
IPv6 header (source = home address,
destination = home agent)
ESP header
Mobility header
Binding Update
Alternative Care-of Address option (care-of address)
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>The Binding Acknowledgement messages sent to the home address MUST support
at least the following headers in the following order:
</p></font><pre>
IPv6 header (source = home agent,
destination = home address)
ESP header
Mobility header
Binding Acknowledgement
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<a name="rfc.section.3.2"></a><h4><a name="anchor4">3.2</a> Return Routability Signaling</h4>
<p>When the Home Test Init messages tunneled to the home agent are protected
by IPsec, they MUST support at least the following headers in the following
order:
</p></font><pre>
IPv6 header (source = care-of address,
destination = home agent)
ESP header
IPv6 header (source = home address,
destination = correspondent node)
Mobility Header
Home Test Init
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>This format assumes that the mobile node's current care-of address
is used as one of the gateway addresses in the security
association. As discussed in <a href="#ipsec-proc-req">IPsec Protocol Processing</a>, this
requires the home agent to update the gateway address when the mobile
node moves. Policy entries and security association selectors stay the
same, however, as the inner packets do not change upon movements.
</p>
<p>Similarly, when the Home Test messages tunneled from the home agent are protected
by IPsec, they MUST support at least the following headers in the following
order:
</p></font><pre>
IPv6 header (source = home agent,
destination = care-of address)
ESP header
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>The format used to protect return routability packets relies on the
destination of the tunnel packets to change for the mobile node as it
moves. The home agent's address stays the same, but the mobile node's
address changes upon movements, as if the security association's
tunnel gateway address had changed. When the mobile node adopts a new
care-of address, its source address selection rules will automatically
adopt a new source address for outgoing tunnel packets. (The home agent
accepts packets sent like this, as the outer source address in tunnel
packets is not checked.)
</p>
<p>The process is more complicated in the home agent side, as the home
agent has stored the previous care-of address in its Security
Association Database as the gateway address. When IKE is being used,
the mobile node runs it on top of its then current care-of address,
and the resulting tunnel-mode security associations will use the same
addresses as IKE was transported on. In order for the home agent to
be able to tunnel a Home Test message to the mobile node, it uses the
current care-of address as the destination of the tunnel packets, as
if the home agent had modified the gateway address of the security
association used for this protection. This implies that the same
security association can be used in multiple locations, and no new
configuration or IKE rekeying is needed per movement.
</p>
<a name="rfc.section.3.3"></a><h4><a name="anchor5">3.3</a> Prefix Discovery</h4>
<p>If IPsec is used to protect prefix discovery, requests for prefixes from the mobile node to the home agent
MUST support at least the following headers in the following
order.
</p></font><pre>
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header
ICMPv6
Mobile Prefix Solicitation
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>Again if IPsec is used, solicited and unsolicited prefix information advertisements from the home
agent to the mobile node MUST support at least the following headers in the
following order.
</p></font><pre>
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header
ICMPv6
Mobile Prefix Advertisement
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<a name="rfc.section.3.4"></a><h4><a name="anchor6">3.4</a> Payload Packets</h4>
<p>If IPsec is used to protect payload packets tunneled to the home agent
from the mobile node, a similar format is used as in the case of tunneled
Home Test Init messages. However, instead of the Mobility Header
these packets may contain any legal IPv6 protocol(s):
</p></font><pre>
IPv6 header (source = care-of address,
destination = home agent)
ESP header
IPv6 header (source = home address,
destination = correspondent node)
Any protocol
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>Similarly, when the payload packets are tunneled from the home agent to
the mobile node with IPsec protection, they MUST support at least the following headers in the following
order:
</p></font><pre>
IPv6 header (source = home agent,
destination = care-of address)
ESP header
IPv6 header (source = correspondent node,
destination = home address)
Any protocol
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<a name="reqts"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.4"></a><h3>4. Requirements</h3>
<p>This section describes mandatory rules for all Mobile IPv6 mobile nodes
and home agents. These rules are necessary in order for it to be possible
to enable IPsec communications despite movements, guarantee sufficient
security, and to ensure correct
processing order of packets.
</p>
<p>The rules in the following sections apply only to the
communications between home agents and mobile nodes. They should not be
taken as requirements on how IPsec in general is used by mobile
nodes.
</p>
<a name="rfc.section.4.1"></a><h4><a name="anchor7">4.1</a> Mandatory Support</h4>
<p>The following requirements apply to both home agents and
mobile nodes:
</p>
<ul class="text">
<li>Manual configuration of security associations MUST be supported.
The configuration of the keys is expected to take place out-of-band,
for instance at the time the mobile node is configured to use its
home agent.
</li>
<li>Automatic key management with <a href="#RFC2409" title="Harkins, D. and D. Carrel, The Internet Key Exchange (IKE), November 1998.">IKE</a>[5] MAY be
supported. Only IKEv1 is discussed in this document, even if it is
expected that the next version of IKE can also be used and that it
offers several improvements in this specific application.
</li>
<li>IPsec protection for Binding Updates and Acknowledgements between
the mobile node and home agent MUST be supported and MUST be used.
</li>
<li>IPsec protection for the Home Test Init and Home Test messages
tunneled between the mobile node and home agent MUST be supported and
SHOULD be used.
</li>
<li>IPsec protection for the ICMPv6 messages related to prefix discovery
MUST be supported and SHOULD be used.
</li>
<li>IPsec protection of the payload packets tunneled between the mobile
node and home agent MAY be supported and used.
</li>
<li>If multicast group membership control protocols or stateful address
autoconfiguration protocols are supported, payload data protection MUST be
supported for those protocols.
</li>
</ul><p>
<a name="rfc.section.4.2"></a><h4><a name="anchor8">4.2</a> Policy Requirements</h4>
<p>The following requirements apply to both home agents and
mobile nodes:
</p>
<ul class="text">
<li>When a packet is matched against IPsec security policy or
selectors of a security association, an
address appearing in a Home Address destination option MUST
be considered as the source address of the packet.
</li>
<li>Similarly, a home address within a Type 2 Routing header
MUST be considered as the destination address of the packet,
when a packet is matched against IPsec security policy or
selectors of a security association.
</li>
<li>When IPsec is used to protect return routability signaling
or payload packets, the security policy database entries
SHOULD be defined specifically for the tunnel interface between
the mobile node and the home agent. That is, the policy
entries are not generally applied on all traffic on the physical
interface(s) of the nodes, but rather only on traffic that
enters this tunnel.
</li>
<li>The authentication of mobile nodes MAY be based either on machine
or user credentials. Note that multi-user operating systems typically
allow all users of a node to use any of the IP addresses assigned to
the node. This limits the capability of the home agent to restrict the
use of a home address to a particular user in such environment. Where
user credentials are applied in a multi-user environment, the
configuration should authorize all users of the node to control all
home addresses assigned to the node.
</li>
<li>When the mobile node returns home and de-registers with the Home
Agent, the tunnel between the home agent and the mobile node's care-of
address is torn down. The SPD entries, which were used for protecting
tunneled traffic between the mobile node and the home agent become
inactive. The corresponding security associations could be stored or
deleted depending on how they were created. If the security
associations were created dynamically using IKE, they are
automatically deleted when they expire. If the security associations
were created through manual configuration, they MUST be retained and
used later when the mobile node moves aways from home again. The
security associations protecting Binding Updates and Acknowledgements,
and prefix discovery SHOULD not be deleted as they do not depend on
care-of addresses and can be used again.
</li>
</ul><p>
<p>The following rules apply to mobile nodes:
</p>
<ul class="text">
<li>The mobile node MUST use the Home Address destination option
in Binding Updates and Mobile Prefix Solicitations, sent to the home
agent from a care-of address.
</li>
<li>When the mobile node receives a changed set of prefixes from the home
agent during prefix discovery, there is a need to configure new
security policy entries, and there may be a need to configure new
security associations. It is outside the scope of this specification
to discuss automatic methods for this.
</li>
</ul><p>
<p>The following rules apply to home agents:
</p>
<ul class="text">
<li>The home agent MUST use the Type 2 Routing header in Binding Acknowledgements
and Mobile Prefix Advertisements sent to the mobile node, again due to
the need to have the home address visible when the policy checks are
made.
</li>
<li>It is necessary to avoid the possibility that a mobile node could
use its security association to send a Binding Update on behalf of
another mobile node using the same home agent. In order to do this,
the security policy database entries MUST unequivocally identify a
single security association for any given home address and home agent
when manual keying is used. When dynamic keying is used, the security
policy database entries MUST unequivocally identify the IKE phase 1
credentials which can be used to authorize the creation of security associations for a
particular home address. How these mappings are maintained is outside
the scope of this specification, but they may be maintained, for
instance, as a locally administered table in the home agent. If the
phase 1 identity is a FQDN, secure forms of DNS may also be used.
</li>
<li>When the set of prefixes advertised by the home agent changes,
there is a need to configure new security policy entries, and there
may be a need to configure new security associations. It is outside
the scope of this specification to discuss automatic methods for
this, if new home addresses are required.
</li>
</ul><p>
<a name="rfc.section.4.3"></a><h4><a name="ipsec-proc-req">4.3</a> IPsec Protocol Processing</h4>
<p>The following requirements apply to both home agents and
mobile nodes:
</p>
<ul class="text">
<li>When securing Binding Updates, Binding Acknowledgements,
and prefix discovery, both the mobile nodes and the home
agents SHOULD use the <a href="#RFC2406" title="Kent, S. and R. Atkinson, IP Encapsulating Security Payload (ESP), November 1998.">Encapsulating Security Payload (ESP)</a>[4] header in
transport mode and MUST use a non-null payload authentication algorithm to
provide data origin authentication, connectionless integrity and
optional anti-replay protection. Note that <a href="#RFC2402" title="Kent, S. and R. Atkinson, IP Authentication Header, November 1998.">Authentication Header (AH)</a>[3]
is also possible but for brevity is not discussed in this specification.
<br>
<br>
Mandatory support for encryption and integrity protection algorithms
is as defined in <a href="#RFC2401" title="Kent, S. and R. Atkinson, Security Architecture for the Internet Protocol, November 1998.">RFC 2401</a>[2], <a href="#RFC2402" title="Kent, S. and R. Atkinson, IP Authentication Header, November 1998.">RFC
2402</a>[3], and <a href="#RFC2406" title="Kent, S. and R. Atkinson, IP Encapsulating Security Payload (ESP), November 1998.">RFC 2406</a>[4].
Care is needed when selecting suitable
encryption algorithms for ESP, however. Currently available
integrity protection algorithms are in general considered to be
secure. The encryption algorithm, DES, mandated by the current IPsec
standards is not, however. This is particularly problematic when
security associations are configured manually, as the same key is used
for a long time.
</li>
<li>Tunnel mode IPsec ESP MUST be supported and SHOULD be used for
the protection of packets belonging to the return routability procedure.
A non-null encryption transform and authentication
algorithm MUST be applied.
</li>
<li>IPsec <a href="#RFC2402" title="Kent, S. and R. Atkinson, IP Authentication Header, November 1998.">AH</a>[3] authenticator calculation
MUST be performed as if a packet with a Type 2 Routing header would
have the home address in the IPv6 destination address field and the
care-of address in the Routing header. Type 2 Routing header should be
treated by IPsec in the same manner as Type 0 Routing header.
</li>
<li>Similarly, the authenticator calculation MUST be performed as if
a packet with a Home Address destination option would have the
home address in the IPv6 source address field and the care-of address
in the destination option.
</li>
</ul><p>
<p>The following rules apply to mobile nodes:
</p>
<ul class="text">
<li>When ESP is used to protect Binding Updates, there is no protection
for the care-of address which appears in the IPv6 header outside the
area protected by ESP. It is important for the home agent to verify
that the care-of address has not been tampered. As a result, the
attacker would have redirected the mobile node's traffic to another
address. In order to prevent this, Mobile IPv6 implementations MUST
use the Alternate Care-of Address mobility option in all Binding
Updates sent to the home agent. (Note that AH
protects also the IPv6 header, and some implementations might avoid
the option if they know AH is being used.)
</li>
<li>When IPsec is used to protect return routability signaling or
payload packets, the mobile node MUST set the source address it uses
for the outgoing tunnel packets to the current primary care-of
address. The mobile node starts to use a new primary care-of address
immediately after sending a Binding Update to the home agent to
register this new address.
</li>
</ul><p>
<p>The following rules apply to home agents:
</p>
<ul class="text">
<li>When IPsec is used to protect return routability signaling or
payload packets, IPsec security associations are needed to provide
this protection. When the care-of address for the mobile node changes as
a result of an accepted Binding Update,
special treatment is needed for the next packets sent using these
security associations. The home agent MUST set the new care-of
address as the destination address of these packets, as if the
destination gateway address in the security association had changed.
</li>
</ul><p>
<a name="rfc.section.4.4"></a><h4><a name="anchor9">4.4</a> Dynamic Keying</h4>
<p>The following requirements apply to both home agents and
mobile nodes:
</p>
<ul class="text">
<li>If replay protection is required, dynamic keying MUST be used.
IPsec can provide replay protection only if dynamic keying is used.
This may not always be possible, and manual keying would be preferred
in some cases. IPsec also does not guarantee correct ordering of
packets, only that they have not been replayed. Because of this,
sequence numbers within the Mobile IPv6 messages ensure correct
ordering. However, if a home agent reboots and loses its state
regarding the sequence numbers, replay attacks become possible. The
use of a key management mechanism together with IPsec can be used to
prevent such replay attacks.
</li>
<li>If IKE version 1 is used with preshared secrets in main mode, it
determines the shared secret to use from the IP address of the
peer. With Mobile IPv6, however, this may be a care-of address and
does not indicate which mobile node attempts to contact the home
agent. Therefore, if preshared secret authentication is used in IKEv1
between the mobile node and the home agent then aggressive mode MUST
be used. Note also that care needs to be taken with phase 1 identity
selection. Where the ID_IPV6_ADDR Identity Payloads is used,
unambiguous mapping of identities to keys is not possible.
(The next version of IKE may not have these limitations.)
</li>
</ul><p>
<p>The following rules apply to mobile nodes:
</p>
<ul class="text">
<li>Where dynamic keying is used, the key management protocol MUST
use the care-of address as the source address in the protocol
exchanges with the mobile node's home agent.
</li>
<li>Conversely, the IPsec security associations with the mobile node's
home agent MUST be requested from the key management protocol with the
home address as the mobile node's address.
<br>
<br>
The security associations for protecting Binding Updates and
Acknowledgements are requested for the Mobility header protocol in
transport mode and for specific IP addresses as endpoints. Similarly,
the security associations for protecting prefix discovery are
requested for the ICMPv6 protocol. Payload and return routability
protection requests security associations for a specific tunnel
interface and either the payload protocol or the Mobility header
protocol, in tunnel mode. In this case one requested endpoint
is an IP address and another one is a wildcard.
</li>
<li>If the mobile node has used IKE to establish security associations
with its home agent, it should follow the procedures discussed in
Section 11.7.1 and 11.7.3 of the base specification to determine
whether the IKE endpoints can be moved or if rekeying is needed.
</li>
</ul><p>
<p>The following rules apply to home agents:
</p>
<ul class="text">
<li>If the home agent has used IKE to establish security associations
with the mobile node, it should follow the procedures discussed in
Section 10.3.1 and 10.3.2 of the base specification to determine
whether the IKE endpoints can be moved or if rekeying is needed.
</li>
</ul><p>
<a name="conf"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.5"></a><h3>5. Example Configurations</h3>
<p>In the following we describe the Security Policy Database (SPD) and Security Association
Database (SAD) entries necessary to
protect Binding Updates and Binding Acknowledgements exchanged between the mobile node and the home
agent. Our examples assume the use of ESP, but a similar configuration could also be used to
protect the messages with AH.
</p>
<p><a href="#conf-format">Format</a> introduces the format we use in the description of the SPD and the SAD.
<a href="#conf-manual">Manual Configuration</a> describes how to configure manually keyed security associations, and
<a href="#conf-dynamic">Dynamic Keying</a> describes how to use dynamic keying.
</p>
<a name="rfc.section.5.1"></a><h4><a name="conf-format">5.1</a> Format</h4>
<p>The format used in the examples is as follows. The SPD description has the format
</p>
</font><pre>
<node> "SPD OUT:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
<node> "SPD IN:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Where <node> represents the name of the node, and <spdentry> has the following format:
</p>
</font><pre>
"IF" <condition> "THEN USE" <sa> |
"IF" <condition> "THEN CREATE" <pattern> |
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Where <condition> is an boolean expression about the fields of the IPv6 packet,
<sa> is the name of a security association, and <pattern> is a specification for a
security association to be negotiated
via <a href="#RFC2409" title="Harkins, D. and D. Carrel, The Internet Key Exchange (IKE), November 1998.">IKE</a>[5]. The SAD description has the format
</p>
</font><pre>
<node> "SAD:"
"-" <sadentry>
"-" <sadentry>
...
"-" <sadentry>
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Where <node> represents the name of the node, and <sadentry> has the following format:
</p>
</font><pre>
<sa> "(" <dir> ","
<spi> ","
<destination> ","
<ahesp> ","
<mode> ")" ":"
<selectors>
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Where <dir> is "IN" or "OUT", <spi> is the SPI of the security association,
<destination> is its destination, <ahesp> is normally
"ESP" in our case but could also be "AH", <mode> is either "TUNNEL" or "TRANSPORT", and <selectors> is a
boolean expression about the fields of the IPv6 packet.
</p>
<p>We will be using an example mobile node in this section with the home
address "home_address_1". The user's identity in this mobile node is
"user_1". The home agent's address is "home_agent_1".
</p>
<a name="rfc.section.5.2"></a><h4><a name="conf-manual">5.2</a> Manual Configuration</h4>
<a name="rfc.section.5.2.1"></a><h4><a name="anchor10">5.2.1</a> Binding Updates and Acknowledgements</h4>
<p>Here are the contents of the SPD
and SAD for protecting Binding Updates and Acknowledgements:
</p>
</font><pre>
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA2
mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA2
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA1
home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>In the above, "MH" refers to the protocol number for the <a href="#I-D.ietf-mobileip-ipv6" title="Perkins, C., Johnson, D. and J. Arkko, Mobility Support in IPv6, February 2003.">Mobility Header</a>[8].
</p>
<a name="rfc.section.5.2.2"></a><h4><a name="anchor11">5.2.2</a> Return Routability Signaling</h4>
<p>In the following we describe the necessary SPD and SAD entries to
protect return routability signaling between the mobile node and the home agent.
Note that the rules in the SPD are ordered, and the ones in the previous
section
must take precedence over these ones:
</p>
</font><pre>
mobile node SPD OUT:
- IF interface = tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA3
mobile node SPD IN:
- IF interface = tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA4
mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH
- SA4(IN, spi_d, home_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
home agent SPD OUT:
- IF interface = tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA4
home agent SPD IN:
- IF interface = tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA3
home agent SAD:
- SA4(OUT, spi_d, home_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<a name="rfc.section.5.2.3"></a><h4><a name="anchor12">5.2.3</a> Prefix Discovery</h4>
<p>In the following we describe some additional SPD and SAD entries to
protect prefix discovery.
</p>
</font><pre>
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA5.
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA6
mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA6
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA5
home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Note that the SPDs described above protect all ICMPv6 traffic between
the mobile node and the home agent.
</p>
<a name="rfc.section.5.2.4"></a><h4><a name="anchor13">5.2.4</a> Payload Packets</h4>
<p>It is also possible to perform some additional, optional, protection
of tunneled payload packets. This protection takes place in a
similar manner to the return routability protection above, but requires a
different value for the protocol field. The necessary SPD and SAD entries
are shown below. It is assumed that the entries for protecting Binding
Updates and Acknowledgements, and the entries to protect Home Test Init
and Home Test messages take precedence over these entries.
</p>
</font><pre>
mobile node SPD OUT:
- IF interface = tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA7
mobile node SPD IN:
- IF interface = tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA8
mobile node SAD:
- SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X
- SA8(IN, spi_h, home_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
home agent SPD OUT:
- IF interface = tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA8
home agent SPD IN:
- IF interface = tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA7
home agent SAD:
- SA8(OUT, spi_h, home_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
- SA7(IN, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>If multicast group membership control protocols such as <a href="#RFC2710" title="Deering, S., Fenner, W. and B. Haberman, Multicast Listener Discovery (MLD) for IPv6, October 1999.">MLDv1</a>[9] or <a href="#I-D.vida-mld-v2" title="Vida, R. and L. Costa, Multicast Listener Discovery Version 2 (MLDv2) for IPv6, December 2002.">MLDv2</a>[12] need to be protected, these
packets may use a link-local address rather than the home address of
the mobile node. In this case the source and destination can be left
as a wildcard and the SPD entries will work solely based on the used
interface and the protocol, which is ICMPv6 for both MLDv1 and
MLDv2.
</p>
<p>Similar problems are encountered when stateful address autoconfiguration
protocols such as <a href="#I-D.ietf-dhc-dhcpv6" title="Droms, R., Dynamic Host Configuration Protocol for IPv6 (DHCPv6), November 2002.">DHCPv6</a>[10]
are used. The same approach is applicable for DHCPv6 as well. DHCPv6
uses the UDP protocol.
</p>
<p>Support for multiple layers of encapsulation (such as ESP
encapsulated in ESP) is not required by <a href="#RFC2401" title="Kent, S. and R. Atkinson, Security Architecture for the Internet Protocol, November 1998.">RFC
2401</a>[2] and is also otherwise often problematic. It is therefore
useful to avoid setting the protocol X in the above entries to either
AH or ESP.
</p>
<a name="rfc.section.5.3"></a><h4><a name="conf-dynamic">5.3</a> Dynamic Keying</h4>
<p>In this section we show an example configuration that uses
IKE to negotiate security associations.
</p>
<a name="rfc.section.5.3.1"></a><h4><a name="anchor14">5.3.1</a> Binding Updates and Acknowledgements</h4>
<p>Here are the contents of the SPD for protecting Binding
Updates and Acknowledgements:
</p>
</font><pre>
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>We have omitted details of the proposed transforms in the above, and
all details related to the particular authentication method such
as certificates beyond listing a specific identity that must be
used.
</p>
<p>We require IKE to be run using the care-of addresses but still
negotiate IPsec SAs that use home addresses. The extra
conditions set by the home agent SPD for the peer phase 1
identity to be "user_1" must be verified by the home agent.
The purpose of the condition is to ensure that the IKE phase 2
negotiation for a given user's home address can't be requested by
another user. In the mobile node, we simply set our local identity
to be "user_1".
</p>
<p>These checks also imply that the configuration of the home agent is
user-specific: every user or home address requires a specific configuration
entry. It would be possible to alleviate the configuration tasks by
using certificates that have home addresses in the Subject AltName field.
However, it isn't clear if all IKE implementations allow one address to be
used for carrying the IKE negotiations when another address is mentioned
in the used certificates. In any case, even this approach would have required
user-specific tasks in the certificate authority.
</p>
<a name="rfc.section.5.3.2"></a><h4><a name="anchor15">5.3.2</a> Return Routability Signaling</h4>
<p>Protection for the return routability signaling can be configured
in a similar manner as above.
</p>
</font><pre>
mobile node SPD OUT:
- IF interface = tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD IN:
- IF interface = tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
local phase 1 identity = user_1
home agent SPD OUT:
- IF interface = tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home_address_1 &
peer phase 1 identity = user_1
home agent SPD IN:
- IF interface = tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home_address_1 &
peer phase 1 identity = user_1
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Here we specified the gateway address for the security
association as the home address for the mobile node. However,
as required by <a href="#ipsec-proc-req">IPsec Protocol Processing</a> the packets will
actually be sent to the current care-of address. In order to
avoid writing dynamically changing information to the SPD
entries, the above has been written with the home address
as the gateway.
</p>
<a name="rfc.section.5.3.3"></a><h4><a name="anchor16">5.3.3</a> Prefix Discovery</h4>
<p>In the following we describe some additional SPD entries to
protect prefix discovery with IKE. (Note that when actual new prefixes are
discovered, there may be a need to enter new manually configured SPD
entries to specify the authorization policy for the resulting new home addresses.)
</p>
</font><pre>
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<a name="rfc.section.5.3.4"></a><h4><a name="anchor17">5.3.4</a> Payload Packets</h4>
<p>Protection for the payload packets happens similarly to the protection
of return routability signaling. As in the manually keyed case, these
SPD entries have lower priority than the above ones.
</p>
</font><pre>
mobile node SPD OUT:
- IF interface = tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = X
THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD IN:
- IF interface = tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = X
THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
local phase 1 identity = user_1
home agent SPD OUT:
- IF interface = tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = X
THEN CREATE ESP TUNNEL SA: gateway = home_address_1 &
peer phase 1 identity = user_1
home agent SPD IN:
- IF interface = tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = X
THEN CREATE ESP TUNNEL SA: gateway = home_address_1 &
peer phase 1 identity = user_1
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<a name="steps"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.6"></a><h3>6. Processing Steps within a Node</h3>
<a name="rfc.section.6.1"></a><h4><a name="steps-bu-to-ha">6.1</a> Binding Update to the Home Agent</h4>
<p>Step 1. At the mobile node, Mobile IPv6 module first produces the following packet:
</p>
</font><pre>
IPv6 header (source = home address,
destination = home agent)
Mobility header
Binding Update
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 2. This packet is matched against the IPsec policy data base on the mobile node and we
make a note that IPsec must be applied.
</p>
<p>Step 3. Then, we add the necessary Mobile IPv6 options but do not change
the addresses yet, as described in Section 11.2.2 of
the <a href="#I-D.ietf-mobileip-ipv6" title="Perkins, C., Johnson, D. and J. Arkko, Mobility Support in IPv6, February 2003.">base specification</a>[8]. This results in:
</p>
</font><pre>
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (care-of address)
Mobility header
Binding Update
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 4. Finally, IPsec headers are added and the necessary authenticator
values are calculated:
</p>
</font><pre>
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (care-of address)
ESP header (SPI = spi_a)
Mobility header
Binding Update
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 5. Before sending the packet, the addresses in the IPv6 header
and the Destination Options header are changed:
</p>
</font><pre>
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header (SPI = spi_a)
Mobility header
Binding Update
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<a name="rfc.section.6.2"></a><h4><a name="steps-bu-from-mn">6.2</a> Binding Update from the Mobile Node</h4>
<p>Step 1. The following packet is received at the home agent:
</p>
</font><pre>
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header (SPI = spi_a)
Mobility header
Binding Update
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 2. The home address option is processed first, which results in
</p>
</font><pre>
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (care-of address)
ESP header (SPI = spi_a)
Mobility header
Binding Update
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 3. ESP header is processed next, resulting in
</p>
</font><pre>
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (care-of address)
Mobility header
Binding Update
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 4. This packet matches the security association selectors (source = home address, destination = home agent, proto = MH).
</p>
<p>Step 5. Mobile IPv6 processes the Binding Update.
The Binding Update is delivered to the Mobile IPv6 module.
</p>
<a name="rfc.section.6.3"></a><h4><a name="steps-ba-to-mn">6.3</a> Binding Acknowledgement to the Mobile Node</h4>
<p>Step 1. Mobile IPv6 produces the following packet:
</p>
</font><pre>
IPv6 header (source = home agent,
destination = home address)
Mobility header
Binding Acknowledgement
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 2. This packet matches the IPsec policy entries, and we remember that
IPsec has to be applied.
</p>
<p>Step 3. Then, we add the necessary Route Headers but do not
change the addresses yet, as described in Section 9.6 of the
<a href="#I-D.ietf-mobileip-ipv6" title="Perkins, C., Johnson, D. and J. Arkko, Mobility Support in IPv6, February 2003.">base specification</a>[8]. This
results in:
</p>
</font><pre>
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
care-of address
Mobility header
Binding Acknowledgement
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 4. We apply IPsec:
</p>
</font><pre>
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
care-of address
ESP header (SPI = spi_b)
Mobility header
Binding Acknowledgement
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 5. Finally, before sending the packet out we change the addresses
in the IPv6 header and the Route header:
</p>
</font><pre>
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header (SPI = spi_b)
Mobility header
Binding Acknowledgement
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<a name="rfc.section.6.4"></a><h4><a name="steps-ba-from-ha">6.4</a> Binding Acknowledgement from the Home Agent</h4>
<p>Step 1. The following packet is received at the mobile node
</p>
</font><pre>
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header (SPI = spi_b)
Mobility header
Binding Acknowledgement
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 2. After the routing header is processed the packet becomes
</p>
</font><pre>
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
care-of address
ESP header (SPI = spi_b)
Mobility header
Binding Acknowledgement
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 3. ESP header is processed next, resulting in:
</p>
</font><pre>
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
care-of address
Mobility header
Binding Acknowledgement
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 4. This packet matches the security association selectors (source = home agent, destination = home address, proto = MH).
</p>
<p>Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6 module.
</p>
<a name="rfc.section.6.5"></a><h4><a name="steps-hoti-to-ha">6.5</a> Home Test Init to the Home Agent</h4>
<p>Step 1. The mobile node constructs a Home Test Init message:
</p>
</font><pre>
IPv6 header (source = home address,
destination = correspondent node)
Mobility header
Home Test Init
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 2. Mobile IPv6 determines that this packet should go to the tunnel
to the home agent.
</p>
<p>Step 3. The packet is matched against IPsec policy entries for the interface,
and we find that IPsec needs to be applied.
</p>
<p>Step 4. IPsec tunnel mode headers are added. Note that we use a care-of
address as a source address for the tunnel packet.
</p>
</font><pre>
IPv6 header (source = care-of address,
destination = home agent)
ESP header (SPI = spi_c)
IPv6 header (source = home address,
destination = correspondent node)
Mobility header
Home Test Init
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 5. The packet no longer satisfies the criteria that made it
enter the tunnel, and it is sent directly to the home agent.
</p>
<a name="rfc.section.6.6"></a><h4><a name="steps-hoti-from-mn">6.6</a> Home Test Init from the Mobile Node</h4>
<p>Step 1. The home agent receives the following packet:
</p>
</font><pre>
IPv6 header (source = care-of address,
destination = home agent)
ESP header (SPI = spi_c)
IPv6 header (source = home address,
destination = correspondent node)
Mobility Header
Home Test Init
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 2. IPsec processing is performed, resulting in:
</p>
</font><pre>
IPv6 header (source = home address,
destination = correspondent node)
Mobility Header
Home Test Init
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 3. The resulting packet matches the selectors and the packet can be processed further.
</p>
<p>Step 4. The packet is then forwarded to the correspondent node.
</p>
<a name="rfc.section.6.7"></a><h4><a name="steps-hot-to-mn">6.7</a> Home Test to the Mobile Node</h4>
<p>Step 1. The home agent receives a Home Test packet from the correspondent node:
</p>
</font><pre>
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test Init
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 2. The home agent determines that this packet is destined to a
mobile node that is away from home, and decides to tunnel it.
</p>
<p>Step 3. The packet matches the IPsec policy entries for the tunnel interface, and
we note that IPsec needs to be applied.
</p>
<p>Step 4. IPsec is applied, resulting in a new packet. Note that the home agent
must keep track of the location of the mobile node, and update the tunnel
gateway address in the security association(s) accordingly.
</p>
</font><pre>
IPv6 header (source = home agent,
destination = care-of address)
ESP header (SPI = spi_d)
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test Init
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 5. The packet no longer satisfies the criteria that made it
enter the tunnel, and it is sent directly to the care-of address.
</p>
<a name="rfc.section.6.8"></a><h4><a name="steps-hot-from-ha">6.8</a> Home Test from the Home Agent</h4>
<p>Step 1. The mobile node receives the following packet:
</p>
</font><pre>
IPv6 header (source = home agent,
destination = care-of address)
ESP header (SPI = spi_d)
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test Init
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 2. IPsec is processed, resulting in:
</p>
</font><pre>
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test Init
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 3. This matches the security association selectors (source = any, destination = home address).
</p>
<p>Step 4. The packet is given to Mobile IPv6 processing.
</p>
<a name="rfc.section.6.9"></a><h4><a name="anchor18">6.9</a> Prefix Solicitation Message to the Home Agent</h4>
<p>This procedure is similar to the one presented in <a href="#steps-bu-to-ha">Binding Update to the Home Agent</a>.
</p>
<a name="rfc.section.6.10"></a><h4><a name="anchor19">6.10</a> Prefix Solicitation Message from the Mobile Node</h4>
<p>This procedure is similar to the one presented in <a href="#steps-bu-from-mn">Binding Update from the Mobile Node</a>.
</p>
<a name="rfc.section.6.11"></a><h4><a name="anchor20">6.11</a> Prefix Advertisement Message to the Mobile Node</h4>
<p>This procedure is similar to the one presented in <a href="#steps-ba-to-mn">Binding Acknowledgement to the Mobile Node</a>.
</p>
<a name="rfc.section.6.12"></a><h4><a name="anchor21">6.12</a> Prefix Advertisement Message from the Home Agent</h4>
<p>This procedure is similar to the one presented in <a href="#steps-ba-from-ha">Binding Acknowledgement from the Home Agent</a>.
</p>
<a name="rfc.section.6.13"></a><h4><a name="anchor22">6.13</a> Payload Packet to the Home Agent</h4>
<p>This procedure is similar to the one presented in <a href="#steps-hoti-to-ha">Home Test Init to the Home Agent</a>.
</p>
<a name="rfc.section.6.14"></a><h4><a name="anchor23">6.14</a> Payload Packet from the Mobile Node</h4>
<p>This procedure is similar to the one presented in <a href="#steps-hoti-from-mn">Home Test Init from the Mobile Node</a>.
</p>
<a name="rfc.section.6.15"></a><h4><a name="anchor24">6.15</a> Payload Packet to the Mobile Node</h4>
<p>This procedure is similar to the one presented in <a href="#steps-hot-to-mn">Home Test to the Mobile Node</a>.
</p>
<a name="rfc.section.6.16"></a><h4><a name="anchor25">6.16</a> Payload Packet from the Home Agent</h4>
<p>This procedure is similar to the one presented in <a href="#steps-hot-from-ha">Home Test from the Home Agent</a>.
</p>
<a name="rfc.section.6.17"></a><h4><a name="anchor26">6.17</a> Establishing New Security Associations</h4>
<p>Step 1. The mobile node wishes to send a Binding Update
to the home agent.
</p>
</font><pre>
IPv6 header (source = home address,
destination = home agent)
Mobility header
Binding Update
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 2. There is no existing security association to protect
the Binding Update, so IKE is initiated. The IKE packets
are sent as shown in the following examples. The first packet
is an example of an IKE packet sent from the mobile node, and
the second one is from the home agent. The examples shows also that the phase 1 identity
used for the mobile node is a FQDN.
</p>
</font><pre>
IPv6 header (source = care-of address,
destination = home agent)
UDP
IKE
... IDii = ID_FQDN mn123.ha.net ...
IPv6 header (source = home agent
destination = care-of address)
UDP
IKE
... IDir = ID_FQDN ha.net ...
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 3. IKE phase 1 completes, and phase 2 is initiated to
request security associations for protecting traffic between the mobile node's
home address and the home agent. This involves sending and
receiving additional IKE packets. The below example shows
again one packet sent by the mobile node and another sent
by the home agent. The example shows also that the phase 2
identity used for the mobile node is the mobile node's home
address.
</p>
</font><pre>
IPv6 header (source = care-of address,
destination = home agent)
UDP
IKE
... IDci = ID_IPV6_ADDR home address ...
IPv6 header (source = home agent,
destination = care-of address)
UDP
IKE
... IDcr = ID_IPV6_ADDR home agent ...
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>Step 4. The remaining steps are as shown in <a href="#steps-bu-to-ha">Binding Update to the Home Agent</a>.
</p>
<a name="rfc.section.6.18"></a><h4><a name="anchor27">6.18</a> Rekeying Security Associations</h4>
<p>Step 1. The mobile node and the home agent have existing
security associations. Either side may decide at any time that
the security associations need to be rekeyed, for instance,
because the specified lifetime is approaching.
</p>
<p>Step 2. Mobility header packets sent during rekey may be protected
by the existing security associations.
</p>
<p>Step 3. When the rekeying is finished, new security
associations are established. In practice there is a time
interval during which an old, about-to-expire security association and newly
established security association will both exist. The new ones
should be used as soon as they become available.
</p>
<p>Step 4. A notification of the deletion of the old security
associations is received. After this, only the new security
associations can be used.
</p>
<p>Note that there is no requirement that the existence of the
IPsec and IKE security associations is tied to the existence
of bindings. It is not necessary to delete a security
association if a binding is removed, as a new binding may soon
be established after this.
</p>
<p>Since cryptographic acceleration hardware may only be able to
handle a limited number of active security associations,
security associations may be deleted via IKE in order
to keep the number of active cryptographic contexts to a
minimum. Such deletions should not be interpreted as a sign of
losing a contact to the peer or as a reason to remove a
binding. Rather, if additional traffic needs to be sent, it
is preferable to bring up another security association to
protect it.
</p>
<a name="rfc.section.6.19"></a><h4><a name="anchor28">6.19</a> Movements and Dynamic Keying</h4>
<p>In this section we describe the sequence of events that relate to
movement with IKE-based security associations. In the initial state,
the mobile node is not registered in any location and has no security
associations with the home agent. Depending on whether the peers
will be able to move IKE endpoints to new care-of addresses, the
actions taken in Step 9 and 10 are different.
</p>
<p>Step 1. Mobile node with the home address A moves to care-of address B.
</p>
<p>Step 2. Mobile node runs IKE from care-of address B to the home
agent, establishing a phase 1.
</p>
<p>Step 3. Protected by this phase 1, mobile node establishes a pair of
security associations for protecting Mobility Header traffic to and from the home
address A.
</p>
<p>Step 4. Mobile node sends a Binding Update and receives a Binding
Acknowledgement using the security associations created in Step 3.
</p>
<p>Step 5. Mobile node establishes a pair of security associations for
protecting return routability packets. These security associations are
in tunnel mode and their endpoint in the mobile node side is care-of
address B. For the purposes of our example, this step
uses the phase 1 connection established in Step 2. Multiple phase 1
connections are also possible.
</p>
<p>Step 6. The mobile node uses the security associations created in
Step 5 to run return routability.
</p>
<p>Step 7. The mobile node moves to a new location and adopts a
new care-of address C.
</p>
<p>Step 8. Mobile node sends a Binding Update and receives a Binding
Acknowledgement using the security associations created in Step 3. The
home agent ensures that the next packets sent using the security
associations created in Step 5 will have the new care-of address
as their destination address, as if the destination gateway address
in the security association had changed.
</p>
<p>Step 9. If the mobile node and the HA have the capability to change
the IKE endpoints, they change the address to C. If they dont have
the capability, both nodes remove their phase 1 connections created
on top of the care-of address B and establish a new IKE phase 1 on
top of the care-of address C. This capability to change the IKE
phase 1 end points is indicated through setting the <a href="#I-D.ietf-mobileip-ipv6" title="Perkins, C., Johnson, D. and J. Arkko, Mobility Support in IPv6, February 2003.">Key Management
Mobility Capability (K) flag</a>[8] in the Binding Update and Binding
Acknowledgement messages.
</p>
<p>Step 10. If a new IKE phase 1 connection was setup after movement,
the MN will not be able to receive any notifications delivered
on top of the old IKE phase 1 security association. Notifications
delivered on top of the new security association are received and
processed normally. If the mobile node and HA were able to update
the IKE endpoints, they can continue using the same IKE phase 1
connection.
</p>
<a name="anchor29"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.7"></a><h3>7. Implementation Considerations</h3>
<p>We have chosen to require an encapsulation format for return
routability and payload packet protection which can only be realized
if the destination of the IPsec packets sent from the home agent can
be changed as the mobile node moves. One of the main reasons for
choosing such a format is that it removes the overhead of twenty four
bytes when a home address option or routing header is added to the
tunneled packet. What is needed is that the home agent must act as if
the gateway address of a security association to the mobile node
would have changed. Implementations are free to choose any particular
method to make this change, such as using an API to the IPsec
implementation to change the parameters of the security association,
removing the security association and installing a new one, or
modification of the packet after it has gone through IPsec
processing. The only requirement is that after registering a new
binding at the home agent, the next IPsec packets sent on this
security association will be addressed to the new care-of address.
</p>
<p>We have also chosen to require that a dynamic key management
protocol must be able to make an authorization decision
for IPsec security association creation with different addresses than with what
the key management protocol is run. We expect this to be
done typically by configuring the allowed combinations
of phase 1 user identities and home addresses.
</p>
<p>The base Mobile IPv6 specification sets high requirements
for a so-called Bump-In-The-Stack (BITS) implementation model
of IPsec. As Mobile IPv6 specific modifications of the packets
are required after IPsec processing, the BITS implementation
has to perform also some tasks related to mobility. This
may increase the complexity of the implementation, even
if it already performs some tasks of the IP layer (such as
fragmentation).
</p>
<p>We have chosen to require policy entries that are specific
to a tunnel interface. This means that implementations have
to regard the Home Agent - Mobile Node tunnel as a separate
interface on which IPsec SPDs can be based.
</p>
<p>A further complication of the IPsec processing on a tunnel
interface is that this requires access to the BITS implementation
before the packet actually goes out.
</p>
<p>When certificate authentication is used, IKE fragmentation can be
encountered. This can occur when certificate chains are used, or
even with single certificates if they are large. Many firewalls
do not handle fragments properly, and may drop them. Routers in
the path may also discard fragments after the initial one, since
they typically will not contain full IP headers that can be
compared against an access list. Where fragmentation occurs, the
endpoints will not always be able to establish a security
association.
</p>
<p>Fortunately, typical Mobile IPv6 deployment uses short certificate
chains, as the mobile node is communicating directly with its home
network. Nevertheless, where the problem appears, one
solution is to replace the firewalls or routers with equipment that
can properly support fragments. If this cannot be done, it may help to
store the peer certificates locally, or to obtain them through other
means.
</p>
<a name="anchor30"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.8"></a><h3>8. Security Considerations</h3>
<p>The <a href="#I-D.ietf-mobileip-ipv6" title="Perkins, C., Johnson, D. and J. Arkko, Mobility Support in IPv6, February 2003.">Mobile IPv6 base specification</a>[8] requires strong security
between the mobile node and the home agent. This memo discusses
how that security can be arranged in practice, using IPsec.
</p>
<a name="rfc.references1"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<h3>Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><b><a name="RFC2119">[1]</a></b></td>
<td class="author-text"><a href="mailto:-">Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, March 1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2401">[2]</a></b></td>
<td class="author-text"><a href="mailto:kent@bbn.com">Kent, S.</a> and <a href="mailto:rja@corp.home.net">R. Atkinson</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">Security Architecture for the Internet Protocol</a>", RFC 2401, November 1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2401.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2401.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2402">[3]</a></b></td>
<td class="author-text"><a href="mailto:kent@bbn.com">Kent, S.</a> and <a href="mailto:rja@corp.home.net">R. Atkinson</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2402.txt">IP Authentication Header</a>", RFC 2402, November 1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2402.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2402.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2402.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2406">[4]</a></b></td>
<td class="author-text"><a href="mailto:kent@bbn.com">Kent, S.</a> and <a href="mailto:rja@corp.home.net">R. Atkinson</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2406.txt">IP Encapsulating Security Payload (ESP)</a>", RFC 2406, November 1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2406.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2406.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2406.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2409">[5]</a></b></td>
<td class="author-text"><a href="mailto:dharkins@cisco.com">Harkins, D.</a> and <a href="mailto:carrel@ipsec.org">D. Carrel</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2409.txt">The Internet Key Exchange (IKE)</a>", RFC 2409, November 1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2409.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2409.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2409.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2460">[6]</a></b></td>
<td class="author-text"><a href="mailto:deering@cisco.com">Deering, S.</a> and <a href="mailto:hinden@iprg.nokia.com">R. Hinden</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2460.txt">Internet Protocol, Version 6 (IPv6) Specification</a>", RFC 2460, December 1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2460.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2460.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2460.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2473">[7]</a></b></td>
<td class="author-text"><a href="mailto:aconta@lucent.com">Conta, A.</a> and <a href="mailto:deering@cisco.com">S. Deering</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2473.txt">Generic Packet Tunneling in IPv6 Specification</a>", RFC 2473, December 1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2473.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2473.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2473.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><b><a name="I-D.ietf-mobileip-ipv6">[8]</a></b></td>
<td class="author-text">Perkins, C., Johnson, D. and J. Arkko, "<a href="http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-21.txt">Mobility Support in IPv6</a>", draft-ietf-mobileip-ipv6-21 (work in progress), February 2003.</td></tr>
</table>
<a name="rfc.references2"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<h3>Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><b><a name="RFC2710">[9]</a></b></td>
<td class="author-text"><a href="mailto:deering@cisco.com">Deering, S.</a>, <a href="mailto:fenner@research.att.com">Fenner, W.</a> and <a href="mailto:haberman@raleigh.ibm.com">B. Haberman</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2710.txt">Multicast Listener Discovery (MLD) for IPv6</a>", RFC 2710, October 1999.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="I-D.ietf-dhc-dhcpv6">[10]</a></b></td>
<td class="author-text">Droms, R., "<a href="http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-28.txt">Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</a>", draft-ietf-dhc-dhcpv6-28 (work in progress), November 2002.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="I-D.ietf-ipsec-nat-t-ike">[11]</a></b></td>
<td class="author-text">Kivinen, T., Huttunen, A., Swander, B. and V. Volpe, "<a href="http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-04.txt">Negotiation of NAT-Traversal in the IKE</a>", draft-ietf-ipsec-nat-t-ike-04 (work in progress), November 2002.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="I-D.vida-mld-v2">[12]</a></b></td>
<td class="author-text">Vida, R. and L. Costa, "<a href="http://www.ietf.org/internet-drafts/draft-vida-mld-v2-06.txt">Multicast Listener Discovery Version 2 (MLDv2) for IPv6</a>", draft-vida-mld-v2-06 (work in progress), December 2002.</td></tr>
</table>
<a name="rfc.authors"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Jari Arkko</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Ericsson</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Jorvas 02420</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Finland</td></tr>
<tr><td class="author" align="right">EMail: </td>
<td class="author-text"><a href="mailto:jari.arkko@ericsson.com">jari.arkko@ericsson.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Vijay Devarapalli</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Nokia Research Center</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">313 Fairchild Drive</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Mountain View CA 94043</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">EMail: </td>
<td class="author-text"><a href="mailto:vijayd@iprg.nokia.com">vijayd@iprg.nokia.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Francis Dupont</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">ENST Bretagne</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Campus de Rennes 2, rue de la Chataigneraie</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">BP 78</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Cesson-Sevigne Cedex 35512</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">France</td></tr>
<tr><td class="author" align="right">EMail: </td>
<td class="author-text"><a href="mailto:Francis.Dupont@enst-bretagne.fr">Francis.Dupont@enst-bretagne.fr</a></td></tr>
</table>
<a name="anchor31"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A. Acknowledgements</h3>
<p>The authors would like to thank Greg O'Shea, Michael Thomas, Kevin Miles, Cheryl
Madson, Bernard Aboba, Erik Nordmark, and Gabriel Montenegro for
interesting discussions in this problem space.
</p>
<a name="anchor32"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.B"></a><h3>Appendix B. Changes from Previous Version</h3>
<p>The following changes have been made to this document from version
02:
</p>
<ul class="text">
<li> It is now better explained why the mobile node can change its source
address in security associations before such a change
is told to the home agent (tracked
issue 249).
</li>
<li> The support for protecting prefix discovery with
IPsec has been made mandatory, but use is still
a SHOULD (tracked issue 249).
</li>
<li> Requirements for security association and policy
configuration for new home addresses received
through prefix discovery have been specified (tracked
issue 243).
</li>
<li> IPsec protocol and mode requirements have now been stated
as minimal requirements and no longer prevent the use of
other protocols (AH) and modes (tracked issue 228).
</li>
<li> The specification explicitly discourages the use of
nested IPsec encapsulation (tracked issue 219).
</li>
<li> The different types of requests for phase 2 security
associations have been explained in the requirements
section. This relates to using IKE for creating
security associations for Binding Update protection
or other tasks (tracked issue 219).
</li>
<li> Many editorial modifications have been performed.
</li>
</ul><p><a name="rfc.copyright"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<h3>Intellectual Property Statement</h3>
<p class='copyright'>
The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication and any assurances of licenses to
be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat.</p>
<p class='copyright'>
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.</p>
<h3>Full Copyright Statement</h3>
<p class='copyright'>
Copyright (C) The Internet Society (2003). All Rights Reserved.</p>
<p class='copyright'>
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.</p>
<p class='copyright'>
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.</p>
<p class='copyright'>
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p>
<h3>Acknowledgement</h3>
<p class='copyright'>
Funding for the RFC Editor function is currently provided by the
Internet Society.</p>
</font></body></html>
| PAFTECH AB 2003-2026 | 2026-04-21 20:46:40 |