Internet DRAFT - draft-wing-nat-reveal-option
draft-wing-nat-reveal-option
Network Working Group A. Yourtchenko
Internet-Draft D. Wing
Intended status: Standards Track cisco
Expires: June 10, 2012 December 8, 2011
Revealing hosts sharing an IP address using TCP option
draft-wing-nat-reveal-option-03
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 clients sharing an IP address. The proposed method
uses a TCP option, which avoids altering the application-level
payload and works well with SSL-protected connections.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 10, 2012.
Copyright Notice
Copyright (c) 2011 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
Yourtchenko & Wing Expires June 10, 2012 [Page 1]
Internet-Draft User Hint via TCP option December 2011
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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Operation of Address Sharing Device . . . . . . . . . . . . 4
3.2. Operation of the TCP Server . . . . . . . . . . . . . . . . 4
3.3. Reusing the USER_HINT value . . . . . . . . . . . . . . . . 4
4. USER_HINT Option Format . . . . . . . . . . . . . . . . . . . . 5
5. Interaction with other TCP Options . . . . . . . . . . . . . . 5
5.1. Option Space . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . . 6
5.3. Authentication Option (TCP-AO) . . . . . . . . . . . . . . 6
6. Interaction with TCP SYN Cookies . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 9
A.1. Changes from draft-wing-nat-reveal-option-01 to -02 . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Yourtchenko & Wing Expires June 10, 2012 [Page 2]
Internet-Draft User Hint via TCP option December 2011
1. Introduction
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
[I-D.ietf-intarea-shared-addressing-issues].
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.
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.
This document describes a TCP option which can be added by an address
sharing device such as a NAT or an application-level proxy. This TCP
option allows a TCP server to differentiate between the TCP clients
sharing that IP address.
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,
Yourtchenko & Wing Expires June 10, 2012 [Page 3]
Internet-Draft User Hint via TCP option December 2011
a small-medium business Internet connection, a University dormitory
room, an individual employee of a company, or the company itself.
3. Description
This proposal defines one new TCP option, USER_HINT, to contain the
TCP client's 16 bit identifier. This value might be the lower 16
bits of their IPv4 address, their VLAN ID, VRF ID, subscriber ID, or
similar. The address sharing device (NAT, application proxy) would
add the TCP option to the TCP SYN packet. 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 USER_HINT option into the TCP
SYN, as depicted below. If the TCP SYN already has a USER_HINT
option present, it is ignored and over-written with the new value.
TCP CLIENT proxy, NAT64, NAT44 TCP SERVER
---------- ------------------- ----------
| | |
|---TCP SYN------>| |
| |---TCP SYN, USER_HINT=12345-->|
... ... ...
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 USER_HINT option. This
can be implemented by modifying the TCP stack to make the USER_HINT
data available to the application via an API (e.g., via a socket
option).
3.3. Reusing the USER_HINT value
The USER_HINT value is only 16 bits, so is obviously not globally
unique. Even when combined with the publicly-routable IP address,
the additional 16 bits are still not guaranteed to uniquely identify
a particular subscriber. Out of necessity, the numbering space will
be re-used by some address sharing devices, especially address
sharing devices that are sharing many users on one IP address. As
with today's IPv4 addresses which are assigned by an ISP,
deterministically associating the IPv4 address (or IPv4 address and
USER_HINT) with a particular subscriber requires more than simply
completing a TCP 3-way handshake. For example, over a single day, an
address sharing device might serve tens of thousands of different
Yourtchenko & Wing Expires June 10, 2012 [Page 4]
Internet-Draft User Hint via TCP option December 2011
subscribers from the same shared IP address, and thus it will need to
rotate through the 16 bit USER_HINT space several times during the
day. When doing so, the USER_HINT MUST NOT be re-used more often
than every 2 minutes (a number chosen out of thin air); if an address
sharing device needs to re-use a USER_HINT value more often than
that, it should use additional IP addresses (to reduce how quickly
the USER_HINT space is consumed on each address) or simply send TCP
SYNs without USER_HINT until 2 minutes have elapsed. This 2 minute
delay is necessary to allow the reputation system on a TCP server to
differentiate between subscribers. For most implementations, the
port sharing ratio (rather than a timer) is sufficient to meet this
requirement.
4. USER_HINT Option Format
The USER_HINT option is always 4 bytes long, with 16 bits of
USER_HINT data
+--------+--------+-----------------------+
|xxxxxxxx|00000100| USER_HINT data |
+--------+--------+-----------------------+
Kind=TBD Length=4
User Hint option data: 16 bits.
If this option is present, it differentiates between active TCP hosts
sharing the same IP address. This field MUST only be sent in the
initial connection request (i.e., in segments with the SYN control
bit set), or in the first ACK if the server's SYN contained the
USER_HINT option.
5. Interaction with other TCP Options
This section details how USER_HINT functions in conjunction with
other TCP options.
5.1. Option Space
As discussed in Appendix A of Multipath TCP (MPTCP)
[I-D.ietf-mptcp-multiaddressed], there is a maximum of 40 bytes for
TCP options, and a typical SYN (with MSS, window scale, SACK
permitted, and timestamp options) leaves 16 bytes spare (if the
options are word-aligned) or 21 bytes spare (if the options are not
word-aligned).
Thus, the 4 byte option proposed in this memo would not cause a
Yourtchenko & Wing Expires June 10, 2012 [Page 5]
Internet-Draft User Hint via TCP option December 2011
problem with a typical TCP SYN.
5.2. Multipath TCP (MPTCP)
If the TCP client supports Multipath TCP (MPTCP)
[I-D.ietf-mptcp-multiaddressed], the client will include the
Multipath Capable or Multipath Join options to the TCP SYN. The
Multipath Capable (MP_CAPABLE) option consumes 12 bytes, so a SYN
containing all of these options would fully consume the 40 byte SYN
option space. The Multipath Join (MP_JOIN) can consumes 12 or 16
bytes, but it is only used after successful early exchange containing
the MP_CAPABLE option. Thus, there is reason to include USER_HINT if
MP_JOIN is present in the TCP SYN -- if the MP_JOIN is not valid, it
will be rejected by the server without creating any state on the
server. Furthermore, if a client TCP is multi-homed, the client's
TCP connections will probably go through different address sharing
devices and thus have different externally-visible IP addresses and
different USER_HINT values. Thus, it is NOT RECOMMENDED to include
the USER_HINT option if the TCP SYN contains the MP_JOIN option.
5.3. Authentication Option (TCP-AO)
The USER_HINT option is incompatible with the Authentication Option
(TCP-AO) [RFC5925], 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.
6. Interaction with TCP SYN Cookies
TCP SYN cookies [RFC4987] are commonly deployed to mitigate TCP SYN
attacks, which have some side effects. The USER_HINT information in
the TCP SYN provides the TCP server with additional information it
can use when deciding if this TCP connection attempt should be
answered with a SYN cookie or should be answered normally. In the
event the TCP server does not (or cannot) store the USER_HINT data,
the USER_HINT data can be re-established on the TCP server when the
client's first ACK is sent. There is a slight risk, however, that
the client's first ACK, as seen by the middlebox, might contain data.
If it does contain data, adding another 4 bytes to the packet could
cause MTU to be exceeded.
Yourtchenko & Wing Expires June 10, 2012 [Page 6]
Internet-Draft User Hint via TCP option December 2011
TCP CLIENT proxy, NAT64, NAT44 TCP SERVER
---------- ------------------- ----------
| | |
|---TCP SYN----------->| |
1. | |---TCP SYN, USER_HINT=12345-->|
2. | |<--TCP SYNACK, USER_HINT=8988-|
3. |<--TCP SYNACK---------| |
: : :
4a. |---TCP ACK (no data)->| |
4a. | |---TCP ACK, USER_HINT=8988--->|
| | |
: : :
4b. |---TCP ACK (data)---->| |
4b. | |---TCP ACK------------------->|
The procedure is as follows:
1. Upon receiving a TCP SYN containing the USER_HINT option, the TCP
server MAY respond to a SYN containing USER_HINT with an ACK
packet containing its own USER_HINT value. (Note: this ACK
response will typically have the SYN bit set.) If the server
does not include the USER_HINT in its ACK packet, processing
stops.
2. The middlebox, upon seeing the USER_HINT in the ACK, records
those 2 bytes, which are used in a later step.
3. The middlebox strips the USER_HINT from the ACK, so it is not
received by the TCP client. The middlebox sends the TCP ACK,
without its USER_HINT option, to the TCP client.
4. The TCP client responds normally, generating a TCP ACK.
5. The middlebox receives an ACK from the TCP client. This ACK will
either contain:
A. no data, which causes the middlebox to add the USER_HINT
value (from step 2) to the TCP ACK
B. data, which causes the middlebox to simply forward the ACK
packet. This is done to avoid MTU problems between the
middlebox and the TCP server.
Yourtchenko & Wing Expires June 10, 2012 [Page 7]
Internet-Draft User Hint via TCP option December 2011
State is required in the address sharing device to perform the steps
described in this section. This isn't a disaster with stateful
address sharing (e.g., NAPT). However, in an A+P-like system (e.g.,
[I-D.ymbk-aplusp], [I-D.despres-intarea-4rd]), the CPE would need to
perform the USER_HINT function, which introduces additional security
considerations (not yet discussed in this version of the document).
7. 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.
8. Acknowledgements
Thanks to Anantha Ramaiah for the discussion. Thanks to Senthil
Sivakumar for his review.
9. IANA Considerations
Assign a new TCP option number (kind value), USER_HINT.
10. References
10.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.
10.2. Informative References
[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]
Yourtchenko & Wing Expires June 10, 2012 [Page 8]
Internet-Draft User Hint via TCP option December 2011
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.
[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.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.]
A.1. Changes from draft-wing-nat-reveal-option-01 to -02
o Limit option value to 16 bits (which becomes 32 bits total with
the 8 bit option number and 8 bit length)
o described how USER_HINT can work successfully with Multipath TCP
(MPTCP)'s options.
o Better described operation with TCP SYN Cookies.
o Renamed option from CX-ID to USER_HINT
Yourtchenko & Wing Expires June 10, 2012 [Page 9]
Internet-Draft User Hint via TCP option December 2011
Authors' Addresses
Andrew Yourtchenko
Cisco Systems, Inc.
6a de Kleetlaan
Diegem 1831
BE
Phone: +32 2 704 5494
Email: ayourtch@cisco.com
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose CA 95134
USA
Email: dwing@cisco.com
Yourtchenko & Wing Expires June 10, 2012 [Page 10]
