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

[Alissa Cooper <[e-mail]>]

Hi Andreas, 

I've included below a version of some privacy text that I provided in section 4 of draft-ietf-intarea-nat-reveal-analysis, adapted for the Forwarded header. Since the privacy implications are so similar, I thought it might make sense to re-use this in some form; feel free to use or tweak as you wish. I have some further notes below.

-----

Privacy Considerations

   The use of web proxies is motivated by a number of different factors.
   While many individual users are unaware of and
   uninvolved in decisions about whether their HTTP traffic passes through one or more proxies, some users realize privacy
   benefits associated with proxy use, and some may even take
   steps to ensure that an anonymizing proxy sits between them and the
   public Internet.  Shared  or anonymizing proxies can make the actions of multiple users
   behind the proxy unattributable to any single host, creating
   room for abuse but also providing some identity protection for non-
   abusive users who wish to transmit data with reduced risk of being
   uniquely identified.

   The Forwarded extension potentially adds a measure of uniqueness
   back to hosts behind proxies.  The extent of that
   uniqueness depends on which information is included in the Forwarded header. [Insert further discussion of uniqueness here if any identifiers other than IP address and port are reasonably expected to be forwarded. See note 1 below.]

   When the Forwarded extension is used to forward a user agent's IP address, the volatility of the header information is the same as the volatility of the user agent's IP address: the information in the header may change when the user agent's IP address changes.  User agents with persistent IP addresses will be persistently trackable by any recipient of the Forwarded header.

   As a general matter, the Forwarded extention does not seek to make hosts
   any more identifiable than they would be if their traffic were not passing through a proxy. [Wondering if there are corner cases here. See note 2 below.]

   The trust placed in the information conveyed by the Forwarded extension is likely
   to be the same as for current practices with source IP addresses.  In
   that sense, a forwarded IP address can be spoofed.  Furthermore, users of anonymous proxies may be capable of stripping forwarded
   information before it reaches its destination.

-----

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.

2. I'm wondering if, in addition to the information leak problem discussed in 8.2, there is also an issue of distinguishability of multiple users who are all behind the same NAT/proxy but may not all be behind the same chain of proxies. That is, suppose A and B are the only two hosts behind a particular NAT and A installed the NAT to help protect his identity. B's traffic passes through 2 further proxies that use Forwarded headers before arriving at C. A's traffic passes through no proxies to arrive at C. C can now effectively identify A. This is just one case -- I'm not sure how realistic it is, but I'm sure there are others. Seems like this is worth more thought/discussion in the text.

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?

4. It might be helpful to take a look through <http://tools.ietf.org/html/draft-iab-privacy-considerations-02#section-5> -- I haven't had time to think through all the questions listed.

Cheers,
Alissa  

On May 14, 2012, at 7:07 PM, SM wrote:

> Hi Stephen,
> At 15:22 14-05-2012, Stephen Farrell wrote:
>> IMO, if we standardise that kind of middlebox feature
>> then there's an onus on us to think about how it might
>> affect the endpoints, one of which in this case has
>> a warm body attached often enough to count.  (I think
>> there was an IAB RFC saying that some time back, can't
>> recall the number now though, and a quick look didn't
>> find it sorry.)
> 
> It's related to the OPES work (RFC 3238).  That RFC introduced the notion of one-party consent.  Given existing legislation, e.g. EU directive about privacy, this is not simply a matter of adding a header.
> 
> Regards,
> -sm 
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>