[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
Network Working Group                                          F. Dupont
Internet-Draft                                                    Point6
Expires: July 11, 2005                                  January 10, 2005

             A note about 3rd party bombing in Mobile IPv6

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 11, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   Mobile IPv6 introduces some new kinds of reflection attacks, as known
   as 3rd party bombing.  This memo analyses these attacks and makes
   some recommendations: the goal is to avoid anything, including in new
   optimized mechanisms, which can make the life of bad guys easier.

1.  Introduction

   The standard reflection attack is based on the "bombing" of a 3rd

Dupont                   Expires July 11, 2005                  [Page 1]

Internet-Draft        3rd party bombing and MIPv6           January 2005

   party, the victim, by a reflector:
   -  the attacker A sends requests to the reflector R using the address
      of the victim V as the source address of requests
   -  the reflector R sends (large) answers to V.
   In the mobile IPv6 [RFC3775] context, the attacker is a mobile node,
   the reflector a correspondent node (a common one or the home agent).

   There are two basic defenses against the reflection attack:
   -  ingress filtering [BCP38] (improved in [BCP84]), i.e., checking
      that source addresses are topologically correct
   -  all protocols which needs some kind of positive feedback from
      peers, as TCP or RTP/RTCP.
   As a correspondent node sees two addresses (a transient care-of
   address and the home address) per mobile node, it is clear that
   mobile IPv6 can add new opportunities to reflection attacks...

2.  Analysis

   There are three different kinds of reflection attacks using mobile
   IPv6 mechanisms, one for each mode of operation: triangular routing,
   bidirectional tunneling and routing optimization.

   Note that the attack is always from the mobile node itself, i.e., no
   intermediate node can successfully modify packets in transit to
   launch an attack as in the transient pseudo-nat attack

   At the opposite, a local / visited network access control with an AAA
   architecture [ID.aaa-mipv6-requirements] or an equivalent can give
   some real guarantees about a care-of address, i.e., something better
   than just trusting mobile nodes.

   The basic argument of this document is the ingress filtering is right
   defense against reflection attacks and similar threats like address
   stealing and network bombing.

2.1  Triangular routing

   In this case the mobile node sends packets carrying in the home
   address option a fake home address.  The correspondent node sends
   back traffic to this home address.  In order to avoid a very
   dangerous attack (bombing traffic has no trace of the attacker) the
   mobile IPv6 specifications [RFC3775] mandates the verification of
   home address options:
   -  when a packet with a home address option matches a binding cache
      entry it is accepted, but routing optimization is active: this
      case will be analyzed further.

Dupont                   Expires July 11, 2005                  [Page 2]

Internet-Draft        3rd party bombing and MIPv6           January 2005

   -  when a proper IPsec security association exists, but in this case
      the home address is proven.
   So there is no reflection attack issue with triangular routing.

2.2  Bidirectional tunneling

   This mode is the basic one: all traffic from or to the mobile node
   goes through a bidirectional tunnel between the mobile node and its
   home agent.

   In order to launch a reflection attack the mobile node has to put a
   fake care-of address in binding updates sent to its home agent (home
   registrations).  The home agent does not perform a routing
   routability check, i.e., it does not check if the mobile node is
   really reachable at its current care-of address.  This point was
   discussed (issue 34 [ISSUE34]) by the mobileip working group which

   "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 registration of a fake care-of address diverts all the
   traffic to the mobile node via the home agent and at least 40 octets
   is added to each packet, so for an attacker this attack is more
   effective than the next one.

2.3  Routing optimization

   The last mode is the routing optimization: binding updates sent by
   the mobile node create or update binding cache entries on the
   correspondent node.  A routing header of type 2 is added to each
   packet to the mobile node with its home address, so the extra
   information uses 24 octets and reveals the home address.

   The reflection attack in the routing optimization case uses fake
   care-of addresses in binding updates sent from the mobile node to the
   correspondent node.  Usually the care-of address is in the source
   address field of the IPv6 header but it can be, with a different
   value, in an alternate care-of address option too.  So the only
   security issue can come from this option because a fake care-of
   address in the IPv6 header is not a different case than a fake source
   address, i.e., the routing optimization does not modify the basic

Dupont                   Expires July 11, 2005                  [Page 3]

Internet-Draft        3rd party bombing and MIPv6           January 2005

   reflection attack.

   When the return routability procedure is used with an alternate
   care-of address, it is applied to the right address (issue 5
   [ISSUE5]).  When some other mechanisms is used, usually a longer term
   one, either a return routability check must be performed, using a
   third packet (aka a hand-shake) repeating a cookie from the binding
   acknowledgment [ID.mipv6-rrcookie] or binding updates with different
   care-of addresses in the IPv6 header and in the alternate care-of
   address option must be refused.

3.  Conclusion

   We recommend that alternative ways to build security associations to
   protect signaling between mobile and correspondent nodes do not
   blindly accept "hidden" care-of addresses.  As the goal of these ways
   is to be more efficient than the return routability procedure, IMHO
   their specifications must forbid alternate care-of address options
   which carry different addresses than source addresses of IPv6

4.  Security Considerations

   This goal of this document is to verify that mobile IPv6 mechanisms
   cannot be misused to make reflection attacks easier.  As the return
   routability is not considered by many people as very safe or
   efficient, some new ways to build security associations to protect
   mobile IPv6 signaling are likely to appear, so they should be
   carefully designed...

5.  Acknowledgments

   Some persons stressed Wassim Haddad to add some defense against
   reflection attacks to his optimized mobile IPv6 [ID.mipv6-omipv6]
   when this is both unnecessary and of course against the idea of

   Pekka Savola raised our attention about [BCP84] which improved
   ingress filtering in multi-homed environments.

6.  References

6.1  Normative References

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

Dupont                   Expires July 11, 2005                  [Page 4]

Internet-Draft        3rd party bombing and MIPv6           January 2005

6.2  Informative References

   [BCP38]    Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", RFC 2827, BCP 38, May 2000.

   [BCP84]    Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", RFC 3704, BCP 84, March 2004.

              Faccin, S., Le, F., Patil, B., Perkins, C., Dupont, F.,
              Laurent-Maknavicius, M. and J. Bournelle, "Mobile IPv6
              Authentication, Authorization, and Accounting
              Requirements", draft-le-aaa-mipv6-requirements-03.txt
              (work in progress), February 2004.

              Haddad, W., Dupont, F., Madour, L., Krishnan, S. and S.
              Park, "Optimizing Mobile IPv6 (OMIPv6)",
              draft-haddad-mipv6-omipv6-01.txt (work in progress),
              February 2004.

              Dupont, F. and J-M. Combes, "Care-of Address Test for
              MIPv6 using a State Cookie",
              draft-dupont-mipv6-rrcookie-00.txt (work in progress),
              January 2005.

              Dupont, F. and J-J. Bernard, "Transient pseudo-NAT attacks
              or how NATs are even more evil than you believed",
              draft-dupont-transient-pseudonat-04.txt (work in
              progress), June 2004.

   [ISSUE34]  Yegin, A., Arkko, J. and F. Dupont, "MIPv6 issue 34: CoA
              test also for home registrations? (Rejected, included in
              draft 18)", May 2004,

   [ISSUE5]   Arkko, J., Ed., "MIPv6 issue 5: Alternative-CoA usage
              rules (Adopted, included in draft 17)", May 2004,

Dupont                   Expires July 11, 2005                  [Page 5]

Internet-Draft        3rd party bombing and MIPv6           January 2005

Author's Address

   Francis Dupont
   c/o GET/ENST Bretagne
   2 rue de la Chataigneraie
   CS 17607
   35576 Cesson-Sevigne Cedex

   Fax:   +33 2 99 12 70 30
   EMail: Francis.Dupont@enst-bretagne.fr

Dupont                   Expires July 11, 2005                  [Page 6]

Internet-Draft        3rd party bombing and MIPv6           January 2005

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Dupont                   Expires July 11, 2005                  [Page 7]