idnits 2.17.1 draft-ietf-appsawg-http-forwarded-10.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 date (October 9, 2012) is 4207 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-19 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-19 ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Petersson 3 Internet-Draft M. Nilsson 4 Intended status: Standards Track Opera Software 5 Expires: April 12, 2013 October 9, 2012 7 Forwarded HTTP Extension 8 draft-ietf-appsawg-http-forwarded-10 10 Abstract 12 This document defines an HTTP extension header field that allows 13 proxy components to disclose information lost in the proxying 14 process, for example, the originating IP address of a request or IP 15 address of the proxy on the user-agent-facing interface. In a path 16 of proxying components, this makes it possible to arrange it so that 17 each subsequent component will have access to, for example, all IP 18 addresses used in the chain of proxied HTTP requests. 20 This document also specifies guidelines for a proxy administrator to 21 anonymize the origin of a request. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 12, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 5 59 3. Syntax Notations . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Forwarded HTTP Header Field . . . . . . . . . . . . . . . . . 5 61 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Forwarded By . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.2. Forwarded For . . . . . . . . . . . . . . . . . . . . . . 7 64 5.3. Forwarded Host . . . . . . . . . . . . . . . . . . . . . . 8 65 5.4. Forwarded Proto . . . . . . . . . . . . . . . . . . . . . 8 66 5.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Node Identifiers . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.1. IPv4 and IPv6 Identifiers . . . . . . . . . . . . . . . . 10 69 6.2. The "unknown" Identifier . . . . . . . . . . . . . . . . . 10 70 6.3. Obfuscated Identifier . . . . . . . . . . . . . . . . . . 10 71 7. Implementation Considerations . . . . . . . . . . . . . . . . 10 72 7.1. HTTP Lists . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.2. Header Field Preservation . . . . . . . . . . . . . . . . 11 74 7.3. Relation to Via . . . . . . . . . . . . . . . . . . . . . 11 75 7.4. Transition . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.5. Example Usage . . . . . . . . . . . . . . . . . . . . . . 12 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 8.1. Header Validity and Integrity . . . . . . . . . . . . . . 13 79 8.2. Information Leak . . . . . . . . . . . . . . . . . . . . . 13 80 8.3. Privacy Considerations . . . . . . . . . . . . . . . . . . 13 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 85 Appendix A. Change Log (to be removed by RFC Editor before 86 publication) . . . . . . . . . . . . . . . . . . . . 16 87 A.1. Since draft-petersson-forwarded-for-00 . . . . . . . . . . 16 88 A.2. Since draft-petersson-forwarded-for-01 . . . . . . . . . . 16 89 A.3. Since draft-petersson-forwarded-for-02 . . . . . . . . . . 17 90 A.4. Since draft-ietf-appsawg-http-forwarded-00 . . . . . . . . 17 91 A.5. Since draft-ietf-appsawg-http-forwarded-01 . . . . . . . . 17 92 A.6. Since draft-ietf-appsawg-http-forwarded-02 . . . . . . . . 17 93 A.7. Since draft-ietf-appsawg-http-forwarded-03 . . . . . . . . 18 94 A.8. Since draft-ietf-appsawg-http-forwarded-04 . . . . . . . . 18 95 A.9. Since draft-ietf-appsawg-http-forwarded-05 . . . . . . . . 18 96 A.10. Since draft-ietf-appsawg-http-forwarded-06 . . . . . . . . 18 97 A.11. Since draft-ietf-appsawg-http-forwarded-07 . . . . . . . . 19 98 A.12. Since draft-ietf-appsawg-http-forwarded-08 . . . . . . . . 19 99 A.13. Since draft-ietf-appsawg-http-forwarded-09 . . . . . . . . 19 100 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 19 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 103 1. Introduction 105 In today's HTTP landscape, there are a multitude of different 106 applications that act as proxies for the user agents. In many cases, 107 these proxies exists without the action or knowledge of the end-user. 108 These cases occur, for example, when the proxy exists as a part of 109 the infrastructure within the organization running the web server. 110 Such proxies may be used for features such as loadbalancing or crypto 111 offload. Another example is when the proxy is used within the same 112 organization as the user, and the proxy is used to cache resources. 113 However, these proxies make the requests appear as if they originated 114 from the proxy's IP address, and may change other information in the 115 original request. This represents a loss of information from the 116 original request. 118 This loss of information can cause problems for a web server that has 119 a specific use for the clients' IP addresses which will not be met by 120 using the address of the proxy or other information changed by the 121 proxy. The main uses of this information are for diagnostics, access 122 control, and abuse management. Diagnostic functions can include 123 event logging, trouble-shooting, and statistics gathering, and the 124 information collected is usually only stored for short periods of 125 time and only gathered in response to a particular problem or a 126 complaint from the client. Access control can be operated by 127 configuring a list of client IP addresses from which access is 128 permitted, but this approach will not work if a proxy is used, unless 129 the proxy is trusted and is, itself, configured with a list of 130 allowed client addresses for the server. Cases of abuse require 131 identification of the abuser and this uses many of the same features 132 identified for diagnostics. 134 Most of the time that a proxy is used, this loss of information is 135 not the primary purpose, or even a desired effect, of using the 136 proxy. Thus, to restore the desired functionality when a proxy is in 137 use, a way of disclosing the original information at the HTTP level 138 is needed. Clearly, however, when the purpose of using a proxy is to 139 provide client anonymity, the proxy will not use the feature defined 140 in this document. 142 It should be noted that the use of a reverse proxy also hides 143 information. Again, where the loss of information is not a 144 deliberate function of the use of the reverse proxy, it can be 145 desirable to find a way to encode the information within the HTTP 146 messages so that the consumer can see it. 148 A common way to disclose this information is by using the non- 149 standard header fields such as X-Forwarded-For, X-Forwarded-By, and 150 X-Forwarded-Proto. There are many benefits to using a standardized 151 approach to commonly desired protocol function: not least is 152 interoperability between implementations. This document standardizes 153 a header field called "Forwarded" and provides the syntax and 154 semantics for disclosing such information. "Forwarded" also combines 155 all the information within one single header field, making it 156 possible to correlate that information. With the header field format 157 described in this document, it is possible to know what information 158 belongs together, as long as the proxies are trusted. Such 159 conclusions are not possible to make with the X-Forwarded class of 160 header fields. The header field defined in this document is optional 161 such that implementations of proxies that are intended to provide 162 privacy are not required to operate or implement the header field. 164 Note that similar issues to those described for proxies also arise 165 with use of NATs. This is discussed further in [RFC6269]. 167 2. Notational Conventions 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 3. Syntax Notations 175 This specification uses the Augmented Backus-Naur Form (ABNF) 176 notation of [RFC5234] with the list rule extension defined in Section 177 3.2.5 of [I-D.ietf-httpbis-p1-messaging]. 179 4. Forwarded HTTP Header Field 181 The "Forwarded" HTTP header field is an OPTIONAL header field that, 182 when used, contains a list of parameter-identifier pairs that 183 disclose information that is altered or lost when a proxy is involved 184 in the path of the request. Due to the sensitive nature of the data 185 passed in this header field (see Section 8.2 and Section 8.3) this 186 header field should be turned off by default. Further, each 187 parameter should be configured individually. "Forwarded" is only for 188 use in HTTP requests and is not to be used in HTTP responses. This 189 applies to forwarding proxies, as well as reverse proxies. 190 Information passed in this header field can be, for example, the 191 source IP address of the request, the IP address of the incoming 192 interface on the proxy, or whether HTTP or HTTPS was used. If the 193 request is passing through several proxies, each proxy can add a set 194 of parameters; it can also remove earlier added Forwarded-header 195 fields. 197 The top-level list is represented as a list of HTTP header field- 198 values as defined in Section 3.2 of [I-D.ietf-httpbis-p1-messaging]. 199 The first element in this list holds information added by the first 200 proxy that implements and uses this header field, and each subsequent 201 element holds information added by each subsequent proxy. Because 202 this header field is optional, any proxy in the chain may choose not 203 to update this header field. Each field-value is a semicolon- 204 separated list; this sub-list consists of parameter-identifier pairs. 205 Parameter-identifier pairs are grouped together by an equals sign. 206 Each parameter MUST NOT occur more than once per field-value. The 207 parameter names are case-insensitive. The header field value can be 208 defined in augmented BNF syntax as: 210 Forwarded = 1#forwarded-element 212 forwarded-element = 213 [ forwarded-pair ] *( ";" [ forwarded-pair ] ) 215 forwarded-pair = token "=" value 216 value = token / quoted-string 218 token = 220 quoted-string = 223 Examples: 225 Forwarded: for="_gazonk" 226 Forwarded: For="[2001:db8:cafe::17]:4711" 227 Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43 228 Forwarded: for=192.0.2.43, for=198.51.100.17 230 Note that as ":" and "[]" are not valid characters in "token", IPv6 231 addresses are written as "quoted-string". 233 A proxy server that wants to add a new "Forwarded" header field value 234 can either append it to the last existing "Forwarded" header field 235 after a comma separator or add a new field at the end of the header 236 block. A proxy MAY remove all "Forwarded" header fields from a 237 request. It MUST, however, ensure that the correct header field is 238 updated in case of multiple "Forwarded" header fields. 240 5. Parameters 242 This document specifies a number of parameters and valid values for 243 each of them: 245 o "by" identifies the user-agent facing interface of the proxy. 247 o "for" identifies the node making the request to the proxy. 249 o "host" is the host request header field as received by the proxy. 251 o "proto" indicates what protocol was used to make the request. 253 5.1. Forwarded By 255 The "by" parameter is used to disclose the interface where the 256 request came in to the proxy server. When proxies choose to use the 257 "by" parameter, its default configuration SHOULD contain an 258 obfuscated identifier as described in Section 6.3. If the server 259 receiving proxied requests requires some address-based functionality, 260 this parameter MAY instead contain an IP-address (and, potentially, a 261 port number). A third option is the "unknown" identifier described 262 in Section 6.2. 264 The syntax of a "by" value, after potential quoted-string unescaping, 265 conforms to the "node" ABNF described in Section 6. 267 This is primarily added by reverse proxies that wish to forward this 268 information to the backend server. It can also be interesting in a 269 multi-homed environment to signal to backend servers where the 270 request came from. 272 5.2. Forwarded For 274 The "for" parameter is used to disclose information about the client 275 that initiated the request and following proxies in a chain of 276 proxies. When proxies choose to use the "for" parameter, its default 277 configuration SHOULD contain an obfuscated identifier as described in 278 Section 6.3. If the server receiving proxied requests requires some 279 address-based functionality, this parameter MAY instead contain an 280 IP-address (and, potentially, a port number). A third option is the 281 "unknown" identifier described in Section 6.2. 283 The syntax of a "for" value, after potential quoted-string 284 unescaping, conforms to the "node" ABNF described in Section 6. 286 In a chain of proxy servers where this is fully utilized, the first 287 for-parameter will disclose the client where the request was first 288 made, followed by any subsequent proxy identifiers. The last proxy 289 in the chain is not part of the list of for-parameters. The last 290 proxy's IP address, and optionally a port number, are, however, 291 readily available as the remote IP address at the transport layer. 292 It can, however, be more relevant to read information about the last 293 proxy from preceding "Forwarded" header field's by-parameter, if 294 present. 296 5.3. Forwarded Host 298 The "host" parameter is used to forward the original value of the 299 "Host" header field. This can be used, for example, by the origin 300 server if a reverse proxy is rewriting the "Host" header field to 301 some internal host name. 303 The syntax for a "host" value, after potential quoted-string 304 unescaping, MUST conform to the Host ABNF described in Section 5.4 of 305 [I-D.ietf-httpbis-p1-messaging]. 307 5.4. Forwarded Proto 309 The "proto" parameter has the value of the used protocol type. The 310 syntax of a "proto" value, after potential quoted-string unescaping, 311 MUST conform to the URI scheme name as defined in Section 3.1 in 312 [RFC3986] and registered to IANA according to [RFC4395]. Typical 313 values are "http" or "https". 315 For example, in an environment where a reverse proxy is also used as 316 a crypto offloader, this allows the origin server to rewrite URLs in 317 a document to match the type of connection as the user agent 318 requested, even though all connections to the origin server are 319 unencrypted HTTP. 321 5.5. Extensions 323 Extensions allow for additional parameters and values. Extensions 324 can be particularly useful in reverse proxy environments. All 325 extension parameters SHOULD be registered in the "HTTP Forwarded 326 Parameter" registry. If certain extensions are expected to have 327 widespread deployment, they SHOULD also be standardized. This is 328 further discussed in Section 9. 330 6. Node Identifiers 332 The node identifier is one of the following: 334 o The client's IP address, with an optional port number 336 o A token indicating that the IP address of the client is not known 337 to the proxy server 339 o A generated token, allowing for tracing and debugging, while 340 allowing the internal structure or sensitive information to be 341 hidden 343 The node identifier is defined by the augmented BNF syntax as: 345 node = nodename [ ":" node-port ] 346 nodename = IPv4address / "[" IPv6address "]" / 347 "unknown" / obfnode 349 IPv4address = 350 IPv6address = 351 obfnode = "_" 1*( ALPHA / DIGIT / "." / "_" / "-") 353 node-port = port / obfport 354 port = 1*5DIGIT 355 obfport = "_" 1*(ALPHA / DIGIT / "." / "_" / "-") 357 DIGIT = 358 ALPHA = 360 Each of the identifiers may optionally have the port identifier, for 361 example, allowing the identification of the end point in a NATted 362 environment. The "node-port" can be identified either by its port 363 number or by a generated token obfuscating the real port number. An 364 obfuscated port may be used in situations where the possessor of the 365 proxy wants the ability to trace requests -- for example, in debug 366 purposes -- but does not want to reveal internal information. 368 Note that the ABNF above also allows port numbers to be appended to 369 the the "unknown" identifier. Interpretation of such notation is, 370 however, left to the possessor of a proxy adding such a value to the 371 header field. To distinguish an "obfport" from a port, the "obfport" 372 MUST have a leading underscore. Further, it MUST also consist of 373 only "ALPHA", "DIGIT", and the characters ".", "_" and "-". 375 It is important to note that an IPv6 address and any nodename with 376 node-port specified MUST be quoted, since ":" is not an allowed 377 character in "token". 379 Examples: 381 "192.0.2.43:47011" 382 "[2001:db8:cafe::17]:47011" 384 6.1. IPv4 and IPv6 Identifiers 386 The ABNF rules for "IPv6address" and "IPv4address" are defined in 387 [RFC3986] The "IPv6address" SHOULD comply with textual representation 388 recommendations [RFC5952] (for example, lowercase, compression of 389 zeros). 391 Note that the IP address may be one from the internal nets, as 392 defined in [RFC1918] and [RFC4193]. Also, note that an IPv6 address 393 is always enclosed in square brackets. 395 6.2. The "unknown" Identifier 397 The "unknown" identifier is used when the identity of the preceding 398 entity is not known, but the proxy server still wants to signal that 399 a forwarding of the request was made. One example would be a proxy 400 server process generating an outgoing request without direct access 401 to the incoming request TCP socket. 403 6.3. Obfuscated Identifier 405 A generated identifier may be used where there is a wish to keep the 406 internal IP addresses secret, while still allowing the "Forwarded" 407 header field to be used for tracing and debugging. This can also be 408 useful if the proxy uses some sort of interface labels and it is 409 desired to pass them rather than an IP address. Unless static 410 assignment of identifiers is necessary for the server's use of the 411 identifiers, obfuscated identifiers SHOULD be randomly generated for 412 each request. If the server requires that identifiers persist across 413 requests, they SHOULD NOT persist longer than client IP addresses. 414 To distinguish the obfuscated identifier from other identifiers, it 415 MUST have a leading underscore "_". Furthermore, it MUST also 416 consist of only "ALPHA", "DIGIT" and the characters ".", "_" and "-". 417 Example: 419 Forwarded: for=_hidden, for=_SEVKISEK 421 7. Implementation Considerations 423 7.1. HTTP Lists 425 Note that an HTTP list allows white spaces to occur between the 426 identifiers, and the list may be split over multiple header fields. 427 As an example, the header field 429 Forwarded: for=192.0.2.43,for="[2001:db8:cafe::17]",for=unknown 431 is equivalent to the header field 433 Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]", for=unknown 435 which is equivalent to the header fields 437 Forwarded: for=192.0.2.43 438 Forwarded: for="[2001:db8:cafe::17]", for=unknown 440 7.2. Header Field Preservation 442 There are some cases when this header field should be kept and some 443 cases where it should not be kept. A directly forwarded request 444 should preserve and possibly extend it. If a single incoming request 445 causes the proxy to make multiple outbound requests, special care 446 must be taken to decide whether the header field should be preserved 447 or not. In many cases the header field should be preserved, but if 448 the outbound request is not a direct consequence of the incoming 449 request, the header field should not be preserved. Consider also the 450 case when a proxy has detected a content mismatch in a 304 response 451 and is following the instructions in 452 [I-D.ietf-httpbis-p4-conditional] Section 4.1 to repeat the request 453 unconditionally, in which case the new request is still basically a 454 direct consequence of the origin request, and the header field should 455 probably be kept. 457 7.3. Relation to Via 459 The "Via" header field [I-D.ietf-httpbis-p4-conditional] Section 6.2 460 is a header field with similar use case as this header field. The 461 "Via" header field, however, only provides information about the 462 proxy itself, and is thereby leaving out the information about the 463 client connecting to the proxy server. The "Forwarded" header field, 464 on the other hand, has relaying information from the client facing 465 side of the proxy server as its main purpose. As "Via" is already 466 widely deployed, its format can not be changed to address the 467 problems that "Forwarded" addresses. 469 Note that it is not possible to combine information from this header 470 field with the information from the Via header field. Some proxies 471 will not update the "Forwarded" header field, some proxies will not 472 update the Via header field, and some proxies will update both. 474 7.4. Transition 476 If a proxy gets incoming requests with X-Forwarded-* header fields 477 present, it is encouraged to convert these into the header field 478 described in this document, if it can be done in a sensible way. If 479 the request only contains one type -- for example, X-Forwarded-For -- 480 this can be translated to "Forwarded", by prepending each element 481 with "for=". Note that IPv6 addresses may not be quoted in 482 X-Forwarded-For, and may not be enclosed by square brackets, but they 483 are quoted and enclosed in square brackets in "Forwarded". 485 X-Forwarded-For: 192.0.2.43, 2001:db8:cafe::17 487 becomes: 489 Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]" 491 Special care must, however, be taken if, for example, both 492 X-Forwarded-For and X-Forwarded-By exist. In such cases, it may not 493 be possible to do a conversion, since it is not possible to know in 494 which order the already existing fields were added. Also, note that 495 removing the X-Forwarded-For header field may cause issues for 496 parties that have not yet implemented support for this new header 497 field. 499 7.5. Example Usage 501 A request from a client with IP address 192.0.2.43 passes through a 502 proxy with IP address 198.51.100.17, then through another proxy with 503 IP address 203.0.113.60 before reaching a origin server. This could, 504 for example, be an office client behind a corporate malware filter 505 talking to a origin server through a reverse proxy. 507 o The HTTP request between the client and the first proxy has no 508 "Forwarded" header field. 510 o The HTTP request between the first and second proxy has a 511 "Forwarded: for=192.0.2.43" header field. 513 o The HTTP request between the second proxy and the origin server 514 has a "Forwarded: for=192.0.2.43, 515 for=198.51.100.17;by=203.0.113.60;proto=http;host=example.com" 516 header field. 518 Note that, at some points in a connection chain, the information 519 might not be updated in the "Forwarded" header field, either because 520 of lack of support of this HTTP extension or because of a policy 521 decision not to disclose information about this network component. 523 8. Security Considerations 524 8.1. Header Validity and Integrity 526 The "Forwarded" HTTP header field cannot be relied upon to be 527 correct, as it may be modified, whether mistakenly or for malicious 528 reasons, by every node on the way to the server, including the client 529 making the request. 531 One approach is to verify the correctness of proxies and to whitelist 532 them as trusted. This approach has at least two weaknesses. First, 533 the chain of IP addresses listed before the request came to the proxy 534 cannot be trusted. Second, unless the communication between proxies 535 and the end point is secured, the data can be modified by an attacker 536 with access to the network. 538 8.2. Information Leak 540 The "Forwarded" HTTP header field can reveal internal structures of 541 the network setup behind the NAT or proxy setup, which may be 542 undesired. This can be addressed either by using obfuscated 543 elements, preventing the internal nodes from updating the HTTP header 544 field, or by having an egress proxy removing entries that reveals 545 internal network information. 547 This header field should never be copied into response messages by 548 origin servers or intermediaries, as it can reveal the whole proxy 549 chain to the client. As a side effect, special care must be taken in 550 hosting environments not to allow the TRACE request where the 551 "Forwarded" field is used, as it would appear in the body of the 552 response message. 554 8.3. Privacy Considerations 556 In recent years, there have been growing concerns about privacy. 557 There is a trade-off between ensuring privacy for users versus 558 disclosing information that is useful, for example for debugging, 559 statistics and generating location-dependent content. The 560 "Forwarded" HTTP header field, by design, exposes information that 561 some users consider privacy sensitive, in order to allow for such 562 uses. A proxy that intends or is widely used to anonymize the user 563 MUST NOT use the header field described in this document. 565 The clients IP address, that may be forwarded in the "for" parameter 566 of this header field, is considered to be privacy sensitive by many 567 people, as the IP address may be able to uniquely identify a client, 568 what operator the user is using, and possibly a rough estimation of 569 where the user is geographically located. 571 Proxies using this extension will preserve the information of a 572 direct connection. This has an end-user privacy impact regardless of 573 whether the end-user or deployer knows or expects that this is the 574 case. 576 Implementers and deployers of such proxies need to consider whether, 577 and how, deploying this extension affects user privacy. 579 The default configuration for both the "by" and "for" parameters 580 SHOULD contain obfuscated identifiers. These identifiers SHOULD be 581 randomly generated per request. If identifiers are required that 582 persist across requests, their lifetimes SHOULD be limited and they 583 SHOULD NOT persist longer than client IP addresses. When generating 584 obfuscated identifiers, care must be taken not to include potentially 585 sensitive information in them. 587 Note that users' IP addresses may already be forwarded by proxies 588 using the header field X-Forwarded-For, which is widely used. It 589 should also be noted that if the user where doing the connection 590 directly without passing the proxy, the clients IP address would be 591 sent to the web server. Users that do not actively choose a 592 anonymizing proxy can not rely on having their IP address shielded. 593 These users who wants to minimize the risk of being tracked must also 594 note that there are other ways information may leak, for example by 595 browser header field fingerprinting. The Forwarded header field 596 itself, even when used without a uniquely identifying client 597 identifier, may make fingerprinting more feasible by revealing the 598 chain of proxies traversed by the client's request. 600 9. IANA Considerations 602 This document specifies the HTTP header field listed below, which 603 should be added to the permanent HTTP header field registry defined 604 in [RFC3864]. 606 Header field: Forwarded 607 Applicable protocol: http 608 Status: standard 609 Author/Change controller: 610 IETF (iesg@ietf.org) 611 Internet Engineering Task Force 612 Specification document(s): this specification (Section 4) 613 Related information: None 615 The "Forwarded" header field contains parameters for which IANA is to 616 create and maintain a new registry entitled "HTTP Forwarded 617 parameters". Initial registrations are given below; for future 618 assignments, the registration procedure to be used is IETF review 620 [RFC5226]. The security and privacy implications of all new 621 parameters should be thoroughly documented. New parameters and their 622 values MUST conform the forwarded-pair as defined in ABNF in 623 Section 4. Further, a short description should be provided in the 624 registration. 626 +-------------+---------------------------------------+-------------+ 627 | Parameter | Description | Definition | 628 | name | | | 629 +-------------+---------------------------------------+-------------+ 630 | by | IP-address of incoming interface of a | Section 5.1 | 631 | | proxy | | 632 | for | IP-address of client making a request | Section 5.2 | 633 | | through a proxy | | 634 | host | Host header field of the incoming | Section 5.3 | 635 | | request | | 636 | proto | Application protocol used for | Section 5.4 | 637 | | incoming request | | 638 +-------------+---------------------------------------+-------------+ 640 Table 1: Initial assignments 642 10. References 644 10.1. Normative References 646 [I-D.ietf-httpbis-p1-messaging] 647 Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 648 1: URIs, Connections, and Message Parsing", 649 draft-ietf-httpbis-p1-messaging-19 (work in progress), 650 March 2012. 652 [I-D.ietf-httpbis-p4-conditional] 653 Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 654 4: Conditional Requests", 655 draft-ietf-httpbis-p4-conditional-19 (work in progress), 656 March 2012. 658 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 659 E. Lear, "Address Allocation for Private Internets", 660 BCP 5, RFC 1918, February 1996. 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, March 1997. 665 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 666 Procedures for Message Header Fields", BCP 90, RFC 3864, 667 September 2004. 669 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 670 Resource Identifier (URI): Generic Syntax", STD 66, 671 RFC 3986, January 2005. 673 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 674 Addresses", RFC 4193, October 2005. 676 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 677 Registration Procedures for New URI Schemes", BCP 35, 678 RFC 4395, February 2006. 680 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 681 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 682 May 2008. 684 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 685 Specifications: ABNF", STD 68, RFC 5234, January 2008. 687 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 688 Address Text Representation", RFC 5952, August 2010. 690 10.2. Informative References 692 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 693 Roberts, "Issues with IP Address Sharing", RFC 6269, 694 June 2011. 696 Appendix A. Change Log (to be removed by RFC Editor before publication) 698 A.1. Since draft-petersson-forwarded-for-00 700 Added IANA considerations. 702 Expanded scope and add parameterized list. 704 A.2. Since draft-petersson-forwarded-for-01 706 Removed "x-" from private extensions. 708 Allow for any protocol name. 710 Rename kv-v to forwarded-element and kv to forwarded-value. 712 Add informative reference RFC6269. 714 A.3. Since draft-petersson-forwarded-for-02 716 Name change to draft-ietf-appsawg-http-forwarded-00. 718 Updated proto in list under section 5 Parameters. 720 Remove "hidden" but mention _hidden as an example in 6.3 Obfuscated 721 identifier. 723 Clarify that IPv6-addresses must be enclosed by square brackets. 725 Restrict ext-value: do not allow "," or ";". 727 A.4. Since draft-ietf-appsawg-http-forwarded-00 729 Write IP address instead of IP number. 731 Remove BNF for IP addresses. 733 A.5. Since draft-ietf-appsawg-http-forwarded-01 735 Refer to httpbis instead of RFC2616. Thereby also change to RFC5234 736 ABNF. 738 Split up ABNF to be more general on top level. 740 Add some comments on draft-ietf-httpbis-p2-semantics-19#section-3.1 741 to "Implementation Considerations" 743 Removal of ABNF appendix. 745 Merging of the sections "Private extensions" and "Future extensions". 747 A.6. Since draft-ietf-appsawg-http-forwarded-02 749 Require obfport to start with an underscore. 751 Include "._-" as valid characters in obfnode. 753 Remove MAY-references from section 5. 755 Add a section about the relation to the via-header field. 757 Add some privacy considerations. 759 Encourage proxies to convert X-Forwarded-* to this format, when 760 possible. 762 Mention and demonstrate that IPv6-addresses must be quoted. 764 Add motivation for the obfnode. 766 Add some notes on when this header field should be preserved or not. 768 Fix some typos and make some clarifications. 770 A.7. Since draft-ietf-appsawg-http-forwarded-03 772 Require that each parameter only occur once per instance. 774 Request for a new registry at IANA. 776 A.8. Since draft-ietf-appsawg-http-forwarded-04 778 Add ABNF references for token, quoted-string, IPv4address, 779 IPv6address, DIGIT and ALPHA. 781 Only define the content of the Forwarded header field. 783 Remove https from "applicable protocol" in Section 9, as this is 784 implied. 786 A.9. Since draft-ietf-appsawg-http-forwarded-05 788 Grouped all ABNF. 790 Change registration from "RFC required" to "Specification required". 792 Extended the section describing the relation to Via. 794 Extended Privacy Considerations. 796 Made some clarifications and language fixes. 798 A.10. Since draft-ietf-appsawg-http-forwarded-06 800 Break up the ABNF again. 802 Update the Privacy Considerations section. 804 Update the IANA registration policy. 806 Change back to *( ";" [ forwarded-pair ] ) . 808 Some minor clarifications. 810 Consistently quote "Forwarded". 812 A.11. Since draft-ietf-appsawg-http-forwarded-07 814 Expanded the Introduction. 816 Expanded the Privacy Considerations discussion. 818 A.12. Since draft-ietf-appsawg-http-forwarded-08 820 Change registration procedure to IETF review. 822 Expand Introduction. 824 Encourage this head field to be off by default. 826 A.13. Since draft-ietf-appsawg-http-forwarded-09 828 Change from "header" to "header field" in some places. 830 Fix copy-paste error in the "for"-section. 832 Appendix B. Acknowledgments 834 Thanks to Per Cederqvist, Alissa Cooper, Adrian Farrel, Stephen 835 Farrell, Ned Freed, Per Hedbor, Amos Jeffries, Poul-Henning Kamp, 836 Murray S. Kucherawy, Barry Leiba, Salvatore Loreto, Alexey Melnikov, 837 S. Moonesamy, Susan Nichols, Mark Nottingham, Julian Reschke, John 838 Sullivan, Willy Tarreau and Dan Wing for their feedback. 840 Authors' Addresses 842 Andreas Petersson 843 Opera Software 844 S:t Larsgatan 12 845 Linkoping SE-582 24 847 Email: pettson@opera.com 848 Martin Nilsson 849 Opera Software 850 S:t Larsgatan 12 851 Linkoping SE-582 24 853 Email: nilsson@opera.com