Re: WGLC: draft-ietf-appsawg-http-forwarded-02.txt - section 5.2

On Wed, 02 May 2012 14:34:22 +1200
Amos Jeffries <squid3@treenet.co.nz> wrote:
> ** section 5.2
> 
> Now that it is mentioning the X-Forwarded-* class of headers and 
> describing security usage for Forwarded: the document needs a safe 
> mapping from X-Forwarded-For to Forwarded:. I have spent quite a while 
> attempting to iterate the cases and find a safe mapping method for Squid 
> to use mapping the fields of XFF to records in Forwarded:, but there is 
> always one case or other which fails badly.

Section 5.2 doesn't mention X-Forwarded-*.

I think it is a futile effort. In some situation it may be 
possible to find a good way. If you find a solution that works
for you, in your shop, it is of course fine to use it. 
But in general I believe it to be super hard to do it in a good
way -> "implementation specific".


> 
> IMO the mapping should be:
> "
> A recipient of X-Forwarded-For header MUST either, drop all 
> X-Forwarded-For: and Forwarded: headers in the request, or drop the 
> X-Forwarded-For header and place a single obfuscated identifier 
> field-value in the Forwarded: header prior to any other information 
> additions of its own. This must be done before interpreting either 
> header.

Dropping seems strange. I would assume it will be common to add
both headers to be backwards compatible.

> "
> 
> For example:
>   client 1.2.3.4:8765 sending
>     Forwarded: for=[::1]
>     X-Forwarded-For: ...
> 
> becomes:
>    Forwarded: for=[::1], _abc, for="1.2.3.4:8765"

That is not valid syntax.

> 
> 
> This retains the security properties of the XFF header environment 
> because:

I don't think you should use neither XFF nor Forwarded for security,
unless you trust the proxy that adds the header field and knows what
header field that proxy updates. That proxy should probably also drop
previous header fields, but that may also depend on how the values are
used etc.

>   1) Dropping is safe because both these are OPTIONAL headers.

Well, while it is strictly true it is probably undesired to lose that
information.

>   2) Using an obfuscated identifier and retaining the Forwarded: header 
> preserves what information is likely safe but places a blocking step at 
> the position of the un-trustable hop.
> 
> The other X-Forwarded-* headers need a similar security protection 
> fixup in the sections they map into.

To specify in the specification for "Forwarded" how to make a transition
from a header field that is not standardized at all seems both
irrelevant and makes the Forwarded-spec more complex than needed.

If something should be said at all it could be done in a separate
document with informal status.


Best regards,
 Andreas

Received on Friday, 4 May 2012 11:26:57 UTC