Subject: Re: [Momipriv] Re: [Mobopts] Privacy BoF Proposal

From: Greg Daley <[email-masked]>
Date: Thu, 23 Jun 2005 04:13:54 +1000

Hi Rajeev, 

----- Original Message -----
[cut]
> > The focus of the proposed work will be on protecting communicating
> > parties' privacy against eavesdroppers and other third parties.
> > Location privacy in the sense of keeping location related 
> information,> such as the IP address, of a mobile party private 
> from the other party
> > is out of scope.  However, location privacy in the sense of 
> keeping a
> > given mobile user's location related information private from such
> > parties that the user is not actively communicating with falls 
> within> the proposed scope.
> >
> The distinction between Location Privacy and Privacy itself is 
> important enough to merit some discussion. "Privacy across layers" 
> is a broader topic that primarily addresses profiling of user
> communication (involving  multiple identifiers).
> From the first sentence of the above paragraph (and from the 
> description below), I understood that ALIEN will focus on just
> that. And, it is   worthwhile IMO.
> The problem of Location Privacy as applicable to _IP_ Mobility
> is primarily concerned with managing disclosure of IP addresses.
> It is a narrower problem.
> And, MobOpts RG has been looking into that, and there are already 
> solutionsavailable. So, I am inclined to suggest that Location 
> Privacy should not be the focus of ALIEN to avoid confusion and to
> foster progress and good  will.  :-)
> I am hopeful that emerging techniques to thwart profiling are also 
> useful for nodes concerned with Location Privacy.

The (probably appropriately) narrow scope of the work which is aimed
for development within Mobopts is actually a really good motivator to
pursue this group as a Location or Locator Privacy group.

It's worthwhile considering that location changes can be divulged across
sets of local access networks, without even needing to run MIPv6.
Existing concerns I have about divulging configuration state in DNA 
would be
helped by a forum where these ideas are being generally discussed.

Again, SHIM6 may be something which doesn't require location privacy,
but may wish to have locator privacy.  In this case, protection of the 
ID-locator split from on-the path eavesdroppers may be useful, even
though mobility isn't a goal.

I don't see this as getting in the way of an RG or WG which wants to 
produce a document on location privacy, any more than the presence of
IPv6 got in the way of MAGMA while it developed MLDv2.

Greg

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

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 22 Jun 2005 11:48:49 -0700

Hi Greg,

Location Privacy with MIPv6 is of immediate interest to MobOpts/MIP6, 
but I am
not suggesting that we limit ourselves to just that.

We need to decide how to go about addressing

1) "privacy across layers" (which is multiple identifier management in 
general), and
2) "location privacy due to mobility" (which is managing specific 
identifiers
     as a function of mobility)

Since MobOpts has already taken up an instance of 2) with identifier = 
HoA/CoA,
we could continue exploring 2) further. If that's not a good idea, 
please (everyone)
share your thoughts.

I support the initiative to study privacy as a research topic.

Regards,

-Rajeev

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 22 Jun 2005 22:09:41 +0300 (EEST)

On Wed, 22 Jun 2005, Rajeev Koodli wrote:

> but I am not suggesting that we limit ourselves to just that.
>
> identifiers as a function of mobility)
>
> HoA/CoA, we could continue exploring 2) further. If that's not a good
> idea, please (everyone) share your thoughts.

=> IMHO, "location privacy due to mobility" is not limited to hiding the
HoA/CoA only. Actually, it is not limited to hiding IP and/or MAC identifiers
only...
IMHO, when you hide the HoA/CoA and leave, for example, the MAC address
disclosed then location privacy can be questioned.

Regards,

Wassim H.

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 22 Jun 2005 15:37:27 -0700

Wassim,

>disclosed then location privacy can be questioned.

Help me understand here a bit. Are you assuming that the MAC Address is 
known, just
as an HoA (or Home Prefix) might be known, as a global identifier whose 
disclosure on a visited network
leads to revealing that some user has roamed? If yes, what mechanisms 
exist on the Internet to know what MAC address is used by a user's device?

Thanks,

-Rajeev

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 23 Jun 2005 18:32:42 +0300 (EEST)

On Wed, 22 Jun 2005, Rajeev Koodli wrote:

