idnits 2.17.1 draft-gont-6man-address-usage-recommendations-01.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 (February 28, 2017) is 2607 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 301, but not defined == Unused Reference: 'RFC2460' is defined on line 312, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-ula-usage-considerations-01 == Outdated reference: A later version (-04) exists of draft-gont-6man-non-stable-iids-00 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Intended status: Best Current Practice G. Gont 5 Expires: September 1, 2017 SI6 Networks 6 M. Garcia Corbo 7 SITRANS 8 February 28, 2017 10 IPv6 Address Usage Recommendations 11 draft-gont-6man-address-usage-recommendations-01 13 Abstract 15 This document analyzes the security and privacy implications of IPv6 16 addresses based on a number of properties such as address scope, 17 stability, and usage type. It analyzes what properties are desirable 18 for some popular scenarios, and provides advice regarding the 19 configuration and usage of such addresses. 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 http://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 1, 2017. 38 Copyright Notice 40 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Predictability Considerations . . . . . . . . . . . . . . . . 3 58 4. Address Scope Considerations . . . . . . . . . . . . . . . . 3 59 5. Address Stability Considerations . . . . . . . . . . . . . . 4 60 6. Usage Type Considerations . . . . . . . . . . . . . . . . . . 5 61 7. Advice on IPv6 Address Configuration . . . . . . . . . . . . 6 62 8. Advice on IPv6 Address Usage . . . . . . . . . . . . . . . . 7 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 12.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 IPv6 hosts typically configure a number of IPv6 addresses, which may 74 differ in multiple aspects, such as address scope and stability (e.g. 75 stable addresses vs. temporary addresses). For example, a host may 76 configure one stable and one temporary address per each 77 autoconfiguration prefix advertised on the local network. The 78 addresses to be configured typically depend on local system 79 configuration, with the aforementioned configuration being static and 80 irrespective of the network the host attaches to. 82 There are three parameters that affect the security and privacy 83 properties of an address: 85 o Scope 87 o Stability 89 o Usage type (client-like "outgoing connections" vs. server-like 90 "incoming connections") 92 Section 3, Section 4, Section 5, and Section 6 discuss the security 93 and privacy implications (and associated tradeoffs) of the scope, 94 stability and usage type properties of IPv6 addresses, respectively. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 3. Predictability Considerations 104 Predictable IPv6 addresses result in a number of security and privacy 105 implications. For example, [Barnes2012] discusses how patterns in 106 network prefixes can be leveraged for IPv6 address scanning. On the 107 other hand, [RFC7707], [RFC7721] and [RFC7217] discuss the security 108 and privacy implications of predictable IPv6 Interface Identifiers 109 (IIDs). 111 Given the aforementioned previous work in this area, and the formal 112 specification update produced by [RFC8064], we expect (and assume in 113 the rest of this document) that implementations have replaced any 114 schemes that produce predictable addresses with alternative schemes 115 that avoid such patterns (e.g., RFC7217 in replacement of the 116 traditional SLAAC addresses that embed link-layer addresses). 118 4. Address Scope Considerations 120 The IPv6 address scope can, in some scenarios, limit the attack 121 exposure of a node as a result of the implicit isolation provided by 122 a non-global address scope. For example, a node that only employs 123 link-local addresses may, in principle, only be exposed to attack 124 from other nodes in the local link. Hosts employing only Unique 125 Local Addresses (ULAs) may be more isolated from attack than those 126 employing Global Unicast Addresses (GUAs), assuming that proper 127 packet filtering is enforced at the network edge. 129 The potential protection provided by a non-global addresses should 130 not be regarded as a complete security strategy, but rather as a form 131 of "prophylactic" security (see 132 [I-D.gont-opsawg-firewalls-analysis]). 134 We note that the use of non-global addresses is usually limited to a 135 reduced type of applications/protocols that e.g. are only meant to 136 operate on a reduced scope, and hence their applicability may be 137 limited. 139 A discussion of ULA usage considerations can be found in 140 [I-D.ietf-v6ops-ula-usage-considerations]. 142 5. Address Stability Considerations 144 The stability of an address has two associated security/privacy 145 implications: 147 o Ability of an attacker to correlate network activity 149 o Exposure to attack 151 For obvious reasons, an address that is employed for multiple 152 communication instances allows the aforementioned network activities 153 to be correlated. The longer an address is employed (i.e., the more 154 stable it is), the longer such correlation will be possible. In the 155 worst-case scenario, a stable address that is employed for multiple 156 communication instances over time will allow all such activities to 157 be correlated. On the other hand, if a host were to generate (and 158 eventually "throw away") one new address for each communication 159 instance (e.g., TCP connection), network activity correlation would 160 be mitigated. 162 NOTE: the use of constant IIDs (as in traditional SLAAC) result in 163 addresses that, while not constant as a whole (since the prefix 164 changes), contain a globally-unique value that leaks out the node 165 "identity". Such addresses result in the worst possible security 166 and privacy implications, and their use has been deprecated by 167 [RFC8064]. 169 Typically, when it comes to attack exposure, the longer an address is 170 employed the longer an attacker is exposed to attacks (e.g. an 171 attacker has more time to find the address in the first place 172 [RFC7707]). While such exposure is traditionally associated with the 173 stability of the address, the usage type of the address (see 174 Section 6) may also have an impact on attack exposure. 176 A popular approach to mitigate network activity correlation is the 177 use of "temporary addresses" [RFC4941]. Temporary addresses are 178 typically configured and employed along with stable addresses, with 179 the temporary addresses employed for outgoing communications, and the 180 stable addresses employed for incoming communications. 182 NOTE: Ongoing work [I-D.gont-6man-non-stable-iids] aims at 183 updating [RFC4941] such that temporary addresses can be employed 184 without the need to configure stable addresses. 186 We note that the extent to which temporary addresses provide improved 187 mitigation of network activity correlation and/or reduced attack 188 exposure may be questionable and/or limited in some scenarios. For 189 example, a temporary address that is reachable for, say, a few hours 190 has a questionable "reduced exposure" (particularly when automated 191 attack tools do not typically require such a long period of time to 192 complete their task). Similarly, if network activity can be 193 correlated for the life of such address (e.g., on the order of 194 several hours), such period of time might be long enough for the 195 attacker to correlate all the network activity he is meaning to 196 correlate. 198 In order to better mitigate network activity correlation and/or 199 possibly reduce host exposure, an implementation might want to either 200 reduce the preferred lifetime of a temporary address, or even better, 201 generate one new temporary address for each new transport protocol 202 instance. However, the associated lifetime/stability of an address 203 may have a negative impact on the network. For example, if a node 204 were to employ "throw away" IPv6 addresses, or employ temporary 205 addresses [RFC4941] with a short preferred lifetime, local nodes 206 might need to maintain too many entries in their Neighbor Cache, and 207 a number of devices (possibly enforcing security policies) might also 208 need to keep such additional state. 210 Additionally, enforcing a maximum lifetime on IPv6 addresses may 211 cause long-lived TCP connections to fail. For example, an address 212 becoming "Invalid" (after transiting through the "Preferred" and 213 "Deprecated" states) would cause the TCP connections employing them 214 to break. This, in turn, would cause e.g. long-lived SSH sessions to 215 break/fail. 217 In some scenarios, attack exposure may be reduced by limiting the 218 usage of temporary addresses to outbound connections, and prevent 219 such addresses from being used for inbound connections (please see 220 Section 6). 222 6. Usage Type Considerations 224 A node that employs one of its addresses to communicate with an 225 external server (i.e., to perform an "outgoing connection") may cause 226 such address to become exposed to attack. For example, once the 227 external server receives an incoming connection, the corresponding 228 server might launch an attack against the aforementioned address. A 229 real-world instance of this type of scenario has been documented in 230 [Hein]. 232 However, we note that employing an IPv6 address for an outgoing 233 communications need not increase the exposure of local services to 234 other parties. For example, nodes could employ temporary addresses 235 only for outgoing connections, but not for incoming connections. 236 Thus, external nodes that learn about client's addresses could not 237 really leverage such addresses for actively contacting the clients. 239 There are multiple ways in which this could possibly be achieved, 240 with different implications. Namely: 242 Run a host-based or network-based firewall 244 Bind services to specific (explicit) addresses 246 Bind services only to stable addresses 248 A client could simply run a host-based firewall that only allows 249 incoming connections on the stable addresses. This is clearly more 250 of an operational way of achieving the desired functionality, and may 251 require good firewall/host integration (e.g., the firewall should be 252 able to tell stable vs. temporary addresses), may require the client 253 to run additional firewall software for this specific purpose, etc. 254 In other scenarios, a network-based firewalls could be configured to 255 allow outgoing communications from all internal addresses, but only 256 allow incoming communications to stable addresses. For obvious 257 reasons, this is generally only applicable to networks where incoming 258 communications are allowed to a limited number of hosts/servers. 260 Services could be bound to specific (explicit) addresses, rather than 261 to all locally-configured addresses. However, there are a number of 262 short-comings associated with this approach. Firstly, an application 263 would need to be able to learn all of its addresses and associated 264 stability properties, something that tends to be non-trivial and non- 265 portable, and that also makes applications protocol-dependent, 266 unnecessarily. Secondly, the Sockets API does not really allow a 267 socket to be bound to a subset of the node's addresses. That is, 268 sockets can be bound to a single address or to all available 269 addresses (wildcard), but not to a subset of all the configured 270 addresses. 272 Binding services only to stable addresses provides a clean separation 273 between addresses employed for client-like outgoing connections and 274 server-like incoming connections. However, we currently lack an 275 appropriate API for nodes to be able to specify that a socket should 276 only be bound to stable addresses. Development of such an API should 277 be considered for future work. 279 7. Advice on IPv6 Address Configuration 281 [TBD] 283 8. Advice on IPv6 Address Usage 285 [TBD] 287 9. IANA Considerations 289 There are no IANA registries within this document. The RFC-Editor 290 can remove this section before publication of this document as an 291 RFC. 293 10. Security Considerations 295 This document discusses address usage considerations, and also 296 describes possible future standards-track work to allow for greater 297 flexibility in IPv6 address usage. 299 11. Acknowledgements 301 The authors would like to thank [TBD] for providing valuable comments 302 on earlier versions of this document. 304 Fernando Gont would like to thank Nelida Garcia and Jorge Oscar Gont 305 for their love and support, and Ivan Arce and Diego Armando Maradona 306 for their inspiration. 308 12. References 310 12.1. Normative References 312 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 313 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 314 December 1998, . 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, 318 DOI 10.17487/RFC2119, March 1997, 319 . 321 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 322 Extensions for Stateless Address Autoconfiguration in 323 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 324 . 326 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 327 Interface Identifiers with IPv6 Stateless Address 328 Autoconfiguration (SLAAC)", RFC 7217, 329 DOI 10.17487/RFC7217, April 2014, 330 . 332 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 333 "Recommendation on Stable IPv6 Interface Identifiers", 334 February 2017, . 336 12.2. Informative References 338 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 339 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 340 . 342 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 343 Considerations for IPv6 Address Generation Mechanisms", 344 RFC 7721, DOI 10.17487/RFC7721, March 2016, 345 . 347 [I-D.ietf-v6ops-ula-usage-considerations] 348 Liu, B. and S. Jiang, "Considerations For Using Unique 349 Local Addresses", draft-ietf-v6ops-ula-usage- 350 considerations-01 (work in progress), August 2016. 352 [I-D.gont-6man-non-stable-iids] 353 Gont, F. and S. LIU, "Recommendation on Non-Stable IPv6 354 Interface Identifiers", draft-gont-6man-non-stable-iids-00 355 (work in progress), May 2016. 357 [I-D.gont-opsawg-firewalls-analysis] 358 Gont, F. and F. Baker, "On Firewalls in Network Security", 359 draft-gont-opsawg-firewalls-analysis-02 (work in 360 progress), February 2016. 362 [Barnes2012] 363 Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great 364 Void Smarter scanning for IPv6", ISMA 2012 AIMS-4 - 365 Workshop on Active Internet Measurements, February 2012, 366 . 369 [Hein] Hein, B., "The Rising Sophistication of Network Scanning", 370 January 2016, . 373 Authors' Addresses 374 Fernando Gont 375 SI6 Networks / UTN-FRH 376 Evaristo Carriego 2644 377 Haedo, Provincia de Buenos Aires 1706 378 Argentina 380 Phone: +54 11 4650 8472 381 Email: fgont@si6networks.com 382 URI: http://www.si6networks.com 384 Guillermo Gont 385 SI6 Networks 386 Evaristo Carriego 2644 387 Haedo, Provincia de Buenos Aires 1706 388 Argentina 390 Phone: +54 11 4650 8472 391 Email: ggont@si6networks.com 392 URI: https://www.si6networks.com 394 Madeleine Garcia Corbo 395 Servicios de Informacion del Transporte 396 Neptuno 358 397 Havana City 10400 398 Cuba 400 Email: madelen.garcia16@gmail.com