| Internet-Draft | IP Address Privacy Considerations | July 2021 |
| Finkel & Iannone | Expires 27 January 2022 | [Page] |
This document provides an overview of privacy considerations related to user IP addresses. It includes an analysis of some current use cases for tracking of user IP addresses, mainly in the context of anti-abuse. It discusses the privacy issues associated with such tracking and provides input on mechanisms to improve the privacy of this existing model. It then captures requirements for proposed 'replacement signals' for IP addresses from this analysis. In addition, existing and under-development techniques are evaluated for fulfilling these requirements.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the mailing list (), which is archived at .¶
Source for this draft and an issue tracker can be found at https://github.com/ShivanKaul/draft-ip-address-privacy.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 January 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
The initial intention of this draft is to capture an overview of the problem space and research on proposed solutions concerning privacy considerations related to user IP addresses. The draft is likely to evolve significantly over time and may well split into multiple drafts as content is added.¶
Tracking of user IP addresses is common place on the Internet today, and is particularly widely used in the context of anti-abuse, e.g. anti-fraud, DDoS management child protection activities. IP addresses are currently used as a source of "reputation" in conjunction with other signals to protect against malicious traffic, since they are a relatively stable identifier of the origin of a request. Servers use these reputations in determining whether or not a given packet, connection, or flow corresponds to malicious traffic.¶
However, identifying the activity of users based on IP addresses has clear privacy implications ([WEBTRACKING1], [WEBTRACKING2]), e.g. user fingerprinting and cross site identity linking. Many technologies exist today to allow users to hide their IP address to avoid such tracking, e.g. VPNs ([VPNCMP1], [VPNCMP2]) or Tor ([TOR], [VPNTOR]). Several new technologies are also emerging in the landscape e.g. Gnatcatcher [GNATCATCHER], Apple Private Relay [APPLEPRIV] and Oblivious technologies (OHTTP [I-D.thomson-http-oblivious], ODoH [I-D.pauly-dprive-oblivious-doh]).¶
General consideration about privacy for Internet protocols can be found in [RFC6973]. This document is more specific and attempts to capture the following aspects of the tension between valid use cases for user identification and the related privacy concerns including:¶
(Work in progress)¶
Cyber-attackers abuse IP addresses posing a serious risk since legitimate service providers, developers, and end users may be mistakenly blacklisted which lowers the image and hurts the reputation of the service.¶
Account abuse, financial fraud, ad fraud, child abuse...¶
Cyber-attackers can leverage on the good reputation of an IP address to carry out specific attacks that wouldn't work otherwise. Main examples are Distributed Denial of Service (DDoS) attacks carried out spoofing a trusted (i.e., having good reputation) IP address (which may or may not be the victim of the attack) so that the servers used to generate the DDoS traffic actually respond to the attackers trigger (i.e., spoofed packets). Similarly Botnets may use spoofed addresses in order to gain access and attack services that would not be otherwise reachable.¶
IP addresses are sent in clear throughout the packet journey over the Internet. As such, any observer along the path can pick it up and use it for various tracking purposes. Beside basic information about the network or the device, it is possible to associate an IP address to an end user, hence, the relevance of of IP addresses for user privacy. A very short list of information about user, device, and network that can be obtained via the IP address.¶
This section aim at providing some basic information about main example of laws adopted worldwide and related to IP address privacy (usually these laws area by product of the broader user privacy protection).¶
Possible content (to focus only on technical IP address related aspects):¶
The ability to track individual people by IP address has been well understood for decades. Commercial VPNs and Tor are the most common methods of mitigating IP address-based tracking.¶
Address anonymization (e.g. [GNATCATCHER] and similar): {¶
Fundamentally, the current ecosystem operates by making the paths of a connection accountable for bad traffic, rather than the sources of the traffic itself. This is problematic because paths are shared by multiple clients and are impermanent. Ideally, clients could present proof of reputation that is separate from the IP address, and uniquely bound to a given connection.¶
Reputation services ([RFC7070]) are critical components present at multiple layers across the Internet and they are responsible for predicting whether a client will be abusive. However, these services are constrainted by available identifiers when making a decision. As a result of this constraint, IP addresses tend to be an influential signal in the reputation assigned to an identity. Identifying alternatives for this dependency on IP addresses is a goal of this document.¶
In the following the requirements of reputation signals are listed. Note that by "client(s)" it is intended an end user device (e.g., a PC or a mobile phone), while by "server(s)" it is intended a device offering an Internet service, which belong to an organisation/company but is not a personal device.¶
Some considerations about reputation services are documented already in [I-D.kucherawy-repute-consid] from the perspective of organizations being operationally reliant on a third-party service. However, these considerations are relevant for and extend to a service's impact on clients, as well.¶
With the goal of replacing IP addresses as a fundemental signal in calculating a reputation, we describe two classes of requirements: properties of a replacement reputation signal, and properties of a reputation system. Each class is further divided into requirements of the client and requirements of the service.¶
The following requirements apply to reputation signals in general, independently from whether is the reputation of a client or a server.¶
The following requirement are specific to clients.¶
Technologies exist that solve problems in similar problem spaces, however none fulfill the above criteria.¶
PrivacyPass [I-D.ietf-privacypass-protocol] is not directly applicable for this use case, but it has been shown to be a useful building block for solving numerous problems. Its design simply allows substituting a CAPTCHA challenge with a token. The token can't carry additional information about the client's reputation, the token is not guaranteed to expire, and the tokens are not bound to an identity. Furthermore, PrivacyPass does not itself specify a reputation system, therefore it cannot be used to derive an unlinkable reputation signal.¶
Trust Tokens [TRUSTTOKEN] are an extension of PrivacyPass where the tokens are allowed to carry private metadata. This additional metadata would allow for encoding information about a client's reputation, but Trust Tokens are not bound to an identity and they do not necessarily expire.¶
This document has no IANA actions.¶
TODO¶