RFC 5568
Mobile IPv6 Fast Handovers
7. Related Protocol and Device Considerations
The protocol specified here, as a design principle, introduces no or minimal changes to related protocols. For example, no changes to the base Mobile IPv6 protocol are needed in order to implement this protocol. Similarly, no changes to the IPv6 stateless address auto- configuration protocol [RFC4862] and DHCP [RFC3315] are introduced. The protocol specifies an optional extension to Neighbor Discovery [RFC4861] in which an access router may send a router advertisement as a response to the UNA message (see Section 6.3). Other than this extension, the specification does not modify Neighbor Discovery behavior (including the procedures performed when attached to the PAR and when attaching to the NAR). The protocol does not require changes to any intermediate Layer 2 device between an MN and its access router that supports this specification. This includes the wireless access points, switches, snooping devices, and so on.8. Evolution from and Compatibility with RFC 4068
This document has evolved from [RFC4068]. Specifically, a new handover key establishment protocol (see [RFC5269]) has been defined to enable a security association between a mobile node and its access router. This allows the secure update of the routing of packets during a handover. In the future, new specifications may be defined to establish such security associations depending on the particular deployment scenario.
The protocol has improved from the experiences in implementing [RFC4068], and from experimental usage. The input has improved the specification of parameter fields (such as lifetime, codepoints, etc.) as well as inclusion of new parameter fields in the existing messages. As of this writing, there are two publicly available implementations, [fmipv6] and [tarzan], and multiple proprietary implementations. Some experience suggests that the protocol meets the delay and packet loss requirements when used appropriately with particular radio access protocols. For instance, see [RFC5184] and [mip6-book]. Nevertheless, it is important to recognize that handover performance is a function of both IP-layer operations, which this protocol specifies, and the particular radio access technology itself, which this protocol relies upon but does not modify. An existing implementation of [RFC4068] needs to be updated in order to support this specification. The primary addition is the establishment of a security association between an MN and its access router (i.e., MN and PAR). One way to establish such a security association is specified in [RFC5269]. An implementation that complies with the specification in this document is likely to also work with [RFC4068], except for the Binding Authorization Data for FMIPv6 option (see Section 6.4.5) that can only be processed when a security association is in place between a mobile node and its access router. This specification deprecates the Fast Neighbor Advertisement (FNA) message. However, it is acceptable for a NAR to process this message from a mobile node as specified in [RFC4068].9. Configurable Parameters
Mobile nodes rely on configuration parameters shown in the table below. Each mobile node MUST have a configuration mechanism to adjust the parameters. Such a configuration mechanism may be either local (such as a command line interface) or based on central management of a number of mobile nodes. +-------------------+---------------+-----------------+ | Parameter Name | Default Value | Definition | +-------------------+---------------+-----------------+ | RTSOLPR_RETRIES | 3 | Section 6.1.1 | | MAX_RTSOLPR_RATE | 3 | Section 6.1.1 | | FBU_RETRIES | 3 | Section 6.2.2 | | PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.1.2 | | HI_RETRIES | 3 | Section 6.2.1.1 | +-------------------+---------------+-----------------+
10. Security Considerations
The following security vulnerabilities are identified and suggested solutions are mentioned. Insecure FBU: in this case, packets meant for one address could be stolen or redirected to some unsuspecting node. This concern is the same as that in an MN and Home Agent relationship. Hence, the PAR MUST ensure that the FBU packet arrived from a node that legitimately owns the PCoA. The access router and its hosts may use any available mechanism to establish a security association that MUST be used to secure FBU. The current version of this protocol relies on a companion protocol [RFC5269] to establish such a security association. Using the shared handover key from [RFC5269], the Authenticator in BADF option (see Section 6.4.5) MUST be computed, and the BADF option included in FBU and FBack messages. Secure FBU, malicious or inadvertent redirection: in this case, the FBU is secured, but the target of binding happens to be an unsuspecting node either due to inadvertent operation or due to malicious intent. This vulnerability can lead to an MN with a genuine security association with its access router redirecting traffic to an incorrect address. However, the target of malicious traffic redirection is limited to an interface on an access router with which the PAR has a security association. The PAR MUST verify that the NCoA to which the PCoA is being bound actually belongs to the NAR's prefix. In order to do this, HI and HAck message exchanges are to be used. When the NAR accepts the NCoA in HI (with Code = 0), it proxies the NCoA so that any arriving packets are not sent on the link until the MN attaches and announces itself through the UNA. Therefore, any inadvertent or malicious redirection to a host is avoided. It is still possible to jam a NAR's buffer with redirected traffic. However, since a NAR's handover state corresponding to an NCoA has a finite (and short) lifetime corresponding to a small multiple of anticipated handover latency, the extent of this vulnerability is arguably small. Sending an FBU from a NAR's link: A malicious node may send an FBU from a NAR's link providing an unsuspecting node's address as an NCoA. This is similar to base Mobile IP where the MN can provide some other node's IP address as its CoA to its Home Agent; here, the PAR acts like a "temporary Home Agent" having a security association with the mobile node and providing forwarding support for the handover traffic. As in base Mobile IP, this misdelivery
is traceable to the MN that has a security association with the
router. So, it is possible to isolate such an MN if it continues
to misbehave. Similarly, an MN that has a security association
with the PAR may provide the LLA of some other node on NAR's link,
which can cause misdelivery of packets (meant for the NCoA) to an
unsuspecting node. It is possible to trace the MN in this case as
well.
Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv
(Section 6.1.2) messages inherit the weaknesses of the Neighbor
Discovery protocol [RFC4861]. Specifically, when its access router
is compromised, the MN's RtSolPr message may be answered by an
attacker that provides a rogue router as the resolution. Should the
MN attach to such a rogue router, its communication can be
compromised. Similarly, a network-initiated PrRtAdv message (see
Section 3.3) from an attacker could cause an MN to handover to a
rogue router. Where these weaknesses are a concern, a solution such
as Secure Neighbor Discovery (SEND) [RFC3971] SHOULD be considered.
The protocol provides support for buffering packets during an MN's
handover. This is done by securely exchanging the Handover Initiate
(HI) and Handover Acknowledge (HAck) messages in response to the FBU
message from an MN. It is possible that an MN may fail, either
inadvertently or purposely, to undergo handover to the NAR, which
typically provides buffering support. This can cause the NAR to
waste its memory containing the buffered packets, and in the worst
case, could create resource exhaustion concerns. Hence,
implementations must limit the size of the buffer as a local policy
configuration that may consider parameters such as the average
handover delay, expected size of packets, and so on.
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages
exchanged between the PAR and NAR MUST be protected using end-to-end
security association(s) offering integrity and data origin
authentication.
The PAR and the NAR MUST implement IPsec [RFC4301] for protecting the
HI and HAck messages. IPsec Encapsulating Security Payload (ESP)
[RFC4303] in transport mode with mandatory integrity protection
SHOULD be used for protecting the signaling messages.
Confidentiality protection of these messages is not required.
The security associations can be created by using either manual IPsec
configuration or a dynamic key negotiation protocol such as Internet
Key Exchange Protocol version 2 (IKEv2) [RFC4306]. If IKEv2 is used,
the PAR and the NAR can use any of the authentication mechanisms, as
specified in RFC 4306, for mutual authentication. However, to ensure
a baseline interoperability, the implementations MUST support shared
secrets for mutual authentication. The following sections describe the Peer Authorization Database (PAD) and Security Policy Database (SPD) entries specified in [RFC4301] when IKEv2 is used for setting up the required IPsec security associations.10.1. Peer Authorization Database Entries When Using IKEv2
This section describes PAD entries on the PAR and the NAR. The PAD entries are only example configurations. Note that the PAD is a logical concept, and a particular PAR or NAR implementation can implement the PAD in any implementation-specific manner. The PAD state may also be distributed across various databases in a specific implementation. PAR PAD: - IF remote_identity = nar_identity_1 THEN authenticate (shared secret/certificate/EAP) and authorize CHILD_SA for remote address nar_address_1 NAR PAD: - IF remote_identity = par_identity_1 THEN authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for remote address par_address_1 The list of authentication mechanisms in the above examples is not exhaustive. There could be other credentials used for authentication stored in the PAD.10.2. Security Policy Database Entries
This section describes the security policy entries on the PAR and the NAR required to protect the HI and HAck messages. The SPD entries are only example configurations. A particular PAR or NAR implementation could configure different SPD entries as long as they provide the required security. In the examples shown below, the identity of the PAR is assumed to be par_1, the address of the PAR is assumed to be par_address_1, and the address of the NAR is assumed to be nar_address_1.
PAR SPD-S:
- IF local_address = par_address_1 &
remote_address = nar_address_1 &
proto = MH &
local_mh_type = HI &
remote_mh_type = HAck
THEN use SA ESP transport mode Initiate using IDi = par_1 to
address nar_address_1
NAR SPD-S:
- IF local_address = nar_address_1 &
remote_address = par_address_1 &
proto = MH &
local_mh_type = HAck &
remote_mh_type = HI
THEN use SA ESP transport mode
11. IANA Considerations
This document defines two new Mobility Header messages that have
received Type assignment from the Mobility Header Type registry.
14 Handover Initiate Message (Section 6.2.1.1)
15 Handover Acknowledge Message (Section 6.2.1.2)
This document defines a new Mobility Option that has received Type
assignment from the Mobility Options Type registry.
1. Mobility Header IPv6 Address/Prefix option (34), described in
Section 6.4.2
This document defines a new ICMPv6 message, which has been allocated
from the ICMPv6 Type registry.
154 FMIPv6 Messages
This document creates a new registry for the 'Subtype' field in the
above ICMPv6 message, called the "FMIPv6 Message Types". IANA has
assigned the following values.
+---------+-------------------+-----------------+
| Subtype | Description | Reference |
+---------+-------------------+-----------------+
| 2 | RtSolPr | Section 6.1.1 |
| 3 | PrRtAdv | Section 6.1.2 |
| 4 | HI - Deprecated | Section 6.2.1.1 |
| 5 | HAck - Deprecated | Section 6.2.1.2 |
+---------+-------------------+-----------------+
The values '0' and '1' are reserved. The upper limit is 255. An RFC
is required for new message assignment. The Subtype values 4 and 5
are deprecated but marked as unavailable for future allocations.
The document defines a new Mobility Option that has received Type
assignment from the Mobility Options Type registry.
1. Binding Authorization Data for FMIPv6 (BADF) option (21),
described in Section 6.4.5
The document defines the following Neighbor Discovery [RFC4861]
options that have received Type assignment from IANA.
+------+--------------------------------------------+---------------+
| Type | Description | Reference |
+------+--------------------------------------------+---------------+
| 17 | IP Address/Prefix Option | Section 6.4.1 |
| 19 | Link-layer Address Option | Section 6.4.3 |
| 20 | Neighbor Advertisement Acknowledgment | Section 6.4.6 |
| | Option | |
+------+--------------------------------------------+---------------+
The document defines the following Mobility Header messages that have
received Type allocation from the Mobility Header Types registry.
1. Fast Binding Update (8), described in Section 6.2.2
2. Fast Binding Acknowledgment (9), described in Section 6.2.3
The document defines the following Mobility Option that has received
Type assignment from the Mobility Options Type registry.
1. Mobility Header Link-Layer Address option (7), described in
Section 6.4.4
12. Acknowledgments
The editor would like to thank all those who have provided feedback on this specification, but can only mention a few here: Vijay Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj Premec, Subba Reddy, K. Raghav, Ranjit Wable, and Jonathan Wood. Behcet Sarikaya and Frank Xia are acknowledged for the feedback on operation over point-to-point links. The editor would like to acknowledge a contribution from James Kempf to improve this specification. Vijay Devarapalli provided text for the security configuration between access routers in Section 10. Thanks to Jari Arkko for the detailed AD Review, which has improved this document. The editor would also like to thank the MIPSHOP working group chair Gabriel Montenegro and the erstwhile MOBILE IP working group chairs Basavaraj Patil and Phil Roberts for providing much support for this work.13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008. [RFC5269] Kempf, J. and R. Koodli, "Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND)", RFC 5269, June 2008.13.2. Informative References
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover", RFC 5184, May 2008. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. [fmipv6] "fmipv6.org : Home Page", <http://fmipv6.org>. [mip6-book] Koodli, R. and C. Perkins, "Mobile Inter-networking with IPv6", Chapter 22, John Wiley & Sons, Inc., 2007. [pfmipv6] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", Work in Progress, May 2009. [tarzan] "Nautilus6 - Tarzan", <http://software.nautilus6.org/TARZAN/>.
[x.s0057] 3GPP2, "E-UTRAN - eHRPD Connectivity and Interworking: Core Network Aspects", 3GPP2 X.S0057-0, April 2009, <http://www.3gpp2.org/Public_html/Specs/ X.S0057-0_v1.0_090406.pdf>.
Appendix A. Contributors
This document has its origins in the fast handover design team in the erstwhile MOBILE IP working group. The members of this design team in alphabetical order were: Gopal Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis, and Alper Yegin.Appendix B. Changes since RFC 5268
This document specifies the Mobility Header format for HI and HAck messages, and the Mobility Header Option format for IPv6 Address/ Prefix option. The use of ICMP for HI and HAck messages is deprecated. The following developments led the WG to adopt this change: o The Proxy Mobile IPv6 protocol [RFC5213] has been adopted for the deployment of fourth-generation mobile networks. This has established Mobility Header as the default type for critical IP mobility signaling. o The Mobile IPv6 protocol [RFC3775] (particularly, the Dual-stack MIP6 or DSMIP6 [RFC5555]) protocol, which is also expected to be deployed in the fourth-generation mobile networks, similarly relies on Mobility Header for critical IP mobility signaling. o The Fast Handover protocol specified in this document is used as the basis for the Fast Handover for Proxy MIP6 [pfmipv6], which is adopted by the "enhanced HRPD" (CDMA) networks [x.s0057]. Hence, the Fast Handover protocol, when used in deployments using either PMIP6 or MIP6, needs to support the Mobility Header for all its critical mobility signaling messages. At the same time, use of ICMP, primarily due to legacy, is unlikely to facilitate critical IP mobility signaling without a non-trivial departure from deploying the new Mobility Header signaling protocols. Therefore, it follows that specifying the Mobility Header for the HI and HAck messages is necessary for the deployment of the protocol along-side PMIP6 and MIP6 protocols.Appendix C. Changes since RFC 4068
The following are the major changes and clarifications: o Specified security association between the MN and its Access Router in the companion document [RFC5269].
o Specified Binding Authorization Data for Fast Handovers (BADF)
option to carry the security parameters used for verifying the
authenticity of FBU and FBack messages. The handover key used for
computing the Authenticator is specified in companion documents.
o Specified the security configuration for inter - access router
signaling (HI, HAck).
o Added a section on prefix management between access routers and
illustrated protocol operation over point-to-point links.
o Deprecated FNA, which is a Mobility Header message. In its place,
the Unsolicited Neighbor Advertisement (UNA) message from RFC 4861
is used.
o Combined the IPv6 Address Option and IPv6 Prefix Option.
o Added description of the DAD requirement on NAR when determining
NCoA uniqueness in Section 4, "Protocol Details".
o Added a new code value for a gratuitous HAck message to trigger a
HI message.
o Added Option-Code 5 in PrRtAdv message to indicate NETLMM
(Network-based Localized Mobility Management) usage.
o Clarified protocol usage when DHCP is used for NCoA formulation
(Sections 6.1.2, 3.1, and 5.2). Added a new Code value (5) in
PrRtAdv (Section 6.1.2).
o Clarified that IPv6 Neighbor Discovery operations are a must in
Section 7, "Related Protocol and Device Considerations".
o Clarified "PAR = temporary HA" for FBUs sent by a genuine MN to an
unsuspecting CoA.
Author's Address
Rajeev Koodli (editor)
Starent Networks
USA
EMail: rkoodli@starentnetworks.com