idnits 2.17.1 draft-gont-taps-sockets-api-limitations-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 2228 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.gont-taps-address-analysis' is mentioned on line 240, but not defined == Unused Reference: 'RFC4193' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC5905' is defined on line 351, but no explicit reference was found in the text == Unused Reference: 'RFC6763' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'Barnes2012' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'Hein' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'I-D.gont-6man-address-usage-recommendations' is defined on line 389, but no explicit reference was found in the text == Unused Reference: 'I-D.gont-6man-non-stable-iids' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'I-D.gont-opsawg-firewalls-analysis' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-ula-usage-considerations' is defined on line 406, 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 (~~), 16 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 Limitations of the Sockets API for IPv6 13 Address Usage 14 draft-gont-taps-sockets-api-limitations-00 16 Abstract 18 This identifies gaps that currently prevent systems and applications 19 from leveraging the increased flexibility and availability of IPv6 20 addresses. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 22, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Default Address Selection in IPv6 . . . . . . . . . . . . . . 3 59 4. Current Possible Approaches for IPv6 Address Usage . . . . . 4 60 4.1. Incoming communications . . . . . . . . . . . . . . . . . 4 61 4.2. Outgoing communications . . . . . . . . . . . . . . . . . 5 62 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. Current Limitations in the Address Selection APIs . . . . 5 64 5.2. Sub-optimal IPv6 Address Configuration . . . . . . . . . 6 65 5.3. Sub-optimal IPv6 Address Usage . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 9.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 IPv6 hosts typically configure a number of IPv6 addresses of 77 different properties. For example, a host may configure one stable 78 and one temporary address per each autoconfiguration prefix 79 advertised on the local network. Currently, the addresses to be 80 configured typically depend on local system policy, with the 81 aforementioned policy being static and irrespective of the network 82 the host attaches to. This "one size fits all" approach limits the 83 ability of systems and applications of fully-leveraging the increased 84 flexibility and availability of IPv6 addresses. 86 Each application running on a given system may have its own set of 87 requirements or expectations for the properties of the IPv6 addresses 88 to be employed. For example, an application meaning to offer a 89 public service might expect to employ global stable addresses for 90 such purpose, while a privacy-sensible client application might 91 prefer short-lived temporary addresses, or might even expect to 92 employ single-use ("throw-away") IPv6 addresses when connecting to 93 public servers. However, the subtetlies associated with IPv6 94 addresses (and associated properties) are often ignored by 95 application programmers and, in any case, current APIs (such as the 96 BSD Sockets API) tend to be very limited in the amount of control 97 they give applications to select the most appropriate IPv6 addresses 98 for a given task, thus limiting a programmer's ability to leverage 99 IPv6 address availability and properties. 101 This document provides a problem statement by identifying and 102 analyzing gaps that prevent systems and applications from fully- 103 leveraging IPv6 addressing capabilities, setting the basis for 104 further work that could fill those gaps. 106 2. Terminology 108 This document employs the definitions of "public address", "stable 109 address", and "temporary address" from Section 2 of [RFC7721]. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 3. Default Address Selection in IPv6 117 Applications use system API's to select the IPv6 addresses that will 118 be used for incoming and outgoing connections. These choices have 119 consequences in terms of privacy, security, stability and 120 performance. 122 Default Address Selection for IPv6 is specified in [RFC6724]. The 123 selection starts with a set of potential destination addresses, such 124 as returned by getaddrinfo(), and the set of potential source 125 addresses currently configured for the selected interfaces. For each 126 potential destination address, the algorithm will select the source 127 address that provides the best route to the destination, while 128 choosing the appropriate scope and preferring temporary addresses. 129 The algorithm will then select the destination address, while giving 130 a preference to reachable addresses with the smallest scope. The 131 selection may be affected by system settings. We note that [RFC6724] 132 only applies for outgoing connections, such as those made by clients 133 trying to use services offered by other hosts. 135 We note that [RFC6724] selects IPv6 addresses from all the currently 136 available addresses on the host, and there is currently no way for an 137 application to indicate expected or desirable properties for the IPv6 138 source addresses employed for such outgoing communications. For 139 example, a privacy-sensitive application might want that each 140 outgoing communication instance employs a new, single-use IPv6 141 address, or to employ a new reusable address that is not employed or 142 reusable by any other application on the host. Reuse of an IPv6 143 address by an application would allow the correlation of all network 144 activities corresponding to such application as being performed by 145 the same host, while reuse of an IPv6 address by multiple different 146 applications would allow the correlation of all such network 147 activities as being performed by the host with such IPv6 address. 149 When devices provide a service, the common pattern is to just wait 150 for connections over all addresses configured on the device. For 151 example, applications using the BSD Sockets API will commonly bind() 152 the listening socket to the undefined address. This long-established 153 behavior is appropriate for devices providing public services, but 154 may have unexpected results for devices providing semi-private 155 services, such as various forms of peer-to-peer or local-only 156 applications. 158 This behavior leads to three problems: device tracking, unexpected 159 address discovery, and availability outside the expected scope 160 (please see [I-D.gont-taps-address-analysis] for more details). 161 These problems are caused in part by the limitations of available 162 address selection API, presented in Section 5.1. 164 4. Current Possible Approaches for IPv6 Address Usage 166 4.1. Incoming communications 168 There are a number of ways in which a system or network may affect 169 which address (and how) may be employed for different services and 170 cases. Namely, 172 o TCP/IP stack address filtering 174 o Application-based address filtering 176 o Firewall-based address filtering 178 Clearly, the most elegant approach for address selection is for 179 applications to be able to specify the properties of the addresses 180 they are willing to employ by means of an API, such the TCP/IP stack 181 itself can "filter" which addresses are allowed to be employed for 182 the given service/application. This relieves the application from 183 dealing with low level details of networking, improves portability, 184 and avoids duplicate code in applications. However, constraints in 185 the current APIs (see Section 5.1) may limit the ability of 186 application progremmers for leveraging this technique. 188 Another possible approach is for applications to e.g. bind services 189 to all available addresses, and perform the associated selection/ 190 filtering at the application level. While possible this has a number 191 of drawbacks. Firstly, it would require applications to deal with 192 low-level networking details, require that all the associated code be 193 duplicated in all applications, and also negatively affect 194 portability. Besides, performing address/selection filtering at the 195 application level may not mitigate some possible threats. For 196 example, port scanning will still be possible, since the 197 aforementioned filtering will only be performed e.g. once UDP packets 198 are received or TCP connections are established. 200 Finally, a firewall may be employed to filter addresses based on 201 their intended usage. For example, a firewall may block incoming 202 requests to all addresses except to some whitelisted addresses (such 203 as the stable addresses of the node). This technique not only 204 requires the use of a firewall (which may or may not be present), but 205 also implies knowledge of the firewall regarding the desired 206 properties of the addresses that each application/service is intended 207 to use. 209 4.2. Outgoing communications 211 An application might be able to obtain the list of currently- 212 configured addresses, and subsequently select an address with desired 213 properties, and explicitly "bind" the address to the socket, to 214 override the default source address selection. 216 However, this approach is problematic for a number of reasons. 217 Firstly, there is no portable way of obtaining the list of currently- 218 configured addresses on the local node, and even less to check for 219 properties such "valid lifetime". Secondly, as discussed in 220 Section 4.1, it would require application programmers to understand 221 all the subtetiles associated with IPv6 addressing, and would also 222 lead to duplicate code on all applications. Finally, applications 223 would be limited to use already-configured addresses and unable to 224 trigger the generation of new addresses where desirable (e.g. the 225 genration of a new temporary address for this application instance or 226 communication instance). 228 5. Problem Statement 230 This section elaborates the problem statement on IPv6 address usage. 231 Section 5.1, Section 5.3, Section 5.2, analyze the possible root of 232 such improper IPv6 address usage, suggesting possible future work. 234 5.1. Current Limitations in the Address Selection APIs 236 Application developers using the BSD Sockets API can "bind" a 237 listening socket to a specific address, and ensure that the 238 application is only reachable through that address. In theory, 239 careful selection of the binding address could mitigate the problems 240 described in [I-D.gont-taps-address-analysis] . Binding services to 241 temporary addresses could mitigate the ability of an attacker from 242 testing for the presence of the node in the network. Binding 243 different services to different addresses could mitigate unexpected 244 discovery. Binding services to link local addresses or ULA could 245 mitigate availability outside the expected scope. However, 246 explicitly managing addresses adds significant complexity to the 247 application development. It requires that application developers 248 master addressing architecture subtleties, and implement logic that 249 reacts adequately to connectivity events and address changes. 250 Experience shows that application developers would probably prefer 251 some much simpler solution. 253 In addition, we should note that many application developers use high 254 level APIs that listen to TLS, HTTP, or some other application 255 protocol. These high level APIs seldom provide detailed access to 256 specific IP addresses, and typically default to listening to all 257 available addresses. 259 A more advanced API could allow an application programmer to select 260 desired properties in an address (scope, lifespan, etc.), such that 261 the best-suitable addresses are selected, while relieving the 262 application for low-level IPv6 addressing details. Such API might 263 also trigger the generation of new IPv6 addresses when the specified 264 properties would require so. 266 5.2. Sub-optimal IPv6 Address Configuration 268 Most operating systems configure the same types of addresses 269 regardless of the current "operating mode" or "profile" of the device 270 (e.g., device connected to enterprise network vs roaming across 271 untrusted networks). For example, many operating systems configure 272 both stable [RFC8064] and temporary [RFC4941] addresses on all 273 network interfaces. However, this "one size fits all" approach tends 274 to be sub-optimal or inappropriate for some scenarios. For example, 275 enterprise networks typically prefer usage of only stable address, 276 thus meaning that a network administator needs to find the means for 277 disabling the generation of temporary addresses on all those systems 278 that would otherwise generate them. On the other hand, some mobile 279 devices configure both stable and temporary addresses, even when 280 their usage pattern (client-like operation, as opposed to offering 281 services to other nodes) would allow for the more privacy-sensible 282 option of configuring only temporary addresses. 284 The lack of better tuned address configuration policies has helped 285 the "one size fits all" approach that, as noted, may lead to 286 suboptimal results. Advice in this area might help achieve more 287 optional address generation policies such that IPv6 addressing 288 capabilities are fully leveraged. 290 5.3. Sub-optimal IPv6 Address Usage 292 An application programmer, left with the question of which are the 293 most appropriate addresses for a given usage type and application, 294 typically resorts to the Default IPv6 Address Selection for IPv6 (see 295 Section 3) for outgoing communications, and to accepting incoming 296 communications on all available addresses for incoming 297 communications. As discussed throughout this document, this leads to 298 sub-optimal results. Besides, all applications on a node share the 299 same pool of configured addresses, and applications are also 300 prevented from triggering the generation of new addresses (e.g. to be 301 employed for a particular application or communcation instance). 303 Guidance in this area is warranted such that applications and systems 304 fully-leverage IPv6 addressing. 306 6. IANA Considerations 308 There are no IANA registries within this document. The RFC-Editor 309 can remove this section before publication of this document as an 310 RFC. 312 7. Security Considerations 314 The security and privacy implications associated with the 315 predictability and lifetime of IPv6 addresses has been analyzed in 316 [RFC7217] [RFC7721], and [RFC7707]. This document complements and 317 extends the aforementioned analysis by considering other IPv6 318 properties such as the address scope and address usage type, and the 319 associated tradeoffs. 321 8. Acknowledgements 323 The authors would like to thank (in alphabetical order) Francis 324 Dupont, Tatuya Jinmei, Erik Kline, Tommy Pauly, and Dave Thaler for 325 providing valuable comments on earlier versions of this document. 327 Fernando Gont would like to thank Spencer Dawkins for his guidance. 329 9. References 331 9.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, 335 DOI 10.17487/RFC2119, March 1997, 336 . 338 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 339 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 340 . 342 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 343 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 344 2006, . 346 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 347 Extensions for Stateless Address Autoconfiguration in 348 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 349 . 351 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 352 "Network Time Protocol Version 4: Protocol and Algorithms 353 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 354 . 356 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 357 "Default Address Selection for Internet Protocol Version 6 358 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 359 . 361 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 362 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 363 . 365 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 366 Interface Identifiers with IPv6 Stateless Address 367 Autoconfiguration (SLAAC)", RFC 7217, 368 DOI 10.17487/RFC7217, April 2014, 369 . 371 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 372 "Recommendation on Stable IPv6 Interface Identifiers", 373 RFC 8064, DOI 10.17487/RFC8064, February 2017, 374 . 376 9.2. Informative References 378 [Barnes2012] 379 Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great 380 Void Smarter scanning for IPv6", ISMA 2012 AIMS-4 - 381 Workshop on Active Internet Measurements, February 2012, 382 . 385 [Hein] Hein, B., "The Rising Sophistication of Network Scanning", 386 January 2016, . 389 [I-D.gont-6man-address-usage-recommendations] 390 Gont, F., Gont, G., Corbo, M., and C. Huitema, "Problem 391 Statement Regarding IPv6 Address Usage", draft-gont-6man- 392 address-usage-recommendations-04 (work in progress), 393 October 2017. 395 [I-D.gont-6man-non-stable-iids] 396 Gont, F., Huitema, C., Krishnan, S., Gont, G., and M. 397 Corbo, "Recommendation on Temporary IPv6 Interface 398 Identifiers", draft-gont-6man-non-stable-iids-03 (work in 399 progress), March 2018. 401 [I-D.gont-opsawg-firewalls-analysis] 402 Gont, F. and F. Baker, "On Firewalls in Network Security", 403 draft-gont-opsawg-firewalls-analysis-02 (work in 404 progress), February 2016. 406 [I-D.ietf-v6ops-ula-usage-considerations] 407 Liu, B. and S. Jiang, "Considerations For Using Unique 408 Local Addresses", draft-ietf-v6ops-ula-usage- 409 considerations-02 (work in progress), March 2017. 411 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 412 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 413 . 415 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 416 Considerations for IPv6 Address Generation Mechanisms", 417 RFC 7721, DOI 10.17487/RFC7721, March 2016, 418 . 420 Authors' Addresses 422 Fernando Gont 423 SI6 Networks / UTN-FRH 424 Evaristo Carriego 2644 425 Haedo, Provincia de Buenos Aires 1706 426 Argentina 428 Phone: +54 11 4650 8472 429 Email: fgont@si6networks.com 430 URI: http://www.si6networks.com 431 Guillermo Gont 432 SI6 Networks 433 Evaristo Carriego 2644 434 Haedo, Provincia de Buenos Aires 1706 435 Argentina 437 Phone: +54 11 4650 8472 438 Email: ggont@si6networks.com 439 URI: https://www.si6networks.com 441 Madeleine Garcia Corbo 442 Servicios de Informacion del Transporte 443 Neptuno 358 444 Havana City 10400 445 Cuba 447 Email: madelen.garcia16@gmail.com 449 Christian Huitema 450 Private Octopus Inc. 451 Friday Harbor, WA 98250 452 U.S.A. 454 Email: huitema@huitema.net 455 URI: http://privateoctopus.com