Forwarded HTTP Extension
Note: This ballot was opened for revision 07 and is now closed.Search Mailarchive
(Barry Leiba) Yes
Comment (2012-08-30 for -07)
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 ------------ http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0035.html Karl Dubost: --- 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 this header? ------------ http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0036.html Matt Domsch: --- > 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). ------------ http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0038.html Willy Tarreau: --- 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. ------------ http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0039.html Martin Thompson: --- 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 definition. 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 does. ------------ http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0048.html Mark Nottingham: --- 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. ------------ http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0071.html Brian Pane: --- > 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 destination. I don't think either of those points is a show-stopper for Forwarded-For, but they're nontrivial implementation challenges. ------------
(Stewart Bryant) (was Discuss) No Objection
Thank you for the work that you have done to address my concerns.
(Gonzalo Camarillo) No Objection
Benoit Claise No Objection
Comment (2012-09-06 for -08)
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.
(Ralph Droms) No Objection
(Adrian Farrel) (was Discuss) No Objection
Comment (2012-10-09 for -09)
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 right.
(Brian Haberman) No Objection
(Russ Housley) No Objection
(Pete Resnick) No Objection
Comment (2012-08-28 for -07)
Section 4: 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 block. So, let's say that I have: Forwarded: FOO Via: BAR that appear in that order. Is it still OK for me to append if I am not on the lookout for Via? Forwarded: FOO,BAZ Via: BAR 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: Forwarded: FOO Forwarded: BAR 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 confusing. 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.
(Robert Sparks) No Objection
Comment (2012-08-29 for -07)
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 I support.
(Martin Stiemerling) No Objection
Comment (2012-08-15 for -07)
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.
(Ron Bonica) (was No Objection) Abstain
Comment (2012-08-29 for -07)
Supporting Stephen Farrell's position
(Wesley Eddy) Abstain
(Stephen Farrell) (was Discuss) Abstain
Comment (2012-08-30 for -07)
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 future. 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.