idnits 2.17.1 draft-boucadair-intarea-nat-reveal-analysis-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 3, 2011) is 4774 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBC' is mentioned on line 319, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-intarea-ipv4-id-update-01 == Outdated reference: A later version (-05) exists of draft-ietf-intarea-shared-addressing-issues-04 == Outdated reference: A later version (-03) exists of draft-wing-nat-reveal-option-01 -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Informational J. Touch 5 Expires: September 4, 2011 USC/ISI 6 P. Levis 7 France Telecom 8 March 3, 2011 10 Analysis of Solution Candidates to Reveal the Origin IP Address in 11 Shared Address Deployments 12 draft-boucadair-intarea-nat-reveal-analysis-00 14 Abstract 16 This document analyzes a set of solution candidates which have been 17 proposed to mitigate some of the issues encountered when address 18 sharing is used. In particular, this document focuses on means to 19 reveal the origin of an IP packet when a Carrier Grade NAT is 20 involved in the path. The ultimate goal is to assess the viability 21 of proposed solutions and hopefully to make a recommendation on the 22 more suitable solution(s). 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 4, 2011. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Problem to Be Solved . . . . . . . . . . . . . . . . . . . 3 65 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Define an IP Option . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Define a TCP Option . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Use of the Identification Field of IP Header (IP-ID) . . . . . 7 73 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7 74 5.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6. Inject Application Headers . . . . . . . . . . . . . . . . . . 8 76 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8 77 6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 7. Enforce a Source-based Selection Algorithm at the Server 79 Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 9 81 7.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 8. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . . . 10 83 8.1. Description . . . . . . . . . . . . . . . . . . . . . . . 10 84 8.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 93 1. Introduction 95 As reported in [I-D.ietf-intarea-shared-addressing-issues], several 96 issues are encountered when an IP address is shared among several 97 subscribers. Examples of such issues are listed below: 99 o Implicit authentication 101 o SPAM 103 o Blacklisting a mis-behaving user 105 o Redirect users with infected machines to a dedicated portal 107 The sole use of the IPv4 address is not sufficient to uniquely 108 distinguish a user. As a mitigation, it is tempting to investigate 109 means which would help in disclosing an information to be used by the 110 remote server as a means to uniquely disambiguate packets of 111 subscribers using the same IPv4 address. 113 The purpose of this document is to analyze the solutions that have 114 been proposed so far and to assess to what extent they solve the 115 problem. 117 Not need to remind that IPv6 is the only perennial solution. 119 Only IPv4-based solutions are analyzed in the following sections: 120 define a new IP option (Section 3), define a new TCP option 121 (Section 4), use the Identification field of IP header (denoted as 122 IP-ID, Section 5), inject application headers (Section 6), use of 123 port set (Section 7) and activate HIP (Section 8). 125 1.1. Problem to Be Solved 127 Observation: Today, servers use the source IPv4 address as an 128 identifier to treat some incoming connections differently. Tomorrow, 129 due to the introduction of CGNs (e.g., NAT44, NAT64), that address 130 will be shared. In particular, when a server receives packets from 131 the same source address. Because this address is shared, the server 132 does not know which host is the sending host. 134 Objective: The server should be able to sort out the packets by 135 sending host. 137 Requirement: The server must have extra information than the source 138 IP address to differentiate the sending host. We call USER_HINT this 139 information. 141 For all solutions analyzed, we provide answers to the following 142 questions: 144 o What is the USER_HINT? It must be unique to each user under the 145 same address. It does not need to be globally unique. Of course, 146 the combination of the (public) IPv4 source address and the 147 identifier ends up being relatively unique. As unique as today's 148 32-bit IPv4 addresses which, today, can change when a user re- 149 connects. 151 o Where is the USER_HINT? (which protocol, which field): If the 152 USER_HINT is put at the IP level, all packets will have to bear 153 the identifier. If it is put at a higher connection-oriented 154 level, the identifier is only needed once in the session 155 establishment phase (for instance TCP three-way-handshake), then, 156 all packets received in this session will be attributed to the 157 host id designated during the session opening. 159 o Who puts the USER_HINT?: For almost all the analyzed solutions, 160 the address sharing function injects the USER_HINT. When there 161 are several address sharing functions in the data path, we 162 describe to what extent the proposed solution is efficient. 164 o What are the security considerations?: Security consideration are 165 common to all analyzed solutions (see Section 10). 167 2. Recommendations 169 The following Table 1 summarizes the approaches analyzed in this 170 document. 172 o "Success ratio" indicates the ratio of successful communications 173 when the option is used. Provided figures are inspired from the 174 results documented in [Options]. 176 o "Deployable today" column indicates if the solution can be 177 generalized without any constraint on current architectures and 178 practices. 180 +---+---+----+---------+-------+----------+----- 181 |UDP|TCP|HTTP|Encrypted|Success|Deployable|Notes 182 | | | | traffic | ratio | today? | 183 -----------+---+---+----+---------+-------+----------+----- 184 IP option |Yes|Yes|Yes | Yes | 30% | Yes | 185 -----------+---+---+----+---------+-------+----------+----- 186 TCP option |No |Yes|Yes | Yes | 99% | Yes | 187 -----------+---+---+----+---------+-------+----------+----- 188 IP-ID |Yes|Yes|Yes | Yes | 100% | Yes | (1) 189 -----------+---+---+----+---------+-------+----------+----- 190 HTTP header|No |No |Yes | No | 100% | Yes | (2) 191 -----------+---+---+----+---------+-------+----------+----- 192 Port set |Yes|Yes|Yes | Yes | 100% | Yes |(1)(3) 193 -----------+---+---+----+---------+-------+----------+----- 194 HIP |-- |-- |-- | -- | Low | No |(4)(5) 195 -----------+---+---+----+---------+-------+----------+------ 197 Table 1: Summary of analyzed solutions. 199 Notes for the above table: 201 (1) requires mechanism to advertise NAT is participating in this 202 scheme (e.g., DNS PTR record) 204 (2) this solution is widely deployed 206 (3) when the port set is not advertised, the solution is less 207 efficient. 209 (4) requires the client and the server to be HIP-compliant and HIP 210 infrastructure to be deployed. 212 (5) if the client and the server are HIP-enabled, the address 213 sharing function does not need to insert a user-hint. If the 214 client is not HIP-enabled, designing the device that performs 215 address sharing to act as a UDP/TCP-HIP relay is not viable. 217 [[Note: Make a recommendation?]] 219 3. Define an IP Option 220 3.1. Description 222 This proposal aims to define an IP option [RFC0791] to convey a "user 223 identifier". This identifier can be inserted by the address sharing 224 function to uniquely distinguish a user among those sharing the same 225 IP address. The option can convey an IPv4 address, the prefix part 226 of an IPv6 address, etc. 228 Another way for using IP option has been described in Section 4.6 of 229 [RFC3022]. 231 3.2. Analysis 233 Unlike the solution presented in Section 4, this proposal can apply 234 for any transport protocol. Nevertheless, it is widely known that 235 routers (and other middle boxes) filter IP options. IP packets with 236 IP options can be dropped by some IP nodes. Previous studies 237 demonstrated that "IP Options are not an option" (Refer to 238 [Not_An_Option], [Options]). 240 As a conclusion, using an IP option to convey a user-hint is not 241 viable. 243 4. Define a TCP Option 245 4.1. Description 247 This proposal [I-D.wing-nat-reveal-option] defines a new TCP option 248 called CX-ID. This option encloses the client's identifier (e.g., an 249 IPv4 address, a subscriber ID, or 64 bits of an IPv6 address). The 250 address sharing device inserts this TCP option to the TCP SYN packet 251 or in the initial ACK. 253 4.2. Analysis 255 The risk related to handling a new TCP option is low as measured in 256 [Options]. Using a new TCP option to convey the user-hint does not 257 require any modification to the applications but it is applicable 258 only for TCP-based applications. Applications relying on other 259 transport protocols are therefore left unsolved. 261 Some downsides have been raised against defining a TCP option to 262 reveal a user identity: 264 o Conveying an IP address in a TCP option may be seen as a violation 265 of OSI layers but since IP addresses are already used for the 266 checksum computation, this is not seen as a blocking point. 268 o TCP option space is limited, and might be consumed by the TCP 269 client. 271 o TCP options are not reliably transmitted. If the first segment is 272 lost and the payload bytes it contained are retransmitted, the 273 retransmitted segment is not required to contain the same options 274 as the lost segment. [I-D.wing-nat-reveal-option] discusses two 275 approaches to sending the USER_HINT: sending the USER_HINT in the 276 TCP SYN (which consumes more bytes in the TCP header of the TCP 277 SYN) and sending the USER_HINT in a TCP ACK (which consumes only 278 two bytes in the TCP SYN). Content providers may find it more 279 desirable to receive the USER_HINT in the TCP SYN, as that more 280 closely preserves the user hint received in the source IP address 281 as per current practices. It is more complicated to implement 282 sending the USER_HINT in a TCP ACK, as it can introduce MTU issues 283 if the ACK packet also contains TCP data, or a TCP segment is 284 lost. 286 o When there are several NATs in the path, the original USER_HINT 287 may be lost. In such case, the procedure may not be efficient. 289 o Interference with current usages such as X-Forwarded-For (see 290 Section 6) should be elaborated to specify the behavior of servers 291 when both options are used; in particular specify which 292 information to use: the content of the TCP option or what is 293 conveyed in the application headers. 295 5. Use of the Identification Field of IP Header (IP-ID) 297 5.1. Description 299 IP-ID (Identification field of IP header) can be used to insert an 300 information which uniquely distinguishes a user among those sharing 301 the same IPv4 address. An address sharing function can re-write the 302 IP-ID field to insert a value unique to the user (16 bits are 303 sufficient to uniquely disambiguate users sharing the same IP 304 address). Note that this field is not altered by some NATs; hence 305 some side effects such as counting hosts behind a NAT as reported in 306 [Count]. 308 A variant of this approach relies upon the format of certain packets, 309 such as TCP SYN, where the IP-ID can be modified to contain a 16 bit 310 user-hint. Address sharing devices performing this function would 311 require to indicate they are performing this function out of band, 312 possibly using a special DNS record. 314 5.2. Analysis 316 This usage is not compliant with what is recommended in 317 [I-D.ietf-intarea-ipv4-id-update]. 319 [TBC]. 321 [[Touch.NOTE: One other problem - picking an ID value here 322 *requires* coordination, i.e., that no other IP packet with this 323 IP address uses that ID within 2MSL. Unless fragmentation is 324 disabled for all packets all the time, you can't use *any* ID 325 value without that coordination.]] 327 [[Wing.NOTE: Most OSes today are emitting TCP packets with DF=1 328 (OSX, Windows XP and 7, Linux, etc.). So, we can assume the TCP 329 SYN is going to have DF=1, and only insert IP-ID if DF=1 and it's 330 a TCP SYN. Doing that, I don't see any disagreement with Joe's 331 IP-ID document.]] 333 6. Inject Application Headers 335 6.1. Description 337 Another option is to not require any change at the transport nor the 338 IP levels but to convey at the application payload the required 339 information which will be used to disambiguate users. This format 340 and the related semantics depend on its application (e.g., HTTP, SIP, 341 SMTP, etc.). 343 For HTTP, the X-Forwarded-For (XFF) header can be used to display the 344 original IP address when an address sharing device is involved. 345 Service Providers operating address sharing devices can enable the 346 feature of injecting the XFF header which will enclose the original 347 IPv4 address or the IPv6 prefix part. The address sharing device has 348 to strip all included XFF headers before injecting their own. 349 Servers may rely on the contents of this field to enforce some 350 policies such as blacklisting misbehaving users. Note that XFF can 351 also be logged by some servers (this is for instance supported by 352 Apache). 354 6.2. Analysis 356 Not all applications impacted by the address sharing can support the 357 ability to disclose the original IP address. Only a subset of 358 protocols (e.g., HTTP) can rely on this solution. 360 For the HTTP case, to prevent users injecting invalid user-hints, an 361 initiative has been launched to maintain a list of trusted ISPs using 362 XFF: See for example the list available at: [Trusted_ISPs] of trusted 363 ISPs as maintained by Wikipedia. If an address sharing device is on 364 the trusted XFF ISPs list, users editing Wikipedia located behind the 365 address sharing device will appear to be editing from their 366 "original" IP address and not from the NATed IP address. If an 367 offending activity is detected, individual users can be blacklisted 368 instead of all users sharing the same IP address. 370 XFF header injection is a common practice of load balancers. When a 371 load balancer is in the path, the original content of any included 372 XFF header should not be stripped. Otherwise the information about 373 the "origin" IP address will be lost. 375 When several address sharing devices are crossed, XFF header can 376 convey the list of IP addresses. The origin USER_HINT can be exposed 377 to the target server. 379 XFF also introduces some implementation complexity if the HTTP packet 380 is at or close to the MTU size. 382 It has been reported that some "poor" implementation may encounter 383 some parsing issues when injecting XFF header. 385 For encrypted HTTP traffic, injecting XFF header may be broken. 387 7. Enforce a Source-based Selection Algorithm at the Server Side 389 7.1. Description 391 This solution proposal does not require any action from the address 392 sharing function to disclose an user identifier. Instead of assuming 393 all the ports are associated with the same user, a random-based 394 algorithm (or any port selection method) is run to generate the set 395 of ports (including the source port of the received packet). The 396 length of the ports set to be generated by the server may be 397 configurable (e.g., 8, 32, 64, 512, 1024, etc.). Instead of a 398 random-based scheme, the server can use contiguous port ranges to 399 form the port sets. 401 The server may reduce (or enlarge) the width of the ports set of the 402 misbehaving action is (not) mitigated. 404 A variant of this proposal is to announce by off-line means the port 405 set assignment policy of an operator. 407 7.2. Analysis 409 In nominal mode, no coordination is required between the address 410 sharing function and the server side but the efficiency of the method 411 depends on the port set selection algorithm. 413 The method is more efficient if the provider that operates the 414 address sharing device advertises its port assignment policy but this 415 may contradicts the port randomization as identified in 416 [I-D.ietf-intarea-shared-addressing-issues]. 418 The server is free to implement the actions (e.g., blacklist all the 419 ports) it judges required to mitigate an abuse attack. 421 8. Host Identity Protocol (HIP) 423 8.1. Description 425 [RFC5201] specifies an architecture which introduces a new namespace 426 to convey an identity information. 428 8.2. Analysis 430 This solution requires both the client and the server to support HIP 431 [RFC5201]. Additional architectural considerations are to be taken 432 into account such as the key exchanges, etc. 434 If the address sharing function is required to act as a UDP/TCP-HIP 435 relay, this is not a viable option. 437 9. IANA Considerations 439 This document does not require any action from IANA. 441 10. Security Considerations 443 The same security concerns apply for the injection of an IP option, 444 TCP option and application-related content (e.g., XFF) by the address 445 sharing device. If the server trusts the content of the user-hint 446 field, a third party user can be impacted by a misbehaving user to 447 reveal a "faked" original IP address. 449 11. Acknowledgments 451 Many thanks to D. Wing and C. Jacquenet for their review, comments 452 and inputs. 454 Some of the issues related to defining a new TCP option have been 455 raised by L. Eggert. 457 12. References 459 12.1. Normative References 461 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 462 September 1981. 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 468 Address Translator (Traditional NAT)", RFC 3022, 469 January 2001. 471 12.2. Informative References 473 [Count] "A technique for counting NATted hosts", 474 . 476 [I-D.ietf-intarea-ipv4-id-update] 477 Touch, J., "Updated Specification of the IPv4 ID Field", 478 draft-ietf-intarea-ipv4-id-update-01 (work in progress), 479 October 2010. 481 [I-D.ietf-intarea-shared-addressing-issues] 482 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 483 Roberts, "Issues with IP Address Sharing", 484 draft-ietf-intarea-shared-addressing-issues-04 (work in 485 progress), February 2011. 487 [I-D.wing-nat-reveal-option] 488 Yourtchenko, A. and D. Wing, "Revealing hosts sharing an 489 IP address using TCP option", 490 draft-wing-nat-reveal-option-01 (work in progress), 491 February 2011. 493 [Not_An_Option] 494 R. Fonseca, G. Porter, R. Katz, S. Shenker, and I. 495 Stoica,, "IP options are not an option", 2005, . 499 [Options] Alberto Medina, Mark Allman, Sally Floyd, "Measuring 500 Interactions Between Transport Protocols and Middleboxes", 501 2005, . 504 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 505 "Host Identity Protocol", RFC 5201, April 2008. 507 [Trusted_ISPs] 508 "Trusted XFF list", . 511 Authors' Addresses 513 Mohamed Boucadair 514 France Telecom 515 Rennes, 35000 516 France 518 Email: mohamed.boucadair@orange-ftgroup.com 520 Joe Touch 521 USC/ISI 523 Email: touch@isi.edu 525 Pierre Levis 526 France Telecom 527 Caen, 14000 528 France 530 Email: pierre.levis@orange-ftgroup.com