RFC 7974
An Experimental TCP Option for Host Identification
RFC 7974: An Experimental TCP Option for Host Identification 🎀
Okay bestie, the paperwork first 📋. This is an Independent Submission, so it's Informational (not Standards Track) and it was published in October 2016 under ISSN 2070-1721. The authors are B. Williams (Akamai, Inc.), M. Boucadair (Orange), and D. Wing. The header doesn't list any RFCs it obsoletes or updates, so it doesn't change anything else in the series 💅
Abstract ✨
Recent RFCs have been spilling tea about host identification in IP address-sharing setups, like address/prefix-sharing devices and application-layer proxies. People have also been brainstorming ways to reveal a host identifier when addresses are shared, and this memo is about one of those ideas that's already running on the Internet today 🌐. It walks through the design, the deployment, and the privacy considerations of a solution that sends a host identifier inside a TCP option 🦋
Independent Submissions Editor Note 🧚
This Informational document specifies an experimental TCP HOST_ID option that's already pretty widely deployed. It goes deep on that option's privacy considerations and really stresses how careful providers need to be in any real deployment 🔍. The Independent Submissions Editor decided to publish it in the Independent Stream so that folks who want to deploy or implement it can see every detail, and so that new implementations can interwork properly with the existing deployments 🫶
IESG Note 🚨
Okay, this part is a little dramatic 😭. This proposal was previously put forward for adoption by the TCPM working group, and it got rejected as an undesirable technical design, for both transport and privacy reasons 💀. This document specifies a new TCP option that uses the shared experimental options format 🧩.
The use of experimental TCP options is specified in [RFC6994] for TCP options "that are not yet eligible for assigned codepoints" 🔢. Since the IETF community rejected this proposal, it isn't eligible to register a TCP option codepoint. It's also worth noting that for experimental TCP options, "is only appropriate to use these values in explicitly-configured experiments; they MUST NOT be shipped as defaults in implementations" [RFC4727] ⚠️.
The IESG also did a review as described in [RFC5742] and concluded that this proposal violates IETF principles about pervasive monitoring as an attack, which are expressed in [RFC7258]. So it should therefore not be published without IETF review and IESG approval 🙈. (The process in [RFC5742] still lets the Independent Submissions Editor publish it anyway, and that's what happened here 🤷♀️.) Deployments of this proprietary TCP option may be widely seen as undermining privacy, and they're likely to run into reliability issues with transport 🥀.
Status of This Memo 📜
This document isn't an Internet Standards Track specification. It's published just for informational purposes 🎀.
This is a contribution to the RFC Series, and it's independent of any other RFC stream. The RFC Editor chose to publish it at their discretion, and they don't say anything about whether it's valuable for implementation or deployment. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard. See Section 2 of RFC 7841 for that 💅.
For info on the current status of this document, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7974 🔗.
Copyright Notice ©️
Copyright (c) 2016 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), as in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📖.
Table of Contents 🗂️
1. Introduction ....................................................4
1.1. Important Use Cases ........................................4
1.2. Document Goals .............................................6
2. Terminology .....................................................6
3. Option Format ...................................................7
4. Option Use ......................................................7
4.1. Option Values ..............................................7
4.2. Sending Host Requirements ..................................9
4.2.1. Alternative SYN Cookie Support ......................9
4.2.2. Persistent TCP Connections ..........................9
4.2.3. Packet Fragmentation ...............................10
4.3. Multiple In-Path HOST_ID Senders ..........................10
5. Option Interpretation ..........................................11
6. Interaction with Other TCP Options .............................12
6.1. Multipath TCP (MPTCP) .....................................12
6.2. Authentication Option (TCP-AO) ............................12
6.3. TCP Fast Open (TFO) .......................................13
7. Security Considerations ........................................13
8. Privacy Considerations .........................................14
9. Pervasive Monitoring (PM) Considerations .......................15
10. IANA Considerations ...........................................16
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................17
Acknowledgements ..................................................20
Authors' Addresses ................................................201. Introduction 🌷
A whole bunch of address-sharing problems have been documented in [RFC6269] and [RFC7620] 😩. On top of that, [RFC6967] looks at different ways to reveal the sending host's identifier (HOST_ID) to the receiver. It finds that using a TCP [RFC793] option for this is one of the possible approaches that could work with limited performance impact and a high success ratio ✨. So this memo's job is to describe a TCP HOST_ID option that's currently deployed on the public Internet, using the TCP experimental option codepoint, along with the related design, deployment, and privacy considerations 🦋.
Multiple documents have defined TCP options for host identification: [REVEAL], [HOSTID], and [OVERLAYPATH]. Having several option formats for the same job is a headache for implementers and causes interoperability drama too 🙄. So the authors of those documents teamed up to define one common TCP option that replaces the formats from all three. This memo describes the version of that common option that's in use on the public Internet right now 🫶.
The option in this memo uses the TCP experimental option codepoint sharing mechanism from [RFC6994]. One of the earlier specs, [OVERLAYPATH], was tied to unauthorized use of a TCP option kind number. Moving to the TCP experimental option codepoint let the authors of that document fix their mistake 🔧.
1.1. Important Use Cases 💖
The authors' implementations mainly focus on the address-sharing use cases below, where deployed systems insert the HOST_ID option 🎯:
- Carrier-Grade NAT (CGN): As defined in [RFC6888], [RFC6333], and other sources, a CGN lets multiple hosts connected to the public Internet share a single Internet-routable IPv4 address. A big thing about the CGN use case is that it changes IP packets in-path, but it isn't the endpoint for the associated TCP connections 🛣️.
- Application Proxy: As defined in [RFC1919], an application proxy splits a TCP connection into two segments. It acts as the endpoint for each connection and relays data flows between them 🔀.
- Overlay Network: An overlay network is an Internet-based system that provides security, optimization, or other services for data flows passing through it 🌐. A network-layer overlay will sometimes act a lot like a CGN, since packets transit the system and NAT gets applied at the overlay's edge. A transport-layer or application-layer overlay [RFC3135] will typically act like an application proxy, since the TCP connection gets segmented with the overlay network as the endpoint for each TCP connection 🧚.
In these sender use cases, the TCP option gets applied to an individual TCP packet either at the connection endpoint (for example, an application proxy or a transport-layer overlay network) or at an address-sharing middlebox (for example, a CGN or a network-layer overlay network) 📦. See Section 4 for more on the types of devices that add the option to a TCP packet, plus the existing limitations on using the option when an address-sharing middlebox inserts it, including issues related to packet fragmentation ✂️.
The existing receiver use cases this memo considers are:
- Telling apart attack traffic from non-attack traffic when the attack's source is sharing an address with non-attack traffic 🚫.
- Applying per-subscriber policies for resource utilization, and so on, when multiple subscribers share a common address 📊.
- Improving server-side load-balancing decisions by letting the load from multiple clients behind a shared address get assigned to different servers, even when session affinity is needed at the application layer ⚖️.
In every one of these cases, telling address-sharing clients apart is done by a network function that doesn't process the application-layer protocol (like HTTP) or the security protocol (like TLS). That's because the action has to happen before decryption or parsing of the application layer 🔐. Because of that, a solution built inside the application layer or the security protocol was considered unable to fully meet the receiver-side requirements 🙅♀️. At the same time, as noted in [RFC6967], using an IP option for this purpose has a low success rate 📉. For these reasons, the authors decided that using a TCP option to deliver the host identifier is an effective way to meet these specific use cases 🏆. See Section 5 for details about receiver-side interpretation of the option 👀.
1.2. Document Goals
okay so this doc has a few jobs ✨ First and foremost, it's here to tell you about a mechanism that's already in broad use on the public Internet 🌐 The authors each work for companies that have implemented, tested, and/or deployed systems using the HOST_ID option out there 💅 Other systems might run into packets carrying this TCP option, so this doc helps everyone understand what it is when they spot it, which means they can make informed decisions about how to handle it 🫶
The testing effort in [HOSTID] showed that a TCP option could be used for host identification without significant disruption of TCP connectivity to legacy servers and networks that don't support the option 🦋 It also showed how mechanisms in existing TCP implementations could use that option for diagnostics and/or packet filtering 🔍 The authors' own use of the option on the public Internet has confirmed it works effectively for their use cases, but it also uncovered some interoperability issues 😭 Those issues show up especially when the option interacts with other TCP options that support new transport capability being specified within the IETF. Section 6 covers those interactions and limitations and explains how their systems handle the associated issues 💖
Privacy is the other big thread here 👀 IETF discussions have raised privacy concerns about the option, especially around pervasive monitoring risks. Existing uses limit the nature of the HOST_ID values and the systems that insert them to help mitigate those risks 🛡️ Sections 8 and 9 discuss the authors' assessments of the privacy and monitoring impact of this TCP option in its current uses, and they suggest behavior for some external systems when the option shows up 🎀 Continued discussion after publication is expected to refine the requirements around the values used to populate the option and how the receiver can interpret them 🌸 There's a trade-off between giving the receiver the functionality it expects and protecting the sender's privacy, so ongoing assessment will be needed to find the right balance ⚖️
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These are the capitalised key words that carry the requirement weight, so they're worth a quick look 💜
3. Option Format
When it's used for host identification, the TCP experimental option uses the experiment identification mechanism described in [RFC6994] 🧚 It has the following format and content:
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ExID |
+--------+--------+--------+--------+
| HOST_ID ...
+--------+---Here's the breakdown:
- Kind: The option kind value is
253. 🍓 - Length: The length is variable and depends on how big the host identifier needs to be. For example, a 2-octet
HOST_IDwill require a length of6, while a 4-octetHOST_IDwill require a length of8📏 - ExID: The experiment ID value is
0x0348(840). 🔢 - HOST_ID: This is a value that can be used to tell apart the various hosts sharing a common public IP address. There's more on this value below 👯
4. Option Use
This section lays out the requirements for using the option, including the expected option values, which hosts are allowed to include the option, and the segments that carry it 📋
4.1. Option Values
The info in the HOST_ID option is meant to uniquely identify the sending host as well as the adding machine can manage, while avoiding anything that doesn't help with that goal 🎯 The option is also not meant to expose info about the sending host that couldn't be figured out by just watching segments in transit on some part of the Internet path between sender and receiver 👀 Existing use cases have different needs on the receiving side, so this doc tries to give the machine adding the option a lot of flexibility 💅
The HOST_ID option value MUST correlate to IP addresses and/or TCP port numbers that were changed by the inserting host/device (i.e., some of the IP address and/or port number bits are used to generate the HOST_ID). Some example values that satisfy this requirement are:
- Unique ID: An inserting host/device could keep a pool of locally unique ID values, mapped dynamically to the unique source IP address values in use behind the host/device because of address sharing. The ID only means something within the context of one specific shared IP address, because it's only locally unique. An ID like this could be smaller than an IP address (e.g., 16 bits) to save TCP option space 🌱 This option is preferred because it doesn't increase IP address visibility on the forward side of the address-sharing system. It SHOULD be used in cases where receiver-side requirements can be met without directly including the original IP address (e.g., some load-balancing uses) ⭐
- IP Address/Subnet: An inserting host/device could just fill the option value with the IP address in use behind the host/device. With IPv6 addresses, fitting the full address into TCP option space can be tricky, so the value would probably need to carry only part of the address (e.g., the first 64 bits) 🧩
- IP Address and TCP Port: Some networks share public IP addresses among multiple subscribers, with a portion of the TCP port number space assigned to each subscriber [RFC6346] 🏠 When a system like that sits behind an address-sharing host/device, including both the IP address and the TCP port number identifies the sending host more uniquely than the IP address alone 🎀
When multiple host identifiers are needed (e.g., an IP address and a port number), the HOST_ID option is included multiple times within the packet, once for each identifier. Yes, this uses up option space quickly 😩 But cases with only a single identifier are expected to be more common, so it's worth optimising for those 💖 Heads up: some middleboxes might reorder TCP options, so this method could be problematic if such a middlebox sits in-path between the address-sharing system and the receiver. This hasn't proven to be a problem for existing use cases 🤞
See Section 8 for the privacy considerations related to selecting HOST_ID values 🔐
4.2. Sending Host Requirements
The HOST_ID option MUST only be added by the sending host, or by any device in the forwarding path that changes IP addresses and/or TCP port numbers (e.g., NAT44 [RFC3022], L2-Aware NAT, DS-Lite Address Family Transition Router (AFTR) [RFC6333], IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296], NAT64 [RFC6146], Dual-Stack Extra Lite [RFC6619], TCP Proxy, etc.). The HOST_ID option MUST NOT be added or modified en route by any device that does not modify IP addresses and/or TCP port numbers 🚦
The sending host or intermediary device can't tell whether the option value is used in a stateful manner by the receiver, and it can't tell whether SYN cookies are in use by the receiver either 🍪 Because of that, the option MUST be included in all segments, both SYN and non-SYN segments, until return segments from the receiver positively indicate that the TCP connection is fully established on the receiver (e.g., the return segment either includes or acknowledges data) 🫶
4.2.1. Alternative SYN Cookie Support
The authors also considered a different approach to SYN cookie support 🤔 In this approach, the receiving host (the host that accepts the TCP connection) echoes the option back to the sender in the SYN/ACK segment whenever a SYN cookie is being sent. That would let the host sending HOST_ID figure out whether it needs to keep including the option. The upside is that the option wouldn't need to be included in non-SYN segments if SYN cookies hadn't been used. Unfortunately, this approach falls apart if the responding host doesn't support the option itself, since an intermediate node would have no way to know that SYN cookies had been used 😭
4.2.2. Persistent TCP Connections
Some types of middleboxes (e.g., application proxies) open and maintain persistent TCP connections to regularly visited destinations, which saves them the hassle of connection establishment every time 🔁 Those middleboxes might use one persistent TCP connection for multiple different client hosts over the life of that connection 👥
This specification doesn't try to support persistent TCP connections for multiple client hosts, because the complexity of providing that support was seen as too much 🙅♀️ Instead, the HOST_ID option is only allowed to be used at connection initiation. An inserting host/device that supports both the HOST_ID option and multi-client persistent TCP connections MUST NOT apply the HOST_ID option to TCP connections that could be used for multiple clients over the life of the connection 🚫 And if the HOST_ID option was sent during connection initiation, the inserting host/device MUST NOT reuse the connection for data flows originating from a client that would require a different HOST_ID value 🙈
4.2.3. Packet Fragmentation
To avoid the overhead that comes with in-path IP fragmentation, it's desirable for the inserting host/device to avoid including the HOST_ID option when IP fragmentation might be required 🧵 This isn't a firm requirement, though, because the HOST_ID option is only included in the first few packets of a TCP connection, so the associated IP fragmentation generally has minimal impact 🌸 The option SHOULD NOT be included in packets if the resulting packet would require local fragmentation.
It can be hard to tell whether local fragmentation would be required 🤷♀️ For example, when multiple interfaces with different MTUs are in use, a local routing decision has to be made before the MTU can be determined, and in some systems that decision might not happen until after TCP option handling is complete. On top of that, the option might push a packet over the path's MTU even though the sending host/device hasn't learned that path MTU yet 😵💫
In existing deployed systems, the impact of IP fragmentation resulting from use of the option has been minimal 🎉
4.3. Multiple In-Path HOST_ID Senders 🌸
okay so what if there are multiple in-path hosts or devices that are all set up to insert the HOST_ID option? 🫣 Like, the client's TCP packets might first go through a CGN device before they reach the edge of a public Internet overlay network. For the HOST_ID value to identify the sender as uniquely as possible, it has to represent both the identity the CGN device sees (the subscriber's internal IP address, e.g., Shared Address Space [RFC6598]) and the identity the overlay network sees (the shared address of the CGN device). How the receiving side handles the HOST_ID value can change depending on what the new HOST_ID value is, as described below. 💅
The problem of multiple in-path HOST_ID senders hasn't been observed in existing deployed systems. 🤷 For that reason, existing implementations don't consistently support this scenario. Some systems don't pass along the received HOST_ID option value in any way, while others follow the guidance below.
If an inserting host/device uses the received packet's source IP address as its HOST_ID value (maybe along with the port), it MUST propagate forward the HOST_ID value(s) from the received packet. 🎀 The reason is that the source IP address and port only represent the previous in-path address-sharing device, not the original sender. In the CGN-plus-overlay example, this means the overlay will include both the CGN's HOST_ID value(s) and a HOST_ID with the source IP address the overlay received. 🦋
An inserting host/device that sends a unique ID (as described in Section 4.1) has two options for how to handle the HOST_ID value(s) from the received packet:
- A host/device that sends a unique ID MAY strip the received HOST_ID option and insert its own option, provided that it uses the received HOST_ID value as a differentiator for selecting the unique ID. What this means in the CGN-plus-overlay example above is that the overlay is allowed to drop the HOST_ID value inserted by the CGN, provided that the HOST_ID value selected by the overlay represents both the CGN itself and the HOST_ID value inserted by the CGN. ✨
- A host/device that sends a unique ID MAY instead select a unique ID that represents only the previous in-path address-sharing host/device and propagate forward the HOST_ID value inserted by the previous host/device. In the CGN-plus-overlay example, this means the overlay would include both the CGN's HOST_ID value and a HOST_ID with a unique ID of its own, selected to represent the CGN's shared address. 🌈
An inserting host/device that sends a unique ID MUST use one of the above two mechanisms. 🙌
5. Option Interpretation 🔍
Because the option value can vary so much, the receiving machine can't reliably work out the value type just from the option itself. So a receiving host/device SHOULD interpret the option value as an opaque identifier. 🧠
This specification lets the inserting host/device provide multiple HOST_ID options. Some middleboxes might change the order of TCP options, so receivers SHOULD NOT rely on option order to give the individual options any extra meaning. Instead, when multiple HOST_ID options are present, their values SHOULD be concatenated together in the order they appear in the packet and treated as a single large identifier. 🧩
For both of the receiver requirements we just talked about, this specification uses SHOULD rather than MUST, because reliable interpretation and ordering of options could be possible if the inserting host and the interpreting host are under common administrative control and integrity-protect communication between them. Mechanisms for signaling the value type(s) and integrity protection aren't provided by this specification. Without them, the receiving host/device MUST interpret the option value(s) as a single opaque identifier. 😤
6. Interaction with Other TCP Options 🦋
This section details how the HOST_ID option works alongside other TCP options. 💖
6.1. Multipath TCP (MPTCP) 🌈
TCP gives you a maximum of 40 octets for TCP options. As discussed in Appendix A of MPTCP [RFC6824], a typical SYN from modern, popular operating systems has several TCP options (MSS (Maximum Segment Size), window scale, SACK (selective acknowledgment) permitted, and timestamp), which eat up 19-24 octets depending on word alignment of the options. The initial SYN from a multipath TCP client would take an extra 16 octets. 😩
HOST_ID needs at least 6 octets to be useful, so 9-21 octets are enough for many scenarios that benefit from HOST_ID. However, 4 octets aren't enough space for the HOST_ID option. So a TCP SYN with all the typical TCP options (MSS, window scale, SACK permitted, and timestamp), plus multipath capable or multipath join, and also word-aligned, doesn't have room for HOST_ID. Something has to give. The choices are either to avoid word alignment in that case (freeing 5 octets) or to avoid adding the HOST_ID option. Both approaches are used in existing implementations and have been deemed acceptable for the associated use case. 🤝
6.2. Authentication Option (TCP-AO) 💜
The TCP Authentication Option (TCP-AO) [RFC5925] is incompatible with address sharing, because it provides integrity protection of the source IP address. So the only use cases where it makes sense to combine TCP-AO and HOST_ID are those where the TCP-AO-NAT extension [RFC6978] is in use. Injecting a HOST_ID TCP option doesn't interfere with TCP-AO-NAT, because the TCP options aren't included in the Message Authentication Code (MAC) calculation. 🔐
6.3. TCP Fast Open (TFO) 🍓
The TFO option [RFC7413] uses a zero-length cookie (total option length is 2 bytes) to request a TFO cookie for use on future connections. The server-generated TFO cookie is required to be at least 4 bytes long and allowed to be as long as 16 bytes (total option length is 6 to 18 bytes). The cookie request form of the option leaves enough room available in a SYN packet with the most commonly used options to accommodate the HOST_ID option. But a valid TFO cookie longer than 13 bytes would prevent even the minimal 6-byte HOST_ID option from being included in the header. 😬
There are multiple possibilities for allowing TFO and HOST_ID to be supported for the same connection, including:
- If the TFO implementation allows the cookie size to be configurable, the configured cookie size can be specifically selected to leave enough option space available in a typical TFO SYN packet to allow inclusion of the HOST_ID option. 🧁
- If the TFO implementation provides explicit support for the HOST_ID option, it can be designed to use a shorter cookie length when the HOST_ID option is present in the TFO cookie request SYN. 🧁
Reducing the TFO cookie size in order to include the HOST_ID option could have unacceptable security implications. So existing deployed systems that use the HOST_ID option consider TFO and HOST_ID to be mutually exclusive, and do not support the use of both options on the same TCP connection. 🙅♀️
Worth noting too: the presence of data in a TFO SYN increases the likelihood that there will be no space available in the SYN packet to support inclusion of the HOST_ID option without IP fragmentation, even if there is enough room in the TCP option space. This is an additional reason that existing systems consider TFO and HOST_ID to be mutually exclusive. 💀
7. Security Considerations 🔥
Security (including privacy) considerations common to all HOST_ID solutions are discussed in [RFC6967]. 🛡️
Okay bestie, this section is SERIOUS. 🚨 Read the trust paragraphs twice.
The content of the HOST_ID option SHOULD NOT be used for purposes that require a trust relationship between the sender and the receiver (e.g., billing and/or subscriber policy enforcement). This requirement uses SHOULD rather than MUST, because reliable interpretation of options could be possible if the inserting host and the interpreting host are under common administrative control and integrity-protect communication between them. Mechanisms for signaling the value type(s) and integrity protection are not provided by this specification. In their absence, the receiving host/device MUST NOT use the HOST_ID value for purposes that require a trust relationship. 🫣
Note that the above trust requirement applies equally to HOST_ID option values propagated forward from a previous in-path host, as described in Section 4.3. In other words, if the trust mechanism does not apply to all option values in the packet, then none of the HOST_ID values can be considered trusted. The receiving host/device MUST NOT use any of the HOST_ID values for purposes that require a trust relationship. An inserting host/device that has such a trust relationship MUST NOT propagate forward an untrusted HOST_ID in such a way as to allow it to be considered trusted. 🚫
When the receiving network uses the values provided by the option in a way that does not require trust (e.g., maintaining session affinity in a load-balancing system), then use of a mechanism to enforce the trust relationship is OPTIONAL. 🌸
8. Privacy Considerations 🔒✨
okay so bestie, sending a TCP SYN over the public Internet necessarily discloses the sending host's public IP address 👀. When an intermediate address-sharing device is deployed on the public Internet, anonymity goes UP, because hosts that show up with lots of different source IP addresses on the ingress side all look like a single source IP address on the egress side 🦋. The HOST_ID TCP option takes that extra anonymity away 😭. It takes information that was already visible in TCP packets on the ingress side and makes it visible on the egress side too. And in some cases the whole point of the address-sharing device is anonymity 🙈, so using the HOST_ID TCP option would be totally incompatible with the purpose of the device. Not it 💀.
A NAT device used to connect a LAN with private [RFC1918] IP addresses to the public Internet is sometimes built specifically to give LAN clients that same anonymity we just talked about 🌸. So address-sharing devices at the border between a private LAN and the public Internet MUST NOT insert the HOST_ID option. No exceptions, periodt 💅.
The HOST_ID option MUST NOT be used to provide client geographic or network location information that was not publicly visible in IP packets for the TCP flows processed by the inserting host. For example, the client's IP address MAY be used as the HOST_ID option value, but any geographic or network location information derived from the client's IP address MUST NOT be used as the HOST_ID value 🗺️🚫.
The HOST_ID option MAY provide differentiating information that is locally unique, so individual TCP flows processed by the inserting host can be reliably identified 🧚. The HOST_ID option MUST NOT provide client identification information that was not publicly visible in IP packets for the TCP flows processed by the inserting host, like subscriber information linked to the IP address 🙅♀️.
The HOST_ID value MUST be changed whenever the subscriber IP address changes. This is so the HOST_ID option does not turn into a new globally unique identifier that sticks around across subscriber IP address changes 🫶.
The HOST_ID option MUST be stripped from IP packets traversing middleboxes that provide network-based anonymity services 🧼.
9. Pervasive Monitoring (PM) Considerations 👀🌈
Okay this section is a big deal, so listen up 📣. [RFC7258] says: "Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions." Legit concerns about host identification have been raised within the IETF 😤. The authors tried to address those concerns by spelling out the nature of the HOST_ID values and the kinds of middleboxes that should and should not include the HOST_ID option in TCP headers. That guidance also describes limitations that existing deployed systems already impose 💜. This section just highlights the most important bits of the design and the related guidance and limitations that matter for the pervasive monitoring discussion ✨.
When a generated identifier is used, this document prohibits the address-sharing device from using globally unique or permanent identifiers. Only locally unique identifiers are allowed 🙅♀️. Just like persistent IP addresses, persistent HOST_ID values could make user tracking easier, so they are prohibited too 🕵️♀️. The specific requirements for permissible HOST_ID values are discussed in Sections 8 and 4.1 📚.
This specification does not aim to expose a host beyond what the original packet, sent from that host, would have already exposed on the public Internet without the option. The option is only meant to carry forward information that was handed to the address-sharing device in the original packet 🎀. HOST_ID option values that don't match this description are prohibited by requirements discussed in Section 8. The design also does not let the HOST_ID option carry personally identifiable information, geographic location identifiers, or anything else that isn't available in the wire format of the associated TCP/IP headers 🚫💖.
This document's guidance on option values is followed in the existing deployed system, so the volatility of the information in a HOST_ID option is similar to that of the public, subscriber IP address 🦋. A distinct HOST_ID gets used by the address-sharing function when the host reboots or gets a new public IP address from the subscriber network 🔄.
The described TCP option lets you identify the network to a similar level as the first 64 bits of an IPv6 address 🌐. So the server can use the bits of the TCP option to help identify a host behind an address-sharing device, in much the same way it would use the host's IPv6 network address if client and server were using IPv6 end to end 💅.
Some address-sharing middleboxes on the public Internet have the express intention of providing originator anonymity 🥷. Publishing this document can help those middleboxes recognize the risk and take action to mitigate it, for example by stripping or modifying the option value 🛡️✨.
10. IANA Considerations 📋💕
This document specifies a new TCP option (HOST_ID) that uses the shared experimental options format [RFC6994], with ExID in network-standard byte order. IANA has registered HOST_ID (0x0348) in the "TCP Experimental Option Experiment Identifiers (TCP ExIDs)" registry 🎉🍓.
11. References 📚🫧
11.1. Normative References 💜
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727,
DOI 10.17487/RFC4727, November 2006,
<http://www.rfc-editor.org/info/rfc4727>.
[RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for
Handling of Independent and IRTF Stream Submissions",
BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009,
<http://www.rfc-editor.org/info/rfc5742>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options",
RFC 6994, DOI 10.17487/RFC6994, August 2013,
<http://www.rfc-editor.org/info/rfc6994>.11.2. Informative References
okay bestie, this is the extra credit reading list 📚✨ these aren't required to implement the thing, but they're where all the good backstory lives. so iconic. 💅
[HOSTID] Abdo, E., Boucadair, M., and J. Queiroz, "HOST_ID TCP
Options: Implementation & Preliminary Test Results", Work
in Progress, draft-abdo-hostid-tcpopt-implementation-03,
July 2012.
[OVERLAYPATH]
Williams, B., "Overlay Path Option for IP and TCP", Work
in Progress, draft-williams-overlaypath-ip-tcp-rfc-04,
June 2013.
[REVEAL] Yourtchenko, A. and D. Wing, "Revealing hosts sharing an
IP address using TCP option", Work in Progress,
draft-wing-nat-reveal-option-03, December 2011.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies",
RFC 1919, DOI 10.17487/RFC1919, March 1996,
<http://www.rfc-editor.org/info/rfc1919>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001,
<http://www.rfc-editor.org/info/rfc3022>.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135,
DOI 10.17487/RFC3135, June 2001,
<http://www.rfc-editor.org/info/rfc3135>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011,
<http://www.rfc-editor.org/info/rfc6269>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<http://www.rfc-editor.org/info/rfc6296>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<http://www.rfc-editor.org/info/rfc6333>.
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to
the IPv4 Address Shortage", RFC 6346,
DOI 10.17487/RFC6346, August 2011,
<http://www.rfc-editor.org/info/rfc6346>.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
2012, <http://www.rfc-editor.org/info/rfc6598>.
[RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable
Operation of Address Translators with Per-Interface
Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012,
<http://www.rfc-editor.org/info/rfc6619>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common Requirements for Carrier-Grade
NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <http://www.rfc-editor.org/info/rfc6888>.
[RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Potential Solutions for Revealing a Host
Identifier (HOST_ID) in Shared Address Deployments",
RFC 6967, DOI 10.17487/RFC6967, June 2013,
<http://www.rfc-editor.org/info/rfc6967>.
[RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT
Traversal", RFC 6978, DOI 10.17487/RFC6978, July 2013,
<http://www.rfc-editor.org/info/rfc6978>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>.
[RFC7620] Boucadair, M., Ed., Chatras, B., Reddy, T., Williams, B.,
and B. Sarikaya, "Scenarios with Host Identification
Complications", RFC 7620, DOI 10.17487/RFC7620, August
2015, <http://www.rfc-editor.org/info/rfc7620>.Acknowledgements 🫶
huge thank yous to W. Eddy, Y. Nishida, T. Reddy, M. Scharf, J. Touch, A. Zimmermann, and A. Falk for their comments. the people who read drafts and give feedback are literally the real MVPs 👑💖
Authors' Addresses 🦋
Brandon Williams
Akamai, Inc.
8 Cambridge Center
Cambridge, MA 02142
United States of America
Email: brandon.williams@akamai.com
Mohamed Boucadair
Orange
Email: mohamed.boucadair@orange.com
Dan Wing
Email: dwing-ietf@fuggles.com📦 where this page comes from
- ietf: rfc7974 2016-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms