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

On Fri, Apr 08, 2011 at 03:58:45PM +0000, Poul-Henning Kamp wrote:
> In message <20110408153631.GD13348@1wt.eu>, Willy Tarreau writes:
> >On Fri, Apr 08, 2011 at 02:08:09PM +0000, Poul-Henning Kamp wrote:
> 
> >> 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.
> 
> You overlooked the bit about it only having meaning in the context
> where it was generated.  To derive that meaning, you will need to
> investigate logs from firewalls, load balancers and everything else.

Except that you will hardly find a product which logs a source port which
is randomly choosen by either the system or the lower layers for an outgoing
connection.

I completely agree with you concerning the context where the information
was generated. It's just that contexts where the port is meaningful are
very rare, and as such, making it mandatory is counter-productive and can
be misleading.

> But IP+port is what identifies the far end, and is the only handle
> you can give the police for the remote end.  What the remote end
> or the police can do with it, is their problem

For the remote end I agree. I was talking about the information which is
already corrupted on your own side before the correct one was logged.

> So we should log the port number, always.

I simply disagree here with "always".

Willy

Received on Friday, 8 April 2011 16:13:20 UTC