MIP6 Working Group Greg Daley INTERNET-DRAFT Monash University CTIE Expires: July 2004 January 2004 Location Privacy and Mobile IPv6 draft-daley-mip6-locpriv-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Definitions of requirements keywords are in accordance with the IETF Best Current Practice - RFC2119 [KEYW-RFC] Abstract Mobile IPv6 aims at providing location independent communications with peers on the Internet. In order to support low-latency communications between peers on the Internet, Mobile IPv6 supports Route Optimization. Route Optimization exposes the Mobile Node's current subnet location to its Internet peers, in order that packet flows may traverse the shortest network path between the devices. Since location information can be discerned from IP prefix information, divulging an on-link Care-of-Address through route optimization effectively defeats location privacy. This document describes some issues related to location privacy which arise when Daley draft-daley-mip6-locpriv-00.txt [Page 1] INTERNET-DRAFT Location Privacy and Mobile IPv6 January 2004 communicating with Mobile IPv6. 1.0 Introduction Location information may be sensitive for some devices which use IP Mobility signaling. Global IPv6 addressing currently ties the concept of locator (in the form of an IP subnet, which has only one nominal location) and the identifier (an address within the subnet which uniquely identifies a node). While a device moves within the Internet it may wish to maintain connectivity to a globally reachable identity, while keeping its current location private. 1.1 Mobile IPv6 and Location Privacy Mobile IPv6 hides location changes from upper layer protocols by providing a location independent communications service, through a Home Agent(HA) [MIPv6]. As the Mobile Node's (MN's) location changes, updates are made to the HA, and packets are automatically forwarded on to the MN's new location through a tunnel. The location of the MN (as the Care-of-Address) and its identity, (the Home Address) are visible in binding signaling exchanges between the MN and its HA. This means that devices on the direct path between the MN and its home agent are able to defeat location privacy for the MN. This is an inherent weakness in providing location privacy of Mobile IPv6, which prevents location privacy when the host is on the same link or path as an eavesdropper. Section 2.3 explains one mechanism to work around this limitation. For communication with other nodes, Mobile IPv6 allows the MN to establish a tunnel such that all packets destined to the Correspondent Node (CN) issue from the home network. By this 'reverse tunneling' all packets appear as if they came from the home while avoiding ingress filters on access routers within the access networks. Because of the indirection through the Home Agent, the latency for packet transfer between the MN and CN may be increased. In the case that the latency is considered acceptable, a system which always transfers data over a home tunnel may achieve acceptable location privacy. This mechanism has to be matched with augmented rules for source address selection (Sec 3.4) and may make use of RTT modification techniques to prevent more accurate location estimation (Appendix). Daley draft-daley-mip6-locpriv-00.txt [Page 2] INTERNET-DRAFT Location Privacy and Mobile IPv6 January 2004 1.2 Mobile IPv6 and Route Optimization Mobile IPv6 allows a mobile node to perform Route Optimization, which directs a device to communicate directly with the MN's current location. This direction requires explicit signaling on behalf of the MN to prove its location, in the form of an on-link Care-of- Address(CoA), to the CN. In this case, the MN<->CN communications may achieve significant reductions in latency, which may have an effect on application performance (for example with TCP or Voice over IP). In addition to higher signaling overhead and potentially higher packet loss on handover, the CoA provided in Route Optimization signaling can provide accurate location information to CN's, and defeat location privacy. It is worth mentioning that the set of devices with which an MN's location information is shared may potentially grow. For example, if one of the HAs or CNs to which the MN has provided one of the set of read-only SNMP access to this information may be readable on a Home Agent or Correspondent Node, to whom the MN has to provide this information through binding signaling[MIP6MIB]. Systems which allow read access to these MIPv6 Binding Cache MIBs may inadvertently divulge the location of client MNs to interested third parties. Therefore, it is important to limit the number of devices to which location information is distributed through route optimization, in order to reduce the risk of information leakage. 1.3 Home Agents Mobile IPv6 Home Agents are devices which are tasked with maintaining an association between the host's location and its identity. Since it is always required that a host updates its Home Agent when its Care-of-Address changes, the Home Agent will have an up-to-date indication of the host's visited network. By being able to request this information from a HA, an MN's movement may be tracked. While Section 2.3 and the Appendix deal with ways to reduce this reliance, the ability to inspect a HA's Binding Cache will almost always reveal a mobile host's location (with varying accuracy, depending on the visited subnet's coverage, and the countermeasures taken). Daley draft-daley-mip6-locpriv-00.txt [Page 3] INTERNET-DRAFT Location Privacy and Mobile IPv6 January 2004 2.0 Mobile IPv6 and other privacy services Mobile IPv6 communications may be used with other mechanisms to achieve better privacy. The following sections outline potential approaches to reduce the amount of divulged information, and potentially protect a host's location and identity from being associated. 2.1 Privacy Addresses [PRIV_ADDR] Defines a set of randomly generated addresses which may be used to prevent divulging a host's identity during communications. When privacy addresses are used as Mobile IPv6 home addresses, this same effect may be achieved. When trying to protect the location of a device, privacy addresses provide limited benefit when used in conjunction with Mobile IPv6. As mentioned in section 1.1, Mobile IPv6 provides a mapping between location and identity in the form of the binding of CoA and Home Address. If privacy addresses are used as care-of-addresses, their identity hiding value is lost if Route Optimization is used. When Home Tunneling is in use, all packets are tunneled between the HA and the privacy CoA. this does not prevent a device on the path between the MN and the HA from determining the identity and location of the MN. As described in [MIPv6], a host can use a CoA as a source address, for short transactions (such as DNS, or HTTP). This avoids the signaling and tunneling requirements of Mobile IPv6. If the identifier used to generate the CoA is the same as that used to create the home address used in Mobile IPv6, this provides the host's location information to the server. Use of a privacy address or another non Mobile IPv6 related identifier is recommended in this case. 2.2 Anonymous CGA addresses As defined in the Securing Neighbor Discovery (SEND) protocol [SEND], cryptographically generated addresses (CGAs) may be used instead of interface identifiers developed from hardware addresses [CGA]. These addresses are generated from an the network prefix, from one of the node's private/public key pairs, and from a generated modifier value, whose initial value is pseudo-randomly selected. As network prefixes change, a CGA device is required to generate a new address for each visited prefix. In terms of privacy, a device which moves IP addresses may be tracked by a device which has Daley draft-daley-mip6-locpriv-00.txt [Page 4] INTERNET-DRAFT Location Privacy and Mobile IPv6 January 2004 knowledge of the public key and modifier used in creating the CGA address[CGA]. This means that both the public key and modifier should be divulged to as few devices as possible. Particularly, use of CGA to verify identity to off-link devices is not compatible with location privacy, since it requires divulging the public key to arbitrary third parties. Therefore, use of a public key which is solely with the purposes of generating CGAs for use in secured neighbor discovery is recommended. In this case, the host may still be subject to co- operative attackers on the same IP link, but those without help on the subnet are unable to determine public key/address mappings. In order to ensure that key tracking does not take place, it is possible that a device could generate of new Public/Private key pairs to be used after movement. Since such key pairs do not have any external requirements for authorization in SEND (other than reachability within a single IP hop), there is no connecting information between the keying information and previous addresses or identities. Creation of keys for CGA entails not only making of a new key pair, but also new modifiers for CGA generation. If the public key generated from this procedure is unpredictable, the likelihood of tracking the identity of the host from generated CGA address is diminished. Generation of public and private key pairs may be prohibitive in some cases for mobile nodes (especially since computation may be limited due to battery resources). In the case that the same public key is used on a succession of subnet changes, the CGA modifier may be re- selected, which makes it more difficult to track the identity of the node. If the public key is used again, it may be possible to regenerate a modifier value, which may make it hard for off-link snoopers to link a new CGA with an old one. Significant processing is associated with changes in modifiers in the case that the CGA security parameter "Sec" is non zero [CGA]. As described in the algorithm, the node (pseudo-)randomly selects a starting point for computations and then brute-force computes a set of hashes, incrementing the modifier until a hash with 16*Sec leading zeros is found. As Sec increases this takes a longer time to compute, and searches for valid hashes consume more of the modifier space. Since the initial value chosen for the modifier is (pseudo-)randomly chosen from a 128 bit identifier space, if Sec is low, it seems computationally infeasible at this time to predict the a device's choice of modifier, if the original generation is sufficiently random. Daley draft-daley-mip6-locpriv-00.txt [Page 5] INTERNET-DRAFT Location Privacy and Mobile IPv6 January 2004 If identity issues arising from public-key management may be overcome, it is reasonable to treat CGA addresses similarly to the privacy addresses described in section 2.1. 2.3 Hierarchical Mobile IPv6 In Hierarchical Mobile IPv6[HMIPv6], IP mobility signaling is reduced through maintaining a regional care-of-address at a Mobility Anchor Point (MAP). Since this address is changed rarely, the amount of Communications from HA and CNs go through the MAP, and may be unaware of the on-link care-of-address, where the MN is currently located. Because of this property, HMIPv6 may be used to provide a limited location privacy. In this way, devices will not know which of the subnets in the MAP's coverage area the MN is under. Since privacy (or other non home-identity) addresses may be used for on-link and regional care-of-addresses, a mobile node may also choose to perform direct communications to CNs by reverse tunneling to the MAP. In this case, the global Home Address information is deliberately left out of packets, and the regional care-of-address (which bears no resemblance to the Home Address) is used in this communication[HMIPv6]. Note that this is equivalent to the CoA only communication mentioned in section 2.1, but allows longer term transactions due to regional address stability. Also using HMIPv6, since it is possible to have no direct mapping between the LCoA, RCoA and Home Address, by reverse tunneling MIPv6 HA signaling to the MAP within an encrypted payload, Binding signaling can be kept private on a wireless access link. 3.0 Other Factors Location privacy is not just an issue of restricting knowledge of a Mobile IP binding. Several other factors play a significant role in the spread of identity and location knowledge from a mobile device. 3.1 Leaving Fingerprints Once a mobile node is determined to be located on a particular subnet or base-station, it is feasible to track the identity of devices moving between adjacent subnets, especially if the number of devices on these networks is low, or cross subnet mobility is low. This may be a factor even in the case where the MN has been able to hide its home identity from observers. Statistical analysis of patterns in a user's movement may indeed provide further information about nodes transiting between subnets. At this stage, correlation Daley draft-daley-mip6-locpriv-00.txt [Page 6] INTERNET-DRAFT Location Privacy and Mobile IPv6 January 2004 of known patterns of behavior may be used to match against previous knowledge or store for later reference (in case the identity is divulged later). Indeed, it may even be possible to discern when a node is attempting to hide its identity, and possibly which method or implementation is in use. While the composition of such tracking systems may not be certain, there are certainly intelligence networks aimed at data communications which may be able to perform such analysis[EU-draft]. 3.2 Visited Network Authorization In some cases, access to an IP network may be authenticated and authorized, before IP layer connectivity is available [802.1X][PPP] or before off-link communications may commence[PANA]. This will especially be the case when a device moves to networks operated by other organizations than their home service provider, due to billing requirements. In most cases, authentication of a host will be based on a unique identity known to the home provider and consequently, through the authorization process, to the visited network provider. If it is possible to trace the host's home address from the authentication identifier, it will be nearly impossible to achieve location privacy from someone with access to the visited networks' accounting logs. With link-layer based access control, further identification may be achieved using constant link-layer identifiers. For example, many link-layer systems make use of static hardware addresses for identification. Since these identifiers are constant from manufacture, once the particular piece of hardware is associated with a user's identity, tracking of the location of the particular device may become trivial (for example through analysing link-layer accounting logs on a RADIUS server [RAD-ACC]). 3.3 Higher Protocol Layers While Network Layer approaches may be used to prevent divulging identity or location information, other protocol layers may not provide equivalent services. In the case that applications may choose their own source addresses from those configured, it may be possible for a device to send identity information within an application or transport-layer data stream (for example by sending cookies within WWW traffic), from two successively configured (but otherwise unconnected) private addresses. Daley draft-daley-mip6-locpriv-00.txt [Page 7] INTERNET-DRAFT Location Privacy and Mobile IPv6 January 2004 Such mechanisms effectively defeat network-layer privacy information. 3.4 Source Address Selection A device's access to the Internet and peer servers may be significantly affected by mobility. It may be required to make use of low bit-rate, high error links, or traverse sub-optimal paths. Consequently, certain applications may attempt to achieve increased quality of service through selection of source addresses which are topologically close to their correspondents[IPv6-SRC]. Existing API's provide support for this type of operation today[SRC-API]. Therefore, an application programming interface which allows source address selection, or route optimization utilization to be controlled by applications has the potential to expose the identity or location of a host to peers. Explicitly, if a computer is attempting to maintain uniform location privacy, it is expected that attempts to make use of location based addresses will be blocked by the API, except for communications directly to and from the Home Agent. 4.0 IANA Considerations There are no IANA considerations in this document. 5.0 Security Considerations This document describes a set of considerations which may be deployed using existing protocols. The reader is referred to these protocols for further information regarding their individual security considerations. Additionally, the application of appropriate source address selection and application address interfaces are vital to ensure that devices do not accidentally divulge their location. The location of a host may have important information for emergency service personnel, or others who need to contact the mobile device. In some situations it may be necessary to divulge location information for emergency purposes based on pre-established authorization. Such policy decisions are necessarily beyond the scope of this document. Daley draft-daley-mip6-locpriv-00.txt [Page 8] INTERNET-DRAFT Location Privacy and Mobile IPv6 January 2004 Normative References [KEYW-RFC] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119 (Best Current Practice) (BCP 14), March 1997. [MIPv6] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6. Internet Draft (work in progress), May 2003. [HMIPv6] H. Soliman et al. "Hierarchical Mobile IPv6 mobility management (HMIPv6)", Internet Draft (work in progress), June 2003. [IPv6-SRC] R. Draves. "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484 (Proposed Standard), February 2003. [PRIV-ADDR] T. Narten, R. Draves. "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041 (Proposed Standard), January 2001. [SEND] J. Arkko, "SEcure Neighbor Discovery (SEND)", Internet Draft (work in progress), January 2004. [CGA] T. Aura, "Cryptographically Generated Addresses (CGA)", Internet Draft (work in progress), December 2003. Non-Normative References [EU-draft] G. Schmid. "Draft Report on the existence of a global system for the interception of private and commercial communications (ECHELON interception system)", European Parliament Temporary Committee on the ECHELON Interception System, May 2001. [MIP6MIB] G. Keeni et al. "Mobile IPv6 MIB", Internet Draft (work in progress), October 2003. [PANA] D. Forsberg et al. "Protocol for Authenticating Network Access", Internet Draft (work in progress) , October 2003. [PPP] W. Simpson, Ed. "The Point-to-Point Protocol", STD0051, RFC 1771 (Standard), July 1994. [RAD-ACC] C. Rigney , "RADIUS Accounting", RFC 2866 (Informational), June 2000. [SRC-API] E. Nordmark, S. Chakrabarti, J. Laganier, "IPv6 Socket API Daley draft-daley-mip6-locpriv-00.txt [Page 9] INTERNET-DRAFT Location Privacy and Mobile IPv6 January 2004 for Address Selection", Internet Draft (work in progress), October 2003. [802.1X] T. Jeffree, Ed. "IEEE Standard for Local and Metropolitan Area Networks Port-Based Network Access Control", IEEE Std 802.1X-2001, June 2001. Acknowledgments A significant portion of this work is based on solutions outlined in [HMIPv6]. Author's Address: greg.daley@eng.monash.edu.au Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton 3800 Victoria Australia Appendix: Location Estimation and Round-Trip-Time This Appendix describes a rough estimation which may be applicable to determine the Mobile Node's maximal distance from its purported IP subnet location. Measurement of the MN's location compared to the router of a particular IP subnet may be used to infer if the MN is away from home, and the maximum radial distance of the MN from its location using speed of light (in the transmission media) propagation to bound estimates. Essentially the mechanism assumes that it is possible to reduce the RTT for home tunneled communications between devices to be: RTT(MN,CN) ~ RTT(MN,HA) + RTT(HA,CN) Therefore, if a CN can measure round trips between itself and the HA, or itself and the MN, it can estimate the RTT(MN,HA). Since the prefix of the home network may be used (in some cases) the location of the home subnet, a portion of RTT(MN,HA) is related to the propagation delay between the MN and HA. Daley draft-daley-mip6-locpriv-00.txt [Page 10] INTERNET-DRAFT Location Privacy and Mobile IPv6 January 2004 Some of the communications delays between the MN and the HA are predictable for a certain packet size (for example serialization delay on a wireless link), and dependent on the number of routers and switches through which the packets have to pass. While it is not possible to determine a-priori which switches and what media a packet must transit through, it may be reasonable to assume a symmetric access network design when a device is connected to a single service provider. In this way, it may be possible to test or estimate the access network (serialization, queueing, MAC, switching) delays using a device topologically close the HA, and subtract this delay from the minimum RTT(HA,MN) estimation as a fixed or predictable delay. Therefore, the maximal distance D(MN,HA) may be expressed in the following fashion: D(MN,HA) < Vmean * [ RTT(MN,HA) - FixEst - VarEst( RTT(MN,HA)) ] ------------------------------------------------------ 2 * PathCost Where: PathCost >= 1, FixEst >=0 VarEst >=0 Vmean < Cvacuum PathCost is an estimation of how many far the data has to travel to increase its radial distance (eg. fiber-miles to air-miles). A typical value is 1.5. FixEst is an estimation of non-location dependent delays associated with transferring packets through the particular class of access network. VarEst is an estimation of variable delays associated with the number of backbone switching and routing hops which a node must pass through for a particular RTT. While this is not explicitly location independent, it is propagation delay independent. A conservative approach (which ensures the MN is within the the radius drawn), minimizes the PathCost, Fixed and Variable Estimation variables, and assumes optical transmission. As mentioned above though, more information about the access network, or typical path cost can be used to increase the accuracy of this measurement, or to give a probabilistic determination of location. Daley draft-daley-mip6-locpriv-00.txt [Page 11] INTERNET-DRAFT Location Privacy and Mobile IPv6 January 2004 Using this simplification, the distance from the HA must be less than: D(MN,HA) < C * [ RTT(MN,HA) ] ------------------ 2 For example, the maximum theoretical distance for a with a minimum 20ms RTT latency to the HA is ~3000km (almost 2000 miles). In any case, it is apparent that adding an induced delay of 2ms to every packet response adds 300km of inaccuracy to the estimation (or at least 100km with a path cost of 1.5 through copper). Therefore, devices which wish to increase their apparent distance from a Home Agent need only to add a constant delay to responses sent to the network. This document expires in July 2004. Daley draft-daley-mip6-locpriv-00.txt [Page 12]