One document matched: draft-dupont-mipv6-3bombing-00.txt

Internet Engineering Task Force                         Francis Dupont
INTERNET DRAFT                                       GET/ENST Bretagne
Expires in August 2004                                   February 2004


            A note about 3rd party bombing in Mobile IPv6

                <draft-dupont-mipv6-3bombing-00.txt>



Status of this Memo
   
   This document is an Internet Draft and is in full conformance
   with all provisions of Section 10 of RFC 2026.

   This document is an Internet-Draft.  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.

   Distribution of this memo is unlimited.

Abstract

   Mobile IPv6 [1] 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.


draft-dupont-mipv6-3bombing-00.txt                            [Page 1]
^L
INTERNET-DRAFT        3rd party bombing and MIPv6        February 2004


1. Introduction

   The standard reflection attack is based on the "bombing" of a
   3rd party, the victim, by a reflector:
    - the attacker A sends requests to the reflector R using as
      its source address in requests the address of the victim V
    - the reflector R sends (large) answers to V.
   In the mobile IPv6 context, the attacker is a mobile node,
   the reflector a correspondent node (common one or the home agent).

   There are two basic defenses against the reflection attack:
    - ingress filtering [2], 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 [3].

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

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


draft-dupont-mipv6-3bombing-00.txt                            [Page 2]
^L
INTERNET-DRAFT        3rd party bombing and MIPv6        February 2004


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 [5]) by the working group
   which decided:

   "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 reflection attack.


draft-dupont-mipv6-3bombing-00.txt                            [Page 3]
^L
INTERNET-DRAFT        3rd party bombing and MIPv6        February 2004


   When the return routability procedure is used with an alternate
   care-of address, it is applied to the right address (issue 5 [6]).
   When some other mechanisms is used, usually a longer term one,
   either a standard return routability check must be specified,
   using a third packet (aka a hand-shake) repeating a cookie from
   the binding acknowledgment, 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
   accept "hidden" care-of addresses. As the goal of these ways is
   to be more efficient than the return routability check, IMHO their
   specifications must forbid alternate care-of address options which
   carry different addresses than source addresses of IPv6 headers.

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 [7] when this
   is both unnecessary and of course against the idea of optimization.

6. Normative References

   [1] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6",
       draft-ietf-mobileip-ipv6-24.txt, June 2003.

7. Informative References

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

   [3] F. Dupont, J-J. Bernard, "Transient pseudo-NAT attacks or how
       NATs are even more evil than you believed",
       draft-dupont-transient-pseudonat-02.txt, October 2003.


draft-dupont-mipv6-3bombing-00.txt                            [Page 4]
^L
INTERNET-DRAFT        3rd party bombing and MIPv6        February 2004


   [4] F. Le & all, "Mobile IPv6 Authentication, Authorization, and
       Accounting Requirements",
       draft-le-aaa-mipv6-requirements-02.txt, April 2003.

   [5] A. Yegin, J. Arkko, F. Dupont & all, "MIPv6 issue 34: CoA test
       also for home registrations? (Rejected, included in draft 18)",
   http://users.piuha.net/jarkko/publications/mipv6/issues/issue34.txt

   [6] J. Arkko (ed), "MIPv6 issue 5: Alternative-CoA usage rules
       (Adopted, included in draft 17)",
   http://users.piuha.net/jarkko/publications/mipv6/issues/issue5.txt

   [7] W. Haddad, F. Dupont, L. Madour, S. Krishnan, S. D. Park,
       "Optimizing Mobile IPv6 (OMIPv6)",
       draft-haddad-mipv6-omipv6-01.txt, February 2004.

8. Author's Address

   Francis Dupont
   ENST Bretagne
   Campus de Rennes
   2, rue de la Chataigneraie
   CS 17607
   35576 Cesson-Sevigne Cedex
   FRANCE
   Fax: +33 2 99 12 70 30
   EMail: Francis.Dupont@enst-bretagne.fr


draft-dupont-mipv6-3bombing-00.txt                            [Page 5]