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

From: Karl Dubost <[email-masked]>
Date: Wed, 22 Jun 2011 13:03:29 -0400

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

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 23 Jun 2011 18:40:11 +1200

> 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

---

From: Andreas Petersson <[email-masked]>
Date: Thu, 23 Jun 2011 12:23:10 +0200

On Wed, 22 Jun 2011 13:03:29 -0400

> http://tools.ietf.org/html/draft-petersson-forwarded-for-00

Well. I've done a draft for the BNF-section. I managed to run into
Henrik Nordström from Squid at an IPv6 seminar in Stockholm, so I've
also been discussing somewhat with him.

I will write the draft around a BNF that looks something like this, 
opinions are welcome.

-----
Appendix A.  Forwarded-For BNF definition

   This appendix defines the Forwarded-For header field.

       Forwarded: = "Forwarded" ":" LWS Forwarded-v
       Forwarded-v = 1#kv-v

       kv-v = OWS kv *( OWS ";" OWS kv ) OWS
       kv   = for-kv | by-kv | proto-kv | host-kv | ext-kv | private-kv

       for-kv     = "for=" node
       by-kv      = "by="  node
       proto-kv   = "proto=" ( "http" | "https" )
       host-kv    = "host=" host
       ext-kv     =  extension "=" ext-value
       private-kv = "x-" extension "=" ext-value

       node = nodename [ ":" node-port ]
       nodename = IPv4address | IP-literal |
                   "unknown" | "hidden" | obfnode
       obfnode = "_" 1*( ALPHA | DIGIT )
       node-port = port | obfport
       port = 1*5DIGIT
       obfport = 1*( ALPHA | DIGIT )
       extension = 1*( ALPHA | DIGIT | "-" )
       ext-value = 1*( ... )  ;; FIXME: exclude ; and CRLF

----

Best regards,
 Andreas Petersson,
 Opera Software