From jeanmichel.combes at francetelecom.com Tue Jun 21 10:15:20 2005 From: jeanmichel.combes at francetelecom.com (COMBES Jean-Michel RD-MAPS-ISS) Date: Tue Jun 21 10:48:20 2005 Subject: [Momipriv] RE: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement Message-ID: Hi Rajeev, I think you forgot these IDs: draft-haddad-momipriv-problem-statement-01.txt draft-haddad-momipriv-threat-model-00.txt which are, in my point of view, maybe what you are looking for :) BTW, will there be a MomiPriv session (BOF/BarBOF/...) during the next IETF meeting? Regards. JMC. France Telecom - R&D Division - MAPS/NSS Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16 ________________________________ De : mobopts-bounces@irtf.org [mailto:mobopts-bounces@irtf.org] De la part de Rajeev Koodli Envoy? : mercredi 15 juin 2005 20:26 ? : mobopts@irtf.org Cc : Gopal Dommety; Basavaraj.Patil@nokia.com Objet : [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement Hello folks, we need to produce a problem statement document (for the MIP6 WG). Just to recap, the problems we are looking into are: - concerns from disclsoing the Home Address to an on-looker when on a visited network - concerns from disclsoing that the MN (user) has roamed to a new network to a correspondent Following are the relevant IDs that describe the solutions. As a first step, we need a succint problem statement document. We will get to the solutions once the problem statement is defined. draft-qiu-mip6-hiding-movement-00.txt draft-zhao-mip6-rr-ext.01.txt draft-dupont-mip6-privacyext-00.html draft-koodli-mip6-location-privacy-solutions-00.txt In the interest of time, I am proposing that we use the existing problem statement document draft-koodli-mip6-location-privacy-00.txt. All input, especially text, is welcome to improve the draft. Comments? -Rajeev From whaddad at tcs.hut.fi Tue Jun 21 11:32:33 2005 From: whaddad at tcs.hut.fi (Wassim Haddad) Date: Tue Jun 21 11:56:18 2005 Subject: [Momipriv] RE: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement In-Reply-To: References: Message-ID: Hi Jean-Michel, On Tue, 21 Jun 2005, COMBES Jean-Michel RD-MAPS-ISS wrote: > Hi Rajeev, > > I think you forgot these IDs: > draft-haddad-momipriv-problem-statement-01.txt > draft-haddad-momipriv-threat-model-00.txt > > which are, in my point of view, maybe what you are looking for :) > BTW, will there be a MomiPriv session (BOF/BarBOF/...) during the next IETF meeting? => Yes there will be a BoF. Regards, Wassim H. From kempf at docomolabs-usa.com Tue Jun 21 13:53:21 2005 From: kempf at docomolabs-usa.com (James Kempf) Date: Tue Jun 21 13:52:21 2005 Subject: [Momipriv] Re: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement References: Message-ID: <057601c57681$bfbadb40$016115ac@dcml.docomolabsusa.com> Is there a mailing list or proposed agenda? Or will the discussion be part of mobopts? Also, I believe if I recall correctly that draft-haddad takes a more comprehensive approach than draft-koodli to the problem. Is the BOF to be restricted to "what are the problems in the current MIP6 protocol with location privacy" or is it rather to be more comprehensive? If the latter, there are some issues that I think are not in either draft that I would like to see discussed. jak ----- Original Message ----- From: "Wassim Haddad" To: "COMBES Jean-Michel RD-MAPS-ISS" Cc: "Gopal Dommety" ; ; "Rajeev Koodli" ; ; Sent: Tuesday, June 21, 2005 7:32 AM Subject: RE: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement > Hi Jean-Michel, > > On Tue, 21 Jun 2005, COMBES Jean-Michel RD-MAPS-ISS wrote: > > > Hi Rajeev, > > > > I think you forgot these IDs: > > draft-haddad-momipriv-problem-statement-01.txt > > draft-haddad-momipriv-threat-model-00.txt > > > > which are, in my point of view, maybe what you are looking for :) > > > BTW, will there be a MomiPriv session (BOF/BarBOF/...) during the next IETF meeting? > > => Yes there will be a BoF. > > > Regards, > > Wassim H. > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > From kempf at docomolabs-usa.com Tue Jun 21 13:48:08 2005 From: kempf at docomolabs-usa.com (James Kempf) Date: Tue Jun 21 14:14:57 2005 Subject: [Momipriv] Re: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement References: Message-ID: <056701c57681$05665b20$016115ac@dcml.docomolabsusa.com> Right, I think we need to at least make sure that the problem statement drafts draft-haddad and draft-koodli are merged so that issues covered in both are included in the WG draft. jak ----- Original Message ----- From: "COMBES Jean-Michel RD-MAPS-ISS" To: "Rajeev Koodli" ; Cc: "Gopal Dommety" ; ; Sent: Tuesday, June 21, 2005 6:15 AM Subject: RE: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement Hi Rajeev, I think you forgot these IDs: draft-haddad-momipriv-problem-statement-01.txt draft-haddad-momipriv-threat-model-00.txt which are, in my point of view, maybe what you are looking for :) BTW, will there be a MomiPriv session (BOF/BarBOF/...) during the next IETF meeting? Regards. JMC. France Telecom - R&D Division - MAPS/NSS Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16 ________________________________ De : mobopts-bounces@irtf.org [mailto:mobopts-bounces@irtf.org] De la part de Rajeev Koodli Envoy? : mercredi 15 juin 2005 20:26 ? : mobopts@irtf.org Cc : Gopal Dommety; Basavaraj.Patil@nokia.com Objet : [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement Hello folks, we need to produce a problem statement document (for the MIP6 WG). Just to recap, the problems we are looking into are: - concerns from disclsoing the Home Address to an on-looker when on a visited network - concerns from disclsoing that the MN (user) has roamed to a new network to a correspondent Following are the relevant IDs that describe the solutions. As a first step, we need a succint problem statement document. We will get to the solutions once the problem statement is defined. draft-qiu-mip6-hiding-movement-00.txt draft-zhao-mip6-rr-ext.01.txt draft-dupont-mip6-privacyext-00.html draft-koodli-mip6-location-privacy-solutions-00.txt In the interest of time, I am proposing that we use the existing problem statement document draft-koodli-mip6-location-privacy-00.txt. All input, especially text, is welcome to improve the draft. Comments? -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From whaddad at tcs.hut.fi Tue Jun 21 14:25:28 2005 From: whaddad at tcs.hut.fi (Wassim Haddad) Date: Tue Jun 21 14:25:34 2005 Subject: [Momipriv] Re: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement In-Reply-To: <057601c57681$bfbadb40$016115ac@dcml.docomolabsusa.com> References: <057601c57681$bfbadb40$016115ac@dcml.docomolabsusa.com> Message-ID: Hi James, On Tue, 21 Jun 2005, James Kempf wrote: > Is there a mailing list or proposed agenda? Or will the discussion be part > of mobopts? => The current mailing list is the "momipriv". > Also, I believe if I recall correctly that draft-haddad takes a more > comprehensive approach than draft-koodli to the problem. Is the BOF to be > restricted to "what are the problems in the current MIP6 protocol with > location privacy" or is it rather to be more comprehensive? If the latter, > there are some issues that I think are not in either draft that I would like > to see discussed. => OK. The BoF charter will be posted soon to the momipriv ML. Regards, Wassim H. > ----- Original Message ----- > From: "Wassim Haddad" > To: "COMBES Jean-Michel RD-MAPS-ISS" > Cc: "Gopal Dommety" ; ; > "Rajeev Koodli" ; ; > > Sent: Tuesday, June 21, 2005 7:32 AM > Subject: RE: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement > > > > Hi Jean-Michel, > > > > On Tue, 21 Jun 2005, COMBES Jean-Michel RD-MAPS-ISS wrote: > > > > > Hi Rajeev, > > > > > > I think you forgot these IDs: > > > draft-haddad-momipriv-problem-statement-01.txt > > > draft-haddad-momipriv-threat-model-00.txt > > > > > > which are, in my point of view, maybe what you are looking for :) > > > > > BTW, will there be a MomiPriv session (BOF/BarBOF/...) during the next > IETF meeting? > > > > => Yes there will be a BoF. > > > > > > Regards, > > > > Wassim H. > > > > _______________________________________________ > > Mobopts mailing list > > Mobopts@irtf.org > > https://www1.ietf.org/mailman/listinfo/mobopts > > > > > > From kempf at docomolabs-usa.com Tue Jun 21 15:27:43 2005 From: kempf at docomolabs-usa.com (James Kempf) Date: Tue Jun 21 15:26:47 2005 Subject: [Momipriv] Re: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement References: <056701c57681$05665b20$016115ac@dcml.docomolabsusa.com> <42B859B4.5080508@iprg.nokia.com> Message-ID: <063b01c5768e$eef51580$016115ac@dcml.docomolabsusa.com> I agree that the solutions for the restricted problem of MIP6 location privacy are very similar, so I think it should be simple enough to come up with a merger. But do we really need a BOF in order to do that? The MIP6 WG could simply modify its charter and put MIP6 location privacy on, then get a design team of a selected set of authors from the existing drafts to come up with a solution. So the question is, what is the purpose of the BOF? jak ----- Original Message ----- From: "Vijay Devarapalli" To: "James Kempf" Cc: "COMBES Jean-Michel RD-MAPS-ISS" ; "Rajeev Koodli" ; ; "Gopal Dommety" ; ; Sent: Tuesday, June 21, 2005 11:17 AM Subject: Re: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement > I think not. draft-koodli deals with only two problems that are > very specific to the MIPv6 protocol. hiding the CoA from the CN > and hiding the HoA from the visited network. for this we already > have solutions (4 solution drafts). the solution drafts are > surprisingly very similar. more than one draft talks about > generating a "privacy label" and using that instead of the home > address in the data packets. > > momipriv looks at lot more than that just these two problems > and I think merits a BoF and a separate mailing list for the > discussions. > > my 2 cents. > > Vijay > > James Kempf wrote: > > Right, I think we need to at least make sure that the problem statement > > drafts draft-haddad and draft-koodli are merged so that issues covered in > > both are included in the WG draft. > > > > jak > > > > ----- Original Message ----- > > From: "COMBES Jean-Michel RD-MAPS-ISS" > > To: "Rajeev Koodli" ; > > Cc: "Gopal Dommety" ; ; > > > > Sent: Tuesday, June 21, 2005 6:15 AM > > Subject: RE: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement > > > > > > Hi Rajeev, > > > > I think you forgot these IDs: > > draft-haddad-momipriv-problem-statement-01.txt > > draft-haddad-momipriv-threat-model-00.txt > > > > which are, in my point of view, maybe what you are looking for :) > > > > BTW, will there be a MomiPriv session (BOF/BarBOF/...) during the next IETF > > meeting? > > > > Regards. > > > > JMC. > > > > France Telecom - R&D Division - MAPS/NSS > > Jean-Michel COMBES, Internet/Intranet Security > > E-Mail: jeanmichel.combes@francetelecom.com > > Phone: +33 (0)1 45 29 45 94 > > Fax: +33 (0)1 45 29 65 19 > > Mobile: +33 (0)6 07 29 30 16 > > > > ________________________________ > > > > De : mobopts-bounces@irtf.org [mailto:mobopts-bounces@irtf.org] De la part > > de Rajeev Koodli > > Envoyi : mercredi 15 juin 2005 20:26 > > @ : mobopts@irtf.org > > Cc : Gopal Dommety; Basavaraj.Patil@nokia.com > > Objet : [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement > > > > > > > > Hello folks, > > > > we need to produce a problem statement > > document (for the MIP6 WG). Just to recap, the problems we > > are looking into are: > > > > - concerns from disclsoing the Home Address to an on-looker when on a > > visited network > > - concerns from disclsoing that the MN (user) has roamed to a new network > > to a correspondent > > > > Following are the relevant IDs that describe the solutions. > > As a first step, we need a succint problem statement document. > > We will get to the solutions once the problem statement is defined. > > > > draft-qiu-mip6-hiding-movement-00.txt > > draft-zhao-mip6-rr-ext.01.txt > > draft-dupont-mip6-privacyext-00.html > > draft-koodli-mip6-location-privacy-solutions-00.txt > > > > In the interest of time, I am proposing that we > > use the existing problem statement document > > draft-koodli-mip6-location-privacy-00.txt. > > All input, especially text, is welcome to improve > > the draft. > > > > Comments? > > > > -Rajeev > > > > > > > > > > > > > > _______________________________________________ > > Mobopts mailing list > > Mobopts@irtf.org > > https://www1.ietf.org/mailman/listinfo/mobopts > > > > > > > > _______________________________________________ > > Mobopts mailing list > > Mobopts@irtf.org > > https://www1.ietf.org/mailman/listinfo/mobopts > > > From vijayd at iprg.nokia.com Tue Jun 21 15:17:24 2005 From: vijayd at iprg.nokia.com (Vijay Devarapalli) Date: Tue Jun 21 15:40:46 2005 Subject: [Momipriv] Re: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement In-Reply-To: <056701c57681$05665b20$016115ac@dcml.docomolabsusa.com> References: <056701c57681$05665b20$016115ac@dcml.docomolabsusa.com> Message-ID: <42B859B4.5080508@iprg.nokia.com> I think not. draft-koodli deals with only two problems that are very specific to the MIPv6 protocol. hiding the CoA from the CN and hiding the HoA from the visited network. for this we already have solutions (4 solution drafts). the solution drafts are surprisingly very similar. more than one draft talks about generating a "privacy label" and using that instead of the home address in the data packets. momipriv looks at lot more than that just these two problems and I think merits a BoF and a separate mailing list for the discussions. my 2 cents. Vijay James Kempf wrote: > Right, I think we need to at least make sure that the problem statement > drafts draft-haddad and draft-koodli are merged so that issues covered in > both are included in the WG draft. > > jak > > ----- Original Message ----- > From: "COMBES Jean-Michel RD-MAPS-ISS" > To: "Rajeev Koodli" ; > Cc: "Gopal Dommety" ; ; > > Sent: Tuesday, June 21, 2005 6:15 AM > Subject: RE: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement > > > Hi Rajeev, > > I think you forgot these IDs: > draft-haddad-momipriv-problem-statement-01.txt > draft-haddad-momipriv-threat-model-00.txt > > which are, in my point of view, maybe what you are looking for :) > > BTW, will there be a MomiPriv session (BOF/BarBOF/...) during the next IETF > meeting? > > Regards. > > JMC. > > France Telecom - R&D Division - MAPS/NSS > Jean-Michel COMBES, Internet/Intranet Security > E-Mail: jeanmichel.combes@francetelecom.com > Phone: +33 (0)1 45 29 45 94 > Fax: +33 (0)1 45 29 65 19 > Mobile: +33 (0)6 07 29 30 16 > > ________________________________ > > De : mobopts-bounces@irtf.org [mailto:mobopts-bounces@irtf.org] De la part > de Rajeev Koodli > Envoyi : mercredi 15 juin 2005 20:26 > @ : mobopts@irtf.org > Cc : Gopal Dommety; Basavaraj.Patil@nokia.com > Objet : [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement > > > > Hello folks, > > we need to produce a problem statement > document (for the MIP6 WG). Just to recap, the problems we > are looking into are: > > - concerns from disclsoing the Home Address to an on-looker when on a > visited network > - concerns from disclsoing that the MN (user) has roamed to a new network > to a correspondent > > Following are the relevant IDs that describe the solutions. > As a first step, we need a succint problem statement document. > We will get to the solutions once the problem statement is defined. > > draft-qiu-mip6-hiding-movement-00.txt > draft-zhao-mip6-rr-ext.01.txt > draft-dupont-mip6-privacyext-00.html > draft-koodli-mip6-location-privacy-solutions-00.txt > > In the interest of time, I am proposing that we > use the existing problem statement document > draft-koodli-mip6-location-privacy-00.txt. > All input, especially text, is welcome to improve > the draft. > > Comments? > > -Rajeev > > > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts From vijayd at iprg.nokia.com Tue Jun 21 15:47:53 2005 From: vijayd at iprg.nokia.com (Vijay Devarapalli) Date: Tue Jun 21 15:48:27 2005 Subject: [Momipriv] Re: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement In-Reply-To: <063b01c5768e$eef51580$016115ac@dcml.docomolabsusa.com> References: <056701c57681$05665b20$016115ac@dcml.docomolabsusa.com> <42B859B4.5080508@iprg.nokia.com> <063b01c5768e$eef51580$016115ac@dcml.docomolabsusa.com> Message-ID: <42B860D9.90704@iprg.nokia.com> James Kempf wrote: > I agree that the solutions for the restricted problem of MIP6 location > privacy are very similar, so I think it should be simple enough to come up > with a merger. But do we really need a BOF in order to do that? The MIP6 WG > could simply modify its charter and put MIP6 location privacy on, then get a > design team of a selected set of authors from the existing drafts to come up > with a solution. I agree. or the work could be done in mobopts and standardized in the MIP6 WG. > > So the question is, what is the purpose of the BOF? the answer is in draft-haddad-momipriv-problem-statement-01.txt draft-haddad-momipriv-threat-model-00.txt which looks at lot more than just hiding the HoA and CoA. I think a BoF is needed to figure out what exactly the "privacy problem" is and what IETF can do to address this. Vijay > > jak > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: "James Kempf" > Cc: "COMBES Jean-Michel RD-MAPS-ISS" ; > "Rajeev Koodli" ; ; "Gopal Dommety" > ; ; > Sent: Tuesday, June 21, 2005 11:17 AM > Subject: Re: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement > > > >>I think not. draft-koodli deals with only two problems that are >>very specific to the MIPv6 protocol. hiding the CoA from the CN >>and hiding the HoA from the visited network. for this we already >>have solutions (4 solution drafts). the solution drafts are >>surprisingly very similar. more than one draft talks about >>generating a "privacy label" and using that instead of the home >>address in the data packets. >> >>momipriv looks at lot more than that just these two problems >>and I think merits a BoF and a separate mailing list for the >>discussions. >> >>my 2 cents. >> >>Vijay >> >>James Kempf wrote: >> >>>Right, I think we need to at least make sure that the problem statement >>>drafts draft-haddad and draft-koodli are merged so that issues covered > > in > >>>both are included in the WG draft. >>> >>> jak >>> >>>----- Original Message ----- >>>From: "COMBES Jean-Michel RD-MAPS-ISS" > > > >>>To: "Rajeev Koodli" ; >>>Cc: "Gopal Dommety" ; ; >>> >>>Sent: Tuesday, June 21, 2005 6:15 AM >>>Subject: RE: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem > > Statement > >>> >>>Hi Rajeev, >>> >>>I think you forgot these IDs: >>>draft-haddad-momipriv-problem-statement-01.txt >>>draft-haddad-momipriv-threat-model-00.txt >>> >>>which are, in my point of view, maybe what you are looking for :) >>> >>>BTW, will there be a MomiPriv session (BOF/BarBOF/...) during the next > > IETF > >>>meeting? >>> >>>Regards. >>> >>>JMC. >>> >>>France Telecom - R&D Division - MAPS/NSS >>>Jean-Michel COMBES, Internet/Intranet Security >>>E-Mail: jeanmichel.combes@francetelecom.com >>>Phone: +33 (0)1 45 29 45 94 >>>Fax: +33 (0)1 45 29 65 19 >>>Mobile: +33 (0)6 07 29 30 16 >>> >>>________________________________ >>> >>>De : mobopts-bounces@irtf.org [mailto:mobopts-bounces@irtf.org] De la > > part > >>>de Rajeev Koodli >>>Envoyi : mercredi 15 juin 2005 20:26 >>>@ : mobopts@irtf.org >>>Cc : Gopal Dommety; Basavaraj.Patil@nokia.com >>>Objet : [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement >>> >>> >>> >>>Hello folks, >>> >>>we need to produce a problem statement >>>document (for the MIP6 WG). Just to recap, the problems we >>>are looking into are: >>> >>>- concerns from disclsoing the Home Address to an on-looker when on a >>>visited network >>>- concerns from disclsoing that the MN (user) has roamed to a new > > network > >>> to a correspondent >>> >>>Following are the relevant IDs that describe the solutions. >>>As a first step, we need a succint problem statement document. >>>We will get to the solutions once the problem statement is defined. >>> >>>draft-qiu-mip6-hiding-movement-00.txt >>>draft-zhao-mip6-rr-ext.01.txt >>>draft-dupont-mip6-privacyext-00.html >>>draft-koodli-mip6-location-privacy-solutions-00.txt >>> >>>In the interest of time, I am proposing that we >>>use the existing problem statement document >>>draft-koodli-mip6-location-privacy-00.txt. >>>All input, especially text, is welcome to improve >>>the draft. >>> >>>Comments? >>> >>>-Rajeev >>> >>> >>> >>> >>> >>> >>>_______________________________________________ >>>Mobopts mailing list >>>Mobopts@irtf.org >>>https://www1.ietf.org/mailman/listinfo/mobopts >>> >>> >>> >>>_______________________________________________ >>>Mobopts mailing list >>>Mobopts@irtf.org >>>https://www1.ietf.org/mailman/listinfo/mobopts >> >> >> > > From pekka.nikander at nomadiclab.com Wed Jun 22 07:37:11 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Wed Jun 22 08:10:16 2005 Subject: [Momipriv] Privacy BoF Proposal Message-ID: All, Please find below our initial proposal for a privacy BoF in Paris. If you have time to review it and give comments, please do it within a next few days. I intend to submit it to the IESG early next week. --Pekka Anonymous Identifiers BOF (ALIEN) ================================= August, 2005 ------------ Name: Anonymous Identifiers (ALIEN) Area: Internet Conflicts: TBD Expected attendance: 100-200 Special requests: none Number of Slots: one Timeslot: 2 hours and 30 minutes Chairs: TBA AGENDA: ------ 5 min Agenda bashing Chairs 5 min Goal and purpose of the BOF Chairs 25 min Other presentations, to be confirmed TBD 10 min Lower layers problem statement TBA 10 min Lower layers threat model TBA 60 min Open Discussion All DESCRIPTION: ------------ Privacy is becoming a more pressing issue in the Internet architecture. There are several reasons to this, including new or proposed legistlation in various countries, the Internet becoming more ubiquitous and mobile, and changes in people's expectations. Furthermore, it must be understood that different people mean different things with network privacy, and that there are huge cultural differences with respect to privacy expectations between various countries. The purpose of this BOF is twofold: 1. To initiate serious long term discussion on privacy within the community. One possible outcome of this would be chartering of a privacy research group at the IRTF. 2. To initiate work on the more short term needs related to the IP layer, including problems related to IP-layer mobility and multi-homing solutions. It remains to be determined whether this work should happen within an existing working group, split among a number of existing working groups, or whether a new working group should be formed. 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. MAILING LIST: ------------- momipriv@lacnic.net To subscribe, visit http://lacnic.net/mailman/listinfo/momipriv BACKGROUND: ----------- While privacy is a multifaceted phenomenon with many different definitions of what it exactly means. Obviously, in this work the aim is to focus on privacy issues in Intenet protocols and architecture, including all protocols from sub-IP to application layers. A basic approach in addressing privacy in protocols is unlinkablity, denoting that an eavesdropper is unable to link together identifiers and other data with the aim of tracking the behaviour, location, and other sensitive information about a user. A more pressing need faces the IP and the layers below it. The IETF has developed and is still working on a various multi-homing and mobility solutions. These solutions aim to target various goals, including keeping ongoing sessions alive while switching between different IP addresses. Introducing an identifier that remains stable even though underlying IP addresses (i.e., locators) change is an important building block. However, the currently standardized and proposed mobility and multi-homing solutions allow eavesdroppers and correspondent nodes to easily identify, locate, and trace nodes in a mobile and multi-homed environment. Among these pieces of information, the IP and MAC addresses are the most valuable source since they can easily enable a malicious party to identify and locate its victim. Once the target is discovered, the eavesdropper can monitor the interaction aken by the entity using these locators / identifiers and use this information as input to other profiling tools in order to collect more information related to the victim's activities and locations in real time. Whenever these actions are possible, they constitue a serious violation of the target's privacy. As argued in input documents, addressing these privacy issues, separately on the IP and MAC layer is insufficient especially that it does not take the unlinkability aspect into account. Hence a solution, which addresses the anonymity and unlinkability at both layers and takes into consideration the synchronisation problem between them is needed. In addition to low layers identifiers, the transport and application layers can also provide information, which can be used for identifying and tracking purposes, especially when combined with data gathered on lower layers. Based on that, addressing anonymity and unlinkability issues at all layers is required also for the long term goals. The ALIEN BoF aims to discuss a recommendation for the IESG and the IAB to charter related work at the IETF and the IRTF. Drafts: draft-haddad-momipriv-problem-statement-01.txt draft-haddad-momipriv-threat-model-00.txt From rajeev at iprg.nokia.com Tue Jun 21 19:32:16 2005 From: rajeev at iprg.nokia.com (Rajeev Koodli) Date: Wed Jun 22 08:32:32 2005 Subject: [Momipriv] Re: [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement In-Reply-To: References: Message-ID: <42B89570.8060803@iprg.nokia.com> Hi JMC, COMBES Jean-Michel RD-MAPS-ISS wrote: >Hi Rajeev, > >I think you forgot these IDs: >draft-haddad-momipriv-problem-statement-01.txt >draft-haddad-momipriv-threat-model-00.txt > > > Actually, I didn't forget them. >which are, in my point of view, maybe what you are looking for :) > > > Let me clarify. The problem scope of what was discussed at the last IETF MIP6 WG is narrow enough that solutions already exist. The momipriv IDs deserve broader attention and I believe a BOF could be a good direction. To re-iterate the problems (listed in my original e-mail), we are addressing the location privacy problems arising from disclosing a) HoA to an on-looker from a visited network, and b) disclosing CoA to an unacquainted CN. We need to produce a problem statement document outlining this for the MIP6 WG by IETF63 (as per the discussion at IETF62). The ML is open for discussing broader set of topics around privacy as well. And, I am sure the momipriv BOF will cover interesting issues. Hope this helps.. Regards, -Rajeev >BTW, will there be a MomiPriv session (BOF/BarBOF/...) during the next IETF meeting? > >Regards. > >JMC. > >France Telecom - R&D Division - MAPS/NSS >Jean-Michel COMBES, Internet/Intranet Security >E-Mail: jeanmichel.combes@francetelecom.com >Phone: +33 (0)1 45 29 45 94 >Fax: +33 (0)1 45 29 65 19 >Mobile: +33 (0)6 07 29 30 16 > >________________________________ > > De : mobopts-bounces@irtf.org [mailto:mobopts-bounces@irtf.org] De la part de Rajeev Koodli > Envoyi : mercredi 15 juin 2005 20:26 > @ : mobopts@irtf.org > Cc : Gopal Dommety; Basavaraj.Patil@nokia.com > Objet : [Mobopts] RESEND: MIPv6 and Location Privacy: Problem Statement > > > > Hello folks, > > we need to produce a problem statement > document (for the MIP6 WG). Just to recap, the problems we > are looking into are: > > - concerns from disclsoing the Home Address to an on-looker when on a visited network > - concerns from disclsoing that the MN (user) has roamed to a new network > to a correspondent > > Following are the relevant IDs that describe the solutions. > As a first step, we need a succint problem statement document. > We will get to the solutions once the problem statement is defined. > > draft-qiu-mip6-hiding-movement-00.txt > draft-zhao-mip6-rr-ext.01.txt > draft-dupont-mip6-privacyext-00.html > draft-koodli-mip6-location-privacy-solutions-00.txt > > In the interest of time, I am proposing that we > use the existing problem statement document > draft-koodli-mip6-location-privacy-00.txt. > All input, especially text, is welcome to improve > the draft. > > Comments? > > -Rajeev > > > > > > > From kempf at docomolabs-usa.com Wed Jun 22 14:30:08 2005 From: kempf at docomolabs-usa.com (James Kempf) Date: Wed Jun 22 14:29:12 2005 Subject: [Momipriv] Re: Privacy BoF Proposal References: Message-ID: <012701c57750$0e7eb0c0$016115ac@dcml.docomolabsusa.com> Hi Pekka, The agenda looks a little thin at the moment. The description is fine, but one thing I think the BOF needs to discuss is privacy as an architectural issue rather than a strictly protocol design issue. That is, I think that each individual protocol needs to approach privacy in a way that is appropriate for the design of that protocol, but that there are likely to be some architectural guidelines that would be useful for all protocols and one could, for example, put together a document that would describe those guidelines ("Architectural Guidelines for Privacy in Internet Protocol Design" or something like that). One area that I think might be somewhat questionable is including sub-IP layer protocols that are not IETF designed (PPP for example or MPLS would be OK to cover, since they are IETF designed). We could come up with some requirements from the IP standpoint about privacy that could then be propagated to the various standardization bodies that control these protocols, but anything in the design space here would probably be better done in the appropriate standardization body. jak ----- Original Message ----- From: "Pekka Nikander" To: Cc: "James Kempf" ; ; ; "Wassim Haddad ((QA/EMC))" ; "Rajeev Koodli" ; "IAB" Sent: Wednesday, June 22, 2005 3:37 AM Subject: Privacy BoF Proposal > All, > > Please find below our initial proposal for a privacy BoF in Paris. > If you have time to review it and give comments, please do it within > a next few days. I intend to submit it to the IESG early next week. > > --Pekka > > Anonymous Identifiers BOF (ALIEN) > ================================= > > August, 2005 > ------------ > > Name: Anonymous Identifiers (ALIEN) > Area: Internet > Conflicts: TBD > Expected attendance: 100-200 > Special requests: none > Number of Slots: one > Timeslot: 2 hours and 30 minutes > > Chairs: TBA > > AGENDA: > ------ > 5 min Agenda bashing Chairs > 5 min Goal and purpose of the BOF Chairs > 25 min Other presentations, to be confirmed TBD > 10 min Lower layers problem statement TBA > 10 min Lower layers threat model TBA > 60 min Open Discussion All > > DESCRIPTION: > ------------ > Privacy is becoming a more pressing issue in the Internet architecture. > There are several reasons to this, including new or proposed > legistlation > in various countries, the Internet becoming more ubiquitous and mobile, > and changes in people's expectations. Furthermore, it must be > understood > that different people mean different things with network privacy, and > that > there are huge cultural differences with respect to privacy expectations > between various countries. > > The purpose of this BOF is twofold: > > 1. To initiate serious long term discussion on privacy within the > community. One possible outcome of this would be chartering > of a privacy research group at the IRTF. > > 2. To initiate work on the more short term needs related to the IP > layer, including problems related to IP-layer mobility and > multi-homing solutions. It remains to be determined whether this > work should happen within an existing working group, split among > a number of existing working groups, or whether a new working > group should be formed. > > 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. > > MAILING LIST: > ------------- > momipriv@lacnic.net > > To subscribe, visit http://lacnic.net/mailman/listinfo/momipriv > > BACKGROUND: > ----------- > > While privacy is a multifaceted phenomenon with many different > definitions > of what it exactly means. Obviously, in this work the aim is to focus > on > privacy issues in Intenet protocols and architecture, including all > protocols from sub-IP to application layers. A basic approach in > addressing privacy in protocols is unlinkablity, denoting that an > eavesdropper is unable to link together identifiers and other data with > the aim of tracking the behaviour, location, and other sensitive > information about a user. > > A more pressing need faces the IP and the layers below it. The IETF has > developed and is still working on a various multi-homing and mobility > solutions. These solutions aim to target various goals, including > keeping ongoing sessions alive while switching between different IP > addresses. Introducing an identifier that remains stable even though > underlying IP addresses (i.e., locators) change is an important building > block. However, the currently standardized and proposed mobility and > multi-homing solutions allow eavesdroppers and correspondent nodes to > easily identify, locate, and trace nodes in a mobile and multi-homed > environment. > > Among these pieces of information, the IP and MAC addresses are the most > valuable source since they can easily enable a malicious party to > identify > and locate its victim. Once the target is discovered, the eavesdropper > can monitor the interaction aken by the entity using these locators / > identifiers and use this information as input to other profiling tools > in order to collect more information related to the victim's activities > and locations in real time. Whenever these actions are possible, they > constitue a serious violation of the target's privacy. > > As argued in input documents, addressing these privacy issues, > separately > on the IP and MAC layer is insufficient especially that it does not take > the unlinkability aspect into account. Hence a solution, which addresses > the anonymity and unlinkability at both layers and takes into > consideration > the synchronisation problem between them is needed. > > In addition to low layers identifiers, the transport and application > layers > can also provide information, which can be used for identifying and > tracking > purposes, especially when combined with data gathered on lower layers. > Based > on that, addressing anonymity and unlinkability issues at all layers is > required also for the long term goals. > > The ALIEN BoF aims to discuss a recommendation for the IESG and the IAB > to > charter related work at the IETF and the IRTF. > > Drafts: > > draft-haddad-momipriv-problem-statement-01.txt > draft-haddad-momipriv-threat-model-00.txt > From rajeev at iprg.nokia.com Wed Jun 22 14:34:02 2005 From: rajeev at iprg.nokia.com (Rajeev Koodli) Date: Wed Jun 22 14:34:28 2005 Subject: [Momipriv] Re: [Mobopts] Privacy BoF Proposal In-Reply-To: References: Message-ID: <42B9A10A.1020407@iprg.nokia.com> Hi Pekka, thanks for bringing this up. I have few comments in-line. Pekka Nikander wrote: > > The purpose of this BOF is twofold: > > 1. To initiate serious long term discussion on privacy within the > community. One possible outcome of this would be chartering > of a privacy research group at the IRTF. > This would be worthwhile (necessary?), especially given the breadth of topics you are hoping to address. It is not clear to me if you need a BOF to start an IRTF RG however :-) > 2. To initiate work on the more short term needs related to the IP > layer, including problems related to IP-layer mobility and > multi-homing solutions. It remains to be determined whether this > work should happen within an existing working group, split among > a number of existing working groups, or whether a new working > group should be formed. > FYI: MobOpts is already looking into Location Privacy due to IP Mobility. More on this below.. > 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 solutions available. 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. Regards, -Rajeev > MAILING LIST: > ------------- > momipriv@lacnic.net > > To subscribe, visit http://lacnic.net/mailman/listinfo/momipriv > > BACKGROUND: > ----------- > > While privacy is a multifaceted phenomenon with many different > definitions > of what it exactly means. Obviously, in this work the aim is to focus on > privacy issues in Intenet protocols and architecture, including all > protocols from sub-IP to application layers. A basic approach in > addressing privacy in protocols is unlinkablity, denoting that an > eavesdropper is unable to link together identifiers and other data with > the aim of tracking the behaviour, location, and other sensitive > information about a user. > > A more pressing need faces the IP and the layers below it. The IETF has > developed and is still working on a various multi-homing and mobility > solutions. These solutions aim to target various goals, including > keeping ongoing sessions alive while switching between different IP > addresses. Introducing an identifier that remains stable even though > underlying IP addresses (i.e., locators) change is an important building > block. However, the currently standardized and proposed mobility and > multi-homing solutions allow eavesdroppers and correspondent nodes to > easily identify, locate, and trace nodes in a mobile and multi-homed > environment. > > Among these pieces of information, the IP and MAC addresses are the most > valuable source since they can easily enable a malicious party to > identify > and locate its victim. Once the target is discovered, the eavesdropper > can monitor the interaction aken by the entity using these locators / > identifiers and use this information as input to other profiling tools > in order to collect more information related to the victim's activities > and locations in real time. Whenever these actions are possible, they > constitue a serious violation of the target's privacy. > > As argued in input documents, addressing these privacy issues, separately > on the IP and MAC layer is insufficient especially that it does not take > the unlinkability aspect into account. Hence a solution, which addresses > the anonymity and unlinkability at both layers and takes into > consideration > the synchronisation problem between them is needed. > > In addition to low layers identifiers, the transport and application > layers > can also provide information, which can be used for identifying and > tracking > purposes, especially when combined with data gathered on lower layers. > Based > on that, addressing anonymity and unlinkability issues at all layers is > required also for the long term goals. > > The ALIEN BoF aims to discuss a recommendation for the IESG and the > IAB to > charter related work at the IETF and the IRTF. > > Drafts: > > draft-haddad-momipriv-problem-statement-01.txt > draft-haddad-momipriv-threat-model-00.txt > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts From kempf at docomolabs-usa.com Wed Jun 22 14:44:01 2005 From: kempf at docomolabs-usa.com (James Kempf) Date: Wed Jun 22 14:43:00 2005 Subject: [Momipriv] Re: [Mobopts] Privacy BoF Proposal References: <42B9A10A.1020407@iprg.nokia.com> Message-ID: <014201c57751$febfdbd0$016115ac@dcml.docomolabsusa.com> Rajeev, > 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. Actually, I think one can make an even further narrowing of scope, and that is location privacy applied specifically to the Mobile IPv6 protocol. As I believe you have pointed out, there are already several similar solutions for this, and so it is probably better to pursue these in Mobopts and MIP6. This gets back to the point I was trying to make about privacy as an architectural v.s. a protocol design issue. > And, MobOpts RG has been looking into that, and there are already solutions > available. 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. > I think location privacy as an architectural issue should be included, but I think that any protocol solutions should be excluded. For example, there may be location privacy issues with HIP or Mobike, or even with SIP, that would need to be addressed in the respective working groups. As far as I know, they aren't, and some architectural work might help these WGs to turn some focussed attention on their particular protocols. jak From rajeev at iprg.nokia.com Wed Jun 22 15:14:33 2005 From: rajeev at iprg.nokia.com (Rajeev Koodli) Date: Wed Jun 22 15:14:57 2005 Subject: [Momipriv] Re: [Mobopts] Privacy BoF Proposal In-Reply-To: <014201c57751$febfdbd0$016115ac@dcml.docomolabsusa.com> References: <42B9A10A.1020407@iprg.nokia.com> <014201c57751$febfdbd0$016115ac@dcml.docomolabsusa.com> Message-ID: <42B9AA89.1020205@iprg.nokia.com> Hi Jim, James Kempf wrote: >I think location privacy as an architectural issue should be included, but I >think that any protocol solutions should be excluded. For example, there may >be location privacy issues with HIP or Mobike, or even with SIP, that would >need to be addressed in the respective working groups. As far as I know, >they aren't, and some architectural work might help these WGs to turn some >focussed attention on their particular protocols. > > > 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. -Rajeev ps: BTW, if anyone is interested in the extended version of our paper on Location Privacy with IP Mobility for Securecomm 2005, let me know. > jak > > > > From rajeev at iprg.nokia.com Wed Jun 22 15:48:49 2005 From: rajeev at iprg.nokia.com (Rajeev Koodli) Date: Wed Jun 22 15:49:13 2005 Subject: [Momipriv] Re: [Mobopts] Privacy BoF Proposal In-Reply-To: References: Message-ID: <42B9B291.2070609@iprg.nokia.com> 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 Greg Daley wrote: >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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lacnic.net/pipermail/momipriv/attachments/20050622/afb42077/attachment-0001.htm From whaddad at tcs.hut.fi Wed Jun 22 16:09:41 2005 From: whaddad at tcs.hut.fi (Wassim Haddad) Date: Wed Jun 22 16:09:47 2005 Subject: [Momipriv] Re: [Mobopts] Privacy BoF Proposal In-Reply-To: <42B9B291.2070609@iprg.nokia.com> References: <42B9B291.2070609@iprg.nokia.com> Message-ID: On Wed, 22 Jun 2005, Rajeev Koodli wrote: > 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. => 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. > Greg Daley wrote: > > >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 > > > > > > > From Greg.Daley at eng.monash.edu.au Wed Jun 22 15:21:42 2005 From: Greg.Daley at eng.monash.edu.au (Greg Daley) Date: Wed Jun 22 16:42:49 2005 Subject: [Momipriv] Re: [Mobopts] Privacy BoF Proposal Message-ID: Hi Rajeev, ----- Original Message ----- From: Rajeev Koodli [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 From Greg.Daley at eng.monash.edu.au Wed Jun 22 15:13:54 2005 From: Greg.Daley at eng.monash.edu.au (Greg Daley) Date: Wed Jun 22 16:53:42 2005 Subject: [Momipriv] Re: [Mobopts] Privacy BoF Proposal Message-ID: 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 From rajeev at iprg.nokia.com Wed Jun 22 19:37:27 2005 From: rajeev at iprg.nokia.com (Rajeev Koodli) Date: Wed Jun 22 19:38:00 2005 Subject: [Momipriv] Re: [Mobopts] Privacy BoF Proposal In-Reply-To: References: <42B9B291.2070609@iprg.nokia.com> Message-ID: <42B9E827.5030009@iprg.nokia.com> Wassim, Wassim Haddad 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? Thanks, -Rajeev >Regards, > >Wassim H. > > > > >>Greg Daley wrote: >> >> >> >>>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 >>> >>> >>> >>> >>> From Greg.Daley at eng.monash.edu.au Wed Jun 22 23:04:35 2005 From: Greg.Daley at eng.monash.edu.au (Greg Daley) Date: Wed Jun 22 23:05:54 2005 Subject: [Momipriv] Re: [Mobopts] Privacy BoF Proposal Message-ID: Hi Rajeev, ----- Original Message ----- From: Rajeev Koodli Date: Thursday, June 23, 2005 8:37 am Subject: Re: [Momipriv] Re: [Mobopts] Privacy BoF Proposal > > Wassim, > > > Wassim Haddad 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? One example where a MAC address can divulge identity/location mapping is where someone is able to monitor a set of access networks, and see which MAC addresses are used for which locators. If the same MAC address is used across a set of networks, and the location and identity are matched on any single link, this means the mapping can be correlated in the future and past. So the MAC address doesn't need to be known initially, if the snooper can connect gathered MAC/locator movement information to an identity. Indeed, even if the actual (upper-layer) identity is not divulged, the MAC address can provide a unique mapping for the set of packet transmissions across the access networks. In order to be safe from this monitoring, no MAC address should be used on a link corresponding to two different locators (i.e. the MAC doesn't outlive a CoA). Greg From clint.chaplin at gmail.com Wed Jun 22 15:58:26 2005 From: clint.chaplin at gmail.com (Clint Chaplin) Date: Thu Jun 23 05:00:57 2005 Subject: [Momipriv] Re: [Mobopts] Privacy BoF Proposal In-Reply-To: References: Message-ID: Excuse my ignorance, but is this an IRTF or an IETF group proposal? On 6/22/05, Pekka Nikander wrote: > All, > > Please find below our initial proposal for a privacy BoF in Paris. > If you have time to review it and give comments, please do it within > a next few days. I intend to submit it to the IESG early next week. > > --Pekka > > Anonymous Identifiers BOF (ALIEN) > ================================= > > August, 2005 > ------------ > > Name: Anonymous Identifiers (ALIEN) > Area: Internet > Conflicts: TBD > Expected attendance: 100-200 > Special requests: none > Number of Slots: one > Timeslot: 2 hours and 30 minutes > > Chairs: TBA > > AGENDA: > ------ > 5 min Agenda bashing Chairs > 5 min Goal and purpose of the BOF Chairs > 25 min Other presentations, to be confirmed TBD > 10 min Lower layers problem statement TBA > 10 min Lower layers threat model TBA > 60 min Open Discussion All > > DESCRIPTION: > ------------ > Privacy is becoming a more pressing issue in the Internet architecture. > There are several reasons to this, including new or proposed > legistlation > in various countries, the Internet becoming more ubiquitous and mobile, > and changes in people's expectations. Furthermore, it must be > understood > that different people mean different things with network privacy, and > that > there are huge cultural differences with respect to privacy expectations > between various countries. > > The purpose of this BOF is twofold: > > 1. To initiate serious long term discussion on privacy within the > community. One possible outcome of this would be chartering > of a privacy research group at the IRTF. > > 2. To initiate work on the more short term needs related to the IP > layer, including problems related to IP-layer mobility and > multi-homing solutions. It remains to be determined whether this > work should happen within an existing working group, split among > a number of existing working groups, or whether a new working > group should be formed. > > 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. > > MAILING LIST: > ------------- > momipriv@lacnic.net > > To subscribe, visit http://lacnic.net/mailman/listinfo/momipriv > > BACKGROUND: > ----------- > > While privacy is a multifaceted phenomenon with many different > definitions > of what it exactly means. Obviously, in this work the aim is to focus > on > privacy issues in Intenet protocols and architecture, including all > protocols from sub-IP to application layers. A basic approach in > addressing privacy in protocols is unlinkablity, denoting that an > eavesdropper is unable to link together identifiers and other data with > the aim of tracking the behaviour, location, and other sensitive > information about a user. > > A more pressing need faces the IP and the layers below it. The IETF has > developed and is still working on a various multi-homing and mobility > solutions. These solutions aim to target various goals, including > keeping ongoing sessions alive while switching between different IP > addresses. Introducing an identifier that remains stable even though > underlying IP addresses (i.e., locators) change is an important building > block. However, the currently standardized and proposed mobility and > multi-homing solutions allow eavesdroppers and correspondent nodes to > easily identify, locate, and trace nodes in a mobile and multi-homed > environment. > > Among these pieces of information, the IP and MAC addresses are the most > valuable source since they can easily enable a malicious party to > identify > and locate its victim. Once the target is discovered, the eavesdropper > can monitor the interaction aken by the entity using these locators / > identifiers and use this information as input to other profiling tools > in order to collect more information related to the victim's activities > and locations in real time. Whenever these actions are possible, they > constitue a serious violation of the target's privacy. > > As argued in input documents, addressing these privacy issues, > separately > on the IP and MAC layer is insufficient especially that it does not take > the unlinkability aspect into account. Hence a solution, which addresses > the anonymity and unlinkability at both layers and takes into > consideration > the synchronisation problem between them is needed. > > In addition to low layers identifiers, the transport and application > layers > can also provide information, which can be used for identifying and > tracking > purposes, especially when combined with data gathered on lower layers. > Based > on that, addressing anonymity and unlinkability issues at all layers is > required also for the long term goals. > > The ALIEN BoF aims to discuss a recommendation for the IESG and the IAB > to > charter related work at the IETF and the IRTF. > > Drafts: > > draft-haddad-momipriv-problem-statement-01.txt > draft-haddad-momipriv-threat-model-00.txt > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager From whaddad at tcs.hut.fi Thu Jun 23 12:32:42 2005 From: whaddad at tcs.hut.fi (Wassim Haddad) Date: Thu Jun 23 12:32:50 2005 Subject: [Momipriv] Re: [Mobopts] Privacy BoF Proposal In-Reply-To: <42B9E827.5030009@iprg.nokia.com> References: <42B9B291.2070609@iprg.nokia.com> <42B9E827.5030009@iprg.nokia.com> Message-ID: 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-anonymity-00.txt Regards, Wassim H. > >>Greg Daley wrote: > >> > >> > >> > >>>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 > >>> > >>> > >>> > >>> > >>> > > > From kempf at docomolabs-usa.com Thu Jun 23 12:57:21 2005 From: kempf at docomolabs-usa.com (James Kempf) Date: Thu Jun 23 12:56:25 2005 Subject: [Momipriv] Re: [Mobopts] Privacy BoF Proposal References: <42B9B291.2070609@iprg.nokia.com> <42B9E827.5030009@iprg.nokia.com> Message-ID: <02f401c5780c$42a04eb0$016115ac@dcml.docomolabsusa.com> 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" To: "Rajeev Koodli" Cc: "Greg Daley" ; ; "IAB" ; "James Kempf" ; ; "Basavaraj Patil" 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-anonymity-00.txt > > > Regards, > > Wassim H. > > > > > >>Greg Daley wrote: > > >> > > >> > > >> > > >>>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 > > >>> > > >>> > > >>> > > >>> > > >>> > > > > > > > From rajeev at iprg.nokia.com Thu Jun 23 15:18:10 2005 From: rajeev at iprg.nokia.com (Rajeev Koodli) Date: Thu Jun 23 15:18:45 2005 Subject: [Momipriv] Re: [Mobopts] Privacy BoF Proposal In-Reply-To: References: Message-ID: <42BAFCE2.5030002@iprg.nokia.com> Hi Greg, I see two different problems. Changing multiple identifiers is more do with profiling than to do with location privacy. More below.. Greg Daley wrote: >One example where a MAC address can divulge identity/location >mapping is where someone is able to monitor a set of access networks, >and see which MAC addresses are used for which locators. > > > This is doable, but needs to be lot more co-ordinated than what one could do with a globally visible (and sometimes accessible from namespace) identifier such as an IP address. Someone following a set of links "stalking" for a particular MAC address raises the bar. >If the same MAC address is used across a set of networks, and the >location and identity are matched on any single link, this means the >mapping can be correlated in the future and past. > > > In order to do so on the Internet, you would first need to build a database of MAC addresses and IP and ULP identifiers. Anyway, what can the IETF community do about L2 identifiers? There are a lot of them, and they are constructed according to the particular L2 technology constraints. Onc _could_ issue an informational if the problem is seen as something that IETF should be concerned with. >So the MAC address doesn't need to be known initially, if the snooper >can connect gathered MAC/locator movement information to an identity. > > > If the MAC address is not known, but the IP identifier is known and remains fixed, you have location privacy problem because of IP identifier disclosure. >Indeed, even if the actual (upper-layer) identity is not divulged, the >MAC address can provide a unique mapping for the set of packet >transmissions across the access networks. > > > This is the profiling problem. Not the location privacy problem. >In order to be safe from this monitoring, no MAC address should be used >on >a link corresponding to two different locators (i.e. the MAC doesn't >outlive a CoA). > > > If you change the CoA while on the same link, yes you may want to consider changing other identifiers to thwart profiling. I don't see a location privacy problem. Perhaps I am missing something. -Rajeev >Greg > > From greg.daley at eng.monash.edu.au Thu Jun 23 21:12:58 2005 From: greg.daley at eng.monash.edu.au (Greg Daley) Date: Fri, 24 Jun 2005 10:12:58 +1000 Subject: [Momipriv] [Mobopts] Privacy BoF Proposal In-Reply-To: <42BAFCE2.5030002@iprg.nokia.com> References: <42BAFCE2.5030002@iprg.nokia.com> Message-ID: <42BB500A.4070502@eng.monash.edu.au> Hi Rajeev, Rajeev Koodli wrote: > > Hi Greg, > > I see two different problems. Changing multiple identifiers is more do with > profiling than to do with location privacy. More below.. I agree that they may be two different problems, or aspects of the same, larger problem. > Greg Daley wrote: [cut] > This is doable, but needs to be lot more co-ordinated than what one > could do > with a globally visible (and sometimes accessible from namespace) > identifier > such as an IP address. Someone following a set of links "stalking" for a > particular MAC > address raises the bar. I guess that I mean it raises the bar to an appropriate level... ;) Plenty of people whom one would like to be private from have deep pockets (I prefer such tracing to require a warrant, and the ISP's complicity). There are other identifiers which need to be managed as well, but the MAC address is one which it's worth mentioning at least informationally. >> If the same MAC address is used across a set of networks, and the >> location and identity are matched on any single link, this means the >> mapping can be correlated in the future and past. >> >> >> > In order to do so on the Internet, you would first need to build a > database of > MAC addresses and IP and ULP identifiers. > > Anyway, what can the IETF community do about L2 identifiers? There are a > lot > of them, and they are constructed according to the particular L2 technology > constraints. Onc _could_ issue an informational if the problem is seen as > something that IETF should be concerned with. Yes. You're right. Database construction is not necessarily difficult though, if there are nearby compromised hosts, for example. It's not something which is solely an IETF issue, but IETF protocols will rely upon untraceability as well as instantaneous location privacy, and the MAC address becomes the achilles heel of existing proposals. Some information needs to be passed to implementers to indicate residual problems which exist even after L3 (mobility?) is fixed. >> So the MAC address doesn't need to be known initially, if the snooper >> can connect gathered MAC/locator movement information to an identity. >> >> >> > If the MAC address is not known, but the IP identifier is known and > remains fixed, > you have location privacy problem because of IP identifier disclosure. Yes, you're correct. This is what 3041 addresses are for :) >> Indeed, even if the actual (upper-layer) identity is not divulged, the >> MAC address can provide a unique mapping for the set of packet >> transmissions across the access networks. >> >> >> > This is the profiling problem. Not the location privacy problem. It's movement privacy, if you like. A location privacy which doesn't also try to thwart ongoing movement tracing attempts, will increase the risk of compromise of the id/locator binding. >> In order to be safe from this monitoring, no MAC address should be >> used on a link corresponding to two different locators (i.e. the MAC >> doesn't >> outlive a CoA). >> >> > If you change the CoA while on the same link, yes you may want to > consider changing > other identifiers to thwart profiling. I don't see a location privacy > problem. Perhaps I am > missing something. When you're performing DNA, and are not sure that you've changed links, any divulgence of the MAC address used on the previous link can be used to tie a new MAC address to the old MAC address, leading to the same profiling mechanism you mentioned before. Perhaps it's not location privacy. It's the case when there is any pseudo-identifier (not just MAC) which can be traced across links, with possible eventual compromise of location privacy. I still think it's in scope for discussion and documentation. Greg From jeanmichel.combes at francetelecom.com Fri Jun 24 15:25:39 2005 From: jeanmichel.combes at francetelecom.com (COMBES Jean-Michel RD-MAPS-ISS) Date: Fri, 24 Jun 2005 20:25:39 +0200 Subject: [Momipriv] [Mobopts] Privacy BoF Proposal Message-ID: 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: jeanmichel.combes at francetelecom.com 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 : momipriv-bounces at lacnic.net > [mailto:momipriv-bounces at lacnic.net] De la part de James Kempf > Envoy? : jeudi 23 juin 2005 17:57 > ? : Wassim Haddad; Rajeev Koodli > Cc : Basavaraj Patil; IAB; momipriv at lacnic.net; Greg Daley; > mobopts at irtf.org > 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 > > ----- Original Message ----- > From: "Wassim Haddad" > To: "Rajeev Koodli" > Cc: "Greg Daley" ; > ; "IAB" > ; "James Kempf" ; > ; "Basavaraj Patil" > 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, > > > >>> > > > >>>----- 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 > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > > > > > > > > > > > > _______________________________________________ > Momipriv mailing list > Momipriv at lacnic.net > http://lacnic.net/mailman/listinfo/momipriv > From whaddad at tcs.hut.fi Fri Jun 24 20:57:14 2005 From: whaddad at tcs.hut.fi (Wassim Haddad) Date: Sat, 25 Jun 2005 02:57:14 +0300 (EEST) Subject: [Momipriv] [Mobopts] Privacy BoF Proposal In-Reply-To: <42BC69C7.7050207@zurich.ibm.com> References: <42BC69C7.7050207@zurich.ibm.com> Message-ID: On Fri, 24 Jun 2005, Brian E Carpenter wrote: > Greg Daley wrote: > ... > > 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. > > 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. => Privacy threats related to static multi-homed nodes are described in draft-haddad-momipriv-threat-model-00. Regards, Wassim H. From brc at zurich.ibm.com Fri Jun 24 17:15:03 2005 From: brc at zurich.ibm.com (Brian E Carpenter) Date: Fri, 24 Jun 2005 22:15:03 +0200 Subject: [Momipriv] [Mobopts] Privacy BoF Proposal In-Reply-To: References: Message-ID: <42BC69C7.7050207@zurich.ibm.com> Greg Daley wrote: ... > 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. 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