RFC 4882

RFC 4882: IP Address Location Privacy and Mobile IPv6: Problem Statement 🎀

Okay bestie, this one is by R. Koodli from Nokia Siemens Networks, dated May 2007. It's an Informational RFC, so it's sharing info with the community and is not an Internet standard 💅 It doesn't say it obsoletes or updates any other RFC, so it's standing on its own ✨

Status of This Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice ©️

Copyright (C) The IETF Trust (2007).

Abstract 🌸

In this doc we talk about location privacy as it applies to Mobile IPv6. We cover the concerns that come up when a Home Address gets revealed to an onlooker, and when a Care-of Address gets disclosed to a correspondent 👀

Table of Contents 🗂️

1. Introduction ....................................................2
2. Definitions .....................................................3
3. Problem Definition ..............................................4
   3.1. Disclosing the Care-of Address to the Correspondent Node ...4
   3.2. Revealing the Home Address to Onlookers ....................4
   3.3. Problem Scope ..............................................4
4. Problem Illustration ............................................5
5. Conclusion ......................................................7
6. Security Considerations .........................................7
7. Acknowledgments .................................................8
8. References ......................................................8
   8.1. Normative References .......................................8
   8.2. Informative References .....................................8
Appendix A. Background ............................................10

1. Introduction ✨

Okay so location privacy and privacy when you're using IP to communicate have gotten SO important, no cap 🔥 IP privacy is basically about protecting your communication from accidentally revealing info that someone could use to analyze and gather sensitive user data. Think about gathering data from certain vantage points, collecting info tied to specific traffic, or monitoring certain groups of users for activity at specific times of day. We call this the "profiling" problem 🕵️‍♀️

Location privacy is about the problem of revealing roaming, which we define as a Mobile Node (MN) moving from one network to another, with or without ongoing sessions 🦋 A constant identifier with global scope can reveal roaming. Examples are a device identifier like an IP address, and a user identifier like a SIP [RFC3261] URI [RFC3986]. Often there's a binding between those two identifiers that's available, e.g., through DNS [RFC1035], which is so easy to find lol. Traffic analysis of those IP and Upper Layer Protocol identifiers on a single network can show that a device and a user are roaming. Roaming could also be inferred by profiling constant fields in IP communication across multiple network movements. For example, an Interface Identifier (IID) [RFC2462] in the IPv6 address that stays the same across networks could suggest roaming. The Security Parameter Index (SPI) in the IPsec [RFC4301] header is another field that may be subject to this kind of profiling and inference 🧩 Inferring roaming this way usually takes traffic analysis across multiple networks, or colluding attackers, or both. When location privacy is compromised, it could lead to more targeted profiling of user communication 😭

As you can see, the location privacy problem spans multiple protocol layers 🌈 Still, we can look at the problems nodes run into when they use one particular protocol layer. Roaming is especially important for Mobile IP, which defines a global identifier (Home Address) that can reveal device roaming. Combined with a matching user identifier (like a SIP URI), it can also reveal user roaming. Also, a user may not want to reveal roaming to correspondent(s), which means using a Care-of Address. Just like a Home Address, the Care-of Address can also reveal the topological location of the Mobile Node 🙈

This document scopes the location privacy problem for the Mobile IP protocol. The main goal is to stop attackers on the path between the Mobile Node (MN) and the Correspondent Node (CN) from detecting roaming because the Home Address was disclosed 🫶 The attackers are assumed to be able to observe, modify, and inject traffic at one point between the MN and the CN. They're assumed NOT to be able to observe at multiple points and correlate what they see to detect roaming. For this reason, MAC addresses, IIDs, and other fields that can be profiled to detect roaming are only in scope to the extent that an attacker at one point can use them. Upper layer protocol identifiers that expose roaming are out of scope, except that a solution to the problem described here needs to be usable as a building block in solutions to those problems 🧱

This document also looks at the problem that comes from exposing a Care-of Address to the CN 💖

