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

On Fri, Apr 8, 2011 at 1:12 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> In message <20110408195627.GB15625@1wt.eu>, Willy Tarreau writes:
>>On Fri, Apr 08, 2011 at 07:42:54PM +0000, Poul-Henning Kamp wrote:
>
>>Most people would not even know [...]
>
> That should not cause us to write standards that make life impossible
> for the people who do know and who do have the need.
>
>>The SHOULD was for us to encourage pushing the format. I'm discussing
>>the proposed format. I'd rather see :
>>
>>   src-IP [ ':' src-port ] [ '/' dst-IP ':' dst-port ]
>>
>>Which also happens to be compatible with current uses.
>
> There is no current uses of "Forwarded-For", backwards compatibility
> therefore does not prevent us from doing it right.

I look at it a bit differently: there are many current uses of
Forwarded-For.  Every web proxy I've seen in the past decade uses it,
every web server has an option to log it, and every nontrivial web
analytics system parses it.  They all do expect the "X-" in front,
though.  The rollout of a naming change will be difficult; I
anticipate that proxy servers will end up sending both X-Forwarded-For
and Forwarded-For for many years.  That might be inevitable, but it
brings to mind two concerns:
- People who plan to log Forwarded-For data for forensic purposes will
need to keep logging X-Forwarded-For as well.
- X-F-F values can get somewhat large, and sending the value twice
(once as X-F-F and once as F-F) will help push more requests past 1MSS
in size, resulting in an extra round-trip delay in cases where the
proxy does not already have an established connection to the
destination.

I don't think either of those points is a show-stopper for
Forwarded-For, but they're nontrivial implementation challenges.

With regard to src-port, I think it should be optional.  Here's my rationale:

Pragmatically speaking, some non-empty subset of the people who run
proxy servers are going to have valid reasons why they can't share
clients' source ports with a third party destination server.  Here are
a couple of examples that come to mind:
- You operate an online business in a jurisdiction where IP addresses
are considered PII.  Your published privacy policy tells users that
you reveal their IP address to various 3rd parties as a necessary part
of whatever service you provide; on the back end, your application
makes HTTP calls to various service providers and sends the client's
address in the X-F-F.  As you read the release notes for the latest
version of your proxy software, you notice that it now can send source
port along with source address in the F-F header.  You ask your
organization's legal counsel for guidance, and their response is,
"that's a grey area, so we'd want to update the privacy policy in
advance of implementing the change," and so you back off on sending
src-port.
- You run multiple tiers of caching servers as part of an ISP or CDN.
You're willing to expose your internal proxies' IP addresses in the
X-F-F headers you send to 3rd-party web servers, because you've found
that the troubleshooting benefits outweigh the risks of that
transparency.  You decide not to also expose source ports, though,
because you don't want 3rd-parties attempting to deduce request rates
or concurrent connection counts within your internal infrastructure by
studying source port numbers for the hops between your proxy tiers on
successive requests.

For cases like these, it seems preferable to let implementations send
src-IP without src-port, rather than to making them choose between
"src-IP ':' src-port" or "no F-F header whatsoever."

-Brian

Received on Friday, 8 April 2011 22:50:35 UTC