One document matched: draft-yourtchenko-fmc-nat-reveal-ping-00.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 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 rfc4987 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4987.xml">
<!ENTITY I-D.abdo-hostid-tcpopt-implementation SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.abdo-hostid-tcpopt-implementation.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="exp" docName="draft-yourtchenko-fmc-nat-reveal-ping-00"
ipr="trust200902">
<front>
<title abbrev="User Hint via ICMP ping">Revealing hosts sharing an IP
address using ICMP Echo Request</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>
<date year="2013" />
<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 proposes a technique to
differentiate TCP and UDP clients sharing an IP address. The proposed method
uses an ICMP Echo Request packet, which allows for more information
about the user mapping to be transmitted than in the case of using
the TCP option - and allows the use with UDP and other protocols.
</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>The transport-layer proposal mentioned in
<xref target="I-D.wing-nat-reveal-option"></xref> has one drawback:
a relatively small amount of information that can be transmitted.
This is caused by the fact that the TCP option space is very scarce.
</t>
<t>Another potential problem is blocking of the new TCP option by the middleboxes,
which, as <xref target="I-D.abdo-hostid-tcpopt-implementation"></xref> shows
a noticeable failure rate of 2.6%</t>
<t>This document describes a mechanism where the address sharing device
encapsulates the necessary differentiating information into an ICMP Echo Request
packet that it sends in parallel with the initial session creation.
The information included in the ICMP Request Data portion describes
the five-tuples as seen on both of the sides of the translating device.
This allows the server to differentiate different internal addresses.
<!--
(AY: future unrelated strawman - could be used to get rid of ALGs in middleboxes by communicating the addresses ?)
-->
At the same time, since the data travels in ICMP packets, even if
they are blocked on the way, the user connection does not have to block.
<!--
(AY: future strawman: this property can be altered by requiring the ICMP echo reply before letting the SYN through the address sharing device,
thus the SYNSENT timer will act as a distributed retransmit mechanism - therefore allowing to avoid storing the state on the address sharing device.
this approach, not unlike the SYN Cookies, needs further definition/discussion).
-->
</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 suggests to initiate the ICMP Echo Request / Echo Response exchange
with the target for each of the new sessions that are being created.
The data portion of the ICMP Echo Request packet will contain the necessary information
about the connection - internal and external five-tuples, as well as any other
information that the translation device considers useful to share.
</t>
<t>The transactional nature of the ICMP Echo/Echo Reply sequence allows to assert
the fact of the remote server (or ICMP proxy thereof) receiving the information - thus,
this approach allows reliable transfer of translation information to the target.
</t>
<section title="Operation of Address Sharing Device">
<t>Upon the creation of the new address mapping, the address sharing device
initiates the new ICMP exchange with the target. This exchange happens in parallel with
the main connection establishment. In case of not receiving the ICMP Echo Reply,
the address sharing device MUST retransmit the echo requests several (exact value TBD) times with exponential backoff.
</t>
<t>The source of the ICMP Echo Reply MAY be a separate address on the address-sharing device, dedicated to these ICMP exchanges.
</t>
<figure>
<artwork><![CDATA[
TCP client address sharing device TCP server
| | |
|---TCP SYN-------------->| |
| |----TCP SYN--------->|
| |--ICMP Echo Request->|
| |<---TCP SYNACK-------|
|<--TCP SYNACK------------| |
| |<-ICMP Echo Response-|
|---TCP ACK-------------->| |
| |--TCP ACK----------->|
| | |
]]></artwork>
</figure>
</section>
<section title="Encoding the information into the ICMP Echo Request">
<t>A strawman proposal is to use the payload within the Echo Request
formatted in a TLV fashion - in order to be able to differentiate between
"ordinary" echo requests and the echo requests carrying extra information like
the one proposed in this draft.
</t>
</section>
<section title="Operation of the TCP Server">
<t>The TCP server identifies the ICMP Echo Request as a special one by
inspecting the payload and matching the included outside five-tuple with one of
its active connections. After the processing of the Echo Request packet the server sends back the Echo Reply
packet with identical contents.
</t>
<t>Note that the out-of-band nature of the proposed signaling allowes multiple scenarios of implementing the
server-side handling.
</t>
<t>Another implementation could employ some more sophisticated processing - e.g. intercept the SYN segments
only from hosts who according to certain heuristics are misbehaving - thus, avoiding any delay for
the well-behaving hosts.
</t>
</section>
</section>
<section title="Interaction with the transport layer protocols">
<t>This section discusses the pros and cons of using a separate channel to discriminate the internal 5-tuples.
</t>
<section title="Upstream NATs and Load Balancers">
<t>The upstream translators may not understand the contents of the packet,
and might simply translate it as another ping packet exchange.
TBD: the data format needs to provision for detection of this.
This item needs further consideration, specifically how
to cascade the multiple translators in a chain.
</t>
<t>However, the extra address translator north of CGN-style one is rather unlikely.</t>
</section>
<!--
<section title="Multipath TCP (MPTCP)">
</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 ICMP Echo packet containing the 5-tuple mapping information may not match
an existing TCP connection on the server. However, in this case the flow of operation
of neither TCP SYN Cookies nor ICMP Echo Request is disturbed - the host can simply
respond as normal. TBD: one way is for the server to defer sending Echo Reply if there
is no matching connection - this will cause the Address Sharing Device to keep
retransmitting the Echo Request, and if the connection is legitimate, then eventually
the Echo Request will match a newly established connection.
</t>
</section>
<section title="Security Considerations">
<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 Dan Wing for the discussions, the reviews of early versions of the draft, very helpful suggestions on the text and the nice ASCII art.
</t>
</section>
<section title="IANA Considerations">
<t>None.</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.abdo-hostid-tcpopt-implementation;
<?rfc include='reference.I-D.wing-nat-reveal-option'?>
</references>
<section title="Change History">
<t>[Note to RFC Editor: Please remove this section prior to
publication.]</t>
<!--
<section title="Changes from -00 to -01">
<t><list style="symbols">
<t>Some change here</t>
</list></t>
</section>
-->
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:28:43 |