Subject: [rrg] draft-brim-mobility-and-privacy-00 & TTR Mobility

From: Robin Whittle <[email-masked]>
Date: Fri, 08 Oct 2010 17:41:52 +1100

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

---

From: Scott Brim <[email-masked]>
Date: Fri, 08 Oct 2010 09:14:00 -0400

>                   Separation (CEE) architecture such as ILNP to

Thank you.  The main thing we wanted to do was to get protocol designers
to make location privacy an explicit consideration.

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

I'll respond to the detailed parts of your message later.

Thanks again ... Scott

---

From: Robin Whittle <[email-masked]>
Date: Mon, 11 Oct 2010 16:15:22 +1100

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,

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

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

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

---

From: [email-masked]
Date: Mon, 11 Oct 2010 06:48:53 -0400

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-masked]>
An: RRG <[email-masked]>
Cc: Scott Brim <[email-masked]>
Verschickt: Mo., 11. Okt. 2010, 7:15
Thema: Re: [rrg] draft-brim-mobility-and-privacy-00 & TTR Mobility

Hi Scott,

   Husband
   Father
   Employee
   Consultant

or

Stack           Yes        Yes        Yes      No

Other           Yes*       Yes*       No       No

  - Robin
_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg