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