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 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. Terminology
• 3. Description
• 3.1. Operation of Address Sharing Device
• 3.2. Encoding the information into the ICMP Echo Request
• 3.3. Operation of the TCP Server
• 4. Interaction with the transport layer protocols
• 4.1. Upstream NATs and Load Balancers
• 5. Interaction with TCP SYN Cookies
• 6. Security Considerations
• 7. Acknowledgements
• 8. IANA Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Appendix A. Change History
• Author's Address

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

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----------->|
       |                         |                     |

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 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

9.2. Informative References

Appendix A. Change History

[Note to RFC Editor: Please remove this section prior to publication.]

Author's Address