Re: [Pidloc] Let's start

[Luigi Iannone <[e-mail]>]

Hi,

I read you document about ID/Loc privacy and have a few comments (inline).

Ciao

L.

> On 4 Sep 2018, at 18:49, Behcet Sarikaya <[e-mail]> wrote:
> 
> Folks,
> 
> As the summer is over, it is time to 
> start talking about our favorite subject, IdLoc protocols and privacy issues.
> 
> As you may know, Erik Nordmark published a draft:
> https://www.ietf.org/id/draft-nordmark-id-loc-privacy-00.txt <https://www.ietf.org/id/draft-nordmark-id-loc-privacy-00.txt>
> 
> in July 2018 just before IETF 102 in Montreal. 
> 
> We would like to propose taking this draft as a PS (problem statement) draft to base the technical discussions on this list and then build other work/ drafts around it.
> 
> Since publication, draft-nordmark-id-loc-privacy received a number of comments on other lists. However it is yet to be discussed on this list.
> 
> So this mail invites people to please read the draft and get on the discussions.
> Also of course if you have a new idea which deserves attention, write a draft and let us know about it. We may also have some ideas and then we may initiate discussions on those in the coming days.
> 
> Our goal currently is to go for a BoF in IETF 104 in Prague.
> 
> Also before closing, let me state again, as Dirk did, please encourage people you know to subscribe pidloc at
> https://www.ietf.org/mailman/listinfo/pidloc <https://www.ietf.org/mailman/listinfo/pidloc>
> 
> Thanks,
> 
> Behcet & Dirk
>  
> -- 
> Pidloc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pidloc


> 
> 
> 
> 
> Network Working Group                                        E. Nordmark
> Internet-Draft                                                    Zededa
> Intended status: Standards Track                            July 2, 2018
> Expires: January 3, 2019
> 
> 
>             Privacy issues in ID/locator separation systems
>                     draft-nordmark-id-loc-privacy-00
> 
> Abstract
> 
>    There exists several protocols and proposals for identifier/locator
>    split which have some form of control plane by which participating
>    nodes can use to share their current id to locator information with
>    their peers.  This document explores some of the privacy
>    considerations for such a system.
> 
> Status of This Memo
> 
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    This Internet-Draft will expire on January 3, 2019.
> 
> Copyright Notice
> 
>    Copyright (c) 2018 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
> 
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
> 
> 
> 
> Nordmark                 Expires January 3, 2019                [Page 1]
> 
> Internet-Draft                idloc privacy                    July 2018
> 
> 
> Table of Contents
> 
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>    2.  Keywords and Terminology  . . . . . . . . . . . . . . . . . .   3
>    3.  Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .   3
>    4.  Threats against Privacy . . . . . . . . . . . . . . . . . . .   4
>      4.1.  Location Privacy  . . . . . . . . . . . . . . . . . . . .   4
>      4.2.  Movement Privacy  . . . . . . . . . . . . . . . . . . . .   4
>    5.  Not everybody all the time  . . . . . . . . . . . . . . . . .   4
>      5.1.  Optimized routing . . . . . . . . . . . . . . . . . . . .   4
>      5.2.  Family and Friends  . . . . . . . . . . . . . . . . . . .   5
>      5.3.  Business Assets . . . . . . . . . . . . . . . . . . . . .   5
>    6.  Boundary between ID/locator part and rest of Internet . . . .   5
>    7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
>    8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
>    9.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
>    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6
> 
> 1.  Introduction
> 
>    When the IP address is separated, one way or another, into an
>    identifier and a locator there is typically a need to be able to look
>    up an identifier to find possible locators which can be used to reach
>    the identified endpoint.  
There is an important assumption here, namely that everything is IP.
Wouldn’t make more sense to have a general discussion were IP-based ID/loc separation is just 
one case?
Or there is a specific reason for this? 


> If such a system (think distributed
>    database) was publicly available while identifiers are assigned to
>    devices such as mobile phones which have a strong binding with an
>    individual, then this would introduce additional privacy
>    considerations which do not exist in the absence of the ID/locator
>    split.
Not sure this is completely true. Think about SLAAC. You can identify the device and you can know were it is because of its prefix.
Sure, there are privacy issues that need to be addressed because of the peculiar ID/Loc separation architecture, but often those issues are variant of issues already existing the in the Internet. 
A question to ask is: those issues are worsened or alleviated with ID/Loc split?

