RFC 5726
Mobile IPv6 Location Privacy Solutions
Mobile IPv6 Location Privacy Solutions 🎀
Okay bestie, let's start with the title block 💖 This is RFC 5726, published in February 2010 ✨. It's an Experimental document from the Internet Research Task Force (IRTF) stream, with ISSN 2070-1721. The authors are Y. Qiu from the Institute for Infocomm Research, F. Zhao (listed as Editor, "Ed.") from Google, and R. Koodli from Cisco Systems 🧚. The header doesn't list any RFC that it obsoletes or updates, so it's standing on its own 💅.
Abstract
Mobile IPv6 (RFC 3775) lets a mobile node stay reachable while it roams around the Internet, which is seriously iconic 🦋. The catch is that the IP addresses showing up in signaling or data packets can reveal where the mobile node is and how it's moving 🙈. In this document, the authors look at the Mobile IPv6 location privacy problem described in RFC 4882, and they propose techniques that are efficient and secure for protecting the mobile node's location privacy 🔒. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group 🌸.
Status of This Memo
Here's the vibe check: this is not an Internet Standards Track specification 💀. It's published so people can examine it, try out experimental implementations, and evaluate it 🧪.
This document defines an Experimental Protocol for the Internet community 🌈. It's a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development work ✨. Those results might not be suitable for deployment, so don't just ship it 😭. This RFC represents the consensus of the IP Mobility Optimizations Research Group of the IRTF 🫶. Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard, and you can check Section 2 of RFC 5741 for the details 📖.
Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc5726 🍓.
Copyright Notice
Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication 📜. Please review those documents carefully, because they describe your rights and restrictions regarding this document 👑.
Table of Contents
1. Introduction ....................................................5
2. Conventions and Terminology .....................................6
2.1. Conventions ................................................6
2.2. Terminology ................................................6
3. Requirements ....................................................8
4. Solution Overview ...............................................9
5. Reverse-Tunneled Correspondent Binding Update ..................11
5.1. The Procedure .............................................12
5.2. Route-Optimized Payload Packets ...........................14
5.3. Mobile Node Operation .....................................15
5.3.1. Conceptual Data Structures .........................15
5.3.2. Reverse-Tunneled Correspondent Binding
Update to the Correspondent Node ...................15
5.3.3. Reverse-Tunneled Correspondent Binding
Acknowledgement from the Correspondent Node ........16
5.3.4. Route-Optimized Payload Packets ....................16
5.3.5. Receiving ICMP Error Message .......................17
5.3.6. Binding Error from the Correspondent Node ..........17
5.3.7. Binding Refresh Request from the
Correspondent Node .................................17
5.4. Home Agent Operation ......................................17
5.5. Correspondent Node Operation ..............................18
5.5.1. Conceptual Data Structures .........................18
5.5.2. Reverse-Tunneled Correspondent Binding
Update from the Mobile Node ........................18
5.5.3. Reverse-tunneled Correspondent Binding
Acknowledgement to the Mobile Node .................18
5.5.4. Route-Optimized Payload Packets ....................18
5.5.5. ICMP Error Message to the Mobile Node ..............19
5.5.6. Binding Error to the Mobile Node ...................19
5.5.7. Binding Refresh Request to the Mobile Node .........19
5.6. Summary ...................................................20
6. IP Address Location Privacy Solution Using the Pseudo
Home Address ...................................................20
6.1. Home Binding Update .......................................20
6.1.1. Pseudo Home Address Registration ...................20
6.1.2. Home De-Registration ...............................21
6.2. Correspondent Binding Update Using the Pseudo Home
Address ...................................................22
6.2.1. Return Routability Procedure .......................22
6.2.2. Route-Optimized Correspondent Binding Update .......24
6.2.3. Reverse-tunneled Correspondent Binding Update ......25
6.2.4. Using Different Pseudo Home Addresses with
Different Correspondent Nodes ......................25
6.3. Payload Packets ...........................................25
6.3.1. Reverse Tunneling Mode .............................25
6.3.2. Route Optimization Mode ............................26
6.4. Prefix Discovery ..........................................26
6.5. Mobile Node Operation .....................................26
6.5.1. Conceptual Data Structures .........................26
6.5.2. Binding Update to the Home Agent ...................27
6.5.3. Binding Acknowledgement from the Home Agent ........27
6.5.4. Home Test Init to the Home Agent ...................28
6.5.5. Home Test from the Home Agent ......................28
6.5.6. Route-Optimized Payload Packets ....................29
6.5.7. Receiving Binding Refresh Request ..................29
6.6. Home Agent Operation ......................................29
6.6.1. Conceptual Data Structures .........................30
6.6.2. Binding Update from the Mobile Node ................30
6.6.3. Binding Acknowledgement to the Mobile Node .........31
6.6.4. Home Test Init from the Mobile Node ................31
6.6.5. Home Test to the Mobile Node .......................32
6.7. Correspondent Node Operation ..............................32
7. Extensions to Mobile IPv6 ......................................32
7.1. Encrypted Home Address Destination Option .................32
7.2. Encrypted Home Address Routing Header .....................33
7.3. Pseudo Home Address Mobility Option .......................34
7.4. Pseudo Home Address Acknowledgement Mobility Option .......35
8. Security Considerations ........................................37
8.1. Home Binding Update .......................................37
8.2. Correspondent Binding Update ..............................38
8.3. Route-Optimized Payload Packets ...........................38
9. Related Work ...................................................39
10. IANA Considerations ...........................................40
11. Conclusion ....................................................40
12. Acknowledgements ..............................................41
13. References ....................................................41
13.1. Normative References .....................................41
13.2. Informative References ...................................42
Appendix A. Profiling Attack: Discussion ..........................44
A.1. The Care-of Address ........................................44
A.2. Profiling on the Encrypted Home Address ....................44
A.3. The IPsec SPI ..............................................45
A.4. The IPsec Sequence Number ..................................45
A.5. The Regular Interval of Signaling Messages..................46
A.6. The Sequence Number in the Binding Update Message ..........46
A.7. Multiple Concurrent Sessions ...............................46
A.8. Summary ....................................................471. Introduction 🎀
Okay so the IP address location privacy problem is basically about accidentally spilling where a mobile node is right now 😭 to eavesdroppers and to the people it's talking to. With mobility as specified in Mobile IPv6 [6], there are two related problems: telling a correspondent node the care-of address, and exposing the home address to an eavesdropper (see the terminology below 💅). If you want the full tea on location privacy, check out RFC 4882 [11]. This doc assumes you already know how Mobile IPv6 works from RFC 3775, plus the location privacy problem from RFC 4882 🧚
To protect location privacy, a mobile node MUST NOT disclose the binding between its care-of address and its home address. 🙈 In this document, we propose a set of extensions to the Mobile IPv6 specification to deal with the IP address location privacy problem. Now, profiling is the other thing that's connected to this: that's where a mobile node's activities get linked together and then analyzed. Profiled activities can help compromise location privacy, especially when they're combined with extra info, and once location privacy is compromised, it can lead to even more targeted profiling. Solutions to stop profiling are important, but they aren't the main focus here. We discuss profiling in the appendix 📚
We propose two IP address location privacy solutions in this document. 💖
- Solution one (Section 5): The mobile node can talk to the correspondent node using the real home address, without eavesdroppers breaching location privacy. It does this by using parameters generated during the return routability procedure to mask the real home address. It's an evolution of location privacy protection built on the return routability messages already specified in RFC 3775.
- Solution two (Section 6): An IPsec tunnel mode security association with a non-null encryption algorithm is negotiated to encrypt signaling messages (including the real home address inside them) exchanged between the mobile node and the home agent, for example during the home binding update procedure. Also, during the return routability procedure and the correspondent binding update procedure, a "pseudo home address" (the definition of this new term and many other commonly used mobility related terms is in Section 2) is used in place of the real home address in various messages. This means the mobile node can hide its real home address from both the correspondent node and eavesdroppers, without needing extra extensions on the correspondent node. The mobile node may also mask the pseudo home address using the mechanism in Section 5 for even more location privacy protection ✨
Each of these two solutions can be implemented on its own without relying on the other 🦋
The solutions here are designed around these assumptions 👑
- First, we focus on location privacy issues that come up when the mobile node attaches to a foreign link. Location privacy issues when the mobile node attaches to its home link, if any, are outside the scope of this document.
- Second, we assume IPsec [2] is used to secure mobility signaling messages exchanged between the mobile node and the home agent. So location privacy solutions for when other security mechanisms are used are beyond the scope of this document.
- Third, we assume eavesdroppers are passive attackers, for example an eavesdropper along the path that traffic flows to or from the mobile node. We make this assumption because messages from active attackers can either be discarded based on local policy at a mobile node, or the mobile node could choose to treat them like messages from any other correspondent node. So specific threats to location privacy posed by active attackers are also beyond the scope of this document.
- Fourth, to simplify the analysis, we assume both the correspondent node and the home agent are fixed nodes. If either one is mobile, the same analysis and solutions for the mobile node may also apply.
- Finally, the same solution applies to each of the care-of addresses if a mobile node maintains more than one care-of address.
This document represents the consensus of the MobOpts Research Group 🌈 It was reviewed by Research Group members active in this specific area of work. At the request of their chairs, it was also comprehensively reviewed by multiple active contributors to the IETF Mobile IP related working groups 🫶
2. Conventions and Terminology 💜
2.1. Conventions
Okay, the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Those are the magic words, bestie, so pay attention to them 🔥
2.2. Terminology
In this document, we introduce two new terms: "pseudo home address" and "encrypted home address". Here's what they mean 🌸
- Pseudo Home Address (pHoA): A unicast IPv6 address formed to replace the real home address used in certain Mobile IPv6 signaling or data packets. Without explicit indication, the pseudo home address looks like a regular IPv6 address [5].
- Encrypted Home Address (eHoA): The output when an encryption algorithm is applied to the real home address or the pseudo home address, with additional inputs such as a key. The real home address can be recovered from the encrypted home address by using a decryption algorithm.
We also use commonly adopted mobility-related terms as defined in [6] and [11] throughout this document. Some of these are listed below for easy reference, but we assume you're already familiar with how Mobile IPv6 works as defined in RFC 3775 [6], RFC 3776 [7], and RFC 4877 [8] 🍓
- Mobile Node (MN): A Mobile IPv6 compliant mobile node that can roam on the Internet.
- Correspondent Node (CN): An IPv6 node that communicates with the mobile node.
- Home Network: The network where the mobile node is normally present when it is not roaming.
- Visited Network: The network that the mobile node uses to access the Internet when it is roaming.
- Home Agent (HA): A router on the mobile node's home network that provides forwarding support when the mobile node is roaming.
- Home Address (HoA): The mobile node's unicast IP address valid on its home network.
- Care-of Address (CoA): The mobile node's unicast IP address valid on the visited network.
- Return Routability (RR): A procedure which enables secure binding between the care-of address and the home address when no pre-existing security association exists between the mobile node and the correspondent node.
- Home Test Init (HoTI) / Home Test (HoT) / Care-of Test Init (CoTI) / Care-of Test (CoT): Messages used during the return routability procedure.
- Binding Update (BU): A message used by the mobile node to securely bind its care-of address to its home address at the correspondent node or the home agent.
- Binding Acknowledgement (BA): A response to the Binding Update.
- Message Authentication Code (MAC): The value, which is computed using HMAC_SHA1 in this document, that protects both a message's integrity and its authenticity.
- Route Optimization: A mechanism that allows direct routing of packets between a roaming mobile node and its correspondent node, without having to traverse the home network.
- Reverse Tunneling or Bidirectional Tunneling: A mechanism used for packet forwarding between a roaming mobile node and its correspondent node via its home agent.
3. Requirements 🦄
In this section, we describe the requirements that Mobile IPv6 location privacy solutions should meet, hereafter referred to as "the solution". These are some of the basic requirements set out to make the solution easy to implement for people who know Mobile IPv6 and the related security protocols used with it (such as IKEv2 [4] and IPsec) 🧚
- R01: The solution must follow the framework and architecture of IPv6 and Mobile IPv6 (as specified in RFC 3775, RFC 3776, and RFC 4877).
- R02: The solution must not interfere with the operation of IPsec. This means the principles and the operation specified in RFC 3776 and RFC 4877 need to be followed. For example, the IPsec security association and policy must be identified by the real home address.
- R03: The solution should provide back-compatibility so different Mobile IPv6 entities can work together even though they may have different capabilities. This requires the mobile node to be able to detect whether the home agent or the correspondent node supports the use of the location privacy solutions.
- R04: The overhead resulting from the solution, in terms of payloads or messages transmitted and memory, should be kept minimal.
4. Solution Overview ✨
okay so the whole point of these IP address location privacy solutions is to hide the link between the mobile node's real home address and its care-of address 🙈 from eavesdroppers and the correspondent node. let's go through the solutions bestie 🎀
With Mobile IPv6, during the home binding update procedure, both the real home address and the care-of address are in cleartext when either IPsec tunnel mode or IPsec transport mode is used with no encryption 💀. As Section 6.1 explains, the fix for stopping the real home address from leaking to eavesdroppers on the MN-HA path during the home binding update is to set up an IPsec tunnel mode security association with a non-null encryption algorithm. That way the home binding signaling messages and the real home address inside them get encrypted 🔐. This same method also gives location privacy during other mobility signaling exchanges between the home agent and the mobile node, like the prefix discovery procedure (see Section 6.4) 🧚.
When the mobile node talks to the correspondent node in reverse tunneling mode, it can hide its current location from the correspondent node and from eavesdroppers along the HA-CN path, since the care-of address isn't included in payload packets on that path 🦋. Also, an IPsec security association with a non-null encryption algorithm between the mobile node and the home agent can hide the real home address carried in payload packets from eavesdroppers on the MN-HA path. it's giving protection on both sides 💅
Now, to talk to a correspondent node in route optimization mode, the mobile node has to do the return routability procedure first, then the correspondent binding update procedure 🌸. With the current Mobile IPv6 spec, the real home address and the care-of address in the correspondent Binding Update message and in payload packets are visible to eavesdroppers 😭. So if the mobile node wants to send and receive packets over the optimized route and protect its location privacy at the same time, it has to disclose its care-of address and hide its real home address. There are two different scenarios here, and this doc proposes a different solution for each one 👑.
Scenario one: the correspondent node can get the mobile node's real home address and starts the communication using that real home address. In this case the mobile node needs to keep using the real home address with the correspondent node to maintain session continuity, and it also needs to hide that real home address from eavesdroppers 🫶. The solution for this one (called "reverse-tunneled correspondent binding update" from here on) is in Section 5. The mobile node swaps the same return routability signaling messages defined in RFC 3775 with the correspondent node, then derives a privacy management key from keygen tokens and uses that key to encrypt the real home address 🔥. Finally, it reverse-tunnels an extended correspondent Binding Update message through the home agent to register both the encrypted home address and the real home address at the correspondent node ✨. After the correspondent registration, the mobile node and the correspondent node use the registered encrypted home address in payload packets over the optimized route, instead of the real home address 🦋. And the encrypted home address is different for each correspondent node, because the privacy management key is different for each one 🌈.
Scenario two: the mobile node wants to hide its real home address from both the correspondent node and the eavesdroppers 🙈. Usually the mobile node starts the communication in this case, since the correspondent node doesn't know the real home address. The solution for this one is in Section 6.2 💜. The mobile node first gets a home keygen token that's generated from the pseudo home address during the home address test procedure 🧚. Then it sends the correspondent Binding Update message to register the binding between the pseudo home address and the care-of address at the correspondent node, over the optimized route 🌸. After the correspondent registration, the mobile node and the correspondent node use the registered pseudo home address, instead of the real home address, in payload packets over the optimized route. And the correspondent node has no idea any of this is happening, since the use of the pseudo home address is completely transparent to it 🫠.
It's also possible to throttle "profiling" on the pseudo home address by combining these two solutions 🍓. In that combo, the mobile node uses the pseudo home address in the extended home address test procedure to get a home keygen token. Then it uses the pseudo home address instead of the real home address in the reverse-tunneled correspondent binding update procedure 🎀. With this setup, the encrypted pseudo home address used in route optimized payload packets looks different to eavesdroppers every time a new round of the return routability procedure is completed 🦋. Iconic 😭
Before a pseudo home address can be used with a correspondent node, it MUST be registered with the home agent during the home registration procedure 📝. The mobile node asks for the pseudo home address in a new mobility option called the Pseudo Home Address option (see Section 7.3), which is carried in the home Binding Update message 💖. The home agent then tells the mobile node the status of that pseudo home address registration using another new mobility option, the Pseudo Home Address Acknowledgement option (see Section 7.4), carried in the home Binding Acknowledgement message 🫶. The pseudo home address MUST be routable so the home agent can intercept packets destined for it 🛰️. It's statistically difficult for other nodes to figure out the real home address from the pseudo home address, so that's the vibe 🔐. A detailed breakdown of how pseudo home addresses get generated is in Section 6.1.1.1 🌟.
Okay so with the extensions in this document, a mobile node can figure out whether the home agent and the correspondent node support the location privacy solutions or not ✨. When the Pseudo Home Address mobility option is present in the home Binding Update message, it's basically the mobile node saying "I want the location privacy solutions, pls" 🥺. If that Binding Update message is valid and the home agent supports location privacy for this particular mobile node, the home agent replies with the Pseudo Home Address Acknowledgement mobility option in the Binding Acknowledgement message 💅. If the home agent doesn't support location privacy solutions, it leaves out the Pseudo Home Address Acknowledgement mobility option from the Binding Acknowledgement message 💀. The same logic goes for the correspondent node: if the correspondent Binding Update message has the Encrypted Home Address destination option, it's telling the correspondent node that the mobile node wants location privacy solutions 🌈. If the message is valid and the correspondent node supports them for this mobile node, it replies with the Encrypted Home Address routing header in the correspondent Binding Acknowledgement message to the mobile node 🦋. If the correspondent node doesn't support location privacy solutions, it rejects the request by sending back an ICMP Parameter Problem message with Code value set to 2 😭. Also, a home agent that recognizes these extensions but doesn't want to provide location privacy protection MAY redirect the mobile node to another home agent 🫠. And if the request for location privacy solutions gets rejected, the mobile node may either proceed without location privacy protection, try a different home agent or correspondent node, or just abort the operation 🙃.
5. Reverse-Tunneled Correspondent Binding Update 🎀
In this section, we describe a solution that protects location privacy against eavesdroppers when the mobile node uses the real home address while communicating with the correspondent node over the optimized route 🔥. Note that this solution doesn't require any change to the return routability signaling messages 💖. Here's how it works, bestie 🫶
5.1. The Procedure ✨
Okay so, after the return routability procedure is totally done, if the mobile node wants location privacy but still wants to use its real home address with the correspondent node, it derives a privacy management key, Kpm, from Kbm, where Kpm = HMAC_SHA1 (Kbm, 0). 🔐 Then it uses Kpm to make the encrypted home address like this:
encrypted home address = Enc(Kpm, the home address)Where Enc() is a symmetric key encryption algorithm. AES is the default encryption algorithm. 🔑
Kpm changes every time Kbm changes, and Kbm changes whenever return routability runs again (like when the care-of address changes, or the keygen token expires, etc.). So Kpm is never reused when a care-of address changes. 🔄✨
Next, the mobile node generates a correspondent Binding Update message and reverse-tunnels it to the correspondent node through the home agent. 🚇 After encapsulation, the message looks like this:
IPv6 header (source = care-of address,
destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address,
destination = correspondent node)
Destination option header
Encrypted Home Address option (encrypted home address)
Parameters:
Alternative Care-of Address option (care-of address)
sequence number (within the Binding Update message header)
home nonce index (within the Nonce Indices option)
care-of nonce index (within the Nonce Indices option)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BU)))This packet is protected by the IPsec security association with a non-null encryption algorithm. 🛡️ If the home agent can process it successfully, it forwards the following packet to the correspondent node. 💌
IPv6 header (source = home address,
destination = correspondent node)
Destination option header
Encrypted Home Address option (encrypted home address)
Parameters:
Alternative Care-of Address option (care-of address)
sequence number (within the Binding Update message header)
home nonce index (within the Nonce Indices option)
care-of nonce index (within the Nonce Indices option)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BU)))After the correspondent node receives a reverse-tunneled correspondent Binding Update message, it does what's described in Section 5.5. 🧠 If that correspondent Binding Update message is processed successfully and an acknowledgement is requested, the correspondent node builds a Binding Acknowledgement message that looks like this:
IPv6 header (source = correspondent node,
destination = home address)
Encrypted Home Address routing header
encrypted home address
Parameters:
sequence number (within the Binding Update message header)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))When the home agent gets this Binding Acknowledgement message, it applies the IPsec security association with a non-null encryption algorithm to it, then forwards the following packet to the mobile node. 🎀
IPv6 header (source = home agent,
destination = care-of address)
ESP header in tunnel mode
IPv6 header (source = correspondent node,
destination = home address)
Encrypted Home Address routing header
encrypted home address
Parameters:
sequence number (within the Binding Update message header)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))The reverse-tunneled correspondent binding update procedure is complete once the mobile node processes the received Binding Acknowledgement message. 🏁 Also, note that when the mobile node talks to a different correspondent node, the encrypted home address looks different. 👀
Now, if the mobile node wants to delete an established Binding Cache entry at the correspondent node, it reverse-tunnels the following Binding Update message via the home agent. 🗑️ Note that the Encrypted Home Address option is optional during correspondent binding de-registration, and in this case only the home keygen token is used to generate Kbm and Kpm, if needed.
IPv6 header (source = care-of address,
destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address,
destination = correspondent node)
Destination option header (optional)
Encrypted Home Address option (encrypted home address)
Parameters:
Alternative Care-of Address option (care-of address)
sequence number (within the Binding Update message header)
home nonce index (within the Nonce Indices option)
care-of nonce index (within the Nonce Indices option)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BU)))If an acknowledgement is requested, the correspondent node sends the following Binding Acknowledgement message back to the mobile node. 💜
IPv6 header (source = correspondent node,
destination = home address)
Encrypted Home Address routing header (optional)
encrypted home address
Parameters:
sequence number (within the Binding Update message header)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))Since the destination IP address in this message is the home address, the home agent receives it and forwards it to the mobile node through the reverse tunnel. 🔁✨
5.2. Route-Optimized Payload Packets 🚀
After the correspondent registration is completed successfully, the payload packets are exchanged over the optimized route between the mobile node and the correspondent node. 🛣️ In these packets, the only things eavesdroppers can see are the encrypted home address in the Encrypted Home Address destination option and the one in the Encrypted Home Address routing header. 🙈
Payload packets from the mobile node to the correspondent node look like this:
IPv6 header (source = care-of address,
destination = correspondent node)
Destination option header
Encrypted Home Address option (encrypted home address)
PayloadPayload packets from the correspondent node to the mobile node look like this:
IPv6 header (source = correspondent node,
destination = care-of address)
Encrypted Home Address routing header
encrypted home address
Payload5.3. Mobile Node Operation 🧚
5.3.1. Conceptual Data Structures 🗂️
The Binding Update List entry for the correspondent registration gets a new field to store the current encrypted home address used with a particular correspondent node. 💅 The encrypted home address is stored when the mobile node sends a reverse-tunneled correspondent Binding Update message, and the state of that Binding Update List entry gets updated once the mobile node successfully processes the correspondent Binding Acknowledgement message. Note that the encrypted home address field is not valid in the Binding Update List entry for the home registration. ❌
Since the encrypted home address is 128 bits long, each encrypted home address (or the combination of the encrypted home address and the correspondent node's IP address) stored in the Binding Update List is expected to be unique. ✨ That means the mobile node can use the encrypted home address (or use it together with the correspondent node's IP address) as a primary key to look up the Binding Update List. 🔍
5.3.2. Reverse-Tunneled Correspondent Binding Update to the Correspondent Node 💌
After the return routability procedure, if the mobile node decides to use the location privacy solution with the correspondent node (for example, because of its configuration), it generates the encrypted home address. 🔐 Then it updates or creates a correspondent Binding Update List entry to store that encrypted home address, and forwards the correspondent Binding Update message through the reverse tunnel established with the home agent. Note that the MAC is generated the same way as specified in RFC 3775, and it does not cover the encrypted home address. 🧾
5.3.3. Reverse-Tunneled Correspondent Binding Acknowledgement from the Correspondent Node 🫶
When the mobile node gets a Binding Acknowledgement message from the correspondent node in response to a previously sent reverse-tunneled correspondent Binding Update message, and that Binding Acknowledgement message contains an Encrypted Home Address routing header, the mobile node figures the correspondent node supports the location privacy solution. 🙌 The mobile node authenticates the message based on RFC 3775. If authentication succeeds, the mobile node decrypts the encrypted home address and compares the result with the real home address, or compares the encrypted home address with the one stored in the Binding Update List entry. ✅ If they match, the mobile node considers the correspondent registration successful and updates the state of the corresponding Binding Update List entry. 🎉 If they don't match, the mobile node MAY start the correspondent binding update procedure again. 🔁
5.3.4. Route-Optimized Payload Packets 🦋
To keep the session continuous, the upper layers of the IP stack in the mobile node still use the real home address, even after the reverse-tunneled correspondent registration. 🌸
One possible way to implement this goes like this. When the Mobile IP sublayer at the mobile node receives a packet from the upper layer, the normal processing specified in RFC 3775 happens first. After that, the Home Address option gets swapped out for the Encrypted Home Address option carrying the encrypted home address stored in the matching Binding Update List entry, and then the mobile node forwards the packet to the correspondent node over the optimized route. 🚀
Going the other way, when the mobile node receives a payload packet carrying the Encrypted Home Address routing header, it uses the encrypted home address (optionally together with the correspondent node's IP address) to look up the Binding Update List. 🔎 If it finds an entry, it accepts the packet, replaces the Encrypted Home Address option with the Home Address option carrying the real home address, and keeps processing based on RFC 3775. 💖 If no entry is found, the mobile node silently drops the received packet. 🤫
5.3.5. Receiving ICMP Error Message 💀
The mobile node may receive an ICMP Parameter Problem, Code 2, message forwarded by the home agent through the bidirectional tunnel, for example when the correspondent node doesn't support the Encrypted Home Address option. 😭 If that happens, the mobile node SHOULD not try to use the location privacy solution with that correspondent node. 🚫 It may either choose not to communicate with the correspondent node, or communicate without location privacy protection. 🫠
5.3.6. Binding Error from the Correspondent Node 🦋
okay so picture this: the mobile node is chatting with a correspondent node using the encrypted home address 🔐, and the correspondent is like "wait, who even are you?" 💀 If there's no valid Binding Cache entry at the correspondent node, a Binding Error message can show up with the Status field set as 1 (unknown binding for Home Address destination option) 😭. We don't make up a new Status value for this one, because the Binding Update List entry can already say whether an encrypted home address is currently being used with that correspondent 🧠. Once the mobile node gets the Binding Error, it can figure out which encrypted home address is invalid just by checking the Home Address field in the message ✨. After that, the mobile node may perform the correspondent binding update procedure to set up a valid binding for that encrypted home address 💖.
5.3.7. Binding Refresh Request from the Correspondent Node 🌸
when the mobile node gets a Binding Refresh Request message from the correspondent node, and the home agent forwards it through the bidirectional tunnel, the mobile node needs to do the correspondent binding update procedure. That refreshes the binding for the encrypted home address at the correspondent node 🫶.
5.4. Home Agent Operation 🏠
no new home agent behaviour is being specified here, bestie 🙌. With the solution in this section (aka Section 5), the home agent just behaves based on RFC 3775 when it processes signaling or data packets. Easy breezy 💅.
5.5. Correspondent Node Operation 🧚
5.5.1. Conceptual Data Structures 💜
the Binding Cache entry gets a new field to store the current encrypted home address used with a particular mobile node. That address gets stored once the correspondent node successfully processes a reverse-tunneled correspondent Binding Update message 📦.
Since the encrypted home address is 128 bits long, each encrypted home address (or the combo of the care-of address and the encrypted home address stored in the Binding Cache entry) is expected to be unique 🔑. So the correspondent node can use the encrypted home address (or use it together with the care-of address) as a primary key to look up the Binding Cache. It's giving database energy 🤓.
5.5.2. Reverse-Tunneled Correspondent Binding Update from the Mobile Node 📬
when a reverse-tunneled Binding Update message comes in with the Encrypted Home Address option, and the correspondent node supports the location privacy solution, it verifies the message the same way RFC 3775 defines. If that verification succeeds, the correspondent node generates Kpm and uses it to decrypt the encrypted home address, then compares the result with the source IP address 🕵️♀️. If they match, the correspondent node stores the encrypted home address in the matching Binding Cache entry ✅.
5.5.3. Reverse-tunneled Correspondent Binding Acknowledgement to the Mobile Node 🎀
if the mobile node asks for an acknowledgement to the reverse-tunneled correspondent Binding Update message, the correspondent node sends back a Binding Acknowledgement message with the Encrypted Home Address routing header, as long as it supports the location privacy solution 💌. The MAC in the Binding Acknowledgement message is generated the same way RFC 3775 specifies, and it does not cover the encrypted home address carried in the Encrypted Home Address routing header 🔒.
5.5.4. Route-Optimized Payload Packets 🚀
to keep session continuity 🫶, the upper layers of the IP stack at the correspondent node still use the real home address, even after the reverse-tunneled correspondent registration.
one possible way to do this (not the only way!) goes like this. After the IP layer at the correspondent node finishes processing the packet from the upper layer based on RFC 3775, the Type 2 routing header and the real home address inside it get swapped for the Encrypted Home Address routing header, carrying the encrypted home address from the matching Binding Cache entry. Then the packet heads to the mobile node over the optimized route 🛣️✨.
on the flip side, when the correspondent node gets a payload packet with the Encrypted Home Address option, it uses the encrypted home address (optionally with the mobile node's care-of address) to look up the Binding Cache 👀. If there's an entry, the correspondent node swaps the Encrypted Home Address option for the Home Address option carrying the real home address, then forwards the packet up to the upper layer. If no matching entry turns up, the correspondent node sends a Binding Error message to the source IP address, which is the mobile node's care-of address 😬.
5.5.5. ICMP Error Message to the Mobile Node 📣
when a reverse-tunneled correspondent Binding Update message with the Encrypted Home Address option shows up, and the correspondent node doesn't support location privacy extensions, it sends an ICMP Parameter Problem, Code 2, message to the source IP address (aka the mobile node's home address). The home agent then forwards that ICMP message to the mobile node through the bidirectional tunnel 🚇.
5.5.6. Binding Error to the Mobile Node 🙅♀️
when the correspondent node gets a payload packet with the Encrypted Home Address option and there's no valid Binding Cache entry for it, it sends a Binding Error message with the Status code set as 1 back to the source IP address of the packet. Also, the Home Address field in the Binding Error message MUST be copied from the Encrypted Home Address field in the Encrypted Home Address destination option of the offending packet, or set to the unspecified address if no such option appears in the packet 💀.
5.5.7. Binding Refresh Request to the Mobile Node ⏰
when the correspondent node realises a Binding Cache entry is about to expire, it sends a Binding Refresh Request message to the real home address of the mobile node stored in that entry 🔔.
5.6. Summary 📝
the real home address is visible in the Binding Update and Binding Acknowledgement messages along the HA-CN path 👀. Like Mobile IPv6 itself, this solution wasn't designed to change communications between the home network and the correspondent node, so the same issues would hit non-mobile hosts too 🤷♀️. Still, this solution meets all the requirements set for location privacy solutions, and it gives a simple way to get location privacy protection while still using the real home address with the correspondent node. Slay, honestly 🌈👑
6. IP Address Location Privacy Solution Using the Pseudo Home Address 🎀
6.1. Home Binding Update 💌
when the mobile node attaches to a foreign link, it first does the home binding update procedure for the real home address with the home agent, just like RFC 3775 says 🏡. To hide the real home address, we require the use of IPsec Encapsulating Security Payload (ESP) [3] in tunnel mode 🧁. For location privacy, a non-null encryption transform must be used, so the real home address is encrypted and encapsulated and invisible to eavesdroppers on the MN-HA path 🕶️. The packet formats and processing rules are the same as in RFC 3775 and RFC 4877 📦.
6.1.1. Pseudo Home Address Registration 🧩
6.1.1.1. Generation 🎲
to protect location privacy in route optimization mode, the mobile node swaps the real home address in certain signaling and payload packets for the pseudo home address 🫣. Unlike the encrypted home address, the pseudo home address needs to be routable, so the home agent can intercept packets that use it as the destination address 🛎️. The pseudo home address is made by concatenating one of the home network prefixes with a random bit string 🪄. There are lots of ways to generate that random bit string, like using a random number generator or a secure encryption or hash algorithm 🎰.
using the pseudo home address instead of the real one, even for return routability and binding updates to the correspondent, has a few perks 💅. First, the pseudo home address doesn't reveal the identity of the mobile node, since it is not (or should not be) publicly known. So the signaling on the HA-CN path is more secure, because attackers can't work out who the mobile node is from the pseudo home address 🕵️. Second, the mobile node can talk to a correspondent without giving up its real home address 🙈. Finally, the chosen pseudo home address can be different for different correspondents, for both signaling and data traffic 🦋.
The prefix used to form the pseudo home address MUST be managed by the same home agent, so it can forward the return routability messages 🏠. It doesn't have to be the same prefix as the real home address, but it is highly recommended to be different 💜. For example, a home agent might use a separate prefix pool for location privacy purposes for a group of mobile nodes. That way the real home address and the pseudo home address aren't co-related (assuming the mobile node picks different interface identifiers (IIDs)) 🧠✨.
6.1.1.2. Registration 📋
the mobile node MUST register the pseudo home address before it actually uses it with a correspondent node 🙏. To do that, it puts a pseudo home address in the Pseudo Home Address mobility option of the Binding Update message sent to the home agent. If the home agent supports the location privacy solution, it runs Duplicate Address Detection to check whether this pseudo home address clashes with other pseudo home addresses from different mobile nodes 🔍. Based on the result, the home agent says yes or no by setting the right status code in the Pseudo Home Address Acknowledgement option of the Binding Acknowledgement message ✅❌. If the home agent would rather use a different home network prefix than the one in the requested pseudo home address, it sends the new pseudo home address back in the Pseudo Home Address Acknowledgement mobility option 🔄.
the mobile node MAY register the pseudo home address when it's about to talk to a correspondent node with location privacy protection 🫶. The default lifetime of registered pseudo home addresses is the same as the Home Binding Cache entry, but a mobile node may choose any value and a home agent may grant any value ⏳. The mobile node can add or delete any pseudo home address using the Pseudo Home Address mobility option in the home Binding Update message 🗂️. And the home agent doesn't have to recover the real home address from the pseudo home address, so it doesn't need to 🙌💖.
6.1.2. Home De-Registration ✨
okay so when the mobile node gets back home, de-registering works the same as in RFC 3775 🏠. the real home address is the source IP address in the Binding Update message and the destination IP address in the Binding Acknowledgement message 💖. de-registering the real home address automatically de-registers all the pseudo home addresses too, so no stragglers 🧹. but if the mobile node decides to disconnect from the home agent while it's still on its foreign link, the Binding Update and Acknowledgement look just like they did for home registration, except the Lifetime field is set to zero ⏳. the home agent then deletes the matching Binding Cache entry, including the registered pseudo home address if there is one 🗑️. clean exit, no drama 💅
6.2. Correspondent Binding Update Using the Pseudo Home Address 🦋
6.2.1. Return Routability Procedure 🔐
this location privacy solution doesn't change the care-of address test procedure from RFC 3775 at all 🙌. what we're doing is adding some extensions to the home address test procedure, where the mobile node gets a home keygen token that's generated from the pseudo home address 🎀.
the mobile node generates and sends a Home Test Init message to the home agent. it looks like this:
IPv6 header (source = care-of address, destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address, destination = correspondent)
Mobility Header (HoTI)
Home Init Cookie
Pseudo Home Address mobility option (pseudo home address)the difference from RFC 3775 is that the mobile node includes a Pseudo Home Address mobility option (see Section 7.3) in the Home Test Init message ✨. we need a new option to carry the pseudo home address because the security association between the mobile node and the home agent is based on the real home address, so the pseudo one has to ride along separately 🫶. the pseudo home address in that option is picked by the mobile node from the set of pseudo home addresses it registered with the home agent during the home registration procedure 💜. also, the Home Test Init message is protected by an IPsec security association in ESP tunnel mode, with a non-null encryption algorithm and a non-null authentication algorithm, as specified in RFC 3776 🔒.
when the home agent receives a Home Test Init message, it does the operation from Section 6.6.4 🛠️. if that works and the Pseudo Home Address mobility option is present, the home agent generates a Home Test Init message and forwards it to the correspondent node. the pseudo home address from the option becomes the source IP address in the forwarded message:
IPv6 header (source = pseudo home address,
destination = correspondent)
Mobility Header (HoTI)
Home Init Cookiethe forwarded message looks exactly the same to the correspondent node as in RFC 3775, so the correspondent node has no idea the pseudo home address is being used 🕵️♀️. it just makes a home keygen token using the same algorithm as RFC 3775:
home keygen token =
First (64, HMAC_SHA1 (Kcn, (pseudo home address | nonce | 0)))the correspondent node then replies with a Home Test message 📨. the format is the same as RFC 3776 says, except the pseudo home address is the destination IP address:
IPv6 header (source = correspondent,
destination = pseudo home address)
Mobility Header (HoT)
Home Init Cookie
Home Keygen Token
Home Nonce Indexwhen the home agent intercepts the Home Test message using proxy Neighbor Discovery, it does the operation from Section 6.6.5 🥰. if that succeeds, the home agent builds the Home Test message below and forwards it to the mobile node:
IPv6 header (source = home agent, destination = care-of address)
ESP header in tunnel mode
IPv6 header (source = correspondent, destination = home address)
Mobility Header (HoT)
Home Init Cookie
Home Keygen Token
Home Nonce Index
Pseudo Home Address Acknowledgement mobility option
(pseudo home address)when the mobile node gets the Home Test message, it does the operation from Section 6.5.5 🎉. if that works, the mobile node has a home keygen token computed using the pseudo home address ✨. once the care-of address test is done, the mobile node hashes the care-of keygen token and the home keygen token together to make Kbm, using the same method as RFC 3775 💖
6.2.2. Route-Optimized Correspondent Binding Update 🚀
in this procedure, the mobile node MUST use the same pseudo home address it used during the home address test procedure 🎯. that pseudo home address goes in the Home Address option of the correspondent Binding Update message:
IPv6 header (source = care-of address,
destination = correspondent)
Destination option header
Home Address destination option (pseudo home address)
Parameters:
sequence number (within the Binding Update message header)
home nonce index (within the Nonce Indices option)
care-of nonce index (within the Nonce Indices option)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BU)))when the correspondent node gets the Binding Update message, it does the same operation as RFC 3775 says 👀. if that works and the mobile node asked for an acknowledgement, the correspondent node replies with this Binding Acknowledgement:
IPv6 header (source = correspondent,
destination = care-of address)
Parameters:
sequence number (within the Binding Update message header)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))once the mobile node gets a Binding Acknowledgement saying the correspondent registration succeeded, it can finally use the pseudo home address to talk to the correspondent node 🥳
such a Binding Update message may also be used by the mobile node to delete a binding it set up earlier at the correspondent node 🧹. like RFC 3775, Kbm is generated only from the home keygen token that's based on the pseudo home address 🔑
6.2.3. Reverse-tunneled Correspondent Binding Update 🌀
the mobile node may choose to use reverse tunneling to send the Binding Update 🔁. the messages in this procedure look similar to what's described in Sections 5 and 6.2.1, except a pseudo home address is used instead of the real home address 🎭. the Encrypted Home Address destination and the Encrypted Home Address routing header SHOULD be used to carry the encrypted pseudo home address 🔐
6.2.4. Using Different Pseudo Home Addresses with Different Correspondent Nodes 🌸
based on its configuration and policy, the mobile node can choose to use the same or different pseudo home addresses with different correspondent nodes 🧩. using a different pseudo home address with each correspondent node may help prevent the mobile node's activities from being linked and correlated 🕶️. to do that, the mobile node picks a different but already registered pseudo home address and repeats the return routability procedure and the correspondent binding update procedure with each correspondent node 💅
and if the mobile node prefers, it MAY use different pseudo home addresses for different sessions with the same correspondent node 🦄. this typically needs extra configuration at the mobile node that links a specific session (identified by things like the port number and the protocol number) to a specific pseudo home address ⚙️. this document doesn't get into the details of this solution 🙈
6.3. Payload Packets 📦
6.3.1. Reverse Tunneling Mode 🔁
payload packets reverse-tunneled via the home agent have the same format as the one specified for the home address test procedure in Section 6.2.1 🎀
6.3.2. Route Optimization Mode 🏎️
when the route-optimized correspondent binding update procedure runs, payload packets exchanged between the mobile node and the correspondent node have the same format as RFC 3775 specifies 💜. how the mobile node behaves when talking to the correspondent node in route optimization mode is covered in Section 6.5.6 ✨
when the reverse tunneled correspondent binding update procedure runs, the payload packet format is the same as Section 5 says, except the encrypted pseudo home address SHOULD be included in the Encrypted Home Address destination option and the Encrypted Home Address routing header 🫧
6.4. Prefix Discovery 🔍
the solution for protecting location privacy during prefix discovery is pretty similar to the one used during the home binding update procedure 👯♀️
6.5. Mobile Node Operation 📱
in this section we walk through what the mobile node does when the location privacy solution is in use 🧠
6.5.1. Conceptual Data Structures 🗂️
6.5.1.1. Pseudo Home Address Table 📒
we're introducing a new data structure called the Pseudo Home Address table, which records info about pseudo home addresses 💖. the mobile node may keep a Pseudo Home Address table for each home agent it registers with 🏠. each entry in the table holds a pseudo home address and its state, which is either "unconfirmed" or "confirmed" ✅. the mobile node creates or updates entries when it sends the home Binding Update message or gets the home Binding Acknowledgement message 📬. the pseudo home address can be used as the key to search the table 🔎. there MUST NOT be any duplicated pseudo home addresses stored in the Pseudo Home Address table 🚫
6.5.1.2. Binding Update List 📝
the Binding Update List entry gets extended with a field called Pseudo Home Address 🌈. this field MAY be implemented as a pointer to the matching entry in the Pseudo Home Address table 👉. the pointer starts out as NULL when the Binding Update List entry is created (for example, when the mobile node sends a Binding Update message or a Home Test Init message to the home agent) 🌱. for a binding sent to a specific home agent, the Pseudo Home Address field points to the first entry in the Pseudo Home Address table (or NULL if the table is empty), so the mobile node can reach every pseudo home address registered at that home agent 🗝️. for a binding sent to a specific correspondent node, the Pseudo Home Address field points to the Pseudo Home Address table entry holding the actual pseudo home address used with that correspondent node (or NULL if no pseudo home address is used with it) 💫
6.5.2. Binding Update to the Home Agent ✨
okay so the mobile node can decide to do its home registration with location privacy protection 🔒, like when it attaches to a foreign link or when it needs to extend how long its registered home binding lasts 🫶
since IPsec tunnel mode is in play, the mobile node MUST negotiate a non-null encryption algorithm (for example, during the bootstrapping) and use it to protect the home Binding Update message as specified in RFC 3775 and RFC 4877 💅 the mobile node can also register a pseudo home address, like we talked about above 🧚 and if it doesn't want to register the pseudo home address yet, but still wants to find out whether the home agent supports the location privacy solution, it includes a Pseudo Home Address mobility option without the Pseudo Home Address field in the Binding Update message sent to the home agent 👀
after sending the home de-registration binding update message, the mobile node does everything RFC 3775 says, and ALSO MUST stop using any data structure specific to the location privacy solution 🙅♀️ it MAY delete them once the Binding Acknowledgement message is processed successfully 🧹
6.5.3. Binding Acknowledgement from the Home Agent 🎀
with IPsec tunnel mode, the mobile node follows the rules in RFC 3775 and RFC 4877 to process the Binding Acknowledgement message, no drama 💖
if there are one or more Pseudo Home Address Acknowledgement mobility options in the Binding Acknowledgement message, the mobile node checks the Status field in each one 👀 if the Status field in an option is 0 (Success), the pseudo home address gets added to the Pseudo Home Address table (if it's not already there), and that entry's state is set to "confirmed" ✅
otherwise, the mobile node deletes any existing pseudo home address that's in the "unconfirmed" state 🗑️ (so either it got an error code, or no acknowledgement showed up for it at all). it's giving clean-up era 🧼
the mobile node considers that the home agent supports the location privacy solution if it gets a valid Pseudo Home Address Acknowledgement mobility option, with or without a Pseudo Home Address field 🦋
and lowkey important: the mobile node MUST determine whether the home registration succeeds or not based on what is specified in RFC 3775 🫶
6.5.4. Home Test Init to the Home Agent 🌸
so to get location privacy protection while talking to the correspondent node in route optimization mode, the mobile node generates a Home Test Init message based on RFC 3775 and RFC 3776 🕵️♀️ if the return routability procedure is for a brand-new session with the correspondent node, the mobile node picks any pseudo home address from the ones already registered with the home agent and stored in the Pseudo Home Address table 🎲 otherwise, it must use the same pseudo home address it used with that same correspondent node before 🔁
the chosen pseudo home address goes in the Pseudo Home Address mobility option of the Home Test Init message, and this message is protected by an IPsec security association with a non-null encryption algorithm 🔐 slay
after sending the Home Test Init message to the home agent, if there's no Binding Update List entry for the correspondent node yet, the mobile node creates one that points to the pseudo home address it used 📝 if there already is one, it just updates that existing entry 💜
6.5.5. Home Test from the Home Agent 💌
when the mobile node gets a Home Test message from the home agent, it processes the packet using the rules in RFC 3775 and RFC 3776 🧠 if the packet is valid and there's a Pseudo Home Address Acknowledgement option in it, the mobile node checks the Status field in that mobility option like this:
- If the Status field says the home address test using the pseudo home address succeeded (the Status field is
0), then, on top of what RFC 3775 says, the mobile node gets ready to use the pseudo home address from the Pseudo Home Address Acknowledgement option for the correspondent registration 🎉 - If the Status field says the home address test using the pseudo home address failed (the Status field is larger than
127), the mobile node can fix whatever caused the error and resend the Home Test Init message, subject to the retransmission limit in RFC 3775 🔧 if that doesn't happen or it doesn't work out, then the mobile node SHOULD record in its Binding Update List that the future home address test procedure SHOULD NOT use that pseudo home address with this correspondent node 🚫 (bestie, don't make the same mistake twice)
6.5.6. Route-Optimized Payload Packets 🦋
once the mobile node finishes the route-optimized correspondent registration using the pseudo home address, payload packets go to the correspondent node with the pseudo home address in the Home Address destination option ✈️
the packet processing rules for sending and receiving route-optimized packets are the same as in RFC 3775, except that pseudo home addresses are used instead 💅 and if encrypted pseudo home addresses are being used, both the mobile node and the correspondent node have to swap the encrypted address for the pseudo home address before handing packets up to the upper layers 🔄
if the mobile node masks the pseudo home address AND uses the reverse-tunneled correspondent binding update procedure, the mobile node does what's specified in Section 5.3.4, except the pseudo home address is expected instead of the real home address 🎭
6.5.7. Receiving Binding Refresh Request 🌈
when the Mobile Node gets a Binding Refresh Request message from a correspondent node, the destination IP address might be the pseudo home address 👀 in that case, the mobile node has to check the matching Binding Update List entry for the correspondent node 🔍 if the pseudo home address is invalid, the mobile node silently discards the message 🤫 otherwise, the mobile node refreshes the binding with the correspondent node by using that same pseudo home address 💖
6.6. Home Agent Operation 👑
this section is all about what the home agent does when the location privacy solution is in use 🏠
6.6.1. Conceptual Data Structures 🧩
the Binding Cache entry gets extended with a field that points to a list of the pseudo home addresses that are currently accepted 📋 note that each registered pseudo home address MUST be unique 🔑 and all the registered pseudo home addresses SHOULD be organized so the associated Binding Cache entry can be found quickly when a pseudo home address is used as the key to look up the Binding Cache 🔎
6.6.2. Binding Update from the Mobile Node 📮
if the received Binding Update message has one or more Pseudo Home Address mobility options, the home agent MUST ignore any option it doesn't recognize 🙈 if it does recognize an option, it generates a Pseudo Home Address Acknowledgement mobility option and sets some fields in it like this:
- If the Pseudo Home Address field received is empty, the Status field is set to
0(Success), and the Pseudo Home Address field stays empty 🫧 - If the Pseudo Home Address field received is set to all zero, the Status field is set to
0(Success), and a pseudo home address SHOULD be included in the Pseudo Home Address field, if the home agent supports dynamic pseudo home address assignment 🎲 otherwise, the Status field is set to132(Dynamic pseudo home address assignment not available) and the Pseudo Home Address field is empty 😭 - The Pseudo Home Address field received may contain an IPv6 address 🌐 if the format of that IP address is incorrect, the Status field is set to
130(Incorrect pseudo home address) 🙅♀️ if the IP address is invalid (for example, the prefix isn't a valid home network prefix, or it's detected as a duplicated IP address), the Status field is set to131(Invalid pseudo home address) 💀 in both cases the Pseudo Home Address field is empty. if the home agent suggests a different pseudo home address, the Status field is set to0(Success), and the new pseudo home address goes in the Pseudo Home Address field ✨ otherwise, if the home agent accepts the requested pseudo home address, the Status field is set to0(Success), and the same IP address goes in the Pseudo Home Address field 🎀 - If the home agent doesn't allow the mobile node to use the pseudo home address with the correspondent node, the Status field SHOULD be set to
129(Administratively prohibited) and the Pseudo Home Address field is empty 🛑 - If the home agent doesn't accept the Pseudo Home Address mobility option for any other reason, the Status field SHOULD be set to
128(Failure, reason unspecified) and the Pseudo Home Address field is empty 😵💫
when the home agent receives a Binding Update message protected with IPsec tunnel mode, it performs the operation specified in RFC 4877 🔐
and when the home agent receives and successfully processes a de-registration Binding Update message from the mobile node, then on top of what RFC 3775 says, the home agent MUST delete the data structures related to the location privacy extension 🧹
6.6.3. Binding Acknowledgement to the Mobile Node 💌
when the home agent sends a Binding Acknowledgement message protected with IPsec tunnel mode, it performs the operation specified in RFC 4877 🎁
the processing rules for the Pseudo Home Address Acknowledgement mobility option are described in Section 6.6.2 ✅
6.6.4. Home Test Init from the Mobile Node 🕵️♀️
when the home agent gets a Home Test Init message from the mobile node, it first verifies the message using the IPsec processing rules in RFC 3776 🔍 if verification fails, the home agent acts according to those IPsec processing rules 🚨 otherwise, if there's no Pseudo Home Address option in the Home Test Init message, the home agent does what RFC 3775 says ✅ if there is one, the following steps happen:
- The home agent looks up its Binding Cache using the real home address as a key 🔑 if the pseudo home address in the Pseudo Home Address option doesn't match any pseudo home address associated with that Binding Cache entry (including when the Pseudo Home Address field is set to zero), the home agent MUST reject the Home Test Init message 🙅♀️ by sending back a Home Test message that includes a Pseudo Home Address Acknowledgement option with the Status field set to
131(Invalid pseudo home address) 💅 - Otherwise, the home agent builds a Home Test Init message with the pseudo home address as the source IP address, and forwards it to the correspondent node 📨 and that's the whole flow, bestie 🍓
6.6.5. Home Test to the Mobile Node 🦋
okay bestie, so when the home agent catches a Home Test message through proxy Neighbor Discovery 👀, it first checks whether the destination IP address matches one of the real home addresses. if it does, the home agent just does what RFC 3775 says, no notes 💅. if it doesn't, the home agent looks up the Binding Cache to see whether there's a matching pseudo home address. no match? it silently discards the message 💀. if it finds one, it generates a Home Test message with a Pseudo Home Address Acknowledgement option and sends it to the mobile node 🫶. inside that option, the Status field is set to zero (Success) and the Pseudo Home Address field gets filled with the address it found ✨.
6.7. Correspondent Node Operation 🌸
so for the correspondent node, when it's part of the route-optimized correspondent binding update procedure, there's no new operation if only pseudo home addresses are used without encryption 🙌. this specification recommends using encrypted pseudo home addresses so nobody can figure out any prefix information about a mobile node 🔒. the additional operations are the same as Section 5.5, except the pseudo home address is used instead of the real home address 🧚.
7. Extensions to Mobile IPv6 ✨
this section is all about the experimental extensions to Mobile IPv6 used in this document 🧪. for experimentation purposes, the experimental IPv6 Option Type, the experimental IPv6 Routing Header Type, and the experimental Mobility Option Type defined in RFC 4727 [12] and RFC 5096 [13] can be used in the Encrypted Home Address destination option, the Encrypted Home Address routing header, the Pseudo Home Address mobility option, and the Pseudo Home Address Acknowledgement mobility option 💜. we'll go through the format of each extension for illustration purposes, obvs 🎀.
7.1. Encrypted Home Address Destination Option 🍓
this option is used in the Destination Option extension header (Next Header value = 60) 💖. here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Encrypted Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Type: a type that identifies the use of the encrypted home address in this option 🏷️. implementations of this RFC can use the value 0xFE. this value is reserved in RFC 4727 for all experiments involving IPv6 destination options.Encrypted Home Address: the encrypted home address generated from either a real or pseudo home address 🔐.
the processing of the other fields in the Encrypted Home Address option is the same as those fields in the Home Address option described in RFC 3775. but heads up 🚨: if the Encrypted Home Address option is in a packet, the encrypted home address in it MUST NOT be treated as the real source IP address by the receiver. no exceptions, bestie 🚫.
7.2. Encrypted Home Address Routing Header 🚂
the encrypted home address rides along in this routing header 🦋. layout:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=2 | Routing Type |Segments Left=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Encrypted Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Routing Type: a type that identifies the use of the encrypted home address in this routing header 🔖. implementations of this RFC can use the value 0xFE. this value is reserved in RFC 4727 for all experiments involving IPv6 routing headers.Encrypted Home Address: the encrypted home address generated from either a real or pseudo home address 🫧.
the processing of the other fields in the Encrypted Home Address routing header is the same as described in RFC 3775. and if this routing header is in a packet, the encrypted home address in it MUST NOT be treated as the real destination IP address by the receiver 🙈.
7.3. Pseudo Home Address Mobility Option 🧚
this mobility option goes in the mobility header, including the Binding Update message and the Home Test Init message, and carries zero or one pseudo home address 🌈. the alignment requirement for this option is 4n. layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |A| Reserved | Prefix length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Pseudo Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: a unique type (together with the 'A' bit in the Reserved field) for identifying the Pseudo Home Address Acknowledgement mobility option 🎀. for experimental purposes, the value of this type is 18, as reserved in RFC 5096.Length: the length of the Pseudo Home Address mobility option, not counting the Type and Length fields 📏. it MUST be 2 when the Pseudo Home Address field is not present; otherwise, it MUST be 18.Reserved Field: the 'A' bit MUST be set to zero to indicate that this is a Pseudo Home Address mobility option 🙅. the rest of the bits MUST be set as zero by the sender and ignored by the receiver.Prefix Length: the length of the home network prefix of the included pseudo home address 🛣️. when the Pseudo Home Address field is not present, the Prefix Length field MUST be set as zero.Pseudo Home Address: if present, this field holds a pseudo home address the mobile node wants for location privacy protection, or zero if the mobile node wants the home agent to hand it a pseudo home address 🍬. this field isn't present if the mobile node only wants to find out whether the home agent supports location privacy solutions. the Length field is how you detect whether the Pseudo Home Address field is there ✨.
7.4. Pseudo Home Address Acknowledgement Mobility Option 💜
this mobility option goes in the mobility header, including the Binding Acknowledgement message and the Home Test message sent to the mobile node, and carries zero or one pseudo home address 🫶. it's used to show the status of the pseudo home address registration and/or whether the home agent supports location privacy solutions. the alignment requirement for this option is 2n. layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Prefix length | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Pseudo Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: a unique type (together with the 'A' bit in the Reserved field) for identifying the Pseudo Home Address Acknowledgement mobility option 🎀. for experimental purposes, the value of this type is 18, as reserved in RFC 5096.Length: the length of the Pseudo Home Address Acknowledgement mobility option, not counting the Type and Length fields 📏. it MUST be 4 when the Pseudo Home Address field is not present; otherwise, it MUST be 20.Reserved: the 'A' bit MUST be set to one to indicate that this is a Pseudo Home Address Acknowledgement mobility option ✅. the rest of the bits MUST be set as zero by the sender and ignored by the receiver.Prefix Length: the length of the home network prefix of the included pseudo home address 🛣️. when the Pseudo Home Address field is not present, the Prefix Length MUST be set as zero.Status: shows the status of the pseudo home address registration 🚦. values from 0 to 127 mean success, and higher values mean failure. these values are reserved:
0 Success
128 Failure, reason unspecified
129 Administratively prohibited
130 Incorrect pseudo home address
131 Invalid pseudo home address
132 Dynamic pseudo home address assignment not availableReserved: this field is reserved for future use 🔮. it MUST be set to zero by the sender and ignored by the receiver.Pseudo Home Address: if present, this field holds a pseudo home address that the home agent registers for the mobile node to use for location privacy protection 🫧. this field is not present when the home agent only needs to say that it supports location privacy solutions, in response to a query from the mobile node. the Length field is how you detect whether the Pseudo Home Address field is there 💖.
8. Security Considerations 🔐
okay bestie, this is the serious part 😭 The solutions in this document tackle one of the big security issues in the mobile world, which is location privacy 🦋. We check how each solution handles location privacy all the way through the doc. We designed them to fit neatly into the Mobile IPv6 framework, so the same threat analysis, security mechanisms (such as IPsec, the sequence number in binding signaling messages, the return routability procedure), and considerations from RFC 3775 still apply 💅. We still go deep on the security threats that come with the location privacy solutions, and we show that they don't add any new vulnerability or weaken the security protection of the original Mobile IPv6 protocol 👑.
8.1. Home Binding Update
Given how strong the cryptography algorithm used to generate the encrypted home address is, eavesdroppers can't work out the real home address from the encrypted home address. That means they can't link the care-of address to the real home address 🙈. On top of that, the encrypted home address can be updated, so eavesdroppers can't easily keep track of the mobile node's ongoing activities ✨.
During pseudo home address registration, the home agent checks that the requested pseudo home address isn't already in use by another mobile node. So no other mobile node can, by accident or on purpose, hijack the ongoing sessions of a victim mobile node by registering the same pseudo home address 🚫.
Okay, the sneaky part: a mobile node could try to register a huge pile of pseudo home addresses, which could drain the pool and stop other mobile nodes from getting location privacy protection 💀. So the home agent MUST limit the number of pseudo home addresses that a mobile node can request. Also, because there's an IPsec security association between the home agent and the mobile node, if anyone misuses pseudo home address registration, the home agent can figure out which mobile node is being naughty and take further action 👮♀️.
8.2. Correspondent Binding Update
The return routability procedure using the pseudo home address works on the same principle as the original one. The message exchange checks that the mobile node is reachable at both the pseudo home address and the care-of address (this works because the pseudo home address is required to be routable) 🛣️. The extended return routability procedure also uses the same security mechanisms defined in RFC 3775, like the nonce, the node key, and the sequence number, to protect against attacks 🔒. Overall, it gives the same security strength as the original return routability procedure, no cap 💯.
The reverse-tunneled correspondent binding update procedure doesn't weaken security either. Yes, the real home address is sent in cleartext on the HA-CN path, but eavesdroppers on that path can already do much worse attacks against a mobile node using the Mobile IPv6 protocol 😤.
8.3. Route-Optimized Payload Packets
Using the Encrypted Home Address option in route-optimized packets has the same security implications as using the Home Address option in those packets. For example, attackers could use the Encrypted Home Address option to launch reflection attacks, such as by putting the IP address of a victim node into the Encrypted Home Address option 👀. Just like the processing rule for the Home Address option in RFC 3775, this document restricts the Encrypted Home Address option: it can only be used if there is an established Binding Cache entry containing the encrypted (pseudo) home address 🚧.
With the proposed location privacy solutions, the Encrypted Home Address routing header carries the encrypted (pseudo) home address. The same threats RFC 3775 describes for the Type 2 routing header are also possible when the routing header carries the encrypted (pseudo) home address 😬. To handle this, the document uses similar processing rules: if the encrypted (pseudo) home address in the Encrypted Home Address routing header doesn't match the one stored in the Binding Update List entry, the packet gets dropped 🗑️.
9. Related Work 🧚
Our work builds on earlier discussions of this topic 🌸. Like the pseudo home address, many documents have proposed using a temporary identity in place of the mobile node's home address in the IPsec security association, in Mobile IPv6 signaling messages, and in data packets. The problem is that the details of how to generate and update that identity are missing. So below, we survey the related work 📚.
RFC 4941 [10] specifies a mechanism for generating randomized interface identifiers, which can be used to update the care-of address and the home address. With our solution, though, the prefix of a pseudo home address can differ from the prefix of the real home address and from other pseudo home addresses. That stops eavesdroppers from correlating and analyzing IP traffic based on a shared prefix 🙌. We also look at how often the IP address should be updated in a mobility scenario, so we can resist the profiling attack both effectively and efficiently 🎯.
In [16], the authors propose a temporary identity called the Temporary Mobile Identifier (TMI) to replace the home address. They also discuss whether the Crypto-Based Identifier (CBID), Cryptographically Generated Addresses (CGA), or Mobility Anchor Point (MAP) could further protect location privacy 🤔. But a TMI is a 128-bit random number, which isn't routable. That makes it unsuitable as the source IP address in the Home Test Init message that the home agent forwards to the correspondent node. Otherwise, the home agent can't receive the Home Test message from the correspondent node 😭. The document also doesn't say how to update the TMI to deal with the profiling attack.
In [14], the authors propose a mechanism that uses an identity as the home address and periodically updates it, using a key and a previous identity as inputs to a cryptography algorithm 🔑.
In [15], the authors propose updating the mobile node's home address periodically to hide its movement. The new home address is generated from the current local network prefix, the Binding Update session key, and the previous home address, and it gets updated every time the return routability procedure runs. The generated home address is random, routable, recognizable, and recoverable 💖.
In [18], the authors propose a mechanism that gets both route optimization and location privacy at the same time 🦋. It does this by finding a tunneling agent near the correspondent node and bidirectionally tunneling data traffic between the mobile node and that tunneling agent ✨.
10. IANA Considerations 📋
This document creates a new registry called "Pseudo Home Address Acknowledgement Status Codes" for the Status field in the Pseudo Home Address Acknowledgement mobility option. The current values are described in Section 7.4 and are as follows:
0 Success
128 Failure, reason unspecified
129 Administratively prohibited
130 Incorrect pseudo home address
131 Invalid pseudo home address
132 Dynamic pseudo home address assignment not available11. Conclusion 🎀
In this document, we've proposed solutions for location privacy issues in the context of mobility 💜. The main idea is to hide the binding between the home address and the care-of address from eavesdroppers and from the correspondent node 🙈. We described two methods. The first method extends return routability to hide the real home address in Binding Update and data packets. It uses the real home address in return routability signaling and doesn't require any changes to the home agent 🌷. The second method uses pseudo home addresses starting from return routability signaling, and it requires some extensions to the home agent operation. This method stops the real home address from being revealed on the HA-CN path 🔥. Together, the two methods hide the real home address from eavesdroppers, and the second method can also hide it from correspondents 👑.
The solutions we've proposed are for the basic Mobile IPv6 protocol specified in RFC 3775. Lots of extensions to Mobile IPv6 have been proposed recently, such as the NEMO Basic Support protocol [19], Dual Stack Mobile IPv6 Support [20], Multiple Care-of Addresses Registration [21], Binding Revocation [22], and the Generic Signaling Message [23] 🌈. The proposed location privacy solutions are expected to work with these extensions too, with some modifications if needed 🧚. One of our future works is to clarify any related issues that come up when the location privacy solutions are used with new Mobile IPv6 extensions 🛠️.
12. Acknowledgements 🫶
The authors would like to thank the co-authors of the previous documents this one is derived from: Vijay Devarapalli, Hannu Flinck, Charlie Perkins, Feng Bao, Robert Deng, James Kempf, and Jianying Zhou 💕. Sincere appreciation also goes to Claude Castelluccia, Francis Dupont, Gabriel Montenegro, Greg Daley, Kilian Weniger, Takashi Aramaki, Wassim Haddad, Heejin Jang, and Michael Welzl for their valuable contributions, review, and discussion 🥹. Work by Fan Zhao was done while he was at University of California, Davis and Marvell Semiconductor, Inc. 🎓
13. References 📖
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[3] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[7] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[8] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture", RFC 4877,
April 2007.
[9] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[10] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions
for Stateless Address Autoconfiguration in IPv6", RFC 4941,
September 2007.
[11] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
Problem Statement", RFC 4882, March 2007.
[12] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6,
UDP, and TCP Headers", RFC 4727, November 2006.
[13] Devarapalli, V., "Mobile IPv6 Experimental Messages", RFC 5096,
December 2007.13.2. Informative References
[14] Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6", Work in Progress, March 2005. 🦋
[15] Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol for Hiding Movement of Mobile Nodes in Mobile IPv6", Work in Progress, March 2005. 🌸
[16] Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple Privacy Extension for Mobile IPv6", Work in Progress, July 2006. ✨
[17] Daley, G., "Location Privacy and Mobile IPv6", Work in Progress, January 2004. 💜
[18] Weniger, K. and T. Aramaki, "Route Optimization and Location Privacy using Tunneling Agents (ROTA)", Work in Progress, October 2005. 🧚
[19] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. 🎀
[20] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. 🍓
[21] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. 💅
[22] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", Work in Progress, October 2009. 🌈
[23] Haley, B. and S. Gundavelli, "Mobile IPv6 Generic Signaling Message", Work in Progress, August 2008. ⭐
Appendix A. Profiling Attack: Discussion 🕵️♀️✨
Okay bestie, profiling attacks are a real threat to user privacy 😭. If someone collects and analyzes IP traffic, either live or after the fact, they can dig up sensitive info about you. In the mobility context, the profiling attack doesn't directly break location privacy the way exposing the binding between the home address and the care-of address does. But attackers can still infer the mobile node's roaming and track its movement (aka handover) by profiling its communication through certain IP packet fields, like a constant IPsec SPI used during home registration. The more info they collect, the higher the chance location privacy gets compromised, and that just leads to more targeted profiling. Scary stuff, fr fr 💀
We did think about the profiling problem when designing the solution to IP address location privacy. Still, not every part of profiling attacks is covered, because the problem spans multiple protocol layers. So below, we give a broad discussion of profiling attacks and protection mechanisms, organized by how profiling attacks can actually be carried out. The sections aren't sorted by any particular criteria, and they might not list every possible attack method. For example, profiling attacks based on upper-layer payloads in data packets aren't discussed here. 🫶
A.1. The Care-of Address 🏡
Eavesdroppers on the MN-HA path and/or the MN-CN path can profile the mobile node's communication by collecting packets that have the same care-of address. It is recommended that the mobile node periodically updates its care-of address by using DHCPv6 or the IPv6 address privacy extension, even if it doesn't change its current attachment point. And it's even better to change the network prefix of the care-of address periodically, since eavesdroppers may profile IP packets based on the common network prefix. Main character energy, changing up your look 💖
Since the binding update procedure has to be performed once the care-of address changes, the mobile node may choose to change its care-of address when the Binding Cache entry at the home agent or the correspondent node is about to expire. That way, it saves on signaling overheads 🧠
A.2. Profiling on the Encrypted Home Address 🔐
The encrypted home address can be generated from either a real or a pseudo home address, and it can be dynamically updated. That's because a new key is generated whenever a new round of the return routability procedure runs, which makes the encrypted home address look different in later Binding Update and Acknowledgement messages. Still, the same encrypted home address is used in payload packets forwarded via the optimized route until the next round of the return routability procedure. Since updating the encrypted home address costs a lot in overhead, the proposed location privacy solutions still give a reasonable level of protection against this kind of profiling 🌸
A.3. The IPsec SPI 🎀
Eavesdroppers on the MN-HA path can profile the mobile node's communication based on the SPI of an IPsec security association. That association protects either the home Binding Update and Acknowledgement messages or bidirectional-tunneled payload packets.
To resist this, the IPsec SPI needs to be updated periodically. One option is for the mobile node and the home agent to rekey the IPsec security association or re-authenticate periodically. The catch is that this may mean more signaling overhead 😮💨 Another option is for the mobile node or the home agent to generate a new SPI and tell each other about it through Binding Update and Acknowledgement messages protected by an existing IPsec security association with a non-null encryption algorithm. This way, the new SPI info stays hidden from eavesdroppers 🤫
The new SPI MUST not conflict with other existing SPIs. If a conflict is detected on one end point, another SPI MUST be generated and synchronized with the other end point. 🚨
The new SPI gets applied to the next packet that needs protecting by this IPsec security association. Honestly, this solution requires close teamwork between Mobile IP and IPsec. For example, when the home agent receives a new SPI suggested by the mobile node, it needs to change the corresponding Security Association Database (SAD) entry. 🫠
A.4. The IPsec Sequence Number 🔢
The IPsec sequence number is required to be larger than the one in the previous valid IPsec packet if the anti-replay service is enabled. But if the increment of the IPsec sequence number is fixed (say, it goes up sequentially), eavesdroppers can spot a sequence of IPsec packets from or to the same mobile node and track its activities. One possible fix is to randomize the increment of the IPsec sequence number on both end points (the mobile node and the home agent) of the IPsec security association. How the randomness gets generated is implementation specific. It could be, for example, any random number generator, chosen independently by each end point 🎲
A.5. The Regular Interval of Signaling Messages ⏰
As described in RFC 3775, certain signaling messages may be exchanged on a regular basis. For example, correspondent registration has to be performed every MAX_RR_BINDING_LIFETIME seconds, and the home binding update procedure has to be performed regularly if the lifetime of the home Binding Cache entry is fixed. That kind of predictable timing lets eavesdroppers run traffic analyses and correlate different messages. Background traffic and routing dynamics can make the timing of messages look irregular to an eavesdropper at a given vantage point. Still, a better solution is to randomize the lifetime of the Binding Cache entry in the home agent and the correspondent node 🌀
A.6. The Sequence Number in the Binding Update Message 📨
RFC 3775 requires that the sequence number in the Binding Update message be larger than the one in the previous valid Binding Update message for a particular mobile node. But if the increment of the sequence number in the home or correspondent Binding Update message is fixed (like it's sequentially increasing), eavesdroppers on the MN-HA or MN-CN path can identify a sequence of Binding Update messages from the same mobile node and track its movement. One possible solution is for the mobile node to randomize the increment of the sequence number used in later Binding Update messages. How the randomness is generated is implementation specific. It could be, for example, any random number generator. Note that this algorithm isn't needed when the sequence number is encrypted, for example, when the home Binding Update message is protected by an IPsec tunnel mode security association 🔒
A.7. Multiple Concurrent Sessions 👯
(Colluding) eavesdroppers can correlate the mobile node's different sessions with the same or different correspondent nodes, for example, based on the same pseudo home address and/or the same care-of address. A possible solution is to use different pseudo home addresses and different care-of addresses in different sessions. The mobile node may also use the same pseudo home address with different correspondent nodes, as long as the pseudo home address is masked by different privacy management keys generated during the return routability procedure with each correspondent node. That way, the encrypted pseudo home addresses used with different correspondent nodes look different to eavesdroppers 🪞
A.8. Summary 💫
Eavesdroppers have multiple ways to correlate observed activities. For example, some IP fields contain constant values and stay unchanged for a long time, which lets eavesdroppers identify and link the mobile node's activities deterministically. Other methods may be less reliable for traffic analysis and correlation, but they still give malicious attackers extra hints 👀
The solution to the profiling attack is to update certain IP fields periodically. Generally, the more often you update, the better the chances of resisting profiling attacks, but the higher the cost in communication and processing overheads and complexity. Since eavesdroppers can profile activities based on multiple fields, it may not be cost-effective to update some fields more frequently than others. On the flip side, it may reduce some overhead if all the related IP fields are updated together at the same frequency. 🧁
The profiling attack is a complicated issue, and a complete solution would have to weigh many different tradeoffs, such as complexity, effectiveness, and efficiency. No one-size-fits-all answer here, babe 🌈
Authors' Addresses 💌
Ying Qiu
Institute for Infocomm Research, Singapore
1 Fusionopolis Way
#21-01 Connexis (South Tower)
Singapore 138632
Phone: +65-6408 2053
EMail: qiuying@i2r.a-star.edu.sg
Fan Zhao (editor)
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
EMail: fanzhao@google.com
Rajeev Koodli
Cisco Systems
EMail: rkoodli@cisco.com📦 where this page comes from
- ietf: rfc5726 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms