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

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.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Friday, 8 April 2011 14:08:33 UTC