Forwarded HTTP Extension
RFC 7239
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-12-20
|
10 | (System) | Received changes through RFC Editor sync (changed abstract to 'This document defines an HTTP extension header field that allows proxy components to disclose information lost … Received changes through RFC Editor sync (changed abstract to 'This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.') |
2017-07-14
|
10 | (System) | Received changes through RFC Editor sync (added Errata tag) |
2015-10-14
|
10 | (System) | Notify list changed from appsawg-chairs@ietf.org, draft-ietf-appsawg-http-forwarded@ietf.org, Alexey.Melnikov@isode.com to (None) |
2014-06-11
|
10 | (System) | IANA registries were updated to include RFC7239 |
2014-06-06
|
10 | (System) | RFC published |
2014-05-27
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-05-22
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-04-16
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2014-03-27
|
10 | (System) | RFC Editor state changed to REF from EDIT |
2014-02-12
|
10 | (System) | RFC Editor state changed to EDIT from MISSREF |
2014-01-23
|
10 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Withdrawn' |
2012-10-18
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-10-18
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2012-10-16
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-10-16
|
10 | (System) | IANA Action state changed to In Progress from Waiting on ADs |
2012-10-15
|
10 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-10-14
|
10 | (System) | IANA Action state changed to Waiting on ADs from In Progress |
2012-10-14
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2012-10-12
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-10-12
|
10 | (System) | IANA Action state changed to In Progress |
2012-10-12
|
10 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-10-12
|
10 | Amy Vezza | IESG has approved the document |
2012-10-12
|
10 | Amy Vezza | Closed "Approve" ballot |
2012-10-12
|
10 | Amy Vezza | Ballot approval text was generated |
2012-10-12
|
10 | Barry Leiba | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-10-12
|
10 | Barry Leiba | Ballot writeup was changed |
2012-10-11
|
10 | Stewart Bryant | [Ballot comment] Thank you for the work that you have done to address my concerns. |
2012-10-11
|
10 | Stewart Bryant | [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss |
2012-10-09
|
10 | Andreas Petersson | New version available: draft-ietf-appsawg-http-forwarded-10.txt |
2012-10-09
|
09 | Adrian Farrel | [Ballot comment] It took a while, but I believe we got to some good compromisetext that helps explain the purpose of your work. Thanks for … [Ballot comment] 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. |
2012-10-09
|
09 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss |
2012-10-09
|
09 | Andreas Petersson | New version available: draft-ietf-appsawg-http-forwarded-09.txt |
2012-09-20
|
08 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2012-09-06
|
08 | Benoît Claise | [Ballot comment] 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 … [Ballot comment] 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. |
2012-09-06
|
08 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-09-06
|
08 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to Abstain from Discuss |
2012-09-06
|
08 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-09-05
|
08 | Andreas Petersson | New version available: draft-ietf-appsawg-http-forwarded-08.txt |
2012-08-31
|
07 | Barry Leiba | Notification list changed to : appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-http-forwarded@tools.ietf.org, Alexey.Melnikov@isode.com |
2012-08-30
|
07 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2012-08-30
|
07 | Stephen Farrell | [Ballot comment] I commented on the privacy aspects of this during IETF LC and while the resulting text (in 8.3) is such that I can … [Ballot comment] 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. |
2012-08-30
|
07 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to Abstain from Discuss |
2012-08-30
|
07 | Sean Turner | [Ballot discuss] NOTE: I'm entering this as a discuss and not as a comment. I support Adrian and Stephen's points. Not entirely sure this actionable, … [Ballot discuss] NOTE: I'm entering this as a discuss and not as a comment. I support Adrian and Stephen's points. Not entirely sure this actionable, but think we ought to at least talk about it on the call: I'm struggling to figure out why we need to standardize this. This feels to me like when a draft was just recently floated to standardize TLS proxies (i.e., standardized MITM) - sure we could do that but is really a good idea? |
2012-08-30
|
07 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2012-08-30
|
07 | Stephen Farrell | [Ballot discuss] I plan to change my DISCUSS position to an ABSTAIN position after the telechat. Its a DISCUSS for now in case some of … [Ballot discuss] I plan to change my DISCUSS position to an ABSTAIN position after the telechat. Its a DISCUSS for now in case some of the points help to improve something in the meantime. (Updated to add DNT point at the end. No other change) 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. |
2012-08-30
|
07 | Stephen Farrell | [Ballot comment] 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 … [Ballot comment] 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. |
2012-08-30
|
07 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2012-08-30
|
07 | Barry Leiba | [Ballot comment] There have been questions about whether anyone really discussed the value of standardizing this, as opposed to just jumping in and working out … [Ballot comment] 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. ------------ |
2012-08-30
|
07 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2012-08-30
|
07 | Wesley Eddy | [Ballot Position Update] New position, Abstain, has been recorded for Wesley Eddy |
2012-08-29
|
07 | Robert Sparks | [Ballot comment] 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 … [Ballot comment] 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. |
2012-08-29
|
07 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-08-29
|
07 | Ron Bonica | [Ballot comment] Supporting Stephen Farrell's position |
2012-08-29
|
07 | Ron Bonica | [Ballot Position Update] Position for Ronald Bonica has been changed to Abstain from No Objection |
2012-08-29
|
07 | Adrian Farrel | [Ballot discuss] I think it is unfortunate that this document does not give any explanation of why it is desirable to expose the information that … [Ballot discuss] I think it is unfortunate that this document does not give any explanation of why it is desirable to expose the information that is lost during proxying and which the proposed extensions make available. It is normal for work in the IETF to be presented along with some motivations based on utility. While it is quite clear that the proposed mechanism would work to provide the function described, it is a mystery why any proxy would implement it or consider the extension valuable. Given that lack of explanation, I don't understand why the IETF would pursue this work on the Standards Track. This Discuss could be resolved by adding some explanation to the document. Barry sent a recent email containing some explanation of why a standard approach to this function would be beneficial - that text would address half of my concern. But the benefits of a standard way of doing something are not the whole answer: I also need to know why *any* way of doing this needs to be documented. |
2012-08-29
|
07 | Adrian Farrel | [Ballot comment] I believe that some of the concerns expressed about privacy would be aliviated if more emphasis was placed on the fact that this … [Ballot comment] I believe that some of the concerns expressed about privacy would be aliviated if more emphasis was placed on the fact that this extension *allows* the disclosure of information, but doesn't require it. This is presumably information that would have been visible had the proxy not been used. Since one possible reason for using the proxy is to obscure this information, it would make sense for the use of this extension by the proxy to be negotiable by the originating component. --- Abstract I would prefer you to s/standardizes/defines/ |
2012-08-29
|
07 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel |
2012-08-28
|
07 | Pete McCann | Request for Telechat review by GENART Completed: Ready. Reviewer: Pete McCann. |
2012-08-28
|
07 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-08-28
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-08-28
|
07 | Stewart Bryant | [Ballot discuss] I agree with Stephen's concern, and will also be Abstaining. I addition to the privacy concern I am also concerned that this may … [Ballot discuss] I agree with Stephen's concern, and will also be Abstaining. I addition to the privacy concern I am also concerned that this may defeat one of the purposes of proxies, which is to defeat geopriv. I therefore think that the least that needs to happen is that the feature MUST be off by default, and that there should be an element of the protocol that allows the user to (silently) specify that the proxy must not apply this feature. |
2012-08-28
|
07 | Stewart Bryant | [Ballot Position Update] New position, Discuss, has been recorded for Stewart Bryant |
2012-08-28
|
07 | Pete Resnick | [Ballot comment] Section 4: A proxy server that wants to add a new "Forwarded" header field value can either append it to the … [Ballot comment] 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. |
2012-08-28
|
07 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-08-27
|
07 | Stephen Farrell | [Ballot discuss] I plan to change my DISCUSS position to an ABSTAIN position after the telechat. Its a DISCUSS for now in case some of … [Ballot discuss] I plan to change my DISCUSS position to an ABSTAIN position after the telechat. Its a DISCUSS for now in case some of the points help to improve something in the meantime. 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. |
2012-08-27
|
07 | Stephen Farrell | [Ballot comment] 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 … [Ballot comment] 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. |
2012-08-27
|
07 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2012-08-27
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-08-27
|
07 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-08-23
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Pete McCann |
2012-08-23
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Pete McCann |
2012-08-15
|
07 | Martin Stiemerling | [Ballot comment] I have no objection to publish the draft, but one question/suggestion: The forwarded header is defined in such a way that it can … [Ballot comment] 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. |
2012-08-15
|
07 | Martin Stiemerling | Ballot comment text updated for Martin Stiemerling |
2012-08-15
|
07 | Martin Stiemerling | [Ballot comment] I have no objection to publish the draft, but one question: The forwarded header is defined in such a way that it can … [Ballot comment] I have no objection to publish the draft, but one question: 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. OTOH browser finger printing can potentially anyhow allow to figure who what user is doing the request. |
2012-08-15
|
07 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-08-13
|
07 | Barry Leiba | Placed on agenda for telechat - 2012-08-30 |
2012-08-13
|
07 | Barry Leiba | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-08-13
|
07 | Barry Leiba | Ballot has been issued |
2012-08-13
|
07 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2012-08-13
|
07 | Barry Leiba | Created "Approve" ballot |
2012-08-13
|
07 | Barry Leiba | Ballot writeup was changed |
2012-08-13
|
07 | Andreas Petersson | New version available: draft-ietf-appsawg-http-forwarded-07.txt |
2012-07-23
|
06 | Barry Leiba | Ballot writeup was changed |
2012-07-23
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-07-20
|
06 | Pearl Liang | IANA has reviewed draft-ietf-appsawg-http-forwarded-06 and has the following comments: IANA understands that, upon approval of this document, there are two actions which IANA must complete. … IANA has reviewed draft-ietf-appsawg-http-forwarded-06 and has the following comments: IANA understands that, upon approval of this document, there are two actions which IANA must complete. First, in the Permanent Message Header Field Names registry located at: www.iana.org/assignments/message-headers/perm-headers.html a new permanent message header will be registered as follows: Header Field Name: Forwarded Protocol: http Status: standard Reference: [ RFC-to-be ] Second, IANA is to create a new registry, called the "HTTP Forwarded parameters" registry. This registry will be maintained through Specification Required as defined by RFC 5226. There are initial assignments for this new registry as follows: +-------------+---------------------------------------+-------------+ | Parameter | Description | Reference | | name | | | +-------------+---------------------------------------+-------------+ | by | IP-address of incoming interface of a |[ RFC-to-be ]| | | proxy | | | for | IP-address of client making a request |[ RFC-to-be ]| | | through a proxy | | | host | Host header field of the incoming |[ RFC-to-be ]| | | request | | | proto | Application protocol used for |[ RFC-to-be ]| | | incoming request | | +-------------+---------------------------------------+-------------+ IANA understands that these two actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. |
2012-07-13
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tim Polk |
2012-07-13
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tim Polk |
2012-07-12
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Allyn Romanow |
2012-07-12
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Allyn Romanow |
2012-07-09
|
06 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Forwarded HTTP Extension) to Proposed Standard … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Forwarded HTTP Extension) to Proposed Standard The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Forwarded HTTP Extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document standardizes an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. Given a trusted path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/ No IPR declarations have been submitted directly on this I-D. ==================================== A specific point for Last Call discussion, please: During AD Evaluation, the registration policy for the new "HTTP Forwarded parameters" registry (see Section 9) was changed to "Specification Required" from "RFC Required". This needs further review during Last Call, for two reasons: 1. While RFC Required forces new registrations through the IETF RFC process, and might discourage registrations from individuals or organizations that are unfamiliar with or averse to that process, Specification Required necessitates the appointment of a Designated Expert to review the requests and associated specifications. Each of these policies comes with baggage, and we have to make sure we're weighing it down with the *right* baggage. 2. If we stay with Specification Required we should include a short paragraph with rough guidelines for the Designated Expert: what to consider when approving registration requests. If we want the DE to approve most requests, just checking the associated specifications for sanity, we need to say that. If we want the DE to put some judgment into deciding whether the requested parameters make sense and fit into the usage model, or whatever, we should say something about that. Comments and proposed text for this are encouraged. ==================================== |
2012-07-09
|
06 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2012-07-09
|
06 | Barry Leiba | Last call was requested |
2012-07-09
|
06 | Barry Leiba | Ballot approval text was generated |
2012-07-09
|
06 | Barry Leiba | State changed to Last Call Requested from AD Evaluation::AD Followup |
2012-07-09
|
06 | Barry Leiba | Last call announcement was changed |
2012-07-09
|
06 | Barry Leiba | Last call announcement was changed |
2012-07-09
|
06 | Barry Leiba | Last call announcement was generated |
2012-07-09
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-07-09
|
06 | Andreas Petersson | New version available: draft-ietf-appsawg-http-forwarded-06.txt |
2012-07-02
|
05 | Barry Leiba | State changed to AD Evaluation::Revised ID Needed from AD Evaluation |
2012-07-02
|
05 | Barry Leiba | Document shepherd writeup: > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why > is … Document shepherd writeup: > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why > is this the proper type of RFC? Is this type of RFC indicated in the > title page header? This document provides definition of a new HTTP header field, which is targeted at replacing many similar but non standard HTTP header fields. This is targeted at becoming a Proposed Standard, which is appropriate, and which is indicated in the document header. > (2) The IESG approval announcement includes a Document Announcement > Write-Up. Please provide such a Document Announcement Write-Up. Recent > examples can be found in the "Action" announcements for approved > documents. The approval announcement contains the following sections: > > Technical Summary > > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. This document standardizes an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, such as the originating IP address of a request and the IP address of the proxy on the user-agent-facing interface. Given a trusted path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document is meant to replace several ad-hoc solutions already deployed today. > Working Group Summary > > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? Nothing worth noting. > Document Quality > > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? There are several implementations of similar header fields already in use. > Personnel > > Who is the Document Shepherd? Who is the Responsible Area > Director? Alexey Melnikov is the document shepherd. Barry Leiba is the responsible AD. > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. If this version of the document is not ready > for publication, please explain why the document is being forwarded to > the IESG. I've read the whole document and tried to spot inconsistencies between different parts or with documents being referenced. I've also reviewed ABNF and IANA considerations in details. The latter was changed based on my review. > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? The document got lots of review in HTTPBIS WG and APPSAWG. No concern about depth and breadth of the reviews. > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that > took place. The document already got reviews regarding Privacy Considerations. I can't think of another review that needs doing (apart from Directorate reviews that would happen anyway). > (6) Describe any specific concerns or issues that the Document Shepherd > has with this document that the Responsible Area Director and/or the > IESG should be aware of? For example, perhaps he or she is uncomfortable > with certain parts of the document, or has concerns whether there really > is a need for it. In any event, if the WG has discussed those issues and > has indicated that it still wishes to advance the document, detail those > concerns here. No concerns. > (7) Has each author confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 78 > and BCP 79 have already been filed. If not, explain why. Yes. > (8) Has an IPR disclosure been filed that references this document? > If so, summarize any WG discussion and conclusion regarding the IPR > disclosures. No IPR disclosures have been filed on this document. > (9) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? The document has solid WG consensus. > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate > email messages to the Responsible Area Director. (It should be in a > separate email because this questionnaire is publicly available.) No. > (11) Identify any ID nits the Document Shepherd has found in this > document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts > Checklist). Boilerplate checks are not enough; this check needs to be > thorough. idnits 2.12.13 reports no errors/warnings. > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. Expert Review for the Forwarded HTTP header field was requested and the Designated Expert (Graham Klyne) confirmed that the registration is Ok. > (13) Have all references within this document been identified as > either normative or informative? Yes. > (14) Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? If such normative > references exist, what is the plan for their completion? The document references Normatively 2 drafts in the HTTPBis WG. The two referenced drafts are believed to be near completion. All other references are to RFCs. > (15) Are there downward normative references references (see RFC 3967)? > If so, list these downward references to support the Area Director in > the Last Call procedure. There are no DownRefs. > (16) Will publication of this document change the status of any > existing RFCs? Are those RFCs listed on the title page header, listed > in the abstract, and discussed in the introduction? If the RFCs are not > listed in the Abstract and Introduction, explain why, and point to the > part of the document where the relationship of this document to the > other RFCs is discussed. If this information is not in the document, > explain why the WG considers it unnecessary. No. > (17) Describe the Document Shepherd's review of the IANA considerations > section, especially with regard to its consistency with the body of the > document. The document registers a new HTTP header field ("Forwarded") and also creates a new subregistry for Forwarded header field parameters. This is consistent with the body of the document. > Confirm that all protocol extensions that the document makes > are associated with the appropriate reservations in IANA registries. Yes. > Confirm that any referenced IANA registries have been clearly > identified. Yes. > Confirm that newly created IANA registries include a > detailed specification of the initial contents for the registry, that > allocations procedures for future registrations are defined, and a > reasonable name for the new registry has been suggested (see RFC 5226). Yes. > (18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find > useful in selecting the IANA Experts for these new registries. The new registry created by the document specifies an RFC Required policy and doesn't require Expert Review. > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal > language, such as XML code, BNF rules, MIB definitions, etc. The ABNF verifies with BAP (after expanding of the list production defined in HTTPBIS documents). |
2012-07-02
|
05 | Barry Leiba | Changed protocol writeup |
2012-06-30
|
05 | Murray Kucherawy | IETF state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2012-06-30
|
05 | Murray Kucherawy | Annotation tag Doc Shepherd Follow-up Underway cleared. |
2012-06-30
|
05 | Barry Leiba | Ballot writeup was changed |
2012-06-30
|
05 | Barry Leiba | Ballot writeup was generated |
2012-06-30
|
05 | Murray Kucherawy | Submitted to IESG. |
2012-06-30
|
05 | Barry Leiba | State changed to AD Evaluation from Publication Requested |
2012-06-30
|
05 | Barry Leiba | State changed to Publication Requested from AD is watching |
2012-06-28
|
05 | Andreas Petersson | New version available: draft-ietf-appsawg-http-forwarded-05.txt |
2012-06-27
|
04 | Alexey Melnikov | IETF state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2012-06-27
|
04 | Alexey Melnikov | Annotation tag Doc Shepherd Follow-up Underway set. Annotation tag Revised I-D Needed - Issue raised by WGLC cleared. |
2012-06-18
|
04 | Alexey Melnikov | WGLC and document shepherd issues seem to be addressed, working on the document shepherding write-up now. |
2012-06-18
|
04 | Andreas Petersson | New version available: draft-ietf-appsawg-http-forwarded-04.txt |
2012-06-08
|
03 | Andreas Petersson | New version available: draft-ietf-appsawg-http-forwarded-03.txt |
2012-05-29
|
02 | Alexey Melnikov | Annotation tag Revised I-D Needed - Issue raised by WGLC set. |
2012-05-22
|
02 | Murray Kucherawy | IETF state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2012-05-01
|
02 | Alexey Melnikov | IETF state changed to In WG Last Call from WG Document |
2012-04-20
|
02 | Alexey Melnikov | The document needs to be updated as per WGLC comments (e.g. ABNF, Security Considerations). |
2012-04-20
|
02 | Murray Kucherawy | WGLC completed 5/18. |
2012-04-20
|
02 | Alexey Melnikov | Initiated WGLC after the request from one of the authors |
2012-04-20
|
02 | Andreas Petersson | New version available: draft-ietf-appsawg-http-forwarded-02.txt |
2012-03-30
|
01 | Barry Leiba | Responsible AD changed to Barry Leiba from Pete Resnick |
2012-03-26
|
01 | Andreas Petersson | New version available: draft-ietf-appsawg-http-forwarded-01.txt |
2012-03-23
|
00 | Alexey Melnikov | Changed shepherd to Alexey Melnikov |
2012-02-04
|
00 | Pete Resnick | Draft added in state AD is watching |
2012-01-27
|
00 | (System) | New version available: draft-ietf-appsawg-http-forwarded-00.txt |