idnits 2.17.00 (12 Aug 2021) /tmp/idnits63641/draft-irtf-pearg-ip-address-privacy-considerations-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: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (26 January 2022) is 108 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-privacypass-protocol-01 == Outdated reference: A later version (-11) exists of draft-pauly-dprive-oblivious-doh-09 == Outdated reference: A later version (-02) exists of draft-wood-key-consistency-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Finkel 3 Internet-Draft The Tor Project 4 Intended status: Informational B. Lassey 5 Expires: 30 July 2022 Google 6 L. Iannone 7 Huawei 8 J.B. Chen 9 Google 10 26 January 2022 12 IP Address Privacy Considerations 13 draft-irtf-pearg-ip-address-privacy-considerations-00 15 Abstract 17 This document provides an overview of privacy considerations related 18 to user IP addresses. It includes an analysis of some current use 19 cases for tracking of user IP addresses, mainly in the context of 20 anti-abuse. It discusses the privacy issues associated with such 21 tracking and provides input on mechanisms to improve the privacy of 22 this existing model. It then captures requirements for proposed 23 'replacement signals' for IP addresses from this analysis. In 24 addition, existing and under-development techniques are evaluated for 25 fulfilling these requirements. 27 Discussion Venues 29 This note is to be removed before publishing as an RFC. 31 Discussion of this document takes place on the mailing list (), which 32 is archived at . 34 Source for this draft and an issue tracker can be found at 35 https://github.com/ShivanKaul/draft-ip-address-privacy. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 30 July 2022. 54 Copyright Notice 56 Copyright (c) 2022 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Revised BSD License text as 65 described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Revised BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.1. Categories of Interaction . . . . . . . . . . . . . . . . 4 73 3. IP address tracking . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. IP address use cases . . . . . . . . . . . . . . . . . . 5 75 3.1.1. Anti-abuse . . . . . . . . . . . . . . . . . . . . . 5 76 3.1.2. DDoS and Botnets . . . . . . . . . . . . . . . . . . 5 77 3.1.3. Multi-platform threat models . . . . . . . . . . . . 6 78 3.1.4. Rough Geolocation . . . . . . . . . . . . . . . . . . 6 79 3.2. Implications of IP addresses . . . . . . . . . . . . . . 7 80 3.2.1. Next-User Implications . . . . . . . . . . . . . . . 7 81 3.2.2. Privacy Implications . . . . . . . . . . . . . . . . 7 82 3.3. IP Privacy Protection and Law . . . . . . . . . . . . . . 8 83 3.4. Mitigations for IP address tracking . . . . . . . . . . . 8 84 4. Replacement signals for IP addresses . . . . . . . . . . . . 9 85 4.1. Signals . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 4.1.1. Adoption . . . . . . . . . . . . . . . . . . . . . . 10 87 4.1.2. Privacy Considerations . . . . . . . . . . . . . . . 11 88 4.1.3. Provenance . . . . . . . . . . . . . . . . . . . . . 12 89 4.1.4. Applying Appropriate Signals . . . . . . . . . . . . 12 90 4.2. Evaluation of existing technologies . . . . . . . . . . . 13 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 95 7.2. Informative References . . . . . . . . . . . . . . . . . 14 96 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 99 1. Introduction 101 The initial intention of this draft is to capture an overview of the 102 problem space and research on proposed solutions concerning privacy 103 considerations related to user IP addresses (informally, IP privacy). 104 The draft is likely to evolve significantly over time and may well 105 split into multiple drafts as content is added. 107 Tracking of IP addresses is common place on the Internet today, and 108 is particularly widely used in the context of anti-abuse, e.g. anti- 109 fraud, DDoS management, and child protection activities. IP 110 addresses are currently used in determining "reputation" [RFC5782] in 111 conjunction with other signals to protect against malicious traffic, 112 since these addresses are usually a relatively stable identifier of a 113 request's origin. Servers use these reputations in determining 114 whether or not a given packet, connection, or flow likely corresponds 115 to malicious traffic. In addition, IP addresses are used in 116 investigating past events and attributing responsibility. 118 However, identifying the activity of users based on IP addresses has 119 clear privacy implications ([WEBTRACKING1], [WEBTRACKING2]), e.g. 120 user fingerprinting and cross-site identity linking. Many 121 technologies exist today that allow users to obfuscate their external 122 IP address to avoid such tracking, e.g. VPNs ([VPNCMP1], [VPNCMP2]) 123 and Tor ([TOR], [VPNTOR]). Several new technologies are emerging, as 124 well, in the landscape, e.g. Apple iCloud Private Relay [APPLEPRIV], 125 Gnatcatcher [GNATCATCHER], and Oblivious technologies (ODoH 126 [I-D.pauly-dprive-oblivious-doh], OHTTP [I-D.thomson-ohai-ohttp]). 128 General consideration about privacy for Internet protocols can be 129 found in [RFC6973]. This document builds upon [RFC6973] and more 130 specifically attempts to capture the following aspects of the tension 131 between valid use cases for user identification and the related 132 privacy concerns, including: 134 * An analysis of the current use cases, attempting to categorize/ 135 group such use cases where commonalities exist. 137 * Find ways to enhance the privacy of existing uses of IP addresses. 139 * Generating requirements for proposed 'replacement signals' from 140 this analysis (these could be different for each category/group of 141 use cases). 143 * Research to evaluate existing technologies or propose new 144 mechanisms for such signals. 146 With the goal of replacing IP addresses as a fundemental signal, the 147 following sections enumerate existing use cases and describe 148 applicable substitution signals. This description may not be 149 exhaustive due to the breadth of IP address usage. 151 2. Terminology 153 (Work in progress) 155 This section defines basic terms used in this document, with 156 references to pre-existing definitions as appropriate. As in 157 [RFC4949] and [RFC6973], each entry is preceded by a dollar sign ($) 158 and a space for automated searching. 160 * $ Identity: Extending [RFC6973], an individual's attributes may 161 only identify an individual up to an anonymity set within a given 162 context. 164 * $ Reputation: A random variable with some distribution. A 165 reputation can either be "bad" or "good" with some probability 166 according to the distribution. 168 * $ Reputation context: The context in which a given reputation 169 applies. 171 * $ Reputation proof: A non-interactive zero knowledge proof of a 172 reputation signal. 174 * $ Reputation signal: A representative of a reputation. 176 * $ Service provider: An entity that provides a service on the 177 Internet; examples services include hosted e-mail, e-commerce 178 sites, and cloud computing platforms. 180 2.1. Categories of Interaction 182 Interactions between parties on the Internet may be classified into 183 one (or more) of three categories: 185 * $ Private Interaction: An interaction occuring between mutually 186 consenting parties, with a mutual expectation of privacy. 188 * $ Public Interaction: An interaction occuring between multiple 189 parties that are not engaged in a Private Interaction. 191 * $ Consumption: An interaction where one party primarily receives 192 information from other parties. 194 3. IP address tracking 196 3.1. IP address use cases 198 3.1.1. Anti-abuse 200 IP addresses are a passive identifier used in defensive operations. 201 They allow correlating requests, attribution, and recognizing 202 numerous attacks, including: 204 * account takeover 206 * advertising fraud (e.g., click-fraud) 208 * disinformation operations (e.g., detecting scaled and/or 209 coordinated attacks) 211 * financial fraud (e.g., stolen credit cards, email account 212 compromise) 214 * malware/ransomware (e.g., detecting C2 connections) 216 * phishing 218 * real-world harm (e.g., child abuse) 220 * scraping (e.g., e-commerce, search) 222 * spam (e.g., email, comments) 224 * vulnerability exploitation (e.g., "hacking") 226 Malicious activity recognized by one service provider may be shared 227 with other services [RFC5782] as a way of limiting harm. 229 3.1.2. DDoS and Botnets 231 Cyber-attackers can leverage the good reputation of an IP address to 232 carry out specific attacks that wouldn't work otherwise. Main 233 examples are Distributed Denial of Service (DDoS) attacks carried out 234 by spoofing a trusted (i.e., having good reputation) IP address 235 (which may or may not be the victim of the attack) so that the 236 servers used to generate the DDoS traffic actually respond to the 237 attackers trigger (i.e., spoofed packets). Similarly botnets may use 238 spoofed addresses in order to gain access and attack services that 239 otherwise would not be reachable. 241 3.1.3. Multi-platform threat models 243 As siloed (single-platform) abuse defenses improve, abusers have 244 moved to multi-platform threat models. For example, a public 245 discussion platform with a culture of anonymity may redirect traffic 246 to YouTube as a video library, bypassing YouTube defenses that 247 otherwise reduce exposure of potentially harmful content. Similarly, 248 a minor could be solicited by an adult impersonating a child on a 249 popular social media platform, then redirected to a smaller, less 250 established and less defended platform where illegal activity could 251 occur. Phishing attacks are also common. There are many such cross- 252 platform abuse models and they cause significant public harm. IP 253 addresses are commonly used to investigate, understand and 254 communicate these cross-platform threats. There are very few 255 alternatives for cross-platform signals. 257 3.1.4. Rough Geolocation 259 A rough geolocation can be inferred from a client's IP address, which 260 is commonly known as either IP-Geo or Geo-IP. This information can 261 have several useful implications. When abuse extends beyond attacks 262 in the digital space, IP addresses may help identify the physical 263 location of real-world harm, such as child exploitation. 265 3.1.4.1. Legal compliance 267 Legal and regulatory compliance often needs to take the jurisdiction 268 of the client into account. This is especially important in cases 269 where regulations are mutually contradictory (i.e. there is no way to 270 be in legal compliance universally). Because Geo-IP is often bound 271 to the IP addresses a given ISP uses, and ISPs tend to operate within 272 national borders, Geo-IP tends to be a good fit for server operators 273 to comply with local laws and regulations 275 3.1.4.2. Contractual obligations 277 Similar to legal compliance, some content and media has licensing 278 terms that are valid only for certain locations. The rough 279 geolocation derived from IP addresses allow this content to be hosted 280 on the web. 282 3.1.4.3. Locally relevant content 284 Rough geolocation can also be useful to tailor content to the 285 client's location simply to improve their experience. A search for 286 "coffee shop" can include results of coffee shops within reasonable 287 travel distance from a user rather than generic information about 288 coffee shops, a merchant's website could show brick and mortar stores 289 near the user and a news site can surface locally relevant news 290 stories that wouldn't be as interesting to visitors from other 291 locations. 293 3.2. Implications of IP addresses 295 3.2.1. Next-User Implications 297 When an attacker uses IP addresses with "good" reputations, the 298 collateral damage poses a serious risk to legitimate service 299 providers, developers, and end users. IP addresses may become 300 assocaited with a "bad" reputation from temporal abuse, and 301 legitimate users may be affected by blocklists as a result. This 302 unintended impact may hurt the reputation of a service or an end user 303 [RFC6269]. 305 3.2.2. Privacy Implications 307 IP addresses are sent in the clear throughout the packet journey over 308 the Internet. As such, any observer along the path can pick it up 309 and use it for various tracking purposes. Beside basic information 310 about the network or the device, it is possible to associate an IP 311 address to an end user, hence, the relevance of IP addresses for user 312 privacy. A very short list of information about user, device, and 313 network that can be obtained via the IP address. 315 * Determine who owns and operates the network. Searching the WHOIS 316 database using an IP address can provide a range of information 317 about the organization to which the address is assigned, including 318 a name, phone number, and civic address; 320 * Through a reverse DNS lookup and/or traceroute the computer name 321 can be obtained, which often contains clues to logical and 322 physical location; 324 * Geo-localisation of the device (hence the user) through various 325 techniques [GEOIP]. Depending on the lookup tool used, this could 326 include country, region/state, city, latitude/longitude, telephone 327 area code and a location-specific map; 329 * Search the Internet using the IP address or computer names. The 330 results of these searches might reveal peer-to-peer (P2P) 331 activities (e.g., file sharing), records in web server log files, 332 or glimpses of the individual's web activities (e.g., Wikipedia 333 edits). These bits of individuals' online history may reveal 334 their political inclinations, state of health, sexuality, 335 religious sentiments and a range of other personal 336 characteristics, preoccupations and individual interests; 338 * Seek information on any e-mail addresses used from a particular IP 339 address which, in turn, could be the subject of further requests 340 for subscriber information. 342 3.3. IP Privacy Protection and Law 344 This section aim at providing some basic information about main 345 example of laws adopted worldwide and related to IP address privacy 346 (usually these laws area by product of the broader user privacy 347 protection). 349 Possible content (to focus only on technical IP address related 350 aspects): 352 * GDPR (General Data Protection Regulation) - EUROPE: Europe 353 considers IP addresses as personal identification information that 354 should be treated like any other personal information e.g. social 355 security number. 357 * The United States has opted for a different approach to data 358 protection. Instead of formulating one all-encompassing 359 regulation such as the EU's GDPR, the US chose to implement 360 sector-specific privacy and data protection regulations that work 361 together with state laws to safeguard American citizens' data. 363 * In 2020, China released the first draft of Personal Information 364 Protection Law (PIPL). The PIPL is the equivalent of European 365 GDPR and will have significant influence. 367 * Japan Protection of Personal Information (APPI) Act (recent 368 changes put the act close to the GDPR model). 370 3.4. Mitigations for IP address tracking 372 The ability to track individual people by IP address has been well 373 understood for decades. Commercial VPNs and Tor are the most common 374 methods of mitigating IP address-based tracking. 376 * Commerical VPNs offer a layer of indirection between the user and 377 the destination, however if the VPN endpoint's IP address is 378 static then this simply substitutes one address for another. In 379 addition, commerial VPNs replace tracking across sites with a 380 single company that may track their users' activities. 382 * Tor is another mitigation option due to its dynamic path selection 383 and distributed network of relays, however its current design 384 suffers from degraded performance. In addition, correct 385 application integration is difficult and not common. 387 * Address anonymization (e.g. [GNATCATCHER] and similar): 389 - [GNATCATCHER] is a single-hop proxy system providing more 390 protection against third-party tracking than a traditional 391 commercial VPN. However, its design maintains the industry- 392 standard reliance on IP addresses for anti-abuse purposes and 393 it provides near backwards compatibility for select services 394 that submit to periodic audits. 396 - [APPLEPRIV] iCloud Private Relay is described as using two 397 proxies between the client and server, and it would provide a 398 level of protection somewhere between a commercial VPN and Tor. 400 * Recent interest has resulted in new protocols such as Oblivious 401 DNS (ODoH ({{I-D.pauly-oblivious-doh-02.html}})) and Oblivious 402 HTTP (OHTTP ({{I-D.thomson-http-oblivious}})). While they both 403 prevent tracking by individual parties, they are not intended for 404 the general-purpose web browsing use case. 406 * Temporary addresses 408 4. Replacement signals for IP addresses 410 Fundamentally, the current ecosystem operates by making the immediate 411 peer of a connection accountable for bad traffic, rather than the 412 source of the traffic itself. This is problematic because in some 413 network architectures the peer node of the connection is simply 414 routing traffic for other clients, and any client's use of that node 415 may be only temporary. Ideally, clients could present appropriate 416 identification end-to-end that is separate from the IP address, and 417 uniquely bound to a given connection. 419 4.1. Signals 421 There are 7 classes of signals identified in this document that may 422 be used in place of IP addresses. A signal's provenance is a 423 critical property and will be discussed in Section 4.1.3. 425 * ADDRESS_ESCROW: Provides sufficient information for retroactively 426 obtaining a client's IP address. 428 * IDENTITY_TRANSPARENCY: Reveals a person's identity within a 429 context. 431 * IS_HUMAN: Informs the recipient that, most likely, a human 432 recently proved their presence on the opposite end of the 433 connection. 435 * PEER_INTEGRITY: Provides a secure, remote attestation of hardware 436 and/or software state. 438 * REIDENTIFICATION: Provides a mechanism for identifying the same 439 user across different connections within a time period. 441 * REPUTATION: Provides the recipient with a proof of reputation from 442 a reputation provider. 444 * SOURCE_ASN: Reveals the ASN from which the client is connecting. 446 In some situations one of the above signals may be a sufficient 447 replacement signal in isolation, or more than one signal may be 448 needed in combination. 450 Separately, there are three signal categories that are out-of-scope 451 for this document but are important improvements for mitigating abuse 452 on platforms. 454 * publisher norms: Standard expections of publishers including 455 identity transparency and conflicts of interest. 457 * protocol improvements: Increasing security of existing protocols. 459 * ecosystem improvements: Reducing reliance on less secure systems, 460 for example, migrating user authentication from password-based to 461 WebAuthn [WEBAUTHN] and relying on multiple factors (MFA). 463 4.1.1. Adoption 465 Adoption of replacement signals requires coordination between user 466 agents, service providers, and proxy services. Some user agents and 467 proxy services may support only a subset of these signals, while 468 service providers may require additional signals. A mechanism of 469 negotiation may be needed for communicating these requirements. 471 In addition, service providers should only require a signal within 472 the scope it will be used. In the same way that service provides 473 only require user authentication when the user requests access to a 474 non-public resource, a signal should not be pre-emptively requested 475 before it is needed. The categories of interaction described above 476 may help define scopes within a service, and they may help 477 communicate to the user the reasoning for requiring a signal. 479 4.1.2. Privacy Considerations 481 A signal should not be required without clear justification, service 482 providers should practice data minimization [RFC6973] wherever 483 possible. Requiring excessive signals may be more harmful to user 484 privacy than requiring IP address transparency. This section 485 provides a more details analysis of some signals. 487 ADDRESS_ESCROW gives service providers a time period within which 488 they may obtain the client's IP address, but the information-in- 489 escrow is not immediately available. Service providers should not 490 gain access to the information in secret. A service provider may 491 misuse the information-in-escrow for tracking and privacy-invasion 492 purposes. 494 PEER_INTEGRITY partitions users into two groups with valid and 495 invalid hardware/software state, at a minimum. If the signal reveals 496 more information, then it may allow more granular tracking of small 497 sets of devices. 499 IDENTITY_TRANSPARENCY may expose significant information about a user 500 to a service provider; the resulting privacy invasion may be 501 significantly worse than IP address transparency causes. 503 IS_HUMAN depends on the mechanism used for proving humanness. 505 REIDENTIFICATION explicitly allows a service provider to associate 506 requests across unlinkable connections. This signal allows for 507 profiling user behavior and tracking user activity without requesting 508 more identifying information. First-party reidentification is a use 509 case for this signal. 511 REPUTATION partitions users into a set based on their reputation. 512 The privacy invasion associated with this signal is intentionally 513 small. 515 SOURCE_ASN allows for identifying request patterns originating from 516 an ASN without providing IP address transparency. However, ASNs are 517 not guaranteed to serve large populations, therefore revealing the 518 source ASN of a request may reveal more information about the user 519 than intended. 521 4.1.3. Provenance 523 Replacement signals are only useful if they are trustworthy. 525 [[OPEN ISSUE: https://github.com/ShivanKaul/draft-ip-address-privacy/ 526 issues/24]] 528 4.1.4. Applying Appropriate Signals 530 As previous discussed, IP addresses are used for various reasons; 531 therefore, describing a one-size-fits-all replacement signal is not 532 appropriate. In addition, the quality and quantity of replacement 533 signals needed by a service depends on the category of interaction of 534 its users and potential attacks on the service. 536 As an example, the attacks listed above in Section 3.1.1 can be 537 organized into six groups based on the signals that may sufficiently 538 replace IP addresses: 540 1. IS_HUMAN, REPUTATION, REIDENTIFICATION, PEER_INTEGRITY 542 * advertising fraud (e.g., click-fraud) 544 * phishing 546 * scraping (e.g., e-commerce, search) 548 * spam (e.g., email, comments) 550 2. IS_HUMAN, REPUTATION, REIDENTIFICATION, ecosystem improvements 552 * account takeover 554 3. IS_HUMAN, REPUTATION, SOURCE_ASN 556 * influence (e.g., brigading, astroturfing) 558 4. publisher norms, (publisher) IDENTITY_TRANSPARENCY, 559 PEER_INTEGRITY 561 * disinformation operations (e.g., detecting scaled and/or 562 coordinated attacks) 564 5. publisher norms, (publisher) IDENTITY_TRANSPARENCY, 565 ADDRESS_ESCROW 567 * real-world harm (e.g., child abuse) 569 6. IDENTITY_TRANSPARENCY, protocol improvements 571 * financial fraud (e.g., stolen credit cards, email account 572 compromise) 574 The remaining two attack categories fall outside of the scope of this 575 document. 577 * malware/ransomware (e.g., detecting C2 connections) 579 * vulnerability exploitation (e.g., "hacking") 581 Note, IP addresses do not provide a perfect signal in their existing 582 usage, and the above replacement signals do not provide a better 583 signal in all cases. 585 4.2. Evaluation of existing technologies 587 Technologies exist that are designed to solve some of the problems 588 described in this document. 590 Privacy Pass [I-D.ietf-privacypass-protocol] is a useful building 591 block for solving numerous problems. Its design involves an 592 interaction between a client and server where, at the end, the client 593 is issued a set of anonymous tokens. These tokens may be redeemed at 594 a later time, and this redemption should not be linkable with the 595 initial issuance interaction. One existing use case is substituting 596 a CAPTCHA challenge with a token, where successfully solving a 597 CAPTCHA challenge results in a client being issued a set of anonymous 598 tokens, and these tokens may be used in the future to bypass solving 599 another CAPTCHA challenge. Therefore, Privacy Pass may be acceptable 600 as an IS_HUMAN signal by some service providers. The current token 601 design can't carry additional metadata like a user's reputation or an 602 expiration date, and the tokens are not bound to an identity. The 603 unlinkability property of the tokens is dependent on the 604 implementation of key consistency [I-D.wood-key-consistency]. 606 Trust Token [TRUSTTOKEN] is an extension of Privacy Pass where the 607 issuance and redemption functionality are provided in the browser 608 setting. The tokens are allowed to carry public and private metadata 609 as extensions. 611 Private Access Tokens [I-D.private-access-tokens] provide a technique 612 for partitioning clients based on a per-origin policy within a time 613 period. Its use cases include rate-limiting access to content and 614 geo-location. PATs could be used as a REIDENTIFICATION signal or a 615 replacement signal for GeoIP, depending on requirements. 617 5. Security Considerations 619 This draft discussses IP address use cases, underlying requirements, 620 and possible replacement signals. Adoption challenges and privacy 621 considerations for those signals are also discussed. Further work is 622 needed to build and evaluate these signals as suitable replacements 623 for IP addresses. 625 6. IANA Considerations 627 This document has no IANA actions. 629 7. References 631 7.1. Normative References 633 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 634 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 635 . 637 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 638 DOI 10.17487/RFC5782, February 2010, 639 . 641 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 642 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 643 DOI 10.17487/RFC6269, June 2011, 644 . 646 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 647 Morris, J., Hansen, M., and R. Smith, "Privacy 648 Considerations for Internet Protocols", RFC 6973, 649 DOI 10.17487/RFC6973, July 2013, 650 . 652 7.2. Informative References 654 [APPLEPRIV] 655 "Apple iCloud Private Relay", n.d., 656 . 659 [GEOIP] Dan, O., Parikh, V., and B. Davison, "IP Geolocation Using 660 Traceroute Location Propagation and IP Range Location 661 Interpolation", Companion Proceedings of the Web 662 Conference 2021, DOI 10.1145/3442442.3451888, April 2021, 663 . 665 [GNATCATCHER] 666 "Global Network Address Translation Combined with Audited 667 and Trusted CDN or HTTP-Proxy Eliminating 668 Reidentification", n.d., 669 . 671 [I-D.ietf-privacypass-protocol] 672 Celi, S., Davidson, A., and A. Faz-Hernandez, "Privacy 673 Pass Protocol Specification", Work in Progress, Internet- 674 Draft, draft-ietf-privacypass-protocol-01, 22 February 675 2021, . 678 [I-D.pauly-dprive-oblivious-doh] 679 Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. 680 Wood, "Oblivious DNS Over HTTPS", Work in Progress, 681 Internet-Draft, draft-pauly-dprive-oblivious-doh-09, 5 682 January 2022, . 685 [I-D.private-access-tokens] 686 Hendrickson, S., Iyengar, J., Pauly, T., Valdez, S., and 687 C. A. Wood, "Private Access Tokens", Work in Progress, 688 Internet-Draft, draft-private-access-tokens-01, 25 October 689 2021, . 692 [I-D.thomson-ohai-ohttp] 693 Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in 694 Progress, Internet-Draft, draft-thomson-ohai-ohttp-00, 25 695 October 2021, . 698 [I-D.wood-key-consistency] 699 Davidson, A., Finkel, M., Thomson, M., and C. A. Wood, 700 "Key Consistency and Discovery", Work in Progress, 701 Internet-Draft, draft-wood-key-consistency-01, 19 August 702 2021, . 705 [TOR] "The Tor Project", n.d., . 707 [TRUSTTOKEN] 708 "Trust Token API Explainer", n.d., 709 . 711 [VPNCMP1] Osswald, L., Haeberle, M., and M. Menth, "Performance 712 Comparison of VPN Solutions", Universität 713 Tübingen article, DOI 10.15496/PUBLIKATION-41810, May 714 2020, . 716 [VPNCMP2] Khanvilkar, S. and A. Khokhar, "Virtual private networks: 717 an overview with performance evaluation", IEEE 718 Communications Magazine Vol. 42, pp. 146-154, 719 DOI 10.1109/mcom.2004.1341273, October 2004, 720 . 722 [VPNTOR] Ramadhani, E., "Anonymity communication VPN and Tor: A 723 comparative study", n.d., . 726 [WEBAUTHN] "Web Authentication: An API for accessing Public Key 727 Credentials Level 2", n.d., 728 . 730 [WEBTRACKING1] 731 Bujlow, T., Carela-Espanol, V., Lee, B., and P. Barlet- 732 Ros, "A Survey on Web Tracking: Mechanisms, Implications, 733 and Defenses", Proceedings of the IEEE Vol. 105, pp. 734 1476-1510, DOI 10.1109/jproc.2016.2637878, August 2017, 735 . 737 [WEBTRACKING2] 738 Mishra, V., Laperdrix, P., Vastel, A., Rudametkin, W., 739 Rouvoy, R., and M. Lopatka, "Don’t Count Me Out: On the 740 Relevance of IP Address in the Tracking Ecosystem", 741 Proceedings of The Web Conference 2020, 742 DOI 10.1145/3366423.3380161, April 2020, 743 . 745 Acknowledgments 747 [[OPEN ISSUE: TODO]] 749 Authors' Addresses 751 Matthew Finkel 752 The Tor Project 754 Email: sysrqb@torproject.org 755 Bradford Lassey 756 Google 758 Email: lassey@chromium.org 760 Luigi Iannone 761 Huawei Technologies France S.A.S.U 763 Email: luigi.iannone@huawei.com 765 J. Bradley Chen 766 Google 768 Email: bradchen@google.com