Network Working Group K. Weniger
Internet-Draft
Expires: June 1, 2009 G. Velev (Ed.)
Panasonic
November 28, 2008
MIPv6 Correspondent Node-Targeted Location Privacy and Optimized Routing
draft-weniger-mobopts-mip6-cnlocpriv-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 1, 2009.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 1]
Internet-Draft CNLocPriv November 2008
Abstract
This document discusses the problem of correspondent node-targeted
location privacy in Mobile IPv6 and proposes a mechanism to achieve
simultaneous optimized routing and full correspondent node-targeted
IP address location privacy. The mechanism utilizes the MIPv6
bootstrapping mechanisms and does neither require any new network
entities nor changes to home agent or correspondent node
implementations.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction and Problem Definition . . . . . . . . . . . . . 5
3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8
5. Changes to Mobile Node Operation . . . . . . . . . . . . . . . 10
5.1. Route Optimization for New Sessions . . . . . . . . . . . 10
5.2. Route Optimization for Ongoing Sessions . . . . . . . . . 11
5.3. Route Optimization Mode Selection . . . . . . . . . . . . 13
5.4. Source Address Selection . . . . . . . . . . . . . . . . . 13
6. Location-dependent Home Agent Discovery . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 2]
Internet-Draft CNLocPriv November 2008
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terminology of [RFC3775] and [RFC5026] is used. Additionally,
the following terms are introduced:
IP Reachability Home Agent (IRHA): A home agent as specified in
[RFC3775] that provides IP reachability and global session
continuity for the mobile node.
Home Address for IP Reachability (HoA_IR): A home address used for
IP reachability and session continuity and that is registered at
the IRHA. This home address is independent of the location of the
mobile node and is disclosed to potential correspondent nodes
(e.g., by publishing the address in DNS).
Optimized path: A path between mobile node and correspondent node
that is shorter than the IP reachability path, but may be longer
than the optimal path. The IP Reachability path is the path
between mobile node and correspondent node if the mobile node uses
bi-directional tunneling mode with the IRHA. The optimal path is
the end-to-end path between mobile node and correspondent node,
e.g., the path in MIPv6 Route Optimization mode.
Optimized routing: Routing data packets over the optimized path
Optimized Routing Home Agent (ORHA): A home agent as specified in
[RFC3775] that is used for providing optimized routing. It must
support the bootstrapping mechanisms specified in [RFC5026] and
should be located close to the correspondent node.
Home Address for Optimized Routing (HoA_OR): A home address used for
optimized routing and session continuity and that is registered at
the ORHA. This home address is usually not public (i.e., not
published in DNS).
Eavesdropper-targeted location privacy: Hiding the mobile node's
location from nodes eavesdropping on the path between mobile node
and correspondent node (and home agent)
Correspondent node-targeted location privacy: Hiding the mobile
node's location from the correspondent node
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 3]
Internet-Draft CNLocPriv November 2008
Full IP address location privacy: Ensuring that no information about
a mobile node's current location can be derived from the mobile
node's IP address by other nodes, not even the current access
network or subnet of the mobile node.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 4]
Internet-Draft CNLocPriv November 2008
2. Introduction and Problem Definition
Location privacy is the ability to hide a user's location from other
users. This is considered to be an important feature, since
disclosure of the location can have serious impacts on the user's
life. In general, location privacy can be achieved by hiding the
relation between identity and location of a user. In Mobile IPv6
[RFC3775], the care-of address and the home address typically
represent topological location and identity of a mobile node,
respectively. Note that a dynamically assigned home address does not
represent a permanent identity itself, but a mapping to one of the
mobile node's permanent identifiers is typically published for IP
reachability reasons (e.g., in DNS), so that other nodes are able to
find out the mobile node's current home address to initiate a session
with the mobile node. Consequently, in Mobile IPv6 at least either
the care-of address or the home address must be hidden from anyone
that is not authorized to obtain the location of the mobile node.
Two rather orthogonal sub-problems of location privacy for Mobile
IPv6 can be distinguished: hiding the location from eavesdroppers on
the path and hiding the location from the correspondent node, which
we henceforth call eavesdropper-targeted and correspondent node-
targeted location privacy, respectively (see [RFC4882] for details
about the Mobile IPv6 location privacy problem). This document is
concerned with correspondent node-targeted location privacy only,
especially with the problem of providing optimized routing at the
same time. Eavesdropper-targeted location privacy is out of scope,
but can be achieved by combining the mechanisms in this document with
pseudo home address mechanisms
[I-D.irtf-mobopts-location-privacy-solutions]. Any location privacy
issues not directly related to Mobile IPv6 are out of the scope of
this document.
An example scenario illustrating the problem is the following: A
mobile node uses Mobile IPv6 with a public home address and wants to
hide its location. The home address can be a dynamically assigned
home address that is linked to a mobile node's public permanent
identifier (e.g., FQDN in DNS). The mobile node requires full
correspondent node-targeted IP address location privacy, i.e., hiding
only the mobility within an access network and revealing the access
network prefix to the correspondent node is not acceptable. An
application on the correspondent node initiates a delay-sensitive
session such as VoIP by sending packets to the mobile node's public
home address. Initiating an IP session typically requires the
correspondent node to already know the mobile node's identity and
thus the mobile node's public home address. The mobile node receives
the packets in bi-directional tunneling mode from its home agent and
may start sending packets back to the corresponding node. Let's
assume the mobile node is located in the United States and the
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 5]
Internet-Draft CNLocPriv November 2008
correspondent node is located in Canada, whereas the mobile node's
home agent is located in Europe. Since the mobile node is far away
from home, the packet delay and hence the user experience is far from
what could be achieved. One approach to reduce the end-to-end packet
delay is to use MIPv6 route optimization. However, if the mobile
node uses route optimization mode, it reveals its CoA and hence its
location to the correspondent node. Note that the correspondent node
can also be an attacker that just initiates a session to find out the
mobile node's location. Consequently, the mobile node has the
choice: it can have good user experience without location privacy or
location privacy with bad user experience. Currently, there is no
way to achieve both simultaneously with Mobile IPv6.
This document proposes a mechanism that can provide full
correspondent node-targeted IP address location privacy and optimized
routing simultaneously. Home agent and correspondent node are
unchanged and no new entities or messages are introduced. The basic
idea is that the mobile node uses a mobility service provided close
to the correspondent node's domain. More specifically, the mobile
node bootstraps with a home agent (henceforth called the ORHA), which
is located topologically close to the correspondent node (in the
above example, e.g., in Canada) and which is used for optimized
communication with this correspondent node. A location close to the
correspondent node ensures that no location information is contained
in the home address HoA_OR anchored at the ORHA while ensuring that
the route via the ORHA is shorter (or at least not significantly
longer) than the route via the IRHA in bi-directional tunneling mode.
For mobile node-initiated sessions with a particular correspondent
node, the mobile node uses the ORHA located topologically close to
the correspondent node in bi-directional tunneling mode and HoA_OR is
used as IP address for the session by higher layers. For
correspondent node-initiated sessions, the public home address HoA_IR
is used as IP address by higher layers and the mobile node registers
the HoA_OR as care-of address at the correspondent node.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 6]
Internet-Draft CNLocPriv November 2008
3. Related work
Qui et. al. [I-D.irtf-mobopts-location-privacy-solutions] propose a
solution to the correspondent node-targeted location privacy problem.
The basic idea is to hide the home address from the correspondent
node in route optimization mode by using a pseudo home address
instead of the real home address. Although the care-of address is
revealed to the correspondent node, location privacy is protected by
hiding the identity (i.e., real home address) of the mobile node from
the correspondent node. This approach has also been proposed in
[I-D.dupont-mip6-privacyext]. However, if the correspondent node
initiates the communication, location privacy is usually compromised,
since the real home address is already known by the correspondent
node. And even if the real home address can be hidden from the
correspondent node, location privacy is compromised if the
correspondent node is able to figure out the mobile node's identity
by any other means on higher layers (e.g., during the conversation).
[RFC5026] and [I-D.ietf-mip6-bootstrapping-integrated-dhc] specify
the mechanisms for Mobile IPv6 bootstrapping in the split and the
integrated scenario, respectively. They allow a mobile node to
bootstrap with any home agent, for which the necessary trust
relationships are in place. When bootstrapping with a local home
agent, optimized routing can be achieved in bi-directional tunneling
mode. However, since the home address obtained from a local home
agent belongs to the network the mobile node is currently visiting,
it contains location information. Consequently, location privacy is
compromised, if the correspondent node knows that the home agent is
local to the mobile node (see security considerations of [RFC5026]).
Although in many cases the correspondent node will not know, there
are cases where the correspondent node can find out whether the
mobile node's home agent is local or remote. For instance, a
correspondent node may know that a mobile node's home agent is local
because the mobile node's Mobility Service Provider (MSP) is known to
always assign local home agents for routing efficiency reasons.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 7]
Internet-Draft CNLocPriv November 2008
4. Applicability Statement
The mechanisms defined in this document require that the mobile node
is able to utilize a mobility service, which is offered close to the
correspondent node's domain. To allow optimized communication with
many or even any correspondent node, it is required that home agent
services are offered to the mobile node from various topological
locations. This typically requires that an MSP offers mobility
service from many different locations or that multiple MSPs have some
kind of roaming relationships with the mobile node's mobility service
authorizer (MSA), so that a group of MSPs offers mobility service
from many different locations. Such roaming relationships can be
based on an AAA infrastructure.
This assumption is not particular to this document: the MIPv6
bootstrapping solutions for the split scenario [RFC5026] and the
integrated scenario [I-D.ietf-mip6-bootstrapping-integrated-dhc] also
require that a roaming relationship between MSP and MSA exist (see
also [RFC4640]). In the integrated scenario the access service
authorizer (ASA) is also the mobility service authorizer (MSA). An
important point of the integrated scenario is that the access service
provider (ASP) that the mobile node is currently visiting is
typically also an MSP, which provides local home agent service. This
means that roaming relationships between many MSPs and the mobile
node's MSA are required and, assuming global roaming, that home agent
services must be offered to the mobile node from various topological
locations. This represents the requirements mentioned in the
beginning of this section. So the assumptions are basically not
different from the assumptions for MIPv6 bootstrapping and can be met
by re-using the home agents, roaming relationships, and the
credentials that are already deployed for MIPv6 bootstrapping.
Note that it is not required that the ORHA is located within the
correspondent node's domain. A domain nearby to the correspondent
node's domain is sufficient to achieve location privacy and improved
routing efficiency. However, if the mobile node is not able to
discover a home agent located close to the correspondent node or if
no roaming relationship to the MSP of such home agent exists,
simultaneous optimized routing and correspondent node-targeted
location privacy cannot be provided by the mechanisms defined in this
document.
It is further assumed that the mobile node is authorized by the MSA
to use ORHAs which are located close to the correspondent node and
which potentially belong to an MSP different from the MSA. Since
location privacy can be seen as a value-added service, a user may be
willing to pay for this service. This may be an incentive for an MSA
to offer this service and delegate the mobility management to an MSP
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 8]
Internet-Draft CNLocPriv November 2008
located close to the correspondent node.
Finally, this optimization requires that the mobile node is able to
handle multiple simultaneous registrations with different home agents
and multiple home addresses. Also, the MSA/MSP must support the
assignment of multiple home agents and home addresses to the same
mobile node.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 9]
Internet-Draft CNLocPriv November 2008
5. Changes to Mobile Node Operation
The mobile node operation is split in two cases: route optimization
for new sessions (i.e., communication sessions that have not yet
started) and route optimization for ongoing sessions. A session is
defined in this context by an application layer context bound to the
IP addresses of the two endpoints, with one of them being the mobile
node's home address. The first case applies, e.g., if the mobile
nodes wants to initiate a session with a correspondent node and
decides to optimized the route before sending the first data packets.
The second case applies, e.g., if the correspondent node initiates a
session with the mobile node or if the mobile node decides to
optimize the route of an ongoing session.
5.1. Route Optimization for New Sessions
The mobile node first tries to discover an ORHA (refer to Section 6
for details about the ORHA discovery). If the discovery is
successful, the mobile node bootstraps with the ORHA and uses it in
bi-directional tunneling mode for communication with the
correspondent node. Existing registrations with other home agents
are kept for communication with other correspondent nodes. The
HoA_OR is not made public, i.e., no DNS update should be triggered
for this home address. Since no correspondent node registration is
initiated, the care-of address is hidden and correspondent node-
targeted location privacy is ensured. An exemplary signaling flow is
shown in Figure 1.
+--+ +-------+ +--+
|MN| | ORHA | |CN|
+--+ +-------+ +--+
[ORHA discovery] | |
| | |
| MIPv6 bootstrapping | |
|<----------------------------------------->| |
| BU/BA (HoA_OR,CoA) | |
|<----------------------------------------->| |
| MIPv6 tunnel (ORHA) | data packets |
|===========================================|<------------------->|
Figure 1: Signaling flow for optimization of the route for a session
that has not yet started
Location privacy is provided, since the correspondent node only
learns the HoA_OR, which contains no information about the mobile
node's location.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 10]
Internet-Draft CNLocPriv November 2008
5.2. Route Optimization for Ongoing Sessions
After the mobile node has decided to optimize the route of a session
(e.g., after receiving the first data packets tunneled by the IRHA
and originated from the correspondent node), it discovers an ORHA and
bootstraps with this ORHA. Since the communication session is based
on HoA_IR, packets are routed through the IRHA. To achieve optimized
routing, the mobile node uses route optimization mode over the
reverse tunnel to the ORHA, i.e., care-of test messages, binding
update messages, and later data packets destined for the
correspondent node are sent over the reverse tunnel to the ORHA.
While establishing the optimized path over the ORHA, the mobile node
can send and receive data packets over the IRHA.
To achieve location privacy, the mobile node uses HoA_IR as home
address and HoA_OR as care-of address in the context of the route
optimization mode. This results in the following headers for packets
sent by the mobile node for the session with the correspondent node
(IPsec for signaling protection to ORHA assumed):
Data packets and binding updates:
IPv6 header (source = care-of address,
destination = ORHA)
ESP header in tunnel mode
IPv6 header (source = HoA_OR,
destination = correspondent node)
Destination Options header
Home Address option (HoA_IR)
Any protocol
Care-of Test Init:
IPv6 header (source = care-of address,
destination = ORHA)
ESP header in tunnel mode
IPv6 header (source = HoA_OR,
destination = correspondent node)
Any protocol
Since from the correspondent node's point of view, HoA_OR is the
care-of address and the HoA_IR is the home address of the mobile
node, data packets sent by the correspondent node to the mobile node
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 11]
Internet-Draft CNLocPriv November 2008
contain the HoA_IR in the type 2 routing header and the HoA_OR in the
destination address field of the IP header. Consequently, the data
packets are intercepted by the ORHA and tunneled to the mobile node.
An exemplary signaling flow is shown in Figure 2.
+--+ +-------+ +-------+ +--+
|MN| | IRHA | | ORHA | |CN|
+--+ +-------+ +-------+ +--+
| BU/BA (HoA_IR,CoA) | | |
|<------------------->| | |
~ ~ ~ ~
| MIPv6 tunnel (IRHA) | data packets |
|=====================|<----------------------------------------->|
| | | |
[ORHA discovery] | | |
| | | |
| MIPv6 bootstrapping | |
|<----------------------------------------->| |
| BU/BA (HoA_OR,CoA) | |
|<----------------------------------------->| |
| MIPv6 tunnel (IRHA) | HoTi |
|=====================|------------------------------------------>|
| MIPv6 tunnel (ORHA) | CoTi |
|===========================================|-------------------->|
| MIPv6 tunnel (IRHA) | HoT |
|=====================|<------------------------------------------|
| MIPv6 tunnel (ORHA) | CoT |
|===========================================|<--------------------|
| MIPv6 tunnel (ORHA) |BU/BA (HoA_IR,HoA_OR)|
|===========================================|<------------------->|
| MIPv6 tunnel (ORHA) | data packets |
|===========================================|<------------------->|
Figure 2: Signaling flow for optimization of the route for an ongoing
session
Location privacy is provided, since the correspondent node only
learns HoA_OR and HoA_IR, which both do not contain any information
about the mobile node's current location.
Note that upon changing the care-of address, the mobile node does not
send binding updates to the correspondent node over the reverse
tunnel to the ORHA, because the care-of address in this context is
the HoA_OR.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 12]
Internet-Draft CNLocPriv November 2008
5.3. Route Optimization Mode Selection
The mobile node has to decide for every correspondent node, whether
it wants to use bi-directional tunneling mode, route optimization
mode or the mechanisms described in this document. How this decision
is made and when the route optimization is triggered is
implementation specific. Generally, for non-delay-sensitive services
such as simple web browsing, bi-directional tunneling to the home
agent is sufficient and achieves full correspondent node-targeted IP
address location privacy. If no location privacy is required, Mobile
IPv6 route optimization mode can be used.
Since the number of simultaneously used home agents have impacts on
the overall signaling overhead and resource consumption on the mobile
node, the mobile node should try to minimize the number of
simultaneously used ORHAs and only use the mechanisms specified in
this document for sessions that require simultaneous optimized
routing and correspondent node-targeted location privacy. Note
however that we are currently not aware of any realistic scenario
where a mobile node would have active sessions with a large amount of
different correspondent nodes simultaneously and all those sessions
require simultaneous optimized routing and correspondent node-
targeted location privacy. Optimizations to improve scalability in
such extreme scenarios may be developed later.
5.4. Source Address Selection
Since the mobile node will typically use different home addresses for
communication with different correspondent nodes when using the route
optimization mechanisms defined in this document, the mobile node
must be able to select the right home address as source address for
packets to be sent to a specific destination address. This can be
achieved with the source address selection mechanisms defined in
[RFC3484]. If the ORHA is located in the correspondent node's
domain, the prefix of the home address anchored at the ORHA is
similar to the prefix of the correspondent node and rule 8 of the
default source address selection [RFC3484] applies. For other cases,
dynamically adding entries for HoA_OR and correspondent node address
with matching labels in the policy table [RFC3484] when route
optimization according to this document is triggered would prefer a
home address as source address for communication with a specific
correspondent node. However, since this is implementation specific,
the details of the source address selection are out of the scope of
this document.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 13]
Internet-Draft CNLocPriv November 2008
6. Location-dependent Home Agent Discovery
The mechanisms defined in this document require the discovery or
assignment of an ORHA, i.e., of a home agent located close to the
correspondent node. One options is to pre-configure the necessary
information on the mobile node, e.g., a list containing home agent
addresses and distances to various prefixes. Two options for dynamic
discovery are proposed in the following.
The first option is to re-use the DNS-based home agent discovery
specified in [RFC5026]. The mobile node would construct the FQDN,
e.g., based on the correspondent node's address, prefix or host name.
The DNS entry can be maintained by the MSP of the ORHA (e.g.,
"ORHA.CNdomain.com") or by the MN's MSA (e.g.,
"CNdomain.ORHA.MSAdomain.com"). Anycast-based home agent discovery
using IKEv2 extensions [I-D.dupont-ikev2-haassign] or DHAAD [RFC3775]
is also possible. The mobile node would, e.g., construct the anycast
destination address based on the correspondent node's prefix.
A second option is to query a dedicated server that is able to map an
FQDN, prefix or address of a correspondent node to an FQDN or address
of a home agent that is located in or topologically close to the
correspondent node's domain. This server can, e.g., be provided by a
third party in the public Internet or by the mobile node's Mobility
Service Authorizer (MSA). The mobile node would query this server to
discover the ORHA address.
This option can, e.g., be realized by re-using DHCP-based HA
assignment with the options and mechanisms defined in
[I-D.ietf-mip6-bootstrapping-integrated-dhc] and
[I-D.ietf-mip6-hiopt]. During network authentication, the MSA would
send to the Network Access Server (NAS) the home agent information
for all the MSPs, which the mobile node is authorized to use. Once
the mobile node wants to request a home agent close to the
correspondent node, it sends a DHCP Information Request message and
appends a Home Network Information Option [I-D.ietf-mip6-hiopt] with
a home network parameter suboption containing the correspondent
node's domain as target domain. The id-type can be set to 1 (target
MSP) or to a newly defined value for this purpose. The NAS would
then select a home agent from the set of authorized home agents that
is in (id-type 1) or close (new id-type) to the target domain
specified in the Home Network Information Option. How this selection
is done may be done in an implementation and operator specific way.
A simple selection algorithm would be to return a home agent with the
domain name equal to the target domain, if such home agent is part of
the list of authorized home agents, and otherwise return an home
agent from the home MSP or an empty Home Network Information option.
Finally, the NAS would assign the selected home agent to the mobile
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 14]
Internet-Draft CNLocPriv November 2008
node by putting the corresponding information in the Home Network
Information Option of the DHCP reply message.
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 not authorized to get this information, i.e., the
ORHA must be trusted by the mobile node. How the trust verification
is done depends on the ORHA discovery mechanism in use. One option
is that the MSA knows which home agents are trusted with respect to
location privacy and only assigns such home agents to the mobile node
(i.e., only sends addresses of trusted home agents to the NAS or only
maintains DNS entries for trusted home agents). The MSA could also
deny the authorization request if the MN tries to bootstrap with an
untrusted home agent. Another option is that the mobile node
verifies the trust by itself, e.g., by pre-configuring a list of
trusted home agent addresses on the mobile node or by using
certificates.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 15]
Internet-Draft CNLocPriv November 2008
7. Security Considerations
With the solution described in this document, a correspondent node
may learn at most the mobile node's addresses HoA_OR and HoA_IR.
HoA_IR is a permanent address used for IP reachability and hence
doesn't contain any information about the mobile node's current
location. Since HoA_OR is anchored close to the correspondent node,
there is no relation between HoA_OR and the mobile node's current
location as well and the correspondent node cannot infer mobile
node's real location from HoA_OR. The correspondent node may wrongly
believe that mobile node is close to himself, though. If the
correspondent node knows both HoA_OR and HoA_IR (the latter e.g.,
from DNS or during the return routability procedure), it may wrongly
think that the mobile node has roamed from HoA_IR to HoA_OR.
However, since the mobile node can bootstrap with a new ORHA and use
a new HoA_OR without moving and since the mobile node does not change
HoA_OR cased on movements, the correspondent node cannot infer the
mobile node's real movement patterns just from HoA_OR and HoA_IR.
An attacker could initiate many faked communication sessions by
spoofing the source address in order to trigger the mobile node to
discover and bootstrap with many home agents. This could consume
significant resources on the mobile node and in the network and may
cause a DoS. As a countermeasure, the mobile node should not start
bootstrapping automatically without further checks when the
correspondent node initiates a session (especially if active ORHA
sessions already exist) or it should limit the number of ORHAs it may
be registered with simultaneously. Faked sessions should be
identified as such as quickly as possible and the mobile node should
de-register immediately from ORHAs that only served faked sessions.
The ORHA knows the location of the mobile node and could distribute
it to third parties without authorization from the mobile node.
Hence, the mobile node must be sure that the ORHA is trusted before
the mobile node reveals its location to the ORHA. How this can be
done is detailed in Section 6. Note that the fact that the ORHA and
the correspondent node may be in the same administrative domain
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
mobile operator don't know the location of other users using a
service provided by the same operator.
The return routability procedure over the reverse tunnel to the ORHA
is not considered less secure than the standard return routability
procedure as long as the ORHA is trusted and the ORHA link is not
vulnerable to eavesdropping.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 16]
Internet-Draft CNLocPriv November 2008
This document is concerned with correspondent node-targeted location
privacy only. Eavesdropper-targeted location privacy and any
location privacy issue not directly related to Mobile IPv6 are out of
the scope of this document.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 17]
Internet-Draft CNLocPriv November 2008
8. Acknowledgements
Thanks to Kuntal Chowdhury, Vijay Devarapalli, Rajeev Koodli, and
Ahmad Muhanna for their valuable comments and suggestions to improve
this document.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 18]
Internet-Draft CNLocPriv November 2008
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4882] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
Problem Statement", RFC 4882, May 2007.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007.
9.2. Informative References
[I-D.dupont-ikev2-haassign]
Weniger, K. and F. Dupont, "IKEv2-based Home Agent
Assignment in Mobile IPv6/NEMO Bootstrapping",
draft-dupont-ikev2-haassign-02 (work in progress),
January 2007.
[I-D.dupont-mip6-privacyext]
Dupont, F., "A Simple Privacy Extension for Mobile IPv6",
draft-dupont-mip6-privacyext-04 (work in progress),
July 2006.
[I-D.ietf-mip6-bootstrapping-integrated-dhc]
Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008.
[I-D.ietf-mip6-hiopt]
Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP
Options for Home Information Discovery in MIPv6",
draft-ietf-mip6-hiopt-17 (work in progress), May 2008.
[I-D.irtf-mobopts-location-privacy-solutions]
Ying, Q., Zhao, F., and R. Koodli, "Mobile IPv6 Location
Privacy Solutions",
draft-irtf-mobopts-location-privacy-solutions-10 (work in
progress), November 2008.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 19]
Internet-Draft CNLocPriv November 2008
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for
bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,
September 2006.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 20]
Internet-Draft CNLocPriv November 2008
Authors' Addresses
Kilian A. Weniger
Email: kilian.weniger@googlemail.com
Genadi Velev
Panasonic R&D Center Germany
Monzastr. 4c
Langen 63225
Germany
Email: genadi.velev@eu.panasonic.com
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 21]
Internet-Draft CNLocPriv November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Weniger & Velev (Ed.) Expires June 1, 2009 [Page 22]