[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-appsawg-http-forwarded

Network Working Group                                       A. Petersson
Internet-Draft                                                M. Nilsson
Intended status: Standards Track                          Opera Software
Expires: October 7, 2011                                   April 5, 2011


                      Forwarded-For HTTP Extension
                    draft-petersson-forwarded-for-00

Abstract

   This document standardizes an HTTP extension header field that allows
   proxy components to disclose the originating IP number of a request.
   Given a trusted path of proxying components, each subsequent
   component will have access to all IP numbers used in the chain of
   proxied HTTP requests.

   This document also standardizes ways for a proxy possessor to
   anonymize the origin of a request.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 7, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Petersson & Nilsson      Expires October 7, 2011                [Page 1]

Internet-Draft        Forwarded-For HTTP Extension            April 2011


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . . . 3
   3.  Syntax Notations  . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Forwarded-For . . . . . . . . . . . . . . . . . . . . . . . . . 3
   5.  Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     5.1.  IPv4 and IPv6 identifiers . . . . . . . . . . . . . . . . . 5
     5.2.  The "unknown" identifier  . . . . . . . . . . . . . . . . . 6
     5.3.  The "hidden" identifier . . . . . . . . . . . . . . . . . . 6
     5.4.  Obfuscated identifier . . . . . . . . . . . . . . . . . . . 6
   6.  Implentations considerations  . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Header validity . . . . . . . . . . . . . . . . . . . . . . 7
     7.2.  Information Leak  . . . . . . . . . . . . . . . . . . . . . 7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Normative references  . . . . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Forwarded-For BNF definition . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8



























Petersson & Nilsson      Expires October 7, 2011                [Page 2]

Internet-Draft        Forwarded-For HTTP Extension            April 2011


1.  Introduction

   In today's HTTP landscape, there are a multitude of different
   applications such as caching, content filtering, and content
   compression, acting as proxy for the user agent and effectively
   anonymizing the requests to look as if they originated from the proxy
   IP number.  As most of the time anonymizing is not the primary
   purpose, or even a desired effect, a way of disclosing the original
   IP number on HTTP level instead of depending on the TCP/IP connection
   remote IP number is needed.

   One common way of disclosing the originator of the HTTP requests and
   the proxy path is with the X-Forwarded-For header field.  This
   document intends to standardize the way of disclosing this
   information by formalizing syntax and semantics for a new Forwarded-
   For header field.  This new header field also extends the de facto
   standard of X-Forwarded-For with features for which real life
   deployments have shown a need.

   This document intentionally does not cover headers specifically
   useful in a reverse proxy environment as that is considered as out of
   scope for this document.


2.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Syntax Notations

   This specification uses the augmented BNF notation defined in Section
   2.1 of [RFC2616], including its rules for implied linear whitespace
   (LWS).

   The syntax for IPv4address and IPv6address is defined in [RFC2373].


4.  Forwarded-For

   The Forwarded-For HTTP header field is an optional header field that,
   when used, contains the identification of the user agent that sent
   the requests being proxied.  The identification would typically be
   the IP number of the host, though in special cases other types of
   tokens may be preferred.  If the request is passing through several
   proxies, the identification of the previous proxy is added to the



Petersson & Nilsson      Expires October 7, 2011                [Page 3]

Internet-Draft        Forwarded-For HTTP Extension            April 2011


   list of identifiers in the header field.  Thus, when utilized fully,
   the Forwarded-For header field combined with the remote IP of the TCP
   connection carrying the HTTP request will form a complete history of
   the non-transparent network entities in the requests network path.

   The list is represented as a list of HTTP header field-values
   [RFC2616], with the client identifier first (leftmost), followed by
   any subsequent proxy identifiers.  The last proxy in the chain is not
   part of the list in the Forwarded-For header field.  The last proxy's
   IP number is, however, readily available as the remote IP of the
   TCP/IP connection.  The header field can be formally defined in
   augmented BNF syntax as

       Forwarded-For = "Forwarded-For" ":" 1#node

   Example:

       Forwarded-For: 192.0.2.43,[2001:db8:cafe::17],unknown

   Given that a proxy wishes to add a Forwarded-For header field to the
   outgoing request, if the incoming request has no such header field,
   the proxy simply adds the header with the remote IP number of the
   TCP/IP connection.  If, on the other hand, the incoming request has
   such a header field, the proxy simply adds a comma and the remote IP
   to the list.  A proxy MAY remove all Forwarded-For header fields from
   a request.  It MUST, however, ensure that the correct header field is
   updated in case of multiple Forwarded-For header fields.

   Example: A request from a client with IP number 192.0.2.43 passes
   through a proxy with IP number 198.51.100.17, then through another
   proxy with IP number 203.0.113.60 before reaching a origin server.
   This could, for example, be an office client behind a corporate
   malware filter talking to a origin server through a cache proxy.

   o  The HTTP request between the client and the first proxy has no
      Forwarded-For header field.

   o  The HTTP request between the first and second proxy has a
      "Forwarded-For: 192.0.2.43" header field.

   o  The HTTP request between the second proxy and the origin server
      has a "Forwarded-For: 192.0.2.43,198.51.100.17" header field.

   Note that, at some points in a connection chain, the IP number might
   not be correctly updated in the Forwarded-For header field, either
   because of lack of support of this HTTP extension, or because of a
   policy decision not to disclose information about this network
   component.



Petersson & Nilsson      Expires October 7, 2011                [Page 4]

Internet-Draft        Forwarded-For HTTP Extension            April 2011


5.  Identifiers

   The identifiers are the IP address of the network node, a predefined
   token hiding the real identity, but signalling that such a component
   exists in the network path, or a generated token allowing for tracing
   and debugging without revealing network internals.

       nodename = IPv4address | IPv6address |
                   "unknown" | "hidden" | obfnode

   All of the identifiers may optionally have the port identifier, for
   example, allowing the identification of the end point in a NAT:ed
   environment.

       node            = nodename [ ":" node-port ]

   The node-port can be identified either by its TCP port number or by a
   generated token obfuscating the real port number.  If a node-port is
   appended to an IPv6address the IPv6address MUST be enclosed by square
   brackets.

       node-port       = port | obfport
       port            = 1*5DIGIT
       obfport         = 1*(ALPHA | DIGIT)

   Note that this also allows portnumbers to be appended to the "hidden"
   and the "unknown" identifiers.  Interpretation of such notation is,
   however, left to the possessor of a proxy adding such a value to the
   header field.  To distinguish an obfport from a port we RECOMMEND
   that an obfort always should contain at least one ALPHA.

5.1.  IPv4 and IPv6 identifiers

   The IPv4address and IPv6address BNF tokens is defined as:

       IPv6address = addr6 | "[" addr6 "]"
       addr6 = hexpart [ ":" IPv4address ]
       IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

       hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
       hexseq  = hex4 *( ":" hex4)
       hex4    = 1*4HEXDIG

   Note that the IP number may be one from the internal nets, as defined
   in [RFC1918] and [RFC4193].






Petersson & Nilsson      Expires October 7, 2011                [Page 5]

Internet-Draft        Forwarded-For HTTP Extension            April 2011


5.2.  The "unknown" identifier

   The "unknown" identifier is used when the identity of the preceding
   entity is not known.  One example would be a proxy server process
   generating an outgoing request without direct access to the incoming
   request TCP socket.

5.3.  The "hidden" identifier

   The "hidden" identifier is used when the administrator of a proxy
   server entity would like to keep the identity of that entity secret,
   but still disclose that it exists.

5.4.  Obfuscated identifier

   A generated identifier may be used where there is a wish to keep the
   internal IP numbers secret, while still allowing the Forwarded-For
   header field to be used for tracing and debugging.  The identifiers
   can be randomly generated for each request and do not need to be
   statically assigned to resources.  To distinguish the obfuscated
   identifier from other identifiers, it MUST have a leading underscore
   "_".  Further it MUST also consist of only US-ASCII letters and US-
   ASCII digits.

         obfnode         = "_" 1*( ALPHA | DIGIT )


6.  Implentations considerations

   Note that an HTTP list allows white spaces to occur between the
   identifiers, and the list may be split over multiple header fields.
   As an example, the header field

       Forwarded-For: 192.0.2.43,[2001:db8:cafe::17],unknown

   is equivalent to the header field

       Forwarded-For: 192.0.2.43, [2001:db8:cafe::17], unknown

   which is equivalent to the header fields

       Forwarded-For: 192.0.2.43
       Forwarded-For: [2001:db8:cafe::17], unknown

   Also note that the draft [I-D.ietf-httpbis-p1-messaging] renders the
   use of folding within a list obsolete.  The use of CRLF within the
   field-value list is therefore NOT RECOMMENDED.




Petersson & Nilsson      Expires October 7, 2011                [Page 6]

Internet-Draft        Forwarded-For HTTP Extension            April 2011


7.  Security Considerations

7.1.  Header validity

   The Forwarded-For HTTP header field cannot be relied upon to be
   correct, as it may be modified, whether mistakenly or for malicious
   reasons, by every node on the way to the server, including the client
   making the request.

   One approach is to verify the correctness of proxies and white list
   them as trusted.  This approach has at least two weaknesses.  First
   the chain of IP numbers listed before the request came to the proxy
   cannot be trusted.  Secondly, unless the communication between
   proxies and end point is secured, the data can be modified by an
   attacker with access to the network.

7.2.  Information Leak

   The Forwarded-For HTTP header field can reveal internal structures of
   the network setup behind the NAT or proxy setup, which may be
   undesired.  This can be addressed either by preventing the internal
   nodes from updating the HTTP header field, or by having an egress
   proxy removing entries that reveals internal network information.


8.  IANA Considerations

   There are no IANA Considerations.


9.  Normative references

   [I-D.ietf-httpbis-p1-messaging]
              Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
              Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke,
              "HTTP/1.1, part 1: URIs, Connections, and Message
              Parsing", draft-ietf-httpbis-p1-messaging-13 (work in
              progress), March 2011.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2373]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 2373, July 1998.



