On 5/17/12 11:29 PM, Alissa Cooper wrote:
> 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
Thanks for your text. We will consider this when we write our privacy
> 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.
> 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.
This sounds very confused.
C can probably also distinguish A from client headers. Installing a
NAT in order to protect his identity seems also very strange (with
that few users).
> 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
> (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.
If you weren't using any proxy at all, you can't hide your address, of
course. So if you use a proxy, that is not under your control, it is
likely that the proxy administrator do not want to hide your real
address. If he hides your address it is more likely he gets more
However, if he is aware of that, and want to provide you an
anonymizing service, he can just choose not to add any Forwarded-header.
So, if you do not want your address to be revealed after a proxy, make
sure that you use a proxy that has the purpose of being anonymizing.
You must also make sure that you trust the administrator of that proxy
not to leak logs files etc in any other way.