Subject: [Mip6] comment on mip6-bootstrap for the integrated scenario

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 1 Mar 2006 10:54:32 -0500

Hello all,

Are there any comments on the integrated scenario bootstrap solution? If
you have not reviewed the I-D, here is the link:

http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integr
ated-dhc-00.txt

-Kuntal (Editor)

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

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 2 Mar 2006 11:26:23 +0100

Hi Kuntal,

according to the security considerations section of draft-ietf-mip6-bootstrapping-split-01.txt, the integrated scenario draft should have some analysis on location privacy properties ("Please see other drafts that contain detailed mechanisms for localized home agent assignment, such as [15], for information on the location privacy properties of particular home agent assignment mechanisms. "). I think this analysis is still missing in the current version of the draft. 

Note that we discussed this issue for the split scenario draft in October last year on the mailing list. We came up with a text, but it was not included in the split scenario draft, because the draft does not specify a particular home agent assignment mechanisms. Maybe we can re-use the text for the integrated scenario draft.

Regards,

Kilian

> -----Original Message-----
> From: Chowdhury, Kuntal [mailto:[email-masked]] 
> Sent: Mittwoch, 1. März 2006 16:55
> To: [email-masked]
> Subject: [Mip6] comment on mip6-bootstrap for the integrated scenario
> 
> Hello all,
>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 2 Mar 2006 11:51:31 -0500

Hello Kilian,

Thanks for pointing out the missing security consideration for location privacy concern that you brought up. I searched the old discussion threads, but could not dig out the relevant text that we could re-use.

Could you kindly post the text that you would like to see added?

-Kuntal