This document is only concerned with IP address location privacy in the context of Mobile IPv6. It does NOT address the overall privacy problem. For instance, it doesn't address privacy issues related to MAC addresses or the relationship between IP and MAC addresses [HADDAD], or the Upper Layer Protocol addresses. Solutions to the problem specified here should provide protection against roaming disclosure due to using Mobile IPv6 addresses from a visited network.

This document assumes you're familiar with the basic operation of Mobile IPv6 [RFC3775] and the terminology defined there. For convenience, we give some definitions below 📚

2. Definitions 🎀

• Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams around networks 🧳
• Correspondent Node (CN): A Mobile IPv6 that node corresponds with an MN 💌
• Home Network: The network where the MN is normally present when it is not roaming 🏠
• Visited Network: A network that an MN uses to access the Internet when it is roaming 🌍
• Home Agent: A router on the MN's home network that provides forwarding support when the MN is roaming 🚏
• Home Address (HoA): The MN's unicast IP address valid on its home network 🏡
• Care-of Address (CoA): The MN's unicast IP address valid on the visited network ✈️
• Reverse Tunneling or Bidirectional Tunneling: A mechanism used for packet forwarding between the MN and its Home Agent 🔁
• Route Optimization: A mechanism that allows direct routing of packets between a roaming MN and its CN, without having to traverse the home network 🛣️

3. Problem Definition 💅

3.1. Disclosing the Care-of Address to the Correspondent Node 👀

When a Mobile IP MN roams from its home network to a visited network, or from one visited network to another, using the Care-of Address in communication with a correspondent reveals that the MN has roamed. This assumes the correspondent can associate the Care-of Address with the Home Address, for instance by inspecting the Binding Cache Entry. The Home Address itself is assumed to have been obtained by whatever means (e.g., through DNS lookup) 🔍

3.2. Revealing the Home Address to Onlookers 🙈

When a Mobile IP MN roams from its home network to a visited network, or from one visited network to another, using a Home Address in communication reveals to an onlooker that the MN has roamed. When a binding of a Home Address to a user identifier (such as a SIP URI) is available, the Home Address can also be used to determine that the user has roamed. This problem doesn't depend on whether the MN uses a Care-of Address to talk directly to the correspondent (i.e., uses route optimization), or whether the MN communicates via the Home Agent (i.e., uses reverse tunneling). Location privacy can be compromised when an onlooker is present on the MN - CN path (when route optimization is used). It may also be compromised when the onlooker is present on the MN - HA path (when bidirectional tunneling without encryption is used; see below) 😬

3.3. Problem Scope 🔭

With existing Mobile IPv6 solutions, there's some protection for location privacy. If a Mobile Node uses reverse tunneling with Encapsulating Security Payload (ESP) encryption, then the Home Address is not revealed on the MN - HA path. So eavesdroppers on the MN - HA path can't determine roaming. They could, however, still profile fields in the ESP header. Still, this problem isn't specific to Mobile IPv6 location privacy 🔐

When an MN uses reverse tunneling (regardless of ESP encryption), the correspondent doesn't have access to the Care-of Address. So it can't determine that the MN has roamed 🙌

So the location privacy problem is especially relevant when Mobile IPv6 route optimization is used, or when reverse tunneling is used without protecting the inner IP packet that contains the Home Address. ⭐

4. Problem Illustration ✨

okay bestie, this section is a little demo of the problem we just talked about 🎀 It's meant to show what the problem looks like in real life.

Picture a Mobile Node sitting at its home network 🏠 Whenever it's doing IP communication, its correspondents can see an IP address that's valid on the home network. The people using peer-to-peer apps will probably just see a friendly identifier like a SIP URI 📱, and the endpoints in the IP stack will see the IP addresses. Users who don't care about IP details, or don't even know they exist, won't notice anything different when the MN gets a new IP address 🙈 Anyone can "tcpdump" or "ethereal" a session, capture the IP packets, and map the MN's IP address to an approximate geo-location 🗺️ That mapping might reveal a user's home location, but a correspondent can't tell whether the user has actually roamed or not. Guessing physical location from an IP address is kinda like guessing where someone lives from the area code of their phone number 📞 How precise that gets depends on how good the tools are, how often an ISP does network re-numbering, and so on. And an IP address can't guarantee that a peer is in a certain area, because of things like VPNs and tunneling 🌐

