Re: [apps-discuss] Comments on draft-ietf-appsawg-http-forwarded-02

[Alissa Cooper <[e-mail]>]

Hi Andreas,

A few responses inline.

On May 18, 2012, at 11:45 AM, Andreas Petersson wrote:
>> Notes:
>> 
>> 1. Section 5.2 says that the typical value of the forwarded-for
>> parameter is an IP address but that it MAY be some other kind of
>> identifier. What other identifiers might it be? Are there any
>> identifiers that should be taken off the table (e.g., subscriber
>> IDs, MAC addresses, credit card numbers)? Obviously some of these
>> are more likely to have value than others but I think it's
>> important to scope this if possible. Just because a proxy may know
>> some persistent host identifier doesn't mean it should be forwarded
>> around in an HTTP header.
> 
> Essentially, any token you like that fits in the obf-node. What this
> translates depends highly on the environment.
> Of course some things are more suitable than others to use as
> identifier. Putting a credit card number there and send it around the
> Internet seems stupid. I don't believe someone will do that, and if
> they would, the would do it regardless of this header field.

So, is there some recommendation you can make to limit the scope of identifiers? Or to caution against the use of permanent, unique identifiers in public network environments?

> 
>> 3. In general it seems like somewhere -- not sure if it should be
>> here, or in the nat-reveal draft, or somewhere else -- the
>> interactions between different mechanisms for IP address hiding and
>> sharing need to be addressed. For example, if my request goes
>> through multiple middleboxes that implement the TCP option for
>> nat-reveal
>> (http://tools.ietf.org/html/draft-wing-nat-reveal-option-03) and
>> then hits an HTTP proxy, can I expect the proxy to take my IP
>> address out of the TCP option and insert it into a Forwarded
>> header? If I want to hide my IP address from the combination of
>> these mechanisms, what do I need to do?
>> 
> 
> I don't think you can expect anything. The fact is that a lot of
> proxies are already adding X-Forwarded-For header field though. This
> is only a formal specification of that, with extra features.

Obviously people will implement and use all kinds of features as they wish, but the formal specification phase is often a good time to assess the consequences of widespread implementation and use.  If discussing those consequences here causes some implementers and users to be more thoughtful about the privacy impact of what they do, that's an additional benefit of standardization.

Alissa