Verifying Correctness of Alternate Care-of Address Option
draft-arkko-mext-rfc3775-altcoa-check-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

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.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 21, 2008.

Abstract

This document revises the RFC 3775 rules on how Alternate Care-of Address option is processed. Alternate Care-of Address option is used to carry the current care-of address inside a Mobility Header message. This is used in addition to the source address in the packet in order to ensure that the care-of address is protected by IPsec ESP, the security mechanism that protects Mobility Header messages. Unfortunately, RFC 3775 did not require verification that the source address and care-of address are the same. This document adds that requirement.

1.  Introduction

This document revises the RFC 3775 rules on how Alternate Care-of Address option is processed [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) by home agents and correspondent nodes. Alternate Care-of Address option is used to carry the current care-of address inside a Mobility Header message. This is used in addition to the source address in the packet in order to ensure that the care-of address is protected by IPsec ESP. IPsec ESP is the security mechanism that protects Mobility Header messages for the signaling between the mobile node and home agent [RFC3776] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.).

Unfortunately, RFC 3775 did not require verification that the source address and care-of address are the same. This document adds that requirement. The rationale for this is to ensure that a mobile node does not spoof its care-of address and cause a flooding attack to a victim residing in the given care-of address [RFC4225] (Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, “Mobile IP Version 6 Route Optimization Security Design Background,” December 2005.). In Mobile IPv6, the home agent trusts the mobile node to not lie about its care-of address, because they have a security association and the administrator of the home agent could disconnect the service to a misbehaving mobile node. This is in contrast to route optimization that is performed with any node in the Internet. There it is required that the correspondent node actually verifies the validity of the claimed care-of address with a return routability test. However, these two cases represent extremes. In the former case, absolutely no checking is done. In the latter case an explicit test is done. Neither case relies on the correctness of the source address. This assumption is valid because, in general, we cannot assume that ingress filtering in the Internet is always done.

But the downside is that the specification does not benefit from possible ingress filtering that may be applied in some networks. For instance, the aviation community is planning to employ Mobile IPv6 in some of its safety critical networks that are not reachable from the global Internet. These networks will apply ingress filtering, and it would be useful to be able to benefit from this within such a network. Currently, this is not possible as there is no requirement that Alternate Care-of Address option contains a valid source address. As a result, this document adds this requirement.

At the same time, this change deprecates the ability of the mobile node to provide a different care-of address to the home agent than it is using as a source address. One potential use of this would be to use a temporary source address [RFC4941] (Narten, T., Draves, R., and S. Krishnan, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6,” September 2007.) for privacy reasons. However, given the existence of an IPsec SPI, sequence number, and potential link layer identifiers, it is unlikely that this approach will be able provide actual protection for privacy.

Another potential use of a different care-of address relates to handovers and being able to instruct the home agent to send traffic to a new care-of address before actually being on the link. However, this is something that cannot be done unless the mobile node either actually attaches to the link or uses mechanisms capable of creating a presence on the other link before attaching to it, such as FMIP [RFC4068] (Koodli, R., “Fast Handovers for Mobile IPv6,” July 2005.). In the former case it becomes possible to send a Binding Update from the right link. In the latter case, FMIP is capable of tunneling packets sent to the old link to the new location, so the Mobile IPv6 handover does not have to be done under so strict timeliness requirements. Note that FMIP itself employs a mandatory Alternate Care-of Address option, using an address that is not topologically correct. Current specification does not say anything about how this address is verified. However, as FMIP routers are aware of the assignment of addresses on the other router, it seems in theory possible to construct such an FMIP-specific test.

Finally, at the time of writing this, extensions are being written to Mobile IPv6 to allow the registration of multiple care-of addresses. The specific mechanisms that these extensions use for ensuring the correctness of care-of address is still being discussed. However, it is assumed that the same principles can apply there as well: the active care-of address is the one that should also appear in the source address, and when a switch to another care-of address is being made some verification of the address happens as a part of the path testing, policy update, or other processes.

As a result, the author believes that benefits of adding this check outweight the potential benefits of being able to use a different source address.

2.  Requirements language

In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Processing Alternate Care-of Address Option

When an Alternate Care-of Address option is present in a Binding Update message, perform the following additional test:

If the address in the Alternate Care-of Address option is not the same as either the home address or the Source Address field in the IPv6 header of the Binding Update packet, then by default the receiving node MUST send back a Binding Acknowledgement with status code TBD-BY-IANA (mismatching source address). The Binding Cache entry targeted by the Binding Update, if any, MUST NOT be changed.

This check is performed by default. Explicit configuration from the network administrator can turn this behaviour off.

This check affects the processing of Binding Updates as specified in RFC 3775 Section 9.5.1, and applies both to correspondent nodes and home agents.

4.  Security Considerations

This document is about a change in the security policy related to the processing of an option in the Mobile IPv6 protocol. The security implications are discussed in Section 1 (Introduction).

While the additional check can be useful in networks that employ Mobile IPv6 and ingress filtering, there is no assumption that ingress filtering is always applied, applied correctly, or that security of Mobile IPv6 is somehow based on a correctly operating ingress filterin underneath. Indeed, ingress filtering is frequently not enabled or enabled to perform only partial checks. For these reasons -- as documented in RFC 3775 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) -- Mobile IPv6 requires strong authentication of the mobile node to its home agent, and that the home agent can trust mobile nodes or at least that the administrators can disconnect a misbehaving mobile node.

5.  IANA Considerations

A new Status Code in the Mobile IPv6 Parameters registry needs to be allocated to "mismatching source address" (Section 3 (Processing Alternate Care-of Address Option)).

6.  References

6.1. Normative References

6.2. Normative References

Appendix A.  Changes from RFC 3775

RFC 3775 has been changed with regards to the Alternate Care-of Address option process rules, outlined in Section 3 (Processing Alternate Care-of Address Option). Note that this also affects indirectly network mobility as specified in [RFC3963] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.).

Appendix B.  Acknowledgements

The author would like to thank the February 2008 MEXT WG interim meeting participants, in particular Ryuji Wakikawa, Jean-Michel Combes, Julien Laganier, and Marcelo Bagnulo Braun for bringing this issue into attention.

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

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, THE IETF TRUST 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.