RFC 6967

Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments

📅 published June 2013, from ietf

Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments 🦋

okay bestie, the title block is giving very organised 💅 so here's the tea:

  • RFC number: 6967 🎀
  • Stream: Internet Engineering Task Force (IETF) 🌈
  • Authors: M. Boucadair (France Telecom), J. Touch (USC/ISI), P. Levis (France Telecom), and R. Penno (Cisco) 🫶
  • Category: Informational, so not a standards track spec 📚
  • ISSN: 2070-1721 ✨
  • Date: June 2013 🍓
  • Obsoletes or updates: the title block doesn't list anything this one obsoletes or updates 🙈

Abstract ✨

okay so this doc is basically a collection of possible solutions for revealing a host identifier (called HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are in the path 🌸. A remote server could use that identifier to sort packets by the host that sent them. The host identifier must be unique to each host under the same shared IP address 🔥.

This document analyzes a bunch of potential solutions for revealing a host identifier. It does not recommend a particular solution, although it does highlight the hazards of some approaches 💀. So it doesn't pick a winner, but it does call out the risky stuff 😬.

Status of This Memo 🧚

This document is not an Internet Standards Track specification. It's published for informational purposes 📚.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard, see Section 2 of RFC 5741 💜.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6967 🦋.

Copyright (c) 2013 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 of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License 📜.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
2.  On HOST_ID  . . . . . . . . . . . . . . . . . . . . . . . . .   5
3.  HOST_ID and Privacy . . . . . . . . . . . . . . . . . . . . .   6
4.  Detailed Solutions Analysis . . . . . . . . . . . . . . . . .   8
  4.1.  Use the Identification Field of the IPv4 Header (IP-ID) .   8
    4.1.1.  Description . . . . . . . . . . . . . . . . . . . . .   8
    4.1.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . .   8
  4.2.  Define an IP Option . . . . . . . . . . . . . . . . . . .   9
    4.2.1.  Description . . . . . . . . . . . . . . . . . . . . .   9
    4.2.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . .   9
  4.3.  Define a TCP Option . . . . . . . . . . . . . . . . . . .   9
    4.3.1.  Description . . . . . . . . . . . . . . . . . . . . .   9
    4.3.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . .  10
  4.4.  Inject Application Protocol Message Headers . . . . . . .  11
    4.4.1.  Description . . . . . . . . . . . . . . . . . . . . .  11
    4.4.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . .  12
  4.5.  PROXY Protocol  . . . . . . . . . . . . . . . . . . . . .  13
    4.5.1.  Description . . . . . . . . . . . . . . . . . . . . .  13
    4.5.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . .  13
  4.6.  Assign Port Sets  . . . . . . . . . . . . . . . . . . . .  14
    4.6.1.  Description . . . . . . . . . . . . . . . . . . . . .  14
    4.6.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . .  14
  4.7.  Host Identity Protocol (HIP)  . . . . . . . . . . . . . .  14
    4.7.1.  Description . . . . . . . . . . . . . . . . . . . . .  14
    4.7.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . .  14
  4.8.  Use of a Notification Channel (e.g., ICMP)  . . . . . . .  15
    4.8.1.  Description . . . . . . . . . . . . . . . . . . . . .  15
    4.8.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . .  15
  4.9.  Use Out-of-Band Mechanisms (e.g., Ident)  . . . . . . . .  16
    4.9.1.  Description . . . . . . . . . . . . . . . . . . . . .  16
    4.9.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . .  17
5.  Solutions Analysis: Synthesis . . . . . . . . . . . . . . . .  18
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  21

1. Introduction ✨

okay so [RFC6269] tells us that a bunch of issues pop up when one IP address is shared among several subscribers 🫠. They show up in lots of deployment setups, like Carrier-Grade NAT (CGN), application proxies, or Address plus Port (A+P) [RFC6346] 🎀. Some examples are:

  • implicit identification (Section 13.2 of [RFC6269]) 🕵️
  • spam (Section 13.3 of [RFC6269]) 📧
  • blacklisting a misbehaving host (Section 13.1 of [RFC6269]) 🚫
  • redirecting users with infected machines to a dedicated portal (Section 5.1 of [RFC6269]) 🦠

Now here's the main drama 🎭. Some servers look at the source IPv4 address as an identifier so they can treat certain incoming connections differently. Because of CGNs (e.g., NAT44 [RFC3022], NAT64 [RFC6146]), that address is going to be shared 🌸. So when a server gets packets from the same source address, the server can't tell which host actually sent them [RFC6269] 😭. The IPv4 address alone is not enough to uniquely tell a host apart. As a quick fix, people are tempted to look into ways of disclosing information that the remote server could use to uniquely tell apart packets sent from hosts using the same IPv4 address 👀.

The risks of not dealing with these issues include an OPEX (Operational Expenditure) increase for IP connectivity service providers (costs from calls to a hotline) 📞, revenue loss for content providers (losing users' audience) 💸, and customers being unhappy (low quality of experience, service segregation, and so on) 😤.

The point of this document is to analyze a set of alternative channels for conveying a host identifier, and to figure out how well each alternative solves the problem described in Section 2 🔍. The evaluation is meant to be comprehensive, no matter how mature or valid a currently known or proposed solution is 💅. The alternatives analyzed in the document are:

  • Use the Identification field of the IP header (denoted as IP-ID, Section 4.1). 🆔
  • Define a new IP option (Section 4.2). 🧩
  • Define a new TCP option (Section 4.3). 🧵
  • Inject application headers (Section 4.4). 💉
  • Enable Proxy Protocol (Section 4.5). 🛰️
  • Assign port sets (Section 4.6). 🎟️
  • Activate HIP (Host Identity Protocol) (Section 4.7). 🪪
  • Use a notification channel (Section 4.8). 🔔
  • Use an out-of-band mechanism (Section 4.9). 📮

A synthesis is in Section 5, and the detailed analysis is in Section 4 🧠.

Section 3 talks about privacy issues that all of the proposed solutions have in common. Digging into privacy issues specific to each solution is out of scope for this document 🔒.

This document doesn't include any recommendations, because the working group felt it was too premature to include one 🙈.

2. On HOST_ID 💖

Policies that rely on source IP addresses, and that some servers enforce, get applied to all hosts sharing the same IP address 😬. For example, if you blacklist the IP address of a spammer host, every other host that shares that address also loses access to the requested service 🚫. [RFC6269] describes these issues in detail 📖. So because addresses are shared, servers need extra information beyond the source IP address to tell the sending host apart. We call this information the HOST_ID 🫶.

The HOST_ID identifies a host under a shared IP address. Privacy-related considerations are discussed in Section 3 🔐.

In this document, a host can be any computer behind a Home Gateway, or any computer directly connected to an address-sharing function in the network provider's domain (usually that would be the Home Gateway itself) 🏠.

Because a remote server uses the HOST_ID to sort packets by sending host, the HOST_ID must be unique to each host under the same shared IP address, where that's possible 🧚. If only the Home Gateway is revealed to the operator side of the translation function, then the HOST_ID only needs to be unique to the Home Gateway 🏡. The HOST_ID does not need to be globally unique. Of course, the combination of the (public) IP source address and the identifier (i.e., HOST_ID) ends up being unique 💜.

If the HOST_ID is conveyed at the IP level, every packet has to carry it 📦. If it's conveyed at a higher, connection-oriented level, it's only needed once during session establishment (for instance, a TCP three-way handshake). After that, every packet received in that session gets attributed to the HOST_ID that was designated when the session opened 🤝.

In this document, we assume the operator-side address-sharing function injects the HOST_ID 🛠️. Another deployment option, which avoids potential performance degradation, is to let the host or Home Gateway inject its own HOST_ID, while the address-sharing function checks its content (just like an IP anti-spoofing function) 🛡️. For some proposals, the HOST_ID is retrieved using an out-of-band mechanism, or it's signaled in a dedicated notification channel 📡.

For A+P [RFC6346] and its variants, port set announcements may be needed, as discussed in Section 4.6 🎀.

Security considerations are common to all of the analyzed solutions (see Section 6) 🚨. Privacy-related aspects are discussed in Section 3 🦋.

The HOST_ID can be ambiguous for hosts with multiple interfaces, or with multiple addresses assigned to a single interface 🌈. HOST_IDs that are the same may be used to imply or infer the same end system. But HOST_IDs that are different should not be used to imply or infer whether the end systems are the same or different 👑.

3. HOST_ID and Privacy 🔒🎀

Okay so IP address sharing happens for a bunch of reasons 💅 For years, lots of network operators have saved public IPv4 addresses by using Customer Premises Equipment (CPE) that gives one single public IPv4 address to every host in the customer's local area network. It uses NAT [RFC3022] to translate between locally unique private IPv4 addresses and the CPE's public address. Once IPv4 address space runs out, address sharing between customers on a way bigger scale is likely to get way more common 📈 Plenty of individual users have no idea and no say when their unique IPv4 addresses get revealed as they send data over IP 🙈 But some users notice the privacy perks, and some may even make sure NAT sits between them and the public Internet 🧚 Basically, IP address sharing makes the actions of all users behind the NAT function unattributable to any single host 👀 That creates room for abuse, but it also gives some identity protection to non-abusive users who want to send data with less risk of being uniquely identified 🫶

The proposals in this document help tell apart hosts that share a public IP address ✨ How much they get told apart depends on what information is included in the HOST_ID 💖

The volatility of the HOST_ID info is kinda like the internal IP address 🔄 A distinct HOST_ID may get used by the address-sharing function when the host reboots or gets a new internal IP address. Same as persistent IP addresses, persistent HOST_IDs make user tracking over time easier 😬

As a general matter, the HOST_ID proposals do not try to make hosts any more identifiable than they'd be if they were using a public, non-shared IP address 🌸 However, depending on the solution proposal, adding HOST_ID info may let a device get fingerprinted more easily than it otherwise would. To prevent this, the following design considerations are to be taken into account:

  • It is recommended that HOST_IDs be limited to providing local uniqueness rather than global uniqueness 💅
  • The address-sharing function should not use permanent HOST_ID values 🚫

Should multiple solutions be combined (e.g., TCP option and Forwarded header) that include different pieces of information in the HOST_ID, fingerprinting may become even easier 😭 To prevent this, an address-sharing function that is able to inject HOST_IDs in several layers should reveal the same subsets of information at each layer. For example, if one layer references the lower 16 bits of an IPv4 address, the other layer should reference these 16 bits too 🎯

A HOST_ID can be spoofed, as this is also the case for spoofing an IP address 🥸 Furthermore, users of network-based anonymity services (like Tor [TOR]) may be capable of stripping HOST_ID information before it reaches its destination 🧅

In order to control the information revealed to external parties, an address-sharing function should be able to strip, rewrite, and add HOST_ID fields 🎛️

An address-sharing function may be configured to enforce different end-user preferences with regards to HOST_ID injection. For example, HOST_ID injection can be disabled for some users. This feature is policy based and deployment specific 📋

HOST_ID specification document(s) should explain the privacy impact of the solutions they specify, including the extent of HOST_ID uniqueness and persistence, assumptions made about the lifetime of the HOST_ID, whether and how the HOST_ID can be obfuscated or recycled, whether location information can be exposed, and the impact of the use of the HOST_ID on device or implementation fingerprinting. [IAB-PRIVACY] provides further guidance 🤓

For more discussion about privacy, refer to [RFC6462] 🔐

4. Detailed Solutions Analysis 🔍

4.1. Use the Identification Field of the IPv4 Header (IP-ID) 🆔

4.1.1. Description 📝

The IPv4 ID (Identification field of IP header, i.e., IP-ID) can be used to insert information that uniquely distinguishes a host among those sharing the same IPv4 address. Use of the IP-ID as a channel to convey the HOST_ID is a theoretical construct (i.e., it is an undocumented proposal) 🧠

An address-sharing function can rewrite the IP-ID field to insert a value that is unique to the host (16 bits are sufficient to uniquely disambiguate hosts sharing the same IP address) ✨ The address-sharing function injecting the HOST_ID must follow the rules defined in [RFC6864]; in particular, the same HOST_ID is not reassigned to another host sharing the same IP address during a given time interval ⏰

A variant of this approach relies upon the format of certain packets, such as TCP SYN, where the IP-ID can be modified to contain a 16-bit HOST_ID 🧩

Address-sharing devices using this solution would be required to indicate that they do so, possibly using a special DNS record 📡

4.1.2. Analysis 🧐

This usage is not consistent with the fragment reassembly use of the Identification field [RFC0791] or the updated handling rules for the Identification field [RFC6864] 🙃

Complications may arise if the packet is fragmented before reaching the device that is injecting the HOST_ID. To appropriately handle those packet fragments, the address-sharing function will need to maintain a lot of state 😵‍💫

Another complication to be encountered is where translation is balanced among several NATs. Setting the appropriate HOST_ID by a given NAT would alter the coordination between those NATs. Of course, one can argue that this coordinated NAT scenario is not a typical deployment scenario; regardless, using the IP-ID as a channel to convey a HOST_ID is ill-advised 🚩

4.2. Define an IP Option 🧩

4.2.1. Description 📝

An alternate way to convey the HOST_ID is to define an IP option [RFC0791]. A HOST_ID IP option can be inserted by the address-sharing function to uniquely distinguish a host among those sharing the same IP address. An example of such an option is documented in [REVEAL-IP]. This IP option allows the conveyance of an IPv4 address, an IPv6 prefix, a Generic Routing Encapsulation (GRE) key, an IPv6 Flow Label, etc. 🏷️

An IP option may also be used as described in Section 4.6 of [RFC3022] 📖

4.2.2. Analysis 🧐

This proposal can apply to any transport protocol. However, it is widely known that routers and other middleboxes filter IP options (e.g., drop IP packets with unknown IP options, strip unknown IP options, etc.) 🗑️

Injecting the HOST_ID IP option introduces some implementation complexity in the following cases:

  • The packet is at or close to the MTU size.
  • The options space is exhausted.

Previous studies demonstrated that "IP Options are not an option" (refer to [Not_An_Option] and [Options]) 💀

In conclusion, using an IP option to convey a HOST_ID is not viable. 🙅‍♀️

4.3. Define a TCP Option 🎀

4.3.1. Description 📝

The HOST_ID may be conveyed in a dedicated TCP option. An example is specified in [REVEAL-TCP]. This option encloses the TCP client's identifier (e.g., the lower 16 bits of its IPv4 address, its VLAN ID, VRF ID, or subscriber ID). The address-sharing device inserts this TCP option into the TCP SYN packet 🎁

4.3.2. Analysis 🧐

Using a new TCP option to convey the HOST_ID does not require any modification to the applications, but it is applicable only for TCP-based applications. Applications relying on other transport protocols are therefore left unsolved 😔

[REVEAL-TCP] discusses the interference with other TCP options 🔍

The risk of session failure due to handling a new TCP option is low as measured in [Options]. [REVEAL-TCP-EXP] provides a detailed implementation and experimentation report of a HOST_ID TCP option. This document provides an in-depth investigation of the impact of implementing HOST_ID on the host, the address-sharing function, and the enforcement of policies at the server side. It also reports a failure ratio of 0.103% among the top 100,000 websites 📊

Some downsides have been identified with defining a TCP option to reveal a host identity 👎

  • Conveying an IP address in a TCP option may be seen as a violation of OSI layers, but since IP addresses are already used for the checksum computation, this is not seen as a blocking point. Moreover, the updated version of [REVEAL-TCP] no longer allows conveyance of a full IP address because the HOST_ID is encoded in 16 bits.
  • TCP option space is limited and might be consumed by the TCP client. [REVEAL-TCP-EXP] discusses two approaches to sending the HOST_ID: sending the HOST_ID in the TCP SYN (which consumes more bytes in the TCP header of the TCP SYN) and sending the HOST_ID in a TCP ACK (which consumes only two bytes in the TCP SYN).
  • Content providers may find it more desirable to receive the HOST_ID in the TCP SYN, as that more closely preserves the HOST_ID received in the source IP address as per current practices. Moreover, sending the HOST_ID in the TCP SYN does not interfere with [FASTOPEN]. In the ACK mode, if the server is configured to deliver different data based on HOST_ID, then it would have to wait for the ACK before transmitting data.
  • HOST_ID mechanisms need to be aware of end-to-end (E2E) issues and avoid interfering with them. One example of such interference would be injecting or removing TCP options of transited packets; another such interference involves terminating and re-originating TCP connections not belonging to the transit device. The HOST_ID TCP option handled by the source node avoids this issue.
  • Injecting the HOST_ID TCP option introduces some implementation complexity if the options space is exhausted. Specification document(s) should specify the behavior of the address-sharing function in detail in such a case.
  • It is more complicated to implement sending the HOST_ID in a TCP ACK, as it can introduce MTU issues if the ACK packet also contains TCP data or if a TCP segment is lost. Note that MTU complications can be experienced if user data is included in a SYN packet (e.g., [FASTOPEN]).
  • When there are several NATs in the path, the original HOST_ID may be lost. The loss of the original HOST_ID may not be a problem, as the target usage is between proxies or between a CGN and server. Only the information leaked in the last communication leg (i.e., between the last address-sharing function and the server) is likely to be useful.
  • Interference with usages such as a Forwarded HTTP header (see Section 4.4) should be elaborated to specify the behavior of servers when both options are used; in particular, specify which information to use: the content of the TCP option or what is conveyed in the application headers.
  • When load balancers or proxies are in the path, this option does not allow the preservation of the original source IP address and source port. Preserving such information is required for logging purposes (e.g., [RFC6302]). [REVEAL-TCP-EXP] defines a TCP option that allows various combinations of source information (e.g., source port, source port and source IP address, source IPv6 prefix, etc.) to be revealed.

More discussion about issues raised when extending TCP can be found at [ExtendTCP] 📚

4.4. Inject Application Protocol Message Headers ✨

4.4.1. Description 💅

okay so another option is to not touch the transport or IP levels at all 🙈 and instead just slide the info needed to tell hosts apart right into the application payload 🎀 the format and semantics depend on the app (HTTP, SIP, SMTP, etc.) ✨

related mechanisms could be built for other application-layer protocols, but this doc only talks about HTTP and similar protocols 🌸

for HTTP, the Forwarded header [HTTP-FRWD] can show the original IP address when an address-sharing device is involved 👑 service providers running address-sharing devices can turn on injecting the Forwarded header, which encloses the original IPv4 address or the IPv6 prefix part (see Figure 1) 🦋 the address-sharing device has to strip all included Forwarded headers before injecting its own. servers may rely on this field to enforce policies like blacklisting misbehaving users 🚫

note that [HTTP-FRWD] standardizes the Forwarded header field, to replace the de facto (and not standard) X-Forwarded-For (XFF) header 🧚

Forwarded: for=192.0.2.1,for=[2001:db8::1]
Forwarded: proto=https;by=192.0.2.15

Figure 1: Example of Forwarded-For

4.4.2. Analysis 😭

not all apps hit by address sharing can support disclosing the original IP address. only a subset of protocols (e.g., HTTP) can rely on this solution.

for the HTTP case, to stop users from injecting invalid HOST_IDs, Wikimedia launched an initiative to maintain a list of trusted ISPs (Internet Service Providers) using XFF (see the list available at [Trusted_ISPs]). if an address-sharing device is on the list of trusted XFF ISPs, users editing Wikimedia behind it will appear to be editing from their "original" IP address and not from the NATed IP address. if offending activity is detected, individual hosts can be blacklisted instead of blacklisting all hosts sharing the same IP address.

XFF header injection is a common practice of load balancers 💜 when a load balancer is in the path, the original content of any included XFF header should not be stripped. otherwise, the info about the "origin" IP address gets lost.

when several address-sharing devices are crossed, the Forwarded header can convey the list of IP addresses (e.g., Figure 1). the origin HOST_ID can be exposed to the target server.

injecting the Forwarded header also introduces some implementation complexity if the HTTP message is at or close to the MTU size.

it has been reported that some HTTP proxy implementations may encounter parsing issues when injecting an XFF header 💀

injecting the Forwarded header for all HTTPS traffic is infeasible. this may be problematic given the current HTTPS usage trends 🥺

4.5. PROXY Protocol 🌈

4.5.1. Description 💖

the solution, referred to as the Proxy Protocol [Proxy], does not require any application-specific knowledge. the proposed solution (Proxy Protocol Version 1) would insert identification data directly into the application-data stream prior to the actual protocol data being sent, regardless of the protocol. every application protocol would begin with a textual string of "PROXY", followed by some textual identification data, and with a CRLF; only then would the application data be inserted. Figure 2 shows an example of a line of data used for this purpose, in this case for a TCP-over-IPv4 connection received from 192.0.2.1:56324 and destined to 192.0.2.15:443.

PROXY TCP4 192.0.2.1 192.0.2.15 56324 443\r\n

Figure 2: Example of PROXY Connection Report

upon receipt of a message conveying this line, the server removes the line from the incoming stream. the line is parsed to retrieve the transported protocol. the content of this line is recorded in logs and used to enforce policies.

Proxy Protocol Version 2 is designed to accommodate IPv4/IPv6 and also non-TCP protocols (see [Proxy] for more details) ✨

4.5.2. Analysis 🙈

this solution can be deployed in a controlled environment, but it cannot be deployed to all access services available in the Internet. if the remote server does not support the Proxy Protocol, the session will fail. other complications will arise due to the presence of firewalls, for instance.

as a consequence, this solution is infeasible and cannot be recommended. not it, bestie 🚫

4.6. Assign Port Sets 🦋

4.6.1. Description 🧚

this solution does not require any action from the address-sharing function to disclose a host identifier. instead of assuming that all transport ports are associated with one single host, each host under the same external IP address is assigned a restricted port set. these port sets are then advertised to remote servers using offline means. this announcement is not required for the delivery of internal services (i.e., offered by the service provider deploying the address-sharing function) relying on implicit identification.

port sets assigned to hosts may be static or dynamic.

port set announcements to remote servers are not required to reveal the identity of individual hosts; they are used to advertise the enforced policy to generate non-overlapping port sets (e.g., the transport space associated with an IP address is fragmented to contiguous blocks of 2048 port numbers).

examples of such an approach are documented in [RFC6346] and [DETERMCGN] 📚

4.6.2. Analysis 🫶

the solution does not require defining new fields or options; it is policy based.

the solution may contradict the port randomization [RFC6056] as identified in [RFC6269]. a mitigation would be to avoid assigning static port sets to individual hosts.

the method is convenient for the delivery of services offered by the service provider that is also offering the Internet access service 👑

4.7. Host Identity Protocol (HIP) 🌸

4.7.1. Description 🎀

[RFC5201] specifies an architecture that introduces a new namespace to convey identity information.

4.7.2. Analysis 🥺

this solution requires both the client and the server to support HIP [RFC5201]. additional architectural considerations are to be taken into account, such as the key exchanges.

an alternative deployment model that does not require the client to be HIP-enabled is having the address-sharing function behave as a UDP/TCP-HIP relay. this model is also not viable as it assumes all servers are HIP-enabled 😩

this solution is a theoretical construct (i.e., the proposal is not documented).

4.8. Use of a Notification Channel (e.g., ICMP) 🔥

4.8.1. Description 💜

another alternative is to convey the HOST_ID using a separate notification channel than the one the packets issued to invoke the service.

this solution relies on a mechanism where the address-sharing function encapsulates the necessary host-identifying information into an ICMP Echo Request packet that it sends in parallel with the initial session creation (e.g., SYN). the information included in the ICMP Request Data portion describes the five-tuples as seen on both sides of the address-sharing function. an implementation example is defined in [REVEAL-ICMP].

4.8.2. Analysis 🌈

  • this ICMP proposal is valid for any transport protocol that uses a port number. the address-sharing function may be configured with the transport protocols that will trigger issuing those ICMP messages.
  • a hint should be provided to the ultimate server (or intermediate nodes) that the ICMP Echo Request conveys a HOST_ID. this may be implemented using magic numbers (a magic number is a self-selected codepoint whose primary value is its unlikely collision with values selected by others).
  • even if ICMP packets are blocked in the communication path, the user connection does not have to be impacted.
  • implementations requiring a session establishment to be delayed until receipt of the companion ICMP Echo Request may lead to some user-experience degradation.
  • because of the presence of load balancers in the path, the ultimate server receiving the SYN packet may not be the one that receives the ICMP message conveying the HOST_ID.
  • because of the presence of load balancers in the path, the port number assigned by address sharing may be lost. therefore, the mapping information conveyed in the ICMP may not be sufficient to associate a SYN packet with a received ICMP.
  • the proposal is not compatible with the presence of cascaded NAT. the main reason is that each NAT in the path will generate an ICMP message to reveal the internal host identifier. because these messages will be translated by the downstream address-sharing devices, the remote server will receive multiple ICMP messages and will need to decide which host identifier to use.
  • the ICMP proposal will add traffic overhead for both the server and the address-sharing device.
  • the ICMP proposal is similar to other mechanisms (e.g., IPFIX [IPFIX-NAT] and Syslog [SYSLOG-NAT]) for reporting dynamic mappings to a mediation platform (mainly for legal traceability purposes). performance degradation is likely to be experienced by address-sharing functions because ICMP messages are sent for each new instantiated mapping (even if the mapping exists).
  • in some scenarios (e.g., Section 3 of [REVEAL-PCP]), the HOST_ID should be interpreted by intermediate devices that embed Policy Enforcement Points (PEP) [RFC2753] responsible for granting access to some services. these PEPs need to inspect all received packets in order to find the companion (traffic) messages to be correlated with ICMP messages conveying HOST_IDs. this induces more complexity to these intermediate devices.

4.9. Use Out-of-Band Mechanisms (e.g., Ident) 🧚

4.9.1. Description 🦋

another alternative is to retrieve the HOST_ID using a dedicated query channel.

an implementation example may rely on the Identification Protocol (Ident) [RFC1413]. this solution assumes that the address-sharing function implements the server part of IDENT, while remote servers implement the client part of the protocol. IDENT needs to be updated to be able to return a host identifier instead of the user-id as defined in [RFC1413]. the IDENT response syntax uses the same USERID field described in [RFC1413], but rather than returning a username, a host identifier (e.g., a 16-bit value) is returned. for any new incoming connection, the server contacts the IDENT server to retrieve the associated identifier. during that phase, the connection may be delayed ⭐

4.9.2. Analysis 🔍

  • okay so IDENT is specifically a TCP thing 🦋 other out-of-band mechanisms could be designed for other transport protocols like UDP, so it's not the end of the road 🌈
  • this solution makes the address-sharing function embed an IDENT server 🛠️ that's a lot of extra work for the box doing the sharing 😭
  • a hint should be given to the ultimate server (or intermediate nodes) that the address-sharing function does IDENT 💅 for example, by publishing it in DNS (other solutions can be envisaged ✨)
  • an out-of-band mechanism might need some admin setup, like a contract agreement, between whoever runs the address-sharing function and whoever runs the remote server 📜 this is NOT feasible across the whole Internet tbh 💀 making and maintaining deals between ISPs and every service is burdensome and not scalable, no thank u
  • if an implementation has to hold off on starting a session until the companion IDENT response shows up, users might notice a slower experience 🐌 not iconic
  • the IDENT proposal adds traffic overhead for both the server and the address-sharing device 📈
  • performance degradation is likely for address-sharing functions that embed the IDENT server 🥲 it gets even worse if the address-sharing function has to handle an IDENT query for every newly instantiated mapping, even when the mapping already exists 😩
  • in some scenarios (like Section 3 of [REVEAL-PCP]), the HOST_ID should be read by intermediate devices that embed Policy Enforcement Points (PEP) [RFC2753] responsible for granting access to some services 🚪 those PEPs need to inspect every received packet so they can generate the companion IDENT queries, which can make these intermediate devices more complicated 🧩
  • IDENT queries might be generated by illegitimate TCP servers 👀 that means the address-sharing function would need to enforce some policies, like rate-limiting queries or filtering based on the source IP address, etc. 🛡️

5. Solutions Analysis: Synthesis 🎀

Table 1 is the highlight reel 🎬 it sums up all the approaches we analyzed in this document.

          +-----+------+------+------+-----+-----+-----+-----+-----+
          |IP-ID| IP   | TCP  |HTTP  |PROXY|Port | HIP |ICMP |IDENT|
          |     |Option|Option|Header|     | Set |     |     |     |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
UDP       | Yes | Yes  | No   | No   | No  | Yes |     | Yes | No  |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
TCP       | Yes | Yes  | Yes  | No   | Yes | Yes |     | Yes | Yes |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
HTTP      | Yes | Yes  | Yes  | Yes  | Yes | Yes |     | Yes | Yes |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Encrypted | Yes | Yes  | Yes  | No   | Yes | Yes |     | Yes | Yes |
Traffic   |     |      |      |      |     |     |     |     |     |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Success   | High| Low  | High | High | Low | 100%|Low  |High |High |
Ratio     |     |      |      |      |     |     |     |     |     |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Possible  | Low | High | Low  |  Med | High| No  | N/A | High|High |
Perf      |  to |      |  to  |   to |     |     |     |     |     |
Impact    | Med |      | Med  | High |     |     |     |     |     |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
OS TCP/IP | Yes | Yes  | Yes  | No   | No  | No  |     | Yes | Yes |
Modif     |     |      |      |      |     |     |     |     |     |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Deployable| Yes | Yes  | Yes  | Yes  | No  | Yes | No  | Yes | Yes |
Today     |     |      |      |      |     |     |     |     |     |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Notes     | (1) |  (8) | (8)  |  (2) | (8) | (1) | (4) | (6) | (1) |
          | (7) |      |      |      |     | (3) | (7) | (8) | (6) |
          |     |      |      |      |     |     |     |     | (8) |
----------+-----+------+------+------+-----+-----+-----+-----+-----+

              Table 1: Summary of Analyzed Solutions
  • "Encrypted Traffic" means TLS 🔐 for the IPsec side and its NAT drama, check out Section 2.2 of [RFC6889]. Similar to Section 13.5 of [RFC6269], the HOST_ID spec document(s) should analyze the compatibility of each IPsec mode in detail 🧐
  • "Success ratio" shows how often communications with remote servers actually work when the HOST_ID is injected using a proposed solution 🎯 more details below on how it's computed for each solution
  • "Possible Perf Impact" is the expected level of performance degradation 📉 it's an estimate based on how much processing is needed at the IP layer
  • "OS TCP/IP Modif" tells you whether the server side needs its OS TCP/IP stack modified 🖥️
  • "Deployable today" tells you if the solution can be generalized without any constraints on current architectures and practices 🚀

Notes:

  • (1) needs a mechanism to advertise that the NAT is participating in this scheme (e.g., a DNS PTR record) 📡
  • (2) this solution is widely deployed (e.g., HTTP servers, load balancers, etc.) 💪
  • (3) when the port set isn't advertised, the solution is less efficient for third-party services 🫠
  • (4) requires that the client and the server be HIP-compliant and that HIP infrastructure be deployed 🔑 if both are HIP-enabled, the address-sharing function doesn't need to insert an identifier ✨ but if the client isn't HIP-enabled, designing the device that performs address sharing to act as a UDP/TCP-HIP relay is not viable 🙅‍♀️
  • (6) the solution is inefficient in some scenarios (see Section 5) 🐢
  • (7) the solution is a theoretical construct, i.e., it isn't documented 🧪
  • (8) the solution is a documented proposal 📄

The provided success ratio figures for TCP and IP options are based on the results documented in [Options] and [REVEAL-TCP-EXP] 📊

The provided success ratio for the IP-ID is theoretical 🤓 it assumes the address-sharing function follows the rules (see [RFC6864]) to rewrite the IP Identification field.

Since PROXY and HIP aren't widely deployed, the success ratio for establishing communication with remote servers using these protocols is low 😬

The success ratio for the ICMP-based solution is implementation specific, but it's likely to be close to 100% 💯 it depends on how efficiently the solution is implemented on the server side. A remote server that doesn't support the ICMP-based solution will ignore received companion ICMP messages 🙈 an upgraded server will need to delay accepting a session until it receives the companion ICMP message.

The success ratio for the IDENT solution is implementation specific but likely close to 100% 🫶 it depends on how efficient the solution is on the server side. A remote server that doesn't support IDENT will accept a session establishment request following its normal operation 🧸 an upgraded server will need to delay accepting a session until it receives a response to the IDENT request it sends to the host.

The provided success ratio for the Port Set and HTTP header solutions is 100% 🏆 because no additional Layer 3 or Layer 4 field is needed to convey HOST_ID for these solutions.

6. Security Considerations 🔐

Okay, this part is serious, bestie 😭 If the server trusts the content of the HOST_ID field, a third-party user can be impacted by a misbehaving user revealing a "faked" HOST_ID (e.g., original IP address) 🚨 this same security concern applies to the injection of an IP option, a TCP option, and application-related content (e.g., the Forwarded HTTP header) by the address-sharing device.

The HOST_ID may be used to leak information about the internal structure of a network behind an address-sharing function 👀 if the network administrator doesn't want that, the address-sharing function can be configured to strip any existing HOST_ID in packets received from internal hosts 🧹

HOST_ID specification documents should elaborate further on the threats inherent to each individual solution used to convey the HOST_ID (e.g., use of the IP-ID field to count hosts behind a NAT [Count]) 🕵️‍♀️

For more discussion of privacy issues related to the HOST_ID, see Section 3 🫣

7. Acknowledgments 💜

Many thanks to D. Wing, C. Jacquenet, J. Halpern, B. Haberman, and P. Yee for their review, comments, and inputs 🙏

Thanks also to P McCann, T. Tsou, Z. Dong, B. Briscoe, T. Taylor, M. Blanchet, D. Wing, and A. Yourtchenko for the discussions in Prague 🇨🇿✨

Some of the issues related to defining a new TCP option were raised by L. Eggert 🧚

The privacy text was provided by A. Cooper 🌸

8. References 📚

8.1. Normative References

  • [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 🌐
  • [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. 🔀
  • [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011. 🎲

8.2. Informative References ✨

okay bestie, these are the extra reads that back up the whole doc 📚💖 they're not required to get the gist, but they're where the receipts live 🧾

  • [Count] Belloven, S., "A Technique for Counting NATted Hosts", <http://www.cs.columbia.edu/~smb/papers/fnat.pdf>.
  • [DETERMCGN] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", Work in Progress, January 2013.
  • [ExtendTCP] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M. and H. Tokuda,, "Is It Still Possible to Extend TCP?", November 2011, <http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf>.
  • [FASTOPEN] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", Work in Progress, February 2013.
  • [HTTP-FRWD] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", Work in Progress, October 2012.
  • [IAB-PRIVACY] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", Work in Progress, July 2012.
  • [IPFIX-NAT] Sivakumar, S. and R. Penno, "IPFIX Information Elements for Logging NAT Events", Work in Progress, March 2013.
  • [Not_An_Option] R. Fonseca, G. Porter, R. Katz, S. Shenker, and I. Stoica,, "IP Options Are Not An Option", 2005, <http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.html>.
  • [Options] Medina, A, Allman, M. and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", 2005, <http://conferences.sigcomm.org/imc/2004/papers/p336-medina.pdf>.
  • [Proxy] Tarreau, W., "The PROXY protocol", November 2010, <http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt>.
  • [REVEAL-ICMP] Yourtchenko, A., "Revealing Hosts Sharing An IP Address Using ICMP Echo Request", Work in Progress, March 2012.
  • [REVEAL-IP] Wu, Y., Ji, H., Chen, Q., and T. ZOU), "IPv4 Header Option For User Identification In CGN Scenario", Work in Progress, March 2011.
  • [REVEAL-PCP] Boucadair, M., Reddy, T., Patil, P., and D. Wing, "Using PCP to Reveal a Host behind NAT", Work in Progress, November 2012.
  • [REVEAL-TCP-EXP] Abdo, E., Boucadair, M., and J. Queiroz, "HOST_ID TCP Options: Implementation & Preliminary Test Results", Work in Progress, July 2012.
  • [REVEAL-TCP] Yourtchenko, A. and D. Wing, "Revealing Hosts Sharing An IP Address Using TCP Option", Work in Progress, December 2011.
  • [RFC1413] St. Johns, M., "Identification Protocol", RFC 1413, February 1993.
  • [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
  • [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
  • [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
  • [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
  • [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011.
  • [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, August 2011.
  • [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", RFC 6462, January 2012.
  • [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, February 2013.
  • [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, "Analysis of Stateful 64 Translation", RFC 6889, April 2013.
  • [SYSLOG-NAT] Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog Format for NAT Logging", Work in Progress, May 2013.
  • [TOR] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The secondgeneration onion router", In Proceedings of the 13th USENIX Security Symposium, August 2004.
  • [Trusted_ISPs] Wikimedia, "Trusted XFF List", May 2013, <http://meta.wikimedia.org/w/index.php?title=XFF_project&oldid=5507690>.

Authors' Addresses 🫶

Meet the squad behind this doc! 💜 Here's where you can reach each of them 💌

Mohamed Boucadair
France Telecom
Rennes  35000
France

EMail: mohamed.boucadair@orange.com
Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, CA  90292-6695
United States

Phone: +1 (310) 448-9151
EMail: touch@isi.edu
Pierre Levis
France Telecom
Caen  14000
France

EMail: pierre.levis@orange.com
Reinaldo Penno
Cisco
United States

EMail: repenno@cisco.com
📦 where this page comes from