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

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 12 Oct 2005 12:02:01 +0200

> jak>> Just knowing the victim's selection policy is not 
> sufficient. The 
> attacker would also have to know the serving ASP's local home agent 
> allocation policy - does the serving ASP allocate home agents 
> or not? If it 
> doesn't, then the attacker would incorrectly conclude that 
> Alice is in Palo 
> Alto when she is actually in Tucson when it saw the DNS entry 
> change to a 
> HoA that was provided by Bob' Mobility Service in Palo Alto.

I think we are just arguing about the accuracy of location information
revealed. I agree that if the eavesdropper does not know whether the ASP
provides local HA service, there is some uncertainty, but IMO some
location information can still be revealed (with lower accuracy). In the
scenario I described, the victim always selects a "nearby" HA (to
improve routing efficiency), i.e., one that is in or at least close to
the serving ASP (in the worst case the HA is only in the same country
than the serving ASP). Hence, the eavesdropper can conclude that the
victim is in or somewhere close the serving ASP. I agree that the
accuracy of the location information might not be known by the
eavesdropper, at least as long as it does not have additional policy
information.

> 
> jak>> In addition, how does the attacker know the victim's 
> selection policy? 

Yes, that's another issue. One possibility may be that a provider has a
default policy, which the eavesdropper can find out. 
Anyhow, I think the main point is that we describe the location privacy
issue in the draft, so that others are aware of it and, e.g., try to not
disclose the policy.

> What I was trying to suggest is that, short of having the 
> victim tell the 
> attacker (which is of course possible, for example, through a spyware 
> infection), the attacker would need to observe changes in the 
> victim's DNS 
> entry over time and correlate that with information on the 
> local home agent 
> allocation policy of the serving ASP.

o.k., I see. I agree that's one way, but maybe not the only one (as you
mentioned yourself).

> jak>> How does this provide any information about the 
> victim's location? It 
> depends on whether the victim actually uses the local home 
> agent or not, 
> which, as you mention above, depends on the victim's local home agent 
> selection policy. If the victim doesn't use ha.t-mobile.de, 
> but rather 
> ha.t-mobile.us, then there's no problem.

Yes, but I was assuming there would be enough MSPs in Germany, of which
at least one would provide an HA bootstrapping service to the victim (I
think that's not a far-fetched assumption). Then there is a possible
issue. 
The main point I tried to make clear is that an issue may exist even
without *local HA discovery*, since *nearby HA discovery* might be
possible with the solution. One way could be country code suffixes
(although I agree that the possibly revealed location information would
be of low accuracy).

> 
> jak>> Anyway, Gerardo wants us to come to agreement on this 
> now so that we 
> can wrap up the draft prior to the IETF 64 drafts deadline. 
> How about the 
> following:
> 
> 1) We put a two sentence paragraph in the SecCons section of 
> draft-mip6-bootstrapping-split that says the following:
> 
>     Allocation of a local home agent raises a possible risk 
> of location 
> privacy compromise. Since the details of how this threat 
> might be actualized 
> depend on how a local home agent is allocated, and local home agent 
> allocation is out of scope for this document, the Security 
> Considerations 
> section of specifications that describe or include local home agent 
> allocation should be consulted for details.
> 
> 2) We include a detailed description of the location privacy 
> threat and how 
> to counter it in the SecCons section of 
> draft-mip6-bootstrapping-integrated, 
> which does include a mechanism for local home agent allocation.

If the question is whether to include nothing or a short note, I prefer
the short note of course. However, I tried to make clear that IMO there
can be an issue with the allocation of "nearby", non-local HAs (with
"local HA" defined as HA in serving ASP network and "nearby HA" as HA in
network close to serving ASP network). This issue would be *specific to
the split scenario*. Hence, if you and others agree to the nearby HAs
issue, this should be reflected by the note IMO. However, in this case I
would prefer to add a more detailed description about the issue specific
to the split scenario to the draft - if not now (because of the
deadline) then at least in a later revision.

But why not use the text initially proposed by you, which has already
been agreed by you and Vijay. We can modify it slightly considering the
recent (IMO fruitful) discussions. We can still refine it later, if
necessary. How about this:

   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 other nodes if the home agent 
   selected by the mobile node is local or nearby, i.e., it is in or 
   close to the serving network access provider's network. 

   For three reasons, the risk here is not as deep as known from Route 
   Optimization mode [draft-koodli-mip6-location-privacy-00.txt]. 
   First, other nodes usually do not know whether the mobile node's 
   home address belongs to a home agent that is local, nearby or 
   remote for the mobile node and, hence, whether the mobile node is 
   really at the location corresponding to the home address. Second, 
   the mobile node (if using reverse tunneling) will effectively 
   appear to be at a fixed topological location in the mobility 
   service provider's as long as it does not bootstrap again with a 
   different home agent in a different network and request DNS update 
   subsequently. Third, depending on the deployment scenario, the 
   geographical area covered by a local home agent (being the "most 
   local" home agent) may be much larger than the area covered by an 
   access router. Since the accuracy of the location derivable from 
   the address decreases with increasing coverage, the accuracy may be 
   lower. In case the HA is only nearby, but not local, the accuracy 
   may be even lower.

   However, the risk may be higher if additional information is known.
   E.g., the mobile node's home agent selection policy and the home 
   agent allocation policy of ASPs can provide information about 
   whether an home agent is local, nearby or remote for the mobile 
   node. If, for instance, the mobile node's home agent selection 
   policy is to bootstrap with a new local home agent as soon as 
   moving to another network to improve routing efficiency of future 
   communication sessions in Bi-directional Tunneling mode, other 
   nodes being aware of the policies may be able to track mobile 
   node's movement to some extent by constantly querying mobile 
   node's DNS entry. 

   To mitigate the risk, the mobile node should either not request DNS 
   update or be careful to select a home agent that is local or nearby. 
   Furthermore, the disclosure of related policy information such as 
   mobile node's home agent selection policy and the home agent 
   allocation policy of ASPs should be carefully considered.

Regards,

Kilian

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Oct 2005 11:03:03 -0700

No, I do not agree to this extensive note.

The split scenerio draft specifically says that the details of local home 
agent allocation are *out of scope*. I don't see the point of a detailed 
security analysis of something that is not covered in the draft. If you or 
someone else writes a draft that says how to do local home agent allocation 
in the split scenerio, then that is the right place for an extensive 
analysis.

What do other members of the WG think?

            jak

----- Original Message ----- 
From: "Kilian Weniger" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Gerardo Giaretta" <[email-masked]>; <[email-masked]>; "Vijay 
Devarapalli" <[email-masked]>
Sent: Wednesday, October 12, 2005 3:02 AM
Subject: RE: [Mip6] review of draft-ietf-mip6-bootstrapping-split-00.txt

Regards,

Kilian

---

From: Francis Dupont <[email-masked]>
Date: Sun, 16 Oct 2005 10:45:02 +0200

In your previous mail you wrote:

=> I fully agree! Local HA stuff is clearly out of scope.

Regards

[email-masked]