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

On 09/04/2011, at 12:08 AM, 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 ]
> 
> To make trouble-shooting and abuse@ processing as simple as possible
> for all law-abiding net-citizens.
> 
> This allows $BIGCORP to cloak their identifiers to avoid leaking
> internal network topology which can be used by criminals, and it
> encourages all 3rd parties (ISP's etc) to provide IP#s for speedy
> resolution of issues.


-1 on this approach; it's a spec (not even technical) solution to a purported legal issue. 

If a proxy doesn't want to leak internal network addresses in requests, IME they'll either a) not add them, or b) strip them at the border. Those that want to track internal requests through a series of devices can either take the (b) approach (which is IME more common, because it's easier to administer) or will identify each node with a pseudonym. This is easy to accommodate in the spec, just as it is for the Via header. 

E.g.,

forwarded-for = 1#( hop *[ ";" parameter ] )
hop = address | pseudonum
pseudonum = token
address = ...

I.e., you don't have to make the header syntactic mush just to make it clear that it doesn't always have semantic integrity.

One of the reasons for allowing extension parameters, btw, is to allow someone to sign the hops if they want to.


--
Mark Nottingham   http://www.mnot.net/

Received on Saturday, 9 April 2011 02:03:24 UTC