> From: Kilian Weniger [mailto:[email-masked]]
> Sent: Thursday, March 02, 2006 4:26 AM
> To: Chowdhury, Kuntal
> Cc: [email-masked]
> Subject: RE: [Mip6] comment on mip6-bootstrap for the integrated scenario
> 
> Hi Kuntal,
> 
> according to the security considerations section of draft-ietf-mip6-
> bootstrapping-split-01.txt, the integrated scenario draft should have some
> analysis on location privacy properties ("Please see other drafts that
> contain detailed mechanisms for localized home agent assignment, such as
> [15], for information on the location privacy properties of particular
> home agent assignment mechanisms. "). I think this analysis is still
> missing in the current version of the draft.
> 
> Note that we discussed this issue for the split scenario draft in October
> last year on the mailing list. We came up with a text, but it was not
> included in the split scenario draft, because the draft does not specify a
> particular home agent assignment mechanisms. Maybe we can re-use the text
> for the integrated scenario draft.
> 
> Regards,
> 
> Kilian
>

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 3 Mar 2006 16:06:29 +0100

Hi Kuntal,

how about the following text:

   If the home agent selected by the mobile node is local or nearby, 
   i.e., if it is in or close to the serving network access povider's 
   network (as in section 3.2.2), disclosing the mobile node's home 
   address (e.g., by updating the mobile node's FQDN in the DNS) has 
   the potential to expose some information about the mobile node's     
   location. 

   Just by knowing the mobile node's home address, an attacker cannot 
   determine whether the mobile node's home address belongs to a home 
   agent that is local, nearby or remote for the mobile node and, 
   hence, cannot determine where the mobile node is actually located. 
   However, if additional information such as the mobile node's home 
   agent selection policy and the home agent allocation policy of 
   ASPs is known by an attacker, this may be different. For instance, 
   if an attacker knows that the mobile node's home agent selection 
   policy is to bootstrap with a new local home agent whenever 
   entering a new network (e.g., because the mobile node wants to 
   improve routing efficiency in Bi-directional Tunneling mode), the 
   attacker can track the mobile node's movement if it is aware of 
   the mobile node's current home addresses.

   However, the accuracy of the revealed location information is 
   usually lower than in Route Optimization mode [draft-koodli-mip6
   location-privacy-00.txt]. First, depending on the deployment 
   scenario, the geographical area covered by a local home agent may 
   be much larger than the area covered by an access router. Second, 
   the mobile node, if using reverse tunneling, will effectively 
   appear to be at a fixed topological location in the mobility 
   service provider's network as long as it does not bootstrap again 
   with a new local home agent.

   Consequently, if a high level of location privacy is desired, a 
   mobile node should not switch to local home agents in an eager 
   manner or should not reveal its home address to untrusted nodes. 
   Furthermore, the disclosure of policy information that can help 
   locating the mobile node such as mobile node's home agent 
   selection policy and the home agent allocation policy of ASPs 
   should be carefully considered.

Kilian

> Sent: Donnerstag, 2. März 2006 17:52
> To: Kilian Weniger
> Cc: [email-masked]
> Thanks for pointing out the missing security consideration 
> for location privacy concern that you brought up. I searched 
> the old discussion threads, but could not dig out the 
> relevant text that we could re-use.
> 
> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."
> 
>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 3 Mar 2006 13:43:18 -0500

Killian,

Thanks for the proposed text for location privacy. Is it possible for you to somehow make it less wordy? 

I think the main issue is that by knowing the MN's HoA one can track its location. The frequency of bootstrapping, the deployment style of the HAs in the MSP, and DNS update with the newly bootstrapped HoA all impact how coarse or fine the granularity of location determination by an attacker is going to be. 

-Kuntal

> Sent: Friday, March 03, 2006 9:06 AM
> To: Chowdhury, Kuntal
> Cc: [email-masked]

---

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 6 Mar 2006 11:18:12 +0100

Hello Kuntal,

I cut the paragraph about the accuracy of revealed location information. 
To keep the analysis precise and complete, I would not cut the text much more.

   If the home agent selected by the mobile node is local or nearby, 
   (as in section 3.2.2), disclosing the mobile node's home address
   (e.g., by updating the mobile node's FQDN in the DNS) has the 
   potential to expose some information about the mobile node's 
   location. 

   the mobile node's current home addresses. The accuracy of the
   revealed location information depends on the deployment style of 
   home agents and the frequency of bootstrapping.

   locating the mobile node should be carefully considered.

Cheers,

Kilian

> Sent: Freitag, 3. März 2006 19:43
> To: Kilian Weniger
> Cc: [email-masked]
> Thanks for the proposed text for location privacy. Is it 
> possible for you to somehow make it less wordy? 
> 
> I think the main issue is that by knowing the MN's HoA one 
> can track its location. The frequency of bootstrapping, the 
> deployment style of the HAs in the MSP, and DNS update with 
> the newly bootstrapped HoA all impact how coarse or fine the 
> granularity of location determination by an attacker is going to be. 
> 
> -Kuntal
> 
>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 7 Mar 2006 23:49:16 -0500

Kilian,

Thanks for modifying the text. It looks good. We need to qualify the term "local". The way things are defined in Mip6 bootstrapping solution is that the MSP is the entity that provides the home agent. So, regardless of near/far, local/remote...the home agent is always in the MSP.

Could you clarify this in the text or if you are OK, I can do that while updating the I-D.

-Kuntal

> Sent: Monday, March 06, 2006 4:18 AM
> To: Chowdhury, Kuntal
> Cc: [email-masked]

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 8 Mar 2006 09:45:37 +0100

Hello Kuntal, 

the term "local home agent" was defined in the previous (uncut) version of the proposed text. After you requested to shorten the text, I deleted the definition from the first paragraph. I thought the term is well-known, because it is also used in draft-ietf-mip6-bootstrapping-split and draft-ietf-mip6-bootstrap-ps (maybe it should be added to the corresponding terminology sections). If you want you can replace the first paragraph with the one of the uncut version, which includes the definition:

Kilian

> Sent: Mittwoch, 8. März 2006 05:49
> To: Kilian Weniger
> Cc: [email-masked]
> Thanks for modifying the text. It looks good. We need to 
> qualify the term "local". The way things are defined in Mip6 
> bootstrapping solution is that the MSP is the entity that 
> provides the home agent. So, regardless of near/far, 
> local/remote...the home agent is always in the MSP.
> 
> > To keep the analysis precise and complete, I would not cut 
> the text much
> > more.
> > 
> > > > > > > Are there any comments on the integrated scenario 
> bootstrap
> > > > > > > solution? If