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

From: [email-masked]
Date: Fri, 8 Oct 2010 05:58:05 EDT

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-masked]:

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-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: Scott Brim <[email-masked]>
Date: Fri, 08 Oct 2010 10:06:50 -0400

On 10/08/2010 05:58 EDT, [email-masked] wrote:
> 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.
>  
> 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.

Let's say: NEED NOT jeopardize privacy.  If the later octets are de
facto allocated in a pattern that typically maps to a finer-grain
location (for example, to the level of a particular city block or a
particular WiFi network in a store) then that would reveal too much,
given the way public policy is going.  Perhaps you could add text saying
that the later octets must not reflect geographic location.