Subject: [Mip6] some comments on draft-ietf-mip6-location-privacy-ps

From: Jari Arkko <[email-masked]>
Date: Sun, 02 Jul 2006 23:01:27 +0300

I happened to read this draft today and had a few comments:

>    This document is only concerned with IP Address Location Privacy in
>    the presence of IP Mobility, as applied to Mobile IPv6.  It does not
>    address the overall profiling problem.  Specifically, it does not
>    concern itself with MAC addresses.  Some other work may address the
>    problem of profiling IP and MAC identifiers (see for instance [1]).

This reads a little bit like MAC addresses would be the only problem.
I presume that there are other location privacy issues beyond those
listed in this draft, and that there are plenty of other privacy issues.
Suggested rewrite:

   This document is only concerned with IP address location privacy in
   the context of Mobile IPv6.  It does not address the overall privacy
   problem. For instance, it does not address privacy issues related to
   MAC addresses or the relationship of IP and MAC addresses [1].

>    Location privacy may be compromised if an on-looker is present on
>    the MN - HA path (when bidirectional tunneling is used), or when the
>    on-looker is present on the MN and CN path (when route optimization
>    is used).

This needs to be explained in more detail. From what I can see,
location privacy is always revealed on the mn-ha path, given the
location of the various options and headers in the binding updates.
You should also talk about the effect or lack thereof of applying
ESP with encryption.

>  Whenever it is involved
>    in IP communication, its correspondents can see an IP address valid
>    on the home network.  Elaborating further, the users involved in peer
>    - peer communication are likely to see a user-friendly identifier
>    such as a SIP URI, and the communication end-points in the IP
>    stack will see IP addresses.  Users uninterested in or unaware of
>    IP communication details will not see any difference when the MN
>    acquires a new IP address.  Of course any user can ``tcpdump'' or
>    ``ethereal'' a session, capture IP packets and map the MN's IP
>    address to an approximate geo-location.  When this mapping reveals a
>    ``home location'' of the user, the correspondent can conclude that
>    the user has not roamed.

This does not appear to follow. Assuming there's bidirectional tunneling
going on, the user is unaware of possible roaming.

>    The above description is valid regardless of whether a Home Address
>    is static or is dynamically allocated. 

Hmm... this seems to need more explanation or perhaps a more in-depth
treatment. Getting a dynamically allocated home address is similar to
running RFC 3041. If you do that, and employ different care-of addresses
for your different communications, it seems that you will be able
provide better location privacy protection, no?

>    Finally, it is also worthwhile to note that both the Home Address
>    and the Care of Address could be subject to profiling, just as
>    any other user traffic.  However, applying existing techniques to
>    thwart profiling may have implications to Mobile IPv6 signaling
>    performance.  For instance, changing the Care of Address often would
>    cause additional Return Routability and binding management signaling.
>    And, changing the Home Address often has implications on IPSec
>    security association management.  These issues need to be addressed
>    in the solutions.

Need to be? Perhaps the conclusion is a bit too quick. Changing
care of addresses "often" for privacy reasons would probably be
either much less often that a fast moving mobile node makes handovers,
or at least fairly infrequent, so is there need for optimizing the process?

The specific issue with IPsec SA management probably needs to
be spelled out too. For instance, if you used the same IKE SA for
everything, it would be kind of silly to worry about privacy. So
that implies multiple IKE SAs.

>  IPSec

IPsec

Missing stuff: I would have expected a good summary of conditions under
which location privacy is not a problem and a set of recommendations
on how networks and policies should be set up to prevent location
disclosure.

--Jari

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 4 Jul 2006 17:24:04 +0300 (EEST)

Hi,

Just to mention that tracking the BU messages via the sequence number is also
one efficient way to link BU messages together and also to learn different
pseudo-HoA(s) and build a profile of the user. Correlating between these
data and other info accumulated from other observations (e.g., if we take
into consideration that most mobile devices will also have a WLAN interface
with possibly a static MAC address) may lead to breaking the user's privacy...

IMHO, it makes sense to mention this issue in a "problem statement" draft
regardless if there is (or not) a solution.

