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

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 30 Sep 2005 10:32:25 +0200

Hi James, Gerardo, Vijay,

my draft does not talk much about location privacy issues of the
bootstrapping solution. It proposes a protocol to solve the trade-off
between location privacy and routing efficiency in Mobile IPv6 in
general (BTW, I'm currently working on the 01-version, which also
supports the scenario shown in Figure 5 of the 00-version). I expect
that ROTA can be combined with the bootstrapping solution.

Regarding the text for the security considerations sections of the
bootstrapping draft, how about something like the following:

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

Kilian

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]] 
> Sent: Donnerstag, 29. September 2005 17:58
> To: Gerardo Giaretta; Vijay Devarapalli; Kilian Weniger
> Cc: [email-masked]
> Subject: Re: [Mip6] review of 
> draft-ietf-mip6-bootstrapping-split-00.txt
> 
> OK, I'll see if I can come up with some text. Can you send a 
> reference to 
> Kilian's draft?
> 
>             jak
> 
> ----- Original Message ----- 
> From: "Gerardo Giaretta" <[email-masked]>
> To: "Vijay Devarapalli" <[email-masked]>; "Kilian Weniger" 
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, September 29, 2005 2:14 AM
> Subject: RE: [Mip6] review of 
> draft-ietf-mip6-bootstrapping-split-00.txt
> 
> 
> 
> 
> > > If my understanding is correct, I think it might be good to
> > have some
> > > text about that in draft-ietf-mip6-bootstrapping-split-00.txt,
> > > especially because location privacy and routing efficiency
> > is mentioned
> > > in draft-ietf-mip6-bootstrap-ps-03.txt as a motiviation for the
> > > bootstrapping solution.
> >
> > I think I understand your point now. if the MN acquires a local
> > HA and HoA and the MN's DNS entry is updated with the local HoA,
> > then this reveals where the MN is located. there isn't much we
> > can do here. maybe just point this out, as Jim recommended, in
> > the Security Considerations section. (somebody a while ago
> > suggested adding location privacy considerations section to
> > every draft :)
> >
> 
> Agree that there is not much we can do here. Specific solutions to the
> location privacy problem (as the one Kilian pointed out) may be useful
> in this scenario, but I think this is not in the scope of the
> bootstrapping draft. We'll provide some text in Sec Cons section to
> address this issue, as James suggested.
> 
> --Gerardo
> 
> > Vijay
> >
> > >
> > > Kilian
> > >
> > >
> > >>>An alternative solution to this problem is to reverse
> > >>
> > >>tunnel to local
> > >>
> > >>>HAs, but keep the HoA of MN unchanged. This approach is,
> > >>
> > >>e.g., proposed
> > >>
> > >>>in draft-weniger-rota-00.txt.
> > >>>
> > >>>BTW, shouldn't the QNAME be set to "_mip6_ipv6.example.com"
> > >>
> > >>instead of
> > >>
> > >>>"mip6.example.com" in the DNS lookup by service name
> > >>
> > >>example in section
> > >>
> > >>>5.1.2 of draft-ietf-mip6-bootstrapping-split-00.txt?
> > >>
> > >>yes.
> > >>
> > >>Vijay
> > >>
> > >>
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > 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
> 
> 
> 
> 

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 30 Sep 2005 11:35:47 -0700

Comments.

how far the HA is off the direct path between MN and CN.The

 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

---

From: Vijay Devarapallli <[email-masked]>
Date: Fri, 30 Sep 2005 16:58:29 -0700

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?

Vijay