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

On 18/11/2011 5:44 a.m., Andreas Petersson wrote:
> 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?
>

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

Received on Friday, 18 November 2011 06:13:46 UTC