Home agents MUST allow the first three variables to be configured by system management, and mobile nodes MUST allow the last variable to be configured by system management. The default value for InitialBindackTimeoutFirstReg has been calculated as 1.5 times the default value of RetransTimer  times the default value of DupAddrDetectTransmits . The value MinDelayBetweenRAs overrides the value of the protocol constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 2461 . This variable SHOULD be set to MinRtrAdvInterval, if MinRtrAdvInterval is less than 3 seconds. 10]. Furthermore, each mobility message may contain mobility options as described in Section 6.2. This document defines a new name space "Mobility Option" to identify these options. The current mobility options are defined starting from Section 6.2.2 and are the following:
0 Pad1 1 PadN 2 Binding Refresh Advice 3 Alternate Care-of Address 4 Nonce Indices 5 Authorization Data Future values of the Option Type can be allocated using Standards Action or IESG Approval . Finally, this document creates a third new name space "Status Code" for the Status field in the Binding Acknowledgement message. The current values are described in Section 6.1.8, and are the following: 0 Binding Update accepted 1 Accepted but prefix discovery necessary 128 Reason unspecified 129 Administratively prohibited 130 Insufficient resources 131 Home registration not supported 132 Not home subnet 133 Not home agent for this mobile node 134 Duplicate Address Detection failed 135 Sequence number out of window 136 Expired home nonce index 137 Expired care-of nonce index 138 Expired nonces 139 Registration type change disallowed
Future values of the Status field can be allocated using Standards Action or IESG Approval . All fields labeled "Reserved" are only to be assigned through Standards Action or IESG Approval. This document also defines a new IPv6 destination option, the Home Address option, described in Section 6.3. This option has been assigned the Option Type value 0xC9. This document also defines a new IPv6 type 2 routing header, described in Section 6.4. The value 2 has been allocated by IANA. In addition, this document defines four ICMP message types, two used as part of the dynamic home agent address discovery mechanism, and two used in lieu of Router Solicitations and Advertisements when the mobile node is away from the home link. These messages have been assigned ICMPv6 type numbers from the informational message range: o The Home Agent Address Discovery Request message, described in Section 6.5; o The Home Agent Address Discovery Reply message, described in Section 6.6; o The Mobile Prefix Solicitation, described in Section 6.7; and o The Mobile Prefix Advertisement, described in Section 6.8. This document also defines two new Neighbor Discovery  options, which have been assigned Option Type values within the option numbering space for Neighbor Discovery messages: o The Advertisement Interval option, described in Section 7.3; and o The Home Agent Information option, described in Section 7.4.
An attacker might also attempt to disrupt a mobile node's communications by replaying a Binding Update that the node had sent earlier. If the old Binding Update was accepted, packets destined for the mobile node would be sent to its old location as opposed to its current location. In conclusion, there are Denial-of-Service, Man-in-the-Middle, Confidentiality, and Impersonation threats against the parties involved in sending legitimate Binding Updates, and Denial-of- Service threats against any other party. o Threats associated with payload packets: Payload packets exchanged with mobile nodes are exposed to similar threats as that of regular IPv6 traffic. However, Mobile IPv6 introduces the Home Address destination option, a new routing header type (type 2), and uses tunneling headers in the payload packets. The protocol must protect against potential new threats involving the use of these mechanisms. Third parties become exposed to a reflection threat via the Home Address destination option, unless appropriate security precautions are followed. The Home Address destination option could be used to direct response traffic toward a node whose IP address appears in the option. In this case, ingress filtering would not catch the forged "return address" [36, 32]. A similar threat exists with the tunnels between the mobile node and the home agent. An attacker might forge tunnel packets between the mobile node and the home agent, making it appear that the traffic is coming from the mobile node when it is not. Note that an attacker who is able to forge tunnel packets would typically also be able to forge packets that appear to come directly from the mobile node. This is not a new threat as such. However, it may make it easier for attackers to escape detection by avoiding ingress filtering and packet tracing mechanisms. Furthermore, spoofed tunnel packets might be used to gain access to the home network. Finally, a routing header could also be used in reflection attacks, and in attacks designed to bypass firewalls. The generality of the regular routing header would allow circumvention of IP-address based rules in firewalls. It would also allow reflection of traffic to other nodes. These threats exist with routing headers in general, even if the usage that Mobile IPv6 requires is safe. o Threats associated with dynamic home agent and mobile prefix discovery.
o Threats against the Mobile IPv6 security mechanisms themselves: An attacker might, for instance, lure the participants into executing expensive cryptographic operations or allocating memory for the purpose of keeping state. The victim node would have no resources left to handle other tasks. As a fundamental service in an IPv6 stack, Mobile IPv6 is expected to be deployed in most nodes of the IPv6 Internet. The above threats should therefore be considered as being applicable to the whole Internet. It should also be noted that some additional threats result from movements as such, even without the involvement of mobility protocols. Mobile nodes must be capable to defend themselves in the networks that they visit, as typical perimeter defenses applied in the home network no longer protect them.
Thus, they can and are supposed to have a security association that can be used to reliably authenticate the exchanged messages. See Section 5.1 for the description of the protocol mechanisms, and Section 15.3 below for a discussion of the resulting level of security. It is expected that Mobile IPv6 route optimization will be used on a global basis between nodes belonging to different administrative domains. It would be a very demanding task to build an authentication infrastructure on this scale. Furthermore, a traditional authentication infrastructure cannot be easily used to authenticate IP addresses because IP addresses can change often. It is not sufficient to just authenticate the mobile nodes; Authorization to claim the right to use an address is needed as well. Thus, an "infrastructureless" approach is necessary. The chosen infrastructureless method is described in Section 5.2, and Section 15.4 discusses the resulting security level and the design rationale of this approach. Specific rules guide the use of the Home Address destination option, the routing header, and the tunneling headers in the payload packets. These rules are necessary to remove the vulnerabilities associated with their unrestricted use. The effect of the rules is discussed in Section 15.7, Section 15.8, and Section 15.9. Denial-of-Service threats against Mobile IPv6 security mechanisms themselves concern mainly the Binding Update procedures with correspondent nodes. The protocol has been designed to limit the effects of such attacks, as will be described in Section 15.4.5.
numbers, replay and reordering attacks become possible. The use of dynamic keying, IPsec anti-replay protection, and the Mobile IPv6 sequence numbers can together prevent such attacks. It is also recommended that use of non-volatile storage be considered for home agents, to avoid losing their state. A sliding window scheme is used for the sequence numbers. The protection against replays and reordering attacks without a key management mechanism works when the attacker remembers up to a maximum of 2**15 Binding Updates. The above mechanisms do not show that the care-of address given in the Binding Update is correct. This opens the possibility for Denial-of-Service attacks against third parties. However, since the mobile node and home agent have a security association, the home agent can always identify an ill-behaving mobile node. This allows the home agent operator to discontinue the mobile node's service, and possibly take further actions based on the business relationship with the mobile node's owner. Note that the use of a single pair of manually keyed security associations conflicts with the generation of a new home address  for the mobile node, or with the adoption of a new home subnet prefix. This is because IPsec security associations are bound to the used addresses. While certificate-based automatic keying alleviates this problem to an extent, it is still necessary to ensure that a given mobile node cannot send Binding Updates for the address of another mobile node. In general, this leads to the inclusion of home addresses in certificates in the Subject AltName field. This again limits the introduction of new addresses without either manual or automatic procedures to establish new certificates. Therefore, this specification restricts the generation of new home addresses (for any reason) to those situations where a security association or certificate for the new address already exists. (Appendix B.4 lists the improvement of security for new addresses as one of the future developments for Mobile IPv6.) Support for IKE has been specified as optional. The following should be observed about the use of manual keying: o As discussed above, with manually keyed IPsec, only a limited form of protection exists against replay and reordering attacks. A vulnerability exists if either the sequence number space is cycled through, or if the home agent reboots and forgets its sequence numbers (and uses volatile memory to store the sequence numbers). Assuming the mobile node moves continuously every 10 minutes, it
takes roughly 455 days before the sequence number space has been cycled through. Typical movement patterns rarely reach this high frequency today. o A mobile node and its home agent belong to the same domain. If this were not the case, manual keying would not be possible , but in Mobile IPv6 only these two parties need to know the manually configured keys. Similarly, we note that Mobile IPv6 employs standard block ciphers in IPsec, and is not vulnerable to problems associated with stream ciphers and manual keying. o It is expected that the owner of the mobile node and the administrator of the home agent agree on the used keys and other parameters with some off-line mechanism. The use of IKEv1 with Mobile IPv6 is documented in more detail in . The following should be observed from the use of IKEv1: o It is necessary to prevent a mobile node from claiming another mobile node's home address. The home agent must verify that the mobile node trying to negotiate the SA for a particular home address is authorized for that home address. This implies that even with the use of IKE, a policy entry needs to be configured for each home address served by the home agent. It may be possible to include home addresses in the Subject AltName field of certificate to avoid this. However, implementations are not guaranteed to support the use of a particular IP address (care-of address) while another address (home address) appears in the certificate. In any case, even this approach would require user-specific tasks in the certificate authority. o If preshared secret authentication is used, IKEv1 main mode cannot be used. Aggressive mode or group preshared secrets need to be used with corresponding security implications instead. Note that, like many other issues, this is a general IKEv1 issue related to the ability to use different IP addresses, and not specifically related to Mobile IPv6. For further information, see Section 4.4 in . o Due to the problems outlined in Section 11.3.2, IKE phase 1 between the mobile node and its home agent is established using the mobile node's current care-of address. This implies that when the mobile node moves to a new location, it may have to re- establish phase 1. A Key Management Mobility Capability (K) flag
is provided for implementations that can update the IKE phase 1 endpoints without re-establishing phase 1, but the support for this behavior is optional. o When certificates are used, IKE fragmentation can occur as discussed in Section 7 in . o Nevertheless, even if per-mobile node configuration is required with IKE, an important benefit of IKE is that it automates the negotiation of cryptographic parameters, including the SPIs, cryptographic algorithms, and so on. Thus, less configuration information is needed. o The frequency of movements in some link layers or deployment scenarios may be high enough to make replay and reordering attacks possible, if only manual keying is used. IKE SHOULD be used in such cases. Potentially vulnerable scenarios involve continuous movement through small cells, or uncontrolled alternation between available network attachment points. o Similarly, in some deployment scenarios the number of mobile nodes may be very large. In these cases, it can be necessary to use automatic mechanisms to reduce the management effort in the administration of cryptographic parameters, even if some per- mobile node configuration is always needed. IKE SHOULD also be used in such cases. o Other automatic key management mechanisms exist beyond IKEv1, but this document does not address the issues related to them. We note, however, that most of the above discussion applies to IKEv2  as well, at least as it is currently specified.
it is at its home location. The possibility of such attacks is not an impediment to the deployment of Mobile IPv6 because these attacks are possible regardless of whether or not Mobile IPv6 is in use. This procedure also protects against Denial-of-Service attacks in which the attacker pretends to be mobile, but uses the victim's address as the care-of address. This would cause the correspondent node to send the victim some unexpected traffic. This procedure defends against these attacks by requiring at least the passive presence of the attacker at the care-of address or on the path from the correspondent to the care-of address. Normally, this will be the mobile node.
binding. This happens even if the attacker moves away from the link. In contrast, an attacker who uses only plain IPv6 generally has to stay on the link in order to continue the attack. Note that in order to launch these new attacks, the IP address of the victim must be known. This makes this attack feasible, mainly in the context of well-known interface IDs, such as those already appearing in the traffic on the link or registered in the DNS. On-path attackers can exploit similar vulnerabilities as in regular IPv6. There are some minor differences, however. Masquerade, Man- in-the-Middle, and Denial-of-Service attacks can be launched with just the interception of a few packets, whereas in regular IPv6 it is necessary to intercept every packet. The effect of the attacks is the same regardless of the method, however. In any case, the most difficult task an attacker faces in these attacks is getting on the right path. The vulnerabilities for off-path attackers are the same as in regular IPv6. Those nodes that are not on the path between the home agent and the correspondent node will not be able to receive the home address probe messages. In conclusion, we can state the following main results from this comparison: o Return routability prevents any off-path attacks beyond those that are already possible in regular IPv6. This is the most important result, preventing attackers on the Internet from exploiting any vulnerabilities. o Vulnerabilities to attackers on the home agent link, the correspondent node link, and the path between them are roughly the same as in regular IPv6. o However, one difference is that in basic IPv6 an on-path attacker must be constantly present on the link or the path, whereas with Mobile IPv6, an attacker can leave a binding behind after moving away. For this reason, this specification limits the creation of bindings to at most MAX_TOKEN_LIFETIME seconds after the last routability check has been performed, and limits the duration of a binding to at most MAX_RR_BINDING_LIFETIME seconds. With these limitations, attackers cannot take any practical advantages of this vulnerability.
o There are some other minor differences, such as an effect to the Denial-of-Service vulnerabilities. These can be considered to be insignificant. o The path between the home agent and a correspondent node is typically easiest to attack on the links at either end, in particular if these links are publicly accessible wireless LANs. Attacks against the routers or switches on the path are typically harder to accomplish. The security on layer 2 of the links plays then a major role in the resulting overall network security. Similarly, security of IPv6 Neighbor and Router Discovery on these links has a large impact. If these were secured using some new technology in the future, this could change the situation regarding the easiest point of attack. For a more in-depth discussion of these issues, see .
Nevertheless, as  describes, there are situations in which it is impossible for the mobile and correspondent nodes to determine if they actually need a binding or whether they just have been fooled into believing so by an attacker. Therefore, it is necessary to consider situations where such attacks are being made. Even if route optimization is a very important optimization, it is still only an optimization. A mobile node can communicate with a correspondent node even if the correspondent refuses to accept any Binding Updates. However, performance will suffer because packets from the correspondent node to the mobile node will be routed via the mobile's home agent rather than a more direct route. A correspondent node can protect itself against some of these resource exhaustion attacks as follows. If the correspondent node is flooded with a large number of Binding Updates that fail the cryptographic integrity checks, it can stop processing Binding Updates. If a correspondent node finds that it is spending more resources on checking bogus Binding Updates than it is likely to save by accepting genuine Binding Updates, then it may silently discard some or all Binding Updates without performing any cryptographic operations. Layers above IP can usually provide additional information to help decide if there is a need to establish a binding with a specific peer. For example, TCP knows if the node has a queue of data that it is trying to send to a peer. An implementation of this specification is not required to make use of information from higher protocol layers, but some implementations are likely to be able to manage resources more effectively by making use of such information. We also require that all implementations be capable of administratively disabling route optimization.
The tokens used in the return routability procedure provide together 128 bits of information. This information is used internally as input to a hash function to produce a 160 bit quantity suitable for producing the keyed hash in the Binding Update using the HMAC_SHA1 algorithm. The final keyed hash length is 96 bits. The limiting factors in this case are the input token lengths and the final keyed hash length. The internal hash function application does not reduce the entropy. The 96 bit final keyed hash is of typical size and is believed to be secure. The 128 bit input from the tokens is broken in two pieces, the home keygen token and the care-of keygen token. An attacker can try to guess the correct cookie value, but again this would require a large number of messages (an the average 2**63 messages for one or 2**127 for two). Furthermore, given that the cookies are valid only for a short period of time, the attack has to keep a high constant message rate to achieve a lasting effect. This does not appear practical. When the mobile node is returning home, it is allowed to use just the home keygen token of 64 bits. This is less than 128 bits, but attacking it blindly would still require a large number of messages to be sent. If the attacker is on the path and capable of seeing the Binding Update, it could conceivably break the keyed hash with brute force. However, in this case the attacker has to be on the path, which appears to offer easier ways for denial-of-service than preventing route optimization.
addresses. In particular, the outer IP address check described above is not sufficient against all attackers. The use of encrypted tunnels is particularly useful for these kinds of home addresses. 26] works in the usual manner even for mobile nodes, as the Source Address is topologically correct. The Home Address option is used to inform the correspondent node of the mobile node's home address. However, the care-of address in the Source Address field does not survive in replies sent by the correspondent node unless it has a binding for this mobile node. Also, not all attacker tracing mechanisms work when packets are being reflected through correspondent nodes using the Home Address option. For these reasons, this specification restricts the use of the Home Address option. It may only be used when a binding has already been established with the participation of the node at the home address, as described in Section 5.5 and Section 6.3. This prevents reflection attacks through the use of the Home Address option. It also ensures that the correspondent nodes reply to the same address that the mobile node sends traffic from. No special authentication of the Home Address option is required beyond the above, but note that if the IPv6 header of a packet is covered by IPsec Authentication Header, then that authentication covers the Home Address option as well. Thus, even when authentication is used in the IPv6 header, the security of the Source Address field in the IPv6 header is not compromised by the presence of a Home Address option. Without authentication of the packet, any field in the IPv6 header, including the Source Address field or any other part of the packet and the Home Address option can be forged or modified in transit. In this case, the contents of the Home Address option is no more suspect than any other part of the packet.
Generally, source routing has a number of security concerns. These include the automatic reversal of unauthenticated source routes (which is an issue for IPv4, but not for IPv6). Another concern is the ability to use source routing to "jump" between nodes inside, as well as outside a firewall. These security concerns are not issues in Mobile IPv6, due to the rules mentioned above. In essence the semantics of the type 2 routing header is the same as a special form of IP-in-IP tunneling where the inner and outer source addresses are the same. This implies that a device which implements the filtering of packets should be able to distinguish between a type 2 routing header and other routing headers, as required in Section 8.3. This is necessary in order to allow Mobile IPv6 traffic while still having the option of filtering out other uses of routing headers. 34] were adopted in the protocol. Significant contributions were made by members of the Mobile IPv6 Security Design Team, including (in alphabetical order) Gabriel Montenegro, Erik Nordmark and Pekka Nikander.
Xinhua Zhao, for their detailed reviews of earlier versions of this document. Their suggestions have helped to improve both the design and presentation of the protocol. We would also like to thank the participants of the Mobile IPv6 testing event (1999), implementors who participated in Mobile IPv6 interoperability testing at Connectathons (2000, 2001, 2002, and 2003), and the participants at the ETSI interoperability testing (2000, 2002). Finally, we would like to thank the TAHI project who has provided test suites for Mobile IPv6.  Eastlake 3rd., D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.  Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.  Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.  Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.  Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.  Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.  Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.  Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.  Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.  Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.  Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.  National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, <http:// www.itl.nist.gov/fipspubs/fip180-1.htm>.  Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.  Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.  Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.  Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
 Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.  Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.  Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", Work in Progress, March 2002.  Bellovin, S., "Guidelines for Mandating Automated Key Management", Work in Progress, August 2003.  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.  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, April 2003.  Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.  Nikander, P., Aura, T., Arkko, J., Montenegro, G. and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", Work in Progress, April 2003.  Nordmark, E., "Securing MIPv6 BUs using return routability (BU3WAY)", Work in Progress, November 2001.  Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", Work in Progress, March 2002.  Savola, P., "Use of /127 Prefix Length Between Routers Considered Harmful", RFC 3627, September 2003.  Savola, P., "Security of IPv6 Routing Header and Home Address Options", Work in Progress, December 2002.  Vida, R. and L. Costa, Eds., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
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- firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.