Subject: RE: [Mip6] review of draft-ietf-mip6-bootstrapping-split-00.txt

From: Gerardo Giaretta <[email-masked]>
Date: Mon, 03 Oct 2005 15:23:17 +0200

> I still don't see what the problem is with the text I provided.
> 
> Suppose we try an example. Let's suppose Alice's MSP is Bob's 
> Mobile IP 
> Service (domain name: bobsmova.com). Suppose Bob owns an 
> access network that 
> covers Palo Alto and Mountain View in California (actually, 
> Bob might not 
> own any access network at all, but for the moment, let's 
> suppose he does). 
> Now, suppose Alice is moving north on El Camino Real in Palo 
> Alto and is 
> using Bob's HA (ha1.bobsmova.com). She's got an HoA in the 
> subnet routed by 
> ha1.bobsmova.com, which just so happens to cover that part of 
> El Camino Real 
> between San Antonio and the intersection of Charleston and 
> Arastadero. 
> Suppose Alice is paranoid about people tracking her movements 
> so she never 
> does route optimization so people never see her care of 
> address, but she 
> does put her HoA into the DNS so that people can SIP call her, at 
> alice.bobsmova.com (Bob also acts as her MSA). Since 
> ha1.bobsmova.com is 
> local to Palo Alto, Alice has obtained a local HA and HoA.
> 
> Now, let's suppose Alice goes to Tucson in order to attend a 
> conference. 
> Alice is driving north on Speedway. She uses Bob's Mobile IP 
> service there 
> too, and she's got a HoA in Bob's network. Maybe the HA is even 
> ha1.bobsmova.com. She puts that HoA into Bob's DNS at 
> alice.bobsmova.com, 
> and she never uses route optimization.
> 
> How can anybody deduce any geographical information about 
> Alice? If Alice 
> never exposes her care of address and always uses her home 
> address, how can 
> they tell if she's between San Antonio and the Charleston/Arastadero 
> intersection in Palo Alto (covered by the subnet that her 
> home address is 
> in), or if she's between the Page Mill Road/Oregon Expressway 
> intersection 
> and the Charleston/Arastadero intersection in Palo Alto 
> (which is in Bob's 
> network but is not covered by the subnet that Alice 's home 
> address is in), 
> or, for that matter, whether she is in Palto Alto at all and 
> not in Tucson 
> (which is not covered by Bob's access network)?
> 

Exactly. From the HoA, CNs can only guess the location where the MN MAY*
have performed bootstrapping procedure. This may be very different from
the current location of the MN.

* moreover, how the CNs know for sure that the MN bootstrapped with a
local HA if bidirectional tunneling is always used? If this the case
(i.e. the CN does not know if the MN has been alloctaed a local HA or
remote HA), is this a real threat to the location privacy of the MN?

--Gerardo 

>             jakb
> 
> ----- Original Message ----- 
> From: "Vijay Devarapallli" <[email-masked]>
> To: "James Kempf" <[email-masked]>
> Cc: "Gerardo Giaretta" <[email-masked]>; "Vijay 
> Devarapalli" 
> <[email-masked]>; "Kilian Weniger" 
> <[email-masked]>; 
> <[email-masked]>
> Sent: Friday, September 30, 2005 4:58 PM
> Subject: Re: [Mip6] review of 
> draft-ietf-mip6-bootstrapping-split-00.txt
> 
> 
> there is some confusion.
> 
> Jim, Kilian's main concern is when the MN configures a HA
> from the visited link (using location specific HA FQDN).
> the issue is if the MN configures a HA and HoA from the
> visited link and then has its DNS entry updated, then the
> CN knows where the MN is currently located. the MN can
> continue doing DNS updates for home address configured from
> the home link. causes no harm. but when it does a DNS update
> for the home address configured from a HA on a visited link,
> it immediately reveals its location to the CN. maybe we
> could add the following to the security considerations section
> 
>   A mobile node could hide its location from its correspondent
>   node by reverse tunneling all traffic through the home agent.
>   The same mobile node could roam and configure a home agent
>   and home address from a visited link. If the home agent
>   updates the DNS entry of the mobile node with its new home
>   address, then this may reveal the current location of the
>   mobile node to the correspondent node. In such a if the mobile
>   node does not want the correspondent node to know its current
>   location, then it should not request the home agent to update
>   the DNS entry.
> 
> comments?
> 
> Vijay
> 
> On 9/30/05, James Kempf <[email-masked]> wrote:
> > Comments.
> >
> > "Note that local HA assignment combined with DNS updates 
> may violate the
> > location privacy of MN. A known solution to location 
> privacy is to hide
> > the CoA from CN by using reverse tunneling to the HA
> > [draft-koodli-mip6-location-privacy-solutions-00.txt]. 
> However, reverse
> > tunneling may significantly decrease routing efficiency, 
> depending on
> > how far the HA is off the direct path between MN and CN.The
> > bootstrapping solution supports local HA assignment to 
> improve routing
> > efficiency, but since the HoA obtained from a local HA assignment
> > topologically belongs to the visited network, it contains location
> > information. Consequently, it must carefully be considered 
> to whom this
> > HoA is revealed and whether DNS updates are requested for 
> this HoA. The
> > latter can even enable others to track MN's movement, if 
> the MN uses an
> > eager strategy for local HA assignment. On the other hand, 
> if the HoA is
> > hidden from other nodes, they cannot reach the MN at this 
> HoA and, thus,
> > cannot benefit from the local HA assignment in terms of routing
> > efficiency. "
> >
> >  jak>> I have a couple problems with this:
> >
> > 1)  Reverse tunneling is the default in IPv6, that is to 
> say, if an HA is
> > used, reverse tunneling must be used, unless the traffic is route 
> > optimized.
> > So it is more accurate to say that in order to protect 
> privacy, the MN 
> > must
> > not route optimize traffic.
> >
> > 2) The solution in draft-ietf-mip6-bootstrapping-split does 
> not specify
> > anything for local home agent assignment. There is nothing 
> in the protocol
> > to actually move the HA from the MSP's network to the 
> serving network. The
> > MN gets to choose an HA from whatever HAs the MSP's DNS SRV 
> RR advertises.
> > If that happens to be in the serving network, then 
> correspondents will be
> > able to obtain some information about where the MN is, but it could 
> > equally
> > well be on the other side of the globe.
> >
> > Note that the integrated scenerio (which the DT is 
> currently working on)
> > will have a mechanism whereby a local home agent can be 
> assigned, since 
> > the
> > MN gets the HA address from the local DHCP server.
> >
> > 3) Since the HoA doesn't change once the MN has established 
> it, I fail to
> > see how an attacker can track the MN's location. Once the MN has 
> > established
> > the HoA, it will appear to be at a fixed topological 
> location in the MSP's
> > network regardless of where the care of address is, if 
> route optimization 
> > is
> > not used.
> >
> > So I think the risk is considerably less that is portrayed 
> by the above
> > text. I think the following text would be more accurate:
> >
> >     Updating the mobile node's FQDN in the DNS
> >     with the mobile node's home address has the
> >     potential to expose some information about
> >     the mobile node's location to correspondents
> >     if the home agent selected by the mobile
> >     node is in the serving network access provider's
> >     network (that is, the serving network access
> >     provider is also acting as the mobility service
> >     provider). The risk here is not as deep as
> >     with route optimization, since the mobile node
> >     will effectively appear to be at a fixed topological
> >     location in the mobility service provider's network
> >     regardless of where the care of address is. To
> >     mitigate the risk, the mobile node should
> >     either not request DNS update or be careful
> >     to select a home agent that is not within the
> >     serving network access provider's network.
> >
> >
> >             jak
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6
> >
> 
> 
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 03 Oct 2005 18:49:48 -0700

> remote HA), is this a real threat to the location privacy of the MN?

well, the CN earlier used to see a home address from a home agent
in Palo Alto and now it sees a home address from a home agent in
Tuscon.

Vijay