idnits 2.17.1 draft-wing-nat-reveal-option-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (June 15, 2011) is 4699 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-boucadair-intarea-nat-reveal-analysis-03 == Outdated reference: A later version (-12) exists of draft-ietf-mptcp-multiaddressed-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Yourtchenko 3 Internet-Draft D. Wing 4 Intended status: Standards Track cisco 5 Expires: December 17, 2011 June 15, 2011 7 Revealing hosts sharing an IP address using TCP option 8 draft-wing-nat-reveal-option-02 10 Abstract 12 When an IP address is shared among several subscribers -- with a NAT 13 or with an application-level proxy -- it is impossible for the server 14 to differentiate between different clients. Such differentiation is 15 valuable in several scenarios. This memo describes a technique to 16 differentiate TCP clients sharing an IP address. The proposed method 17 uses a TCP option, which avoids altering the application-level 18 payload and works well with SSL-protected connections. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 17, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Operation of Address Sharing Device . . . . . . . . . . . . 4 58 3.2. Operation of the TCP Server . . . . . . . . . . . . . . . . 4 59 3.3. Reusing the USER_HINT value . . . . . . . . . . . . . . . . 4 60 4. USER_HINT Option Format . . . . . . . . . . . . . . . . . . . . 5 61 5. Interaction with other TCP Options . . . . . . . . . . . . . . 5 62 5.1. Option Space . . . . . . . . . . . . . . . . . . . . . . . 5 63 5.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . . 6 64 5.3. Authentication Option (TCP-AO) . . . . . . . . . . . . . . 6 65 6. Interaction with TCP SYN Cookies . . . . . . . . . . . . . . . 6 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 9 73 A.1. Changes from draft-wing-nat-reveal-option-01 to -02 . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 When clients are allocated unique, publicly-routable IPv4 addresses, 79 it is easy to associate certain characteristics with their IP 80 address. For example, if an IP address sends a lot of spam, that IP 81 address is classified by many public (and private) system as "a 82 spammer". Such classification can cause email or other traffic from 83 that IP address to be blocked, rate limited, challenged with a 84 captcha, or to receive other treatment. Reputation systems of 85 various sorts exist for a wide variety of services on the Internet 86 including IMAP, HTTP, ssh -- often these systems will slow down or 87 interfere with normal login attempts when a dictionary attack is 88 detected. An IP address can be added to a multitude of 'reputation' 89 systems. Some of these systems are distributed across the Internet, 90 some are shared amongst consenting parties, and some are operated by 91 individual enterprises or individual hosts. Further discussion of 92 the impacts of address sharing can be found in 93 [I-D.ietf-intarea-shared-addressing-issues]. 95 With the exhaustion of the IPv4 address space, IPv4 addresses will be 96 shared on a large scale. This sharing will persist long after IPv6 97 is ubiquitous -- in fact, IPv4 address sharing will persist until all 98 content and services on the Internet are available over IPv6. Once 99 all content and services are available over IPv6, an Internet service 100 provider will no longer need to provide access to the IPv4 Internet. 102 Until that time, both legitimate users and attackers will share IPv4 103 addresses. This IP address sharing means legitimate users will share 104 the reputation of attackers. 106 This document describes a TCP option which can be added by an address 107 sharing device such as a NAT or an application-level proxy. This TCP 108 option allows a TCP server to differentiate between the TCP clients 109 sharing that IP address. 111 An analysis of other techniques is available in 112 [I-D.boucadair-intarea-nat-reveal-analysis]. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC2119 [RFC2119]. 120 subscriber: the client accessing an address sharing device, who is 121 responsible for the actions of their device(s). This might be an 122 individual handset (with mobile devices), a home Internet connection, 123 a small-medium business Internet connection, a University dormitory 124 room, an individual employee of a company, or the company itself. 126 3. Description 128 This proposal defines one new TCP option, USER_HINT, to contain the 129 TCP client's 16 bit identifier. This value might be the lower 16 130 bits of their IPv4 address, their VLAN ID, VRF ID, subscriber ID, or 131 similar. The address sharing device (NAT, application proxy) would 132 add the TCP option to the TCP SYN packet. TCP options are treated 133 outside of the TCP sequence space, so no modifications of either 134 sequence or acknowledgement numbers are needed. 136 3.1. Operation of Address Sharing Device 138 The address sharing device inserts the USER_HINT option into the TCP 139 SYN, as depicted below. If the TCP SYN already has a USER_HINT 140 option present, it is ignored and over-written with the new value. 142 TCP CLIENT proxy, NAT64, NAT44 TCP SERVER 143 ---------- ------------------- ---------- 144 | | | 145 |---TCP SYN------>| | 146 | |---TCP SYN, USER_HINT=12345-->| 147 ... ... ... 149 3.2. Operation of the TCP Server 151 The TCP server identifies the client by combining the source IPv4 152 address in the IP header with the data in the USER_HINT option. This 153 can be implemented by modifying the TCP stack to make the USER_HINT 154 data available to the application via an API (e.g., via a socket 155 option). 157 3.3. Reusing the USER_HINT value 159 The USER_HINT value is only 16 bits, so is obviously not globally 160 unique. Even when combined with the publicly-routable IP address, 161 the additional 16 bits are still not guaranteed to uniquely identify 162 a particular subscriber. Out of necessity, the numbering space will 163 be re-used by some address sharing devices, especially address 164 sharing devices that are sharing many users on one IP address. As 165 with today's IPv4 addresses which are assigned by an ISP, 166 deterministically associating the IPv4 address (or IPv4 address and 167 USER_HINT) with a particular subscriber requires more than simply 168 completing a TCP 3-way handshake. For example, over a single day, an 169 address sharing device might serve tens of thousands of different 170 subscribers from the same shared IP address, and thus it will need to 171 rotate through the 16 bit USER_HINT space several times during the 172 day. When doing so, the USER_HINT MUST NOT be re-used more often 173 than every 2 minutes (a number chosen out of thin air); if an address 174 sharing device needs to re-use a USER_HINT value more often than 175 that, it should use additional IP addresses (to reduce how quickly 176 the USER_HINT space is consumed on each address) or simply send TCP 177 SYNs without USER_HINT until 2 minutes have elapsed. This 2 minute 178 delay is necessary to allow the reputation system on a TCP server to 179 differentiate between subscribers. For most implementations, the 180 port sharing ratio (rather than a timer) is sufficient to meet this 181 requirement. 183 4. USER_HINT Option Format 185 The USER_HINT option is always 4 bytes long, with 16 bits of 186 USER_HINT data 188 +--------+--------+-----------------------+ 189 |xxxxxxxx|00000100| USER_HINT data | 190 +--------+--------+-----------------------+ 191 Kind=TBD Length=4 193 User Hint option data: 16 bits. 195 If this option is present, it differentiates between active TCP hosts 196 sharing the same IP address. This field MUST only be sent in the 197 initial connection request (i.e., in segments with the SYN control 198 bit set), or in the first ACK if the server's SYN contained the 199 USER_HINT option. 201 5. Interaction with other TCP Options 203 This section details how USER_HINT functions in conjunction with 204 other TCP options. 206 5.1. Option Space 208 As discussed in Appendix A of Multipath TCP (MPTCP) 209 [I-D.ietf-mptcp-multiaddressed], there is a maximum of 40 bytes for 210 TCP options, and a typical SYN (with MSS, window scale, SACK 211 permitted, and timestamp options) leaves 16 bytes spare (if the 212 options are word-aligned) or 21 bytes spare (if the options are not 213 word-aligned). 215 Thus, the 4 byte option proposed in this memo would not cause a 216 problem with a typical TCP SYN. 218 5.2. Multipath TCP (MPTCP) 220 If the TCP client supports Multipath TCP (MPTCP) 221 [I-D.ietf-mptcp-multiaddressed], the client will include the 222 Multipath Capable or Multipath Join options to the TCP SYN. The 223 Multipath Capable (MP_CAPABLE) option consumes 12 bytes, so a SYN 224 containing all of these options would fully consume the 40 byte SYN 225 option space. The Multipath Join (MP_JOIN) can consumes 12 or 16 226 bytes, but it is only used after successful early exchange containing 227 the MP_CAPABLE option. Thus, there is reason to include USER_HINT if 228 MP_JOIN is present in the TCP SYN -- if the MP_JOIN is not valid, it 229 will be rejected by the server without creating any state on the 230 server. Furthermore, if a client TCP is multi-homed, the client's 231 TCP connections will probably go through different address sharing 232 devices and thus have different externally-visible IP addresses and 233 different USER_HINT values. Thus, it is NOT RECOMMENDED to include 234 the USER_HINT option if the TCP SYN contains the MP_JOIN option. 236 5.3. Authentication Option (TCP-AO) 238 The USER_HINT option is incompatible with the Authentication Option 239 (TCP-AO) [RFC5925], because TCP-AO provides integrity protection of 240 the TCP SYN, including TCP options. However, TCP-AO is already 241 incompatible with address sharing, because TCP-AO provides integrity 242 protection of the source IP address. 244 6. Interaction with TCP SYN Cookies 246 TCP SYN cookies [RFC4987] are commonly deployed to mitigate TCP SYN 247 attacks, which have some side effects. The USER_HINT information in 248 the TCP SYN provides the TCP server with additional information it 249 can use when deciding if this TCP connection attempt should be 250 answered with a SYN cookie or should be answered normally. In the 251 event the TCP server does not (or cannot) store the USER_HINT data, 252 the USER_HINT data can be re-established on the TCP server when the 253 client's first ACK is sent. There is a slight risk, however, that 254 the client's first ACK, as seen by the middlebox, might contain data. 255 If it does contain data, adding another 4 bytes to the packet could 256 cause MTU to be exceeded. 258 TCP CLIENT proxy, NAT64, NAT44 TCP SERVER 259 ---------- ------------------- ---------- 260 | | | 261 |---TCP SYN----------->| | 262 1. | |---TCP SYN, USER_HINT=12345-->| 263 2. | |<--TCP SYNACK, USER_HINT=8988-| 264 3. |<--TCP SYNACK---------| | 266 : : : 268 4a. |---TCP ACK (no data)->| | 269 4a. | |---TCP ACK, USER_HINT=8988--->| 270 | | | 272 : : : 274 4b. |---TCP ACK (data)---->| | 275 4b. | |---TCP ACK------------------->| 277 The procedure is as follows: 279 1. Upon receiving a TCP SYN containing the USER_HINT option, the TCP 280 server MAY respond to a SYN containing USER_HINT with an ACK 281 packet containing its own USER_HINT value. (Note: this ACK 282 response will typically have the SYN bit set.) If the server 283 does not include the USER_HINT in its ACK packet, processing 284 stops. 286 2. The middlebox, upon seeing the USER_HINT in the ACK, records 287 those 2 bytes, which are used in a later step. 289 3. The middlebox strips the USER_HINT from the ACK, so it is not 290 received by the TCP client. The middlebox sends the TCP ACK, 291 without its USER_HINT option, to the TCP client. 293 4. The TCP client responds normally, generating a TCP ACK. 295 5. The middlebox receives an ACK from the TCP client. This ACK will 296 either contain: 298 A. no data, which causes the middlebox to add the USER_HINT 299 value (from step 2) to the TCP ACK 301 B. data, which causes the middlebox to simply forward the ACK 302 packet. This is done to avoid MTU problems between the 303 middlebox and the TCP server. 305 State is required in the address sharing device to perform the steps 306 described in this section. This isn't a disaster with stateful 307 address sharing (e.g., NAPT). However, in an A+P-like system (e.g., 308 [I-D.ymbk-aplusp], [I-D.despres-intarea-4rd]), the CPE would need to 309 perform the USER_HINT function, which introduces additional security 310 considerations (not yet discussed in this version of the document). 312 7. Security Considerations 314 An attacker might use this functionality to appear as if IP address 315 sharing is occurring, in the hopes that a naive server will allow 316 additional attack traffic. TCP servers and applications SHOULD NOT 317 assume the mere presence of the functionality described in this paper 318 indicates there are other (benign) users sharing the same IP address. 320 8. Acknowledgements 322 Thanks to Anantha Ramaiah for the discussion. Thanks to Senthil 323 Sivakumar for his review. 325 9. IANA Considerations 327 Assign a new TCP option number (kind value), USER_HINT. 329 10. References 331 10.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, March 1997. 336 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 337 Authentication Option", RFC 5925, June 2010. 339 10.2. Informative References 341 [I-D.boucadair-intarea-nat-reveal-analysis] 342 Boucadair, M., Touch, J., Levis, P., and R. Penno, 343 "Analysis of Solution Candidates to Reveal a Host 344 Identifier in Shared Address Deployments", 345 draft-boucadair-intarea-nat-reveal-analysis-03 (work in 346 progress), June 2011. 348 [I-D.despres-intarea-4rd] 349 Despres, R., Matsushima, S., Murakami, T., and O. Troan, 350 "IPv4 Residual Deployment across IPv6-Service networks 351 (4rd) ISP-NAT's made optional", 352 draft-despres-intarea-4rd-01 (work in progress), 353 March 2011. 355 [I-D.ietf-intarea-shared-addressing-issues] 356 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 357 Roberts, "Issues with IP Address Sharing", 358 draft-ietf-intarea-shared-addressing-issues-05 (work in 359 progress), March 2011. 361 [I-D.ietf-mptcp-multiaddressed] 362 Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 363 "TCP Extensions for Multipath Operation with Multiple 364 Addresses", draft-ietf-mptcp-multiaddressed-03 (work in 365 progress), March 2011. 367 [I-D.ymbk-aplusp] 368 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 369 draft-ymbk-aplusp-10 (work in progress), May 2011. 371 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 372 Mitigations", RFC 4987, August 2007. 374 Appendix A. Change History 376 [Note to RFC Editor: Please remove this section prior to 377 publication.] 379 A.1. Changes from draft-wing-nat-reveal-option-01 to -02 381 o Limit option value to 16 bits (which becomes 32 bits total with 382 the 8 bit option number and 8 bit length) 384 o described how USER_HINT can work successfully with Multipath TCP 385 (MPTCP)'s options. 387 o Better described operation with TCP SYN Cookies. 389 o Renamed option from CX-ID to USER_HINT 391 Authors' Addresses 393 Andrew Yourtchenko 394 Cisco Systems, Inc. 395 6a de Kleetlaan 396 Diegem 1831 397 BE 399 Phone: +32 2 704 5494 400 Email: ayourtch@cisco.com 402 Dan Wing 403 Cisco Systems, Inc. 404 170 West Tasman Drive 405 San Jose CA 95134 406 USA 408 Email: dwing@cisco.com