Network Working Group                                           J. Arkko
Internet-Draft                                                  Ericsson
Updates: 3775 (if approved)                            February 25, 2008
Intended status: Standards Track
Expires: August 28, 2008


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

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 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (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



Arkko                    Expires August 28, 2008                [Page 1]

 
Internet-Draft                Alt-CoA Check                February 2008


   the source address and care-of address are the same.  This document
   adds that requirement.


.  Introduction

   This document revises the RFC 3775 rules on how Alternate Care-of
   Address option is processed [RFC3775] 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].

   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].  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] for privacy reasons.
   However, given the existence of an IPsec SPI, sequence number, and



Arkko                    Expires August 28, 2008                [Page 2]

 
Internet-Draft                Alt-CoA Check                February 2008


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

   Implementations running on multiple cards of a distributed system may
   have a need to use a different addresses at different times.  For
   instance, a control process in a blade based architecture may exist
   at one part of the system in one IP address while the payload packets
   are handled in another part.  Such implementations are not typical of
   actual mobile nodes, however, and would be more likely to appear in
   situations such as high end Proxy Mobile IPv6 agents
   [I-D.ietf-netlmm-proxymip6].  In these situations if the given
   implementation architecture can not internally route packets to the
   right part of the system, the special use of addresses appears to be
   something that could be allowed by configuration.

   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.  In those rare cases where the checks specified in
   this document are not appropriate they can be turned off by
   configuration.




Arkko                    Expires August 28, 2008                [Page 3]

 
Internet-Draft                Alt-CoA Check                February 2008


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


.  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.
   The Binding Acknowledgement is sent as specified in RFC 3775 Section 
   9.5.4.  Note that this implies that the Binding Acknowledgement
   message is sent to the source address of the Binding Update packet
   (assuming the source address was a unicast address).

   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.


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

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




Arkko                    Expires August 28, 2008                [Page 4]

 
Internet-Draft                Alt-CoA Check                February 2008


.  IANA Considerations

   A new Status Code in the Mobile IPv6 Parameters registry needs to be
   allocated to "mismatching source address" (Section 3).


.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

6.2.  Normative References

   [RFC3776]  Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
              Protect Mobile IPv6 Signaling Between Mobile Nodes and
              Home Agents", RFC 3776, June 2004.

   [RFC4068]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
              July 2005.

   [RFC4225]  Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
              Nordmark, "Mobile IP Version 6 Route Optimization Security
              Design Background", RFC 4225, December 2005.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [I-D.ietf-netlmm-proxymip6]
              Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6",
              draft-ietf-netlmm-proxymip6-07 (work in progress),
              November 2007.


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.  Note that this



Arkko                    Expires August 28, 2008                [Page 5]

 
Internet-Draft                Alt-CoA Check                February 2008


   also affects indirectly network mobility as specified in [RFC3963].


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

   Jari Arkko
   Ericsson
   Jorvas  02420
   Finland

   Email: jari.arkko@piuha.net
































Arkko                    Expires August 28, 2008                [Page 6]

 
Internet-Draft                Alt-CoA Check                February 2008


Full Copyright Statement

   Copyright (C) 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Arkko                    Expires August 28, 2008                [Page 7]