IP Address Privacy Considerations
draft-ip-address-privacy-considerations-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Matthew Finkel , Luigi Iannone | ||
| Last updated | 2021-07-26 (Latest revision 2021-07-12) | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ip-address-privacy-considerations-01
Network Working Group M. Finkel
Internet-Draft The Tor Project
Intended status: Informational L. Iannone
Expires: 27 January 2022 Huawei
26 July 2021
IP Address Privacy Considerations
draft-ip-address-privacy-considerations-01
Abstract
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.
Discussion Venues
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.
Status of This Memo
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.
Finkel & Iannone Expires 27 January 2022 [Page 1]
Internet-Draft IP Address Privacy Considerations July 2021
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IP address tracking . . . . . . . . . . . . . . . . . . . . . 4
3.1. IP address use cases . . . . . . . . . . . . . . . . . . 4
3.1.1. Anti-abuse . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. DDoS and Botnets . . . . . . . . . . . . . . . . . . 4
3.2. Privacy implications of IP addresses . . . . . . . . . . 4
3.3. IP Privacy Protection and Law . . . . . . . . . . . . . . 5
3.4. Mitigations for IP address tracking . . . . . . . . . . . 6
4. Replacement signals for IP addresses . . . . . . . . . . . . 7
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Required properties of replacement reputation
signal . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Requirements of a reputation system . . . . . . . . . 8
4.2. Evaluation of existing technologies . . . . . . . . . . . 8
4.3. Potential new technologies . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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.
Finkel & Iannone Expires 27 January 2022 [Page 2]
Internet-Draft IP Address Privacy Considerations July 2021
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:
* An analysis of the current use cases, attempting to categorize/
group such use cases where commonalities exist
* Find ways to enhance the privacy of existing uses of IP addresses.
* Generating requirements for proposed 'replacement signals' from
this analysis (these could be different for each category/group of
use cases)
* Research to evaluate existing technologies or propose new
mechanisms for such signals
2. Terminology
(Work in progress)
* Identity: Any identifying information about an end-user or
service, be it a client or server, including IP addresses.
* Reputation: A random variable with some distribution. A
reputation can either be "bad" or "good" with some probability
according to the distribution.
Finkel & Iannone Expires 27 January 2022 [Page 3]
Internet-Draft IP Address Privacy Considerations July 2021
* Reputation context: The context in which a given reputation
applies.
* Reputation proof: A non-interactive zero knowledge proof of a
reputation signal.
* Reputation signal: A representative of a reputation.
3. IP address tracking
3.1. IP address use cases
3.1.1. Anti-abuse
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...
3.1.2. DDoS and Botnets
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.
3.2. Privacy implications of IP addresses
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.
* Determine who owns and operates the network. Searching the WHOIS
database using an IP address can provide a range of information
about the organization to which the address is assigned, including
a name, phone number, and civic address;
Finkel & Iannone Expires 27 January 2022 [Page 4]
Internet-Draft IP Address Privacy Considerations July 2021
* Through a reverse DNS lookup and/or traceroute the computer name
can be obtained, which often contains clues to logical and
physical location;
* Geo-localisation of the device (hence the user) through various
techniques [GEOIP]. Depending on the lookup tool used, this could
include country, region/state, city, latitude/longitude, telephone
area code and a location-specific map;
* Search the Internet using the IP address or computer names. The
results of these searches might reveal peer-to-peer (P2P)
activities (e.g., file sharing), records in web server log files,
or glimpses of the individual's web activities (e.g., Wikipedia
edits). These bits of individuals' online history may reveal
their political inclinations, state of health, sexuality,
religious sentiments and a range of other personal
characteristics, preoccupations and individual interests;
* Seek information on any e-mail addresses used from a particular IP
address which, in turn, could be the subject of further requests
for subscriber information.
3.3. IP Privacy Protection and Law
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):
* GDPR (General Data Protection Regulation) - EUROPE: Europe
considers IP addresses as personal identification information that
should be treated like any other personal information e.g. social
security number.
* The United States has opted for a different approach to data
protection. Instead of formulating one all-encompassing
regulation such as the EU's GDPR, the US chose to implement
sector-specific privacy and data protection regulations that work
together with state laws to safeguard American citizens' data.
* In 2020, China released the first draft of Personal Information
Protection Law (PIPL). The PIPL is the equivalent of European
GDPR and will have significant influence.
Finkel & Iannone Expires 27 January 2022 [Page 5]
Internet-Draft IP Address Privacy Considerations July 2021
* Japan Protection of Personal Information (APPI) Act (recent
changes put the act close to the GDPR model).
3.4. Mitigations for IP address tracking
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.
* Commerical VPNs offer a layer of indirection between the user and
the destination, however if the VPN endpoint's IP address is
static then this simply substitutes one address for another. In
addition, commerial VPNs replace tracking across sites with a
single company that may track their users' activities.
* Tor is another mitigation option due to its dynamic path selection
and distributed network of relays, however its current design
suffers from degraded performance. In addition, correct
application integration is difficult and not common.
* Address anonymization (e.g. [GNATCATCHER] and similar): {
- {GNATCATCHER}} is a single-hop proxy system providing more
protection against third-party tracking than a traditional
commercial VPN. However, its design maintains the industry-
standard reliance on IP addresses for anti-abuse purposes and
it provides near backwards compatibility for select services
that submit to periodic audits.
- [APPLEPRIV] iCloud Private Relay is described as using two
proxies between the client and server, and it would provide a
level of protection somewhere between a commercial VPN and Tor.
* Recent interest has resulted in new protocols such as Oblivious
DNS (ODoH (https://www.ietf.org/staging/draft-pauly-oblivious-doh-
02.html)) and Oblivious HTTP (OHTTP
(https://www.ietf.org/archive/id/draft-thomson-http-oblivious-
00.html)). While they both prevent tracking by individual
parties, they are not intended for the general-purpose web
browsing use case.
* Finally, iCloud Private Relay is described as using two proxies
between the client and server, and it would provide a level of
protection somewhere between a commercial VPN and Tor.
* Temporary addresses
Finkel & Iannone Expires 27 January 2022 [Page 6]
Internet-Draft IP Address Privacy Considerations July 2021
4. Replacement signals for IP addresses
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.
4.1. Requirements
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.
4.1.1. Required properties of replacement reputation signal
4.1.1.1. General Requirements
The following requirements apply to reputation signals in general,
independently from whether is the reputation of a client or a server.
* Reputation signals MUST NOT remain valid indefinitely. New
reputation signals periodically must be obtained periodically.
Finkel & Iannone Expires 27 January 2022 [Page 7]
Internet-Draft IP Address Privacy Considerations July 2021
* Reputation MUST NOT be transferable.
* Reputation signals MUST be bound to a context, and MUST NOT be
transferrable across contexts.
4.1.1.2. Client requirements
The following requirement are specific to clients.
* Clients MUST be able to request and present new reputation proofs
on demand.
* A reputation signal MUST NOT be linkable to any identifying
information for which the signal corresponds.
* Clients MUST be able to demonstrate good faith and improve
reputation if needed.
* Clients MUST be able to dispute their reputation.
* Clients MUST be able to determine and verify the context in which
a given reputation applies.
4.1.1.3. Server requirements
* A reputation signal MUST NOT remain valid indefinitely meaning a
client must obtain a new reputation signals periodically.
* A reputation signal MUST be bound to a reputation context, and
MUST NOT be transferable across contexts.
4.1.2. Requirements of a reputation system
4.1.2.1. Client requirements
TODO
4.1.2.2. Server requirements
TODO
4.2. Evaluation of existing technologies
Technologies exist that solve problems in similar problem spaces,
however none fulfill the above criteria.
Finkel & Iannone Expires 27 January 2022 [Page 8]
Internet-Draft IP Address Privacy Considerations July 2021
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.
4.3. Potential new technologies
5. Security Considerations
TODO
6. IANA Considerations
This document has no IANA actions.
7. References
7.1. Normative References
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/rfc/rfc6973>.
7.2. Informative References
[APPLEPRIV]
"Apple iCloud Private Relay", n.d.,
<https://appleinsider.com/articles/21/06/10/how-apple-
icloud-private-relay-works>.
[GEOIP] Dan, O., Parikh, V., and B. Davison, "IP Geolocation Using
Traceroute Location Propagation and IP Range Location
Interpolation", Companion Proceedings of the Web
Conference 2021, DOI 10.1145/3442442.3451888, April 2021,
<https://doi.org/10.1145/3442442.3451888>.
Finkel & Iannone Expires 27 January 2022 [Page 9]
Internet-Draft IP Address Privacy Considerations July 2021
[GNATCATCHER]
"Global Network Address Translation Combined with Audited
and Trusted CDN or HTTP-Proxy Eliminating
Reidentification", n.d.,
<https://github.com/bslassey/ip-blindness>.
[I-D.ietf-privacypass-protocol]
Celi, S., Davidson, A., and A. Faz-Hernandez, "Privacy
Pass Protocol Specification", Work in Progress, Internet-
Draft, draft-ietf-privacypass-protocol-01, 22 February
2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
privacypass-protocol-01>.
[I-D.kucherawy-repute-consid]
Kucherawy, M. S., "Considerations Regarding Third-Party
Reputation Services", Work in Progress, Internet-Draft,
draft-kucherawy-repute-consid-00, 27 November 2013,
<https://datatracker.ietf.org/doc/html/draft-kucherawy-
repute-consid-00>.
[I-D.pauly-dprive-oblivious-doh]
Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A.
Wood, "Oblivious DNS Over HTTPS", Work in Progress,
Internet-Draft, draft-pauly-dprive-oblivious-doh-06, 8
March 2021, <https://datatracker.ietf.org/doc/html/draft-
pauly-dprive-oblivious-doh-06>.
[I-D.thomson-http-oblivious]
Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
Progress, Internet-Draft, draft-thomson-http-oblivious-01,
21 February 2021, <https://datatracker.ietf.org/doc/html/
draft-thomson-http-oblivious-01>.
[RFC7070] Borenstein, N. and M. Kucherawy, "An Architecture for
Reputation Reporting", RFC 7070, DOI 10.17487/RFC7070,
November 2013, <https://www.rfc-editor.org/rfc/rfc7070>.
[TOR] "The Tor Project", n.d., <https://www.torproject.org/>.
[TRUSTTOKEN]
"Trust Token API Explainer", n.d.,
<https://github.com/WICG/trust-token-api>.
[VPNCMP1] Osswald, L., Haeberle, M., and M. Menth, "Performance
Comparison of VPN Solutions", Universität
Tübingen article, DOI 10.15496/PUBLIKATION-41810, May
2020, <https://doi.org/10.15496/PUBLIKATION-41810>.
Finkel & Iannone Expires 27 January 2022 [Page 10]
Internet-Draft IP Address Privacy Considerations July 2021
[VPNCMP2] Khanvilkar, S. and A. Khokhar, "Virtual private networks:
an overview with performance evaluation", IEEE
Communications Magazine Vol. 42, pp. 146-154,
DOI 10.1109/mcom.2004.1341273, October 2004,
<https://doi.org/10.1109/mcom.2004.1341273>.
[VPNTOR] Ramadhani, E., "Anonymity communication VPN and Tor: A
comparative study", n.d., <Journal of Physics Conference
Series>.
[WEBTRACKING1]
Bujlow, T., Carela-Espanol, V., Lee, B., and P. Barlet-
Ros, "A Survey on Web Tracking: Mechanisms, Implications,
and Defenses", Proceedings of the IEEE Vol. 105, pp.
1476-1510, DOI 10.1109/jproc.2016.2637878, August 2017,
<https://doi.org/10.1109/jproc.2016.2637878>.
[WEBTRACKING2]
Mishra, V., Laperdrix, P., Vastel, A., Rudametkin, W.,
Rouvoy, R., and M. Lopatka, "Don’t Count Me Out: On the
Relevance of IP Address in the Tracking Ecosystem",
Proceedings of The Web Conference 2020,
DOI 10.1145/3366423.3380161, April 2020,
<https://doi.org/10.1145/3366423.3380161>.
Acknowledgments
TODO
Authors' Addresses
Matthew Finkel
The Tor Project
Email: sysrqb@torproject.org
Luigi Iannone
Huawei Technologies France S.A.S.U
Email: luigi.iannone@huawei.com
Finkel & Iannone Expires 27 January 2022 [Page 11]