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

From: "James Kempf" <[email-masked]>
Date: Sat, 1 Oct 2005 20:38:40 -0700

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)?

            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
>

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

---

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

James Kempf wrote:
> Suppose we try an example. 

okay, lets use the 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.
> 
> 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.

Kilian was raising a different issue. the issues is valid when
the access service provider also provides a local HA. lets say
Alice goes to Tucson. she wants to download from a server in
Tucson. ha1.bobsmova.com is too far. the MN and the CN are in
Tucson. she configures a local HA and a local HoA. now if
Alice has the DNS entry alice.bobsmova.com updated with the
local HoA, the CNs know Alice is in Tucson.

Vijay

> 
> 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)?
> 
>            jakb
> 
> ----- Original Message ----- From: "Vijay Devarapallli" <[email-masked]>
> <[email-masked]>; "Kilian Weniger" 
> <[email-masked]>; <[email-masked]>
>> will have a mechanism whereby a local home agent can be assigned, 
>> since the
>> network regardless of where the care of address is, if route 
>> optimization is
>> not used.
>>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 4 Oct 2005 08:30:15 -0700

> local HoA, the CNs know Alice is in Tucson.

Actually, no. What the CN knows is that Alice is now using an MSP with an HA 
in Tucson. She could equally well be in Oracle, Phoenix, or, for that 
matter, Chicago. Bob still might be serving as her MSA, but she may have 
changed her MSP to a Tucson-based MSP.

So I still don't see how being able to allocate a local HA is a problem.

Even if it were a problem, there are a couple other factors to consider.

1) The geographical area covered by a local HA is likely to be large, so the 
risk of location privacy compromise is likely to be relatively minor. It is 
not like using route optimization and exposing the CoA, where the last hop 
link may cover a small area, like an airport waiting lounge or a floor of an 
office building (but could also be quite large too, as is the case in 3G 
networks).

2) We've had some discussion and we have an outstanding issue about the text 
in draft-bootstrapping-split concerning local HA naming conventions. If we 
remove that text (as has been suggested), then there really is no support in 
the split scenario for local HA allocation.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 04 Oct 2005 14:28:34 -0700

James Kempf wrote:
> Actually, no. What the CN knows is that Alice is now using an MSP with 
> an HA in Tucson. She could equally well be in Oracle, Phoenix, or, for 
> that matter, Chicago. Bob still might be serving as her MSA, but she may 
> have changed her MSP to a Tucson-based MSP.

to an extent this is a true. but to the CN it appears as if Alice
who always used to use ha1.bobsmova.com is now suddenly using
a HA in Tuscon. most likely reason is that Alice is roaming in
Tucson.

> 1) The geographical area covered by a local HA is likely to be large, so 
> the risk of location privacy compromise is likely to be relatively 
> minor. It is not like using route optimization and exposing the CoA, 
> where the last hop link may cover a small area, like an airport waiting 
> lounge or a floor of an office building (but could also be quite large 
> too, as is the case in 3G networks).

agree.

> 2) We've had some discussion and we have an outstanding issue about the 
> text in draft-bootstrapping-split concerning local HA naming 
> conventions. If we remove that text (as has been suggested), then there 
> really is no support in the split scenario for local HA allocation.

there is some confusion here. the suggestion to remove it was
because the reviewer felt there were not enough details. the
reviewer in fact likes the feature. :) see Jari Arkko's emails.
we (in the bootstrap design team) had deliberately removed the
details because it is very similar to HA lookup by name. there
is nothing new to explain.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Tue, 4 Oct 2005 14:45:56 -0700

> a HA in Tuscon. most likely reason is that Alice is roaming in

For an eavesdropper to know that she switched MSPs, they would have to 
monitor multiple conversations with Alice. And the assumption that she is 
roaming in Tucson is just that, an assumption. She could have moved to 
Tucson and she is now on a business trip in Chicago, or maybe the Tucson MSP 
is having a special on service this month ($14.95 for the first three 
months, whereas Bob charges $29.95) and Alice has decided to switch service 
providers even though she still lives in Palo Alto.

In other words, without some kind of outside information about Alice, the 
eavesdropper can't know for sure anything about where she is.

>> text in draft-bootstrapping-split concerning local HA naming conventions. 
>> If we remove that text (as has been suggested), then there really is no 
>> support in the split scenario for local HA allocation.
>

As I (perhaps incorrectly) recall, the issue was defining an interoperable 
cannonical naming standard for naming local HAs. We could certainly do that, 
but I am not sure whether draft-bootstrapping-split is the right place to do 
it in. Actually, I like the feature too, its just I think it will be really 
hard to define such a naming convention, and also, as I mentioned before, 
there are many other dimensions of HA service that one might want to name 
one's HAs after, so one needs to ask the question about why this particular 
one should be singled out.

Anyway, I think it might be better to tackle the topic of location privacy 
in draft-bootstrapping-integrated, since there is very clearly an issue of 
local HA assignment, even if you don't buy my argument about a local 
HA-assigned HoA address really not providing much information about the MN's 
real geographic location.

            jak