idnits 2.17.1 draft-gont-taps-address-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 21, 2018) is 2227 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6724' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'I-D.gont-6man-address-usage-recommendations' is defined on line 455, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-05) exists of draft-gont-6man-address-usage-recommendations-04 == Outdated reference: A later version (-04) exists of draft-gont-6man-non-stable-iids-03 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-ula-usage-considerations-02 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Services (taps) Working Group F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Intended status: Informational G. Gont 5 Expires: September 22, 2018 SI6 Networks 6 M. Garcia Corbo 7 SITRANS 8 C. Huitema 9 Private Octopus Inc. 10 March 21, 2018 12 Problem Statement Regarding IPv6 Address Usage 13 draft-gont-taps-address-analysis-00 15 Abstract 17 This document analyzes the security, privacy, and interoperability 18 implications of IPv6 addresses based on a number of properties (such 19 as address scope, stability, and usage type). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 22, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. IPv6 Address Properties . . . . . . . . . . . . . . . . . . . 3 59 4.1. Address Scope Considerations . . . . . . . . . . . . . . 3 60 4.2. Address Stability Considerations . . . . . . . . . . . . 4 61 4.3. Usage Type Considerations . . . . . . . . . . . . . . . . 5 62 5. Issues Associated with Sub-optimal IPv6 Address Usage . . . . 7 63 5.1. Correlation of Network Activity . . . . . . . . . . . . . 7 64 5.2. Testing for the Presence of Node in the Network . . . . . 7 65 5.3. Unexpected Address Discovery . . . . . . . . . . . . . . 7 66 5.4. Availability Outside the Expected Scope . . . . . . . . . 8 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 9.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 IPv6 addresses may differ in a number of properties, such as address 78 scope (e.g. link-local vs. global), stability (e.g. stable addresses 79 vs. temporary addresses), and intended usage type (outgoing 80 communications vs. incomming communications). While often 81 overlooked, these properties have impact on areas such as security, 82 privacy, and interoperability. 84 This document analyzes the impact of a number of properties of IPv6 85 addresses on areas such as security and privacy, and analyzes how 86 IPv6 addresses are curently generated and employed by different 87 operating systems and applications. 89 2. Terminology 91 This document employs the definitions of "public address", "stable 92 address", and "temporary address" from Section 2 of [RFC7721]. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 3. Background 100 Predictable IPv6 addresses result in a number of security and privacy 101 implications. For example, [Barnes2012] discusses how patterns in 102 network prefixes can be leveraged for IPv6 address scanning. On the 103 other hand, [RFC7707], [RFC7721] and [RFC7217] discuss the security 104 and privacy implications of predictable IPv6 Interface Identifiers 105 (IIDs). 107 Given the aforementioned previous work in this area, and the formal 108 specification update produced by [RFC8064], we expect (and assume in 109 the rest of this document) that implementations have replaced any 110 schemes that produce predictable addresses with alternative schemes 111 that avoid such patterns (e.g., RFC7217 in replacement of the 112 traditional SLAAC addresses that embed link-layer addresses). 114 4. IPv6 Address Properties 116 There are three parameters that affect the security and privacy 117 properties of an IPv6 address: 119 o Scope 121 o Stability 123 o Usage type (client-like "outgoing connections" vs. server-like 124 "incoming connections") 126 Section 4.1, Section 4.2, and Section 4.3 discuss the security and 127 privacy implications (and associated tradeoffs) of the scope, 128 stability and usage type properties of IPv6 addresses, respectively. 130 4.1. Address Scope Considerations 132 The IPv6 address scope can, in some scenarios, limit the attack 133 exposure of a node as a result of the implicit isolation provided by 134 a non-global address scope. For example, a node that only employs 135 link-local addresses may, in principle, only be exposed to attack 136 from other nodes in the local link. Hosts employing only Unique 137 Local Addresses (ULAs) may be more isolated from attack than those 138 employing Global Unicast Addresses (GUAs), assuming that proper 139 packet filtering is enforced at the network edge. 141 The potential protection provided by a non-global addresses should 142 not be regarded as a complete security strategy, but rather as a form 143 of "prophylactic" security (see 144 [I-D.gont-opsawg-firewalls-analysis]). 146 We note that the use of non-global addresses is usually limited to a 147 reduced type of applications/protocols that e.g. are only meant to 148 operate on a reduced scope, and hence their applicability may be 149 limited. 151 A discussion of ULA usage considerations can be found in 152 [I-D.ietf-v6ops-ula-usage-considerations]. 154 4.2. Address Stability Considerations 156 The stability of an address has two associated security/privacy 157 implications: 159 o Ability of an attacker to correlate network activity 161 o Exposure to attack 163 For obvious reasons, an address that is employed for multiple 164 communication instances allows the aforementioned network activities 165 to be correlated. The longer an address is employed (i.e., the more 166 stable it is), the longer such correlation will be possible. In the 167 worst-case scenario, a stable address that is employed for multiple 168 communication instances over time will allow all such activities to 169 be correlated. On the other hand, if a host were to generate (and 170 eventually "throw away") one new address for each communication 171 instance (e.g., TCP connection), network activity correlation would 172 be mitigated. 174 NOTE: 175 The use of constant IIDs (as in traditional SLAAC) result in 176 addresses that, while not constant as a whole (since the prefix 177 changes), contain a globally-unique value that leaks out the node 178 "identity". Such addresses result in the worst possible security 179 and privacy implications, and their use has been deprecated by 180 [RFC8064]. 182 Typically, when it comes to attack exposure, the longer an address is 183 employed the longer an attacker is exposed to attacks (e.g. an 184 attacker has more time to find the address in the first place 185 [RFC7707]). While such exposure is traditionally associated with the 186 stability of the address, the usage type of the address (see 187 Section 4.3) may also have an impact on attack exposure. 189 A popular approach to mitigate network activity correlation is the 190 use of "temporary addresses" [RFC4941]. Temporary addresses are 191 typically configured and employed along with stable addresses, with 192 the temporary addresses employed for outgoing communications, and the 193 stable addresses employed for incoming communications. 195 NOTE: 196 Ongoing work [I-D.gont-6man-non-stable-iids] aims at updating 197 [RFC4941] such that temporary addresses can be employed without 198 the need to configure stable addresses. 200 We note that the extent to which temporary addresses provide improved 201 mitigation of network activity correlation and/or reduced attack 202 exposure may be questionable and/or limited in some scenarios. For 203 example, a temporary address that is reachable for, say, a few hours 204 has a questionable "reduced exposure" (particularly when automated 205 attack tools do not typically require such a long period of time to 206 complete their task). Similarly, if network activity can be 207 correlated for the life of such address (e.g., on the order of 208 several hours), such period of time might be long enough for the 209 attacker to correlate all the network activity he is meaning to 210 correlate. 212 In order to better mitigate network activity correlation and/or 213 possibly reduce host exposure, an implementation might want to either 214 reduce the preferred lifetime of a temporary address, or even better, 215 generate one new temporary address for each new transport protocol 216 instance. However, the associated lifetime/stability of an address 217 may have a negative impact on the network. For example, if a node 218 were to employ "throw away" IPv6 addresses, or employ temporary 219 addresses [RFC4941] with a short preferred lifetime, local nodes 220 might need to maintain too many entries in their Neighbor Cache, and 221 a number of devices (possibly enforcing security policies) might also 222 need to cope with such additional state. 224 Additionally, enforcing a maximum lifetime on IPv6 addresses may 225 cause long-lived TCP connections to fail. For example, an address 226 becoming "Invalid" (after transitioning through the "Preferred" and 227 "Deprecated" states) would cause the TCP connections employing them 228 to break. This, in turn, would cause e.g. long-lived SSH sessions to 229 break/fail. 231 In some scenarios, attack exposure may be reduced by limiting the 232 usage of temporary addresses to outgoing connections, and prevent 233 such addresses from being used for incoming connections (please see 234 Section 4.3). 236 4.3. Usage Type Considerations 238 A node that employs one of its addresses to communicate with an 239 external server (i.e., to perform an "outgoing connection") may cause 240 such address to become exposed to attack. For example, once the 241 external server receives an incoming connection, the corresponding 242 server might launch an attack against the aforementioned address. A 243 real-world instance of this type of scenario has been documented in 244 [Hein]. 246 However, we note that employing an IPv6 address for outgoing 247 communications need not increase the exposure of local services to 248 other parties. For example, nodes could employ temporary addresses 249 only for outgoing connections, but not for incoming connections. 250 Thus, external nodes that learn about client's addresses could not 251 really leverage such addresses for actively contacting the clients. 253 There are multiple ways in which this could possibly be achieved, 254 with different implications. Namely: 256 o Run a host-based or network-based firewall 258 o Bind services to specific (explicit) addresses 260 o Bind services only to stable addresses 262 A client could simply run a host-based firewall that only allows 263 incoming connections on the stable addresses. This is clearly more 264 of an operational way of achieving the desired functionality, and may 265 require good firewall/host integration (e.g., the firewall should be 266 able to tell stable vs. temporary addresses), may require the client 267 to run additional firewall software for this specific purpose, etc. 268 In other scenarios, a network-based firewall could be configured to 269 allow outgoing communications from all internal addresses, but only 270 allow incoming communications to stable addresses. For obvious 271 reasons, this is generally only applicable to networks where incoming 272 communications are allowed to a limited number of hosts/servers. 274 Services could be bound to specific (explicit) addresses, rather than 275 to all locally-configured addresses. However, there are a number of 276 short-comings associated with this approach. Firstly, an application 277 would need to be able to learn all of its addresses and associated 278 stability properties, something that tends to be non-trivial and non- 279 portable, and that also makes applications protocol-dependent, 280 unnecessarily. Secondly, the BSD Sockets API does not really allow a 281 socket to be bound to a subset of the node's addresses. That is, 282 sockets can be bound to a single address or to all available 283 addresses (wildcard), but not to a subset of all the configured 284 addresses. 286 Binding services only to stable addresses provides a clean separation 287 between addresses employed for client-like outgoing connections and 288 server-like incoming connections. However, we currently lack an 289 appropriate API for nodes to be able to specify that a socket should 290 only be bound to stable addresses. 292 5. Issues Associated with Sub-optimal IPv6 Address Usage 294 5.1. Correlation of Network Activity 296 As discussed in [RFC7721], a node that reuses an IPv6 address for 297 multiple communication instances would allow the correlation of such 298 network activities. This could be the case when the same IPv6 299 address is employed by several instances of the same application 300 (e.g., a browser in "privacy" mode and a browser in "normal" mode), 301 or when the same IPv6 address is employed by two different 302 applications on the same node (e.g., a browser in "privacy" mode, and 303 an email client). 305 Particularly for privacy-sensitive applications, an application or 306 system might want to limit the usage of a given IPv6 address to a 307 single communication instance, a single application, a single user on 308 the system, etc. However, given current APIs, this is practically 309 impossible. 311 5.2. Testing for the Presence of Node in the Network 313 The stable addresses recommended in [RFC8064] use stable IIDs defined 314 in [RFC7217]. One key part of that algorithm is that if a device 315 connects to a given network at different times, it will always 316 configure the same IPv6 addresses on that network. If the device 317 hosts a service ready to accept connections on that stable address, 318 adversaries can test the presence of the device on the network by 319 attempting connections to that stable address. Stable addresses used 320 by listening services will thus enable testing whether a specific 321 device is returning to a particular network, which in a number of 322 cases might be considered a privacy issue. 324 5.3. Unexpected Address Discovery 326 Systems like DNS-Based Service Discovery [RFC6763] allow clients to 327 discover services within a limited scope, that can be defined by a 328 domain name. These services are not advertised outside of that 329 scope, and thus do not expect to be discovered by random parties on 330 the Internet. However, such services may be easily discoverable if 331 they listen for connections to IPv6 addresses that a client process 332 also uses as source address when connecting to remote servers. 334 NOTE: 335 An example of such unexpected discovery is described in [Hein]. A 336 network manager observed scanning traffic directed at the 337 temporary addresses of local devices. The analysis in [Hein] 338 shows that the scanners learned the addresses by observing the 339 device contact an NTP service ([RFC5905]). The remote scanning 340 was possible because the local devices were also accepting 341 connections directed to the temporary addresses. 343 It should be obvious from the example that the "attack surface" of 344 the services is increased because they are bond to the same IPv6 345 addresses that are also used by clients for outgoing communications 346 with remote systems. But the overlap between "client" and "server" 347 addresses is only one part of the problem. Suppose that a device 348 hosts both a video game and a home automation application. The video 349 game users will be able to discover the IPv6 address of the game 350 server. If the home automation server listens to the same IPv6 351 addresses, it is now exposed to connection attempts by all these 352 users. That, too, increases the attack surface of the home 353 automation server. 355 5.4. Availability Outside the Expected Scope 357 The IPv6 addressing architecture [RFC4291] defines multiple address 358 scopes. In practice, devices are often configured with globally 359 reachable unicast addresses, link local addresses, and Unique Local 360 IPv6 Unicast Addresses (ULA) [RFC4193]. Availability outside the 361 expected scope happens when a service is expected to be only 362 available in some local scope, but inadvertently becomes available to 363 remote parties. That could happen for example if a service is meant 364 to be available only on a given link, but becomes reachable through 365 ULA or through globally reachable addresses, or if a service is meant 366 to be available only inside some organization's perimeter and becomes 367 reachable through globally reachable addresses. It will happen in 368 particular if a service intended for some local scope is programmed 369 to bind to "unspecified" addresses, which in practice means every 370 address configured for the device. 372 6. IANA Considerations 374 There are no IANA registries within this document. The RFC-Editor 375 can remove this section before publication of this document as an 376 RFC. 378 7. Security Considerations 380 The security and privacy implications associated with the 381 predictability and lifetime of IPv6 addresses has been analyzed in 382 [RFC7217] [RFC7721], and [RFC7707]. This document complements and 383 extends the aforementioned analysis by considering other IPv6 384 properties such as the address scope and address usage type, and the 385 associated tradeoffs. 387 8. Acknowledgements 389 The authors would like to thank (in alphabetical order) Francis 390 Dupont, Tatuya Jinmei, Erik Kline, Tommy Pauly, and Dave Thaler for 391 providing valuable comments on earlier versions of this document. 393 Fernando Gont would like to thank Spencer Dawkins for his guidance. 395 9. References 397 9.1. Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, 401 DOI 10.17487/RFC2119, March 1997, 402 . 404 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 405 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 406 . 408 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 409 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 410 2006, . 412 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 413 Extensions for Stateless Address Autoconfiguration in 414 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 415 . 417 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 418 "Network Time Protocol Version 4: Protocol and Algorithms 419 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 420 . 422 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 423 "Default Address Selection for Internet Protocol Version 6 424 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 425 . 427 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 428 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 429 . 431 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 432 Interface Identifiers with IPv6 Stateless Address 433 Autoconfiguration (SLAAC)", RFC 7217, 434 DOI 10.17487/RFC7217, April 2014, 435 . 437 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 438 "Recommendation on Stable IPv6 Interface Identifiers", 439 RFC 8064, DOI 10.17487/RFC8064, February 2017, 440 . 442 9.2. Informative References 444 [Barnes2012] 445 Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great 446 Void Smarter scanning for IPv6", ISMA 2012 AIMS-4 - 447 Workshop on Active Internet Measurements, February 2012, 448 . 451 [Hein] Hein, B., "The Rising Sophistication of Network Scanning", 452 January 2016, . 455 [I-D.gont-6man-address-usage-recommendations] 456 Gont, F., Gont, G., Corbo, M., and C. Huitema, "Problem 457 Statement Regarding IPv6 Address Usage", draft-gont-6man- 458 address-usage-recommendations-04 (work in progress), 459 October 2017. 461 [I-D.gont-6man-non-stable-iids] 462 Gont, F., Huitema, C., Krishnan, S., Gont, G., and M. 463 Corbo, "Recommendation on Temporary IPv6 Interface 464 Identifiers", draft-gont-6man-non-stable-iids-03 (work in 465 progress), March 2018. 467 [I-D.gont-opsawg-firewalls-analysis] 468 Gont, F. and F. Baker, "On Firewalls in Network Security", 469 draft-gont-opsawg-firewalls-analysis-02 (work in 470 progress), February 2016. 472 [I-D.ietf-v6ops-ula-usage-considerations] 473 Liu, B. and S. Jiang, "Considerations For Using Unique 474 Local Addresses", draft-ietf-v6ops-ula-usage- 475 considerations-02 (work in progress), March 2017. 477 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 478 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 479 . 481 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 482 Considerations for IPv6 Address Generation Mechanisms", 483 RFC 7721, DOI 10.17487/RFC7721, March 2016, 484 . 486 Authors' Addresses 488 Fernando Gont 489 SI6 Networks / UTN-FRH 490 Evaristo Carriego 2644 491 Haedo, Provincia de Buenos Aires 1706 492 Argentina 494 Phone: +54 11 4650 8472 495 Email: fgont@si6networks.com 496 URI: http://www.si6networks.com 498 Guillermo Gont 499 SI6 Networks 500 Evaristo Carriego 2644 501 Haedo, Provincia de Buenos Aires 1706 502 Argentina 504 Phone: +54 11 4650 8472 505 Email: ggont@si6networks.com 506 URI: https://www.si6networks.com 508 Madeleine Garcia Corbo 509 Servicios de Informacion del Transporte 510 Neptuno 358 511 Havana City 10400 512 Cuba 514 Email: madelen.garcia16@gmail.com 515 Christian Huitema 516 Private Octopus Inc. 517 Friday Harbor, WA 98250 518 U.S.A. 520 Email: huitema@huitema.net 521 URI: http://privateoctopus.com