Network Working Group A. Yourtchenko
Internet-Draft D. Wing
Intended status: Standards Track cisco
Expires: February 26, 2011 August 25, 2010
Revealing hosts sharing an IP address using TCP option
draft-wing-nat-reveal-option-00
Abstract
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.
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 February 26, 2011.
Copyright Notice
Copyright (c) 2010 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
Yourtchenko & Wing Expires February 26, 2011 [Page 1]
Internet-Draft Connection Identity via TCP option August 2010
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Operation of Address Sharing Device . . . . . . . . . . . 4
3.2. Operation of the TCP Server . . . . . . . . . . . . . . . . 5
4. Option format . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Interaction with TCP SYN Cookies . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Yourtchenko & Wing Expires February 26, 2011 [Page 2]
Internet-Draft Connection Identity via TCP option August 2010
1. Introduction
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 I-D.ietf-intarea-shared-
addressing-issues [I-D.ietf-intarea-shared-addressing-issues]. IP
address sharing is done by both network address and port translators
(NAPT) and by application-layer proxies (e.g., HTTP or FTP proxies).
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,
o adjustment of TCP sequence numbers and acknowledgement numbers for
the duration of the TCP session
o risk of false-positive application matching (e.g., accidentally
inserting an HTTP header into a non-HTTP payload).
o interference with application payload by increasing packet size
(e.g., MTU)
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:
o 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
o noticeable increase in the processing power required on the
address sharing device to decrypt and re-encrypt that application
payload
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].
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
Yourtchenko & Wing Expires February 26, 2011 [Page 3]
Internet-Draft Connection Identity via TCP option August 2010
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.
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 I-D.ietf-intarea-shared-addressing-issues
[I-D.ietf-intarea-shared-addressing-issues].
2. Notational Conventions
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].
3. Description
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.
3.1. Operation of Address Sharing Device
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.
Yourtchenko & Wing Expires February 26, 2011 [Page 4]
Internet-Draft Connection Identity via TCP option August 2010
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----------------->|
| | |
... ... ...
3.2. Operation of the TCP Server
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.
4. Option format
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.
+--------+--------+---------...-------------+
|xxxxxxxx|00001010| TCP client identifier |
+--------+--------+---------...-------------+
Kind=(to be IANA assigned) Length=variable, up to 10
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).
5. Interaction with TCP SYN Cookies
TCP SYN cookies are commonly deployed to mitigate TCP SYN attacks
RFC4987 [RFC4987]. 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.
Yourtchenko & Wing Expires February 26, 2011 [Page 5]
Internet-Draft Connection Identity via TCP option August 2010
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.
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-->|
| | |
... ... ...
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:
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-->|
| | |
... ... ...
This idea is still under evaluation.
6. Security Considerations
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.
An attacker might might use this functionality to appear as if IP
address sharing is occuring, in the hopes that a naive server will
Yourtchenko & Wing Expires February 26, 2011 [Page 6]
Internet-Draft Connection Identity via TCP option August 2010
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.
The addition of this TCP option will break TCP-AO RFC5925 [RFC5925],
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).
7. Acknowledgements
Thanks to Anantha Ramaiah for the discussion. Thanks to Senthil
Sivakumar for his review.
8. IANA Considerations
Assign a new TCP option number, CX-ID.
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.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-01 (work in
progress), June 2010.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007.
Yourtchenko & Wing Expires February 26, 2011 [Page 7]
Internet-Draft Connection Identity via TCP option August 2010
Authors' Addresses
Andrew Yourtchenko
cisco
6a de Kleetlaan
Diegem 1831
BE
Phone: +32 2 704 5494
Email: ayourtch@cisco.com
Dan Wing
cisco
170 West Tasman Drive
San Jose CA 95134
USA
Email: dwing@cisco.com
Yourtchenko & Wing Expires February 26, 2011 [Page 8]