├── .circleci └── config.yml ├── .github ├── CODEOWNERS └── workflows │ ├── archive.yml │ ├── ghpages.yml │ ├── publish.yml │ └── update.yml ├── .gitignore ├── .note.xml ├── CONTRIBUTING.md ├── LICENSE.md ├── Makefile ├── README.md └── draft-irtf-pearg-ip-address-privacy-considerations.md /.circleci/config.yml: -------------------------------------------------------------------------------- 1 | version: 2 2 | jobs: 3 | build: 4 | docker: 5 | - image: martinthomson/i-d-template:latest 6 | working_directory: ~/draft 7 | 8 | steps: 9 | - run: 10 | name: "Print Configuration" 11 | command: | 12 | xml2rfc --version 13 | gem list -q kramdown-rfc2629 14 | echo -n 'mmark '; mmark --version 15 | 16 | - restore_cache: 17 | name: "Restoring cache - Git" 18 | keys: 19 | - v2-cache-git-{{ .Branch }}-{{ .Revision }} 20 | - v2-cache-git-{{ .Branch }} 21 | - v2-cache-git- 22 | 23 | - restore_cache: 24 | name: "Restoring cache - References" 25 | keys: 26 | - v1-cache-references-{{ epoch }} 27 | - v1-cache-references- 28 | 29 | # Workaround for https://discuss.circleci.com/t/22437 30 | - run: 31 | name: Tag Checkout 32 | command: | 33 | if [ -n "$CIRCLE_TAG" ] && [ -d .git ]; then 34 | remote=$(echo "$CIRCLE_REPOSITORY_URL" | \ 35 | sed -e 's,/^git.github.com:,https://github.com/,') 36 | git fetch -f "$remote" "refs/tags/$CIRCLE_TAG:refs/tags/$CIRCLE_TAG" || \ 37 | (echo 'Removing .git cache for tag build'; rm -rf .git) 38 | fi 39 | 40 | - checkout 41 | 42 | # Build txt and html versions of drafts 43 | - run: 44 | name: "Build Drafts" 45 | command: "make 'CLONE_ARGS=--reference ~/git-reference'" 46 | 47 | # Update editor's copy on gh-pages 48 | - run: 49 | name: "Update GitHub Pages" 50 | command: | 51 | if [ "${CIRCLE_TAG#draft-}" == "$CIRCLE_TAG" ]; then 52 | make gh-pages 53 | fi 54 | 55 | # For tagged builds, upload to the datatracker. 56 | - deploy: 57 | name: "Upload to Datatracker" 58 | command: | 59 | if [ "${CIRCLE_TAG#draft-}" != "$CIRCLE_TAG" ]; then 60 | make upload 61 | fi 62 | 63 | # Archive GitHub Issues 64 | - run: 65 | name: "Archive GitHub Issues" 66 | command: "make archive || make archive DISABLE_ARCHIVE_FETCH=true && make gh-archive" 67 | 68 | # Create and store artifacts 69 | - run: 70 | name: "Create Artifacts" 71 | command: "make artifacts CI_ARTIFACTS=/tmp/artifacts" 72 | 73 | - store_artifacts: 74 | path: /tmp/artifacts 75 | 76 | - run: 77 | name: "Prepare for Caching" 78 | command: "git reflog expire --expire=now --all && git gc --prune=now" 79 | 80 | - save_cache: 81 | name: "Saving Cache - Git" 82 | key: v2-cache-git-{{ .Branch }}-{{ .Revision }} 83 | paths: 84 | - ~/draft/.git 85 | 86 | - save_cache: 87 | name: "Saving Cache - Drafts" 88 | key: v1-cache-references-{{ epoch }} 89 | paths: 90 | - ~/.cache/xml2rfc 91 | 92 | 93 | workflows: 94 | version: 2 95 | build: 96 | jobs: 97 | - build: 98 | filters: 99 | tags: 100 | only: /.*?/ 101 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Automatically generated CODEOWNERS 2 | # Regenerate with `make update-codeowners` 3 | draft-irtf-pearg-ip-address-privacy-considerations.md sysrqb@apple.com lassey@chromium.org luigi.iannone@huawei.com bradchen@google.com 4 | -------------------------------------------------------------------------------- /.github/workflows/archive.yml: -------------------------------------------------------------------------------- 1 | name: "Archive Issues and Pull Requests" 2 | 3 | on: 4 | schedule: 5 | - cron: '0 0 * * 0,2,4' 6 | repository_dispatch: 7 | types: [archive] 8 | workflow_dispatch: 9 | inputs: 10 | archive_full: 11 | description: 'Recreate the archive from scratch' 12 | default: false 13 | type: boolean 14 | 15 | jobs: 16 | build: 17 | name: "Archive Issues and Pull Requests" 18 | runs-on: ubuntu-latest 19 | steps: 20 | - name: "Checkout" 21 | uses: actions/checkout@v4 22 | 23 | # Note: No caching for this build! 24 | 25 | - name: "Update Archive" 26 | uses: martinthomson/i-d-template@v1 27 | env: 28 | ARCHIVE_FULL: ${{ inputs.archive_full }} 29 | with: 30 | make: archive 31 | token: ${{ github.token }} 32 | 33 | - name: "Update GitHub Pages" 34 | uses: martinthomson/i-d-template@v1 35 | with: 36 | make: gh-archive 37 | token: ${{ github.token }} 38 | 39 | - name: "Save Archive" 40 | uses: actions/upload-artifact@v4 41 | with: 42 | path: archive.json 43 | -------------------------------------------------------------------------------- /.github/workflows/ghpages.yml: -------------------------------------------------------------------------------- 1 | name: "Update Editor's Copy" 2 | 3 | on: 4 | push: 5 | paths-ignore: 6 | - README.md 7 | - CONTRIBUTING.md 8 | - LICENSE.md 9 | - .gitignore 10 | pull_request: 11 | paths-ignore: 12 | - README.md 13 | - CONTRIBUTING.md 14 | - LICENSE.md 15 | - .gitignore 16 | 17 | jobs: 18 | build: 19 | name: "Update Editor's Copy" 20 | runs-on: ubuntu-latest 21 | steps: 22 | - name: "Checkout" 23 | uses: actions/checkout@v4 24 | 25 | - name: "Setup" 26 | id: setup 27 | run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" 28 | 29 | - name: "Caching" 30 | uses: actions/cache@v4 31 | with: 32 | path: | 33 | .refcache 34 | .venv 35 | .gems 36 | node_modules 37 | .targets.mk 38 | key: i-d-${{ steps.setup.outputs.date }} 39 | restore-keys: i-d- 40 | 41 | - name: "Build Drafts" 42 | uses: martinthomson/i-d-template@v1 43 | with: 44 | token: ${{ github.token }} 45 | 46 | - name: "Update GitHub Pages" 47 | uses: martinthomson/i-d-template@v1 48 | if: ${{ github.event_name == 'push' }} 49 | with: 50 | make: gh-pages 51 | token: ${{ github.token }} 52 | 53 | - name: "Archive Built Drafts" 54 | uses: actions/upload-artifact@v4 55 | with: 56 | path: | 57 | draft-*.html 58 | draft-*.txt 59 | -------------------------------------------------------------------------------- /.github/workflows/publish.yml: -------------------------------------------------------------------------------- 1 | name: "Publish New Draft Version" 2 | 3 | on: 4 | push: 5 | tags: 6 | - "draft-*" 7 | workflow_dispatch: 8 | inputs: 9 | email: 10 | description: "Submitter email" 11 | default: "" 12 | type: string 13 | 14 | jobs: 15 | build: 16 | name: "Publish New Draft Version" 17 | runs-on: ubuntu-latest 18 | steps: 19 | - name: "Checkout" 20 | uses: actions/checkout@v4 21 | 22 | # See https://github.com/actions/checkout/issues/290 23 | - name: "Get Tag Annotations" 24 | run: git fetch -f origin ${{ github.ref }}:${{ github.ref }} 25 | 26 | - name: "Setup" 27 | id: setup 28 | run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" 29 | 30 | - name: "Caching" 31 | uses: actions/cache@v4 32 | with: 33 | path: | 34 | .refcache 35 | .venv 36 | .gems 37 | node_modules 38 | .targets.mk 39 | key: i-d-${{ steps.setup.outputs.date }} 40 | restore-keys: i-d- 41 | 42 | - name: "Build Drafts" 43 | uses: martinthomson/i-d-template@v1 44 | with: 45 | token: ${{ github.token }} 46 | 47 | - name: "Upload to Datatracker" 48 | uses: martinthomson/i-d-template@v1 49 | with: 50 | make: upload 51 | env: 52 | UPLOAD_EMAIL: ${{ inputs.email }} 53 | 54 | - name: "Archive Submitted Drafts" 55 | uses: actions/upload-artifact@v4 56 | with: 57 | path: "versioned/draft-*-[0-9][0-9].*" 58 | -------------------------------------------------------------------------------- /.github/workflows/update.yml: -------------------------------------------------------------------------------- 1 | name: "Update Generated Files" 2 | # This rule is not run automatically. 3 | # It can be run manually to update all of the files that are part 4 | # of the template, specifically: 5 | # - README.md 6 | # - CONTRIBUTING.md 7 | # - .note.xml 8 | # - .github/CODEOWNERS 9 | # - Makefile 10 | # 11 | # 12 | # This might be useful if you have: 13 | # - added, removed, or renamed drafts (including after adoption) 14 | # - added, removed, or changed draft editors 15 | # - changed the title of drafts 16 | # 17 | # Note that this removes any customizations you have made to 18 | # the affected files. 19 | on: workflow_dispatch 20 | 21 | jobs: 22 | build: 23 | name: "Update Files" 24 | runs-on: ubuntu-latest 25 | steps: 26 | - name: "Checkout" 27 | uses: actions/checkout@v4 28 | 29 | - name: "Update Generated Files" 30 | uses: martinthomson/i-d-template@v1 31 | with: 32 | make: update-files 33 | token: ${{ github.token }} 34 | 35 | - name: "Push Update" 36 | run: git push 37 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.html 2 | *.pdf 3 | *.redxml 4 | *.swp 5 | *.txt 6 | *.upload 7 | *~ 8 | .tags 9 | /*-[0-9][0-9].xml 10 | /.gems/ 11 | /.refcache 12 | /.targets.mk 13 | /.venv/ 14 | /.vscode/ 15 | /lib 16 | /node_modules/ 17 | /versioned/ 18 | Gemfile.lock 19 | archive.json 20 | draft-irtf-pearg-ip-address-privacy-considerations.xml 21 | package-lock.json 22 | report.xml 23 | !requirements.txt 24 | -------------------------------------------------------------------------------- /.note.xml: -------------------------------------------------------------------------------- 1 | 2 | Discussion of this document takes place on the 3 | mailing list (), 4 | which is archived at . 5 | Source for this draft and an issue tracker can be found at 6 | . 7 | 8 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | This repository relates to activities in the Internet Engineering Task Force 4 | ([IETF](https://www.ietf.org/)). All material in this repository is considered 5 | Contributions to the IETF Standards Process, as defined in the intellectual 6 | property policies of IETF currently designated as 7 | [BCP 78](https://www.rfc-editor.org/info/bcp78), 8 | [BCP 79](https://www.rfc-editor.org/info/bcp79) and the 9 | [IETF Trust Legal Provisions (TLP) Relating to IETF Documents](http://trustee.ietf.org/trust-legal-provisions.html). 10 | 11 | Any edit, commit, pull request, issue, comment or other change made to this 12 | repository constitutes Contributions to the IETF Standards Process 13 | (https://www.ietf.org/). 14 | 15 | You agree to comply with all applicable IETF policies and procedures, including, 16 | BCP 78, 79, the TLP, and the TLP rules regarding code components (e.g. being 17 | subject to a Simplified BSD License) in Contributions. 18 | ## Working Group Information 19 | 20 | Discussion of this work occurs on the [Privacy Enhancements and Assessments Research Group 21 | Research Group mailing list](mailto:pearg@irtf.org) 22 | ([archive](https://mailarchive.ietf.org/arch/browse/pearg/), 23 | [subscribe](https://mailman.irtf.org/mailman/listinfo/pearg/)). 24 | In addition to contributions in GitHub, you are encouraged to participate in 25 | discussions there. 26 | 27 | **Note**: Some working groups adopt a policy whereby substantive discussion of 28 | technical issues needs to occur on the mailing list. 29 | 30 | You might also like to familiarize yourself with other 31 | [Research Group documents](https://datatracker.ietf.org/rg/pearg/documents/). 32 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # License 2 | 3 | See the 4 | [guidelines for contributions](https://github.com/IRTF-PEARG/draft-ip-address-privacy/blob/main/CONTRIBUTING.md). 5 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | LIBDIR := lib 2 | include $(LIBDIR)/main.mk 3 | 4 | $(LIBDIR)/main.mk: 5 | ifneq (,$(shell grep "path *= *$(LIBDIR)" .gitmodules 2>/dev/null)) 6 | git submodule sync 7 | git submodule update $(CLONE_ARGS) --init 8 | else 9 | git clone -q --depth 10 $(CLONE_ARGS) \ 10 | -b main https://github.com/martinthomson/i-d-template $(LIBDIR) 11 | endif 12 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # IP Address Privacy Considerations 2 | 3 | This is the working area for the individual Internet-Draft, "IP Address Privacy Considerations". 4 | 5 | * [Editor's Copy](https://IRTF-PEARG.github.io/draft-ip-address-privacy/#go.draft-irtf-pearg-ip-address-privacy-considerations.html) 6 | * [Datatracker Page](https://datatracker.ietf.org/doc/draft-irtf-pearg-ip-address-privacy-considerations) 7 | * [Individual Draft](https://datatracker.ietf.org/doc/html/draft-irtf-pearg-ip-address-privacy-considerations) 8 | * [Compare Editor's Copy to Individual Draft](https://IRTF-PEARG.github.io/draft-ip-address-privacy/#go.draft-irtf-pearg-ip-address-privacy-considerations.diff) 9 | 10 | 11 | ## Contributing 12 | 13 | See the 14 | [guidelines for contributions](https://github.com/IRTF-PEARG/draft-ip-address-privacy/blob/main/CONTRIBUTING.md). 15 | 16 | Contributions can be made by creating pull requests. 17 | The GitHub interface supports creating pull requests using the Edit (✏) button. 18 | 19 | 20 | ## Command Line Usage 21 | 22 | Formatted text and HTML versions of the draft can be built using `make`. 23 | 24 | ```sh 25 | $ make 26 | ``` 27 | 28 | Command line usage requires that you have the necessary software installed. See 29 | [the instructions](https://github.com/martinthomson/i-d-template/blob/main/doc/SETUP.md). 30 | 31 | -------------------------------------------------------------------------------- /draft-irtf-pearg-ip-address-privacy-considerations.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "IP Address Privacy Considerations" 3 | docname: draft-irtf-pearg-ip-address-privacy-considerations-latest 4 | v: 3 5 | submissionType: IRTF 6 | category: info 7 | area: IRTF 8 | wg: PEARG 9 | venue: 10 | group: "PEARG" 11 | type: "Research Group" 12 | mail: "pearg@ietf.org" 13 | arch: "https://mailarchive.ietf.org/arch/browse/pearg/" 14 | github: "IRTF-PEARG/draft-ip-address-privacy" 15 | latest: "https://pearg.org/draft-ip-address-privacy/draft-irtf-pearg-ip-address-privacy-considerations.html" 16 | keyword: 17 | - IP 18 | - privacy 19 | author: 20 | - 21 | ins: M. Finkel 22 | name: Matthew Finkel 23 | organization: Apple Inc. 24 | email: sysrqb@apple.com 25 | - 26 | ins: B. Lassey 27 | name: Bradford Lassey 28 | organization: Google 29 | email: lassey@chromium.org 30 | - 31 | ins: L. Iannone 32 | name: Luigi Iannone 33 | org: Huawei Technologies France S.A.S.U 34 | abbrev: Huawei 35 | email: luigi.iannone@huawei.com 36 | - 37 | ins: J. B. Chen 38 | name: J. Bradley Chen 39 | organization: Google 40 | email: bradchen@google.com 41 | 42 | normative: 43 | 44 | informative: 45 | 46 | WEBTRACKING1: DOI.10.1109/JPROC.2016.2637878 47 | WEBTRACKING2: DOI.10.1145/3366423.3380161 48 | VPNCMP1: DOI.10.15496/publikation-41810 49 | VPNCMP2: DOI.10.1109/MCOM.2004.1341273 50 | GEOIP: DOI.10.1145/3442442.3451888 51 | TOR: 52 | title: "The Tor Project" 53 | target: https://www.torproject.org/ 54 | VPNTOR: 55 | title: "Anonymity communication VPN and Tor: A comparative study" 56 | author: 57 | ins: E. Ramadhani 58 | target: Journal of Physics Conference Series 59 | GNATCATCHER: 60 | title: "Global Network Address Translation Combined with Audited and Trusted CDN or HTTP-Proxy Eliminating Reidentification" 61 | target: https://github.com/bslassey/ip-blindness 62 | APPLEPRIV: 63 | title: "Apple iCloud Private Relay" 64 | target: https://www.apple.com/icloud/docs/iCloud_Private_Relay_Overview_Dec2021.pdf 65 | TRUSTTOKEN: 66 | title: "Trust Token API Explainer" 67 | target: https://github.com/WICG/trust-token-api 68 | WEBAUTHN: 69 | title: "Web Authentication: An API for accessing Public Key Credentials Level 2" 70 | target: https://www.w3.org/TR/webauthn-2/ 71 | GDPR: 72 | title: "General Data Protection Regulation" 73 | target: https://gdpr.eu/tag/gdpr/ 74 | APPI: 75 | title: "Japan - Data Protection Overview" 76 | target: https://www.dataguidance.com/notes/japan-data-protection-overview 77 | LGPD: 78 | title: "General Personal Data Protection Law (Brazil)" 79 | target: https://iapp.org/media/pdf/resource_center/Brazilian_General_Data_Protection_Law.pdf 80 | PIPL-C: 81 | title: "Personal Information Protection Law of the People's Republic of China (Chinese)" 82 | target: http://www.npc.gov.cn/npc/c30834/202108/a8c4e3672c74491a80b53a172bb753fe.shtml 83 | PIPL: 84 | title: "Personal Information Protection Law of the People's Republic of China (English translation)" 85 | target: https://digichina.stanford.edu/work/translation-personal-information-protection-law-of-the-peoples-republic-of-china-effective-nov-1-2021/ 86 | PIPEDA: 87 | title: "Personal Information Protection and Electronic Documents Act" 88 | target: https://laws-lois.justice.gc.ca/PDF/P-8.6.pdf 89 | IP2009: 90 | title: "Washington Court Rules that IP Addresses are not Personally Identifiable Information" 91 | target: https://www.huntonprivacyblog.com/2009/07/10/washington-court-rules-that-ip-addresses-are-not-personally-identifiable-information/ 92 | CCPA: 93 | title: "California Consumer Privacy Act (CCPA)" 94 | target: https://oag.ca.gov/privacy/ccpa 95 | MOZ_NET_PART: 96 | title: "State Partitioning" 97 | target: https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning#network_partitioning 98 | BRAVE_NET_PART: 99 | title: "Partitioning network-state for privacy" 100 | target: https://brave.com/privacy-updates/14-partitioning-network-state/ 101 | CHROME_NET_PART: 102 | title: "Network State Partitioning" 103 | target: https://chromestatus.com/feature/6713488334389248 104 | 3P_COOKIES_CHROME: 105 | title: "Building a more private web: A path towards making third party cookies obsolete" 106 | target: https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html 107 | 3P_COOKIES_WEBKIT: 108 | title: "Tracking Prevention in WebKit: The Default Cookie Policy" 109 | target: https://webkit.org/tracking-prevention/#the-default-cookie-policy 110 | 111 | --- abstract 112 | 113 | This document provides an overview of privacy considerations related to user IP 114 | addresses. It includes an analysis of some current use cases for tracking of 115 | user IP addresses, grouping them into two categories: personalization and 116 | anti-abuse. This document also discusses the 117 | privacy issues associated with such tracking and provides input on mechanisms 118 | to improve the privacy of this existing model. It then captures requirements 119 | for proposed 'replacement signals' for IP addresses from this analysis. In 120 | addition, existing and under-development techniques are evaluated for 121 | fulfilling these requirements. 122 | 123 | 124 | --- middle 125 | 126 | # Introduction 127 | 128 | The initial intention of this draft is to capture an overview of the problem 129 | space and research on proposed solutions concerning privacy considerations 130 | related to user IP addresses (informally, IP privacy). The draft is likely to 131 | evolve significantly over time and may well split into multiple drafts as 132 | content is added. 133 | 134 | Tracking of IP addresses is common place on the Internet today, and falls 135 | roughly into two broad categories. The first is personalization, the tailoring 136 | of content for a given user. The second is anti-abuse: e.g. anti-fraud, DDoS 137 | management, and child protection activities. The latter includes uses of IP 138 | addresses to determine "reputation" {{!RFC5782}} in conjunction with other signals to 139 | protect against malicious traffic, since these addresses are usually a 140 | relatively stable identifier of a request's origin. Servers use these 141 | reputations in determining whether or not a given packet, connection, or flow 142 | likely corresponds to malicious traffic. In addition, IP addresses are used in 143 | investigating past events and attributing responsibility. 144 | 145 | Personalizing content based on the user's IP address has clear 146 | privacy implications ({{WEBTRACKING1}}, {{WEBTRACKING2}}), e.g. user 147 | fingerprinting and cross-site identity linking. Many technologies exist today 148 | that allow users to obfuscate their external IP address to avoid such tracking, 149 | e.g. VPNs ({{VPNCMP1}}, {{VPNCMP2}}) and Tor ({{TOR}}, {{VPNTOR}}). Several new 150 | technologies are emerging, as well, in the landscape, e.g. Apple iCloud Private 151 | Relay {{APPLEPRIV}}, Gnatcatcher {{GNATCATCHER}}, and Oblivious technologies 152 | (ODoH {{?I-D.pauly-dprive-oblivious-doh}}, OHTTP {{?I-D.thomson-ohai-ohttp}}). 153 | 154 | General consideration about privacy for Internet protocols can be found in 155 | {{!RFC6973}}. This document builds upon {{!RFC6973}} and more specifically 156 | attempts to capture the following aspects of the tension between use of IP 157 | addresses to prevent abuse, and some users' desire to prevent overzealous 158 | personalization: 159 | 160 | * An analysis of the current use cases, attempting to categorize/group such use 161 | cases where commonalities exist. 162 | 163 | * Find ways to enhance the privacy of existing uses of IP addresses. 164 | 165 | * Generating requirements for proposed 'replacement signals' from this analysis 166 | (these could be different for each category/group of use cases). 167 | 168 | * Research to evaluate existing technologies or propose new mechanisms for such 169 | signals. 170 | 171 | With the goal of replacing IP addresses as a fundemental signal, the following 172 | sections enumerate existing use cases and describe applicable substitution 173 | signals. This description may not be exhaustive due to the breadth of IP 174 | address usage. 175 | 176 | # Terminology 177 | 178 | (Work in progress) 179 | 180 | This section defines basic terms used in this document, with references to 181 | pre-existing definitions as appropriate. As in {{!RFC4949}} and {{!RFC6973}}, 182 | each entry is preceded by a dollar sign ($) and a space for automated searching. 183 | 184 | $ Identity: 185 | 186 | : Extending {{!RFC6973}}, an individual's attributes may only identify an 187 | individual up to an anonymity set within a given context. 188 | 189 | $ Reputation: 190 | 191 | : A random variable with some distribution. A reputation can either be "bad" or 192 | "good" with some probability according to the distribution. 193 | 194 | $ Reputation context: 195 | 196 | : The context in which a given reputation applies. 197 | 198 | $ Reputation proof: 199 | 200 | : A non-interactive zero knowledge proof of a reputation signal. 201 | 202 | $ Reputation signal: 203 | 204 | : A representative of a reputation. 205 | 206 | $ Service provider: 207 | 208 | : An entity that provides a service on the Internet; examples services include 209 | hosted e-mail, e-commerce sites, and cloud computing platforms. 210 | 211 | ## Categories of Interaction 212 | 213 | Interactions between parties on the Internet may be classified into one (or 214 | more) of three categories: 215 | 216 | Private Interaction: 217 | 218 | : An interaction occuring between mutually consenting parties, with a mutual 219 | expectation of privacy. 220 | 221 | Public Interaction: 222 | 223 | : An interaction occuring between multiple parties that are not engaged in a 224 | Private Interaction. 225 | 226 | Consumption: 227 | 228 | : An interaction where one party primarily receives information from other 229 | parties. 230 | 231 | 232 | # Mitigations for IP address tracking 233 | 234 | The ability to track individual people by IP address has been well understood 235 | for decades. Due to the prevalence of systems that profile users using their IP 236 | addresses, countermeasures have been developed. Commercial VPNs and Tor are the 237 | most common methods of mitigating IP address-based tracking. 238 | 239 | - Commercial VPNs offer a layer of indirection between the user and the 240 | destination, however if the VPN endpoint's IP address is static then this 241 | simply substitutes one address for another. In addition, commercial VPNs 242 | replace tracking across sites with a single company that may track their 243 | users' activities. 244 | 245 | - Tor is another mitigation option due to its dynamic path selection and 246 | distributed network of relays, however its current design suffers from 247 | degraded performance. In addition, correct application integration is 248 | difficult and not common. 249 | 250 | - Address anonymization (e.g. {{GNATCATCHER}} and similar): 251 | 252 | - {{GNATCATCHER}} is a single-hop proxy system providing more protection 253 | against third-party tracking than a traditional commercial VPN. However, 254 | its design maintains the industry-standard reliance on IP addresses for 255 | anti-abuse purposes and it provides near backwards compatibility for select 256 | services that submit to periodic audits. 257 | 258 | - {{APPLEPRIV}} iCloud Private Relay is described as using two proxies 259 | between the client and server, and it would provide a level of protection 260 | somewhere between a commercial VPN and Tor. 261 | 262 | - Recent interest has resulted in new protocols such as Oblivious DNS 263 | ([ODoH]({{?I-D.pauly-dprive-oblivious-doh}})) and Oblivious HTTP 264 | ([OHTTP]({{?I-D.thomson-ohai-ohttp}})). While they both prevent tracking by 265 | individual parties, they are not intended for the general-purpose web 266 | browsing use case. 267 | 268 | - The use of temporary addresses is another way to limit IP address-based 269 | tracking. Changing addresses over time reduces the window of time during 270 | which it is possible to easily correlate network activity when the same 271 | address is employed for multiple transactions by the same host. Temporary 272 | addresses have been introduced only for IPv6, as an extension of its 273 | Stateless Address Configuration mechanism ({{?RFC8981}}). However, since the 274 | network prefix remains the same, in many cases it remains possible to 275 | identify a cellular user or a household. 276 | 277 | # Accepted Uses of IP Addresses 278 | 279 | The mitigations described above are often designed to prevent unwanted uses of 280 | IP addresses such as profiling users. However, they often prevent other uses of 281 | IP addresses that users did not necessarily want or intend to disrupt. 282 | 283 | ## Anti-abuse {#antiabuse} 284 | 285 | IP addresses are a passive identifier used in defensive operations. They allow 286 | correlating requests, attribution, and recognizing numerous attacks, including: 287 | 288 | - account takeover 289 | - advertising fraud (e.g., click-fraud) 290 | - disinformation operations (e.g., detecting scaled and/or coordinated attacks) 291 | - financial fraud (e.g., stolen credit cards, email account compromise) 292 | - malware/ransomware (e.g., detecting C2 connections) 293 | - phishing 294 | - real-world harm (e.g., child abuse) 295 | - scraping (e.g., e-commerce, search) 296 | - spam (e.g., email, comments) 297 | - vulnerability exploitation (e.g., "hacking") 298 | 299 | Malicious activity recognized by one service provider may be shared with other 300 | services {{!RFC5782}} as a way of limiting harm. 301 | 302 | ## DDoS and Botnets 303 | 304 | Cyber-attackers can leverage the good reputation of an IP address to carry out 305 | specific attacks that wouldn't work otherwise. Main examples are Distributed 306 | Denial of Service (DDoS) attacks carried out by spoofing a trusted (i.e., 307 | having good reputation) IP address (which may or may not be the victim of the 308 | attack) so that the servers used to generate the DDoS traffic actually respond 309 | to the attackers trigger (i.e., spoofed packets). Similarly botnets may use 310 | spoofed addresses in order to gain access and attack services that otherwise 311 | would not be reachable. 312 | 313 | ## Multi-platform threat models 314 | 315 | As siloed (single-platform) abuse defenses improve, abusers have moved to 316 | multi-platform threat models. For example, a public discussion platform with a 317 | culture of anonymity may redirect traffic to YouTube as a video library, 318 | bypassing YouTube defenses that otherwise reduce exposure of potentially 319 | harmful content. Similarly, a minor could be solicited by an adult 320 | impersonating a child on a popular social media platform, then redirected to a 321 | smaller, less established and less defended platform where illegal activity 322 | could occur. Phishing attacks are also common. There are many such 323 | cross-platform abuse models and they cause significant public harm. IP 324 | addresses are commonly used to investigate, understand and communicate these 325 | cross-platform threats. There are very few alternatives for cross-platform 326 | signals. 327 | 328 | ## Rough Geolocation 329 | 330 | A rough geolocation can be inferred from a client's IP address, which is 331 | commonly known as either IP-Geo or Geo-IP. This information can have several 332 | useful implications. When abuse extends beyond attacks in the digital space, IP 333 | addresses may help identify the physical location of real-world harm, such as 334 | child exploitation. 335 | 336 | ## Legal compliance 337 | 338 | Legal and regulatory compliance often needs to take the jurisdiction of the 339 | client into account. This is especially important in cases where regulations 340 | are mutually contradictory (i.e. there is no way to be in legal compliance 341 | universally). Because Geo-IP is often bound to the IP addresses a given ISP 342 | uses, and ISPs tend to operate within national borders, Geo-IP tends to be a 343 | good fit for server operators to comply with local laws and regulations 344 | 345 | ## Contractual obligations 346 | 347 | Similar to legal compliance, some content and media has licensing terms that 348 | are valid only for certain locations. The rough geolocation derived from IP 349 | addresses allow this content to be hosted on the web. 350 | 351 | ## Locally relevant content 352 | 353 | Rough geolocation can also be useful to tailor content to the client's location 354 | simply to improve their experience. A search for "coffee shop" can include 355 | results of coffee shops within reasonable travel distance from a user rather 356 | than generic information about coffee shops, a merchant's website could show 357 | brick and mortar stores near the user and a news site can surface locally 358 | relevant news stories that wouldn't be as interesting to visitors from other 359 | locations. 360 | 361 | # Implications of IP addresses 362 | 363 | ## Next-User Implications 364 | 365 | When an attacker uses IP addresses with "good" reputations, the collateral 366 | damage poses a serious risk to legitimate service providers, developers, and 367 | end users. IP addresses may become assocaited with a "bad" reputation from 368 | temporal abuse, and legitimate users may be affected by blocklists as a result. 369 | This unintended impact may hurt the reputation of a service or an end user 370 | {{!RFC6269}}. 371 | 372 | ## Privacy Implications 373 | 374 | IP addresses are sent in the clear throughout the packet journey over the 375 | Internet. As such, any observer along the path can pick it up and use it for 376 | various tracking purposes. Beside basic information about the network or the 377 | device, it is possible to associate an IP address to an end user, hence, the 378 | relevance of IP addresses for user privacy. A very short list of information 379 | about user, device, and network that can be obtained via the IP address. 380 | 381 | - Determine who owns and operates the network. Searching the WHOIS database 382 | using an IP address can provide a range of information about the organization 383 | to which the address is assigned, including a name, phone number, and civic 384 | address; 385 | 386 | - Through a reverse DNS lookup and/or traceroute the computer name can be 387 | obtained, which often contains clues to logical and physical location; 388 | 389 | - Geo-localisation of the device (hence the user) through various techniques 390 | {{GEOIP}}. Depending on the lookup tool used, this could include country, 391 | region/state, city, latitude/longitude, telephone area code and a 392 | location-specific map; 393 | 394 | - Search the Internet using the IP address or computer names. The results of 395 | these searches might reveal peer-to-peer (P2P) activities (e.g., file 396 | sharing), records in web server log files, or glimpses of the individual's 397 | web activities (e.g., Wikipedia edits). These bits of individuals' online 398 | history may reveal their political inclinations, state of health, sexuality, 399 | religious sentiments and a range of other personal characteristics, 400 | preoccupations and individual interests; 401 | 402 | - Seek information on any e-mail addresses used from a particular IP address 403 | which, in turn, could be the subject of further requests for subscriber 404 | information. 405 | 406 | ## Cross-site vs Same-site 407 | 408 | In a web context, IP Addresses can be used to link a user's activity both 409 | within a single site and across multiple sites. Users may want to have a single 410 | site recognize them within a browsing session or across browsing sessions and 411 | in fact cookies are a mechanism to do exactly that. If IP Addresses are only 412 | stable within the context a first-party cookie, they don't represent any 413 | additional privacy threat. However, since clients are currently in control of 414 | their first-party cookies, abusive clients can delete their cookies in an 415 | effort to evade detection. IP Addresses currently allow counter-abuse detection 416 | to track many such abusive clients across cookie deletions. However, IP 417 | Addresses, along with other fingerprinting techniques, also allow the linking 418 | of client identity across sites in the web context. Third-party cookies can 419 | also allow such a capability, but in a more limited manner as practically 420 | speaking no one third-party cookie is present across all websites. Also, 421 | browsers are increasingly putting limits on the ability to use third-party 422 | cookies in order to combat these threats {{3P_COOKIES_CHROME}} and 423 | {{3P_COOKIES_WEBKIT}}. Other network related information can also be used to 424 | link client identity across sites, but that is increasingly being seen as a bug 425 | to be addressed by browsers through network state partitioning (e.g. 426 | {{MOZ_NET_PART}}, {{BRAVE_NET_PART}}, {{CHROME_NET_PART}}). Finally, the above 427 | discussion uses the web and browsers as a concrete example, but this 428 | generalizes to other contexts such as linking user identity across VoIP 429 | solutions, DNS resolvers, video streaming platforms etc. 430 | 431 | # IP Privacy Protection and Law 432 | 433 | Various countries, in the last decade, have adopted, or updated, laws that aim 434 | at protecting citizens privacy, which includes IP addresses. Very often, these 435 | laws are actually part of larger regulatory frameworks aimed at protecting 436 | users' Personal Identifiable Information (PII) in a broad sense. {{table:laws}} 437 | provides a snapshot of relevant existing regulations. 438 | 439 | |Country|Law|IP Address is PII| 440 | |-|-|-| 441 | |Brazil |{{LGPD}} - Lei General de Protecao de Dados Pessoals |Yes (not explicitly stated)| 442 | |Canada |{{PIPEDA}} - Personal Information Protection and Electronic Documents Act|Yes | 443 | |China |{{PIPL-C}}{{PIPL}} - Personal Information Protection Law |Yes| 444 | |European Union |{{GDPR}} - General Data Protection Regulation |Yes| 445 | |Japan |{{APPI}} - Act of Protection of Personal Information |Yes (including anonymized data)| 446 | {: #table:laws title="Relevant privacy laws and regulations"} 447 | 448 | All of the major laws recognizes IP addresses as personal identification 449 | information when there is sufficiently strong correlation between an address 450 | and a person or when combined with other information to create that 451 | correlation. Brazil does not mention IP addresses explicitly but includes them 452 | de facto. Japan does protect even anonymized data. All require an explicit 453 | action from the user to grant permission to use PII, except for Canada that 454 | allows implicit consent. Note that all laws include exceptions on the type of 455 | consent, which, however are difficult to summarize. USA does not have a general 456 | federal law, but state sector-specific laws pertaining to privacy that would be 457 | too difficult to summarize (see {{CCPA}} as an example). Depending on the 458 | state, IP addresses may not be considered as personally identifiable 459 | information {{IP2009}}. 460 | 461 | 462 | # Replacement signals for IP addresses 463 | 464 | Fundamentally, the current ecosystem operates by making the immediate peer of a 465 | connection accountable for bad traffic, rather than the source of the traffic 466 | itself. This is problematic because in some network architectures the peer node 467 | of the connection is simply routing traffic for other clients, and any client's 468 | use of that node may be only temporary. Ideally, clients could present 469 | appropriate identification end-to-end that is separate from the IP address, and 470 | uniquely bound to a given connection. 471 | 472 | ## Signals 473 | 474 | There are 7 classes of signals identified in this document that may be used in 475 | place of IP addresses. A signal's provenance is a critical property and will be 476 | discussed in {{provenance}}. 477 | 478 | ADDRESS_ESCROW: 479 | 480 | :Provides sufficient information for retroactively obtaining a client's IP 481 | address. 482 | 483 | IDENTITY_TRANSPARENCY: 484 | 485 | : Reveals a person's identity within a context. 486 | 487 | IS_HUMAN: 488 | 489 | : Informs the recipient that, most likely, a human recently proved their 490 | presence on the opposite end of the connection. 491 | 492 | PEER_INTEGRITY: 493 | 494 | : Provides a secure, remote attestation of hardware and/or software state. 495 | 496 | REIDENTIFICATION: 497 | 498 | : Provides a mechanism for identifying the same user across different 499 | connections within a time period. 500 | 501 | REPUTATION: 502 | 503 | : Provides the recipient with a proof of reputation from a reputation provider. 504 | 505 | SOURCE_ASN: 506 | 507 | : Reveals the ASN from which the client is connecting. 508 | 509 | In some situations one of the above signals may be a sufficient replacement 510 | signal in isolation, or more than one signal may be needed in combination. 511 | 512 | Separately, there are three signal categories that are out-of-scope for this 513 | document but are important improvements for mitigating abuse on platforms. 514 | 515 | Publisher norms: 516 | 517 | : Standard expections of publishers including identity transparency and 518 | conflicts of interest. 519 | 520 | Protocol improvements: 521 | 522 | : Increasing security of existing protocols. 523 | 524 | Ecosystem improvements: 525 | 526 | : Reducing reliance on less secure systems, for example, migrating user 527 | authentication from password-based to WebAuthn [WEBAUTHN] and relying on 528 | multiple factors (MFA). 529 | 530 | ### Adoption 531 | 532 | Adoption of replacement signals requires coordination between user agents, 533 | service providers, and proxy services. Some user agents and proxy services may 534 | support only a subset of these signals, while service providers may require 535 | additional signals. A mechanism of negotiation may be needed for communicating 536 | these requirements. 537 | 538 | In addition, service providers should only require a signal within the scope it 539 | will be used. In the same way that service provides only require user 540 | authentication when the user requests access to a non-public resource, a signal 541 | should not be pre-emptively requested before it is needed. The categories of 542 | interaction described above may help define scopes within a service, and they 543 | may help communicate to the user the reasoning for requiring a signal. 544 | 545 | ### Privacy Considerations 546 | 547 | A signal should not be required without clear justification, service providers 548 | should practice data minimization {{!RFC6973}} wherever possible. Requiring 549 | excessive signals may be more harmful to user privacy than requiring IP address 550 | transparency. This section provides a more details analysis of some signals. 551 | 552 | ADDRESS_ESCROW gives service providers a time period within which they may 553 | obtain the client's IP address, but the information-in-escrow is not 554 | immediately available. Service providers should not gain access to the 555 | information in secret. A service provider may misuse the information-in-escrow 556 | for tracking and privacy-invasion purposes. 557 | 558 | PEER_INTEGRITY partitions users into two groups with valid and invalid 559 | hardware/software state, at a minimum. If the signal reveals more information, 560 | then it may allow more granular tracking of small sets of devices. 561 | 562 | IDENTITY_TRANSPARENCY may expose significant information about a user to a 563 | service provider; the resulting privacy invasion may be significantly worse 564 | than IP address transparency causes. 565 | 566 | IS_HUMAN depends on the mechanism used for proving humanness. 567 | 568 | REIDENTIFICATION explicitly allows a service provider to associate requests 569 | across unlinkable connections. This signal allows for profiling user behavior 570 | and tracking user activity without requesting more identifying information. 571 | First-party reidentification is a use case for this signal. 572 | 573 | REPUTATION partitions users into a set based on their reputation. The privacy 574 | invasion associated with this signal is intentionally small. 575 | 576 | SOURCE_ASN allows for identifying request patterns originating from an ASN 577 | without providing IP address transparency. However, ASNs are not guaranteed to 578 | serve large populations, therefore revealing the source ASN of a request may 579 | reveal more information about the user than intended. 580 | 581 | ### Provenance {#provenance} 582 | 583 | Replacement signals are only useful if they are trustworthy. 584 | 585 | [OPEN ISSUE 24](https://github.com/IRTF-PEARG/draft-ip-address-privacy/issues/24) 586 | 587 | ### Applying Appropriate Signals 588 | 589 | As previous discussed, IP addresses are used for various reasons; therefore, 590 | describing a one-size-fits-all replacement signal is not appropriate. In 591 | addition, the quality and quantity of replacement signals needed by a service 592 | depends on the category of interaction of its users and potential attacks on 593 | the service. 594 | 595 | As an example, the attacks listed above in {{antiabuse}} can be organized into 596 | six groups based on the signals that may sufficiently replace IP addresses: 597 | 598 | 1. IS_HUMAN, REPUTATION, REIDENTIFICATION, PEER_INTEGRITY 599 | - advertising fraud (e.g., click-fraud) 600 | - phishing 601 | - scraping (e.g., e-commerce, search) 602 | - spam (e.g., email, comments) 603 | 1. IS_HUMAN, REPUTATION, REIDENTIFICATION, ecosystem improvements 604 | - account takeover 605 | 1. IS_HUMAN, REPUTATION, SOURCE_ASN 606 | - influence (e.g., brigading, astroturfing) 607 | 1. publisher norms, (publisher) IDENTITY_TRANSPARENCY, PEER_INTEGRITY 608 | - disinformation operations (e.g., detecting scaled and/or coordinated 609 | attacks) 610 | 1. publisher norms, (publisher) IDENTITY_TRANSPARENCY, ADDRESS_ESCROW 611 | - real-world harm (e.g., child abuse) 612 | 1. IDENTITY_TRANSPARENCY, protocol improvements 613 | - financial fraud (e.g., stolen credit cards, email account compromise) 614 | 615 | The remaining two attack categories fall outside of the scope of this document. 616 | 617 | - malware/ransomware (e.g., detecting C2 connections) 618 | - vulnerability exploitation (e.g., "hacking") 619 | 620 | Note, IP addresses do not provide a perfect signal in their existing usage, and 621 | the above replacement signals do not provide a better signal in all cases. 622 | 623 | ## Evaluation of existing technologies 624 | 625 | Technologies exist that are designed to solve some of the problems described in 626 | this document. 627 | 628 | Privacy Pass {{?I-D.ietf-privacypass-protocol}} is a useful building block for 629 | solving numerous problems. Its design involves an interaction between a client 630 | and server where, at the end, the client is issued a set of anonymous tokens. 631 | These tokens may be redeemed at a later time, and this redemption should not be 632 | linkable with the initial issuance interaction. One existing use case is 633 | substituting a CAPTCHA challenge with a token, where successfully solving a 634 | CAPTCHA challenge results in a client being issued a set of anonymous tokens, 635 | and these tokens may be used in the future to bypass solving another CAPTCHA 636 | challenge. Therefore, Privacy Pass may be acceptable as an IS_HUMAN signal by 637 | some service providers. The current token design can't carry additional 638 | metadata like a user's reputation or an expiration date, and the tokens are not 639 | bound to an identity. The unlinkability property of the tokens is dependent on 640 | the implementation of key consistency {{?I-D.wood-key-consistency}}. 641 | 642 | Trust Token {{TRUSTTOKEN}} is an extension of Privacy Pass where the issuance 643 | and redemption functionality are provided in the browser setting. The tokens 644 | are allowed to carry public and private metadata as extensions. 645 | 646 | Private Access Tokens {{?I-D.private-access-tokens}} provide a technique for 647 | partitioning clients based on a per-origin policy within a time period. Its use 648 | cases include rate-limiting access to content and geo-location. PATs could be 649 | used as a REIDENTIFICATION signal or a replacement signal for GeoIP, depending 650 | on requirements. 651 | 652 | # Security Considerations 653 | 654 | This draft discussses IP address use cases, underlying requirements, and 655 | possible replacement signals. Adoption challenges and privacy considerations 656 | for those signals are also discussed. Further work is needed to build and 657 | evaluate these signals as suitable replacements for IP addresses. 658 | 659 | # IANA Considerations 660 | 661 | This document has no IANA actions. 662 | 663 | --- back 664 | 665 | # Acknowledgments 666 | {:numbered="false"} 667 | 668 | TODO acknowledge 669 | --------------------------------------------------------------------------------