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

From: Gerardo Giaretta <[email-masked]>
Date: Mon, 03 Oct 2005 14:23:29 +0200

Vijay, 

few comments below...

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

I would mitigate a little bit this possible threat to the location
privacy of the MN.

First of all, we don't specify a way to allocate a local HA in
draft-ietf-mip6-bootstrapping-split. This is correct since in split
scenario there is no assumption on ASP. Therefore, this text may be more
appropriate to the integrated scenario.

Besides that, based on the HoA, a CN can only guess the location from
which the MN performed the bootstrapping procedure. Subsequent movements
are not visible to CNs if bidirectional tunneling is used. This may or
may not be an issue depending the mobility pattern of the MN, too. I'd
suggest to include a sentence about this in the draft, if we want to
address this issue.

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

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

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

---

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

> appropriate to the integrated scenario.

but we do provide a mechanism using DNS. FQDNs could be configured
such that the MN can lookup a HA based on its location.

> suggest to include a sentence about this in the draft, if we want to

the issue is about using different home addresses for the same FQDN.
the home addresses could potentially reveal where the MN is located.

Vijay