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

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 11 Oct 2005 10:37:21 +0200

> 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 

In one example I have given in the last emails the eavesdropper
additionally knows the victim's HA selection policy and this policy is
"always using nearby HAs". IMO, no additional information such as
victim's customary MSP would be needed in this scenario (of course, it
is again assumed that HoAs are DNS-registered). 

Note that this HA selection policy is not far-fetched because it can
provide good routing efficiency in bi-directional tunneling mode. Also
note that for good routing efficiency of CN-initiated sessions,
DNS-registered HoAs are required.

> subnet prefixes 
> assigned to home addresses by the victim's customary MSP, how can the 
> attacker determine that the current HoA is somehow different? 

Again, if the victim's policy is "always using nearby HAs" (this implies
that the victim only uses its customary MSP if it is close to this MSP)
and the eavesdopper is aware of that, the eavesdropper knows that the
new HA is nearby. I agree that in case the current ASP does not provide
local HA service, the location information is less accurate (as you
mentioned, an eavesdropper may be aware of the local HA support of
ASPs). In this case the MN could bootstrap with an HA of a nearby MSP
(In the worst case "nearby" may mean in the same country).

> 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 

see above

> jak>> I belive there is a threat, and I think it worthwhile 
> to describe it. 

I agree.

> I think the amount of information required (a-d) is rather 
> large, but not 
> undoable for a dedicated attacker.

I think there are scenarios where less information is needed (see
above).

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

I agree to this, but it is a different question whether a solution
*intends* to enable something or whether it enables something. ;)
So far, I didn't see anything in the split scenario draft that prevents
MNs from bootstrapping with different HAs more or less frequently (at
least frequent enough that enables the policy "always using nearby
HAs").

> 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.

No, I'm not talking about MN's FQDN, I'm talking about HA's FQDN. The
issue is that location-dependent HA discovery is possible to some extent
by using the country code suffix of an HA's FQDN. If, for example, the
user roams from US to Germany, it can discover an HA located in Germany
by querying, e.g., "ha.t-mobile.de" or "ha.vodafone.de" (or
"_mip6._ipv6.vodafone.de"). This HA would be "nearby", but not
necessarily "local".

Kilian

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Oct 2005 14:57:31 -0700

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.

jak>> In addition, how does the attacker know the victim's selection 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.

see above

I agree.

jak>> OK.

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.

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.

            jak