[Mobopts] New I-D: draft-weniger-mobopts-mip6-cnlocpriv-01 (Correspondent Node-Targeted Location Privacy and Optimized Routing)

Hi all,

draft-weniger-mobopts-mip6-cnlocpriv was presented and discussed at the
last mobopts meeting in San Diego. The draft proposes a simple mechanism
based on the MIPv6 bootstrapping solutions that allows a MN to utilize
an optimized route without revealing its location to the CN. This
feature is currently not fully supported by
draft-irtf-mobopts-location-privacy-solutions (see section 2 of
draft-weniger-mobopts-mip6-cnlocpriv for reasoning). 

We received some valuable questions and comments during the meeting,
mainly on deployment issues. I tried to address all of those in the new
draft. A short summary:

- Aren't there many new trust/roaming relationships required? 
It is expected that the trust/roaming relationships that are needed for
draft-ietf-mip6-bootstrapping-integrated-02 can be re-used (see section
3 for details).

- Isn't this solution only applicable if there is a home agent in every
correspondent node's domain?
It is not required that the home agent (ORHA) is located in the
correspondent node's domain.  A domain nearby to the correspondent
node's domain is sufficient to achieve location privacy and improved
routing efficiency. It is expected that the (local) HAs needed for
draft-ietf-mip6-bootstrapping-integrated-02 can be re-used.

- Isn't location privacy compromised since the home agent (ORHA) is
close to the CN?
Since the ORHA learns the location of the mobile node, the mobile node
must be sure that the ORHA doesn't reveal the mobile node's location to
nodes that are not authorized to get the location, i.e., the ORHA must
be trusted by the mobile node. It is assumed that the ORHA discovery
mechanism only returns trusted home agents or that the mobile node is
able to verify during the bootstrapping procedure whether the ORHA is
trusted. Note that even if the ORHA and correspondent node are in the
same domain, this doesn't imply that the ORHA reveals the mobile node's
location to the correspondent node. This is also true in today's
cellular networks, where it is ensured that users of a service provided
by a particular operator don't know the location of other users using a
service provided by the same operator.

- How can an ORHA be discovered?
A specification of a discovery mechanism is currently out of scope, but
one option could be to re-use DHCP-based HA assignment as defined in
draft-ietf-mip6-bootstrapping-integrated and draft-ietf-mip6-hiopt. The
mobile node would put the correspondent node's domain as target domain
in the Home Network Identifier DHCP Option and the mobile node's MSA
would then determine and assign a home agent to the mobile node, which
is in or close to the correspondent node's domain (see section 5 for
details).

The new draft draft-weniger-mobopts-mip6-cnlocpriv-01.txt should appear
on the announce I-D list soon. Before that, it can be accessed at
http://home.arcor.de/k.weniger/draft-weniger-mobopts-mip6-cnlocpriv-01.t
xt

Comments are highly appreciated. 

Regards,

Kilian

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts