IPv6 header (source = home agent
destination = care-of address)
UDP
IKE
... IDir = ID_FQDN ha.net ...
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. These addresses will be used
as selectors. 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.
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 ...
Step 4. The remaining steps are as shown in Section 6.1.
6.18. Rekeying Security Associations
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.
Step 2. Mobility header packets sent during rekey may be protected
by the existing security associations.
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.
Step 4. A notification of the deletion of the old security
associations is received. After this, only the new security
associations can be used.
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.
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.
6.19. Movements and Dynamic Keying
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.
Step 1. Mobile node with the home address A moves to care-of address
B.
Step 2. Mobile node runs IKE from care-of address B to the home
agent, establishing a phase 1. The home agent can only act as the
responder before it knows the current location of the mobile node.
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.
Step 4. Mobile node sends a Binding Update and receives a Binding
Acknowledgement using the security associations created in Step 3.
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.
Step 6. The mobile node uses the security associations created in
Step 5 to run return routability.
Step 7. The mobile node moves to a new location and adopts a new
care-of address C.
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 outer header destination address
in the security association had changed.
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 do not have
the capability, both nodes remove their phase 1 connections created
on top of the care-of address B and will 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 Key Management
Mobility Capability (K) flag [7] in the Binding Update and Binding
Acknowledgement messages.
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.
7. Implementation Considerations
7.1. IPsec
Note that packet formats and header ordering discussed in Section 3
must be supported, but implementations may also support other
formats. In general, the use of formats not required here may lead
to incorrect processing of the packets by the peer (such as silently
discarding them), unless support for these formats has been verified
off-line. Such verification can take place at the same time the
parameters of the security associations are agreed upon. In some
cases, however, basic IPv6 specifications call for support of options
not discussed here. In these cases, such a verification step might
be unnecessary as long as the peer fully supports the relevant IPv6
specifications. However, no claims are made in this document about
the validity of these other formats in the context of Mobile IPv6.
It is also likely that systems that support Mobile IPv6 have been
tested more extensively with the required formats.
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. Such an overhead would not be significant for the
protection of the return routability packets, but would create an
additional overhead if IPsec is used to protect the tunneling of
payload packets to the home agent. This overhead may be significant
for real-time traffic. Given that the use of the shorter packet
formats for any traffic requires the existence of suitable APIs, we
have chosen to require support for the shorter packet formats both
for payload and return routability packets.
In order to support the care-of address as the destination address on
the mobile node side, the home agent must act as if the outer header
destination address in the security association to the mobile node
would have changed upon movements. 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.
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. 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.
7.2. IKE
We have 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.
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.
Fortunately, typical Mobile IPv6 deployment uses short certificate
chains, as the mobile node is communicating directly with its home
network. Where the problem appears, it may be difficult (at least
away from home) to replace the firewalls or routers with equipment
that can properly support fragments. It may help to store the peer
certificates locally, or to obtain them through other means.
7.3. Bump-in-the-Stack
Mobile IPv6 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 before or 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).
Specifically, Bump-in-the-Stack implementations may have to deal with
the following issues:
o Processing the Home Address destination option and Routing header
type 2 to a form suitable for IPsec processing to take place.
This is needed, among other things, for the security association
and policy lookups. While relatively straightforward, the
required processing may have a hardware effect in BITS
implementations, if they use hardware support beyond the
cryptographic operations.
o Detecting packets sent between the mobile node and its home agent
using IPv6 encapsulation.
o Offering the necessary APIs for updating the IPsec and IKE
security association endpoints.
8. IANA Considerations
No IANA actions are necessary based on this document. IANA actions
for the Mobile IPv6 protocol itself have been covered in [7].
9. Security Considerations
The Mobile IPv6 base specification [7] requires strong security
between the mobile node and the home agent. This memo discusses how
that security can be arranged in practice, using IPsec. The security
considerations related to this are documented in the base
specification, including a discussion of the implications of using
either manual or dynamic keying.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
10.2. Informative References
[8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[10] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[11] Vida, R. and L. Costa, Eds., "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
11. Acknowledgements
The authors would like to thank Greg O’Shea, Michael Thomas, Kevin
Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, Gabriel
Montenegro, Steven Kent, and Santeri Paavolainen for interesting
discussions in this problem space.
12. Authors’ Addresses
Jari Arkko
Ericsson
02420 Jorvas
Finland
EMail: jari.arkko@ericsson.com
Vijay Devarapalli
Nokia Research Center
313 Fairchild Drive
Mountain View CA 94043
USA
EMail: vijayd@iprg.nokia.com
Francis Dupont
ENST Bretagne
Campus de Rennes
2, rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
EMail: Francis.Dupont@enst-bretagne.fr
13. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.