One document matched: draft-wing-nat-reveal-option-01.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-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-01" ipr="trust200902">
<front>
<title abbrev='Connection Identity via TCP option'>Revealing hosts sharing an IP address using TCP option</title>
<author initials='A.' surname='Yourtchenko' fullname='Andrew Yourtchenko'>
<organization>cisco</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 initials='D.' surname='Wing' fullname='Dan Wing'>
<organization>cisco</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, it is impossible to determine which subscriber has initiated that TCP connection. This memo describes a technique to share the identity of a subscriber that initiated a TCP connection with the TCP server. The proposed method avoids altering the application-level payload and works well with SSL-protected connections. It uses a new TCP option for this purpose.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>
There are several scenarios where it is valuable to know the identity of a TCP client, including geolocation, DoS blocking, and spam blacklists. Historically, this has been done by equating IPv4 address with 'identity'. However, the identity of a TCP client is obscured when an IP address is shared <xref target="I-D.ietf-intarea-shared-addressing-issues">I-D.ietf-intarea-shared-addressing-issues</xref>. IP address sharing is done by both network address and port translators (NAPT) and by application-layer proxies (e.g., HTTP or FTP proxies).
</t>
<t>
The current state of the art requires the address sharing alter the application-level payload and include the identity of the internal host -- usually the internal host's private IP address (e.g., X-Forwarded-For). This incurs several drawbacks,<list style="symbols">
<t>adjustment of TCP sequence numbers and acknowledgement numbers for the duration of the TCP session</t><t>risk of false-positive application matching (e.g., accidentally inserting an HTTP header into a non-HTTP payload).</t><t>interference with application payload by increasing packet size (e.g., MTU)</t></list>
With SSL-protected applications (e.g., HTTP CONNECT, https) the current state of the art requires breaking the end-to-end encrypted connection. This results in several undesirable consequences:<list style="symbols">
<t>necessity for the translator to break the end-to-end encryption, typically by installing an addional Certificate Authority on the client's CA trust list</t><t>noticeable increase in the processing power required on the address sharing device to decrypt and re-encrypt that application payload</t></list>
</t>
<t>
This specification avoids the problems described above, and defines the method of communicating the TCP client's identity to the TCP server with a new TCP option to signal the internal IP address. and is an alternative submission compared to [the nat-reveal].
</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>
<t>
This extension is necessary because IP address sharing will allow malicious users to connect to IPv4-capable servers. Thus, until a server is only accessible via IPv6 (and inaccessible via IPv4), IPv4 servers will suffer from the inability to identify individual TCP clients as discussed in <xref target="I-D.ietf-intarea-shared-addressing-issues">I-D.ietf-intarea-shared-addressing-issues</xref>.
</t>
</section>
<section title='Notational Conventions'>
<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>
</section>
<section title='Description'>
<t>
This proposal defines one new TCP option, CX-ID, to contain the client's identifier -- which might be their IPv4 address, VLAN ID, VRF ID, subscriber ID, or first half of their IPv6 address. The address sharing device (NAT, application proxy) would add the TCP option to the TCP SYN packet. Up to 8 octets (64 bits) can be expressed. 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>
</t>
<t>
The address sharing device inserts the CX-ID option onto the TCP SYN, as depicted below. If there is already an CX-ID option present, it is over-written with the new value.
</t>
<t>
<figure><artwork>
TCP CLIENT proxy, NAT64, NAT44 TCP SERVER
---------- ------------------- ----------
| | |
|---TCP SYN------>| |
| |---TCP SYN, CX-ID=1.2.3.4-->|
| |<--TCP SYNACK---------------|
|<--TCP SYNACK----| |
|---TCP ACK------>| |
| |---TCP ACK----------------->|
| | |
... ... ...
</artwork></figure>
</t>
</section>
<section title='Operation of the TCP Server'>
<t>
</t>
<t>
The TCP server identifies the client by combining the source IPv4 address in the IP header with the data in the CX-ID option. This can be implemented by modifying the TCP stack to record the CX-ID information when the TCP SYN is received, and providing that information to the application via an API.
</t>
</section></section>
<section title='Option format'>
<t>
With the CX-ID option, the client's 64-bit identifier is the TCP option payload. This can contain the TCP client's internal IPv4 address, or other identifier that reliably identifies that subscriber's traffic, such as a combination of internal VLAN ID + internal IPv4 address, or the IPv6 tunnel ID.
</t>
<t>
<figure><artwork>
+--------+--------+---------...-------------+
|xxxxxxxx|00001010| TCP client identifier |
+--------+--------+---------...-------------+
Kind=(to be IANA assigned) Length=variable, up to 10
</artwork></figure>
</t>
<t>
If this option is present, it communicates the internal identity of the TCP which sends this segment. This field MUST only be sent in the initial connection request (i.e., in segments with the SYN control bit set).
</t>
</section>
<section title='Interaction with TCP SYN Cookies'>
<t>
TCP SYN cookies are commonly deployed to mitigate TCP SYN attacks <xref target="RFC4987">RFC4987</xref>. The mechanism described in this document requires the server store extra information which arrives on the TCP SYN, which increases the TCP server's attack surface.
</t>
<t>
To mitigate this, the authors have considered sending the CX-ID on the first ACK packet, if the TCP server sends CX-ID in the SYNACK.
</t>
<t>
<figure><artwork>
TCP CLIENT proxy, NAT64, NAT44 TCP SERVER
---------- ------------------- ----------
| | |
|---TCP SYN------>| |
| |---TCP SYN, Cx-ID=1.2.3.4-->|
| |<--TCP SYNACK, CX-ID=0------|
|<--TCP SYNACK----| |
|---TCP ACK------>| |
| |---TCP ACK, CX-ID=1.2.3.4-->|
| | |
... ... ...
</artwork></figure>
</t>
<t>
Another idea is to use on option value with no payload (length=2), in the SYN, to merely indicate "I can do CX", which is echoed by a supporting server. The internal identifier itself is then sent in the first ACK:
</t>
<t>
<figure><artwork>
TCP CLIENT proxy, NAT64, NAT44 TCP SERVER
---------- ------------------- ----------
| | |
|---TCP SYN------>| |
| |---TCP SYN, CX-ID, len=2----->|
| |<--TCP SYNACK, CX-ID, len=2--|
|<--TCP SYNACK----| |
|---TCP ACK------>| |
| |---TCP ACK, CX-ID=1.2.3.4-->|
| | |
... ... ...
</artwork></figure>
</t>
<t>
This idea is still under evaluation.
</t>
</section>
<section title='Security Considerations'>
<t>
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 might use this functionality to appear as if IP address sharing is occuring, 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>
<t>
The addition of this TCP option will break TCP-AO <xref target="RFC5925">RFC5925</xref>, which provides integrity protection of the TCP SYN (including TCP options). However, TCP-AO is already known to not survive address sharing (through a NAPT or through an application proxy).
</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, CX-ID.
</t>
<t>
</t></section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc5925;
</references>
<references title="Informative References">
&rfc4987;
&I-D.ietf-intarea-shared-addressing-issues;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 13:09:07 |