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

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 4 Oct 2005 15:41:42 +0200

Sorry for the late reply. 
Vijay already provided some answers that I had in mind. Please see some
further comments below.

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

I agree. But maybe "...must not use Route Optimization mode" would be
more accurate than "...must not route optimize traffic", since other
mechanisms (e.g., draft-weniger-rota-00.txt) exist that optimize the
route without revealing the CoA to CN.
 
> 2) The solution in draft-ietf-mip6-bootstrapping-split does 
> not specify 
> anything for local home agent assignment. There is nothing in 

But draft-ietf-mip6-bootstrapping-split supports location-dependent HA
address discovery, as Vijay pointed out. Consequently, MN should be able
to discover and bootstrap an HA from the visited network, i.e., a local
HA, right? 

> the protocol 
> to actually move the HA from the MSP's network to the serving 
> network. The 

What do you mean by moving the HA? A scenario that I had in mind is what
I called "eager local HA assignment": A MN bootstraps with a local HA
after moving to a new network while being registered with other (e.g.,
previously local) HAs. The other HAs can be used for ongoing
communication sessions, whereas the new (local) HA can be used for
future communication sessions (e.g., for improved routing efficiency in
case of reverse tunneling).

> MN gets to choose an HA from whatever HAs the MSP's DNS SRV 
> RR advertises. 

As already mentioned, I had location-dependent HA address discovery in
mind (as mentioned in section 5.1.1 DNS lookup by Home Agent Name).

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

I agree that in general other nodes do not know if the HoA in MN's DNS
entry belongs to a local HA or a remote HA, i.e., whether the MN is
currently at the location corresponding to the HoA in DNS or not. I
think this is also the issue Gerardo mentioned in his mail.

The severity of the issue depends on the MN's strategy to select HAs for
bootstrapping and whether this strategy is known. E.g., if most MNs use
local HAs, the MN's HoA obtained from DNS most likely corresponds to
MN's location. If most MNs don't use local HAs, this problem might be
less severe. Maybe different providers force different (default)
strategies, but if the strategy is known, the problem may become severe
again.
Note that it might be beneficial to use HAs from the visited network,
since they can provide good routing efficiency even in case of reverse
tunneling. 

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

I guess this location privacy issue applies more to the integrated
scenario. But as the integrated scenario can be seen a special case of
the split scenario, it should apply to both. 

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

Yes, CN cannot track MN's movement by looking at the very MN's HoA that
CN's higher layers are using for communication with MN. The text was not
very clear at this point. The issue is that CN (and any other node)
might be able to track MN's movement by constantly querying MN's DNS
entry. However, this is only possible in the "eager local HA assignment"
scenario, i.e., if the MN always bootstraps with a local HA when
changing networks and requests DNS updates subsequently. As already
mentioned, this would have the benefit of improved routing efficiency in
case of reverse tunneling. 
BTW, in this scenario the MN's DNS entry may potentially change quite
frequently. Since I currently do not see a motivation for MNs to
frequently bootstrap with different remote HAs, this could be a hint
that the MN's HoAs in DNS belong to local HAs. 

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

I'm fine with the first half of the text. In the second half, maybe it
should be made clear that MN only appears to be at a fixed topological
location as long as it does not bootstrap with a new HA and requests DNS
update accordingly. Otherwise, nodes can query DNS to find out the new
MN's HoA and thus the potential new location.

Cheers,

Kilian

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

---

From: Gerardo Giaretta <[email-masked]>
Date: Tue, 04 Oct 2005 16:17:48 +0200

Hi Kilian,

please see some quick comments below...

> to discover and bootstrap an HA from the visited network, 

Yes. Note that this is true only if MSP == ASP, otherwise we do not have
a local HA assignment.

As a side note, the HA discovery based on location-dependent naming is
currently an open issue of the draft. See issue 53 in the issue tracker
(http://www.mip4.org/issues/tracker/mip6/).

> case of reverse tunneling).

I agree that this may be a possible scenario. 

> think this is also the issue Gerardo mentioned in his mail.

Yes, my point is that the CNs cannot be sure if the HA assigned to the
MN is a local or a remote one.

> strategies, but if the strategy is known, the problem may 

The CNs should "discover" somehow the HA assignment policies of the
operator. I guess this is not simple if different providers have
different strategies, but I agree that it may be possible as you
mentioned.

> the split scenario, it should apply to both. 

It applies more to integrated scenario because ideally in the split
scenario there is no relationship between the mobility service and the
network access service. But I agree that it may be an issue also in
split scenario since it is possible that MSP==ASP and that the MN
discovers the HA by a name that is geographic-dependent.

> MN's HoA and thus the potential new location.

okay, I think we are near to reach an agreement. 
Kilian, can you please send some text based on James' text so that we
can close the issue?

--Gerardo

> Kilian

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

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 5 Oct 2005 10:51:29 +0200

(sending again without superfluous line breaks...)

> Kilian, can you please send some text based on James' text so that we

O.k., I tried to incorporate James' comments. How about the following
text

   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, i.e., it is in the serving 
   network access provider's network (that is, the serving network 
   access provider is also acting as the mobility service provider). 

   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 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 
   network regardless of the current mobile node's location. Thus, 
   only the location at the time of bootstrapping would be revealed. 
   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 low.

   However, the risk may be high if the mobile node's home agent 
   selection policy is known. If, for instance, the mobile node 
   bootstraps 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 are 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 not within the
   serving network access provider's network. 

The text may also be applicable (with some changes) to the solution
draft for the integrated scenario.

Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 17 Oct 2005 10:52:35 +0200

I agree that the split scenario draft says that local HA assignment is
out of scope (although it mentions benefits of local HAs and describes
two examples how a mobile node can be provided with a local HA). 

My assumption was that local (or nearby) HA assignment is possible with
an implementation complying to the split scenario draft, because the
protocol as described fundamentally supports bootstrapping with any HA
(including local or nearby HAs). Even if a local HA naming convention is
not given in the draft, an operator might, e.g., use its own
local/nearby HA naming convention and provide local/nearby HA service to
its users (or even for roaming users) to improve efficiency. Or a user
on a trip in another country (manually?) discovers a "nearby" HA by
using the country code suffix and bootstraps with this HA. Or would you
say that this does not comply with the split scenario draft? 

Please don't get me wrong, I fully support the bootstrapping split
scenario solution. I just think that, provided that the assumption above
is correct, including a short note about location privacy in the seccons
section would be good (and I think we already agreed that the issue only
exists in specific scenarios). If the assumption above is not correct, I
agree to the short note James suggested.

Regards,

Kilian

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]] 
> Sent: Mittwoch, 12. Oktober 2005 20:03
> To: Kilian Weniger
> Cc: Gerardo Giaretta; [email-masked]; Vijay Devarapalli
> Subject: Re: [Mip6] review of 
> draft-ietf-mip6-bootstrapping-split-00.txt
> 
> 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
> 
> 
> 
> > 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:
> 
>    selected by the mobile node is local or nearby, i.e., it is in or
>    close to the serving network access provider's network.
> 
>    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.
> 
>    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
> 
> 
> 
> 
> 
> 
> 
> 
> 
>