Note: This ballot was opened for revision 07 and is now closed.
Summary: Needs 4 more YES or NO OBJECTION positions to pass.
It took a while, but I believe we got to some good compromisetext that helps
explain the purpose of your work. Thanks for the time taken to get the polish
There have been questions about whether anyone really discussed the value of
standardizing this, as opposed to just jumping in and working out the details.
Here's a brief citation of some of the related discussion on the httpbis
mailing list from April 2011, when Andreas started the discussion of the
predecessor document, http://tools.ietf.org/html/draft-petersson-forwarded-for
Are there other products/companies using X-Forwarded-For?
What are the products emitting the header?
What are the products parsing the header? (libraries, etc)
What are the usual mistakes, errors, etc we might have to face when parsing
> Are there other products/companies using X-Forwarded-For?
> What are the products emitting the header?
Apache mod_proxy emits the header, at least when used as a reverse proxy (front
end for web applications).
I know quite a number of companies using it for logging purposes.
> What are the products emitting the header?
At least apache , haproxy and squid immediately come to mind.
Haproxy already emits it for IPv4 and IPv6 addresses and uses
no brackets, it emits it as returned by inet_ntop().
> What are the products parsing the header? (libraries, etc)
haproxy is able to use it for various purposes (IP-based ACL
filtering, transparent binding, etc...). Right now it only
parses it for IPv4 addresses, so adding support for both
brackets and non-brackets forms is not a problem.
Some form of standardization of this would be useful for us. We plan to use
this for more than just logging. Of course, we'll cope without a formal
I'll note that adding a new header is nice, but it actually means more work -
we still have to process X-Forwarded-For to support all the existing stuff. Is
the "X-" so offensive? Is there a reason not to simply specify what everyone
It's not so much that; it's that there's no interop on the contents of
X-Forwarded-For for IPv6 headers (AFAIK), so we should take the opportunity to
define a new header that specifies it well.
While we're at it, I'd like to see extensibility points added; there are a
bunch of bits of per-hop metadata that would be nice to allow in here, instead
of defining separate headers. For example, in some use cases it'd be good to
identify the receiving address, as well as the sending one.
> There is no current uses of "Forwarded-For", backwards compatibility
> therefore does not prevent us from doing it right.
I look at it a bit differently: there are many current uses of
Forwarded-For. Every web proxy I've seen in the past decade uses it,
every web server has an option to log it, and every nontrivial web
analytics system parses it. They all do expect the "X-" in front,
though. The rollout of a naming change will be difficult; I
anticipate that proxy servers will end up sending both X-Forwarded-For
and Forwarded-For for many years. That might be inevitable, but it
brings to mind two concerns:
- People who plan to log Forwarded-For data for forensic purposes will
need to keep logging X-Forwarded-For as well.
- X-F-F values can get somewhat large, and sending the value twice
(once as X-F-F and once as F-F) will help push more requests past 1MSS
in size, resulting in an extra round-trip delay in cases where the
proxy does not already have an established connection to the
I don't think either of those points is a show-stopper for
Forwarded-For, but they're nontrivial implementation challenges.
I read the latest version draft-ietf-appsawg-http-forwarded-08
I believe that the authors introduced the justifications (even if this could
always be improved). While I understand the privacy issues, since X-forwarded
is deployed and the WG wants to standardize this, I support the format
specifications of this draft.
I have no objection to publish the draft, but one question/suggestion:
The forwarded header is defined in such a way that it can only carry complete
IP addresses, but not IP prefixes.
Extending the header to carry IP prefixes would allow to make a tradeoff
between user privacy and interest of the other end in learning about from where
the request came. Such a prefix could, for instance, say 192.168.178.0/24
instead of giving the full IP address of 192.168.178.22.
Would this make sense?
OTOH browser finger printing can potentially anyhow allow to figure who what
user is doing the request.
A proxy server that wants to add a new "Forwarded" header field value
can either append it to the last existing "Forwarded" header field
after a comma separator or add a new field at the end of the header
So, let's say that I have:
that appear in that order. Is it still OK for me to append if I am not on the
lookout for Via?
Will that screw things up semantically because now I don't know which order the
events happened in?
If that's not a problem, it seems to me that:
is semantically equivalent to:
Forwarded: FOO, BAR
If that is true, I think you should explicitly say that at the end of section
4. Would I be allowed to collect together multiple Forwarded fields and make
them one big Forwarded field?
Section 5: I find the first sentence in each of sections 5.1 and 5.2 very
5.1: "The 'by' parameter is used to disclose the interface where the request
came in to the proxy server." If I understand this correctly, you are saying
"The 'by' parameter identifies the interface on the proxy server creating the
Forwarded information on which the request came in." If that's right, it's not
clear from sentence.
5.2 "The 'for' parameter is used to disclose information about the client that
initiated the request and following proxies in a chain of proxies." I think I
get the first part of the sentence: "The 'for' parameter identifies the client
that connected to the proxy server creating the Forwarded information." I can't
figure out what the second part of the sentence means.
I commented on the privacy aspects of this during IETF LC and while
the resulting text (in 8.3) is such that I can accept the outcome of
that discussion is as good as we can get, I still have to say this
isn't really something that I think we would have developed
from-scratch in a WG. With this document, we're standardising
something that is the opposite of privacy-friendly, basically just
because the existing X-Forwarded-* header fields exist and are used
already and anything we developed that was more privacy-friendly
wouldn't get deployed.
I'm also not at all clear as to who benefits from standardising
this, e.g. see my comments on 7.2 & 8.1 below. That may have been
discussed on the apps-discuss list, but I don't recall that so am
concerned that we may just be standardising this because someone had
the energy to write and process the document.
I think the document would be better if it didn't present this as
being a good (or unconditionally "needed") thing, at least without
caveats. For example, I don't think this is "needed" by users, but
rather more by others. That's mostly a writing-style thing though.
What is a "trusted path" of proxies, or a "trusted proxy"? I think
that phrase could just be deleted since there are very few cases
where anyone knows of and (equally) trusts all the proxies on a
path. I don't think the document defines that well enough for the
phrase to be kept.
Encouraging addition and modification of header fields like this
means that any future HTTP e2e integrity mechanisms will have to be
more complex than otherwise, basically about as complex as DKIM (or
the DOSETA proposal derived from that). I'm not sure if that might
or might not have a bad effect on future work with HTTP. I don't
know if that was discussed on the httpbis list or on apps-discuss.
Section 4 says proxies MUST ensure the "correct" header field is
updated but doesn't seem to say exactly how to know which header
field is the correct one.
5.4 seems to be standardising a practice that amounts to trying to
fool the user-agent into believing that TLS was used end to end when
in fact it was not. While this is so widely deployed that its
probably pointless to try even discourage, I'm not convinced that a
WG would design a standard for a server-side crypto accellerator in
this way. I think we'd be more likely to make the middlebox at least
visible to the user-agent.
7.2 doesn't seem to me to specify when to preserve the header field
and when not to do so. I don't think "direct consequence" is
something that all implementers will understand in the same way.
(If doing whatever you like is fine here, then that calls into
question the basis for standardising this in the first place.)
8.1 says this cannot be relied upon. If that's the case then why is
it being standardised? Whitelisting proxies is (as the document
admits) not a credible mitigation.
8.2 says telling the client about the proxy chain is somehow a bad
thing but doesn't justify that. Since a client could find out anyway
if they wanted to bother, that seems wrong.
8.2 says to disallow the TRACE request. Is that a change to HTTP?
If so, then where was that discussed?
Section 9 says only that the expert should ensure that the
specification "address the security and privacy implications of the
requested parameter." So if I defined a parameter that passed on the
precise location of the end-user or the most recent healthcare
related URL they've accessed then would that be ok? I think
additional instructions are needed as to the acceptable purposes to
which such parameters can be put or else perhaps IETF review would
in fact be better. Given the field of applicability I would not be
surprised if very privacy-invasive parameters were defined in
The W3C have standardised the DoNotTrack header field. It
should be clear whether or not, and if so, how, this header
field interacts with that one.
5.1 says "some other kind of identifier" which seems quite loose.
5.5 says widely deployed extensions SHOULD be standardized which is
an odd use of 2119.
What does "in a sensible way" mean in 7.4? That seems underspecified.
The long threads on apps-discuss and ietf-general focused early on syntax
details and privacy implications. Perhaps there were in-meeting conversations
that discussed why standardizing this would help that weren't captured on list?
It would be good to capture in this document a clear statement of why the IETF
believes this is a good behavior to standardize (and be sure we have consensus
behind it). This would fall out from the resolution of Adrian's discuss, which
Supporting Stephen Farrell's position
Thank you for the work that you have done to address my concerns.