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

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 10 Oct 2005 16:45:34 +0200

Hi James,

please see comments inline.

> jak>> The only way an eavesdropper could know, from a 
> DNS-registered home 
> address obtained through bootstrapping, that a MN is at a particular 
> location is:
> 
> 1) The eavesdropper has been keeping track of the DNS-registered home 
> address in the past and has seen that the newly registered address is 
> different,
> 2) The eavesdropper knows the victim's home MSP, either from previous 
> addresses, or from some other way (note: the victim's FQDN 
> doesn't provide 
> any information in general about the MSP, because the FQDN is 
> handled by the 
> MSA, which might be a separate administrative entity),
> 2) The eavesdropper knows that the newly registered address 
> belongs to an 
> MSP that is not the victim's home MSP and that the current 
> MSP routinely 
> uses local home agents,

Can you clarify why the eavesdropper needs to know the home MSP of the
victim and/or that the newly registered address is different?

IMO, it is sufficient that the victim uses a DNS-registered HoA of a
nearby HA (e.g., to improve routing efficiency) and that the
eavesdropper knows that this HA is (currently) nearby for the victim. In
this case, the eavesdropper can find out the approx. location by
querying the victim's FQDN in DNS. If the victim constantly obtains
DNS-registered HoAs of "the most nearby" HAs when moving, the
eavesdropper can track the victim's movement. In both cases, I don't see
why the eavesdropper would need to know the victim's home MSP. IMO, it
would only need to know the victim's FQDN and the victim's HA selection
policy. How easy it is for the eavesdropper to determine the victim's HA
selection policy is another issue, but relying on secrecy of the policy
would remind me on "security through obscurity".

Or do you mean that the eavesdropper might not be sure whether the
victim is *currently* nearby to the HA. In the latter case (where DNS is
constantly updated with the most nearby HA) this is trivial, in the
former case the eavesdropper can possibly be more certain that the HA is
still nearby for the victim when the HoA in DNS has recently changed,
but that depends on the movement pattern of the MN. However, I guess
keeping track of an DNS entry is not difficult for an eavesdropper. 

BTW, I called the HA "nearby" because it even doesn't need to be local.
If the serving access network provider does not provide local HA
bootstrapping service, the MN could select an HA of a nearby network,
i.e., the MSP would be different from ASP and different from home MSP.
This can improve routing efficiency if the home MSP is far away and the
ASP doesn't provide local HA bootstrapping for this user. For instance,
if a user from US roams to Vodafone Germany and Vodafone Germany does
not support local HA bootstrapping for this user, the user may bootstrap
with an HA of T-Mobile Germany to still improve routing efficiency. It
could, e.g., discover an HA in Germany using country code suffixes and a
list of MSPs (e.g., "ha.t-mobile.de", "ha.vodafone.de",...). 

> 
> In addition, the granularity of the information obtained from 
> the home 
> address depends on the topological to geographical coverage 
> of the home 

I totally agree. That's reflected in the text.

> agent. So if the coverage area is, say, the entire Bay Area 
> in California, 
> the eavesdropper doesn't get a whole heck of a lot of 
> information about 
> where the person is.

I think whether this scenario would be an issue for the user depends on
the location privacy requirements of the user. At least some users don't
even want to disclose whether they are currently on a trip in another
country, e.g., because this can provide a hint to burglars.

> 
> jak>> My point is that the eavesdropper needs a lot of additional 
> information about the victim and the MSPs that the victim is 
> using before it 
> can conclude anything about the location. If you want to put 
> all these 
> conditions into the text, I think it would make the description more 
> accurate.

see comment above

