Internet DRAFT - draft-yourtchenko-nat-reveal-ping
draft-yourtchenko-nat-reveal-ping
Network Working Group A. Yourtchenko
Internet-Draft cisco
Intended status: Standards Track March 5, 2012
Expires: September 6, 2012
Revealing hosts sharing an IP address using ICMP Echo Request
draft-yourtchenko-nat-reveal-ping-00
Abstract
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 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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2012.
Copyright Notice
Copyright (c) 2012 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
Yourtchenko Expires September 6, 2012 [Page 1]
Internet-Draft User Hint via ICMP ping March 2012
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Operation of Address Sharing Device . . . . . . . . . . . . 4
3.2. Encoding the information into the ICMP Echo Request . . . . 4
3.3. Operation of the TCP Server . . . . . . . . . . . . . . . . 4
4. Interaction with the transport layer protocols . . . . . . . . 5
4.1. Upstream NATs and Load Balancers . . . . . . . . . . . . . 5
5. Interaction with TCP SYN Cookies . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Yourtchenko Expires September 6, 2012 [Page 2]
Internet-Draft User Hint via ICMP ping March 2012
1. Introduction
The transport-layer proposal mentioned in
[I-D.wing-nat-reveal-option] 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.
Another potential problem is blocking of the new TCP option by the
middleboxes, which, as [I-D.abdo-hostid-tcpopt-implementation] shows
a noticeable failure rate of 2.6%
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. 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.
An analysis of other techniques is available in
[I-D.boucadair-intarea-nat-reveal-analysis].
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 [RFC2119].
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.
3. Description
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.
The transactional nature of the ICMP Echo/Echo Reply sequence allows
Yourtchenko Expires September 6, 2012 [Page 3]
Internet-Draft User Hint via ICMP ping March 2012
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.
3.1. Operation of Address Sharing Device
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.
The source of the ICMP Echo Reply MAY be a separate address on the
address-sharing device, dedicated to these ICMP exchanges.
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----------->|
| | |
3.2. Encoding the information into the ICMP Echo Request
A strawman proposal is to use the payload within the Echo Request
similar in format to the one described in
[I-D.shen-traceroute-ping-ext], with a different magic number. This
has the advantage of reusing the code and allowing for some forms of
authentication of the NAT devices.
3.3. Operation of the TCP Server
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.
Note that the out-of-band nature of the proposed signaling allowes
Yourtchenko Expires September 6, 2012 [Page 4]
Internet-Draft User Hint via ICMP ping March 2012
multiple scenarios of implementing the server-side handling. An
early prototype implementation is in progress using libipq on Linux,
which would delay the inbound SYN segments for a configurable
interval, in the hope that the ICMP Echo Request with the translation
details arrives shortly.
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.
4. Interaction with the transport layer protocols
This section discusses the pros and cons of using a separate channel
to discriminate the internal 5-tuples.
4.1. Upstream NATs and Load Balancers
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.
However, the extra address translator north of CGN-style one is
rather unlikely.
5. Interaction with TCP SYN Cookies
TCP SYN cookies [RFC4987] 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.
6. Security Considerations
An attacker might use this functionality to appear as if IP address
sharing is occurring, in the hopes that a naive server will allow
Yourtchenko Expires September 6, 2012 [Page 5]
Internet-Draft User Hint via ICMP ping March 2012
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.
7. Acknowledgements
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.
8. IANA Considerations
None.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
9.2. Informative References
[I-D.abdo-hostid-tcpopt-implementation]
Abdo, E., Boucadair, M., and J. Queiroz, "HOST_ID TCP
Options: Implementation & Preliminary Test Results",
draft-abdo-hostid-tcpopt-implementation-02 (work in
progress), January 2012.
[I-D.boucadair-intarea-nat-reveal-analysis]
Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Solution Candidates to Reveal a Host
Identifier in Shared Address Deployments",
draft-boucadair-intarea-nat-reveal-analysis-04 (work in
progress), September 2011.
[I-D.despres-intarea-4rd]
Despres, R., Matsushima, S., Murakami, T., and O. Troan,
"IPv4 Residual Deployment across IPv6-Service networks
(4rd) ISP-NAT's made optional",
draft-despres-intarea-4rd-01 (work in progress),
March 2011.
Yourtchenko Expires September 6, 2012 [Page 6]
Internet-Draft User Hint via ICMP ping March 2012
[I-D.ietf-intarea-shared-addressing-issues]
Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing",
draft-ietf-intarea-shared-addressing-issues-05 (work in
progress), March 2011.
[I-D.ietf-mptcp-multiaddressed]
Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", draft-ietf-mptcp-multiaddressed-04 (work in
progress), July 2011.
[I-D.shen-traceroute-ping-ext]
Shen, N., Pignataro, C., Asati, R., Chen, E., and A.
Atlas, "Traceroute and Ping Message Extension",
draft-shen-traceroute-ping-ext-04 (work in progress),
February 2012.
[I-D.wing-nat-reveal-option]
Yourtchenko, A. and D. Wing, "Revealing hosts sharing an
IP address using TCP option",
draft-wing-nat-reveal-option-02 (work in progress),
June 2011.
[I-D.ymbk-aplusp]
Bush, R., "The A+P Approach to the IPv4 Address Shortage",
draft-ymbk-aplusp-10 (work in progress), May 2011.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007.
Appendix A. Change History
[Note to RFC Editor: Please remove this section prior to
publication.]
Yourtchenko Expires September 6, 2012 [Page 7]
Internet-Draft User Hint via ICMP ping March 2012
Author's Address
Andrew Yourtchenko
Cisco Systems, Inc.
6a de Kleetlaan
Diegem 1831
BE
Phone: +32 2 704 5494
Email: ayourtch@cisco.com
Yourtchenko Expires September 6, 2012 [Page 8]
