Internet DRAFT - draft-yourtchenko-fmc-nat-reveal-ping
draft-yourtchenko-fmc-nat-reveal-ping
Network Working Group A. Yourtchenko
Internet-Draft cisco
Intended status: Experimental July 03, 2013
Expires: January 04, 2014
Revealing hosts sharing an IP address using ICMP Echo Request
draft-yourtchenko-fmc-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 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.
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 January 04, 2014.
Copyright Notice
Copyright (c) 2013 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 January 04, 2014 [Page 1]
Internet-Draft User Hint via ICMP ping July 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Operation of Address Sharing Device . . . . . . . . . . . 3
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 . . . . . . . 4
4.1. Upstream NATs and Load Balancers . . . . . . . . . . . . 4
5. Interaction with TCP SYN Cookies . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
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.
2. Terminology
Yourtchenko Expires January 04, 2014 [Page 2]
Internet-Draft User Hint via ICMP ping July 2013
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
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----------->|
| | |
Yourtchenko Expires January 04, 2014 [Page 3]
Internet-Draft User Hint via ICMP ping July 2013
3.2. Encoding the information into the ICMP Echo Request
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.
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
multiple scenarios of implementing the server-side handling.
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
Yourtchenko Expires January 04, 2014 [Page 4]
Internet-Draft User Hint via ICMP ping July 2013
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
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.
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-03 (work in
progress), July 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-03 (work in progress), December 2011.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007.
Appendix A. Change History
Yourtchenko Expires January 04, 2014 [Page 5]
Internet-Draft User Hint via ICMP ping July 2013
[Note to RFC Editor: Please remove this section prior to
publication.]
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 January 04, 2014 [Page 6]