Regards,

Wassim H.

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 05 Jul 2006 11:04:07 -0700

Hi Jari,

>   MAC addresses or the relationship of IP and MAC addresses [1].
Okay.

>You should also talk about the effect or lack thereof of applying
I would like to be clear about one thing. We are dealing primarily with 
HoA and CoA revealing
here. These are the "identifiers" whose disclosure leads to compromise 
in location privacy. The
other parameters by themselves are either not enough to compromise 
location privacy or are essentially
the same as the general "profiling" problem.

So, on the MN-HA path, if the HoA is revealed, yes, that would lead to a 
compromise in location
privacy.

The other thing I would like to mention is that the specifics of use of 
ESP etc are solutions. I am
hoping to produce a crisp problem statement document.

>going on, the user is unaware of possible roaming.
This paragraph is about the user being at home though.."Consider a 
Mobile Node at its home network..."

It's only saying that a user has to be able to actually see the IP 
address beyond the user
identifier (such as a SIP URI) and map that IP address a geo-location to 
know where the user is.

>provide better location privacy protection, no?
The sentence above ("The above description is valid ..") is used in the 
context of the rest of the
section. It is saying that the granularity of mapping the HoA (either 
dynamically assigned or statically
assigned) to a geo-location is almost the same (which is stated in the 
sentence that follows the above
sentence). This is because the network prefix maps to the same physical 
location.

It's the same thing with 3041. When you combine that with different 
CoAs, it does not change the
problem fundamentally; it's perhaps one way to deal with the problem. 
The basic problem is:

- revealing HoA with global scope, no matter how it is assigned, to an 
on-looker compromises
  location privacy.
- revealing CoA together with HoA reveals to a CN that the MN has 
roamed. Does not matter
  how they are assigned.

>or at least fairly infrequent, so is there need for optimizing the process?
Ah, if the CoA change does not happen often, there is nothing to do. 
Agree that there is no need
to optimize the process. The intention was to note the cost of changing 
the CoA and HoA.
How about the reword of the last sentence:

"Solutions should be careful in considering the cost of change of either 
CoA or HoA on signaling.
For instance, changing the Care of Address often would cause additional 
Return Routability and
binding management signaling. And, changing the Home Address often has 
implications on IPsec
 security association management. These issues need to be addressed in 
the solutions."

>that implies multiple IKE SAs.
Would you consider this a "profiling" problem or "location privacy" 
problem?

>IPsec
noted.

>on how networks and policies should be set up to prevent location
The recommendation is what I am hoping the solutions draft will provide.
Compared to privacy at large, Mobile IP introduces a specific problem 
due to the use of HoA and CoA.
When a global identifier such as HoA is used from visited networks, 
on-lookers can figure out
roaming. When HoA is used in conjunction with CoA, a CN can figure out 
that the MN has
roamed. This specific problem is what this ID is trying to specify.

I see the above problem existing wherever Mobile IP is supported 
regardless of network
conditions. We can issue guidelines such as "use ESP in reverse 
tunneling to hide HoA", and that's
what I am hoping to have in the solutions document (which will also 
address route optimization's
implications).

Thanks for your input.

-Rajeev

---

From: Jari Arkko <[email-masked]>
Date: Thu, 06 Jul 2006 22:30:40 +0300

Hi Rajeev,

Thanks for your quick response.  I'm continuing the discussion
inline for the remaining points:

> I would like to be clear about one thing. We are dealing primarily
> with HoA and CoA revealing
> So, on the MN-HA path, if the HoA is revealed, yes, that would lead to
> a compromise in location
> privacy.

I don't think you can entirely get away from the identity privacy problem.
Any disclosure of the host's identity may lead to a location privacy
problem,
if the attacker can associate your identity with the different traffic
streams
at different places.

But I agree that you need to draw a line somewhere where you stop
describing the details. But please provide some details at least
as examples. For instance, you could mention HAO, IPsec/IKE SPIs,
the use of the same IID, etc.

> The other thing I would like to mention is that the specifics of use
> of ESP etc are solutions. I am

