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 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]