>    Without an ID/locator split a device is already providing its IP
>    address (in the form of a source address) to any network device along
>    the path, and also to the remote endpoint.  That endpoint in
>    particular might use IP geolocation databases to get a pretty good
>    idea of where its peer is located, for instance to offer information
>    and/or advertising relevant to that location.
> 
>    However, such such a device (e.g., a laptop or smartphone connected
delete the duplicate "such"

>    over WiFi) move e.g., from home to a coffee shop, the IP address
>    changes.  This makes it harder for network devices along the paths to
>    realize that the its is the same mobile device. 
something wrong in the sentence above … may be “that it is the same mobile device”...
>  And if the mobile
>    device is not retaining cookies or logged into websites, those remote
>    peers would also have some difficulty determining it is the same
>    mobile device.  Furthermore, a mobile device which is using typical
>    cellular network technologies end up with an IP address, at least as
>    seen by remote peers outside of the cellular network, which is
>    associated with the cellular operator but does not necessarily
>    indicate a particular location of the mobile device.
> 
> 
> 
> Nordmark                 Expires January 3, 2019                [Page 2]
> 
> Internet-Draft                idloc privacy                    July 2018
> 
> 
>    Note that even if the IP address isn't always useful to track a
>    mobile device today, there are several mechanisms higher in the stack
>    which can do this.  For instance cookies or SSL sessions,
>    applications which share GPS location, or operators who offer
>    additional location information (for instance based on which cellular
>    base station a mobile device is using) to business partners.
> 
>    With that baseline in mind, let's look at what additional privacy
>    considerations can be introduced by a system which provides ID to
>    locator mappings.
> 
> 2.  Keywords and Terminology
> 
>    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
>    SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
>    document, are to be interpreted as described in [RFC2119].
The above to be updated with the new:

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP <https://tools.ietf.org/html/bcp14>
   14 <https://tools.ietf.org/html/bcp14> [RFC2119 <https://tools.ietf.org/html/rfc2119>] [RFC8174 <https://tools.ietf.org/html/rfc8174>] when, and only when, they appear in all
   capitals, as shown here.



> 3.  Assumptions
> 
>    We assume that there are benefits associated with sharing ID to
>    locator mappings with some peers sometimes.  Those benefits can be
> 
>    o  Lower latency and higher bandwidth: If two peer devices have some
>       locators which are topologically closer, then sharing all the
>       locators means that the devices can find a short path (fewer hops
>       and/or shorter round-trip time), or find a path which offer higher
>       throughput, then if the devices only shared some form of default
>       locator.
You may be interested in the reference: 

\bibitem{Jour:Li18}
Y.~Li and L.~Iannone, ``{Assessing Locator/Identifier Separation Protocol
  interworking performance through RIPE Atlas},'' in {\em Computer Networks},
  vol.~132, pp.~118 -- 128, Elsevier, February 2018.

That work show how sometimes reaching probes in China from Europe is faster using LISP rather than the normal BGP routing.
We kind of shortcut the routing infrastructure.


>    o  Higher availability and robustness: If two peer devices share all
>       their locators, then if there is some network outage the devices
>       can autonomously discover a working path using the different
>       locator pairs.

Wouldn’t make sense to to add TE? Devices can load share the traffic among different paths.

Mobility coud be another use case.

>    However, those benefits do not imply that it is a good idea to always
>    share all of the locators with everybody.  That would make tracking
>    by third parties trivial.
> 
>    A device can obfuscate itself by, instead of using a single long-
>    lived identifier, using multiple short-lived identifiers.  In that
>    case the value to the ID/locator binding for any particular
>    identifier would be lower.  However, this assumes that the device can
>    ensure unlinkablity between the different identifiers it is using
>    either concurrently or over time.  Also, some of the benefits above
>    implicitly assume that there can be some long-lived sessions or
>    associations between pairs of identifiers.  For instance, if a device
>    would need to go fetch the current identifier of its peer from some
>    remove system, then it might not experience improved robustness since
>    that fetch might depend on the failed external connectivity.  Thus we
> 
> 
> 
> Nordmark                 Expires January 3, 2019                [Page 3]
> 
> Internet-Draft                idloc privacy                    July 2018
> 
> 
>    believe that we can explore the core of the ID/locator privacy issue
>    by looking at long-lived identifiers.

