[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02 03 04 05                                             
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

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

   Distribution of this memo is unlimited.


   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

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
   Fax: +33 2 99 12 70 30
   EMail: Francis.Dupont@enst-bretagne.fr

draft-dupont-ipv6-rfc3041harmful-00.txt                       [Page 5]