Petersson & Nilsson      Expires October 7, 2011                [Page 7]

Internet-Draft        Forwarded-For HTTP Extension            April 2011


   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.


Appendix A.  Forwarded-For BNF definition

   This appendix defines the Forwarded-For header field.

       Forwarded-For = "Forwarded-For" ":" LWS Forwarded-For-v
       Forwarded-For-v = 1#node
       node = nodename [":" node-port]
       nodename = IPv4address | IPv6address |
                   "unknown" | "hidden" | obfnode
       obfnode = "_" 1*( ALPHA | DIGIT )
       node-port = port | obfport
       port = 1*5DIGIT
       obfport = 1*( ALPHA | DIGIT )

       IPv6address = addr6 | "[" addr6 "]"
       addr6 = hexpart [ ":" IPv4address ]
       IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

       hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
       hexseq  = hex4 *( ":" hex4)
       hex4    = 1*4HEXDIG


Authors' Addresses

   Andreas Petersson
   Opera Software
   S:t Larsgatan 12
   Linkoping  SE-582 24

   Email: pettson@opera.com


   Martin Nilsson
   Opera Software
   S:t Larsgatan 12
   Linkoping  SE-582 24

   Email: nilsson@opera.com




Petersson & Nilsson      Expires October 7, 2011                [Page 8]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/