Network Working Group C. Castelluccia
Internet-Draft INRIA
Expires: August 15, 2005 F. Dupont
Point6
G. Montenegro
Sun Labs
February 14, 2005
A Simple Privacy Extension for Mobile IPv6
draft-dupont-mip6-privacyext-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This draft presents a simple privacy extension for Mobile IPv6 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
Castelluccia, et al. Expires August 15, 2005 [Page 1]
Internet-Draft MIPv6 Privacy Ext February 2005
node initiates the communication.
1. Introduction
In Mobile IPv6 [RFC3775], the home address of a mobile node is
included in the packets that it sends and receives.
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 encrypted tunneling via the home agent.
Full privacy is then provided at the cost of routing performance. It
should be noted that [HMIPv6] 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 include any IP address in their payloads.)
2. Problem statement
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
Castelluccia, et al. Expires August 15, 2005 [Page 2]
Internet-Draft MIPv6 Privacy Ext February 2005
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.
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 [RFC3041] to configure the home address and
the care-of addresses. While this solution represents a marked
improvement over the default address configuration methods
[RFC2462], and should be used for the home and care-of addresses,
we contend that this is not sufficient. [RFC3041] 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 [RFC3041] is used to
generate the home address, this address will change periodically
but the network prefix (64 highest bits) will remain unchanged.
This network prefix can still reveal much information about the
mobile node's identity to an eavesdropper. This mechanism
described in [RFC3041] must be used for the home address and
care-of addresses in Mobile IPv6 but one should not rely on it to
get full privacy protection.
- Home address 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 (security
associations 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 [RFC3024]. This solution has the following
disadvantages:
(1) addition of extra bandwidth (packets need to be
encapsulated) and processing overhead,
(2) the routing is suboptimal.
Castelluccia, et al. Expires August 15, 2005 [Page 3]
Internet-Draft MIPv6 Privacy Ext February 2005
4. Our Proposal
In our scheme a mobile node uses the privacy extension described in
[RFC3041] 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 correspondent IPsec security association 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).
- Mobile Server (the correspondent node initiates the
communication).
4.1.1 Mobile client
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 address. 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 care-of
address (Mobile IPv6 should be modified to provide such
functionality.)
4.1.2 Mobile Server
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
Castelluccia, et al. Expires August 15, 2005 [Page 4]
Internet-Draft MIPv6 Privacy Ext February 2005
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 eavesdroppers 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
security association 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 TMIs 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...
We propose derive the TMI from the SHA-1 message digest of the mobile
node's home address. The mobile node's home address 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.
SHA-1 was chosen because its particular properties were adequate to
produce the desired level of randomness and uniqueness. IPv6 nodes
are already required to implement SHA-1 as part of IPsec [RFC2401].
Castelluccia, et al. Expires August 15, 2005 [Page 5]
Internet-Draft MIPv6 Privacy Ext February 2005
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
[RFC3041]...
For example, the digest for the new TMI can be generated as follows:
new digest = SHA-1 (home address | old digest), where "|" stands for
concatenation.
A dedicated prefix of 16 bits should used and TMI allocated into this
prefix (i.e., an address in this prefix 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 prefix.
+ this prefix can be marked as unroutable, i.e., 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. Security Considerations
This document address some privacy issues in the mobile IPv6
protocols. Even if privacy does not provide real security (i.e.,
security through obscurity is poor security) then it makes the job of
bad guys (eavesdroppers, rogue correspondents, ...) harder so should
improve the overall security.
6. Acknowledgments
John Wells (INRIA), Karim El-Malki (Ericsson), Hesham Soliman
(Ericsson), Jean-Michel Combes (France Telecom DR&D), Imad Add
(INRIA), Pars Mutaf (INRIA)...
7. History
This document was directly extracted from an old proposition by the
first two authors. CBID (Crypto-Based IDentifier) and HMIPv6
extensions / improvements were removed to keep the first version of
this draft very small.
Castelluccia, et al. Expires August 15, 2005 [Page 6]
Internet-Draft MIPv6 Privacy Ext February 2005
8. IANA Considerations
Allocation of the needed prefix is the subject of [ID.cgpref].
9. References
9.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
9.2 Informative References
[HMIPv6] Soliman, H., Castelluccia, C., El Malki, K. and L.
Bellier, "Hierarchical Mobile IPv6 mobility management
(HMIPv6)", draft-ietf-mipshop-hmipv6-04.txt (work in
progress), December 2005.
[ID.cgpref]
Dupont, F., Ed., "An IPv6 Prefix for Cryptographically
Generated IDs", draft-dupont-ipv6-cgpref-00.txt (work in
progress), January 2005.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, December 2001.
Authors' Addresses
Claude Castelluccia
INRIA
EMail: Claude.Castelluccia@inria.fr
Castelluccia, et al. Expires August 15, 2005 [Page 7]
Internet-Draft MIPv6 Privacy Ext February 2005
Francis Dupont
Point6
c/o GET/ENST Bretagne
EMail: Francis.Dupont@enst-bretagne.fr
Gabriel Montenegro
Sun Labs
EMail: gab@sun.com
Castelluccia, et al. Expires August 15, 2005 [Page 8]
Internet-Draft MIPv6 Privacy Ext February 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Castelluccia, et al. Expires August 15, 2005 [Page 9]