idnits 2.17.1 draft-boucadair-intarea-nat-reveal-analysis-04.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 (September 2, 2011) is 4618 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-iab-privacy-workshop-00 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-03 == 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-02 -- 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: March 5, 2012 USC/ISI 6 P. Levis 7 France Telecom 8 R. Penno 9 Juniper Networks 10 September 2, 2011 12 Analysis of Solution Candidates to Reveal a Host Identifier in Shared 13 Address Deployments 14 draft-boucadair-intarea-nat-reveal-analysis-04 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) or 22 application proxies are involved in the path. This host identifier 23 must be unique to each host under the same shared IP address. 25 The ultimate goal is to assess the viability of proposed solutions 26 and hopefully to make a recommendation on the more suitable 27 solution(s). 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on March 5, 2012. 51 Copyright Notice 53 Copyright (c) 2011 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Problem to Be Solved . . . . . . . . . . . . . . . . . . . 4 70 1.2. HOST_ID and Privacy . . . . . . . . . . . . . . . . . . . 5 71 1.3. IPv6 May Also Be Concerned . . . . . . . . . . . . . . . . 6 72 1.4. Purpose and Scope . . . . . . . . . . . . . . . . . . . . 6 73 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 74 3. Solutions Analysis . . . . . . . . . . . . . . . . . . . . . . 8 75 3.1. Define an IP Option . . . . . . . . . . . . . . . . . . . 8 76 3.1.1. Description . . . . . . . . . . . . . . . . . . . . . 8 77 3.1.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 78 3.2. Define a TCP Option . . . . . . . . . . . . . . . . . . . 9 79 3.2.1. Description . . . . . . . . . . . . . . . . . . . . . 9 80 3.2.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 81 3.3. Use the Identification Field of IP Header (IP-ID) . . . . 10 82 3.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10 83 3.3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 11 84 3.4. Inject Application Headers . . . . . . . . . . . . . . . . 11 85 3.4.1. Description . . . . . . . . . . . . . . . . . . . . . 11 86 3.4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 11 87 3.5. PROXY Protocol . . . . . . . . . . . . . . . . . . . . . . 12 88 3.5.1. Description . . . . . . . . . . . . . . . . . . . . . 12 89 3.5.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 12 90 3.6. Enforce a Source-based Selection Algorithm at the 91 Server Side (Port Set) . . . . . . . . . . . . . . . . . . 12 92 3.6.1. Description . . . . . . . . . . . . . . . . . . . . . 12 93 3.6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 13 94 3.7. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 13 95 3.7.1. Description . . . . . . . . . . . . . . . . . . . . . 13 96 3.7.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 13 97 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 98 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 99 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 100 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 101 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 102 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 105 1. Introduction 107 As reported in [RFC6269], several issues are encountered when an IP 108 address is shared among several subscribers. Examples of such issues 109 are listed below: 111 o Implicit identification (Section 13.2 of [RFC6269]) 112 o SPAM (Section 13.3 of [RFC6269]) 113 o Blacklisting a mis-behaving user (Section 13.1 of [RFC6269]) 114 o Redirect users with infected machines to a dedicated portal 115 (Section 5.1 of [RFC6269]) 117 The sole use of the IPv4 address is not sufficient to uniquely 118 distinguish a host. As a mitigation, it is tempting to investigate 119 means which would help in disclosing an information to be used by the 120 remote server as a means to uniquely disambiguate packets of hosts 121 using the same IPv4 address. 123 The risk of not mitigating these issues are: OPEX increase for IP 124 connectivity service providers (costs induced by calls to a hotline), 125 revenue loss for content providers (loss of users audience), 126 customers unsatisfaction (low quality of experience, service 127 segregation, etc.). 129 1.1. Problem to Be Solved 131 Observation: Today, servers use the source IPv4 address as an 132 identifier to treat some incoming connections differently. 133 Tomorrow, due to the introduction of CGNs (e.g., NAT44 134 [I-D.ietf-behave-lsn-requirements], NAT64 [RFC6146]), that 135 address will be shared. In particular, when a server 136 receives packets from the same source address. Because 137 this address is shared, the server does not know which host 138 is the sending host. 139 Objective: The server should be able to sort out the packets by 140 sending host. 141 Requirement: The server must have extra information than the source 142 IP address to differentiate the sending host. We call 143 HOST_ID this information. 145 For all solutions analyzed, we provide answers to the following 146 questions: 148 What is the HOST_ID? It must be unique to each host under the same 149 IP address. It does not need to be globally unique. Of course, 150 the combination of the (public) IPv4 source address and the 151 identifier (i.e., HOST_ID) ends up being relatively unique. As 152 unique as today's 32-bit IPv4 addresses which, today, can change 153 when a host re-connects. 155 Where is the HOST_ID? (which protocol, which field): If the HOST_ID 156 is put at the IP level, all packets will have to bear the 157 identifier. If it is put at a higher connection-oriented level, 158 the identifier is only needed once in the session establishment 159 phase (for instance TCP three-way-handshake), then, all packets 160 received in this session will be attributed to the HOST_ID 161 designated during the session opening. 163 Who puts the HOST_ID? For almost all the analyzed solutions, the 164 address sharing function injects the HOST_ID. When there are 165 several address sharing functions in the data path, we describe 166 to what extent the proposed solution is efficient. Another 167 option to avoid potential performance degradation is to let the 168 host inject its HOST_ID but the address sharing function will 169 check its content (just like an IP anti-spoofing function). 171 What are the security considerations? Security considerations are 172 common to all analyzed solutions (see Section 5). Privacy- 173 related aspect are discussed in Section 1.2. 175 1.2. HOST_ID and Privacy 177 HOST_ID provides an additional information to uniquely disambiguate a 178 host among those sharing the same IP address. Unlike URIs, HOST_ID 179 does not leak user's identity information. 181 The HOST_ID does not reveal more privacy information than what the 182 source IP address does in a non-shared address environment (see 183 [I-D.morris-privacy-considerations]). 185 The volatility of the HOST_ID information is similar to the source IP 186 address: a distinct HOST_ID may be used by the address sharing 187 function when the host reboots or gets a new internal IP address. If 188 the HOST_ID is persistent it may be used to track a host (similar to 189 persistent IP addresses). 191 The trust on the information conveyed in the HOST_ID is likely to be 192 the same as for current practices with the source IP address. In 193 that sense, a HOST_ID can be spoofed as this is also the case for 194 spoofing an IP address. 196 It is the responsibility of the remote server to rely or not on the 197 content of the HOST_ID to enforce its policies and to log or not the 198 content conveyed in the HOST_ID. 200 Enabling explicit identification means and adequate security suite is 201 more robust than relying on source IP address or HOST_ID. But 202 tension may appear between strong privacy and usability (see Section 203 4.2 of [I-D.iab-privacy-workshop]). 205 1.3. IPv6 May Also Be Concerned 207 Issues similar to the ones described in Section 1.1 may be 208 encountered also in an IPv6 environment (e.g., when the same /64 is 209 used among several hosts). 211 1.4. Purpose and Scope 213 The purpose of this document is to analyze the solutions that have 214 been proposed so far and to assess to what extent they solve the 215 problem (see Section 1.1). 217 The purpose of this document is not to argue in favor of mandating 218 the use of a HOST_ID but to document encountered issues, proposed 219 solutions and their limitations. 221 Only IPv4-based solutions are analyzed in the following sections: 223 o define a new IP option (Section 3.1) 224 o define a new TCP option (Section 3.2) 225 o use the Identification field of IP header (denoted as IP-ID, 226 Section 3.3) 227 o inject application headers (Section 3.4) 228 o enable Proxy Protocol ( (Section 3.5)) 229 o use of port set (Section 3.6) 230 o activate HIP (Section 3.7). 232 2. Recommendations 234 The following Table 1 summarizes the approaches analyzed in this 235 document. 237 o "Success ratio" indicates the ratio of successful communications 238 when the option is used. Provided figures are inspired from the 239 results documented in [Options]. 240 o "Deployable today" indicates if the solution can be generalized 241 without any constraint on current architectures and practices. 242 o "Possible Perf Impact" indicates the level of expected performance 243 degradation. The rationale behind the indicated potential 244 performance degradation is whether the injection requires some 245 treatment at the IP level or not. 247 o "OS TCP/IP Modif" indicates whether a modification of the OS 248 TCP/IP stack is required at the server side. 250 +-------+-------+-------+--------+----------+------+-----+ 251 | IP | TCP | IP-ID | HTTP | Proxy | Port | HIP | 252 | Option| Option| | Header | Protocol | Set | | 253 | | | | (XFF) | | | | 254 ----------+-------+-------+-------+--------+----------+------+-----+ 255 UDP | Yes | No | Yes | No | No | Yes | | 256 ----------+-------+-------+-------+--------+----------+------+-----+ 257 TCP | Yes | Yes | Yes | No | Yes | Yes | | 258 ----------+-------+-------+-------+--------+----------+------+-----+ 259 HTTP | Yes | Yes | Yes | Yes | Yes | Yes | | 260 ----------+-------+-------+-------+--------+----------+------+-----+ 261 Encrypted | Yes | Yes | Yes | No | Yes | Yes | | 262 Traffic | | | | | | | | 263 ----------+-------+-------+-------+--------+----------+------+-----+ 264 Success | 30% | 99% | 100% | 100% | Low | 100% |Low | 265 Ratio | | | | | | | | 266 ----------+-------+-------+-------+--------+----------+------+-----+ 267 Possible | High | Med | Low | Med | High | No | N/A | 268 Perf | | to | to | to | | | | 269 Impact | | High | Med | High | | | | 270 ----------+-------+-------+-------+--------+----------+------+-----+ 271 OS TCP/IP | Yes | Yes | Yes | No | No | No | | 272 Modif | | | | | | | | 273 ----------+-------+-------+-------+--------+----------+------+-----+ 274 Deployable| Yes | Yes | Yes | Yes | No | Yes | No | 275 Today | | | | | | | | 276 ----------+-------+-------+-------+--------+----------+------+-----+ 277 Notes | | | (1) | (2) | | (1) | (4) | 278 | | | | | | (3) | (5) | 279 ----------+-------+-------+-------+--------+----------+------+-----+ 281 Table 1: Summary of analyzed solutions. 283 Notes for the above table: 284 (1) Requires mechanism to advertise NAT is participating in this 285 scheme (e.g., DNS PTR record) 286 (2) This solution is widely deployed 287 (3) When the port set is not advertised, the solution is less 288 efficient for third-party services. 289 (4) Requires the client and the server to be HIP-compliant and HIP 290 infrastructure to be deployed. 292 (5) If the client and the server are HIP-enabled, the address 293 sharing function does not need to insert a host-hint. If the 294 client is not HIP-enabled, designing the device that performs 295 address sharing to act as a UDP/TCP-HIP relay is not viable. 297 According to the above table and the analysis elaborated in 298 Section 3: 300 o IP Option, IP-ID and Proxy Protocol proposals are broken; 302 o HIP is not largely deployed; 304 o The use of Port Set may contradict the port randomization 305 [RFC6056] requirement identified in [RFC6269]. This solution can 306 be used by a service provider for the delivery of its own service 307 offerings relying on implicit identification. 309 o XFF is de facto standard deployed and supported in operational 310 networks (e.g., HTTP Severs, Load-Balancers, etc.). 312 o From an application standpoint, the TCP Option is superior to XFF 313 since it is not restricted to HTTP. Nevertheless XFF is 314 compatible with the presence of address sharing and load-balancers 315 in the communication path. To provide a similar functionality, 316 the TCP Option may be extended to allow conveying a list of IP 317 addresses to not loose the source IP address in the presence of 318 load-balancers. Note that TCP Option requires the modification of 319 the OS TCP/IP stack of remote servers; which can be seen as a 320 blocking point. 322 As a conclusion of this analysis, the following recommendation is 323 made: 325 [Hopefully to be completed] 327 3. Solutions Analysis 329 3.1. Define an IP Option 331 3.1.1. Description 333 This proposal aims to define an IP option [RFC0791] to convey a "host 334 identifier". This identifier can be inserted by the address sharing 335 function to uniquely distinguish a host among those sharing the same 336 IP address. The option can convey an IPv4 address, the prefix part 337 of an IPv6 address, etc. 339 Another way for using IP option has been described in Section 4.6 of 340 [RFC3022]. 342 3.1.2. Analysis 344 Unlike the solution presented in Section 3.2, this proposal can apply 345 for any transport protocol. Nevertheless, it is widely known that 346 routers (and other middle boxes) filter IP options. IP packets with 347 IP options can be dropped by some IP nodes. Previous studies 348 demonstrated that "IP Options are not an option" (Refer to 349 [Not_An_Option], [Options]). 351 As a conclusion, using an IP option to convey a host-hint is not 352 viable. 354 3.2. Define a TCP Option 356 3.2.1. Description 358 This proposal [I-D.wing-nat-reveal-option] defines a new TCP option 359 called USER_HINT. This option encloses the TCP client's identifier 360 (e.g., the lower 16 bits of their IPv4 address, their VLAN ID, VRF 361 ID, subscriber ID). The address sharing device inserts this TCP 362 option to the TCP SYN packet. 364 3.2.2. Analysis 366 The risk related to handling a new TCP option is low as measured in 367 [Options]. 369 [I-D.wing-nat-reveal-option] discusses the interference with other 370 TCP options. 372 Using a new TCP option to convey the host-hint does not require any 373 modification to the applications but it is applicable only for TCP- 374 based applications. Applications relying on other transport 375 protocols are therefore left unsolved. 377 Some downsides have been raised against defining a TCP option to 378 reveal a host identity: 380 o Conveying an IP address in a TCP option may be seen as a violation 381 of OSI layers but since IP addresses are already used for the 382 checksum computation, this is not seen as a blocking point. 383 Moreover, Updated version of [I-D.wing-nat-reveal-option] does not 384 allow anymore to convey an IP address (the HOST_ID is encoded in 385 16bits). 387 o TCP option space is limited, and might be consumed by the TCP 388 client. Earlier versions of [I-D.wing-nat-reveal-option] discuss 389 two approaches to sending the HOST_ID: sending the HOST_ID in the 390 TCP SYN (which consumes more bytes in the TCP header of the TCP 391 SYN) and sending the HOST_ID in a TCP ACK (which consumes only two 392 bytes in the TCP SYN). Content providers may find it more 393 desirable to receive the HOST_ID in the TCP SYN, as that more 394 closely preserves the host hint received in the source IP address 395 as per current practices. It is more complicated to implement 396 sending the HOST_ID in a TCP ACK, as it can introduce MTU issues 397 if the ACK packet also contains TCP data, or a TCP segment is 398 lost. The latest specification of the HOST_ID TCP Option, 399 documented at [I-D.wing-nat-reveal-option], allows only to enclose 400 the HOST_ID in the TCP SYN packet. 402 o When there are several NATs in the path, the original HOST_ID may 403 be lost. In such case, the procedure may not be efficient. 405 o Interference with current usages such as X-Forwarded-For (see 406 Section 3.4) should be elaborated to specify the behavior of 407 servers when both options are used; in particular specify which 408 information to use: the content of the TCP option or what is 409 conveyed in the application headers. 411 o When load-balancers or proxies are in the path, this option does 412 not allow to preserve the original source IP address and source. 413 Preserving such information is required for logging purposes for 414 instance. 416 3.3. Use the Identification Field of IP Header (IP-ID) 418 3.3.1. Description 420 IP-ID (Identification field of IP header) can be used to insert an 421 information which uniquely distinguishes a host among those sharing 422 the same IPv4 address. An address sharing function can re-write the 423 IP-ID field to insert a value unique to the host (16 bits are 424 sufficient to uniquely disambiguate hosts sharing the same IP 425 address). Note that this field is not altered by some NATs; hence 426 some side effects such as counting hosts behind a NAT as reported in 427 [Count]. 429 A variant of this approach relies upon the format of certain packets, 430 such as TCP SYN, where the IP-ID can be modified to contain a 16 bit 431 host-hint. Address sharing devices performing this function would 432 require to indicate they are performing this function out of band, 433 possibly using a special DNS record. 435 3.3.2. Analysis 437 This usage is not compliant with what is recommended in 438 [I-D.ietf-intarea-ipv4-id-update]. 440 3.4. Inject Application Headers 442 3.4.1. Description 444 Another option is to not require any change at the transport nor the 445 IP levels but to convey at the application payload the required 446 information which will be used to disambiguate hosts. This format 447 and the related semantics depend on its application (e.g., HTTP, SIP, 448 SMTP, etc.). 450 For HTTP, the X-Forwarded-For (XFF) header can be used to display the 451 original IP address when an address sharing device is involved. 452 Service Providers operating address sharing devices can enable the 453 feature of injecting the XFF header which will enclose the original 454 IPv4 address or the IPv6 prefix part. The address sharing device has 455 to strip all included XFF headers before injecting their own. 456 Servers may rely on the contents of this field to enforce some 457 policies such as blacklisting misbehaving users. Note that XFF can 458 also be logged by some servers (this is for instance supported by 459 Apache). 461 3.4.2. Analysis 463 Not all applications impacted by the address sharing can support the 464 ability to disclose the original IP address. Only a subset of 465 protocols (e.g., HTTP) can rely on this solution. 467 For the HTTP case, to prevent users injecting invalid host-hints, an 468 initiative has been launched to maintain a list of trusted ISPs using 469 XFF: See for example the list available at: [Trusted_ISPs] of trusted 470 ISPs as maintained by Wikipedia. If an address sharing device is on 471 the trusted XFF ISPs list, users editing Wikipedia located behind the 472 address sharing device will appear to be editing from their 473 "original" IP address and not from the NATed IP address. If an 474 offending activity is detected, individual hosts can be blacklisted 475 instead of all hosts sharing the same IP address. 477 XFF header injection is a common practice of load balancers. When a 478 load balancer is in the path, the original content of any included 479 XFF header should not be stripped. Otherwise the information about 480 the "origin" IP address will be lost. 482 When several address sharing devices are crossed, XFF header can 483 convey the list of IP addresses. The origin HOST_ID can be exposed 484 to the target server. 486 XFF also introduces some implementation complexity if the HTTP packet 487 is at or close to the MTU size. 489 It has been reported that some "poor" implementation may encounter 490 some parsing issues when injecting XFF header. 492 For encrypted HTTP traffic, injecting XFF header may be broken. 494 3.5. PROXY Protocol 496 3.5.1. Description 498 The solution, referred to as Proxy Protocol [Proxy], does not require 499 any application-specific knowledge. The rationale behind this 500 solution is to prepend each connection with a line reporting the 501 characteristics of the other side's connection as shown in the 502 example below (excerpt from [Proxy]): 504 PROXY TCP4 198.51.100.1 198.51.100.11 56324 443\r\n 506 Upon receipt of a message conveying this line, the server removes the 507 line. The line is parsed to retrieve the transported protocol. The 508 content of this line is recorded in logs and used to enforce 509 policies. 511 3.5.2. Analysis 513 This solution can be deployed in a controlled environment but it can 514 not be deployed to all access services available in the Internet. If 515 the remote server does not support the Proxy Protocol, the session 516 will fail. Other complications will raise due to the presence of 517 firewalls for instance. 519 As a consequence, this solution is broken and can not be recommended. 521 3.6. Enforce a Source-based Selection Algorithm at the Server Side 522 (Port Set) 524 3.6.1. Description 526 This solution proposal does not require any action from the address 527 sharing function to disclose a host identifier. Instead of assuming 528 all the ports are associated with the same host, a random-based 529 algorithm (or any port selection method) is run to generate the set 530 of ports (including the source port of the received packet). The 531 length of the ports set to be generated by the server may be 532 configurable (e.g., 8, 32, 64, 512, 1024, etc.). Instead of a 533 random-based scheme, the server can use contiguous port ranges to 534 form the port sets. 536 The server may reduce (or enlarge) the width of the ports set of the 537 misbehaving action is (not) mitigated. 539 A variant of this proposal is to announce by off-line means the port 540 set assignment policy of an operator. This announcement is not 541 required for the delivery of internal services (i.e., offered by the 542 service provider deploying the address sharing function) relying on 543 implicit identification. 545 3.6.2. Analysis 547 In nominal mode, no coordination is required between the address 548 sharing function and the server side but the efficiency of the method 549 depends on the port set selection algorithm. 551 The method is more efficient if the provider that operates the 552 address sharing device advertises its port assignment policy but this 553 may contradicts the port randomization as identified in [RFC6269]. 555 The method is deterministic for the delivery of services offered by 556 the service provider offering also the IP connectivity service. 558 3.7. Host Identity Protocol (HIP) 560 3.7.1. Description 562 [RFC5201] specifies an architecture which introduces a new namespace 563 to convey an identity information. 565 3.7.2. Analysis 567 This solution requires both the client and the server to support HIP 568 [RFC5201]. Additional architectural considerations are to be taken 569 into account such as the key exchanges, etc. 571 If the address sharing function is required to act as a UDP/TCP-HIP 572 relay, this is not a viable option. 574 4. IANA Considerations 576 This document does not require any action from IANA. 578 5. Security Considerations 580 The same security concerns apply for the injection of an IP option, 581 TCP option and application-related content (e.g., XFF) by the address 582 sharing device. If the server trusts the content of the HOST_ID 583 field, a third party user can be impacted by a misbehaving user to 584 reveal a "faked" original IP address. 586 6. Acknowledgments 588 Many thanks to D. Wing and C. Jacquenet for their review, comments 589 and inputs. 591 Thanks also to P. McCann, T. Tsou, Z. Dong, B. Briscoe, T. Taylor, M. 592 Blanchet, D. Wing and A. Yourtchenko for the discussions in Prague. 594 Some of the issues related to defining a new TCP option have been 595 raised by L. Eggert. 597 7. References 599 7.1. Normative References 601 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 602 September 1981. 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 608 Address Translator (Traditional NAT)", RFC 3022, 609 January 2001. 611 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 612 Protocol Port Randomization", BCP 156, RFC 6056, 613 January 2011. 615 7.2. Informative References 617 [Count] "A technique for counting NATted hosts", 618 . 620 [I-D.iab-privacy-workshop] 621 Cooper, A., "Report from the Internet Privacy Workshop", 622 draft-iab-privacy-workshop-00 (work in progress), 623 June 2011. 625 [I-D.ietf-behave-lsn-requirements] 626 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 627 and H. Ashida, "Common requirements for Carrier Grade NAT 628 (CGN)", draft-ietf-behave-lsn-requirements-03 (work in 629 progress), August 2011. 631 [I-D.ietf-intarea-ipv4-id-update] 632 Touch, J., "Updated Specification of the IPv4 ID Field", 633 draft-ietf-intarea-ipv4-id-update-02 (work in progress), 634 March 2011. 636 [I-D.morris-privacy-considerations] 637 Aboba, B., Morris, J., Peterson, J., and H. Tschofenig, 638 "Privacy Considerations for Internet Protocols", 639 draft-morris-privacy-considerations-03 (work in progress), 640 March 2011. 642 [I-D.wing-nat-reveal-option] 643 Yourtchenko, A. and D. Wing, "Revealing hosts sharing an 644 IP address using TCP option", 645 draft-wing-nat-reveal-option-02 (work in progress), 646 June 2011. 648 [Not_An_Option] 649 R. Fonseca, G. Porter, R. Katz, S. Shenker, and I. 650 Stoica,, "IP options are not an option", 2005, . 654 [Options] Alberto Medina, Mark Allman, Sally Floyd, "Measuring 655 Interactions Between Transport Protocols and Middleboxes", 656 2005, . 659 [Proxy] Tarreau, W., "The PROXY protocol", November 2010, . 662 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 663 "Host Identity Protocol", RFC 5201, April 2008. 665 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 666 NAT64: Network Address and Protocol Translation from IPv6 667 Clients to IPv4 Servers", RFC 6146, April 2011. 669 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 670 Roberts, "Issues with IP Address Sharing", RFC 6269, 671 June 2011. 673 [Trusted_ISPs] 674 "Trusted XFF list", . 677 Authors' Addresses 679 Mohamed Boucadair 680 France Telecom 681 Rennes, 35000 682 France 684 Email: mohamed.boucadair@orange-ftgroup.com 686 Joe Touch 687 USC/ISI 689 Email: touch@isi.edu 691 Pierre Levis 692 France Telecom 693 Caen, 14000 694 France 696 Email: pierre.levis@orange-ftgroup.com 698 Reinaldo Penno 699 Juniper Networks 700 1194 N Mathilda Avenue 701 Sunnyvale, California 94089 702 USA 704 Email: rpenno@juniper.net