summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7974.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7974.txt')
-rw-r--r--doc/rfc/rfc7974.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc7974.txt b/doc/rfc/rfc7974.txt
new file mode 100644
index 0000000..aeef9c3
--- /dev/null
+++ b/doc/rfc/rfc7974.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Independent Submission B. Williams
+Request for Comments: 7974 Akamai, Inc.
+Category: Informational M. Boucadair
+ISSN: 2070-1721 Orange
+ D. Wing
+ October 2016
+
+
+ An Experimental TCP Option for Host Identification
+
+Abstract
+
+ Recent RFCs have discussed issues with host identification in IP
+ address-sharing systems, such as address/prefix-sharing devices and
+ application-layer proxies. Potential solutions for revealing a host
+ identifier in shared address deployments have also been discussed.
+ This memo describes the design, deployment, and privacy
+ considerations for one such solution in operational use on the
+ Internet today that uses a TCP option to transmit a host identifier.
+
+Independent Submissions Editor Note
+
+ This Informational document specifies an experimental TCP HOST_ID
+ option that is already fairly widely deployed. It discusses that
+ option's privacy considerations in considerable detail and highlights
+ the care providers need to exercise in any actual deployment. The
+ Independent Submissions Editor has chosen to publish this document in
+ the Independent Stream so that potential deployers and implementors
+ can understand all its details, so as to produce implementations that
+ will interwork properly with other (existing) deployments.
+
+IESG Note
+
+ This proposal was previously proposed for adoption by the TCPM
+ working group and rejected as being 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". As this
+ proposal has been rejected by the IETF community, it is not eligible
+ for the registration of a TCP option codepoint. It should be further
+ noted that for experimental TCP options, it "is only appropriate to
+ use these values in explicitly-configured experiments; they MUST NOT
+ be shipped as defaults in implementations" [RFC4727]. The IESG also
+ carried out a review as described in [RFC5742] and concluded that
+ this proposal violates IETF principles expressed in [RFC7258] about
+ pervasive monitoring as an attack and should therefore not be
+ published without IETF review and IESG approval. (The process
+
+
+
+Williams, et al. Informational [Page 1]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+ described in [RFC5742] nonetheless allows the Independent Submissions
+ Editor to publish, as has been chosen in this case.) Deployments of
+ this proprietary TCP option may be widely viewed as undermining
+ privacy and are likely to encounter issues with reliability of
+ transport.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This is a contribution to the RFC Series, independently of any other
+ RFC stream. The RFC Editor has chosen to publish this document at
+ its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 7841.
+
+ 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/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) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams, et al. Informational [Page 2]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+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 ................................................20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams, et al. Informational [Page 3]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+1. Introduction
+
+ A broad range of issues associated with address sharing have been
+ documented in [RFC6269] and [RFC7620]. In addition, [RFC6967]
+ provides an analysis of various solutions to the problem of revealing
+ the sending host's identifier (HOST_ID) information to the receiver,
+ indicating that a solution using a TCP [RFC793] option for this
+ purpose is among the possible approaches that could be applied with
+ limited performance impact and a high success ratio. The purpose of
+ this memo is to describe a TCP HOST_ID option that is currently
+ deployed on the public Internet using the TCP experimental option
+ codepoint, including discussion of related design, deployment, and
+ privacy considerations.
+
+ Multiple documents have defined TCP options for the purpose of host
+ identification: [REVEAL], [HOSTID], and [OVERLAYPATH]. Specification
+ of multiple option formats to serve the purpose of host
+ identification increases the burden for potential implementers and
+ presents interoperability challenges as well, so the authors of those
+ documents have worked together to define a common TCP option that
+ supersedes the formats from those three documents. This memo
+ describes a version of that common TCP option format that is
+ currently in use on the public Internet.
+
+ The option defined in this memo uses the TCP experimental option
+ codepoint sharing mechanism defined in [RFC6994]. One of the earlier
+ specifications, [OVERLAYPATH], is associated with unauthorized use of
+ a TCP option kind number, and moving to the TCP experimental option
+ codepoint has allowed the authors of that document to correct their
+ error.
+
+1.1. Important Use Cases
+
+ The authors' implementations have primarily focused on the following
+ address-sharing use cases in which currently deployed systems insert
+ the HOST_ID option:
+
+ Carrier-Grade NAT (CGN): As defined in [RFC6888], [RFC6333], and
+ other sources, a CGN allows multiple hosts connected to the public
+ Internet to share a single Internet routable IPv4 address. One
+ important characteristic of the CGN use case is that it modifies
+ IP packets in-path, but does not serve as the endpoint for the
+ associated TCP connections.
+
+ Application Proxy: As defined in [RFC1919], an application proxy
+ splits a TCP connection into two segments, serving as an endpoint
+ for each of the connections and relaying data flows between the
+ connections.
+
+
+
+Williams, et al. Informational [Page 4]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+ Overlay Network: An overlay network is an Internet-based system
+ providing security, optimization, or other services for data flows
+ that transit the system. A network-layer overlay will sometimes
+ act much like a CGN, in that packets transit the system with NAT
+ being applied at the edge of the overlay. A transport-layer or
+ application-layer overlay [RFC3135] will typically act much like
+ an application proxy, in that the TCP connection will be segmented
+ with the overlay network serving as an endpoint for each of the
+ TCP connections.
+
+ In this set of sender use cases, the TCP option is applied to an
+ individual TCP packet either at the connection endpoint (e.g., an
+ application proxy or a transport-layer overlay network) or at an
+ address-sharing middlebox (e.g., a CGN or a network-layer overlay
+ network). See Section 4 for additional details about the types of
+ devices that add the option to a TCP packet, as well as existing
+ limitations on use of the option when it is inserted by an address-
+ sharing middlebox, including issues related to packet fragmentation.
+
+ The existing receiver use cases considered by this memo include the
+ following:
+
+ o Differentiating between attack and non-attack traffic when the
+ source of the attack is sharing an address with non-attack
+ traffic.
+
+ o Application of per-subscriber policies for resource utilization,
+ etc., when multiple subscribers are sharing a common address.
+
+ o Improving server-side load-balancing decisions by allowing the
+ load for multiple clients behind a shared address to be assigned
+ to different servers, even when session affinity is required at
+ the application layer.
+
+ In all of the above cases, differentiation between address-sharing
+ clients is performed by a network function that does not process the
+ application-layer protocol (e.g., HTTP) or the security protocol
+ (e.g., TLS), because the action needs to be performed prior to
+ decryption or parsing the application layer. Due to this, a solution
+ implemented within the application layer or security protocol was
+ considered unable to fully meet the receiver-side requirements. At
+ the same time, as noted in [RFC6967], use of an IP option for this
+ purpose has a low success rate. For these reasons, using a TCP
+ option to deliver the host identifier was deemed by the authors to be
+ an effective way to satisfy these specific use cases. See Section 5
+ for details about receiver-side interpretation of the option.
+
+
+
+
+
+Williams, et al. Informational [Page 5]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+1.2. Document Goals
+
+ Publication of this memo is intended to serve multiple purposes.
+
+ First and foremost, this document intends to inform readers about a
+ mechanism that is in broad use on the public Internet. The authors
+ are each affiliated with companies that have implemented, tested,
+ and/or deployed systems that use the HOST_ID option on the public
+ Internet. Other systems might encounter packets that contain this
+ TCP option, and this document is intended to help others understand
+ the nature of the TCP option when it is encountered so they can make
+ informed decisions about how to handle it.
+
+ The testing effort documented in [HOSTID] indicated that a TCP option
+ could be used for host identification purposes without significant
+ disruption of TCP connectivity to legacy servers and networks that do
+ not support the option. It also showed how mechanisms available in
+ existing TCP implementations could make use of such a TCP option for
+ diagnostics and/or packet filtering. The authors' use of the TCP
+ option on the public Internet has confirmed that it can be used
+ effectively for our use cases, but it has also uncovered some
+ interoperability issues associated with the option's use on the
+ public Internet, especially regarding interactions with other TCP
+ options that support new transport capability being specified within
+ the IETF. Section 6 discusses those interactions and limitations and
+ explains how our systems handle associated issues.
+
+ Discussions within the IETF have raised privacy concerns about the
+ option's use, especially in regard to pervasive monitoring risks.
+ Existing uses of the option limit the nature of the HOST_ID values
+ that are used and the systems that insert them in order to mitigate
+ pervasive monitoring risks. Sections 8 and 9 discuss the authors'
+ assessments of the privacy and monitoring impact of this TCP option
+ in its current uses and suggest behavior for some external systems
+ when the option is encountered. Continued discussion following
+ publication of this memo is expected to allow further refinement of
+ requirements related to the values used to populate the option and
+ how those values can be interpreted by the receiver. There is a
+ trade-off between providing the expected functionality to the
+ receiver and protecting the privacy of the sender, and continued
+ assessment will be necessary in order 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].
+
+
+
+
+Williams, et al. Informational [Page 6]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+3. Option Format
+
+ When used for host identification, the TCP experimental option uses
+ the experiment identification mechanism described in [RFC6994] and
+ has the following format and content.
+
+ 0 1 2 3
+ 01234567 89012345 67890123 45678901
+ +--------+--------+--------+--------+
+ | Kind | Length | ExID |
+ +--------+--------+--------+--------+
+ | HOST_ID ...
+ +--------+---
+
+ Kind: The option kind value is 253.
+
+ Length: The length of the option is variable, based on the required
+ size of the host identifier (e.g., a 2-octet HOST_ID will require
+ a length of 6, while a 4-octet HOST_ID will require a length of
+ 8).
+
+ ExID: The experiment ID value is 0x0348 (840).
+
+ HOST_ID: The host identifier is a value that can be used to
+ differentiate among the various hosts sharing a common public IP
+ address. See below for further discussion of this value.
+
+4. Option Use
+
+ This section describes requirements associated with the use of the
+ option, including expected option values, which hosts are allowed to
+ include the option, and segments that include the option.
+
+4.1. Option Values
+
+ The information conveyed in the HOST_ID option is intended to
+ uniquely identify the sending host to the best capability of the
+ machine that adds the option to the segment, while at the same time
+ avoiding inclusion of information that does not assist this purpose.
+ In addition, the option is not intended to be used to expose
+ information about the sending host that could not be discovered by
+ observing segments in transit on some portion of the Internet path
+ between the sender and the receiver. Existing use cases have
+ different requirements for receiver-side functionality, so this
+ document attempts to provide a high degree of flexibility for the
+ machine that adds the option to TCP segments.
+
+
+
+
+
+Williams, et al. Informational [Page 7]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+ 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). Example values that satisfy this requirement include
+ the following:
+
+ Unique ID: An inserting host/device could maintain a pool of locally
+ unique ID values that are dynamically mapped to the unique source
+ IP address values in use behind the host/device as a result of
+ address sharing. This ID value would be meaningful only within
+ the context of a specific shared IP address due to the local
+ uniqueness characteristic. Such an ID value could be smaller than
+ an IP address (e.g., 16 bits) in order to conserve TCP option
+ space. This option is preferred because it does not increase IP
+ address visibility on the forward side of the address-sharing
+ system, and it SHOULD be used in cases where receiver-side
+ requirements can be met without direct inclusion of the original
+ IP address (e.g., some load-balancing uses).
+
+ IP Address/Subnet: An inserting host/device could simply populate
+ the option value with the IP address value in use behind the host/
+ device. In the case of IPv6 addresses, it could be difficult to
+ include the full address due to TCP option space constraints, so
+ the value would likely need to provide only a portion 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 being assigned to each subscriber [RFC6346]. When such a
+ system is behind an address-sharing host/device, inclusion of both
+ the IP address and the TCP port number will more uniquely identify
+ the sending host than just the IP address on its own.
+
+ When multiple host identifiers are necessary (e.g., an IP address and
+ a port number), the HOST_ID option is included multiple times within
+ the packet, once for each identifier. While this approach
+ significantly increases option space utilization when multiple
+ identifiers are included, cases where only a single identifier is
+ included are expected to be more common; thus, it is beneficial to
+ optimize for those cases. Note that some middleboxes might reorder
+ TCP options, so this method could be problematic if such a middlebox
+ is in-path between the address-sharing system and the receiver. This
+ has not proven to be a problem for existing use cases.
+
+ See Section 8 for discussion of privacy considerations related to
+ selection of HOST_ID values.
+
+
+
+
+
+Williams, et al. Informational [Page 8]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+4.2. Sending Host Requirements
+
+ The HOST_ID option MUST only be added by the sending host or any
+ device involved 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 cannot determine whether the
+ option value is used in a stateful manner by the receiver, nor can it
+ determine whether SYN cookies are in use by the receiver. For this
+ reason, 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 have also considered an alternative approach to SYN
+ cookie support in which the receiving host (i.e., the host that
+ accepts the TCP connection) echoes the option back to the sender in
+ the SYN/ACK segment when a SYN cookie is being sent. This would
+ allow the host sending HOST_ID to determine whether further inclusion
+ of the option is necessary. This approach would have the benefit of
+ not requiring inclusion of the option in non-SYN segments if SYN
+ cookies had not been used. Unfortunately, this approach fails if the
+ responding host itself does not support the option, since an
+ intermediate node would have no way to determine that SYN cookies had
+ been used.
+
+4.2.2. Persistent TCP Connections
+
+ Some types of middleboxes (e.g., application proxy) open and maintain
+ persistent TCP connections to regularly visited destinations in order
+ to minimize the burden of connection establishment. Such middleboxes
+ might use a single persistent TCP connection for multiple different
+ client hosts over the life of the persistent connection.
+
+ This specification does not attempt to support the use of persistent
+ TCP connections for multiple client hosts due to the perceived
+ complexity of providing such support. 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
+
+
+
+Williams, et al. Informational [Page 9]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+ the connection. 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
+
+ In order to avoid the overhead associated with in-path IP
+ fragmentation, it is desirable for the inserting host/device to avoid
+ including the HOST_ID option when IP fragmentation might be required.
+ This is not a firm requirement though, because the HOST_ID option is
+ only included in the first few packets of a TCP connection; thus,
+ associated IP fragmentation will generally have minimal impact. The
+ option SHOULD NOT be included in packets if the resulting packet
+ would require local fragmentation.
+
+ It can be difficult to determine whether local fragmentation would be
+ required. For example, in cases where 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, this decision
+ could be made after TCP option handling is complete. Additionally,
+ it could be true that inclusion of the option causes the packet to
+ violate the path's MTU but the path's MTU has not been learned yet on
+ the sending host/device.
+
+ In existing deployed systems, the impact of IP fragmentation that
+ results from use of the option has been minimal.
+
+4.3. Multiple In-Path HOST_ID Senders
+
+ The possibility exists that there could be multiple in-path hosts/
+ devices configured to insert the HOST_ID option. For example, the
+ client's TCP packets might first traverse a CGN device on their way
+ to the edge of a public Internet overlay network. In order for the
+ HOST_ID value to most uniquely identify the sender, it needs to
+ represent both the identity observed by the CGN device (the
+ subscriber's internal IP address, e.g., Shared Address Space
+ [RFC6598]) and the identity observed by the overlay network (the
+ shared address of the CGN device). The mechanism for handling the
+ received HOST_ID value could vary depending upon the nature of the
+ new HOST_ID value to be inserted, as described below.
+
+ The problem of multiple in-path HOST_ID senders has not been observed
+ in existing deployed systems. For this reason, existing
+ implementations do not consistently support this scenario. Some
+ systems do not propagate forward the received HOST_ID option value in
+ any way, while other systems follow the guidance described below.
+
+
+
+
+Williams, et al. Informational [Page 10]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+ An inserting host/device that uses the received packet's source IP
+ address as the HOST_ID value (possibly along with the port) MUST
+ propagate forward the HOST_ID value(s) from the received packet,
+ since the source IP address and port only represent the previous
+ in-path address-sharing device and do not represent the original
+ sender. In the CGN-plus-overlay example, this means that the overlay
+ will include both the CGN's HOST_ID value(s) and a HOST_ID with the
+ source IP address received by the overlay.
+
+ 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:
+
+ 1. 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.
+
+ 2. 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 that the overlay would include both the CGN's HOST_ID value
+ and a HOST_ID with a unique ID of its own that was 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
+
+ Due to the variable nature of the option value, it is not possible
+ for the receiving machine to reliably determine the value type from
+ the option itself. For this reason, a receiving host/device SHOULD
+ interpret the option value as an opaque identifier.
+
+ This specification allows the inserting host/device to provide
+ multiple HOST_ID options. The order of appearance of TCP options
+ could be modified by some middleboxes, so receivers SHOULD NOT rely
+ on option order to provide additional meaning to the individual
+ options. Instead, when multiple HOST_ID options are present, their
+ values SHOULD be concatenated together in the order in which they
+ appear in the packet and treated as a single large identifier.
+
+
+
+
+Williams, et al. Informational [Page 11]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+ For both of the receiver requirements discussed above, 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
+ the inserting host and the interpreting host. Mechanisms for
+ signaling the value type(s) and integrity protection are not provided
+ by this specification, and in their absence, 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 functions in conjunction
+ with other TCP options.
+
+6.1. Multipath TCP (MPTCP)
+
+ TCP provides for a maximum of 40 octets for TCP options. As
+ discussed in Appendix A of MPTCP [RFC6824], a typical SYN from
+ modern, popular operating systems contains several TCP options (MSS
+ (Maximum Segment Size), window scale, SACK (selective acknowledgment)
+ permitted, and timestamp), which consume 19-24 octets depending on
+ word alignment of the options. The initial SYN from a multipath TCP
+ client would consume an additional 16 octets.
+
+ HOST_ID needs at least 6 octets to be useful, so 9-21 octets are
+ sufficient for many scenarios that benefit from HOST_ID. However, 4
+ octets are not enough space for the HOST_ID option. Thus, a TCP SYN
+ containing all the typical TCP options (MSS, window scale, SACK
+ permitted, and timestamp) and also containing multipath capable or
+ multipath join as well as being word-aligned has insufficient space
+ to accommodate HOST_ID. This means something has to give. The
+ choices are either to avoid word alignment in that case (freeing 5
+ octets) or avoid adding the HOST_ID option. Each of these approaches
+ is used in existing implementations and has 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 due to the fact that it provides integrity protection
+ of the source IP address. For this reason, 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
+ does not interfere with the use of TCP-AO-NAT because the TCP options
+ are not included in the Message Authentication Code (MAC)
+ calculation.
+
+
+
+Williams, et al. Informational [Page 12]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+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 length 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:
+
+ o 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.
+
+ o 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.
+
+ It should also be noted that 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 the existing system considers 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].
+
+ 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
+
+
+
+Williams, et al. Informational [Page 13]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+ integrity-protect communication between the inserting host and the
+ interpreting host. Mechanisms for signaling the value type(s) and
+ integrity protection are not provided by this specification, and 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, and 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
+
+ Sending a TCP SYN across the public Internet necessarily discloses
+ the public IP address of the sending host. When an intermediate
+ address-sharing device is deployed on the public Internet, anonymity
+ of the hosts using the device will be increased, with hosts
+ represented by multiple source IP addresses on the ingress side of
+ the device using a single source IP address on the egress side. The
+ HOST_ID TCP option removes that increased anonymity, taking
+ information that was already visible in TCP packets on the public
+ Internet on the ingress side of the address-sharing device and making
+ it available on the egress side of the device as well. In some
+ cases, an explicit purpose of the address-sharing device is
+ anonymity, in which case use of the HOST_ID TCP option would be
+ incompatible with the purpose of the device.
+
+ A NAT device used to provide interoperability between a local area
+ network (LAN) using private [RFC1918] IP addresses and the public
+ Internet is sometimes specifically intended to provide anonymity for
+ the LAN clients as described in the above paragraph. For this
+ reason, address-sharing devices at the border between a private LAN
+ and the public Internet MUST NOT insert the HOST_ID option.
+
+ 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
+
+
+
+
+Williams, et al. Informational [Page 14]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+ 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 such that 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, such as subscriber information linked to the IP address.
+
+ The HOST_ID value MUST be changed whenever the subscriber IP address
+ changes. This requirement ensures that the HOST_ID option does not
+ introduce a new globally unique identifier that persists 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
+
+ [RFC7258] provides the following guidance: "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." Legitimate concerns about
+ host identification have been raised within the IETF. The authors of
+ this memo have attempted to address those concerns by providing
+ details about the nature of the HOST_ID values and the types of
+ middleboxes that should and should not include the HOST_ID option in
+ TCP headers, which describes limitations already imposed by existing
+ deployed systems. This section is intended to highlight some
+ particularly important aspects of this design and the related
+ guidance/limitations that are relevant to 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. As with
+ persistent IP addresses, persistent HOST_ID values could facilitate
+ user tracking and are therefore prohibited. The specific
+ requirements for permissible HOST_ID values are discussed in Sections
+ 8 and 4.1.
+
+ This specification does not target exposing a host beyond what the
+ original packet, issued from that host, would have already exposed on
+ the public Internet without introduction of the option. The option
+ is intended only to carry forward information that was conveyed to
+ the address-sharing device in the original packet, and HOST_ID option
+
+
+
+Williams, et al. Informational [Page 15]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+ values that do not match this description are prohibited by
+ requirements discussed in Section 8. This design does not allow the
+ HOST_ID option to carry personally identifiable information,
+ geographic location identifiers, or any other information that is not
+ 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. Thus, the volatility of the information conveyed in
+ a HOST_ID option is similar to that of the public, subscriber IP
+ address. A distinct HOST_ID is 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 allows network identification to a similar
+ level as the first 64 bits of an IPv6 address. That is, 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 the server would use the
+ host's IPv6 network address if the 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. Publication of
+ this document can help such middleboxes recognize the associated risk
+ and take action to mitigate it (e.g., 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>.
+
+
+
+
+
+Williams, et al. Informational [Page 16]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+ [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
+
+ [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>.
+
+
+
+
+
+
+
+
+Williams, et al. Informational [Page 17]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+ [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>.
+
+
+
+Williams, et al. Informational [Page 18]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+ [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams, et al. Informational [Page 19]
+
+RFC 7974 Experimental TCP HOST_ID Option October 2016
+
+
+Acknowledgements
+
+ Many thanks to W. Eddy, Y. Nishida, T. Reddy, M. Scharf, J. Touch,
+ A. Zimmermann, and A. Falk for their comments.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams, et al. Informational [Page 20]
+