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