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

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

Hi Rajeev,

----- Original Message -----
From: Rajeev Koodli <[email-masked]>
[cut]
> I was commenting on the proposal for which you have added the 
> "architectural"
> viewpoint.. IMO, we lack a consensus on what privacy means. So, my 
> steps 
> would
> be:
> 
> 1. Have folks talk about what privacy means. The result should be 
> a problem
>    definition folks have consensus on.
> 2. Identify what could be done. This would be a "framework" or 
> "architecture" sort
>    of discussion if my understanding of the breadth of the 
> problem is 
> even partially accurate.
> 3. Identify specific protocol interactions. And, take them to 
> respective 
> IETF WGs or spin out
>    new ones if there is interest.
> 
> Location Privacy is more to do with disclosing identifiers to both 
> on-lookers and (unacquainted) correspondents. As such, I agree
> it also belongs in the "architecture" discussion, but I am not
> sure if ALIEN is shooting itself for that. 
> Location Privacy with Mobile IPv6, as we agree, is an even narrower
> problem which we are considering in MobOpts.

I guess this is a fair approach.

I'd like some location privacy aspects to be covered 
architecturally in ALIEN.

Greg

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

---

From: "COMBES Jean-Michel RD-MAPS-ISS" <[email-masked]>
Date: Fri, 24 Jun 2005 20:25:39 +0200

Hi,

I mainly agree with James but I think too that the role of such a WG/BoF is too watch interoperability between the solutions proposed in each WG: it would be useless to see that MIPv6 privacy doesn't work when the MH is in a NEMO network because the MR sends the real location of the MH using RO protocol or a MR, which is a MH too, cannot use NEMO privacy solution with MIPv6 solution at the same time - this are just assumptions of course :)

JMC.

France Telecom - R&D Division - MAPS/NSS   
Jean-Michel COMBES, Internet/Intranet Security
E-Mail: [email-masked]
Phone: +33 (0)1 45 29 45 94
Fax: +33 (0)1 45 29 65 19
Mobile: +33 (0)6 07 29 30 16 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de James Kempf
> Envoyé : jeudi 23 juin 2005 17:57
> À : Wassim Haddad; Rajeev Koodli
> Cc : Basavaraj Patil; IAB; [email-masked]; Greg Daley; 
> [email-masked]
> Objet : Re: [Momipriv] Re: [Mobopts] Privacy BoF Proposal
> 
> 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
> 
> 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
> 
> 
> > On Wed, 22 Jun 2005, Rajeev Koodli wrote:
> >
> > > >=> 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.
> > > >
> > > 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?
> >
> > => 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-anon
> ymity-00.txt
> >
> >
> > Regards,
> >
> > Wassim H.
> >
> >
> >
> > > >>Greg Daley wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Hi Rajeev,
> > > >>>
> > > >>>>>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
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > >
> > >
> > >
> >
> 
> 
> Momipriv mailing list
> [email-masked]
> http://lacnic.net/mailman/listinfo/momipriv
>