Subject: ID draft-petersson-forwarded-for-02.txt

From: Andreas Petersson <[email-masked]>
Date: Thu, 17 Nov 2011 17:44:19 +0100

Hi,
new draft submitted.

http://www.ietf.org/id/draft-petersson-forwarded-for-02.txt

Changes from last version:

B.2.  Since draft-petersson-forwarded-for-01

   Removed "x-" from private extensions.

   Allow for any protocol name.

   Rename kv-v to forwarded-element and kv to forwarded-value.

   Add informative reference RFC6269.

Best regards,
 Andreas Petersson

PS.
Do anyone know how to force a page break
within <back></back>, in this case between
references and appendix A?

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 18 Nov 2011 19:12:52 +1300

On 18/11/2011 5:44 a.m., Andreas Petersson wrote:
> within<back></back>, in this case between

There have been two things bothering me about this draft for a while and 
I have not been able to find the right words to express it clearly. So 
apologies if this is a bit fuzzy.

Firstly, why the case for "unknown", "hidden" and obscured tokens.  
Essentially "hidden" overlaps with obscured, except the cases where it 
overlaps with "unknown". Would you agree with making it "_hidden", and 
mentioned as an example case in 6.4 ?

The other thing, is that by name it appears superficially to be an 
upgrade of X-Forwarded-For from Squid. Giving it a lot of consideration 
as such I have come down to the conclusion that the cases where they are 
a great danger of corrupting each other are many and the ways they can 
be used together are few.

I propose mandating that the X-Forwarded-For header MUST NOT be sent by 
any software sending the Forwarded-For header. Probably under security 
considerations since XFF is use securtiy checks very often.  It seems 
fairly safe to hash the XFF header and insert an obscured _hash token 
into Forwarded-For marking a point where the data chain became broken. 
Then erasing the received XFF header.

As far as I can tell all other possible avenues of importing the XFF 
relay trail into Forwarded-For lead to header corruption one way or 
another as the request hops between chains of new and old software (new 
being the Forwarded-For aware proxies). If anyone has other ideas for a 
safe algorithm I'd welcome the input.

AYJ

---

From: Andreas Petersson <[email-masked]>
Date: Tue, 22 Nov 2011 15:35:21 +0100

On Fri, 18 Nov 2011 19:12:52 +1300
> mentioned as an example case in 6.4 ?

Agree, we can mention "_hidden" as an example for obfuscated a token.

> safe algorithm I'd welcome the input.

Both X-Forwarded-For and Forwarded will likely be emitted when you have
no idea about the log capabilities at the receiving end.
Forcing the X-Forwarded-For to be removed will make the upgrade path
harder. 
You should probably be allowed to prepend (after a comparison with
Forwarded) the X-Forwarded-For entries to the Forwarded, though.
You should not trust neither X-Forwarded-For or
Forwarded for security checks unless you have a certain level of
control for the whole chain. If you have that control you should also
know what headers are being sent.

 /Andreas Petersson