idnits 2.17.1 draft-dupont-ipv6-rfc3041harmful-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2004) is 7255 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3041 (ref. '1') (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3513 (ref. '3') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2462 (ref. '4') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2068 (ref. '7') (Obsoleted by RFC 2616) Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Francis Dupont 2 INTERNET DRAFT GET/ENST Bretagne 3 Expires in December 2004 Pekka Savola 4 CSC/FUNET 5 June 2004 7 RFC 3041 Considered Harmful 9 11 Status of this Memo 13 This document is an Internet Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Distribution of this memo is unlimited. 35 Abstract 37 The purpose of the privacy extensions for stateless address 38 autoconfiguration [1] is to change the interface identifier (and 39 the global-scope addresses generated from it) over time in order 40 to make it more difficult for eavesdroppers and other information 41 collectors to identify when different addresses used in different 42 transactions actually correspond to the same node. 44 Current Distributed Denial of Service (DDoS) [2] attacks employ 45 forged source addresses which can also be in the same prefixes 46 than the real addresses of the compromised nodes used for attacks. 47 Indeed, network ingress filtering defeats DDoS using "random" 48 forged source addresses. 50 The issue developed in this document is that the behavior of a 51 compromised node used as source in a DDoS attack with "in-prefix" 52 spoofed source address and the behavior of nodes using temporary 53 addresses at high rate can not be distinguished. This could make 54 future defenses against DDoS attacks very hard. 56 1. Introduction 58 Last IPv6 addressing architecture document [3] defines the modified 59 EUI-64 format for interface identifiers. This format is mandatory 60 for all unicast addresses, except those that start with binary 61 value 000 and is 64 bit long with two special bits: 62 - the universal/local "u" bit which indicates whether the scope of 63 the identifier is global or local. 64 - the individual/group "g" bit inherited from IEEE specification. 66 In practice interface identifiers enter in one of these categories: 67 - global scoped identifiers derived from a built-in interface 68 hardware identifier like an IEEE MAC-48 address. 69 - manually assigned small identifiers (::1, ::2, ...) which have, 70 of course, a local scope. 71 - randomly generated identifiers (with a local scope, used when 72 the first category of identifiers raises a privacy concern) 73 - identifiers derived from a key like Statically Unique and 74 Cryptographically Verifiable identifiers [5] (also with a local 75 scope but bound to a key with a provable ownership). 77 The RFC 3041 (privacy extensions) [1] defines the management of 78 randomly generated identifiers and, in the real world, all of them. 80 Interface identifiers are used in the stateless address 81 autoconfiguration [4] to create link-local addresses (in all cases) 82 and to create global and site-local addresses (for hosts from 83 prefix information options in router advertisements). 85 2. Privacy Extensions 87 The privacy extensions document addresses claimed privacy concerns 88 with globally unique and/or persistent interface identifiers. 90 The basic issue is when a constant identifier is reused over an 91 extended period of time and in multiple independent activities, 92 it becomes possible for that identifier to be used to correlate 93 seemingly unrelated activity. 95 Note that the interface identifier is usually only the half of the 96 whole address, and to change the interface identifier when the 97 prefix remains the same will not improve the privacy. 99 There are only two cases where privacy extensions can be justified: 100 where the link has a very high number of nodes or where the link 101 (and the prefix(es)) changes from time to time. In the second case 102 a fresh interface identifier gives a whole new address 103 which can not be tracked, but an interface identifier change 104 between two movements should give only complexity with little 105 benefit. 107 How little benefit the is to be had depends mainly on how frequently 108 the prefix changes. For example, if ISPs assign a static prefix to 109 a customer, changing the interface identifier never really helps. 110 However, if ISPs assign a dynamic prefix to a customer, how often 111 the prefix changes (compared to the rate at which new interface 112 identifiers are generated) restricts the applicability of the 113 privacy extensions. For example, if the prefix changes about once 114 a month, practically the users will be trackable; on the other 115 hand, if the prefix changes once a day it could be argued the 116 privacy extensions could provide some extra privacy in that 117 timeframe. In the latter case, the goal is to have a dynamic prefix 118 out of a large dynamic prefix address block, so it is unnoticeable 119 to the observers when a different user from the bigger address 120 block is using the prefix under observation and when the same user 121 has generated a new interface identifier. 123 Our argument is that in the second case the prefix(es) and the 124 interface identifier should be changed at the same time, or at least 125 that the prefix(es) should be changed often enough when compared to 126 the interface identifier change frequency. 128 3. "In-Prefix" Source Addresses Spoofing 130 Distributed Denial of Services (DDoS) attacks are a variant of 131 Denial of Service attacks where the attackers use a large number of 132 compromised hosts in poorly managed domains to flood aimed targets 133 with forged packets. In some cases, the amount of traffic is enough 134 to overload network infrastructures near the targets. 136 In order to hide the real addresses of compromised hosts, to defeat 137 easy defenses like rate limitation on detected flows, to avoid 138 returned traffic, etc, DDoS attacks employ forged, rapidly changing 139 source addresses. When spoofed source addresses are randomly chosen, 140 ingress filtering [2] can check if they are topologically plausible 141 and drop forged packets. Ingress filtering, especially based on 142 unicast Reverse Path Forwarding Forwarding (uRPF) checking, has been 143 enough deployed in some networks in the today Internet to encourage 144 the attackers to also find different ways to spoof addresses to 145 perform effective DDoS attacks. 147 But ingress filtering is not effective against "in-prefix" source 148 address spoofing where forged addresses are derived from real ones 149 by only changing the last bits so they are likely to be topologically 150 correct. Administrators of systems under attacks have the choice 151 between accepting some traffic from fake sources and filtering out 152 too much traffic including legitimate traffic from close to the 153 apparent attack source, i.e. meaning a denial of service for those 154 legitimate sources. Of course, IPv6 gives the attackers even more 155 bits to play with (64 bits for a link, 80 for a site); practically 156 e.g. rate limiting by address must be changed to rate limiting 157 by prefix. 159 To summarize, filtering works only when it is possible and/or easy 160 to recognize legitimate packets from forged packets. In some 161 cases attacks can be detected at some places (it should always be 162 the case near the targets) but again defensive actions need a good 163 selection criterion or they become themselves denial of service 164 attacks. 166 4. Temporary vs. Forged Source Addresses 168 Privacy extensions create new temporary addresses with an additive 169 rate, i.e. with 1000 nodes and a rate by node of one new temporary 170 address per day (the default rate [1]) the resulting rate is one 171 new address every 90 seconds. So, where changing the temporary 172 addresses makes sense, the uses of temporary or forged addresses 173 are very hard to distinguish. 175 Of course, solutions like per address network access control and 176 outbound traffic filtering are both unlikely in poorly managed 177 sites where the attackers find hosts to compromise, and are not 178 very compatible with user privacy concerns. 180 So we recommend: 181 - the use of temporary addresses should be disabled by default 182 (as in the revision of RFC 3041 [6]). 183 - implementations should be updated as soon as possible when 184 their default is to use temporary addresses. 185 - next revisions of RFC 3041 should address the tradeoff 186 between temporary and forged addresses. 187 - schemes for cryptographically generated addresses (CGAs) 188 should take the issue described in this document into account. 189 - A new revision of RFC 3041 should be finished as soon as 190 possible and released to update RFC 3041 to avoid further 191 damage. 193 4. Security Considerations 195 This document proposed to fill the Security Considerations 196 section of revisions [6] of RFC 3041 which is currently empty. 198 Cryptographically generated addresses (CGAs) are by definition 199 verifiable but verifying a CGA can be 200 an expensive operation and if different levels of verification 201 are possible, levels which provide good trust are likely to 202 be more expensive. So if a network access control should check 203 CGAs, the design must avoid to transform it into an easy target 204 for Denial of Service attacks. 206 It should also be noted that there are a lot more ways to collect 207 privacy information than watching the addresses (e.g. User Agent 208 logging in HTTP [7]); these may not enough to make conclusions 209 about the node in itself, but could be used, in part, when trying 210 to tell whether two addresses might belong to the same node. 212 One can argue the usage of privacy features should be 213 unobservable [8]. 215 5. Acknowledgments 217 The nature of current DDoS attacks was described by Stanislav 218 Shaluno during an ingress filtering and home address option 219 thread in mobile-ip and ipv6 IETF WG mailing-lists. 221 Thomas Narten and Richard Draves tried to explain exactly 222 what kind of privacy temporary addresses can (not) provide. 223 Unfortunately this answer to complaints about IEEE derived 224 interface identifiers and privacy is not IMHO technically 225 far more well-founded than the complaints themselves; but 226 there was not the time for a real anonymity device (the 227 future work section of the RFC 3041 revision [6] finishes 228 by the same kind of considerations). 230 Alberto Escudero-Pascual suggested to have a look on the 231 observability of privacy extensions [8]. 233 6. Normative References 235 [1] T. Narten, R. Draves, "Privacy Extensions for Stateless Address 236 Autoconfiguration in IPv6", RFC 3041, January 2001. 238 [2] P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating 239 Denial of Service Attacks which employ IP Source Address Spoofing", 240 RFC 2827 / BCP 38, May 2000. 242 [3] R. Hinden, S. Deering, "Internet Protocol Version 6 (IPv6) 243 Addressing Architecture", RFC 3513, April 2003. 245 [4] S. Thomson, T. Narten, "IPv6 Stateless Address 246 Autoconfiguration", RFC 2462, December 1998. 248 7. Informative References 250 [5] G. Montenegro, C. Castelluccia, "SUCV Identifiers and 251 Addresses", draft-montenegro-sucv-03.txt (expired), July 2002. 253 [6] T. Narten, R. Draves, "Privacy Extensions for Stateless Address 254 Autoconfiguration in IPv6", revision of RFC 3041, 255 draft-ietf-ipngwg-temp-addresses-v2-00.txt (expired), July 2001. 257 [7] R. Fielding, et al., "Hypertext Transfer Protocol -- HTTP/1.1", 258 RFC 2068, January 1997. 260 [8] A. Escudero, "Requirements for unobservability of privacy 261 extension in IPv6", RVK02, Stockholm, June 2002. 263 8. Author's Addresses 265 Francis Dupont 266 ENST Bretagne 267 Campus de Rennes 268 2, rue de la Chataigneraie 269 CS 17607 270 35576 Cesson-Sevigne Cedex 271 FRANCE 272 Fax: +33 2 99 12 70 30 273 EMail: Francis.Dupont@enst-bretagne.fr 275 Pekka Savola 276 CSC/FUNET 277 Espoo, Finland 278 EMail: psavola@funet.fi