Because people might think that TARA, according to draft-hummel-tara-00.txt, will also jeopadize privacy (because it utilizes geographical location) I like to point out the following: The by DNS retrievable user's locator denominates the geographical location of that TARA-router to which the user is attached or, more general, from where some intra-domain path leads to the particular user via which packets are forwarded based on the destination user's IP-address. Indeed the first two octets of this locator information MUST comply with the true geographical square-degree-geopatch (which is 111 km times 111 km at the equator) where this TARA-router is situated. However,wrt the remaining 3 octets it is only necessary that each TARA-router within this geopatch has a different value. I can imagine several methods how to accomplish this. Will say: TARA does not jeopardize privacy! Heiner In einer eMail vom 08.10.2010 08:42:01 Westeuropäische Sommerzeit schreibt [email protected]:
Short version: This is in interesting and important I-D. I think it was written in a way which did not consider TTR Mobility. I provide a description of TTR Mobility and how the concerns and recommendations of this I-D apply to it, vs. how they apply to LISP Mobile or the use of a Loc/ID Separation (CEE) architecture such as ILNP to mobility. I think that LISP Mobile or ILNP etc. are incapable of meeting the first recommendation. I think TTR Mobility, either under Ivip or LISP can meet the concerns which motivate this recommendation - that movement of the MN not enable communicating parties or anyone else to infer its geographic (or perhaps topological) location. Hi Scott and colleagues, Thanks for your interesting new I-D: http://tools.ietf.org/html/draft-brim-mobility-and-privacy-00 Here are my notes on this I-D, as it applies to TTR Mobility and to some other architectures. It appears that you didn't consider TTR Mobility as one of the architectures you were were trying to anticipate the problems of. I first described TTR Mobility along with the basis of Ivip in June 2007: http://www.ietf.org/mail-archive/web/ram/current/msg01518.html While there is not yet an Internet Draft, it has been properly described, with diagrams, since August 2008: http://www.firstpr.com.au/ip/ivip/#mobile This message contains a pretty good description of TTR Mobility. Its not complex, but it is flexible and could be used in many ways. Here are some thoughts on your Mobility and Privacy I-D, which I think tackles an extremely important topic. On page 4, the third point ("An identifier ...") states that the MN (Mobile Node) needs an identifier such as an FQDN, SIP URI or the like. This is on the assumption that the MN will have a different IP address as it moves around the network and the physical world. However, with TTR Mobility, the MN retains the same IP address, or multiple IP addresses (such as a /64 for IPv6) for all applications to use, no matter where it is. So for other hosts to initiate contact with it, they can simply use the MN's IP address, either directly, via a referral or similar, or after obtaining the IP address via DNS lookup of an FQDNs, or as part of a SIP URI etc. The third point mentions the MN's IP address being associated with a "rendezvous point" or "home agent". In TTR Mobility there is no necessarily fixed home agent or anything like it. The IP address (or multiple IP addresses) of the MN are mapped by the Core-Edge Separation system (such as Ivip or LISP) to a particular TTR, which behaves like an ETR to the rest of this system. The MN establishes a two way (typically encrypted) tunnel to this TTR from its one or more Care of Addresses (CoAs) - addresses it gets from whatever access networks it is using, such as wired Ethernet, 3G or WiFi Wireless etc. These CoA addresses can be behind one or more layers of NAT and can also be on TTR addresses. These principles recurse to any depth or mixture, though the packets can get a little dizzy as they traverse the various translations! So you could have a CoA address which is behind two layers of NAT, where the outer NAT box's address is an SPI (Scalable PI) address which itself is provided by Ivip, including perhaps via TTR Mobility. That TTR Mobile address could itself be provided via a CoA which is behind NAT, or on another TTR Mobile SPI address etc. etc. The MN's owner pays for the use of the TTRs of (for convenience of explanation) of a single TTR Mobility company's set of TTRs, which would be located all over the world, or in the area the company services. For instance, there could be TTRs (or data centres with multiple TTRs) in 10 major North American cities, another 10 in Europe, 2 or 3 in Australia etc. No matter what the topological location of the MN's CoA, it can build a two-way tunnel to any of these TTRs. (TTRs are always on conventional, non SPI, global unicast addresses, as all ETRs must be with Ivip.) The TTR accepts outgoing packets sent by the applications in the MN and routes them to the rest of the Net. For instance, a MN in Melbourne Australia might have two CoAs (one via 3G and another behind NAT on a home DSL service) and from each would build a tunnel to a single TTR somewhere - let's say in Sydney (900km away). This would work fine. If the MN was moved to London, it would have new CoAs and would tunnel from these to the Sydney TTR. It would be desirable (to reduce delays and packet loss rates), but not essential, for the MN to use a London-based TTR in preference to the Sydney one. So, typically, the TTR company's management system would detect the approximate topological location of the new CoAs and direct the MN to tunnel to a London TTR as well as well. The TTR company's management system controls the mapping of the micronet which contains the MN's SPI space - which might be a single IPv4 address, multiple of them, or one or more IPv6 /64 prefixes. Once the MN established a two-way tunnel from each of its one or more CoAs to the new London-based TTR, the TTR company's management system would change the mapping of the MN's micronet from the Sydney TTR to the London TTR. Within a second or two (except for in rare error conditions where ITRs handling packets for this MN, for some reason don't get the updated mapping) all the the packets addressed to the MN's IP address(es) would be tunneled by ITRs all over the world to the London TTR instead of the Sydney one. Once all ITRs are doing this (typically a few seconds in Ivip, but longer in LISP depending on the mapping distribution system) the MN could drop its tunnels with the Sydney TTR. So the TTR is a little like a home agent, but there is no single TTR the MN is dependent upon. The ITRs of the CES system ensure that ordinary hosts all over the world have their packets sent to the currently mapped TTR with generally little stretch. By changing to a nearby (such as within 1000km or so) TTR - which involves a mapping change - the MN can ensure generally low stretch for the entire path of packets being sent to it, and for its outgoing packets. So the fourth point (route optimization) is covered partly by the ITR->(TTR=ETR) function of the CES system, and partly by the MN typically working with a nearby TTR. Point five seems to be relevant to other mobility approaches (perhaps LISP mobile or the mobility functions of a Locator/Identifier Separation architecture such as ILNP), but not to TTR Mobility, since the MN uses its (numerically) stable SPI IP address at all times. With TTR Mobility, there are no special protocols required for correspondent hosts. Likewise, point 6 refers to an identifier, but in TTR Mobility, this is simply the MN's SPI IP address (or multiple such addresses), and perhaps any FQDN which points to this. The next paragraph (middle of page 5) considers mobile nodes operating only as clients. This does not apply to TTR Mobility, since each MN has its one or more SPI IP addresses just like any other host on a global unicast address. Section 4 raises the privacy and security problems which would arise due to a MN changing its IP address as it moves. This does not occur with TTR Mobility - since the correspondent hosts continue to access the MN by its numerically stable SPI global unicast IP address(es). However, it would be easy for someone with an interest in doing so to determine the IP address of the TTR which is currently used by the MN. This can easily be found by looking up the (Ivip or LISP) mapping for the MN's IP address, which returns the address of the ETR which packets should be tunneled to. This is the address of the TTR. Assuming this could be used to infer geographic location of the TTR (which would normally be the case) then with TTR Mobility, it would be easy to infer the geographic location of the currently used TTR. However, a privacy-conscious user might configure their MN (which works with the TTR company's management system - so perhaps it would mean configuring the management system) not to change to another TTR when the MN moves to a new CoA under any circumstances, no matter the distance between that CoA's point of attachment to the interdomain routing system and the point of attachment of the currently used TTR. TTR changes are desirable only to reduce stretch - and the consequent delays and higher risks of packet loss). So changing to another TTR probably only make sense for moves of order 1000km, given the broadly global nature of Internet communications. A privacy-conscious user might have their MN always use a TTR in a given location, no matter where on Earth the MN is physically located. This involves stretch but that might be a worthwhile price to pay to avoid the potentially deadly consequences which are quite rightly raised in this I-D. Careful scrutiny of delay times to the MN could be used to infer its distance from the MN. Suppose my MN was using a TTR in Los Angeles, but my MN was in Ulan Bator (Mongolia), there would be a significant delay in all communications. If was keen to avoid other people detecting this, I could do so with a special hack in my MN's stack to determine the delay to the TTR, and impose similar delays for all packets, or perhaps all packets from hosts which I didn't trust. Savvy TTR Mobility companies could offer this as a service, to be implemented by the TTRs. On page 6: The biggest concern is if information that makes a mobile node traceable is required to be publicly available in order for the Internet to function. If it is, it can be accessed not only without the mobile node's consent but even without its knowledge, perhaps without any audit trail of who is accessing the information that could be looked at after the fact. This is indeed a concern. With LISP or ILNP, every time the MN moves to a new access network, so gaining a new IP address (or for ILNP, a new Locator) then it needs to change its mapping. Anyone can read the current mapping by doing mapping queries, without needing to even send a packet to the MN. So these approaches to mobility inherently have this "invisible tracking" vulnerability. With TTR Mobility, the mapping only changes when a new TTR is used - and for most devices, such as those which stay in the one city or region of a country, this may not happen for months, years or at any time. Furthermore, as noted above, a privacy-conscious user could retain the same TTR no matter where they are - so an attacker would see no change in mapping from one year to the next. The rest of this paragraph raises acute problems for LISP Mobile and for the mobility approaches of ILNP and other Loc/ID Separation (Core-Edge Elimination) architectures. The problem is far less acute for TTR Mobility, and users can avoid the problem entirely by retaining the one TTR (or at least a TTR in the one geographic location) at all times. MIPv6 avoids the "invisible tracking" problem since it always uses a single home agent, but an attacker only needs to open up a session with the MN and use the "route optimization" function in order to determine the MN's current CoA. To avoid this kind of attack, the MN would need to be configured not to allow route optimization except with trusted hosts. On page 7: The principle of hiding information that can expose geographic location in both data and control planes, and deferring revealing more until the mobile node or its agent decides what it wants to do, is essential. TTR Mobility typically only reveals very coarse geographic location information - for instance if the MN does in fact gain a new TTR if it moves some distance like 1000km or so from the current TTR. I mention 1000km purely as an order-of-magnitude figure. The actual geographic location is not important - what matters is the extra distance and extra number of routers packets need to take due to the relative topological locations of the MN's CoA and its TTR. A MN might have two CoAs at a time, such as via a WiFi and a 3G network. Topologically, these could have very different distances from the TTR. There may be many situations where it would make little or no difference whether the path to the TTR involved 10 or 5,000 km of fibre and various intervening routers. So I think most people would find the system works like a charm if they kept the one TTR whenever they were in North America, and changed to another TTR when they went to Europe, Russia, South America, Australia / New Zealand, South East Asia, the Middle East, Japan / Korea / Taiwan or mainland China. This pretty much avoids the recipients of birthday presents accidentally or deliberately tracking the shopping expedition unless she is about to receive a Mongolian horse! Folks with more serious concerns such as those in the espionage trade would take further precautions, such as retaining the same TTR indefinitely, and adding delay to obfuscate inferences about their physical location. A single MN could also have multiple IP addresses or IP address ranges, each with completely different TTR mobility arrangements, including the use of TTRs of other companies. This way, the IP address used in the owner's personal business can be kept separate from that used for their professional activities. Here are my thoughts on the Recommendations: 1 - Architectural changes MUST avoid requiring exposing a mapping between any of a node's identifiers and IP addresses/locators to unknown observers. If they require exposure, they will experience a head-on collision with basic principles of the IETF and with privacy policies around the world. It will simply not be acceptable to require the loss of this much individual privacy. This is on the assumption that the MN's IP address changes as it moves. This is not the case with TTR Mobility. The only organization which knows the MN's one or more CoAs is the TTR company. Since the global unicast IP address(es) used by the MN in TTR Mobility (either under Ivip or LISP) do not imply anything about their geographic location, I think TTR Mobility is compatible with the privacy and security concerns which give rise to this requirement. As far as I know, LISP Mobile and Loc/ID Separation architectures such as ILNP are all incapable of complying with this recommendation. 2 - An architectural proposal MAY make it possible to use public information systems to optimize traffic flow, but ideally it should do so without sacrificing privacy. If it cannot do so without sacrificing privacy, the default case built into the architecture SHOULD be to preserve privacy instead of optimizing. The reason is that most users will not change defaults, and the default be one of privacy, only moving away from it by customer choice. If the TTR Mobility system defaulted to changing to a new TTR when the MN moved far enough away from the current one (such as 1000km or more, very loosely, but really based on topology, packet losses, delays etc.) then it would reveal geographical (or really topological) movements of the MN only at a gross scale. It would not reveal movements such as most moves of hundreds of km. However, it is possible that a new access network might give a CoA with a very different topological location, such as by using a geostationary satellite link, or an office LAN of some organization which had its links not to local ISPs, but via a VPN to head office in a distant country. In order to comply with this recommendation, TTR Mobility systems would need to default to not changing the TTR except with the explicit permission of the user, or automatically after the user had made a fully informed and unpressured decision to allow this. I plan to add this to future documentation of TTR Mobility. "Fully informed and unpressured" is a phrase I used in previous privacy advocacy work. Its not good enough that the user has to actively select an option to reduce their privacy and security - since this could easily be done in a manner in which they were uninformed about the consequences of their action, or felt unreasonable pressure to do so for some other reason. It is beyond the scope of RFCs etc. whether the actions of the user are fully informed and unpressured, but it might be worth adding a sentence to this recommendation: If the default setting is to protect the user's privacy and security, and if the user changes the setting only after being fully informed, and after making an unpressured decision to do so, then the system will protect their privacy and security to the maximum extent possible, without requiring users to take any action or fully inform themselves of all the issues. 3 - If possible, information about who is gathering data about a user SHOULD be available to that user. Everyone deserves to know who is watching them. I think this would be highly impractical or impossible for Ivip or LISP - or for any of the other architectures. All these architectures involve a global-scale lookup function: Ivip: An ITR or any other device or person can look up an SPI (Scalable PI) IP address of a destination host and get: Start address of the matching micronet. Length of the micronet. ETR address. For TTR Mobility, the ETR address is that of the currently used TTR, which implies only coarse geographical location, or perhaps none if the user elects to keep the same TTR at all times. LISP: An ITR or any other device or person can look up an EID IP address of a destination host and get: Base address and mask-length of the matching EID prefix. One or more ETR addresses, potentially with extra. information to do with priorities and TE (load sharing). For TTR Mobility, this would likewise be the address of the one or potentially multiple TTRs. (In Ivip or LISP, a MN could maintain tunnels to multiple TTRs, but in Ivip, the mapping at any one time is to a single TTR=ETR.) So for TTR Mobility, LISP's mapping system would not reveal much - no more than noted above for Ivip. For LISP Mobile, the ETR address is the CoA of the MN itself, since the MN acts as its own ETR. (There's no way this can work behind NAT, and it involves nested encapsulation for the ITR->ETR tunneling if the CoA is on an EID address.) This mapping will change every time the MN gains or loses a CoA. This information is highly correlated with the MN's geographical location. Even walking near a cafe with free WiFi may cause the MN to get a new CoA, and so change its mapping to include an IP address traceable to that restaurant - (assuming the cafe gave out global unicast addresses on its WiFi system, since LISP Mobile can't run its ETR functions from a behind NAT address). So with LISP Mobile, it would be potentially possible to watch, in real-time, the movement of the MN through a locality or city - without ever sending a packet to or from the MN. IRON: I have not read the latest IRON I-Ds, but I understand it incorporates, or is inspired by, some elements of TTR Mobility. ILNP or other Loc/ID Separation architectures: As with LISP Mobile, the global Identifier to Locator mapping system returns Locators, which are much the same as, or are identical to, the global unicast CoA address. So the security and privacy implications of this are equally serious. There's no technical or administrative way of reliably ensuring that every person or technical entity who enquires about this information is identified to the user of the MN. (Even if this could be done, it would raise further security and privacy problems.) These mapping lookup systems involve caching (maybe not ILNP?). Even if they didn't involve caching, it would be impossible to prevent one entity requesting and gaining the information and then passing it on to another entity. I think this recommendation is not helpful, since it is impossible to achieve on any architecture. 4 - Proposals SHOULD address the issue of loss of geographic location privacy due to monitoring of packets crossing the Internet, and find an explicit balance between conflicting goals. I fully support this. 5 - Protocols SHOULD avoid using identifiers for multiple purposes. Different identifier scopes do not need to overlap. Confidentiality boundaries can be established by clearly defining limited interfaces. I fully support this too. End-users can implement this by using separate identifiers (IP addresses, in the case of TTR Mobility for Ivip or LISP, or for LISP Mobile ; Identifiers for ILNP and other Loc/ID Separation architectures.) It is up to the end-users to be careful how they use their various IP addresses, Identifiers or whatever. 6 - Protocols SHOULD avoid using long-lasting identifiers in scopes where they are not necessary. I agree - but more generally, they should avoid using anything, including "locators" (which are accessible to correspondent hosts directly, or to anyone via a mapping lookup) for longer than is necessary for a particular person in a particular role, since that would increase the externally observable correlations between the user's activities and the IP address, Identifier or Locator their MN was associated with. - Robin _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
