Mobile phone users can already be located based on current technology - this is a fact. Although I appreciate all respective privacy concerns ( in Germany an intensive pro/con-StreetView debate is still going on) I think that this aspect doesn't impact any of the discussed concepts. Heiner
-----Ursprüngliche Mitteilung----- Von: Robin Whittle <[email protected]> An: RRG <[email protected]> Cc: Scott Brim <[email protected]> Verschickt: Mo., 11. Okt. 2010, 7:15 Thema: Re: [rrg] draft-brim-mobility-and-privacy-00 & TTR Mobility Short version: More analysis of how various architectures meet or do not meet the first requirement of this I-D. Also, some thoughts on the definition of privacy and on the various roles people have, which will be reflected in the way they configure their mobile devices. Each mobile device might have 10 or more network addresses (Identifiers and perhaps Locators) - one for each of its owner's roles. So maybe scalable routing needs to cope with 10^11 micronets, EID prefixes, Identifiers or whatever, rather than the previously discussed 10^10. Hi Scott, Thanks for your message, in which you wrote: > Thank you. The main thing we wanted to do was to get protocol designers > to make location privacy an explicit consideration. > >> I think that LISP Mobile or ILNP etc. are >> incapable of meeting the first recommendation. > > I don't know if that's true at all. In fact I'm sure they can come up > with a response, could answer the concern, and may have thought of the > tradeoffs already. Let's not second-guess them. OK - it will be interesting to see what they write. > I'll respond to the detailed parts of your message later. > > Thanks again ... Scott OK. Here is some more detailed analysis regarding how I think the various architectures would meet your first requirement: http://tools.ietf.org/html/draft-brim-mobility-and-privacy-00#section-5 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. I am using "host" and "node" as interchangeable synonyms. I discuss LISP and the LISP approach to mobility - LISP-MN: http://tools.ietf.org/html/draft-meyer-lisp-mn-03 This is out of scope in the LISP WG, and hasn't been discussed much in public, as far as I know. I discuss "ILNP etc." meaning ILNP specifically, but also any other Loc/ID Separation (Core-Edge Elimination CEE) architecture. In these architectures, the host stack (and perhaps application, though for simplicity I assume not) is responsible for knowing the one or more Locators of the other hosts it is sending packets to. For simplicity I assume the MN has a single SPI address (Ivip), EID address (LISP) or Identifier ILNP etc. There's nothing to stop a single physical device having multiple of these, such as for different roles or even for the same role, to make it difficult to track the device's use in these roles. The simplest view of "roles" for a personal mobile device could mean one for personal communications and one for business. This would be closely analogous, or would include exactly, the idea of a cell-phone having one number for personal calls and another for business. Outgoing calls could be made with either number, and each number could be turned on and off, with incoming calls going to one or separate voice mail services, according to the user's choice. There could be multiple business roles, and multiple personal roles. People might work for different companies, or have quite differing roles, within the one company. So in the future we can expect the mobile device to have a row of buttons, one for each role - to enable or disable how the device responds to the network addresses, identifiers etc. associated with each role: Husband Father Employee Consultant or Daughter (for purposes of parents and school) Individual (friend group A) Individual (friend group B) Employee (part time job is frequently a PITA) I think everyone, at some time or other, feels one or more of our roles are a PITA and it would be good to have voice mail, the email Inbox etc. handle that stuff for the time being! There needs to be a master "I am sleeping etc." button too, since mobile devices take so long to power down and boot up. Adolescents will surely have one role their parent's know about and any number of other roles kept well hidden from their parents. This is a natural part of how people live, or try to live. It is essential to health and happiness. We disclose different things to different people according to our preferences, which may change from time to time - and accept contact from people likewise. We may have a friend relationship with someone we work with, and a work relationship - these roles, and our contactabilty for each role, needs to be kept reasonably separate. We don't want them calling us on Saturday morning about some work matter, but if they are having a BBQ, then we would probably be happy to hear from them. The idea that a cellphone has a single number is a technological convenience for the network and the device itself, not one which suits the way people actually want their communication systems to behave. By the way, one definition of privacy is: Ensuring each individual has full autonomy in managing their personal boundaries. This is essential to our physical and mental health. The boundaries concern the influx and egress of information. They also concern the attention we need to pay to other people and things, and attention they pay to us. Telemarketing calls and spam violate the principle that the person should control their attention and not have it distracted, at least in a systematic manner for no purpose they care about, by other people. Getting a call from the fire brigade that a bushfire is heading towards your home would also be an intrusion, and a systematic and impersonal one. However, it is the kind of intrusion an individual is more likely to accept than telemarketing calls. Privacy is more than about the outflow of personal information to other parties. It is also about being undisturbed. I think the concept can also be extended to the person not having to know things they really don't want or need to know. (Blind folks have an advantage in that they never get to see - are never forced to see - down the back of some people's pants which are deliberately slipping half-way down the wearer's backside.) I would also extend it to protecting children from unpleasant and unhealthy aspects of the adult world (which is a highly subjective matter) - but that is probably going beyond what most privacy advocates would mean by the term "privacy". "Autonomy" can reasonably be considered as meaning "consent with full knowledge and unpressured decision making". There are well-established legal limits to privacy, such as not being able to drive when alcohol-affected, not being able to use a cellphone etc. while driving, not being able to hide a disability like poor eyesight when getting a driving licence etc. Other limits to privacy are more contentious, such as being subject to police surveillance, ideally with a variety of checks and balances against this being done without "proper justification" and protection for whatever information is gleaned by the surveillance. Perhaps we need to add another factor of 10 into estimates of the number of micronets (EID prefixes, in LISP) which the total system must scale to. If there are 10 billion people, with one mobile device each, and 10 roles each, we need 10^11 micronets . . . In principle, with TTR Mobility, the MN could treat each such role as a different entity. For the SPI address it uses for the Father role, it could tunnel to the nearest TTR, since security and privacy with this role is regarded as not requiring a stable TTR. For some other roles - and Scott and colleagues mentioned police informers - the MN would surely be configured to tunnel to one fixed TTR no matter where the MN was. So this raises a MN physical device behaving like multiple separate "virtual MNs" from a networking point of view. Each such "virtual MN" would have its own SPI address, EID address or Identifier, and the rules for when it would connect to any TTR, or to which TTR and with what extra delay, could vary between the various roles. Back to mobile devices - for simplicity, discussing a single identifier, role or whatever. With LISP and LISP-MN, the EID of the MN never changes with location. (This could be a single IPv4 address, a subnet of them or one or a subnet of IPv6 /64 prefixes.) Likewise with Ivip, the SPI (Scalable PI) address of the MN (Mobile Node) never changes. (This could be one or more contiguous IPv4 addresses or one or more contiguous IPv6 /64 prefixes.) Similarly, with ILNP etc., the MN's Identifier never changes. Its one or more Locators will change as it connects to various access networks. For simplicity, I will use "CoA" = "Care of Address" to mean: LISP-MN, LISP-TTR-Mobility & Ivip-TTR-Mobility: Each IP address the MN gets from an access network. (It could get multiple from each access network, and in IPv6 it might get a whole /64.) ILNP etc. (Loc/ID Separation) Each Locator, which in ILNP and some other architectures is actually an IPv6 address. Applications in the correspondent hosts in all these architectures would not notice anything to do with the other host being mobile, since they use the MN's EID, SPI address or Identifier. [This is on the assumption that an application actually works with an ILNP stack. When I tried, I couldn't see how existing IPv6 applications could work with an ILNP stack. Tony Li (msg07111) didn't figure out how it could be done and Ran didn't try.] In ILNP, the stack of the correspondent host would know all about the CoA(s) of the MN, since each one is (or has) a different Locator, and in ILNP etc. (Loc/ID Sep.) the host's stack is doing all the work of deciding which of the other host's multiple Locators to send packets to. By contrast, the stack of the correspondent host in LISP-MN, Ivip-TTR-Mobility or LISP-TTR-Mobility would not see anything to do with the MN's mobility, since it is always addressed by its numerically stable, physically mobile, EID or SPI IP address. The ITRs in these architectures are doing the work which hosts have to do with ILNP etc. Still, in ILNP or LISP-MN, if someone wanted to track the movement of a mobile node, they could easily do that, even without sending any packets to the MN. Simply looking up the EID->RLOC mapping in LISP-MN, or the Identifier->Locator mapping in ILNP, would provide the MN's changing CoAs in real-time. Here's a chart of the architectures and whether I think they meet Scott's first requirement (first point in Section 5), from various places where the MN's movement might be tracked. "Application" means application on a correspondent host, mobile or not. Likewise, "Stack" means the stack of the correspondent host. "Other" means anyone who wants to track the MN but is not necessarily running a host which is communicating with the MN. Ivip-TTR LISP-TTR LISP-MN ILNP & other Loc/ID Sep architectures Application Yes Yes Yes Yes# Stack Yes Yes Yes No Other Yes* Yes* No No Yes Meets the requirement. # This assumes the application either doesn't, or can't, ask the stack about Locators, or doesn't in fact take an interest in them. Any application could, if it was written to do so, perform an Identifier > Locator lookup. So there's no way of preventing an application from violating the first requirement. No The "Other" attacker, or an attacker using the stack of a correspondent host, can always easily find out the current CoA of the MN. This will generally provide highly detailed real-time topological / geographic location information. * In TTR Mobility, the TTR company always knows the one or more CoAs of the MN. So the MN owner needs to completely trust the TTR company regarding the security and privacy implications of their MN's mobility. If the MN always uses the one TTR, then no-one but the TTR company has any information about the topological / geographic location of the MN. Round trip delays could reveal distance of the MN from its TTR, but that could be fudged to remove this cue too. If these two steps are taken, then the requirement is fully met. But this would mean generally worst case delays all the time, and potentially long path lengths if, for instance, the TTR was in Berlin and the MN was in Hong Kong. In my previous message (msg07460) I wrote that in order for a TTR Mobility system to comply with requirement 2: 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. To really fully comply with this, the default would have to be: 1 - Keep the same TTR no matter where the MN is located. 2 - Add delays if necessary to keep the same delay behavior no matter how far the MN is from the TTR. This would be the ideal from a privacy and security point of view. However, it also enforces worst case delay times on all communications, since the delay needs to be as long as worst case between the TTR and MN when they are on opposite sides of the Earth and its network topology. I think this delay stuff would be particularly burdensome. So I am not sure to what extent this would actually be followed by the TTR operators. The TTR Mobility spec can recommend defaults for these things, but I think it is beyond the IETF's role to specify what they must be for commercial services. If the MN changes to a "nearby" TTR, then an "Other" attacker can always look up the mapping of the MN's micronet / EID prefix and find the IP address of the currently used TTR. That provides coarse topological / geographical locality information. How coarse depends on how many TTR sites there are to choose from and how assiduously the TTR company makes the MN tunnel to the "closest" TTR. For practical purposes, I am thinking of TTR sites in major cities, such as half a dozen in the USA. So that would be the granularity of the exposure of geographical location, if the "closest" TTR was used. With TTR-Mobility, the TTR company knows the CoA addresses and it is the company's business to closely monitor the topological "location" of all the MN's CoAs. It doesn't need to do this if the MN's owner wants the MN to tunnel to generally nearby TTRs - which would be the case for a privacy sensitive user. However, assuming most MN owners want to get the best performance, lowest stretch, then they would have the TTR company's management system constantly monitor where the CoAs are in the network, and if a new CoA was "too far", however judged, from the current TTR, the MN would be instructed to tunnel to a closer TTR. Then the mapping would be changed. That mapping change reveals to any "Other" inquiring mind something coarse about the topological or geographic location of the MN. - 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