> 
> Can
> you agree to the following sentence (and we drop the "Thus..revealed"
> sentence, as you suggested)?
> 
>    "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."
> 
> jak>> That seems OK.
> 
> > interoperability. If we decide in favor of removing, then I
> > think we should
> > save this text and put it into the integrated scenerio draft.
> 
> I agree that the potential location privacy issue with local 
> HAs should
> be described in the sec cons sections in the integrated 
> scenario draft.
> But even if the text about location-dependent HA naming is 
> removed from
> the split scenario draft, location-dependent HA discovery may still be
> possible to some extent by using country code suffixes (the 
> location is
> of course much less accurate). Depending on how strict the requirement
> for location privacy is, an issue may still exist. If, for instance, a
> user from US is on a business trip in Europe and that user roams to
> Vodafone Germany, it may discover an HA for bootstrapping using
> "ha1.vodafone.de" or "_mip6._ipv6.vodafone.de". When updating DNS with
> the new HoA, that may give a hint that the user is currently 
> in Germany.
> 
> jak>> If Vodafone has no local HA service in Germany, then 
> the user will 
> always use it's home MSP in the US. So there's no issue.

As I said above, the user may also use another nearby MSP to improve
routing efficiency and various ways to discover a more or less nearby HA
may exist, e.g., by using country code suffixes.

> jak>> We're currently discussing among the authors about what 
> to put in the 
> draft regarding local home agent assignment. If there is no 
> text specifying 
> how to do it, then I think we don't need to say anything. But 
> I think we do 
> need to say something in the integrated scenario draft, 
> because it will be 
> possible there.

I think the issue potentially exists once location-dependent HA
discovery is possible with the solution (plus DNS updates, of course)
and this may be possible (at least to some extent) with the DNS-based
discovery procedure described in the split scenario draft even without
the text about local home agent assigment (e.g., by using country code
suffixes). Hence, I would prefer to add text about this issue in the
integrated scenario draft AND the split scenario draft, even in case you
decide to remove the text about local home agent assigment.

Regards,

Kilian

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Oct 2005 09:37:12 -0700

jak>> Given that the attacker only sees the current DNS entry (knows nothing 
more) how is to determine if the HA and HoA are "nearby" to the victim or 
not? Unless the attacker knows somehow specifically the subnet prefixes 
assigned to home addresses by the victim's customary MSP, how can the 
attacker determine that the current HoA is somehow different? And, again, 
even if the attacker knows the prefixes assigned by the customary MSP and it 
sees an HoA with a prefix not in that set, how can the attacker determine 
that the victim is in a particular geographical location when it sees that 
prefix? Returning to my previous example, the victim might be using an MSP 
in Tucson today, though it usually uses one in Palo Alto, but the victim 
might actually be in Chicago and using that MSP because it was the only one 
offered on the hotspot Web page.

The attacker would have to know a) the customary MSP of the victim so it can 
compare the home prefix to whatever the currently registered prefix is b) 
that the current MSP provides local home agent service so that it can tell 
that the victim must be using an MSP with local home agent c) that the HoA 
is from a home agent that is used to provide local home agent service so it 
can tell whether the victim is in the geographical area or using the HA 
remotely d) a detailed topological to geographical mapping that maps the 
subnets of the home MSPs to geographical areas so that it can work out the 
geographical location of the victim.

jak>> I belive there is a threat, and I think it worthwhile to describe it. 
I think the amount of information required (a-d) is rather large, but not 
undoable for a dedicated attacker.

jak>> There is nothing in RFC 3775 to allow changing HAs frequently, and 
bootstrapping isn't intended to enable this either.

jak>> See above.

jak>> Yes, that's true. This should be mentioned. However, note that there 
are other ways that an attacker could derive this kind of information, for 
example, the round trip time of the packets. Some of these can't be 
eliminated.

see comment above

jak>> Why are country codes an issue? The DNS name for the MN is always 
fixed, otherwise, potential correspondents can't find it. Thus, if I am 
roaming in Germany and my home MSA is in the US, my FQDN always has the 
".us" country code. Even if I am using a local home agent, the name doesn't 
change. And the HA FQDN is never exposed to the correspondent.

jak>> Regarding putting this text in the draft, I believe we have agreed 
that the split draft will only have a very general statement about local 
HAs, and that any further discussion is out of scope. So it seems to me 
better to put it in the integrated draft, where a more detailed discussion 
will occur.

            jak