> > HoA/CoA only. Actually, it is not limited to hiding IP and/or MAC
> > identifiers only...
> > IMHO, when you hide the HoA/CoA and leave, for example, the MAC
> > address disclosed then location privacy can be questioned.
> >
> known, just as an HoA (or Home Prefix) might be known, as a global
> identifier whose disclosure on a visited network leads to revealing that
> some user has roamed? If yes, what mechanisms exist on the Internet to
> know what MAC address is used by a user's device?

=> IMHO, you are mixing many privacy aspects together. IMHO, Location
privacy, should be viewed only as a *consequence* of providing real
privacy aspects like the anonymity and unlinkability. Based on that,
creating and addressing a problem called "location privacy" seems to me as
trying to solve what you *implicitely* get from solving the real problem,
which is mainly about the anonymity and unlinkability issues.

IMHO, if we look at the IP layer only, then providing anonymity alone will
replace the real IP address with a dynamic pseudo-IDs. However, keeping the
static real MAC address disclosed allows the bad guys to *link* all your
pseudo-IDs together regardless of how frequent the update will be.
IMHO, such possibility and its consequences should not be pushed aside.

In addition to anonymity, providing unlinkability at the IP layer alone,
e.g., if we "unlink" different "items-of-interest" like between the "data
exchange and the subsequent BU/BA exchange" (1) and between the "BU/BA
exchange and the following data exchange" (2) and between all BU/BAs (if
taken alone) (3), then again disclosing the real MAC address breaks
everything on the IP layer and allows to easily correlate between (1), (2)
and (3).

IMHO, the danger of using the MAC address to identify the target and/or to
correlate between different actions is implicitely highlighted in the draft
we've submited:
http://www.sureshk.com/drafts/draft-haddad-privacy-omipv6-anonymity-00.txt

Regards,

Wassim H.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 23 Jun 2005 08:57:21 -0700

Wassam,

I think the problem from the user's (or operator's) standpoint is, in fact,
location privacy. I think we probably need to refine that a little bit to
describe exactly what location privacy means for the Internet. For example,
there is one extreme viewpoint that location privacy requires that the
source address of a packet always be only tracable back to the home
operator's network, i.e. always be the home address, yet still routing of
the packet over the Internet is optimal (not through a home agent or some
routing proxy like a VPN tunnel gateway in the home operator's network),
even if the terminal is roaming in a foreign operator's network. This
definition of location privacy is extremely difficult to do given current
Internet routing technology. There are other definitions of location privacy
that are easier to achieve given current Internet routing technology. And
there are also regulatory and legal constraints on network operators that
require specific levels of location privacy depending on what level of
detail is being revealed. Well, at least there are such regulatory and legal
constraints in Europe and Japan, the situation in the US is so confused so
as to be essentially undefined (don't know about Canada).

I think what you've identified below - anonymity and unlinkability - are
properties of identifiers and protocols that make solution of location
privacy possible. The exact scope of these needs to be defined for any
particular protocol and identifier. Perhaps what a general BOF or WG on
privacy can achieve is to define these more precisely and relate them back
to the user/operator problem. While I think a general BOF or WG might be
able to take a few examples, I think it would be technically risky for such
a group to try to claim to work on location privacy issues for all IETF
protocols, since that really should be the job of the WGs that develop those
protocols.

            jak

----- Original Message ----- 
From: "Wassim Haddad" <[email-masked]>
To: "Rajeev Koodli" <[email-masked]>
Cc: "Greg Daley" <[email-masked]>; <[email-masked]>; "IAB"
<[email-masked]>; "James Kempf" <[email-masked]>;
<[email-masked]>; "Basavaraj Patil" <[email-masked]>
Sent: Thursday, June 23, 2005 8:32 AM
Subject: Re: [Momipriv] Re: [Mobopts] Privacy BoF Proposal

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Jun 2005 22:15:03 +0200

Greg Daley wrote:
...
> though mobility isn't a goal.

Not really. In the shim6 model, the address used as a ULID (upper layer ID)
is simply one of the set of addresses used as alternative locators.
So there realy isn't any value from the privacy point of view of
treating it differently from the other locators in the set. But there are
other reasons why we need to protect the locator set from eavesdroppers,
and that protection may have some security value.

draft-ietf-multi6-hba-00 may be of interest.

   Brian

---

From: Wassim Haddad <[email-masked]>
Date: Sat, 25 Jun 2005 02:57:14 +0300 (EEST)

> draft-ietf-multi6-hba-00 may be of interest.

=> Privacy threats related to static multi-homed nodes are described in
draft-haddad-momipriv-threat-model-00.

Regards,

Wassim H.