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

On Thu, 28 Apr 2011 12:12:03 +0200
Willy Tarreau <w@1wt.eu> wrote:

> On Thu, Apr 28, 2011 at 11:48:36AM +0200, Andreas Petersson wrote:
> > I don't think it would be that much harder to parse out the address
> > family. By specifying family at one place seems strange if you have 
> > incoming on IPv4 and outgoing on IPv6.
> 
> I don't see why. The family is necessarily unique at one step. In fact,
> if a proxy puts you an IPv4 source and an IPv6 destination, how are you
> supposed to parse those addresses ? With an explicit family, at least
> you know which one is wrong.

Yes, sorry, that wasn't really thought through. I still think it might
be redundant information.

> 
> > src/from and dst/to should be unique within one proxy step.
> 
> I'm not sure what you mean here.

There should not be both src6 and src4 present.

> 
> > I also think it is not so much gain by
> > having separate port-parameters. 
> 
> It simplifies parsing as you don't need delimiters. We already know all
> the issues we can encounter with multi-level delimiters. For instance,
> if we make brackets mandatory, an attacker could decide to emit this
> header with a missing closing bracket. The proxy won't care about the
> syntax and will only have to complete the header by adding a new value.
> You'd then have something like this :
> 
> attacker sends :
>   Forwarded: from=[2001::1:2:3
> 
> proxy adds :
>   Forwarded: from=[2001::1:2:3
>   Forwarded: from=[2002::5:6:7]:12345; to=[2002::8:9:A]:80
> 
> which results in :
>   Forwarded: from=[2001::1:2:3, from=[2002::5:6:7]:12345; to=[2002::8:9:A]:80
> 
> It's expected that many server-side parser will parse it that way :
>   from=[2001::1:2:3, from=[2002::5:6:7]:12345
>   to=[2002::8:9:A]:80
> 
> Then they'd strip the address around the first opening bracket and the
> last closing one (strchr/strrchr), and pass their own inet_pton() over
> the result :
>   my_inet_pton("2001::1:2:3, from=[2002::5:6:7")
> 
> They's get 2001::1:2:3, happily ignore the error pointing to the comma
> and result in using the attacker-fed address as the source, with the
> proxy-fed port as the port.

Is this a problem in all other places where you have brackets?
I have hard to believe we can specify the standard in a way that
totally eliminates the need for input sanitation. 

> 
> Last point is that right now apps don't care about the port as it's the
> proxy's role to log it. Apps want the IP address for statistics, tracking,
> gelocation, etc... I predict that if we make it optional, almost nobody
> will enable it because they don't care a dime. Thus, let's not force
> everyone to complexify their parsers because we added information they're
> not interested in.
> 

I can agree to some extent, I see your point. Do others have an opinion
here?


 /Andreas Petersson

Received on Thursday, 28 April 2011 15:05:17 UTC