Internet DRAFT - draft-castelluccia-mobileip-privacy
draft-castelluccia-mobileip-privacy
Internet Engineering Task Force Claude Castelluccia
INTERNET-DRAFT INRIA, France
Francis Dupont
ENST Bretagne, France
Expires in August 2001 February, 2001
A Simple Privacy Extension for Mobile IPv6
<draft-castelluccia-mobileip-privacy-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC3036. 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.
Abstract
This draft presents a simple privacy extensions for Mobile IPv6 [4]
that prevents eavesdroppers from identifying the packets sent or
received from a particular mobile node. This extension also allows
a mobile node to hide its identity from correspondent nodes when
the mobile node initiates the communication.
1. Introduction
In Mobile IPv6 [4], the home address of a mobile node is included in
the packets that it sends and receives.
C. Castelluccia [Page 1]
Internet Draft Privacy Extension for MIPv6 February, 2001
As a result any node in the network can identify packets that
belong to a particular mobile node (and use them to perform some
kind of traffic analysis) and track its movements (i.e. its care-of
address) and usage. We propose a solution to prevent such tracking
while still using route optimisation.
In particular our proposal solves the two following problems:
- Privacy of mobile client from its correspondent node and from any
eavesdroppers in the network: the mobile node connects to a remote
node (a server for example) and wants to hide it identity, i.e.
its home address, from this node and from any eavesdropper in the
network while still being able to move.
- Privacy of mobile server from eavesdroppers: The remote node
initiates the communication and the mobile node is able to hide
its identity (and therefore its locations) from any eavesdropper
in the network (but not from the remote node).
We do not solve the problem of privacy of a mobile server from
its correspondent nodes. In this case a mobile node still needs
to reveal its care-of address to its correspondent nodes to ensure
optimal routing. If this level of privacy is desired, one possible
solution is bi-directional tunneling via the home agent.
Full privacy is then provided at the cost of routing
performance. It should be noted that HMIPv6 [5] in revealing the
Regional care-of address (RCoA) instead of the care-of address
might be an other alternative.
In this draft we only look at privacy issues in Mobile IPv6 and
assume that a mobile node's identity is not revealed by other
protocols such as AAA, IKE,...and by the applications (i.e.
applications must not use any IP address in their payloads.)
2. Mobile IPv6 Review
In Mobile IPv6, the home address of a mobile node is included in
cleartext in the packets it sends and receives. In fact, packets
sent by a mobile node includes a home address option that contains
its home address. Packets sent by a correspondent node to a given
mobile node contains a routing header that includes the mobile
home address. As a result, any eavesdropper within the network can
easily identify packets that belong to a particular mobile node
(and use them to perform some kind of traffic analysis) and track
mobile movements and usage.
C. Castelluccia [Page 2]
Internet Draft Privacy Extension for MIPv6 February, 2001
Home Address Option
The home address destination option is used in a packet sent by a
mobile node while away from home, to inform the recipient of that
packet of the mobile node's home address. For packets sent by a
mobile node while away from home, the mobile node generally uses
one of its care-of addresses as the source address in the packet's
IPv6 header. By including a home address option in the packet, the
correspondent node receiving the packet is able to substitute the
mobile node's home address for this care-of address when processing
the packet, thus making the use of the care-of address transparent
to the correspondent node.
The home address option MUST be placed as follows:
- After the routing header, if that header is present
- Before the fragment header, if that header is present
- Before the AH Header or ESP Header, if either one of those
headers is present
Routing header
Before sending any packet, the sending node should examine its
binding cache for an entry for the destination address to which
the packet is being sent. If the sending node has a binding cache
entry for this address, the sending node should use a routing header
to route the packet to this mobile node (the destination node) by
way of the care-of address in the binding recorded in that binding
cache entry. The destination address in the packet's IPv6 header
is set to the mobile node's care-of address copied from the binding
cache entry.
3. Possible solutions
Several solutions are possible, all with their limitations:
- IPv6 Privacy Extension: A solution could be to used the privacy
extension described in [1] to configure the home address and
the care-of addresses. While this solution represents a marked
improvement over the standard address configuration methods [2],
and should be used for the home and care-of addresses, we contend
that this is not sufficient. [1] causes nodes to generate
global-scope addresses from interface identifiers that change over
time, even in cases where the interface contains an embedded IEEE
identifier. As a result if [1] is used to generate the home address,
this address will change periodically but the network prefix (64
highest bits) will remain unchanged. This network perfix can still
reveal much information about the mobile node's identity to an
eavesdropper. This mechanism described in [1] must be used for the
home address and care-of address in Mobile IPv6 but one should not
rely on it to get full privacy protection.
C. Castelluccia [Page 3]
Internet Draft Privacy Extension for MIPv6 February, 2001
- HA option encryption: An other solution could be to encrypt the
home address option. This solution is not satisfactory because
(1) it would require to modify IPsec implementation (SA should then
be indexed with the care-of address and therefore would need to be
updated at each movement of the mobile node) and (2) it would make
the usage of firewalls difficult (currently firewalls look at the
home address option to perform some filtering). Futhermore this
solution does not solve the problem of incoming packets that
contain a routing header which reveals the home address.
- IPsec bi-directional Tunnel (mobile VPN): A solution could be to
open a bi-directional IPsec tunnel between the mobile node and its
home agent [3]. This solution has the following disadvantages: (1)
addition of extra bandwidth (packets need to be encapsulated) and
processing overhead, (2) the routing is suboptimal.
4. Our Proposal
In our scheme a mobile node uses the privacy extension described in
[1] to configure its home address and care-of addresses. A mobile
node must use an interface identifier for its home address that is
different from the one used for its care-of addresses. It should
also use a new interface identifier when configuring a new care-of
address. As a result, it would be more difficult for an eaversdropper
to identify a mobile node's identity and track its movement.
We also propose to assign to each mobile node a TMI (Temporary
Mobile Identifier) that is a 128-bit long random number. This TMI
is used by the mobile node's home agent and correspondent nodes to
identify the mobile node. This TMI might be used by the correspondent
node to index the IPsec SA correspondent to the mobile and might be
used by firewalls to do filtering.
4.1 Protocol description
Two cases must be considered:
- Mobile Client (The mobile node initiates the communication):
The mobile then uses standard Mobile IPv6 with the TMI as its Home
address. Packets sent and received by a mobile node will contain
its TMI instead of its home agent. As a result, the mobile identity
is hidden from the correspondent node and from potential
eavesdroppers in the network.
Note that in this case the correspondent node must never use the
home address, i.e. the TMI that is not routable, but must use the
C. Castelluccia [Page 4]
Internet Draft Privacy Extension for MIPv6 February, 2001
care-of address. Mobile IPv6 need to be modified to provide such
functionality.
- Mobile Server (the corrresponding node initiates the communication):
In this case, the correspondent node knows the mobile identity by
definition. If a mobile node wants to hide its mobility, i.e. its
care-of address, to a particular correspondent node, it must not
send any binding update to this correspondent node and use
bi-directional tunneling. As a result the packets that are sent to
the mobile node are addressed to its home address and encapsulated
by the home agent to its current care-of address. The decision to
send or not to send a binding update to a correspondent node is
a policy issue that is out of the scope of this draft. Any eaves-
droppers between the home agent and the mobile node is able to
identify and track the mobile movement by looking at the inner
packet. Therefore we suggest to encrypt the packets that are sent
between the mobile node and its home agent.
If the mobile node decides to use route optimization, it then
sends a binding update to its correspondent node. This binding
update contains the TMI in the home address option and the actual
home address is encoded in a newly defined binding update
sub-option. Of course to preserve privacy the binding update must
be encrypted (the SA should be indexed with the TMI and not the
home address). The correspondent node uses the binding update to
bind the TMI with the Home Address and the care-of address.
Subsequent packets between the mobile node and the correspondent
node will contain the TMI in the home address option and in the
routing header extension instead of the actual home address.
As a result an eavesdropper won't be able to identify the packets
belonging to a particular node.
4.2 Temporary Mobile Identifier (TMI)
4.2.1 TMI generation
The TMI of a mobile node should be globally unique and must be
locally unique. By locally unique we mean that two mobile nodes
communicating with the same correspondent node/or home agent must
use different TMI but two mobile nodes communicating with different
correspondent nodes can use the same TMI. The consequences of two
mobile nodes using the same TMI with the same correspondent node
is similar than the consequences of two mobile nodes using the same
home address with standard mobile IPv6. The correspondent node
might get confused...
C. Castelluccia [Page 5]
Internet Draft Privacy Extension for MIPv6 February, 2001
We propose to use the MD5 message digest of the mobile node's home
address as its TMI. The mobile node being globally unique, the TMI
collision probability is therefore very small. Furthermore the
probably of two mobile nodes generating the same TMI and
communicating with the same correspondent node is even smaller
and negligible.
MD5 was chosen because its particular properties were adequate to
produce the desired level of randomness and uniqueness. IPv6 nodes
are already required to implement MD5 as part of IPsec [6].
4.2.2 TMI management
The TMI of a mobile user must be changed periodically (every
few minutes, hours or days) in order to avoid TMI leakage as
explained in [1]...
For example, the digest for the new TMI can be generated as follows:
new digest = MD5 ( Home address | old digest), where "|" stands
for concatenation.
A dedicated Top-Level Aggregation identifier [7] should used and
TMI allocated into this TLA (ie. an address in this TLA is known
to be a TMI). This has some drawbacks and many advantages:
- the first 16 bits are fixed (but 112 bits should be enough
to keep the collision probability very close to zero).
- a TMI is very easy to recognize by bad guys.
+ any mobile node can be automatically authorized to use
any address in this TLA.
+ this TLA can be marked as unroutable, ie. a wrong packet to
a TMI destination will be dropped by the first router, not
the first default free router. In general misuses of TMI
become very easy to detect.
5. Privacy with HMIPv6 (basic mode)
With HMIPv6 basic mode [5], a mobile node may choose to hide its
care-of address from its correspondent nodes and its home agent
by using its Regional care-of address (RCoA) in the source field
of the packets that it sends. The location tracking of a mobile
node by its correspondent nodes or its home agent is therefore
difficult.
C. Castelluccia [Page 6]
Internet Draft Privacy Extension for MIPv6 February, 2001
Note that in HMIPv6 basic mode, the Mobile Anchor Point (MAP)
does not know the home address (i.e. the identity) of the mobile
node. The MAP only knows the binding between the mobile's node
regional care-of address and care-of address. One may argue that
a MAP could snoop the mobile host's packets to discover its home
address. This is true but however this is still an improvement
over Mobile IPv6.
When combining the privacy extension presented in this draft
with HMIPv6 basic mode, a mobile node uses the privacy extension
to register with its home agent, its correspondent nodes and the
local MAP. We can achieve full privacy protection because the
mobile node's identity is hidden from its correspondent nodes and
the local MAP. Its care-of address is hidden from its home agent
and correspondent nodes. No node knows the mobile node's identity
(home address) and its care- of address together. Furthermore the
MAP can not find out the mobile node identity by snooping its
packets (because the home address is not included in the packets
anymore). We argue that the combinaison of HMIPv6 with the privacy
extension of this draft provides a level of privacy to a mobile
node that is superior to that which a VPN provides (bi-directional
tunnel between the mobile node and its home agent) but without
the cost of aVPN.
Indeed when using HMIPv6 with the proposed privacy extension, we can:
- hide the location (care-of address) of a mobile node from its
Home Agent (this is not provided by a VPN),
- hide the location (care-of address) of a mobile node from its
correspondent nodes (provided by a VPN),
- hide the identity of a mobile node from its Correspondent nodes
when the mobile is the client (not provided by a VPN),
- prevent any eavesdropper in the network from identifying the
packets that belong to a particular mobile and to track its location.
6. Security Considerations
This document address some privacy issues in the mobile IPv6
protocols. Even if privacy does not provide real security (ie.
security through obscurity is poor security) then it makes the job
of bad guys (eavesdroppers, rogue correspondents, ...) harder so
should improve the overall security.
7. Acknowledgments
John Wells (INRIA), Karim El-Malki (Ericsson), Hesham Soliman
(Ericsson), Jean-Michel Combes (France Telecom R&D), Gabriel
Montenegro (SunLabs Europe), Imad Add (INRIA), Pars Mutaf (INRIA)...
C. Castelluccia [Page 7]
Internet Draft Privacy Extension for MIPv6 February, 2001
8. References
[1] T.Narten and R. Draves. "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6". RFC3041, January 2001.
[2] S. Thomson and T. Narten, "IPv6 Address Autoconfiguration",
RFC 2462, December 1998.
[3] G. Montenegro, "Reverse Tunneling for Mobile IP, revised",
RFC 3024, January 2001.
[4] D. Johnson and C.Perkins, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-13.txt, November 2000.
[5] H. Soliman, C. Castelluccia, K. El-Malki and L. Bellier,
"Hierarchical MIPv6 mobility management",
draft-ietf-mobileip-hmipv6-01.txt, September 2000.
[6] Kent, S., Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[7] Hinden R., O'Dell M., Deering S., "An IPv6 Aggregatable
Global Unicast Address Format", RFC 2374, July 1998..
Authors' Addresses
Claude Castelluccia
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
FRANCE
email: claude.castelluccia@inria.fr
phone: +33 4 76 61 52 15
fax: +33 4 76 61 52 52
Francis Dupont
ENST Bretagne
Campus de Rennes
2, rue de la Chataigneraie
BP 78
35512 Cesson-Sevigne Cedex
FRANCE
Fax: +33 2 99 12 70 30
EMail: Francis.Dupont@enst-bretagne.fr
C. Castelluccia [Page 8]