Yes, indeed it is useful to avoid going into the solution space. However,
I would like the document to talk about the properties and possibilities
of *current* solutions. E.g., if you configure your network this way then
it implies that for the location privacy. Such a description is very useful
when evaluating the need for future solutions in this space.

> Mobile Node at its home network..."

Ah, I see. Perhaps you could delete the sentence about the
correspondent node's conclusion.

> The sentence above ("The above description is valid ..") is used in
> the context of the rest of the
> sentence). This is because the network prefix maps to the same
> physical location.
>

Right, I see.

But location privacy problem doesn't exist in a vacuum. Whether you can
associate the location to a useful identity is the question. If you
change your
global identifier, then according to the definition you have in Section
1 there
appears to be no problem.

> to optimize the process. The intention was to note the cost of
> changing the CoA and HoA.
> "Solutions should be careful in considering the cost of change of
> either CoA or HoA on signaling.
> For instance, changing the Care of Address often would cause
> additional Return Routability and

This is better, but I would still like to see more discussion of what
situations current solutions can and can not handle.

> Would you consider this a "profiling" problem or "location privacy"

The SA management is basically a profiling problem. But if you
explain what current mechanisms can do for the protection of
your location privacy, you may end up explaining that changing,
e.g., home address is not sufficient if you still use the same IKE SA.

> address route optimization's

Ah. Is there a MOBOPTS solution draft that I can go read?

Many of my issues above are related to the scope of the document,
and they go away if we only define the problem without considering
to what extent it can be mitigated with the current Mobile IPv6 protocol.
I think the document would be more useful, if it did the latter. But we
can talk about that.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Fri, 7 Jul 2006 15:51:55 -0700

>   MAC addresses or the relationship of IP and MAC addresses [1].

I would recommend saying "location privacy" here. I think there is a 
distinction between location privacy and privacy in general. Privacy in 
general is a much larger topic, which this draft doesn't really address.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 07 Jul 2006 16:50:24 -0700

Hi Jari,

yes, there is a MobOpts solutions document. It is addressing the problems
specified in the ps document.

Regarding scoping, I see your point. What you can do with current MIP6
protocol is to use reverse tunneling with ESP. However, with RR and BU/BAck
messages, you do expose the HoA. Beyond that, I am open to your thoughts
on what could be done with current protocol.

more comments inline..

>the use of the same IID, etc.
Ok. This is the profiling of fixed fields. I will write some text. If 
you have something in
mind, that's welcome too :-)

>when evaluating the need for future solutions in this space.
Could you elaborate further?

(I think the primary problem here is the disclosure of HoA and CoA. 
These are the addresses
which have global scope and are specific to MIP. And, they can 
compromise location privacy.
I don't know what kind of network settings you have in mind which would 
allow hiding them)

>correspondent node's conclusion.
Ok, I will see how to rephrase it.

>appears to be no problem.
You could change HoA, but if the network prefix maps to a known 
location, then you can figure
out that some user from ISP X has roamed to network Y.

>situations current solutions can and can not handle.
hmm.. There are two issues here. First, what's the problem. And, second, 
what are the existing
solutions. Are you saying that the problem does not exist under certain 
assumptions or or you saying
there are solutions? If it's the latter, I agree; and the scope of this 
document is to merely specify the
problem and leave out existing and possibly new mechanisms to the 
solutions draft.

>e.g., home address is not sufficient if you still use the same IKE SA.
In that case, how is the problem specific to MIP6? (I realize MIP6 uses 
IKE, but so do many
other protocols).

>Ah. Is there a MOBOPTS solution draft that I can go read?
draft-irtf-mobopts-location-privacy-solutions-02.txt

It still needs work. And, your input here is useful.

>I think the document would be more useful, if it did the latter. But we
Right. The scope I have assumed is primarily MIP6 addresses and location 
privacy. In the solutions
document, we are considering the implications of profiling fields such 
as the Sequence Number.
I tend to think that the solutions, including the existing ones, belong 
to the solutions document. So, if we
agree on the problems here, I think we can happily consider the 
solutions in the mobopts document.

Regards,

-Rajeev