Internet Engineering Task Force Francis Dupont INTERNET DRAFT ENST Bretagne Expires in August 2002 February 2002 RFC 3041 Considered Harmful 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 The purpose of the privacy extensions for stateless address autoconfiguration [1] is to change the interface identifier (and the global-scope addresses generated from it) over time in order to make it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. Current Distributed Denial of Service (DDoS) [2] attacks employ forged source addresses which are likely to be in the same prefixes than the real addresses of the compromised nodes used for attacks. Indeed, network ingress filtering defeats DDoS using "random" forged source addresses. draft-dupont-ipv6-rfc3041harmful-00.txt [Page 1] INTERNET-DRAFT RFC 3041 Considered Harmful Feb 2002 The issue developed in this document is that the behavior of a compromised node used as source in a DDoS attack with "in-prefix" spoofed source address and the behavior of nodes using temporary addresses at high rate can not be distinguished. This should make future defenses against DDoS attacks very hard. 1. Introduction Last IPv6 addressing architecture document [3] defines the modified EUI-64 format for interface identifiers. This format is mandatory for all unicast addresses, except those that start with binary value 000 and has 64 bit long with two special bits: - the universal/local "u" bit which indicates whether the scope of the identifier is global or local. - the individual/group "g" bit inherited from IEEE specification. In practice interface identifiers enter in one of these categories: - global scoped identifiers derived from a built-in interface hardware identifier like an IEEE MAC-48 address. - manually assigned small identifiers (::1, ::2, ...) which have, of course, a local scope. - randomly generated identifiers (with a local scope, used when the first category of identifiers raises a privacy concern) - identifiers derived from a key like Statically Uniq and Cryptographically Verifiable identifiers [5] (with a local scope too but bound to a key with a provable ownership). The RFC 3041 (privacy extensions) [1] defines the management of randomly generated identifiers and, in the real world, all of them. Interface identifiers are used in the stateless address autoconfiguration [4] to create link-local addresses (in all cases) and to create global and site-local addresses (for hosts from prefix informations in router advertisements). 2. Privacy Extensions The privacy extensions document addresses claimed privacy concerns with globally unique and/or persistent interface identifiers. The basic issue is when a constant identifier is reused over an extended period of time and in multiple independent activities, it becomes possible for that identifier to be used to correlate seemingly unrelated activity. Note the interface identifier is only the half of the whole address, and to change the interface identifier when the prefix remains the same shall not improve the privacy... draft-dupont-ipv6-rfc3041harmful-00.txt [Page 2] INTERNET-DRAFT RFC 3041 Considered Harmful Feb 2002 There are only two cases where privacy extensions can be justified: where the link has a very high number of nodes or where the link (and the prefix(es)) changes from time to time. In the second case a fresh interface identifier gives a whole new care-of address which can not be tracked, but an interface identifier change between two movements should give only complexity with no benefit. 3. "In-Prefix" Source Addresses Spoofing Distributed Denial of Services (DDoS) attacks are a variant of denial of services attacks where bad guys use a large number of compromised hosts in poorly managed domains to flood aimed targets with forged packets. In some cases, the amount of traffic is enough to overload network infrastructures near targets. In order to hide real addresses of compromised hosts, to defeat easy defenses like rate limitation on detected flows, to avoid returned traffic, etc, DDoS attacks employ forged changing source addresses. When spoofed source addresses are randomly chosen, ingress filtering [2] can check if they are topologically plausible and drop forged packets. Ingress filtering based on unicast Reverse Path Forwarding Forwarding (uRPF) checking seems to be enough deployed in the today Internet to make this kind of source address spoofing unattractive. But ingress filtering is not effective against "in-prefix" source address spoofing where forged addresses are derived from real ones by changing last bits so they are likely to be topologically correct and administrators of systems under attacks have the choice between to accept some traffic from fake sources and to filter out too many traffic including legitimate traffic from close to apparent attack source, i.e. a denial of service... Of course IPv6 gives more bits to play with to bad guys (64 bits for a link, 80 for a site). To summary filtering works only when it is possible and/or easy to recognize legitimate packets from forged packets. In some cases attacks can be detected at some places (it should be always the case near targets) but again defensive actions need a good selection criterion or they becomes themselves denial of services attacks. draft-dupont-ipv6-rfc3041harmful-00.txt [Page 3] INTERNET-DRAFT RFC 3041 Considered Harmful Feb 2002 4. Temporary vs. Forged Source Addresses Privacy extensions create new temporary addresses with an additive rate, i.e. with 1000 nodes and a rate by node of one new temporary address per day (the default rate [1]) the resulting rate is one new address every one minute and half. So where to change temporary addresses makes sense, the uses of temporary or forged addresses are very hard to distinguish. Of course solutions like per address network access control and outbound traffic filtering are both unlikely in poorly managed sites where bad guys find hosts to compromise, and not very compatible with user privacy concerns. So we recommend: - the use of temporary addresses should be disable by default (as in the revision of RFC 3041 [6]). - implementations should be updated as soon as possible when their default is to use temporary addresses. - next revisions of RFC 3041 should address the tradeoff between temporary and forged addresses. - schemes for cryptographically generated addresses (CGAs) should take the issue described in this document into account. 4. Security Considerations This document proposed to fill the Security Considerations section of revisions [6] of RFC 3041 which is currently empty. CGAs are by definition verifiable but to verify a CGA can be an expensive operation and if different levels of verification are possible, levels which provides good trust are likely to be more expensive. So if a network access control should check CGAs, the design must avoid to transform it into an easy target for denial of services attacks. 5. Acknowledgments The nature of current DDoS attacks was described by Stanislav Shaluno during an ingress filtering and home address option thread in mobile-ip and ipv6 IETF WG mailing-lists. draft-dupont-ipv6-rfc3041harmful-00.txt [Page 4] INTERNET-DRAFT RFC 3041 Considered Harmful Feb 2002 Thomas Narten and Richard Draves tried to explain exactly what kind of privacy temporary addresses can (not) provide. Unfortunately this answer to complaints about IEEE derived interface identifiers and privacy is not IMHO technically far more well-founded than complaints themselves... but there was not the time for a real anonymity device (the future work section of the RFC 3041 revision [6] finishes by the same kind of considerations). 6. Normative References [1] T. Narten, R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [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] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", draft-ietf-ipngwg-addr-arch-v3-07.txt (update of RFC 2373), November 2001. [4] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. 7. Informative References [5] G. Montenegro, C. Castelluccia, "SUCV Identifiers and Addresses", draft-montenegro-sucv-02.txt, November 2001. [6] T. Narten, R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", revision of RFC 3041, draft-ietf-ipngwg-temp-addresses-v2-00.txt, July 2001. 8. Author's Address Francis Dupont ENST Bretagne Campus de Rennes 2, rue de la Chataigneraie BP 78 35512 Cesson-Sevigne Cedex FRANCE Fax: +33 2 99 12 70 30 EMail: Francis.Dupont@enst-bretagne.fr draft-dupont-ipv6-rfc3041harmful-00.txt [Page 5]