Re: I-D draft-petersson-forwarded-for-00.txt

On 23/06/11 05:03, Karl Dubost wrote:
> Hi Andreas,
>
> Le 7 avr. 2011 à 05:32, Andreas Petersson a écrit :
>> I recently submitted a draft for standardizing a replacement for the
>> X-Forwarded-For header field.
>
> Did you have time for a second version?
>
> For the group
> http://tools.ietf.org/html/draft-petersson-forwarded-for-00
>

Sticking my head out as the person who formalized the Squid 
X-Forwarded-For security model.

  (I read some rumours that XFF was created by my predecessors here in 
Squid years back. I have not been able to verify that. If you of your 
experts knows better please educate me.)


Nit:

Reminder to the authors that the BNF for IPv6 permits localhost port 80 
to be written "::1:80". Requiring IPv6 wrapped in [] is fine since this 
is a new header name. I dislike port being present but not strongly 
enough to object loudly.


Nit:

As currently written the draft omits two of the current practice use 
cases for the X-Forwarded-For header.

The XFF handling cases in Squid today are:
    1) MAY erase the header entirely
    2) MAY omit adding the header
    3) MAY pass the header through unchanged IF trust of the received 
content is warranted.
    4) otherwise MUST add the direct client IP address or the 
obfuscation text "unknown" when a valid IP cannot be determined.

The draft currently omits points (2) and (3) but hints at them under 
security considerations section 7.


Nit:

I like "hidden", but am not sure of its potential uptake. Anonymity 
people have a history of choosing full erasure even when "unknown" was 
offered. Most point out websites such as whatismyip indicating "you are 
using a proxy at IP a.b.c.d" when it finds "unknown,a.b.c.d" in the header.

Also it overlaps with section 5.4 obfuscated node. Why not define 
example obfsnode tokens "_hidden" and "_unknown"? or even just "_" by 
itself.


Nit:

I'm not sure if its appropriate. But if possible can you add a MUST to 
the security considerations of section 7.1.

  If an agent does choose to verify and whitelist the chain and is 
unable to verify trust of any given token it MUST ignore the entire set 
of earlier (left-wise) tokens. This is necessary to avoid the most 
blatant security problems created by forgery and the section 5.4 
obfsnode tokens.


AYJ

Received on Thursday, 23 June 2011 06:40:56 UTC