One document matched: draft-wing-nat-reveal-option-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5925.xml">
<!ENTITY rfc4987 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4987.xml">
<!ENTITY I-D.ietf-intarea-shared-addressing-issues SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-shared-addressing-issues.xml">
<!ENTITY I-D.boucadair-intarea-nat-reveal-analysis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.boucadair-intarea-nat-reveal-analysis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc='yes'?>
<?rfc rfcprocack="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-wing-nat-reveal-option-02"
ipr="trust200902">
<front>
<title abbrev="User Hint via TCP option">Revealing hosts sharing an IP
address using TCP option</title>
<author fullname="Andrew Yourtchenko" initials="A." surname="Yourtchenko">
<organization abbrev="cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>6a de Kleetlaan</street>
<city>Diegem</city>
<code>1831</code>
<country>BE</country>
</postal>
<phone>+32 2 704 5494</phone>
<email>ayourtch@cisco.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<code>CA 95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<date year="2011" />
<workgroup></workgroup>
<abstract>
<t>When an IP address is shared among several subscribers -- with a NAT
or with an application-level proxy -- it is impossible for the server to
differentiate between different clients. Such differentiation is
valuable in several scenarios. This memo describes a technique to
differentiate TCP clients sharing an IP address. The proposed method
uses a TCP option, which avoids altering the application-level payload
and works well with SSL-protected connections.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>When clients are allocated unique, publicly-routable IPv4 addresses,
it is easy to associate certain characteristics with their IP address.
For example, if an IP address sends a lot of spam, that IP address is
classified by many public (and private) system as "a spammer". Such
classification can cause email or other traffic from that IP address to
be blocked, rate limited, challenged with a captcha, or to receive other
treatment. Reputation systems of various sorts exist for a wide variety
of services on the Internet including IMAP, HTTP, ssh -- often these
systems will slow down or interfere with normal login attempts when a
dictionary attack is detected. An IP address can be added to a multitude
of 'reputation' systems. Some of these systems are distributed across
the Internet, some are shared amongst consenting parties, and some are
operated by individual enterprises or individual hosts. Further
discussion of the impacts of address sharing can be found in <xref
target="I-D.ietf-intarea-shared-addressing-issues"></xref>.</t>
<t>With the exhaustion of the IPv4 address space, IPv4 addresses will be
shared on a large scale. This sharing will persist long after IPv6 is
ubiquitous -- in fact, IPv4 address sharing will persist until all
content and services on the Internet are available over IPv6. Once all
content and services are available over IPv6, an Internet service
provider will no longer need to provide access to the IPv4 Internet.</t>
<t>Until that time, both legitimate users and attackers will share IPv4
addresses. This IP address sharing means legitimate users will share the
reputation of attackers.</t>
<t>This document describes a TCP option which can be added by an address
sharing device such as a NAT or an application-level proxy. This TCP
option allows a TCP server to differentiate between the TCP clients
sharing that IP address.</t>
<t>An analysis of other techniques is available in <xref
target="I-D.boucadair-intarea-nat-reveal-analysis"></xref>.</t>
<!--
<t>Some services on the Internet will react to TCP SYNs from certain
IP addresses, such as by filtering them entirely. This is
because completing a 3-way handshake consumes resources and some attacks
are intended to consume resources; once the attacking source is
identified, its connections attempts are ignored. The
mechanism proposed in this paper allows a TCP server to continue to drop
those incoming TCP SYN messages, even if they are from a device behing a
carrier's NAT or behind an application proxy. Likewise, some
services need to perform database lookups when the TCP SYN arrives or
immediately after the 3-way handshake completes (and before application
data arrives). This mechanism described in this document allows
such mechanisms to continue to function at their current speed and
efficiency.</t>
-->
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119">RFC2119</xref>.</t>
<t>subscriber: the client accessing an address sharing device, who is
responsible for the actions of their device(s). This might be an
individual handset (with mobile devices), a home Internet connection, a
small-medium business Internet connection, a University dormitory room,
an individual employee of a company, or the company itself.</t>
</section>
<section title="Description">
<t>This proposal defines one new TCP option, USER_HINT, to contain the
TCP client's 16 bit identifier. This value might be the lower 16 bits of
their IPv4 address, their VLAN ID, VRF ID, subscriber ID, or similar.
The address sharing device (NAT, application proxy) would add the TCP
option to the TCP SYN packet. TCP options are treated outside of the TCP
sequence space, so no modifications of either sequence or
acknowledgement numbers are needed.</t>
<section title="Operation of Address Sharing Device">
<t>The address sharing device inserts the USER_HINT option into the
TCP SYN, as depicted below. If the TCP SYN already has a
USER_HINT option present, it is ignored and over-written with the new
value.</t>
<figure>
<artwork><![CDATA[
TCP CLIENT proxy, NAT64, NAT44 TCP SERVER
---------- ------------------- ----------
| | |
|---TCP SYN------>| |
| |---TCP SYN, USER_HINT=12345-->|
... ... ...
]]></artwork>
</figure>
</section>
<section title="Operation of the TCP Server">
<t>The TCP server identifies the client by combining the source IPv4
address in the IP header with the data in the USER_HINT option.
This can be implemented by modifying the TCP stack to make the
USER_HINT data available to the application via an API (e.g., via a
socket option).</t>
</section>
<section title="Reusing the USER_HINT value">
<t>The USER_HINT value is only 16 bits, so is obviously not globally
unique. Even when combined with the publicly-routable IP address, the
additional 16 bits are still not guaranteed to uniquely identify a
particular subscriber. Out of necessity, the numbering space will be
re-used by some address sharing devices, especially address sharing
devices that are sharing many users on one IP address. As with today's
IPv4 addresses which are assigned by an ISP, deterministically
associating the IPv4 address (or IPv4 address and USER_HINT) with a
particular subscriber requires more than simply completing a TCP 3-way
handshake. For example, over a single day, an address sharing device
might serve tens of thousands of different subscribers from the same
shared IP address, and thus it will need to rotate through the 16 bit
USER_HINT space several times during the day. When doing so, the
USER_HINT MUST NOT be re-used more often than every 2 minutes (a
number chosen out of thin air); if an address sharing device needs to
re-use a USER_HINT value more often than that, it should use
additional IP addresses (to reduce how quickly the USER_HINT space is
consumed on each address) or simply send TCP SYNs without USER_HINT
until 2 minutes have elapsed. This 2 minute delay is necessary to
allow the reputation system on a TCP server to differentiate between
subscribers. For most implementations, the port sharing ratio (rather
than a timer) is sufficient to meet this requirement.</t>
</section>
</section>
<section title="USER_HINT Option Format">
<t>The USER_HINT option is always 4 bytes long, with 16 bits of
USER_HINT data</t>
<figure>
<artwork align="center"><![CDATA[
+--------+--------+-----------------------+
|xxxxxxxx|00000100| USER_HINT data |
+--------+--------+-----------------------+
Kind=TBD Length=4
]]></artwork>
</figure>
<t>User Hint option data: 16 bits.</t>
<t>If this option is present, it differentiates between active TCP hosts
sharing the same IP address. This field MUST only be sent in the initial
connection request (i.e., in segments with the SYN control bit set), or
in the first ACK if the server's SYN contained the USER_HINT option.</t>
</section>
<section title="Interaction with other TCP Options">
<t>This section details how USER_HINT functions in conjunction with
other TCP options.</t>
<section title="Option Space">
<t>As discussed in <xref
target="I-D.ietf-mptcp-multiaddressed">Appendix A of Multipath TCP
(MPTCP)</xref>, there is a maximum of 40 bytes for TCP options, and a
typical SYN (with MSS, window scale, SACK permitted, and timestamp
options) leaves 16 bytes spare (if the options are word-aligned) or 21
bytes spare (if the options are not word-aligned).</t>
<t>Thus, the 4 byte option proposed in this memo would not cause a
problem with a typical TCP SYN.</t>
</section>
<section title="Multipath TCP (MPTCP)">
<t>If the TCP client supports <xref
target="I-D.ietf-mptcp-multiaddressed">Multipath TCP (MPTCP)</xref>,
the client will include the Multipath Capable or Multipath Join
options to the TCP SYN. The Multipath Capable (MP_CAPABLE) option
consumes 12 bytes, so a SYN containing all of these options would
fully consume the 40 byte SYN option space. The Multipath Join
(MP_JOIN) can consumes 12 or 16 bytes, but it is only used after
successful early exchange containing the MP_CAPABLE option. Thus,
there is reason to include USER_HINT if MP_JOIN is present in the TCP
SYN -- if the MP_JOIN is not valid, it will be rejected by the server
without creating any state on the server. Furthermore, if a client TCP
is multi-homed, the client's TCP connections will probably go through
different address sharing devices and thus have different
externally-visible IP addresses and different USER_HINT values. Thus,
it is NOT RECOMMENDED to include the USER_HINT option if the TCP SYN
contains the MP_JOIN option.</t>
</section>
<section title="Authentication Option (TCP-AO)">
<t>The USER_HINT option is incompatible with the <xref
target="RFC5925">Authentication Option (TCP-AO)</xref>, because TCP-AO
provides integrity protection of the TCP SYN, including TCP options.
However, TCP-AO is already incompatible with address sharing, because
TCP-AO provides integrity protection of the source IP address.</t>
</section>
</section>
<section title="Interaction with TCP SYN Cookies">
<t><xref target="RFC4987">TCP SYN cookies</xref> are commonly deployed
to mitigate TCP SYN attacks, which have some side effects. The USER_HINT
information in the TCP SYN provides the TCP server with additional
information it can use when deciding if this TCP connection attempt
should be answered with a SYN cookie or should be answered normally. In
the event the TCP server does not (or cannot) store the USER_HINT data,
the USER_HINT data can be re-established on the TCP server when the
client's first ACK is sent. There is a slight risk, however, that the
client's first ACK, as seen by the middlebox, might contain data. If it
does contain data, adding another 4 bytes to the packet could cause MTU
to be exceeded.</t>
<figure>
<artwork align="center"><![CDATA[
TCP CLIENT proxy, NAT64, NAT44 TCP SERVER
---------- ------------------- ----------
| | |
|---TCP SYN----------->| |
1. | |---TCP SYN, USER_HINT=12345-->|
2. | |<--TCP SYNACK, USER_HINT=8988-|
3. |<--TCP SYNACK---------| |
: : :
4a. |---TCP ACK (no data)->| |
4a. | |---TCP ACK, USER_HINT=8988--->|
| | |
: : :
4b. |---TCP ACK (data)---->| |
4b. | |---TCP ACK------------------->|
]]></artwork>
</figure>
<t>The procedure is as follows:</t>
<t><list style="numbers">
<t>Upon receiving a TCP SYN containing the USER_HINT option, the TCP
server MAY respond to a SYN containing USER_HINT with an ACK packet
containing its own USER_HINT value. (Note: this ACK response will
typically have the SYN bit set.) If the server does not include the
USER_HINT in its ACK packet, processing stops.</t>
<t>The middlebox, upon seeing the USER_HINT in the ACK, records
those 2 bytes, which are used in a later step.</t>
<t>The middlebox strips the USER_HINT from the ACK, so it is not
received by the TCP client. The middlebox sends the TCP ACK, without
its USER_HINT option, to the TCP client.</t>
<t>The TCP client responds normally, generating a TCP ACK.</t>
<t>The middlebox receives an ACK from the TCP client. This ACK will
either contain:<list style="letters">
<t>no data, which causes the middlebox to add the USER_HINT
value (from step 2) to the TCP ACK</t>
<t>data, which causes the middlebox to simply forward the ACK
packet. This is done to avoid MTU problems between the middlebox
and the TCP server.</t>
</list></t>
</list></t>
<t>State is required in the address sharing device to perform the steps
described in this section. This isn't a disaster with stateful address
sharing (e.g., NAPT). However, in an A+P-like system (e.g., <xref
target="I-D.ymbk-aplusp"></xref>, <xref
target="I-D.despres-intarea-4rd"></xref>), the CPE would need to perform
the USER_HINT function, which introduces additional security
considerations (not yet discussed in this version of the document).</t>
</section>
<section title="Security Considerations">
<!--
<t>In the absence of IP address sharing, when a client initiates
a connection, the client's IP address is seen by the server by
necessity: so that the packet can be routed back to the
client. In the presence of IP address address sharing, the
server will see the IP address of the address sharing device
(rather than the client's address). Thus, address sharing
discloses less information to the server. This can be used
to an attacker's advantage, so the attacker can hide amongst
legitimate traffic
In the absence of address sharing, initiating a connection
The connections that happen, today, without a NAPT necessarily reveal
the source address of the TCP client; so this mechanism revealing the
identity of the client should not be a concern except for the
installations that attempt to use NAPT for "privacy" reasons. At such
installations, their NAPT would not implement the TCP option described
in this document. </t>
-->
<t>An attacker might use this functionality to appear as if IP address
sharing is occurring, in the hopes that a naive server will allow
additional attack traffic. TCP servers and applications SHOULD NOT
assume the mere presence of the functionality described in this paper
indicates there are other (benign) users sharing the same IP
address.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Anantha Ramaiah for the discussion. Thanks to Senthil
Sivakumar for his review.</t>
</section>
<section title="IANA Considerations">
<t>Assign a new TCP option number (kind value), USER_HINT.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc5925;
</references>
<references title="Informative References">
&rfc4987;
&I-D.ietf-intarea-shared-addressing-issues;
&I-D.boucadair-intarea-nat-reveal-analysis;
<?rfc include='reference.I-D.ietf-mptcp-multiaddressed'?>
<?rfc include='reference.I-D.ymbk-aplusp'?>
<?rfc include='reference.I-D.despres-intarea-4rd'?>
</references>
<section title="Change History">
<t>[Note to RFC Editor: Please remove this section prior to
publication.]</t>
<section title="Changes from draft-wing-nat-reveal-option-01 to -02">
<t><list style="symbols">
<t>Limit option value to 16 bits (which becomes 32 bits total with
the 8 bit option number and 8 bit length)</t>
<t>described how USER_HINT can work successfully with Multipath
TCP (MPTCP)'s options.</t>
<t>Better described operation with TCP SYN Cookies.</t>
<t>Renamed option from CX-ID to USER_HINT</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:54:37 |