When the MN roams to another network, the location privacy problem has two parts: revealing information to its correspondents, and revealing information to onlookers 👀

With its correspondents, the MN can either talk to them directly or reverse-tunnel its packets through the Home Agent. Reverse tunneling doesn't reveal the MN's Care-of Address 🙌 though the end-to-end delay might change depending on the scenario. With the correspondents that can be told the Care-of Address "on the wire", the MN has the option of using route-optimized communication ⚡ The transport protocol still sees the Home Address even with route optimization. Unless the correspondent is running some packet capturing tool, the user can't see which mode (reverse tunneling or route optimization) is in use, but they do know they're talking to the same peer whose URI they already have 💖 It's kinda like chatting with a roaming cellphone user whose phone number, just like the URI, never changes 📲

Here's the tea 🫖 Whether the MN uses route optimization or reverse tunneling (without ESP encryption), its Home Address shows up in data packets. If an onlooker on the MN - HA path can inspect packets "on the wire", they can figure out that the MN has roamed, and maybe even that the user has roamed too 😭 That could wreck the location privacy even if the MN tried to hide its roaming from a correspondent.

This is true whether the Home Address is statically or dynamically allocated 💅 In both cases, mapping the IP address to a geo-location will most likely give results with the same level of granularity. With the free tools out there on the Internet, that granularity is the physical address of the ISP or the organization that registered ownership of the prefix chunk. An ISP or organization isn't, rightly, required to hand out a blueprint of its subnets, so for a mobile wireless network the granularity stays pretty coarse 🌸 Still, sophisticated attackers might be able to do site mapping and get more fine-grained subnet info 🕵️‍♀️

A location privacy compromise could also lead to more targeted profiling of user data 🎯 An eavesdropper could specifically track the traffic that contains the Home Address and watch the Mobile Node move around as its Care-of Address changes. The profiling problem isn't specific to Mobile IPv6, but revealing the Home Address could trigger a location privacy compromise that leads to it. A correspondent could also take advantage of knowing that a user has roamed once the Care-of Address is revealed, and change how it acts based on that knowledge 😬 That could really worry a mobile user, especially if the correspondent turns out to be untrustworthy. For these reasons, appropriate security measures on the management interfaces on the MN should be considered, to guard against disclosure or misuse of location information 🔐

Applying existing techniques to stop profiling might have effects on Mobile IPv6 signaling performance 📉 For example, changing the Care-of Address often would cause extra Return Routability [RFC3775] and binding management signaling. And changing the Home Address often affects IPsec security association management. Careful consideration should be given to the signaling cost of changing either the Care-of Address or the Home Address 🧮

When roaming, an MN can treat its home network nodes like any other correspondents. Reverse tunneling is probably enough for home network communication, since route-optimized communication would go over the identical path 🛣️ So an MN can avoid revealing its Care-of Address to its home network correspondents just by using reverse tunneling. The Proxy Neighbor Advertisements [RFC2461] from the Home Agent could act as hints to home network nodes that the Mobile Node is away. However, they won't be able to know the Mobile Node's current point of attachment unless the MN uses route optimization with them ✨

5. Conclusion 🎀

Alright, recap time 💜 In this document we talked about the location privacy problem as it applies to Mobile IPv6. The short version: disclosing the Care-of Address to a correspondent, and revealing the Home Address to an onlooker, can compromise the location privacy of a Mobile Node, and therefore of a user 😭

We saw that bidirectional tunneling lets an MN protect its Care-of Address from the CN 🛡️ And ESP encryption of an inner IP packet lets the MN protect its Home Address from onlookers on the MN - HA path 🔒 But with route optimization, the MN will reveal its Care-of Address to the CN 🙈 Route optimization also causes the Home Address to be revealed to onlookers, both in the data packets and in Mobile IPv6 signaling messages. The solutions to this problem are expected to be protocol specifications that use the existing Mobile IPv6 functional entities: the Mobile Node, its Home Agent, and the Correspondent Node 👑

