idnits 2.17.1 draft-boucadair-intarea-nat-reveal-analysis-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 14, 2011) is 4791 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBC' is mentioned on line 369, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-intarea-ipv4-id-update-01 == Outdated reference: A later version (-04) exists of draft-ietf-intarea-server-logging-recommendations-03 == 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 (~~), 7 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 15, 2011 USC/ISI 6 P. Levis 7 France Telecom 8 March 14, 2011 10 Analysis of Solution Candidates to Reveal the Origin IP Address in 11 Shared Address Deployments 12 draft-boucadair-intarea-nat-reveal-analysis-01 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 15, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Problem to Be Solved . . . . . . . . . . . . . . . . . . . 4 65 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Preserve Source Port Number . . . . . . . . . . . . . . . 7 67 3. Solutions Analysis . . . . . . . . . . . . . . . . . . . . . . 7 68 3.1. Define an IP Option . . . . . . . . . . . . . . . . . . . 7 69 3.1.1. Description . . . . . . . . . . . . . . . . . . . . . 7 70 3.1.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.2. Define a TCP Option . . . . . . . . . . . . . . . . . . . 8 72 3.2.1. Description . . . . . . . . . . . . . . . . . . . . . 8 73 3.2.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.3. Use the Identification Field of IP Header (IP-ID) . . . . 9 75 3.3.1. Description . . . . . . . . . . . . . . . . . . . . . 9 76 3.3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.4. Inject Application Headers . . . . . . . . . . . . . . . . 10 78 3.4.1. Description . . . . . . . . . . . . . . . . . . . . . 10 79 3.4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.5. PROXY Protocol . . . . . . . . . . . . . . . . . . . . . . 11 81 3.5.1. Description . . . . . . . . . . . . . . . . . . . . . 11 82 3.5.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 11 83 3.6. Enforce a Source-based Selection Algorithm at the 84 Server Side . . . . . . . . . . . . . . . . . . . . . . . 11 85 3.6.1. Description . . . . . . . . . . . . . . . . . . . . . 11 86 3.6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 12 87 3.7. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 12 88 3.7.1. Description . . . . . . . . . . . . . . . . . . . . . 12 89 3.7.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 12 90 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 92 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 95 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 98 1. Introduction 100 As reported in [I-D.ietf-intarea-shared-addressing-issues], several 101 issues are encountered when an IP address is shared among several 102 subscribers. Examples of such issues are listed below: 104 o Implicit authentication 106 o SPAM 108 o Blacklisting a mis-behaving user 110 o Redirect users with infected machines to a dedicated portal 112 The sole use of the IPv4 address is not sufficient to uniquely 113 distinguish a user. As a mitigation, it is tempting to investigate 114 means which would help in disclosing an information to be used by the 115 remote server as a means to uniquely disambiguate packets of 116 subscribers using the same IPv4 address. 118 The purpose of this document is to analyze the solutions that have 119 been proposed so far and to assess to what extent they solve the 120 problem. 122 Not need to remind that IPv6 is the only perennial solution. 124 Only IPv4-based solutions are analyzed in the following sections: 125 define a new IP option (Section 3.1), define a new TCP option 126 (Section 3.2), use the Identification field of IP header (denoted as 127 IP-ID, Section 3.3), inject application headers (Section 3.4), enable 128 Proxy Protocol Section 3.5, use of port set (Section 3.6) and 129 activate HIP (Section 3.7). 131 1.1. Problem to Be Solved 133 Observation: Today, servers use the source IPv4 address as an 134 identifier to treat some incoming connections differently. Tomorrow, 135 due to the introduction of CGNs (e.g., NAT44, NAT64), that address 136 will be shared. In particular, when a server receives packets from 137 the same source address. Because this address is shared, the server 138 does not know which host is the sending host. 140 Objective: The server should be able to sort out the packets by 141 sending host. 143 Requirement: The server must have extra information than the source 144 IP address to differentiate the sending host. We call USER_HINT this 145 information. 147 For all solutions analyzed, we provide answers to the following 148 questions: 150 o What is the USER_HINT? It must be unique to each user under the 151 same address. It does not need to be globally unique. Of course, 152 the combination of the (public) IPv4 source address and the 153 identifier ends up being relatively unique. As unique as today's 154 32-bit IPv4 addresses which, today, can change when a user re- 155 connects. 157 o Where is the USER_HINT? (which protocol, which field): If the 158 USER_HINT is put at the IP level, all packets will have to bear 159 the identifier. If it is put at a higher connection-oriented 160 level, the identifier is only needed once in the session 161 establishment phase (for instance TCP three-way-handshake), then, 162 all packets received in this session will be attributed to the 163 host id designated during the session opening. 165 o Who puts the USER_HINT?: For almost all the analyzed solutions, 166 the address sharing function injects the USER_HINT. When there 167 are several address sharing functions in the data path, we 168 describe to what extent the proposed solution is efficient. 170 o What are the security considerations?: Security consideration are 171 common to all analyzed solutions (see Section 5). 173 2. Recommendations 175 The following Table 1 summarizes the approaches analyzed in this 176 document. 178 o "Success ratio" indicates the ratio of successful communications 179 when the option is used. Provided figures are inspired from the 180 results documented in [Options]. 182 o "Deployable today" column indicates if the solution can be 183 generalized without any constraint on current architectures and 184 practices. 186 +---+---+----+---------+-------+----------+----- 187 |UDP|TCP|HTTP|Encrypted|Success|Deployable|Notes 188 | | | | traffic | ratio | today? | 189 -----------+---+---+----+---------+-------+----------+----- 190 IP option |Yes|Yes|Yes | Yes | 30% | Yes | 191 -----------+---+---+----+---------+-------+----------+----- 192 TCP option |No |Yes|Yes | Yes | 99% | Yes | 193 -----------+---+---+----+---------+-------+----------+----- 194 IP-ID |Yes|Yes|Yes | Yes | 100% | Yes | (1) 195 -----------+---+---+----+---------+-------+----------+----- 196 HTTP header|No |No |Yes | No | 100% | Yes | (2) 197 -----------+---+---+----+---------+-------+----------+----- 198 Proxy Proto| No|Yes|Yes | Yes | Low | No | 199 -----------+---+---+----+---------+-------+----------+----- 200 Port set |Yes|Yes|Yes | Yes | 100% | Yes |(1)(3) 201 -----------+---+---+----+---------+-------+----------+----- 202 HIP |-- |-- |-- | -- | Low | No |(4)(5) 203 -----------+---+---+----+---------+-------+----------+------ 205 Table 1: Summary of analyzed solutions. 207 Notes for the above table: 209 (1) requires mechanism to advertise NAT is participating in this 210 scheme (e.g., DNS PTR record) 212 (2) this solution is widely deployed 214 (3) when the port set is not advertised, the solution is less 215 efficient. 217 (4) requires the client and the server to be HIP-compliant and HIP 218 infrastructure to be deployed. 220 (5) if the client and the server are HIP-enabled, the address 221 sharing function does not need to insert a user-hint. If the 222 client is not HIP-enabled, designing the device that performs 223 address sharing to act as a UDP/TCP-HIP relay is not viable. 225 According to the above table and the analysis elaborated in 226 Section 3: 228 o IP Option, IP-ID and Proxy Protocol proposals are broken; 230 o HIP is not largely deployed; 231 o The use of Port Set may contradict the port randomization 232 [RFC6056] requirement identified in 233 [I-D.ietf-intarea-shared-addressing-issues]; 235 o XFF is de facto standard deployed and supported in operational 236 networks (e.g., HTTP Severs, Load-Balancers, etc.). 238 o From an application standpoint, the TCP Option is superior to XFF 239 since it is not restricted to HTTP. Nevertheless XFF is 240 compatible with the presence of address sharing and load-balancers 241 in the communication path. To provide a similar functionality, 242 the TCP Option may be extended to allow conveying a list of IP 243 addresses to not loose the source IP address in the presence of 244 load-balancers. 246 2.1. Preserve Source Port Number 248 In order to implement the recommendation documented in 249 [I-D.ietf-intarea-server-logging-recommendations], extensions are 250 required to preserve the source port number and to avoid this 251 information to be lost when load-balancers are involved in the path. 252 Examples of mitigation solutions are provided below: 254 1. Extend XFF to convey the port in addition to the IP address 256 2. Define a header similar to XFF to convey the source port 258 3. Extend the TCP Option to convey the source port 260 4. Enable the Proxy Protocol [Proxy]. 262 [[Note: Is there an interest to consider this issue or this should be 263 left out of scope of this I-D?]]. 265 3. Solutions Analysis 267 3.1. Define an IP Option 269 3.1.1. Description 271 This proposal aims to define an IP option [RFC0791] to convey a "user 272 identifier". This identifier can be inserted by the address sharing 273 function to uniquely distinguish a user among those sharing the same 274 IP address. The option can convey an IPv4 address, the prefix part 275 of an IPv6 address, etc. 277 Another way for using IP option has been described in Section 4.6 of 279 [RFC3022]. 281 3.1.2. Analysis 283 Unlike the solution presented in Section 3.2, this proposal can apply 284 for any transport protocol. Nevertheless, it is widely known that 285 routers (and other middle boxes) filter IP options. IP packets with 286 IP options can be dropped by some IP nodes. Previous studies 287 demonstrated that "IP Options are not an option" (Refer to 288 [Not_An_Option], [Options]). 290 As a conclusion, using an IP option to convey a user-hint is not 291 viable. 293 3.2. Define a TCP Option 295 3.2.1. Description 297 This proposal [I-D.wing-nat-reveal-option] defines a new TCP option 298 called CX-ID. This option encloses the client's identifier (e.g., an 299 IPv4 address, a subscriber ID, or 64 bits of an IPv6 address). The 300 address sharing device inserts this TCP option to the TCP SYN packet 301 or in the initial ACK. 303 3.2.2. Analysis 305 The risk related to handling a new TCP option is low as measured in 306 [Options]. Using a new TCP option to convey the user-hint does not 307 require any modification to the applications but it is applicable 308 only for TCP-based applications. Applications relying on other 309 transport protocols are therefore left unsolved. 311 Some downsides have been raised against defining a TCP option to 312 reveal a user identity: 314 o Conveying an IP address in a TCP option may be seen as a violation 315 of OSI layers but since IP addresses are already used for the 316 checksum computation, this is not seen as a blocking point. 318 o TCP option space is limited, and might be consumed by the TCP 319 client. 321 o TCP options are not reliably transmitted. If the first segment is 322 lost and the payload bytes it contained are retransmitted, the 323 retransmitted segment is not required to contain the same options 324 as the lost segment. [I-D.wing-nat-reveal-option] discusses two 325 approaches to sending the USER_HINT: sending the USER_HINT in the 326 TCP SYN (which consumes more bytes in the TCP header of the TCP 327 SYN) and sending the USER_HINT in a TCP ACK (which consumes only 328 two bytes in the TCP SYN). Content providers may find it more 329 desirable to receive the USER_HINT in the TCP SYN, as that more 330 closely preserves the user hint received in the source IP address 331 as per current practices. It is more complicated to implement 332 sending the USER_HINT in a TCP ACK, as it can introduce MTU issues 333 if the ACK packet also contains TCP data, or a TCP segment is 334 lost. 336 o When there are several NATs in the path, the original USER_HINT 337 may be lost. In such case, the procedure may not be efficient. 339 o Interference with current usages such as X-Forwarded-For (see 340 Section 3.4) should be elaborated to specify the behavior of 341 servers when both options are used; in particular specify which 342 information to use: the content of the TCP option or what is 343 conveyed in the application headers. 345 3.3. Use the Identification Field of IP Header (IP-ID) 347 3.3.1. Description 349 IP-ID (Identification field of IP header) can be used to insert an 350 information which uniquely distinguishes a user among those sharing 351 the same IPv4 address. An address sharing function can re-write the 352 IP-ID field to insert a value unique to the user (16 bits are 353 sufficient to uniquely disambiguate users sharing the same IP 354 address). Note that this field is not altered by some NATs; hence 355 some side effects such as counting hosts behind a NAT as reported in 356 [Count]. 358 A variant of this approach relies upon the format of certain packets, 359 such as TCP SYN, where the IP-ID can be modified to contain a 16 bit 360 user-hint. Address sharing devices performing this function would 361 require to indicate they are performing this function out of band, 362 possibly using a special DNS record. 364 3.3.2. Analysis 366 This usage is not compliant with what is recommended in 367 [I-D.ietf-intarea-ipv4-id-update]. 369 [TBC]. 371 [[Touch.NOTE: One other problem - picking an ID value here 372 *requires* coordination, i.e., that no other IP packet with this 373 IP address uses that ID within 2MSL. Unless fragmentation is 374 disabled for all packets all the time, you can't use *any* ID 375 value without that coordination.]] 377 [[Wing.NOTE: Most OSes today are emitting TCP packets with DF=1 378 (OSX, Windows XP and 7, Linux, etc.). So, we can assume the TCP 379 SYN is going to have DF=1, and only insert IP-ID if DF=1 and it's 380 a TCP SYN. Doing that, I don't see any disagreement with Joe's 381 IP-ID document.]] 383 3.4. Inject Application Headers 385 3.4.1. Description 387 Another option is to not require any change at the transport nor the 388 IP levels but to convey at the application payload the required 389 information which will be used to disambiguate users. This format 390 and the related semantics depend on its application (e.g., HTTP, SIP, 391 SMTP, etc.). 393 For HTTP, the X-Forwarded-For (XFF) header can be used to display the 394 original IP address when an address sharing device is involved. 395 Service Providers operating address sharing devices can enable the 396 feature of injecting the XFF header which will enclose the original 397 IPv4 address or the IPv6 prefix part. The address sharing device has 398 to strip all included XFF headers before injecting their own. 399 Servers may rely on the contents of this field to enforce some 400 policies such as blacklisting misbehaving users. Note that XFF can 401 also be logged by some servers (this is for instance supported by 402 Apache). 404 3.4.2. Analysis 406 Not all applications impacted by the address sharing can support the 407 ability to disclose the original IP address. Only a subset of 408 protocols (e.g., HTTP) can rely on this solution. 410 For the HTTP case, to prevent users injecting invalid user-hints, an 411 initiative has been launched to maintain a list of trusted ISPs using 412 XFF: See for example the list available at: [Trusted_ISPs] of trusted 413 ISPs as maintained by Wikipedia. If an address sharing device is on 414 the trusted XFF ISPs list, users editing Wikipedia located behind the 415 address sharing device will appear to be editing from their 416 "original" IP address and not from the NATed IP address. If an 417 offending activity is detected, individual users can be blacklisted 418 instead of all users sharing the same IP address. 420 XFF header injection is a common practice of load balancers. When a 421 load balancer is in the path, the original content of any included 422 XFF header should not be stripped. Otherwise the information about 423 the "origin" IP address will be lost. 425 When several address sharing devices are crossed, XFF header can 426 convey the list of IP addresses. The origin USER_HINT can be exposed 427 to the target server. 429 XFF also introduces some implementation complexity if the HTTP packet 430 is at or close to the MTU size. 432 It has been reported that some "poor" implementation may encounter 433 some parsing issues when injecting XFF header. 435 For encrypted HTTP traffic, injecting XFF header may be broken. 437 3.5. PROXY Protocol 439 3.5.1. Description 441 The solution, referred to as Proxy Protocol [Proxy], does not require 442 any application-specific knowledge. The rationale behind this 443 solution is to prepend each connection with a line reporting the 444 characteristics of the other side's connection as shown in the 445 example below (excerpt from [Proxy]): 447 PROXY TCP4 192.168.0.1 192.168.0.11 56324 443\r\n 449 Upon receipt of a message conveying this line, the server removes the 450 line. The line is parsed to retrieve the transported protocol. The 451 content of this line is recorded in logs and used to enforce 452 policies. 454 3.5.2. Analysis 456 This solution can be deployed in a controlled environment but it can 457 not be deployed to all access services available in the Internet. If 458 the remote server does not support the Proxy Protocol, the session 459 will fail. Other complications will raise due to the presence of 460 firewalls for instance. 462 As a consequence, this solution is broken and can not be recommended. 464 3.6. Enforce a Source-based Selection Algorithm at the Server Side 466 3.6.1. Description 468 This solution proposal does not require any action from the address 469 sharing function to disclose an user identifier. Instead of assuming 470 all the ports are associated with the same user, a random-based 471 algorithm (or any port selection method) is run to generate the set 472 of ports (including the source port of the received packet). The 473 length of the ports set to be generated by the server may be 474 configurable (e.g., 8, 32, 64, 512, 1024, etc.). Instead of a 475 random-based scheme, the server can use contiguous port ranges to 476 form the port sets. 478 The server may reduce (or enlarge) the width of the ports set of the 479 misbehaving action is (not) mitigated. 481 A variant of this proposal is to announce by off-line means the port 482 set assignment policy of an operator. 484 3.6.2. Analysis 486 In nominal mode, no coordination is required between the address 487 sharing function and the server side but the efficiency of the method 488 depends on the port set selection algorithm. 490 The method is more efficient if the provider that operates the 491 address sharing device advertises its port assignment policy but this 492 may contradicts the port randomization as identified in 493 [I-D.ietf-intarea-shared-addressing-issues]. 495 The server is free to implement the actions (e.g., blacklist all the 496 ports) it judges required to mitigate an abuse attack. 498 3.7. Host Identity Protocol (HIP) 500 3.7.1. Description 502 [RFC5201] specifies an architecture which introduces a new namespace 503 to convey an identity information. 505 3.7.2. Analysis 507 This solution requires both the client and the server to support HIP 508 [RFC5201]. Additional architectural considerations are to be taken 509 into account such as the key exchanges, etc. 511 If the address sharing function is required to act as a UDP/TCP-HIP 512 relay, this is not a viable option. 514 4. IANA Considerations 516 This document does not require any action from IANA. 518 5. Security Considerations 520 The same security concerns apply for the injection of an IP option, 521 TCP option and application-related content (e.g., XFF) by the address 522 sharing device. If the server trusts the content of the user-hint 523 field, a third party user can be impacted by a misbehaving user to 524 reveal a "faked" original IP address. 526 6. Acknowledgments 528 Many thanks to D. Wing and C. Jacquenet for their review, comments 529 and inputs. 531 Some of the issues related to defining a new TCP option have been 532 raised by L. Eggert. 534 7. References 536 7.1. Normative References 538 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 539 September 1981. 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, March 1997. 544 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 545 Address Translator (Traditional NAT)", RFC 3022, 546 January 2001. 548 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 549 Protocol Port Randomization", BCP 156, RFC 6056, 550 January 2011. 552 7.2. Informative References 554 [Count] "A technique for counting NATted hosts", 555 . 557 [I-D.ietf-intarea-ipv4-id-update] 558 Touch, J., "Updated Specification of the IPv4 ID Field", 559 draft-ietf-intarea-ipv4-id-update-01 (work in progress), 560 October 2010. 562 [I-D.ietf-intarea-server-logging-recommendations] 563 Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 564 "Logging recommendations for Internet facing servers", 565 draft-ietf-intarea-server-logging-recommendations-03 (work 566 in progress), February 2011. 568 [I-D.ietf-intarea-shared-addressing-issues] 569 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 570 Roberts, "Issues with IP Address Sharing", 571 draft-ietf-intarea-shared-addressing-issues-05 (work in 572 progress), March 2011. 574 [I-D.wing-nat-reveal-option] 575 Yourtchenko, A. and D. Wing, "Revealing hosts sharing an 576 IP address using TCP option", 577 draft-wing-nat-reveal-option-01 (work in progress), 578 February 2011. 580 [Not_An_Option] 581 R. Fonseca, G. Porter, R. Katz, S. Shenker, and I. 582 Stoica,, "IP options are not an option", 2005, . 586 [Options] Alberto Medina, Mark Allman, Sally Floyd, "Measuring 587 Interactions Between Transport Protocols and Middleboxes", 588 2005, . 591 [Proxy] Tarreau, W., "The PROXY protocol", November 2010, . 594 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 595 "Host Identity Protocol", RFC 5201, April 2008. 597 [Trusted_ISPs] 598 "Trusted XFF list", . 601 Authors' Addresses 603 Mohamed Boucadair 604 France Telecom 605 Rennes, 35000 606 France 608 Email: mohamed.boucadair@orange-ftgroup.com 609 Joe Touch 610 USC/ISI 612 Email: touch@isi.edu 614 Pierre Levis 615 France Telecom 616 Caen, 14000 617 France 619 Email: pierre.levis@orange-ftgroup.com