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