6. Security Considerations 💀

This document is all about the location privacy problem specific to Mobile IPv6, and it's serious business 🚨 Any solution must be able to protect (e.g., using encryption) the Home Address from disclosure to onlookers in data packets when using route optimization or reverse tunneling. On top of that, solutions must consider protecting the Mobile IPv6 signaling messages from disclosing the Home Address along the MN - HA and MN - CN paths.

Disclosing the Care-of Address is inevitable if an MN wants to use route optimization 😩 Whether the Care-of Address is an on-link address of the MN on the visited link or one belonging to a cooperating proxy, the mere presence of a Binding Cache Entry is enough for a CN to figure out that the MN has roamed. So an MN that cares about location privacy should be careful about whether to use route optimization, especially with correspondents it hasn't met before 🫣

The solutions should also consider the use of temporary addresses and what they mean for Mobile IPv6 signaling, as discussed in Section 4, "Problem Illustration". Use of IP addresses with privacy extensions [RFC3041] could be especially useful for Care-of Addresses, as long as the trade-offs with Return Routability signaling are taken into account 🦋

7. Acknowledgments 🫶

Big thanks to James Kempf, Qiu Ying, Sam Xia, and Lakshminath Dondeti for reviewing and giving feedback 💖 Thanks also to Jari Arkko and Kilian Weniger for the last-call review and for suggesting improvements and text 🌟 And a special shoutout to Sam Hartman for providing text that improved the problem scope 👑

8. References 📚

8.1. Normative References

• [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

8.2. Informative References

• [HADDAD] Haddad, W., et al., "Privacy for Mobile and Multi-homed Nodes: Problem Statement" Work in Progress, June 2006.
• [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
• [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
• [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
• [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
• [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
• [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
• [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.
• [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

Appendix A. Background 🧚

The location privacy topic is broad and often means different things to different people 🌈 It also spans multiple layers of the OSI reference model. Besides that, there are attributes beyond the IP address alone that can hint at location. For instance, even if a correspondent is talking to the same endpoint it always has, the "time of day" attribute can give the user away ⏰ Some roaming cellphone users may have noticed that their SMS messages carry a timestamp in their "home network" time zone (for location privacy or otherwise), which can reveal that the user is in a different time zone when messages are sent at a "normal" time of day 📱 Furthermore, tools exist on the Internet that can map an IP address to the physical address of an ISP or the organization that owns the prefix chunk. Taking it a step further, with built-in GPS receivers on IP hosts, applications can be built to map geo-locations to IP network information 🛰️ Even without GPS receivers, geo-locations can be obtained in environments where "Geopriv" is supported, for instance as a DHCP option [RFC3825]. In summary, a user's physical location can be determined or guessed with some certainty and at varying levels of granularity by different means, even though IP addresses don't inherently provide any geo-location information on their own 💅 It's useful to keep this broad scope in mind as the problem of IP address location privacy in the presence of IP Mobility gets addressed 💖

Author's Address 💌

Rajeev Koodli
Nokia Siemens Networks
313 Fairchild Drive
Mountain View, CA 94043

EMail: rajeev.koodli@nokia.com

Full Copyright Statement 💅

Okay so, Copyright (C) The IETF Trust (2007). 🌸 This document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth therein, the authors retain all their rights. Their rights, their call! 💜

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈

Intellectual Property 🦋

The IETF is not picking a side 🫠 on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or cover what they claim, or whether any license under those rights might or might not be available. It also doesn't claim it went looking for those rights itself. If you want the details on how rights work for RFC documents, check out BCP 78 and BCP 79. ✨

Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. The same goes for the result of any attempt to get a general license or permission to use those proprietary rights by implementers or users of this specification. 💖

The IETF also invites any interested party to flag any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. Speak up, bestie! 📣

Acknowledgement 🎀

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈 Thank you to them for keeping the lights on! 🫶