idnits 2.17.1 draft-boucadair-intarea-nat-reveal-analysis-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 10, 2011) is 4704 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-01 == Outdated reference: A later version (-07) exists of draft-ietf-intarea-ipv4-id-update-02 == 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 (~~), 5 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: December 12, 2011 USC/ISI 6 P. Levis 7 France Telecom 8 R. Penno 9 Juniper Networks 10 June 10, 2011 12 Analysis of Solution Candidates to Reveal a Host Identifier in Shared 13 Address Deployments 14 draft-boucadair-intarea-nat-reveal-analysis-02 16 Abstract 18 This document analyzes a set of solution candidates which have been 19 proposed to mitigate some of the issues encountered when address 20 sharing is used. In particular, this document focuses on means to 21 reveal a host identifier when a Carrier Grade NAT (CGN) is involved 22 in the path. The ultimate goal is to assess the viability of 23 proposed solutions and hopefully to make a recommendation on the more 24 suitable solution(s). 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 12, 2011. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Problem to Be Solved . . . . . . . . . . . . . . . . . . . 4 68 1.2. HOST_ID and Privacy . . . . . . . . . . . . . . . . . . . 5 69 1.3. Purpose and Scope . . . . . . . . . . . . . . . . . . . . 6 70 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Solutions Analysis . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1. Define an IP Option . . . . . . . . . . . . . . . . . . . 8 73 3.1.1. Description . . . . . . . . . . . . . . . . . . . . . 9 74 3.1.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.2. Define a TCP Option . . . . . . . . . . . . . . . . . . . 9 76 3.2.1. Description . . . . . . . . . . . . . . . . . . . . . 9 77 3.2.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 78 3.3. Use the Identification Field of IP Header (IP-ID) . . . . 10 79 3.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10 80 3.3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 11 81 3.4. Inject Application Headers . . . . . . . . . . . . . . . . 11 82 3.4.1. Description . . . . . . . . . . . . . . . . . . . . . 11 83 3.4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 11 84 3.5. PROXY Protocol . . . . . . . . . . . . . . . . . . . . . . 12 85 3.5.1. Description . . . . . . . . . . . . . . . . . . . . . 12 86 3.5.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 12 87 3.6. Enforce a Source-based Selection Algorithm at the 88 Server Side (Port Set) . . . . . . . . . . . . . . . . . . 13 89 3.6.1. Description . . . . . . . . . . . . . . . . . . . . . 13 90 3.6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 13 91 3.7. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 13 92 3.7.1. Description . . . . . . . . . . . . . . . . . . . . . 13 93 3.7.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 14 94 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 96 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 98 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 99 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 102 1. Introduction 104 As reported in [I-D.ietf-intarea-shared-addressing-issues], several 105 issues are encountered when an IP address is shared among several 106 subscribers. Examples of such issues are listed below: 108 o Implicit identification (Section 13.2 of 109 [I-D.ietf-intarea-shared-addressing-issues]) 111 o SPAM (Section 13.3 of [I-D.ietf-intarea-shared-addressing-issues]) 113 o Blacklisting a mis-behaving user (Section 13.1 of 114 [I-D.ietf-intarea-shared-addressing-issues]) 116 o Redirect users with infected machines to a dedicated portal 117 (Section 5.1 of [I-D.ietf-intarea-shared-addressing-issues]) 119 The sole use of the IPv4 address is not sufficient to uniquely 120 distinguish a user. As a mitigation, it is tempting to investigate 121 means which would help in disclosing an information to be used by the 122 remote server as a means to uniquely disambiguate packets of hosts 123 using the same IPv4 address. 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 130 [I-D.ietf-behave-lsn-requirements], NAT64 [RFC6146]), that address 131 will be shared. In particular, when a server receives packets from 132 the same source address. Because this address is shared, the server 133 does not know which host is the sending host. 135 Objective: The server should be able to sort out the packets by 136 sending host. 138 Requirement: The server must have extra information than the source 139 IP address to differentiate the sending host. We call HOST_ID this 140 information. 142 For all solutions analyzed, we provide answers to the following 143 questions: 145 o What is the HOST_ID? It must be unique to each host under the 146 same address. It does not need to be globally unique. Of course, 147 the combination of the (public) IPv4 source address and the 148 identifier ends up being relatively unique. As unique as today's 149 32-bit IPv4 addresses which, today, can change when a user re- 150 connects. 152 o Where is the HOST_ID? (which protocol, which field): If the 153 HOST_ID is put at the IP level, all packets will have to bear the 154 identifier. If it is put at a higher connection-oriented level, 155 the identifier is only needed once in the session establishment 156 phase (for instance TCP three-way-handshake), then, all packets 157 received in this session will be attributed to the host id 158 designated during the session opening. 160 o Who puts the HOST_ID?: For almost all the analyzed solutions, the 161 address sharing function injects the HOST_ID. When there are 162 several address sharing functions in the data path, we describe to 163 what extent the proposed solution is efficient. Another option to 164 avoid potential performance degradation is to let the host inject 165 its HOST_ID but the address sharing function will check its 166 content (just like an IP anti-spoofing function). 168 o What are the security considerations?: Security consideration are 169 common to all analyzed solutions (see Section 5). 171 1.2. HOST_ID and Privacy 173 The HOST_ID does not reveal the identity of a user but provide an 174 information to be used to uniquely identify a host among those 175 sharing the same IP address. 177 The HOST_ID does not reveal more privacy information than what the 178 source IP address does in a non-shared address environment. 180 The volatility of the HOST_ID information is similar the source IP 181 address: a distinct HOST_ID may be used by the address sharing 182 function when the host reboots or gets a new internal IP address. 184 The trust on the information conveyed in the HOST_ID is the same as 185 for current practices with the source IP address. In that sense, a 186 HOST_ID can be spoofed as this is also the case for the spoofing of 187 the IP address. 189 It is of the responsibility of the remote server to rely or not on 190 the content of the HOST_ID to enforce its policies and to log or not 191 the content conveyed in the HOST_ID. 193 For content providers requiring strong security, enabling explicit 194 authentication means and adequate security suite is more robust than 195 relying on source IP address or HOST_ID. 197 1.3. Purpose and Scope 199 The purpose of this document is to analyze the solutions that have 200 been proposed so far and to assess to what extent they solve the 201 problem. 203 Note that similar issues may be encountered in an IPv6 environment 204 also (e.g., when the same /64 is used among several hosts). 206 The purpose of this document is not to argue in favor of mandating 207 the use of a HOST_ID but to document encountered issues, proposed 208 solutions and their limitations. 210 Only IPv4-based solutions are analyzed in the following sections: 211 define a new IP option (Section 3.1), define a new TCP option 212 (Section 3.2), use the Identification field of IP header (denoted as 213 IP-ID, Section 3.3), inject application headers (Section 3.4), enable 214 Proxy Protocol Section 3.5, use of port set (Section 3.6) and 215 activate HIP (Section 3.7). 217 2. Recommendations 219 The following Table 1 summarizes the approaches analyzed in this 220 document. 222 o "Success ratio" indicates the ratio of successful communications 223 when the option is used. Provided figures are inspired from the 224 results documented in [Options]. 226 o "Deployable today" indicates if the solution can be generalized 227 without any constraint on current architectures and practices. 229 +-------+-------+-------+--------+----------+------+-----+ 230 | IP | TCP | IP-ID | HTTP | Proxy | Port | HIP | 231 | Option| Option| | Header | Protocol | Set | | 232 | | | | (XFF) | | | | 233 ----------+-------+-------+-------+--------+----------+------+-----+ 234 UDP | Yes | No | Yes | No | No | Yes | | 235 ----------+-------+-------+-------+--------+----------+------+-----+ 236 TCP | Yes | Yes | Yes | No | Yes | Yes | | 237 ----------+-------+-------+-------+--------+----------+------+-----+ 238 HTTP | Yes | Yes | Yes | Yes | Yes | Yes | | 239 ----------+-------+-------+-------+--------+----------+------+-----+ 240 Encrypted | Yes | Yes | Yes | No | Yes | Yes | | 241 Traffic | | | | | | | | 242 ----------+-------+-------+-------+--------+----------+------+-----+ 243 Success | 30% | 99% | 100% | 100% | Low | 100% |Low | 244 Ratio | | | | | | | | 245 ----------+-------+-------+-------+--------+----------+------+-----+ 246 Possible | High | Med | Low | No | High | No | N/A | 247 Perf | | to | to | | | | | 248 Impact (6)| | High | Med | | | | | 249 ----------+-------+-------+-------+--------+----------+------+-----+ 250 OS TCP/IP | Yes | Yes | Yes | No | No | No | | 251 Modif (7) | | | | | | | | 252 ----------+-------+-------+-------+--------+----------+------+-----+ 253 Deployable| Yes | Yes | Yes | No | No | Yes | No | 254 Today | | | | | | | | 255 ----------+-------+-------+-------+--------+----------+------+-----+ 256 Notes | | | (1) | (2) | | (1) | (4) | 257 | | | | | | (3) | (5) | 258 ----------+-------+-------+-------+--------+----------+------+-----+ 260 Table 1: Summary of analyzed solutions. 262 Notes for the above table: 264 (1) requires mechanism to advertise NAT is participating in this 265 scheme (e.g., DNS PTR record) 267 (2) this solution is widely deployed 269 (3) when the port set is not advertised, the solution is less 270 efficient for third-party services. 272 (4) requires the client and the server to be HIP-compliant and HIP 273 infrastructure to be deployed. 275 (5) if the client and the server are HIP-enabled, the address 276 sharing function does not need to insert a host-hint. If the 277 client is not HIP-enabled, designing the device that performs 278 address sharing to act as a UDP/TCP-HIP relay is not viable. 280 (6) The rationale behind the indicated potential performance 281 degradation is whether the injection requires some treatment at 282 the IP level. 284 (6) The modification is required at the server side. 286 According to the above table and the analysis elaborated in 287 Section 3: 289 o IP Option, IP-ID and Proxy Protocol proposals are broken; 291 o HIP is not largely deployed; 293 o The use of Port Set may contradict the port randomization 294 [RFC6056] requirement identified in 295 [I-D.ietf-intarea-shared-addressing-issues]. This solution can be 296 used by a service provider for the delivery of its own service 297 offerings relying on implicit identification. 299 o XFF is de facto standard deployed and supported in operational 300 networks (e.g., HTTP Severs, Load-Balancers, etc.). 302 o From an application standpoint, the TCP Option is superior to XFF 303 since it is not restricted to HTTP. Nevertheless XFF is 304 compatible with the presence of address sharing and load-balancers 305 in the communication path. To provide a similar functionality, 306 the TCP Option may be extended to allow conveying a list of IP 307 addresses to not loose the source IP address in the presence of 308 load-balancers. Note that TCP Option requires the modification of 309 the OS TCP/IP stack of remote servers; which can be seen as a 310 blocking point. 312 As a conclusion of this analysis, the following recommendation is 313 made: 315 [Hopefully to be completed] 317 3. Solutions Analysis 319 3.1. Define an IP Option 320 3.1.1. Description 322 This proposal aims to define an IP option [RFC0791] to convey a "host 323 identifier". This identifier can be inserted by the address sharing 324 function to uniquely distinguish a host among those sharing the same 325 IP address. The option can convey an IPv4 address, the prefix part 326 of an IPv6 address, etc. 328 Another way for using IP option has been described in Section 4.6 of 329 [RFC3022]. 331 3.1.2. Analysis 333 Unlike the solution presented in Section 3.2, this proposal can apply 334 for any transport protocol. Nevertheless, it is widely known that 335 routers (and other middle boxes) filter IP options. IP packets with 336 IP options can be dropped by some IP nodes. Previous studies 337 demonstrated that "IP Options are not an option" (Refer to 338 [Not_An_Option], [Options]). 340 As a conclusion, using an IP option to convey a host-hint is not 341 viable. 343 3.2. Define a TCP Option 345 3.2.1. Description 347 This proposal [I-D.wing-nat-reveal-option] defines a new TCP option 348 called CX-ID. This option encloses the client's identifier (e.g., an 349 IPv4 address, a subscriber ID, or 64 bits of an IPv6 address). The 350 address sharing device inserts this TCP option to the TCP SYN packet 351 or in the initial ACK. 353 3.2.2. Analysis 355 The risk related to handling a new TCP option is low as measured in 356 [Options]. Using a new TCP option to convey the host-hint does not 357 require any modification to the applications but it is applicable 358 only for TCP-based applications. Applications relying on other 359 transport protocols are therefore left unsolved. 361 Some downsides have been raised against defining a TCP option to 362 reveal a host identity: 364 o Conveying an IP address in a TCP option may be seen as a violation 365 of OSI layers but since IP addresses are already used for the 366 checksum computation, this is not seen as a blocking point. 368 o TCP option space is limited, and might be consumed by the TCP 369 client. 371 o TCP options are not reliably transmitted. If the first segment is 372 lost and the payload bytes it contained are retransmitted, the 373 retransmitted segment is not required to contain the same options 374 as the lost segment. [I-D.wing-nat-reveal-option] discusses two 375 approaches to sending the HOST_ID: sending the HOST_ID in the TCP 376 SYN (which consumes more bytes in the TCP header of the TCP SYN) 377 and sending the HOST_ID in a TCP ACK (which consumes only two 378 bytes in the TCP SYN). Content providers may find it more 379 desirable to receive the HOST_ID in the TCP SYN, as that more 380 closely preserves the host hint received in the source IP address 381 as per current practices. It is more complicated to implement 382 sending the HOST_ID in a TCP ACK, as it can introduce MTU issues 383 if the ACK packet also contains TCP data, or a TCP segment is 384 lost. 386 o When there are several NATs in the path, the original HOST_ID may 387 be lost. In such case, the procedure may not be efficient. 389 o Interference with current usages such as X-Forwarded-For (see 390 Section 3.4) should be elaborated to specify the behavior of 391 servers when both options are used; in particular specify which 392 information to use: the content of the TCP option or what is 393 conveyed in the application headers. 395 3.3. Use the Identification Field of IP Header (IP-ID) 397 3.3.1. Description 399 IP-ID (Identification field of IP header) can be used to insert an 400 information which uniquely distinguishes a host among those sharing 401 the same IPv4 address. An address sharing function can re-write the 402 IP-ID field to insert a value unique to the host (16 bits are 403 sufficient to uniquely disambiguate hosts sharing the same IP 404 address). Note that this field is not altered by some NATs; hence 405 some side effects such as counting hosts behind a NAT as reported in 406 [Count]. 408 A variant of this approach relies upon the format of certain packets, 409 such as TCP SYN, where the IP-ID can be modified to contain a 16 bit 410 host-hint. Address sharing devices performing this function would 411 require to indicate they are performing this function out of band, 412 possibly using a special DNS record. 414 3.3.2. Analysis 416 This usage is not compliant with what is recommended in 417 [I-D.ietf-intarea-ipv4-id-update]. 419 [[Touch.NOTE: One other problem - picking an ID value here 420 *requires* coordination, i.e., that no other IP packet with this 421 IP address uses that ID within 2MSL. Unless fragmentation is 422 disabled for all packets all the time, you can't use *any* ID 423 value without that coordination.]] 425 [[Wing.NOTE: Most OSes today are emitting TCP packets with DF=1 426 (OSX, Windows XP and 7, Linux, etc.). So, we can assume the TCP 427 SYN is going to have DF=1, and only insert IP-ID if DF=1 and it's 428 a TCP SYN. Doing that, I don't see any disagreement with Joe's 429 IP-ID document.]] 431 3.4. Inject Application Headers 433 3.4.1. Description 435 Another option is to not require any change at the transport nor the 436 IP levels but to convey at the application payload the required 437 information which will be used to disambiguate hosts. This format 438 and the related semantics depend on its application (e.g., HTTP, SIP, 439 SMTP, etc.). 441 For HTTP, the X-Forwarded-For (XFF) header can be used to display the 442 original IP address when an address sharing device is involved. 443 Service Providers operating address sharing devices can enable the 444 feature of injecting the XFF header which will enclose the original 445 IPv4 address or the IPv6 prefix part. The address sharing device has 446 to strip all included XFF headers before injecting their own. 447 Servers may rely on the contents of this field to enforce some 448 policies such as blacklisting misbehaving users. Note that XFF can 449 also be logged by some servers (this is for instance supported by 450 Apache). 452 3.4.2. Analysis 454 Not all applications impacted by the address sharing can support the 455 ability to disclose the original IP address. Only a subset of 456 protocols (e.g., HTTP) can rely on this solution. 458 For the HTTP case, to prevent users injecting invalid host-hints, an 459 initiative has been launched to maintain a list of trusted ISPs using 460 XFF: See for example the list available at: [Trusted_ISPs] of trusted 461 ISPs as maintained by Wikipedia. If an address sharing device is on 462 the trusted XFF ISPs list, users editing Wikipedia located behind the 463 address sharing device will appear to be editing from their 464 "original" IP address and not from the NATed IP address. If an 465 offending activity is detected, individual hosts can be blacklisted 466 instead of all hosts sharing the same IP address. 468 XFF header injection is a common practice of load balancers. When a 469 load balancer is in the path, the original content of any included 470 XFF header should not be stripped. Otherwise the information about 471 the "origin" IP address will be lost. 473 When several address sharing devices are crossed, XFF header can 474 convey the list of IP addresses. The origin HOST_ID can be exposed 475 to the target server. 477 XFF also introduces some implementation complexity if the HTTP packet 478 is at or close to the MTU size. 480 It has been reported that some "poor" implementation may encounter 481 some parsing issues when injecting XFF header. 483 For encrypted HTTP traffic, injecting XFF header may be broken. 485 3.5. PROXY Protocol 487 3.5.1. Description 489 The solution, referred to as Proxy Protocol [Proxy], does not require 490 any application-specific knowledge. The rationale behind this 491 solution is to prepend each connection with a line reporting the 492 characteristics of the other side's connection as shown in the 493 example below (excerpt from [Proxy]): 495 PROXY TCP4 198.51.100.1 198.51.100.11 56324 443\r\n 497 Upon receipt of a message conveying this line, the server removes the 498 line. The line is parsed to retrieve the transported protocol. The 499 content of this line is recorded in logs and used to enforce 500 policies. 502 3.5.2. Analysis 504 This solution can be deployed in a controlled environment but it can 505 not be deployed to all access services available in the Internet. If 506 the remote server does not support the Proxy Protocol, the session 507 will fail. Other complications will raise due to the presence of 508 firewalls for instance. 510 As a consequence, this solution is broken and can not be recommended. 512 3.6. Enforce a Source-based Selection Algorithm at the Server Side 513 (Port Set) 515 3.6.1. Description 517 This solution proposal does not require any action from the address 518 sharing function to disclose a host identifier. Instead of assuming 519 all the ports are associated with the same host, a random-based 520 algorithm (or any port selection method) is run to generate the set 521 of ports (including the source port of the received packet). The 522 length of the ports set to be generated by the server may be 523 configurable (e.g., 8, 32, 64, 512, 1024, etc.). Instead of a 524 random-based scheme, the server can use contiguous port ranges to 525 form the port sets. 527 The server may reduce (or enlarge) the width of the ports set of the 528 misbehaving action is (not) mitigated. 530 A variant of this proposal is to announce by off-line means the port 531 set assignment policy of an operator. This announcement is not 532 required for the delivery of internal services (i.e., offered by the 533 service provider deploying the address sharing function) relying on 534 implicit identification. 536 3.6.2. Analysis 538 In nominal mode, no coordination is required between the address 539 sharing function and the server side but the efficiency of the method 540 depends on the port set selection algorithm. 542 The method is more efficient if the provider that operates the 543 address sharing device advertises its port assignment policy but this 544 may contradicts the port randomization as identified in 545 [I-D.ietf-intarea-shared-addressing-issues]. 547 The method is deterministic for the delivery of services offered by 548 the service provider offering also the IP connectivity service. 550 3.7. Host Identity Protocol (HIP) 552 3.7.1. Description 554 [RFC5201] specifies an architecture which introduces a new namespace 555 to convey an identity information. 557 3.7.2. Analysis 559 This solution requires both the client and the server to support HIP 560 [RFC5201]. Additional architectural considerations are to be taken 561 into account such as the key exchanges, etc. 563 If the address sharing function is required to act as a UDP/TCP-HIP 564 relay, this is not a viable option. 566 4. IANA Considerations 568 This document does not require any action from IANA. 570 5. Security Considerations 572 The same security concerns apply for the injection of an IP option, 573 TCP option and application-related content (e.g., XFF) by the address 574 sharing device. If the server trusts the content of the host-hint 575 field, a third party user can be impacted by a misbehaving user to 576 reveal a "faked" original IP address. 578 6. Acknowledgments 580 Many thanks to D. Wing and C. Jacquenet for their review, comments 581 and inputs. 583 Thanks also to P. McCann, T. Tsou, Z. Dong, B. Briscoe, T. Taylor, M. 584 Blanchet, D. Wing and A. Yourtchenko for the discussions in Prague. 586 Some of the issues related to defining a new TCP option have been 587 raised by L. Eggert. 589 7. References 591 7.1. Normative References 593 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 594 September 1981. 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 600 Address Translator (Traditional NAT)", RFC 3022, 601 January 2001. 603 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 604 Protocol Port Randomization", BCP 156, RFC 6056, 605 January 2011. 607 7.2. Informative References 609 [Count] "A technique for counting NATted hosts", 610 . 612 [I-D.ietf-behave-lsn-requirements] 613 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 614 and H. Ashida, "Common requirements for IP address sharing 615 schemes", draft-ietf-behave-lsn-requirements-01 (work in 616 progress), March 2011. 618 [I-D.ietf-intarea-ipv4-id-update] 619 Touch, J., "Updated Specification of the IPv4 ID Field", 620 draft-ietf-intarea-ipv4-id-update-02 (work in progress), 621 March 2011. 623 [I-D.ietf-intarea-shared-addressing-issues] 624 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 625 Roberts, "Issues with IP Address Sharing", 626 draft-ietf-intarea-shared-addressing-issues-05 (work in 627 progress), March 2011. 629 [I-D.wing-nat-reveal-option] 630 Yourtchenko, A. and D. Wing, "Revealing hosts sharing an 631 IP address using TCP option", 632 draft-wing-nat-reveal-option-01 (work in progress), 633 February 2011. 635 [Not_An_Option] 636 R. Fonseca, G. Porter, R. Katz, S. Shenker, and I. 637 Stoica,, "IP options are not an option", 2005, . 641 [Options] Alberto Medina, Mark Allman, Sally Floyd, "Measuring 642 Interactions Between Transport Protocols and Middleboxes", 643 2005, . 646 [Proxy] Tarreau, W., "The PROXY protocol", November 2010, . 649 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 650 "Host Identity Protocol", RFC 5201, April 2008. 652 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 653 NAT64: Network Address and Protocol Translation from IPv6 654 Clients to IPv4 Servers", RFC 6146, April 2011. 656 [Trusted_ISPs] 657 "Trusted XFF list", . 660 Authors' Addresses 662 Mohamed Boucadair 663 France Telecom 664 Rennes, 35000 665 France 667 Email: mohamed.boucadair@orange-ftgroup.com 669 Joe Touch 670 USC/ISI 672 Email: touch@isi.edu 674 Pierre Levis 675 France Telecom 676 Caen, 14000 677 France 679 Email: pierre.levis@orange-ftgroup.com 681 Reinaldo Penno 682 Juniper Networks 683 1194 N Mathilda Avenue 684 Sunnyvale, California 94089 685 USA 687 Email: rpenno@juniper.net