It seems to me that the problem has several facets.

- IDs privacy wise short lived temporary ID is better.  
- RLOC “advertisement”. With who I share my locators? all of them? none? 
- ID-LOC association. Can someone spy on a loc to keep track of which IDs are there?

> 4.  Threats against Privacy
> 
>    This is the first version of this draft so this is very preliminary.
>    But there seems to be at least two different privacy threats relating
>    to ID/locator mapping systems.

need more meat here :-) 


> 4.1.  Location Privacy
> 
>    If a third party can at any time determine the IP location of some
>    identifier, then the device can at one point be IP geolocated at
>    home, and later a coffee shop.
> 
> 4.2.  Movement Privacy
> 
>    If a third party can determine that an identifier has changed
>    locator(s) at time T, then even without knowing the particular
>    locators before and after, it can correlate this movement event with
>    other information (e.g., security cameras) to create a binding
>    between the identifier and a person.
> 
> 5.  Not everybody all the time
> 
>    In order to see the benefits about but minimizing the privacy
>    implication one can explore limiting to which peers and when the ID/
>    locator binding are exposed.
> 
>    A few initial examples help illustrate this.
> 
> 5.1.  Optimized routing
> 
>    If some operator of a network where there is a large amount of
>    mobility wants to ensure efficient routing, then a ID/locator split
>    approach might make sense.  Such a system can potentially be limited
>    to the set of devices (routers etc) which are under the operators
>    control.  If this is the case, then the ID/locator mapping system can
>    provide access control so that only those trusted devices can access
>    the mappings.
Or… they access no mappings at all. The ID/loc split is done on the acmes network in a totally transparent manner.


>    Note that from a privacy perspective this isn't any different than
>    the same operator using a link-state routing protocol to share host
>    routes for all the mobile devices.  
Not sure i share this view.
You statement is true if you use a push based mechanism. But if you use a pull-based mechanism you end up with a totally different system.
Think about DNS…   your ID are domain names and the locators are IP addresses. 
(business is slightly different since sites that put their name in the DNS want to be reachable…) 


> In that case all participants in
>    the link-state protocol can determine the location (attached to which
>    router) and notice any mobility events.  Of course, there are
>    significant non-privacy differences between those two approaches.
> 
> 
> 
> 
> Nordmark                 Expires January 3, 2019                [Page 4]
> 
> Internet-Draft                idloc privacy                    July 2018
> 
> 
>    Exposing the ID/locator mapping to attached devices (e.g., any mobile
>    devices which wouldn't be trusted to participate in the link-state
>    routing counterpart approach), will change the privacy implications.
> 
> 5.2.  Family and Friends
> 
>    There are cases where it is quite reasonable to share location
>    information with other family members or friends.  For instance,
>    young children might run applications which enable their parents to
>    track them on their way to/from school.  And I might share my
>    location with friends so we can more easily find each other while out
>    on town.
> 
>    Today such location sharing happens at an application layer using GPS
>    coordinates.  But while such sharing is in effect, it wouldn't be
>    unreasonable to also consider sharing IP locators to make it more
>    efficient or more robust to e.g., route a video feed from one device
>    to another.
> 
> 5.3.  Business Assets
> 
>    In the area of Industrial IoT there are cases where an asset owner
>    might want to ensure that their assets can communicate efficiently
>    and robustly.  In many cases those assets might be decoupled from any
>    persons, but there can still be strong reasons to not share the ID/
>    locator binding with third parties, such as enabling competitors to
>    determine the number of deployed devices in a particular IP prefix.
I am curios about this use case. Can you make a practical example?

> 6.  Boundary between ID/locator part and rest of Internet
> 
>    If the access to the ID/locator mapping are restricted as suggested
>    above, then most of the potential peer devices would not have access
>    to the ID/locator mappings.  This means that there has to be a
>    demarcation point between the part of the network which can access
>    the ID/locator mappings for a particular identifier and the one which
>    can not.  There might be several choices how to handle this such as
>    still using an ID/locator system but pointing a locator for some
>    fixed anchor point, or injecting routing prefixes for the ID prefixes
>    into the normal routing system, or not providing any stable locators
>    across this boundary; only allow ephemeral IP addresses per session
>    or otherwise limited exposure.
Not sure what is the point of this section. It is the already mentioned issue of “what to annonce to whom”. 
Or am I missing something?



Thanks

L.