W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

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

From: Willy Tarreau <w@1wt.eu>
Date: Fri, 8 Apr 2011 17:36:31 +0200
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Andreas Petersson <andreas@sbin.se>, Mark Nottingham <mnot@mnot.net>, "Thomson, Martin" <Martin.Thomson@commscope.com>, Karl Dubost <karld@opera.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <20110408153631.GD13348@1wt.eu>
On Fri, Apr 08, 2011 at 02:08:09PM +0000, Poul-Henning Kamp wrote:
> In message <20110408153603.6e3f7e2b@hetzer>, Andreas Petersson writes:
> 
> >What do the list think?
> >What parameters would be relevant? ("by"? "port"? "proto"? "host"?
> >other..?)
> 
> I've pondered this some more, and I fear we are headed the wrong way.
> 
> This header, like X-Forwarded-For will become part of the toolbox
> for answering criminal investigations log-requests and similar and
> we must think about it in that light.
> 
> Spoofing X-F-F headers have been used in the past, both to circumvent
> badly thought out security-barriers and generally confuse people
> reading logfiles.
> 
> The IP#'s you receive in such headers from the outside, are only
> badly hashed cryptographic nonces:  You don't need to sit in the
> White House to send an (X-)F-F with IP# 198.137.241.43.
> 
> Nothing is actually won by mandating that they look like IP# in the
> first place, but it is very convenient for well-behaved-net-entities
> that they are IP#, and this probably covers 99.99% of the cases
> where somebody has to deal with them.
> 
> So my considered proposal would be:
> 
> The standard should make this header as a comma separated list of
> identifiers defined like:
> 
> 	1*<any CHAR except LWS and ",">
> 
> The standard should make it very clear that they are nonces which
> can only be correctly interpreted in the context where they were
> created.  (In other words:  A lawyer cannot sue based on the
> identifier, until whoever created it translates its meaning for him,
> even if it looks like an IP number).
> 
> And then we SHOULD strongly encourage that they follow this form:
> 
> 	src-IP ':' src-port [ '/' dst-IP ':' dst-port ]

While I agree with the principle, I would render the port optional.
It's almost always wrong anyway because you have the equipments in
the following order :

   client
   firewall
   load balancer
   reverse-proxy
   ...
   server

The load balancer almost always translates the source port (unless it's
doing DSR, which is progressively disappearing), and nobody car correlate
this source port seen by the reverse-proxy to anything logged anywhere.
So while there are *some* situations where the port can be exploited, i
practice where admins do care about logs, it's meaningless.

Regards,
Willy
Received on Friday, 8 April 2011 15:37:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:39 GMT