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

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.

> src/from and dst/to should be unique within one proxy step.

I'm not sure what you mean here.

> 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.

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.

Regards,
Willy

Received on Thursday, 28 April 2011 10:13:04 UTC