From nobody Tue Oct 2 02:09:46 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFBC130E51 for ; Tue, 2 Oct 2018 02:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm1rIVTSgIgz for ; Tue, 2 Oct 2018 02:09:32 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0DA130E21 for ; Tue, 2 Oct 2018 02:09:31 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id e4-v6so1297061wrs.0 for ; Tue, 02 Oct 2018 02:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=B9V3E3cD9rPAUQQBxoAlzmLVtYCY96Hmtwto17rnM/A=; b=HGkZQl9M6T9K4uIXVLoSyNrIdOGnvogySa8LyKJuekms/6EYRN0g9PvGzt9moR+y4O jkKGHh6l8uQgSrqXb6AmDhPNMneBhAbuuBHCIkBv+emmtRHXaz9kHZV5hmC6i2WoKswP J2j7UDAITGEUSSUUcsfmfJWDwo6L5DAZy7eJ4R6Kv33HekP93rRUCGT6cnAZUSE5OFZj xyD3iggOz0JgYWK14mwK5hDTswyHhVjFwfvvLerYKW2wolXlFmnZsjluWLxp5nkdnokj j/DG4e1e3hEQJOiT6LpiDRYebQPrA4OH0IK41+SedwLEsoVdQA4a2K0swVa5Y9ZV+Bpt ynbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=B9V3E3cD9rPAUQQBxoAlzmLVtYCY96Hmtwto17rnM/A=; b=h2/gyaiRgV+gbh7RUQS/oDQbsg9iOka0x0zt35NIu8A2GVBSxUJ3L8qOyulgxuSy/m ilgtgUT4kSNs8nPRHmBgi3f6/0vcfRM7TPImVAK44K6dG0ABNSdIO3Tf6dUSOrgMWzZn 9FRwVvVSgyPzEVoM/GAoBXIQqd0v/6qvWndA20wkDwH/YxTGKhYgXVmoLdmniDZhKMYZ SG1JMXDPH97hV2POWXKNVp9ZqiNaPyVLjFNgIYhfsqgE4s2UNsd70lkKT/W8KCaPMjxF fkcWJU3htTZ3TkY1duRIJCrhDoofwxLR08WL//MLTvydQ46BgmORwpXzA/Bdu8jMOvcZ Z3NQ== X-Gm-Message-State: ABuFfogSnlroNTXK9GB/nvS9cmzyawsQYCasbH5UxENLEs2T+JJxwPjB +OPsRTP2XCIrocHigdlbiSMaGnQRuBY= X-Google-Smtp-Source: ACcGV61H9k2zfS2rO2NF6OmzQ7FMuT9RpyyOxWi2VTBmEhd1odFfsJedkhTFK/kU7qsAgp6IU1EG+A== X-Received: by 2002:a5d:49c4:: with SMTP id t4-v6mr8069880wrs.116.1538471368653; Tue, 02 Oct 2018 02:09:28 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:a028:1c42:a674:b950? ([2001:660:330f:a4:a028:1c42:a674:b950]) by smtp.gmail.com with ESMTPSA id b83-v6sm11065404wmh.16.2018.10.02.02.09.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 02:09:27 -0700 (PDT) From: Luigi Iannone Message-Id: <1591EDB8-E72D-4582-8393-1458232162F9@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_8C3A7CA1-BE8D-429B-B76E-3CFEFB483202" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Tue, 2 Oct 2018 11:09:30 +0200 In-Reply-To: Cc: pidloc@ietf.org To: sarikaya@ieee.org References: X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Pidloc] Let's start X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 09:09:43 -0000 --Apple-Mail=_8C3A7CA1-BE8D-429B-B76E-3CFEFB483202 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = wrote: >=20 > Folks, >=20 > As the summer is over, it is time to=20 > start talking about our favorite subject, IdLoc protocols and privacy = issues. >=20 > As you may know, Erik Nordmark published a draft: > https://www.ietf.org/id/draft-nordmark-id-loc-privacy-00.txt = >=20 > in July 2018 just before IETF 102 in Montreal.=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Our goal currently is to go for a BoF in IETF 104 in Prague. >=20 > 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 = >=20 > Thanks, >=20 > Behcet & Dirk > =20 > --=20 > Pidloc mailing list > Pidloc@ietf.org > https://www.ietf.org/mailman/listinfo/pidloc >=20 >=20 >=20 >=20 > Network Working Group E. = Nordmark > Internet-Draft = Zededa > Intended status: Standards Track July 2, = 2018 > Expires: January 3, 2019 >=20 >=20 > Privacy issues in ID/locator separation systems > draft-nordmark-id-loc-privacy-00 >=20 > Abstract >=20 > 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. >=20 > Status of This Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > 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/. >=20 > 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." >=20 > This Internet-Draft will expire on January 3, 2019. >=20 > Copyright Notice >=20 > Copyright (c) 2018 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > 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. >=20 >=20 >=20 > Nordmark Expires January 3, 2019 [Page = 1] > =0C > Internet-Draft idloc privacy July = 2018 >=20 >=20 > Table of Contents >=20 > 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 >=20 > 1. Introduction >=20 > 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. =20 There is an important assumption here, namely that everything is IP. Wouldn=E2=80=99t make more sense to have a general discussion were = IP-based ID/loc separation is just=20 one case? Or there is a specific reason for this?=20 > 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.=20 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. >=20 > 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.=20 something wrong in the sentence above =E2=80=A6 may be =E2=80=9Cthat it = is the same mobile device=E2=80=9D... > 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. >=20 >=20 >=20 > Nordmark Expires January 3, 2019 [Page = 2] > =0C > Internet-Draft idloc privacy July = 2018 >=20 >=20 > 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. >=20 > 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. >=20 > 2. Keywords and Terminology >=20 > 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 = 14 [RFC2119 = ] [RFC8174 = ] when, and only when, they appear = in all capitals, as shown here. > 3. Assumptions >=20 > We assume that there are benefits associated with sharing ID to > locator mappings with some peers sometimes. Those benefits can be >=20 > 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:=20 \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=E2=80=99t 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. >=20 > 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 >=20 >=20 >=20 > Nordmark Expires January 3, 2019 [Page = 3] > =0C > Internet-Draft idloc privacy July = 2018 >=20 >=20 > 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. =20 - RLOC =E2=80=9Cadvertisement=E2=80=9D. With who I share my locators? = all of them? none?=20 - ID-LOC association. Can someone spy on a loc to keep track of which = IDs are there? > 4. Threats against Privacy >=20 > 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 :-)=20 > 4.1. Location Privacy >=20 > 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. >=20 > 4.2. Movement Privacy >=20 > 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. >=20 > 5. Not everybody all the time >=20 > 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. >=20 > A few initial examples help illustrate this. >=20 > 5.1. Optimized routing >=20 > 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=E2=80=A6 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. =20 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=E2=80=A6 your ID are domain names and the locators are = IP addresses.=20 (business is slightly different since sites that put their name in the = DNS want to be reachable=E2=80=A6)=20 > 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. >=20 >=20 >=20 >=20 > Nordmark Expires January 3, 2019 [Page = 4] > =0C > Internet-Draft idloc privacy July = 2018 >=20 >=20 > 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. >=20 > 5.2. Family and Friends >=20 > 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. >=20 > 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. >=20 > 5.3. Business Assets >=20 > 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 >=20 > 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 =E2=80=9Cwhat to annonce to whom=E2=80=9D.=20 Or am I missing something? Thanks L. --Apple-Mail=_8C3A7CA1-BE8D-429B-B76E-3CFEFB483202 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 = <sarikaya2012@gmail.com> 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

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

Thanks,

Behcet & Dirk
 
--
Pidloc mailing list
Pidloc@ietf.org
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]
=0C
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=E2=80=99t 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 =E2=80=A6 may = be =E2=80=9Cthat it is the same mobile device=E2=80=9D...
 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]
=0C
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
   14 [RFC2119] [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=E2=80=99t 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]
=0C
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 = =E2=80=9Cadvertisement=E2=80=9D. 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=E2=80=A6 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=E2=80=A6   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=E2=80=A6) 


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]
=0C
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 =E2=80=9Cwhat to annonce = to whom=E2=80=9D. 
Or am I missing = something?



Thanks

L.

= --Apple-Mail=_8C3A7CA1-BE8D-429B-B76E-3CFEFB483202-- From nobody Thu Oct 4 08:02:28 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E254130E3C for ; Thu, 4 Oct 2018 08:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmSa_XhIxQAn for ; Thu, 4 Oct 2018 08:02:25 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54EC8130DFB for ; Thu, 4 Oct 2018 08:02:25 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id e187-v6so1891115wmf.0 for ; Thu, 04 Oct 2018 08:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=VYO4BPUkpmuZodd7V3b7zvArs4Sgp+FfL1kmvdCjScM=; b=uMXH7aU03GhFKbqEw9V4+KGtP2tZY0LvGUhoyoExdfRRlVv9WN7O9SkJGGiqUQBfhd y+zSpmvSozVGOgtTUeqCNQhEHF5XNMQh8R6wDxKFj+tT2b+o42DTEXfYRsNuflJ/vObo RsxZT6Qol+nKcTeUSTTDQ2ebigHrAgLufkdRdO30cixmNCiZKDcDc+fFNIrVH7gzvfTB l21eoANjqUXQxChphY9PXytgI/3l5jFA5xFeo6hS6ZxecrIkSlOs4dWocBHhqwoLVwwN aWgActRdSc4IwyQQ/ukkUsTNycsqbcXhaUNz72S2rLrkw393ByQCf3IkdSKebvMXLLCc yz4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=VYO4BPUkpmuZodd7V3b7zvArs4Sgp+FfL1kmvdCjScM=; b=aK8StZ7q5gQxtsDkCmHJ+j4Ae5ScadQE00d14r0++NXKImpY9KPLZjMYoH/YPQNaFo 9kYCDwccLszyKb2E6lK+47sgbvagxtclJKLNzThoBGUxfvi359nyj0rR9JhhF39ddaJy TWt6lzmhwyvFWIYsWGAeaFyAXzslrczwy5S6UGIDwCC5eGA0NWtNwo0B2kPYctmB28gc x5Kw2X/kZKJVNSpXWIqb9R507T2eDv6TC5nodjyO7b7ZTWQNa3o+QoiuJHxPhFvB4DP6 Y38s9E7p4PxtZXt9JgRpVIebH0ojxB5sFBoRrZ1SH2uipDrKJXfBxUkmyiJQodR1V5dj 9qHg== X-Gm-Message-State: ABuFfogrfG403HqxS4CZSHCMJZ8OKj3CQK7lrXah/dtsukjYFaIKXzfu vl/HsHVylU39vN/+RXnYh6TLPikIKTwSJ/DevInedT/N X-Google-Smtp-Source: ACcGV60Eez7TVCJf4HY4+sP+XUAa+dHeDb9mT3PrdRhirf0xZSMfPV4G4UvPerTL1OA7c3aq4TCHz1YtKHPkTdWYYAU= X-Received: by 2002:a1c:8a94:: with SMTP id m142-v6mr4951416wmd.80.1538665343611; Thu, 04 Oct 2018 08:02:23 -0700 (PDT) MIME-Version: 1.0 Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Thu, 4 Oct 2018 10:02:12 -0500 Message-ID: To: pidloc@ietf.org Content-Type: multipart/alternative; boundary="0000000000003bf7e405776871a0" Archived-At: Subject: [Pidloc] draft-nordmark-id-loc-privacy X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 15:02:27 -0000 --0000000000003bf7e405776871a0 Content-Type: text/plain; charset="UTF-8" Hi Luigi, Dirk, all, So far we have a number of reviews on Erik's draft indicating some editorial issues and asking for clarification of some parts. All that is good. What I suggest is that we should also look into what he is saying in that draft, what is he suggesting as the future work to do? Here I am going to summary what I could find out: - We should concentrate on long-lived identifiers; - Worry not much on designing a privacy based unified mapping mapping system which we had concentrated in our previous activity. This is because only trusted devices can access the mappings in an operator network - Instead worry about minimizing the privacy implication one can explore limiting to which peers and when the ID/ locator binding are exposed. The cases where ID/locator bindings are exposed (especially any mobile devices) - Family and friends for example where are parents sharing young children location - In industrial IoT case, the devices belonging to the same company share ID/locator bindings but not share the ID/locator binding with third parties In Section 6, the draft points to some possibilities on how this limiting can be achieved: 1. pointing a locator for some fixed anchor point, like PGW or UPF 2. injecting routing prefixes for the ID prefixes into the normal routing system 3. not providing any stable locators across this boundary; only allow ephemeral IP addresses per session or otherwise limited exposure. In short, the draft is coming up with a lot work to do. We suggest that the group takes a close look into all these points and see what we can do :-) Regards, Behcet & Dirk --0000000000003bf7e405776871a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Luigi, Dirk= , all,

S= o far we have a number of reviews on Erik's draft indicating some edito= rial issues and asking for clarification of some parts. All that is good.= =C2=A0

What I suggest is that we should also look into what he is saying in= that draft, what is he suggesting as the future work to do?

Here I am going = to summary what I could find out:

- We should concentrate on long-lived ident= ifiers;

- Worry not much on designing a privacy based unified mapping mappin= g system which we had concentrated in our previous activity. This is becaus= e=C2=A0only trusted d= evices can access the mappings=C2=A0 in an operator network=C2=A0

- Instead worry a= bout=C2=A0minimizing = the privacy im= plication one can explore limiting to which peers and when the ID/ locator binding are ex= posed.

<= span style=3D"color:rgb(0,0,0);white-space:pre-wrap">The cases where ID/loc= ator bindings are exposed (especially any mobile devices)
- Family and friends for = example where are parents sharing young children location
- In industrial IoT case, the devices belonging to the same company shar= e ID/locator b= indings but no= t share the ID/locator binding with third parties

<= /div>
In Section 6, the draft points to some possibilities on how this lim= iting can be achieved:

1. poin= ting a locator for some fixed anchor point, like PGW or UPF

2. injecting routing prefixes for the ID prefixes into the normal routing= system

<= span style=3D"color:rgb(0,0,0);white-space:pre-wrap">3. not providing any = stable locators across this boundary; only allow ephemeral IP addresses per session or otherwise limite= d exposure.

= In short, the draft is coming up with a lot work to do.
We suggest that the group takes a close loo= k into all these points and see what we can do :-)
Regards,
Behcet & Dirk
=
--0000000000003bf7e405776871a0-- From nobody Thu Oct 4 11:15:53 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1341C130D7A for ; Thu, 4 Oct 2018 11:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56CPKSJrHGpW for ; Thu, 4 Oct 2018 11:15:49 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04AB1252B7 for ; Thu, 4 Oct 2018 11:15:49 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id l191-v6so14449969ita.4 for ; Thu, 04 Oct 2018 11:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CQQndy9+0KyyPp8i62A+2Kk3tJVss7Ew+93GlS+r80Q=; b=LBLyM98qbZ1kU2FasHZQ7rFFuCdNkh+MVrY6BcUkjMzjYldpHDGM/133olBE8si28/ x1CAwiA5AAt6aICtJ1QTuC8/9mT1/zMgdX4oA+kyAUQQPwfxlIg366bdkRYEZsVAxAj4 XhKiYIs7BDCiOknGmfhF6H5Uk30IPJ6DIK7pOQhxF0NQanm3Q6IFvdMEgZxfBKfEzoDR 3uJAa5FXdLL6mr5hWzwIKB3yks3L2XmTNabi2hmt1WtX8PS6xFG+BaDBUvDRD73Ygv7D JRK1epaI3qFjmn2VjdAaRVjb/FaNrg8+j9DIqEIVlzdmkqybj4rd6uvT3eU+HqAgGoKW 5cwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CQQndy9+0KyyPp8i62A+2Kk3tJVss7Ew+93GlS+r80Q=; b=QXxDIAH+gEZ49Xisl6VlEuiB5CFtBE5snUx24lre5AXg2SMKQgIYg/1+K59rfd/W6P 5/m0H7UAEYD4ubChpDJTtX7Q8AjzK4oigRAFjR9w1zqm3BQMT6OadSLzcKCoKlLaIkgp NDxDD7JHVxhMFzq+Pvlm59YiC+4/FHltTD+nZznUBEmu2YF/aC/qZlAuklDmcfsEhYAR +KTxtOimqHE2kXNCUKuNKErW3ipim9mrPZaAEJKN3DxvNAriNO8LhKGq6hyKh5TgDan4 2ADAx03diXZc/cFiHoMTXetnIgHBGtdZI1YReHFcmoBvYxQ39ou4w2lyu4w+vmgV6Onr 402A== X-Gm-Message-State: ABuFfoi9HOqXebQMRprZTBrqecpIO+Bb75HHv1M4LaBR0oroWZCVFOYX B7tgE5I+q/YETEI9Loxf+PoezqcYv1xnJq/ab05dKg== X-Google-Smtp-Source: ACcGV62vdMrMy1Tctjjw7ldAvsrt4kM+PyU4eTXM3NvvgFxUrT5xIQFYZTRGPG50aqU+gVM1M2QewqOj+5RQoyMZQzA= X-Received: by 2002:a24:3c0a:: with SMTP id m10-v6mr1616310ita.15.1538676948757; Thu, 04 Oct 2018 11:15:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:7a59:0:0:0:0:0 with HTTP; Thu, 4 Oct 2018 11:15:48 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Thu, 4 Oct 2018 11:15:48 -0700 Message-ID: To: Behcet Sarikaya Cc: pidloc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Pidloc] draft-nordmark-id-loc-privacy X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 18:15:52 -0000 On Thu, Oct 4, 2018 at 8:02 AM, Behcet Sarikaya wrote: > Hi Luigi, Dirk, all, > > So far we have a number of reviews on Erik's draft indicating some editorial > issues and asking for clarification of some parts. All that is good. > > What I suggest is that we should also look into what he is saying in that > draft, what is he suggesting as the future work to do? > > Here I am going to summary what I could find out: > > - We should concentrate on long-lived identifiers; > > - Worry not much on designing a privacy based unified mapping mapping system > which we had concentrated in our previous activity. This is because only > trusted devices can access the mappings in an operator network > > - Instead worry about minimizing the privacy implication one can explore > limiting to which peers and when the ID/ locator binding are exposed. > > The cases where ID/locator bindings are exposed (especially any mobile > devices) > - Family and friends for example where are parents sharing young children > location I don't believe this case is relevant. There's already applications that I can use to track my kids (like Life360). These use the GPS in mobile devices and secure connections to trasmit location information; it's far more accurate and secure than trying to deriving location information from a few bits in an IP address. I think it's a hard requirement that Identifiers (IP addresses in general) must not expose geo location or mobile devices, and it follows that identifier/locator bindings should never be shared outside a network except LEA orders. Tom > - In industrial IoT case, the devices belonging to the same company share > ID/locator bindings but not share the ID/locator binding with third parties > > In Section 6, the draft points to some possibilities on how this limiting > can be achieved: > > 1. pointing a locator for some fixed anchor point, like PGW or UPF > > 2. injecting routing prefixes for the ID prefixes into the normal routing > system > > 3. not providing any stable locators across this boundary; only allow > ephemeral IP addresses per session or otherwise limited exposure. > > In short, the draft is coming up with a lot work to do. > We suggest that the group takes a close look into all these points and see > what we can do :-) > Regards, > Behcet & Dirk > > -- > Pidloc mailing list > Pidloc@ietf.org > https://www.ietf.org/mailman/listinfo/pidloc > From nobody Fri Oct 5 07:24:34 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B810128CF3 for ; Fri, 5 Oct 2018 07:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFe2bmeBFPgA for ; Fri, 5 Oct 2018 07:24:30 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1837124C04 for ; Fri, 5 Oct 2018 07:24:29 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id y140-v6so3887156wmd.0 for ; Fri, 05 Oct 2018 07:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=y0NZij1Ry3qxBOTEnX2IC6OkxJJFjid9EIJUZFSTlVk=; b=vFD6x+bs1S4BdQ9MUfPGJFkSuKJ7rPBCTgpflUbJ1T01OBS4sSr9jNiGRLMZOpwut6 g3NQqiZlqLSh+p6277YHi08qXOhyTYH+KszWHopgLKnOA/jMzuZacDPfNTf/2CZ5zMl8 eALjKmNFGhqImxEqv1meyVu+2Qi1coyz/1koQIJsW0AP3L6U7QyPslJ5ZIpjGgelv9Jd 8XS7bqSoFjBQdTRfIi43uLJjG+WFfN9cTouK1l6XuANgc8ByyAwN0PQ0dO/WvUiCgKXj 6XS+UoasfVWCGcJbYifPMNKxVF6cSipV6km5Npb2LcnERWThljw9fXO5yqJQx/Ex1qer R0dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=y0NZij1Ry3qxBOTEnX2IC6OkxJJFjid9EIJUZFSTlVk=; b=ld9tDrnyL0ElyAcTyfU4cflXMOutzZs9MP0j5rhMHEx8ZGABnZYPet8oOTggyoa/Hg 8KKktMPV00AqDPiGVmQghVuh2BbXFyagVPFoXJLZ5Ha59fu4BQ9OnkB20QFTHGXm6Cfl /07TJi3+dn+31STbnY0vSdcf/dHaBUKzdCNqkr4w1dnWcMM0qyrGxfp9Ve4SN6zYNTvG HnO03zJgal+jLoZKpWvND4vroKBnGcSsVklGjw83ksUZoMkM4sInVWJZ0Ac3QEVJC5un d7YsbmN2BuHsG1I/BP7TS+yJ/PD7XeyiN9b1J0p2rOoBztJ1GCWVSQyuSqPVh4b5FnM7 5O4Q== X-Gm-Message-State: ABuFfoigCymgvtQEjLvLeo4f1NJnn0FmwVBp7CcG5AhBnvAJx00hGrgs hqExSDxm6otZ89eaLeJT7oQXBaxDHkz9hWJZMmfeevK6 X-Google-Smtp-Source: ACcGV62USIE2Uymvwu+ZZhPQPIV1iDfS81Zjyme6BuEdP7Cb3EnHDXwy5+apP8A2Qk4xqgtvyjI26BuvNffKEgAMpbI= X-Received: by 2002:a1c:3c4:: with SMTP id 187-v6mr7611738wmd.90.1538749468012; Fri, 05 Oct 2018 07:24:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Fri, 5 Oct 2018 09:24:16 -0500 Message-ID: To: Tom Herbert Cc: sarikaya@ieee.org, pidloc@ietf.org Content-Type: multipart/alternative; boundary="00000000000070751005777c07c4" Archived-At: Subject: Re: [Pidloc] draft-nordmark-id-loc-privacy X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 14:24:32 -0000 --00000000000070751005777c07c4 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 4, 2018 at 1:15 PM Tom Herbert wrote: > On Thu, Oct 4, 2018 at 8:02 AM, Behcet Sarikaya > wrote: > > Hi Luigi, Dirk, all, > > > > So far we have a number of reviews on Erik's draft indicating some > editorial > > issues and asking for clarification of some parts. All that is good. > > > > What I suggest is that we should also look into what he is saying in that > > draft, what is he suggesting as the future work to do? > > > > Here I am going to summary what I could find out: > > > > - We should concentrate on long-lived identifiers; > > > > - Worry not much on designing a privacy based unified mapping mapping > system > > which we had concentrated in our previous activity. This is because only > > trusted devices can access the mappings in an operator network > > > > - Instead worry about minimizing the privacy implication one can explore > > limiting to which peers and when the ID/ locator binding are exposed. > > > > The cases where ID/locator bindings are exposed (especially any mobile > > devices) > > - Family and friends for example where are parents sharing young children > > location > > I don't believe this case is relevant. There's already applications > that I can use to track my kids (like Life360). These use the GPS in > mobile devices and secure connections to trasmit location information; > it's far more accurate and secure than trying to deriving location > information from a few bits in an IP address. Yes, this has already been alluded to in the draft: Today such location sharing happens at an application layer using GPS coordinates. I think it's a hard > requirement that Identifiers (IP addresses in general) must not expose > geo location or mobile devices, and it follows that identifier/locator > bindings should never be shared outside a network except LEA orders. > > Here is the rest of the above paragraph I quoted from Erik's draft: 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. What do you think? Behcet Tom > > > - In industrial IoT case, the devices belonging to the same company share > > ID/locator bindings but not share the ID/locator binding with third > parties > > > > In Section 6, the draft points to some possibilities on how this limiting > > can be achieved: > > > > 1. pointing a locator for some fixed anchor point, like PGW or UPF > > > > 2. injecting routing prefixes for the ID prefixes into the normal routing > > system > > > > 3. not providing any stable locators across this boundary; only allow > > ephemeral IP addresses per session or otherwise limited exposure. > > > > In short, the draft is coming up with a lot work to do. > > We suggest that the group takes a close look into all these points and > see > > what we can do :-) > > Regards, > > Behcet & Dirk > > > > -- > > Pidloc mailing list > > Pidloc@ietf.org > > https://www.ietf.org/mailman/listinfo/pidloc > > > --00000000000070751005777c07c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 4, 2018 at 1:15 PM Tom Herbert <= tom@quantonium.net> wrote:
=
On Thu, Oct 4, 2018 at 8:02 AM, Behcet Sarikaya <= sarikaya2012@gm= ail.com> wrote:
> Hi Luigi, Dirk, all,
>
> So far we have a number of reviews on Erik's draft indicating some= editorial
> issues and asking for clarification of some parts. All that is good. >
> What I suggest is that we should also look into what he is saying in t= hat
> draft, what is he suggesting as the future work to do?
>
> Here I am going to summary what I could find out:
>
> - We should concentrate on long-lived identifiers;
>
> - Worry not much on designing a privacy based unified mapping mapping = system
> which we had concentrated in our previous activity. This is because on= ly
> trusted devices can access the mappings=C2=A0 in an operator network >
> - Instead worry about minimizing the privacy implication one can explo= re
> limiting to which peers and when the ID/ locator binding are exposed.<= br> >
> The cases where ID/locator bindings are exposed (especially any mobile=
> devices)
> - Family and friends for example where are parents sharing young child= ren
> location

I don't believe this case is relevant. There's already applications=
that I can use to track my kids (like Life360). These use the GPS in
mobile devices and secure connections to trasmit location information;
it's far more accurate and secure than trying to deriving location
information from a few bits in an IP address.

<= div>Yes, this has already =C2=A0been alluded to in the draft:
Toda= y such location sharing happens at an application layer using GPS coordinates.

I think it's a h= ard
requirement that Identifiers (IP addresses in general) must not expose
geo location or mobile devices, and it follows that identifier/locator
bindings should never be shared outside a network except LEA orders.


Here is the rest of the above paragrap= h I quoted from Erik's draft:

But while such sh=
aring 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.

What do you think?
=

Behcet
=
Tom

> - In industrial IoT case, the devices belonging to the same company sh= are
> ID/locator bindings but not share the ID/locator binding with third pa= rties
>
> In Section 6, the draft points to some possibilities on how this limit= ing
> can be achieved:
>
> 1. pointing a locator for some fixed anchor point, like PGW or UPF
>
> 2. injecting routing prefixes for the ID prefixes into the normal rout= ing
> system
>
> 3. not providing any stable locators across this boundary; only allow<= br> > ephemeral IP addresses per session or otherwise limited exposure.
>
> In short, the draft is coming up with a lot work to do.
> We suggest that the group takes a close look into all these points and= see
> what we can do :-)
> Regards,
> Behcet & Dirk
>
> --
> Pidloc mailing list
> Pidloc@ietf.org
> https://www.ietf.org/mailman/listinfo/pidloc >
--00000000000070751005777c07c4-- From nobody Fri Oct 5 07:54:18 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EC0130DDF for ; Fri, 5 Oct 2018 07:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daPVFA0S4NGt for ; Fri, 5 Oct 2018 07:54:14 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED555130DC6 for ; Fri, 5 Oct 2018 07:54:13 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id y10-v6so10859594ioa.10 for ; Fri, 05 Oct 2018 07:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CjxDucb+FHbbTv+R5Jl84Tel8ozpxU0bCuYUTrmcdPM=; b=toRVkNhlwuNat2ikWfWngL+JGsIEYiP30YkYiKAlf812hi54oQA/3IrV2uHb5rzd2b TmyqMuySfR7qAhgbz0Y8JEENbPCFZNpcpbLrDg1KKgCAEujX7tVHRirIvqmrZ87vlvV8 yQfbtHQkB8+bjse85a0xx1MebwwBrv63V63Bi4q3IiFumWaUVHOmR/MDi/w32e5XA9Om UCXCoRQort//7WCf3ROuVi488vQJ5AIv2I/E2zmxbYmmC4yTEcNTLj9TsVi8rIPPmgpF S8pv8WH6LKQo7c59gn7BhVHqDckRsRz1Equ3XHNiSFQ8zjvuje5IWmi3mfCGXXpjUORC FT9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CjxDucb+FHbbTv+R5Jl84Tel8ozpxU0bCuYUTrmcdPM=; b=mi5PNaK4oazXJ+4/m3OJ7QWWTO4Nshbg5ET6R9y4tIE9s0JPftstOwZkWyv+A7MM6H F0RbdDWhTUELuZ47kCx+SoCaCpn43JCrKnG5UY9VPkIpwk1G6q5OnvBL4Op/qJ5MNZWY PCqx+udMuTVv9NPZ0d3B81cOFp6SBtnPmBXaTAD2oOPYoYi2DG3mExzDkeBQr1aqQyfu cof/DqdnZax9W2ZmJWnMlqAs9t8OJkCNmRAH+QTcYZh4DIfgJ6DiV6lAg9fud04bpDsi kYcfyOVkOcIuYyyym7WxFsgRFv1bF/U44KUYjx+cS4YhB/LZt8J8XgXxDrFTwitA0VL9 L0Ew== X-Gm-Message-State: ABuFfoh9LuzK4bKZ/K57MC7fdb51QCLmeiHgRXbSbc0nN5/9BDIf01gc a7kAMZXNLbZEz7pe2BtahGbHQ6KDKr8+7kq6sEzWYg== X-Google-Smtp-Source: ACcGV60xTC0HXTOYV5u+CoqLnQWb1Pb7SbuWTGyXHJqOHGQBMlCBTXa+5laTx43CohIGUJQAiGzNhg2pV003X1EX0+U= X-Received: by 2002:a6b:18c5:: with SMTP id 188-v6mr8045988ioy.211.1538751253003; Fri, 05 Oct 2018 07:54:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:7a59:0:0:0:0:0 with HTTP; Fri, 5 Oct 2018 07:54:12 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Fri, 5 Oct 2018 07:54:12 -0700 Message-ID: To: Behcet Sarikaya Cc: pidloc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Pidloc] draft-nordmark-id-loc-privacy X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 14:54:17 -0000 On Fri, Oct 5, 2018 at 7:24 AM, Behcet Sarikaya wrote: > > > On Thu, Oct 4, 2018 at 1:15 PM Tom Herbert wrote: >> >> On Thu, Oct 4, 2018 at 8:02 AM, Behcet Sarikaya >> wrote: >> > Hi Luigi, Dirk, all, >> > >> > So far we have a number of reviews on Erik's draft indicating some >> > editorial >> > issues and asking for clarification of some parts. All that is good. >> > >> > What I suggest is that we should also look into what he is saying in >> > that >> > draft, what is he suggesting as the future work to do? >> > >> > Here I am going to summary what I could find out: >> > >> > - We should concentrate on long-lived identifiers; >> > >> > - Worry not much on designing a privacy based unified mapping mapping >> > system >> > which we had concentrated in our previous activity. This is because only >> > trusted devices can access the mappings in an operator network >> > >> > - Instead worry about minimizing the privacy implication one can explore >> > limiting to which peers and when the ID/ locator binding are exposed. >> > >> > The cases where ID/locator bindings are exposed (especially any mobile >> > devices) >> > - Family and friends for example where are parents sharing young >> > children >> > location >> >> I don't believe this case is relevant. There's already applications >> that I can use to track my kids (like Life360). These use the GPS in >> mobile devices and secure connections to trasmit location information; >> it's far more accurate and secure than trying to deriving location >> information from a few bits in an IP address. > > > Yes, this has already been alluded to in the draft: > > Today such location sharing happens at an application layer using GPS > coordinates. > > >> I think it's a hard >> requirement that Identifiers (IP addresses in general) must not expose >> geo location or mobile devices, and it follows that identifier/locator >> bindings should never be shared outside a network except LEA orders. >> > > Here is the rest of the above paragraph I quoted from Erik's draft: > > 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. > > > What do you think? Sure, it could be considered, but the benefits of exposing a third party to identifier/locator mappings would have to be weighed against the cost. The potential cost is weakened user privacy and security. Locators will convey geo location in a mobile network, so if someone knows identifier to locator mapping, then they know location of node with that identifier. But more than that, knowledge of identifier/locator mappings allow correlations to be made between identifiers. For instance, if a device is using some number of untrackable and uncorrelatable identifiers for privacy, knowledge of identifier to locator mappings allows correlations to be made and the identifiers that belong to the device can be deduced and the users can be tracked. Tom > > > Behcet >> >> Tom >> >> > - In industrial IoT case, the devices belonging to the same company >> > share >> > ID/locator bindings but not share the ID/locator binding with third >> > parties >> > >> > In Section 6, the draft points to some possibilities on how this >> > limiting >> > can be achieved: >> > >> > 1. pointing a locator for some fixed anchor point, like PGW or UPF >> > >> > 2. injecting routing prefixes for the ID prefixes into the normal >> > routing >> > system >> > >> > 3. not providing any stable locators across this boundary; only allow >> > ephemeral IP addresses per session or otherwise limited exposure. >> > >> > In short, the draft is coming up with a lot work to do. >> > We suggest that the group takes a close look into all these points and >> > see >> > what we can do :-) >> > Regards, >> > Behcet & Dirk >> > >> > -- >> > Pidloc mailing list >> > Pidloc@ietf.org >> > https://www.ietf.org/mailman/listinfo/pidloc >> > From nobody Fri Oct 5 08:10:14 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE74B130DFF for ; Fri, 5 Oct 2018 08:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihGCpersOUSo for ; Fri, 5 Oct 2018 08:10:10 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230A9124BE5 for ; Fri, 5 Oct 2018 08:10:10 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id x12-v6so13911617wru.8 for ; Fri, 05 Oct 2018 08:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=+tsKzT75q5olPYTj+8bdDGdTwr4/KOm+hOIl59qD2sY=; b=DhwODe1PaQgoSvD+R1DgY1RW036KRUd+qZNcfoUSZ0T41Ux0oLAmcmXDPx6dhr1os+ 17iYq+cODca7tnJWVs7qPFQcvTVU6PbFeP5rqYDwQbrcuhmHpiJJQdtxFtLX0ed1JgBF AAQLeFcVgSURYgbCVwOFCbg47eXdmiUooPFIF8NdDw+cpmP2CGWmAqY+ZdLKVA5lOzZX mWB1PmK68ZTB9mgw7aOs+STb3LnhVIykolvFzTyU0Jp2MBMAvuXzZgmIqF2BJABKxY2k OghX9liw4ma6jTJAcdhEmHE3dArgsbTqCtS3QpBTQJj+1kfwV2h4fz62HAunGfMFeZyQ igqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=+tsKzT75q5olPYTj+8bdDGdTwr4/KOm+hOIl59qD2sY=; b=TW4R4sdW6beh/k+XLUT+jJdtEJwMVv9jOY5eJ7bonUrt0IzjgPGEjdZZVvQJ2lBeyw 96Q/puqciaUkbFOuGZCUiF6syib3HZOTiqmthumV37SWraK+HxV2APIXtk0PDxbDf5ka xnOdcJZsq3GWakxycvu5LgLujOGAnQWtFkB0V+/+IOi58myekvYcFRCXBe6MPW0MzZd8 n771byU6Km5oxIl/NVLufJIdRPsDerdeZduNFXaFLzLpSI9HgD1To7Erb0RMUz9NZnHB NoEZfACL0YGe/DvJefSQB+DfBgl1lNMLkgPaC7Goi4FKBPqFbELmcB7zufDuaYvJ/PAR B5+g== X-Gm-Message-State: ABuFfohMB9d/4Zx5xsHtt8hpTsTQwKZa/gImhhavVKkUywUuXemZ7Me9 x40xD+Zoew6/Z6HSyDavaSIUJozC0bJOoV8HJRRUQQ== X-Google-Smtp-Source: ACcGV63ii4/n1p+tV5g6WetzvnFuMEAZ2oaOpiUGHbj/D79kvLlBJA0XVgDvNPunZFP7vhtred1n9QYOv5yS7YrYTUM= X-Received: by 2002:adf:e784:: with SMTP id n4-v6mr9261981wrm.187.1538752208601; Fri, 05 Oct 2018 08:10:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Fri, 5 Oct 2018 10:09:57 -0500 Message-ID: To: Tom Herbert Cc: pidloc@ietf.org Content-Type: multipart/alternative; boundary="000000000000ca870405777caaf9" Archived-At: Subject: Re: [Pidloc] draft-nordmark-id-loc-privacy X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 15:10:13 -0000 --000000000000ca870405777caaf9 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 5, 2018 at 9:54 AM Tom Herbert wrote: > On Fri, Oct 5, 2018 at 7:24 AM, Behcet Sarikaya > wrote: > > > > > > On Thu, Oct 4, 2018 at 1:15 PM Tom Herbert wrote: > >> > >> On Thu, Oct 4, 2018 at 8:02 AM, Behcet Sarikaya > > >> wrote: > >> > Hi Luigi, Dirk, all, > >> > > >> > So far we have a number of reviews on Erik's draft indicating some > >> > editorial > >> > issues and asking for clarification of some parts. All that is good. > >> > > >> > What I suggest is that we should also look into what he is saying in > >> > that > >> > draft, what is he suggesting as the future work to do? > >> > > >> > Here I am going to summary what I could find out: > >> > > >> > - We should concentrate on long-lived identifiers; > >> > > >> > - Worry not much on designing a privacy based unified mapping mapping > >> > system > >> > which we had concentrated in our previous activity. This is because > only > >> > trusted devices can access the mappings in an operator network > >> > > >> > - Instead worry about minimizing the privacy implication one can > explore > >> > limiting to which peers and when the ID/ locator binding are exposed. > >> > > >> > The cases where ID/locator bindings are exposed (especially any mobile > >> > devices) > >> > - Family and friends for example where are parents sharing young > >> > children > >> > location > >> > >> I don't believe this case is relevant. There's already applications > >> that I can use to track my kids (like Life360). These use the GPS in > >> mobile devices and secure connections to trasmit location information; > >> it's far more accurate and secure than trying to deriving location > >> information from a few bits in an IP address. > > > > > > Yes, this has already been alluded to in the draft: > > > > Today such location sharing happens at an application layer using GPS > > coordinates. > > > > > >> I think it's a hard > >> requirement that Identifiers (IP addresses in general) must not expose > >> geo location or mobile devices, and it follows that identifier/locator > >> bindings should never be shared outside a network except LEA orders. > >> > > > > Here is the rest of the above paragraph I quoted from Erik's draft: > > > > 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. > > > > > > What do you think? > > Sure, it could be considered, but the benefits of exposing a third > party to identifier/locator mappings would have to be weighed against > the cost. The potential cost is weakened user privacy and security. > Locators will convey geo location in a mobile network, so if someone > knows identifier to locator mapping, then they know location of node > with that identifier. But more than that, knowledge of > identifier/locator mappings allow correlations to be made between > identifiers. For instance, if a device is using some number of > untrackable and uncorrelatable identifiers for privacy, knowledge of > identifier to locator mappings allows correlations to be made and the > identifiers that belong to the device can be deduced and the users can > be tracked. > > Absolutely. One reason why I posted this mail was to encourage the discussion of solution approaches in different IdLoc protocols. How could we treat each of cases of Family and Friends, Industrial IoT, etc. in ILA, ILNP, and LISP? What about the three points in Section 6? Behcet > > --000000000000ca870405777caaf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Oct 5, 2018 at 9:54 AM Tom Herbert <tom@quantonium.net> wrote:
On Fri, Oct 5, 2018 at 7:24 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wrot= e:
>
>
> On Thu, Oct 4, 2018 at 1:15 PM Tom Herbert <tom@quantonium.net> wrote:
>>
>> On Thu, Oct 4, 2018 at 8:02 AM, Behcet Sarikaya <sarikaya2012@gmail.com>= ;
>> wrote:
>> > Hi Luigi, Dirk, all,
>> >
>> > So far we have a number of reviews on Erik's draft indica= ting some
>> > editorial
>> > issues and asking for clarification of some parts. All that i= s good.
>> >
>> > What I suggest is that we should also look into what he is sa= ying in
>> > that
>> > draft, what is he suggesting as the future work to do?
>> >
>> > Here I am going to summary what I could find out:
>> >
>> > - We should concentrate on long-lived identifiers;
>> >
>> > - Worry not much on designing a privacy based unified mapping= mapping
>> > system
>> > which we had concentrated in our previous activity. This is b= ecause only
>> > trusted devices can access the mappings=C2=A0 in an operator = network
>> >
>> > - Instead worry about minimizing the privacy implication one = can explore
>> > limiting to which peers and when the ID/ locator binding are = exposed.
>> >
>> > The cases where ID/locator bindings are exposed (especially a= ny mobile
>> > devices)
>> > - Family and friends for example where are parents sharing yo= ung
>> > children
>> > location
>>
>> I don't believe this case is relevant. There's already app= lications
>> that I can use to track my kids (like Life360). These use the GPS = in
>> mobile devices and secure connections to trasmit location informat= ion;
>> it's far more accurate and secure than trying to deriving loca= tion
>> information from a few bits in an IP address.
>
>
> Yes, this has already=C2=A0 been alluded to in the draft:
>
> Today such location sharing happens at an application layer using GPS<= br> >=C2=A0 =C2=A0 coordinates.
>
>
>> I think it's a hard
>> requirement that Identifiers (IP addresses in general) must not ex= pose
>> geo location or mobile devices, and it follows that identifier/loc= ator
>> bindings should never be shared outside a network except LEA order= s.
>>
>
> Here is the rest of the above paragraph I quoted from Erik's draft= :
>
> But while such sharing is in effect, it wouldn't be
>=C2=A0 =C2=A0 unreasonable to also consider sharing IP locators to make= it more
>=C2=A0 =C2=A0 efficient or more robust to e.g., route a video feed from= one device
>=C2=A0 =C2=A0 to another.
>
>
> What do you think?

Sure, it could be considered, but the benefits of exposing a third
party to identifier/locator mappings would have to be weighed against
the cost. The potential cost is weakened user privacy and security.
Locators will convey geo location in a mobile network, so if someone
knows identifier to locator mapping, then they know location of node
with that identifier. But more than that, knowledge of
identifier/locator mappings allow correlations to be made between
identifiers. For instance, if a device is using some number of
untrackable and uncorrelatable identifiers for privacy, knowledge of
identifier to locator mappings allows correlations to be made and the
identifiers that belong to the device can be deduced and the users can
be tracked.


Absolutely.

One reason = why I posted this mail was to encourage the discussion of solution approach= es in different=C2=A0
IdLoc protocols.
How could we treat each of cases of Family = and Friends, Industrial IoT, etc. in ILA, ILNP, and LISP?
= What about the three points in Section 6?

Behcet

--000000000000ca870405777caaf9-- From nobody Mon Oct 8 08:02:17 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C3E130EF9 for ; Mon, 8 Oct 2018 08:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgl2N5ZIEI80 for ; Mon, 8 Oct 2018 08:01:57 -0700 (PDT) Received: from mailout41.telekom.de (MAILOUT41.telekom.de [194.25.225.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94DAD130EFF for ; Mon, 8 Oct 2018 08:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1539010896; x=1570546896; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0VBWOig9rp6KlpCHtvOFg1vDtfOvn+eXfUNk7sHfeYw=; b=o2H237fKBRNXFWM5082iUorBUELYVJTl4MhgJQO9OONI832F7tL7S2nG L1W4a5w1xOlgXRRDr4Z1LcejxgPEUmJVL38TYiJ2voF7hinC85xgSW3Ey 4uGsDMj7w/c9+Y8Pb+zwI8aRpJ2QotZkCtnSNi6k4mGZqHdFn+OH+eIo0 KsOY21IKvJSgBI4imkq1JAE6CsRU1OfFNatJSCB1Aw1OQVwVbAvJkcv1s nNRQ2FmKHIjHuiUEHt77o2XLF5E7EILe5lSr/qU1+XzurJF4h2Gzv64y/ pxhQpgXokHGYs0A3NkZm910oF9KXC7NXLiZ89jhEs51aKYE0ozd01Kz/D A==; Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Oct 2018 17:01:34 +0200 X-IronPort-AV: E=Sophos;i="5.54,357,1534802400"; d="scan'208,217";a="138392308" Received: from he106138.emea1.cds.t-internal.com ([10.169.119.71]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 08 Oct 2018 17:01:33 +0200 Received: from HE105704.EMEA1.cds.t-internal.com (10.169.119.21) by HE106138.emea1.cds.t-internal.com (10.169.119.71) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Oct 2018 17:01:33 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105704.EMEA1.cds.t-internal.com (10.169.119.21) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 8 Oct 2018 17:01:33 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.15) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 8 Oct 2018 17:01:01 +0200 Received: from FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE (10.158.135.18) by FRAPR01MB0804.DEUPRD01.PROD.OUTLOOK.DE (10.158.135.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.27; Mon, 8 Oct 2018 15:01:32 +0000 Received: from FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE ([fe80::19d:3b54:fe88:c744]) by FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE ([fe80::19d:3b54:fe88:c744%4]) with mapi id 15.20.1207.024; Mon, 8 Oct 2018 15:01:32 +0000 From: To: , CC: Thread-Topic: [Pidloc] draft-nordmark-id-loc-privacy Thread-Index: AQHUW/PZa2PqHWSHd06U0N/4DdnTsqUPZKQAgAFRpQCAAAhdAIAABGaAgASxzbA= Date: Mon, 8 Oct 2018 15:01:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dirk.von-Hugo@telekom.de; x-originating-ip: [212.201.104.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0804; 6:yI3m1xIrTD3/wojQHaWhExiAJg3onqpe55NjJgpcJ15ykdfx3hthrf+8bsizsz/NUsd02UC+JJdsOa3MsYNzTxoIP/9AXEbF9+8CI8+EDq4/tAlK8KGxaUiUP8pwzdz4kF0D3RnPlrDWgXDUfcayIBCf1sHu1KInSr8aiwdnSzwsWKVpEhJNNu1qmYzeN5guaKDsLQANTPnzgaiXD6VUSe8HtymCVvdoSf++r3eLLchclAauiOcKoP1m9pxlRb+0d48WAGroW2bQKYp6j2r+xv1tuPmPjO2F6MvlpYGtPjzS7vXqBuRL9n4M6mxKdggIntoloRhTOutBtMCqrTsNvcc5sktrFOO20vvsZEO9eLPtYYJcfVjXhfbTYtq7s0jHGaca5uOFveDih8Pp75NQGGFS+kztYWbO8tLXZrmhdDkMBYTr8h/CybdkFmEUPV2ZJ0ZtVu1TP7PmUMdyG33Mmg==; 5:QwBvwaTGTFSTb0UmfKtm2vuVnWAys48CNRo6eaGn3FQrzR/mNOGX1P3KHZ+LOr29A8u5vIdGDEMCeZndJrzoc13gOSUjMdyV4jUBAuUoS1Xi1LjICpUNfrmECRajd1HrArnIs+oXL1ZeoRdGw18wCqJ7g9qRWvKR5aIkqfdcPnY=; 7:SMZHuVHQBPXUV5iL08DSEQ9h8tufOXuKOu1EFPBY7b9Z2+nI3tWEKWy1azb5sw8M7obZceaKNazbqevVF6QFdnl9rXLYEOO3j3RZtJS4JFeCnEJOAMNIJOwvXzdtZfZPDlPvBFa5yGczmVB8TSaCY4R48XYsasqbF+hPfKKjGZRTP2v+Cc9gx+PjOH96QkZYp6GtmzQWOBQ49PY5Fes4TWsWy+1Ewx9KOQcqNyM2xIlCNhSWHtTU6Fu2Z2oWc4rp x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 2a3e6cdb-01b4-4aa2-98d8-08d62d2eef17 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:FRAPR01MB0804; x-ms-traffictypediagnostic: FRAPR01MB0804: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(278428928389397)(269456686620040)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201708071742011)(7699051); SRVR:FRAPR01MB0804; BCL:0; PCL:0; RULEID:; SRVR:FRAPR01MB0804; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(376002)(366004)(346002)(39860400002)(189003)(199004)(102836004)(229853002)(71190400001)(86362001)(26005)(186003)(6246003)(68736007)(5660300001)(93886005)(71200400001)(33656002)(2501003)(2900100001)(5250100002)(4326008)(105586002)(76176011)(790700001)(3846002)(6116002)(75402003)(97736004)(53546011)(52396003)(7696005)(316002)(2906002)(74482002)(486006)(110136005)(8676002)(66066001)(72206003)(8936002)(53936002)(14444005)(81156014)(6306002)(9686003)(54896002)(81166006)(55016002)(236005)(14454004)(478600001)(256004)(476003)(7736002)(106356001)(11346002)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0804; H:FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: DJI7J/DYWFlt0bEf2zxHGUVtla/5EKoEVYjZWWMDPaHM8kQmBpK+KJZQSzEWWciORKBDIyp12jV4aEr3+rAtkic6LnkHAQuazMUf0RIuMmWsEsHHVvC5ja0WkBLVgM36vMY5ihOoCDaNYTPxbZqJk2HWkfVawlstUMgOTQOtfQP6yzJLunwQJ6/n910jmo2bS62aqyOkjc5D8QELcAnp/OkFQ0Ug+GM6j1y5fcbE3FcBVkPMDQtnYCH0Om9IWI/WgEEVSaerj40RUiC86DOaOvGAwBZlzyMmK+hvGOoVoxO2horhAOo0+OfK1dYx83k2KSIN9WbfOZRB/4c7U4IHEJ5TOHdss1Z8YigDMGDnAe8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FRAPR01MB0801B1C10EFB13D804095D3ED1E60FRAPR01MB0801DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2a3e6cdb-01b4-4aa2-98d8-08d62d2eef17 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2018 15:01:32.2237 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0804 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [Pidloc] draft-nordmark-id-loc-privacy X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 15:02:16 -0000 --_000_FRAPR01MB0801B1C10EFB13D804095D3ED1E60FRAPR01MB0801DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlIGJlbG93IOKApg0KVGhhbmtzIGFuZCBCUiwgRGlyaw0KT24gRnJpLCBPY3QgNSwgMjAxOCBh dCA5OjU0IEFNIFRvbSBIZXJiZXJ0IDx0b21AcXVhbnRvbml1bS5uZXQ8bWFpbHRvOnRvbUBxdWFu dG9uaXVtLm5ldD4+IHdyb3RlOg0KT24gRnJpLCBPY3QgNSwgMjAxOCBhdCA3OjI0IEFNLCBCZWhj ZXQgU2FyaWtheWEgPHNhcmlrYXlhMjAxMkBnbWFpbC5jb208bWFpbHRvOnNhcmlrYXlhMjAxMkBn bWFpbC5jb20+PiB3cm90ZToNCj4NCj4NCj4gT24gVGh1LCBPY3QgNCwgMjAxOCBhdCAxOjE1IFBN IFRvbSBIZXJiZXJ0IDx0b21AcXVhbnRvbml1bS5uZXQ8bWFpbHRvOnRvbUBxdWFudG9uaXVtLm5l dD4+IHdyb3RlOg0KPj4NCj4+IE9uIFRodSwgT2N0IDQsIDIwMTggYXQgODowMiBBTSwgQmVoY2V0 IFNhcmlrYXlhIDxzYXJpa2F5YTIwMTJAZ21haWwuY29tPG1haWx0bzpzYXJpa2F5YTIwMTJAZ21h aWwuY29tPj4NCj4+IHdyb3RlOg0KPj4gPiBIaSBMdWlnaSwgRGlyaywgYWxsLA0KPj4gPg0KPj4g PiBTbyBmYXIgd2UgaGF2ZSBhIG51bWJlciBvZiByZXZpZXdzIG9uIEVyaWsncyBkcmFmdCBpbmRp Y2F0aW5nIHNvbWUNCj4+ID4gZWRpdG9yaWFsDQo+PiA+IGlzc3VlcyBhbmQgYXNraW5nIGZvciBj bGFyaWZpY2F0aW9uIG9mIHNvbWUgcGFydHMuIEFsbCB0aGF0IGlzIGdvb2QuDQo+PiA+DQo+PiA+ IFdoYXQgSSBzdWdnZXN0IGlzIHRoYXQgd2Ugc2hvdWxkIGFsc28gbG9vayBpbnRvIHdoYXQgaGUg aXMgc2F5aW5nIGluDQo+PiA+IHRoYXQNCj4+ID4gZHJhZnQsIHdoYXQgaXMgaGUgc3VnZ2VzdGlu ZyBhcyB0aGUgZnV0dXJlIHdvcmsgdG8gZG8/DQo+PiA+DQo+PiA+IEhlcmUgSSBhbSBnb2luZyB0 byBzdW1tYXJ5IHdoYXQgSSBjb3VsZCBmaW5kIG91dDoNCj4+ID4NCj4+ID4gLSBXZSBzaG91bGQg Y29uY2VudHJhdGUgb24gbG9uZy1saXZlZCBpZGVudGlmaWVyczsNCj4+ID4NCj4+ID4gLSBXb3Jy eSBub3QgbXVjaCBvbiBkZXNpZ25pbmcgYSBwcml2YWN5IGJhc2VkIHVuaWZpZWQgbWFwcGluZyBt YXBwaW5nDQo+PiA+IHN5c3RlbQ0KPj4gPiB3aGljaCB3ZSBoYWQgY29uY2VudHJhdGVkIGluIG91 ciBwcmV2aW91cyBhY3Rpdml0eS4gVGhpcyBpcyBiZWNhdXNlIG9ubHkNCj4+ID4gdHJ1c3RlZCBk ZXZpY2VzIGNhbiBhY2Nlc3MgdGhlIG1hcHBpbmdzICBpbiBhbiBvcGVyYXRvciBuZXR3b3JrDQo+ PiA+DQo+PiA+IC0gSW5zdGVhZCB3b3JyeSBhYm91dCBtaW5pbWl6aW5nIHRoZSBwcml2YWN5IGlt cGxpY2F0aW9uIG9uZSBjYW4gZXhwbG9yZQ0KPj4gPiBsaW1pdGluZyB0byB3aGljaCBwZWVycyBh bmQgd2hlbiB0aGUgSUQvIGxvY2F0b3IgYmluZGluZyBhcmUgZXhwb3NlZC4NCj4+ID4NCj4+ID4g VGhlIGNhc2VzIHdoZXJlIElEL2xvY2F0b3IgYmluZGluZ3MgYXJlIGV4cG9zZWQgKGVzcGVjaWFs bHkgYW55IG1vYmlsZQ0KPj4gPiBkZXZpY2VzKQ0KPj4gPiAtIEZhbWlseSBhbmQgZnJpZW5kcyBm b3IgZXhhbXBsZSB3aGVyZSBhcmUgcGFyZW50cyBzaGFyaW5nIHlvdW5nDQo+PiA+IGNoaWxkcmVu DQo+PiA+IGxvY2F0aW9uDQo+Pg0KPj4gSSBkb24ndCBiZWxpZXZlIHRoaXMgY2FzZSBpcyByZWxl dmFudC4gVGhlcmUncyBhbHJlYWR5IGFwcGxpY2F0aW9ucw0KPj4gdGhhdCBJIGNhbiB1c2UgdG8g dHJhY2sgbXkga2lkcyAobGlrZSBMaWZlMzYwKS4gVGhlc2UgdXNlIHRoZSBHUFMgaW4NCj4+IG1v YmlsZSBkZXZpY2VzIGFuZCBzZWN1cmUgY29ubmVjdGlvbnMgdG8gdHJhc21pdCBsb2NhdGlvbiBp bmZvcm1hdGlvbjsNCj4+IGl0J3MgZmFyIG1vcmUgYWNjdXJhdGUgYW5kIHNlY3VyZSB0aGFuIHRy eWluZyB0byBkZXJpdmluZyBsb2NhdGlvbg0KPj4gaW5mb3JtYXRpb24gZnJvbSBhIGZldyBiaXRz IGluIGFuIElQIGFkZHJlc3MuDQo+DQo+DQo+IFllcywgdGhpcyBoYXMgYWxyZWFkeSAgYmVlbiBh bGx1ZGVkIHRvIGluIHRoZSBkcmFmdDoNCj4NCj4gVG9kYXkgc3VjaCBsb2NhdGlvbiBzaGFyaW5n IGhhcHBlbnMgYXQgYW4gYXBwbGljYXRpb24gbGF5ZXIgdXNpbmcgR1BTDQo+ICAgIGNvb3JkaW5h dGVzLg0KPg0KPg0KPj4gSSB0aGluayBpdCdzIGEgaGFyZA0KPj4gcmVxdWlyZW1lbnQgdGhhdCBJ ZGVudGlmaWVycyAoSVAgYWRkcmVzc2VzIGluIGdlbmVyYWwpIG11c3Qgbm90IGV4cG9zZQ0KPj4g Z2VvIGxvY2F0aW9uIG9yIG1vYmlsZSBkZXZpY2VzLCBhbmQgaXQgZm9sbG93cyB0aGF0IGlkZW50 aWZpZXIvbG9jYXRvcg0KPj4gYmluZGluZ3Mgc2hvdWxkIG5ldmVyIGJlIHNoYXJlZCBvdXRzaWRl IGEgbmV0d29yayBleGNlcHQgTEVBIG9yZGVycy4NCj4+DQo+DQo+IEhlcmUgaXMgdGhlIHJlc3Qg b2YgdGhlIGFib3ZlIHBhcmFncmFwaCBJIHF1b3RlZCBmcm9tIEVyaWsncyBkcmFmdDoNCj4NCj4g QnV0IHdoaWxlIHN1Y2ggc2hhcmluZyBpcyBpbiBlZmZlY3QsIGl0IHdvdWxkbid0IGJlDQo+ICAg IHVucmVhc29uYWJsZSB0byBhbHNvIGNvbnNpZGVyIHNoYXJpbmcgSVAgbG9jYXRvcnMgdG8gbWFr ZSBpdCBtb3JlDQo+ICAgIGVmZmljaWVudCBvciBtb3JlIHJvYnVzdCB0byBlLmcuLCByb3V0ZSBh IHZpZGVvIGZlZWQgZnJvbSBvbmUgZGV2aWNlDQo+ICAgIHRvIGFub3RoZXIuDQo+DQo+DQo+IFdo YXQgZG8geW91IHRoaW5rPw0KDQpTdXJlLCBpdCBjb3VsZCBiZSBjb25zaWRlcmVkLCBidXQgdGhl IGJlbmVmaXRzIG9mIGV4cG9zaW5nIGEgdGhpcmQNCnBhcnR5IHRvIGlkZW50aWZpZXIvbG9jYXRv ciBtYXBwaW5ncyB3b3VsZCBoYXZlIHRvIGJlIHdlaWdoZWQgYWdhaW5zdA0KdGhlIGNvc3QuIFRo ZSBwb3RlbnRpYWwgY29zdCBpcyB3ZWFrZW5lZCB1c2VyIHByaXZhY3kgYW5kIHNlY3VyaXR5Lg0K TG9jYXRvcnMgd2lsbCBjb252ZXkgZ2VvIGxvY2F0aW9uIGluIGEgbW9iaWxlIG5ldHdvcmssIHNv IGlmIHNvbWVvbmUNCmtub3dzIGlkZW50aWZpZXIgdG8gbG9jYXRvciBtYXBwaW5nLCB0aGVuIHRo ZXkga25vdyBsb2NhdGlvbiBvZiBub2RlDQp3aXRoIHRoYXQgaWRlbnRpZmllci4gQnV0IG1vcmUg dGhhbiB0aGF0LCBrbm93bGVkZ2Ugb2YNCmlkZW50aWZpZXIvbG9jYXRvciBtYXBwaW5ncyBhbGxv dyBjb3JyZWxhdGlvbnMgdG8gYmUgbWFkZSBiZXR3ZWVuDQppZGVudGlmaWVycy4gRm9yIGluc3Rh bmNlLCBpZiBhIGRldmljZSBpcyB1c2luZyBzb21lIG51bWJlciBvZg0KdW50cmFja2FibGUgYW5k IHVuY29ycmVsYXRhYmxlIGlkZW50aWZpZXJzIGZvciBwcml2YWN5LCBrbm93bGVkZ2Ugb2YNCmlk ZW50aWZpZXIgdG8gbG9jYXRvciBtYXBwaW5ncyBhbGxvd3MgY29ycmVsYXRpb25zIHRvIGJlIG1h ZGUgYW5kIHRoZQ0KaWRlbnRpZmllcnMgdGhhdCBiZWxvbmcgdG8gdGhlIGRldmljZSBjYW4gYmUg ZGVkdWNlZCBhbmQgdGhlIHVzZXJzIGNhbg0KYmUgdHJhY2tlZC4NCg0KQWJzb2x1dGVseS4NCg0K T25lIHJlYXNvbiB3aHkgSSBwb3N0ZWQgdGhpcyBtYWlsIHdhcyB0byBlbmNvdXJhZ2UgdGhlIGRp c2N1c3Npb24gb2Ygc29sdXRpb24gYXBwcm9hY2hlcyBpbiBkaWZmZXJlbnQNCklkTG9jIHByb3Rv Y29scy4NCkhvdyBjb3VsZCB3ZSB0cmVhdCBlYWNoIG9mIGNhc2VzIG9mIEZhbWlseSBhbmQgRnJp ZW5kcywgSW5kdXN0cmlhbCBJb1QsIGV0Yy4gaW4gSUxBLCBJTE5QLCBhbmQgTElTUD8NCldoYXQg YWJvdXQgdGhlIHRocmVlIHBvaW50cyBpbiBTZWN0aW9uIDY/DQoNCkJlaGNldA0KDQpESD4gSSB0 aGluayB3ZSBoYXZlIHRvIGRpZmZlcmVudGlhdGUgaGVyZSBiZXR3ZWVuIElQIExvY2F0b3IgbWVu dGlvbmVkIGFib3ZlIGFuZCBnZW9sb2NhdGlvbi4gV2hpbGUgdGhlIGZpcnN0IHVzZWQgZm9yIGVu ZCBwb2ludCByb3V0aW5nIG1heSBiZSBzdGF0aWNhbGx5IGNvcnJlbGF0ZWQgdG8gYSB0cmFja2Fi bGUgZ2VvZ3JhcGhpYyBwb3NpdGlvbiBhbmQgdGh1cyBhbGxvdyBmb3IgcHJpdmFjeSByZWxhdGVk IHRyYWNraW5nIHRoZXJlIHNob3VsZCBiZSBtZWFzdXJlcyB0byBvYmZ1c2NhdGUgdGhpcyBtYXBw aW5nIHRvIHRoZSBvdXRzaWRlIHdvcmxkIGFzIHRoZSBvbmUgYmV0d2VlbiBuYW1lIG9yIElkZW50 aXR5IHRvIGN1cnJlbnQgbG9jYXRpb24uDQpBcyBzdWNoIG1lYXN1cmVzIGNvdWxkIHNlcnZlIHRo ZSBjaG9pY2VzIGhvdyB0byBoYW5kbGUgSUQvbG9jYXRvciBtYXBwaW5nIG1lbnRpb25lZCBieSBF cmlrIGluIHNlY3QuIDY6DQotICAgc3RpbGwgdXNpbmcgYW4gSUQvbG9jYXRvciBzeXN0ZW0gYnV0 IHBvaW50aW5nIGEgbG9jYXRvciBmb3Igc29tZSBmaXhlZCBhbmNob3IgcG9pbnQsDQotIGluamVj dGluZyByb3V0aW5nIHByZWZpeGVzIGZvciB0aGUgSUQgcHJlZml4ZXMgaW50byB0aGUgbm9ybWFs IHJvdXRpbmcgc3lzdGVtDQotIG5vdCBwcm92aWRpbmcgYW55IHN0YWJsZSBsb2NhdG9ycyBhY3Jv c3MgdGhlIGJvdW5kYXJ5IGJldHdlZW4gSWQvTG9jIGRvbWFpbiBhbmQgcmVzdCBvZiB3b3JsZCDi gKYNCg0KSSBoYXZlIG5vIHByZWZlcmVuY2UgZm9yIHRoZSB0aW1lIGJlaW5nDQo= --_000_FRAPR01MB0801B1C10EFB13D804095D3ED1E60FRAPR01MB0801DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0 IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlNlZSBiZWxvdyDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGFua3MgYW5kIEJSLCBEaXJrPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE9jdCA1LCAyMDE4IGF0 IDk6NTQgQU0gVG9tIEhlcmJlcnQgJmx0OzxhIGhyZWY9Im1haWx0bzp0b21AcXVhbnRvbml1bS5u ZXQiPnRvbUBxdWFudG9uaXVtLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5PbiBGcmksIE9jdCA1LCAyMDE4IGF0IDc6MjQgQU0sIEJlaGNldCBTYXJpa2F5 YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhcmlrYXlhMjAxMkBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5zYXJpa2F5YTIwMTJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IE9uIFRodSwgT2N0IDQsIDIwMTggYXQgMToxNSBQTSBUb20gSGVyYmVy dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbUBxdWFudG9uaXVtLm5ldCIgdGFyZ2V0PSJfYmxhbmsi PnRvbUBxdWFudG9uaXVtLm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgT24gVGh1LCBPY3QgNCwgMjAxOCBhdCA4OjAyIEFNLCBCZWhjZXQgU2FyaWtheWEgJmx0 OzxhIGhyZWY9Im1haWx0bzpzYXJpa2F5YTIwMTJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ c2FyaWtheWEyMDEyQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgd3JvdGU6PGJyPg0K Jmd0OyZndDsgJmd0OyBIaSBMdWlnaSwgRGlyaywgYWxsLDxicj4NCiZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7IFNvIGZhciB3ZSBoYXZlIGEgbnVtYmVyIG9mIHJldmlld3Mgb24gRXJp aydzIGRyYWZ0IGluZGljYXRpbmcgc29tZTxicj4NCiZndDsmZ3Q7ICZndDsgZWRpdG9yaWFsPGJy Pg0KJmd0OyZndDsgJmd0OyBpc3N1ZXMgYW5kIGFza2luZyBmb3IgY2xhcmlmaWNhdGlvbiBvZiBz b21lIHBhcnRzLiBBbGwgdGhhdCBpcyBnb29kLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7IFdoYXQgSSBzdWdnZXN0IGlzIHRoYXQgd2Ugc2hvdWxkIGFsc28gbG9vayBpbnRv IHdoYXQgaGUgaXMgc2F5aW5nIGluPGJyPg0KJmd0OyZndDsgJmd0OyB0aGF0PGJyPg0KJmd0OyZn dDsgJmd0OyBkcmFmdCwgd2hhdCBpcyBoZSBzdWdnZXN0aW5nIGFzIHRoZSBmdXR1cmUgd29yayB0 byBkbz88YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBIZXJlIEkgYW0gZ29p bmcgdG8gc3VtbWFyeSB3aGF0IEkgY291bGQgZmluZCBvdXQ6PGJyPg0KJmd0OyZndDsgJmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsgLSBXZSBzaG91bGQgY29uY2VudHJhdGUgb24gbG9uZy1saXZlZCBp ZGVudGlmaWVyczs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAtIFdvcnJ5 IG5vdCBtdWNoIG9uIGRlc2lnbmluZyBhIHByaXZhY3kgYmFzZWQgdW5pZmllZCBtYXBwaW5nIG1h cHBpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IHN5c3RlbTxicj4NCiZndDsmZ3Q7ICZndDsgd2hpY2gg d2UgaGFkIGNvbmNlbnRyYXRlZCBpbiBvdXIgcHJldmlvdXMgYWN0aXZpdHkuIFRoaXMgaXMgYmVj YXVzZSBvbmx5PGJyPg0KJmd0OyZndDsgJmd0OyB0cnVzdGVkIGRldmljZXMgY2FuIGFjY2VzcyB0 aGUgbWFwcGluZ3MmbmJzcDsgaW4gYW4gb3BlcmF0b3IgbmV0d29yazxicj4NCiZndDsmZ3Q7ICZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IC0gSW5zdGVhZCB3b3JyeSBhYm91dCBtaW5pbWl6aW5nIHRo ZSBwcml2YWN5IGltcGxpY2F0aW9uIG9uZSBjYW4gZXhwbG9yZTxicj4NCiZndDsmZ3Q7ICZndDsg bGltaXRpbmcgdG8gd2hpY2ggcGVlcnMgYW5kIHdoZW4gdGhlIElELyBsb2NhdG9yIGJpbmRpbmcg YXJlIGV4cG9zZWQuPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgVGhlIGNh c2VzIHdoZXJlIElEL2xvY2F0b3IgYmluZGluZ3MgYXJlIGV4cG9zZWQgKGVzcGVjaWFsbHkgYW55 IG1vYmlsZTxicj4NCiZndDsmZ3Q7ICZndDsgZGV2aWNlcyk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IC0g RmFtaWx5IGFuZCBmcmllbmRzIGZvciBleGFtcGxlIHdoZXJlIGFyZSBwYXJlbnRzIHNoYXJpbmcg eW91bmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGNoaWxkcmVuPGJyPg0KJmd0OyZndDsgJmd0OyBsb2Nh dGlvbjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBkb24ndCBiZWxpZXZlIHRoaXMgY2Fz ZSBpcyByZWxldmFudC4gVGhlcmUncyBhbHJlYWR5IGFwcGxpY2F0aW9uczxicj4NCiZndDsmZ3Q7 IHRoYXQgSSBjYW4gdXNlIHRvIHRyYWNrIG15IGtpZHMgKGxpa2UgTGlmZTM2MCkuIFRoZXNlIHVz ZSB0aGUgR1BTIGluPGJyPg0KJmd0OyZndDsgbW9iaWxlIGRldmljZXMgYW5kIHNlY3VyZSBjb25u ZWN0aW9ucyB0byB0cmFzbWl0IGxvY2F0aW9uIGluZm9ybWF0aW9uOzxicj4NCiZndDsmZ3Q7IGl0 J3MgZmFyIG1vcmUgYWNjdXJhdGUgYW5kIHNlY3VyZSB0aGFuIHRyeWluZyB0byBkZXJpdmluZyBs b2NhdGlvbjxicj4NCiZndDsmZ3Q7IGluZm9ybWF0aW9uIGZyb20gYSBmZXcgYml0cyBpbiBhbiBJ UCBhZGRyZXNzLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBZZXMsIHRoaXMgaGFzIGFs cmVhZHkmbmJzcDsgYmVlbiBhbGx1ZGVkIHRvIGluIHRoZSBkcmFmdDo8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBUb2RheSBzdWNoIGxvY2F0aW9uIHNoYXJpbmcgaGFwcGVucyBhdCBhbiBhcHBsaWNhdGlv biBsYXllciB1c2luZyBHUFM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBjb29yZGluYXRlcy48YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IEkgdGhpbmsgaXQncyBhIGhhcmQ8YnI+DQom Z3Q7Jmd0OyByZXF1aXJlbWVudCB0aGF0IElkZW50aWZpZXJzIChJUCBhZGRyZXNzZXMgaW4gZ2Vu ZXJhbCkgbXVzdCBub3QgZXhwb3NlPGJyPg0KJmd0OyZndDsgZ2VvIGxvY2F0aW9uIG9yIG1vYmls ZSBkZXZpY2VzLCBhbmQgaXQgZm9sbG93cyB0aGF0IGlkZW50aWZpZXIvbG9jYXRvcjxicj4NCiZn dDsmZ3Q7IGJpbmRpbmdzIHNob3VsZCBuZXZlciBiZSBzaGFyZWQgb3V0c2lkZSBhIG5ldHdvcmsg ZXhjZXB0IExFQSBvcmRlcnMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIZXJl IGlzIHRoZSByZXN0IG9mIHRoZSBhYm92ZSBwYXJhZ3JhcGggSSBxdW90ZWQgZnJvbSBFcmlrJ3Mg ZHJhZnQ6PGJyPg0KJmd0Ozxicj4NCiZndDsgQnV0IHdoaWxlIHN1Y2ggc2hhcmluZyBpcyBpbiBl ZmZlY3QsIGl0IHdvdWxkbid0IGJlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgdW5yZWFzb25hYmxl IHRvIGFsc28gY29uc2lkZXIgc2hhcmluZyBJUCBsb2NhdG9ycyB0byBtYWtlIGl0IG1vcmU8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyBlZmZpY2llbnQgb3IgbW9yZSByb2J1c3QgdG8gZS5nLiwgcm91 dGUgYSB2aWRlbyBmZWVkIGZyb20gb25lIGRldmljZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHRv IGFub3RoZXIuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFdoYXQgZG8geW91IHRoaW5r Pzxicj4NCjxicj4NClN1cmUsIGl0IGNvdWxkIGJlIGNvbnNpZGVyZWQsIGJ1dCB0aGUgYmVuZWZp dHMgb2YgZXhwb3NpbmcgYSB0aGlyZDxicj4NCnBhcnR5IHRvIGlkZW50aWZpZXIvbG9jYXRvciBt YXBwaW5ncyB3b3VsZCBoYXZlIHRvIGJlIHdlaWdoZWQgYWdhaW5zdDxicj4NCnRoZSBjb3N0LiBU aGUgcG90ZW50aWFsIGNvc3QgaXMgd2Vha2VuZWQgdXNlciBwcml2YWN5IGFuZCBzZWN1cml0eS48 YnI+DQpMb2NhdG9ycyB3aWxsIGNvbnZleSBnZW8gbG9jYXRpb24gaW4gYSBtb2JpbGUgbmV0d29y aywgc28gaWYgc29tZW9uZTxicj4NCmtub3dzIGlkZW50aWZpZXIgdG8gbG9jYXRvciBtYXBwaW5n LCB0aGVuIHRoZXkga25vdyBsb2NhdGlvbiBvZiBub2RlPGJyPg0Kd2l0aCB0aGF0IGlkZW50aWZp ZXIuIEJ1dCBtb3JlIHRoYW4gdGhhdCwga25vd2xlZGdlIG9mPGJyPg0KaWRlbnRpZmllci9sb2Nh dG9yIG1hcHBpbmdzIGFsbG93IGNvcnJlbGF0aW9ucyB0byBiZSBtYWRlIGJldHdlZW48YnI+DQpp ZGVudGlmaWVycy4gRm9yIGluc3RhbmNlLCBpZiBhIGRldmljZSBpcyB1c2luZyBzb21lIG51bWJl ciBvZjxicj4NCnVudHJhY2thYmxlIGFuZCB1bmNvcnJlbGF0YWJsZSBpZGVudGlmaWVycyBmb3Ig cHJpdmFjeSwga25vd2xlZGdlIG9mPGJyPg0KaWRlbnRpZmllciB0byBsb2NhdG9yIG1hcHBpbmdz IGFsbG93cyBjb3JyZWxhdGlvbnMgdG8gYmUgbWFkZSBhbmQgdGhlPGJyPg0KaWRlbnRpZmllcnMg dGhhdCBiZWxvbmcgdG8gdGhlIGRldmljZSBjYW4gYmUgZGVkdWNlZCBhbmQgdGhlIHVzZXJzIGNh bjxicj4NCmJlIHRyYWNrZWQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+QWJz b2x1dGVseS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij5PbmUgcmVhc29uIHdo eSBJIHBvc3RlZCB0aGlzIG1haWwgd2FzIHRvIGVuY291cmFnZSB0aGUgZGlzY3Vzc2lvbiBvZiBz b2x1dGlvbiBhcHByb2FjaGVzIGluIGRpZmZlcmVudCZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTMuNXB0Ij5JZExvYyBwcm90b2NvbHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox My41cHQiPkhvdyBjb3VsZCB3ZSB0cmVhdCBlYWNoIG9mIGNhc2VzIG9mIEZhbWlseSBhbmQgRnJp ZW5kcywgSW5kdXN0cmlhbCBJb1QsIGV0Yy4gaW4gSUxBLCBJTE5QLCBhbmQgTElTUD88L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+V2hhdCBhYm91dCB0aGUgdGhyZWUgcG9pbnRzIGlu IFNlY3Rpb24gNj88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij5CZWhjZXQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5ESCZndDsgSSB0aGluayB3 ZSBoYXZlIHRvIGRpZmZlcmVudGlhdGUgaGVyZSBiZXR3ZWVuIElQIExvY2F0b3IgbWVudGlvbmVk IGFib3ZlIGFuZCBnZW9sb2NhdGlvbi4gV2hpbGUgdGhlIGZpcnN0IHVzZWQgZm9yDQogZW5kIHBv aW50IHJvdXRpbmcgbWF5IGJlIHN0YXRpY2FsbHkgY29ycmVsYXRlZCB0byBhIHRyYWNrYWJsZSBn ZW9ncmFwaGljIHBvc2l0aW9uIGFuZCB0aHVzIGFsbG93IGZvciBwcml2YWN5IHJlbGF0ZWQgdHJh Y2tpbmcgdGhlcmUgc2hvdWxkIGJlIG1lYXN1cmVzIHRvIG9iZnVzY2F0ZSB0aGlzIG1hcHBpbmcg dG8gdGhlIG91dHNpZGUgd29ybGQgYXMgdGhlIG9uZSBiZXR3ZWVuIG5hbWUgb3IgSWRlbnRpdHkg dG8gY3VycmVudCBsb2NhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTAuOXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFzIHN1Y2gg bWVhc3VyZXMgY291bGQgc2VydmUgdGhlIGNob2ljZXMgaG93IHRvIGhhbmRsZSBJRC9sb2NhdG9y IG1hcHBpbmcgbWVudGlvbmVkIGJ5IEVyaWsNCiBpbiBzZWN0LiA2OjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMC45cHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+LSZuYnNwOyZuYnNwOyBzdGlsbCB1c2luZyBhbiBJRC9sb2NhdG9yIHN5c3Rl bSBidXQgcG9pbnRpbmcgYSBsb2NhdG9yIGZvciBzb21lIGZpeGVkIGFuY2hvciBwb2ludCwNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDoxMC45cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+LSBpbmplY3Rpbmcgcm91dGluZyBwcmVmaXhlcyBm b3IgdGhlIElEIHByZWZpeGVzIGludG8gdGhlIG5vcm1hbCByb3V0aW5nIHN5c3RlbTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDox MC45cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+LSBub3QgcHJvdmlkaW5nIGFueSBzdGFibGUgbG9jYXRvcnMg YWNyb3NzIHRoZSBib3VuZGFyeSBiZXR3ZWVuIElkL0xvYyBkb21haW4gYW5kIHJlc3Qgb2Ygd29y bGQNCiDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTAuOXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMC45cHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+SSBoYXZlIG5vIHByZWZlcmVuY2UgZm9yIHRoZSB0aW1lIGJlaW5nPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FRAPR01MB0801B1C10EFB13D804095D3ED1E60FRAPR01MB0801DEUP_-- From nobody Mon Oct 8 09:20:46 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D5A130DC0 for ; Mon, 8 Oct 2018 09:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF55CVB9_w9y for ; Mon, 8 Oct 2018 09:20:43 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9117C127133 for ; Mon, 8 Oct 2018 09:20:41 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id e187-v6so8920969wmf.0 for ; Mon, 08 Oct 2018 09:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=R5R7oRTnT1KiJ2Ncp4euYdnPdq6PVawBoHaquw8bt/s=; b=bR+rouOeGhhVNX9gsZ68qBPIg9rHf6Kbd/P0jXRDDWKxjEDXsx2I6f6ArLZ932Y0eT +opY61g/YZ61XOP07SgwUHHuWDhXtpqk0VJL+qk5piMRDs3LK48kxwTotye4x1EmvQ1m kZxHKRsyhHbIImTr37k8FOMHN5ZI1a09afuqzvCLYOdmvD35aEFvRJHWFgTMnLC8y39D CJQDPvghxRfw9IJrBezUiZrhEHuacA0iGv1wh+1acAfB/nsbUKlEEclenbVQwVscGjC3 NI7FTWtkwYCbz4XSlFWkx5L9IyrsJviw3pqlhJNdw19dcJpaaq/5Yznu4jl7eXsvGSqF tajA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=R5R7oRTnT1KiJ2Ncp4euYdnPdq6PVawBoHaquw8bt/s=; b=rZn1ztrmyDFxLqSXpxY/z0cNVQ4F2CdxyVtyJburhWiuXkgVKQhhfn4BzWtg769leO P0n1BbZUU6D/IK4hYCySV9xbNN2CZOXJpYaMxpUsYMPSJrAkLW3w0j5l3DEKh7axXzcR CxywSV03xi3b9msFbOUFP8FOyt3nVme6jK46MRAvlRhlGhLXQLMPbyEqPKTUX8yCo2NO PewyusjPwEVwE8ha3+2Mc9i3J2XnANRIu42dAK7/0BAzWUUmnNhJ8ZVP+xY1/gGpw8Uv 2KSZpPXyyMadpGUbDQ8iWyznRj+CfDe4VFBXeF47jVp5G/jkiaxyzAkalPlVtjasTVWG cH4Q== X-Gm-Message-State: ABuFfoi299l1IfGiRb9V/AL5XubWpK9eL0twiGJzRnjgDkLpK1/xFd7I dhPIM99cYIJc2xL9eIbN6rseCK8omPoqsqJ6k461PQ== X-Google-Smtp-Source: ACcGV62pwIgODPY0SGzXTNSlsOQQ0Dz95FFZ+YhofvQBXQwBKNRDWleCl8ZwNj4hAqtS7f+DQnsELG4OIxKzOIgnyjE= X-Received: by 2002:a1c:1783:: with SMTP id 125-v6mr16324610wmx.75.1539015639877; Mon, 08 Oct 2018 09:20:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Mon, 8 Oct 2018 11:20:28 -0500 Message-ID: To: Tom Herbert Cc: pidloc@ietf.org Content-Type: multipart/alternative; boundary="00000000000084ce510577ba00e2" Archived-At: Subject: Re: [Pidloc] draft-nordmark-id-loc-privacy X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 16:20:45 -0000 --00000000000084ce510577ba00e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom, On Mon, Oct 8, 2018 at 10:01 AM wrote: > See below =E2=80=A6 > > Thanks and BR, Dirk > > On Fri, Oct 5, 2018 at 9:54 AM Tom Herbert wrote: > > On Fri, Oct 5, 2018 at 7:24 AM, Behcet Sarikaya > wrote: > > > > > > On Thu, Oct 4, 2018 at 1:15 PM Tom Herbert wrote: > >> > >> On Thu, Oct 4, 2018 at 8:02 AM, Behcet Sarikaya > > >> wrote: > >> > Hi Luigi, Dirk, all, > >> > > >> > So far we have a number of reviews on Erik's draft indicating some > >> > editorial > >> > issues and asking for clarification of some parts. All that is good. > >> > > >> > What I suggest is that we should also look into what he is saying in > >> > that > >> > draft, what is he suggesting as the future work to do? > >> > > >> > Here I am going to summary what I could find out: > >> > > >> > - We should concentrate on long-lived identifiers; > >> > > >> > - Worry not much on designing a privacy based unified mapping mappin= g > >> > system > >> > which we had concentrated in our previous activity. This is because > only > >> > trusted devices can access the mappings in an operator network > >> > > >> > - Instead worry about minimizing the privacy implication one can > explore > >> > limiting to which peers and when the ID/ locator binding are exposed= . > >> > > >> > The cases where ID/locator bindings are exposed (especially any mobi= le > >> > devices) > >> > - Family and friends for example where are parents sharing young > >> > children > >> > location > >> > >> I don't believe this case is relevant. There's already applications > >> that I can use to track my kids (like Life360). These use the GPS in > >> mobile devices and secure connections to trasmit location information; > >> it's far more accurate and secure than trying to deriving location > >> information from a few bits in an IP address. > > > > > > Yes, this has already been alluded to in the draft: > > > > Today such location sharing happens at an application layer using GPS > > coordinates. > > > > > >> I think it's a hard > >> requirement that Identifiers (IP addresses in general) must not expose > >> geo location or mobile devices, and it follows that identifier/locator > >> bindings should never be shared outside a network except LEA orders. > >> > > > > Here is the rest of the above paragraph I quoted from Erik's draft: > > > > 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. > > > > > > What do you think? > > Sure, it could be considered, but the benefits of exposing a third > party to identifier/locator mappings would have to be weighed against > the cost. The potential cost is weakened user privacy and security. > Locators will convey geo location in a mobile network, so if someone > knows identifier to locator mapping, then they know location of node > with that identifier. > > > But more than that, knowledge of > identifier/locator mappings allow correlations to be made between > identifiers. For instance, if a device is using some number of > untrackable and uncorrelatable identifiers for privacy, knowledge of > identifier to locator mappings allows correlations to be made and the > identifiers that belong to the device can be deduced and the users can > be tracked. > > > So you are saying that there is a cost for allowing Id/Loc mappings. Do you think that letting family and friends or Industrial IoT devices that belong to my company know my locator also poses similar cost or issue? What should we do? How could this effect, e.g. ILA? Behcet > Absolutely. > > > > One reason why I posted this mail was to encourage the discussion of > solution approaches in different > > IdLoc protocols. > > How could we treat each of cases of Family and Friends, Industrial IoT, > etc. in ILA, ILNP, and LISP? > > What about the three points in Section 6? > > > > Behcet > > > > DH> I think we have to differentiate here between IP Locator mentioned > above and geolocation. While the first used for end point routing may be > statically correlated to a trackable geographic position and thus allow f= or > privacy related tracking there should be measures to obfuscate this mappi= ng > to the outside world as the one between name or Identity to current > location. > > As such measures could serve the choices how to handle ID/locator mapping > mentioned by Erik in sect. 6: > > - still using an ID/locator system but pointing a locator for some fixe= d > anchor point, > > - injecting routing prefixes for the ID prefixes into the normal routing > system > > - not providing any stable locators across the boundary between Id/Loc > domain and rest of world =E2=80=A6 > > > > I have no preference for the time being > > --00000000000084ce510577ba00e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,


On Mon, Oct 8, 2018 at 10:01 AM <Dirk.von-Hugo@telekom.de> wrote:

See belo= w =E2=80=A6

Thanks= and BR, Dirk

On Fri, Oct 5, 2018 at 9:54 AM Tom Herbert <tom@quantonium.net&g= t; wrote:

On Fri, Oct 5, 2018 a= t 7:24 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
>
>
> On Thu, Oct 4, 2018 at 1:15 PM Tom Herbert <tom@quantonium.net> wrote:
>>
>> On Thu, Oct 4, 2018 at 8:02 AM, Behcet Sarikaya <sarikaya2012@gmail.com>= ;
>> wrote:
>> > Hi Luigi, Dirk, all,
>> >
>> > So far we have a number of reviews on Erik's draft indica= ting some
>> > editorial
>> > issues and asking for clarification of some parts. All that i= s good.
>> >
>> > What I suggest is that we should also look into what he is sa= ying in
>> > that
>> > draft, what is he suggesting as the future work to do?
>> >
>> > Here I am going to summary what I could find out:
>> >
>> > - We should concentrate on long-lived identifiers;
>> >
>> > - Worry not much on designing a privacy based unified mapping= mapping
>> > system
>> > which we had concentrated in our previous activity. This is b= ecause only
>> > trusted devices can access the mappings=C2=A0 in an operator = network
>> >
>> > - Instead worry about minimizing the privacy implication one = can explore
>> > limiting to which peers and when the ID/ locator binding are = exposed.
>> >
>> > The cases where ID/locator bindings are exposed (especially a= ny mobile
>> > devices)
>> > - Family and friends for example where are parents sharing yo= ung
>> > children
>> > location
>>
>> I don't believe this case is relevant. There's already app= lications
>> that I can use to track my kids (like Life360). These use the GPS = in
>> mobile devices and secure connections to trasmit location informat= ion;
>> it's far more accurate and secure than trying to deriving loca= tion
>> information from a few bits in an IP address.
>
>
> Yes, this has already=C2=A0 been alluded to in the draft:
>
> Today such location sharing happens at an application layer using GPS<= br> >=C2=A0 =C2=A0 coordinates.
>
>
>> I think it's a hard
>> requirement that Identifiers (IP addresses in general) must not ex= pose
>> geo location or mobile devices, and it follows that identifier/loc= ator
>> bindings should never be shared outside a network except LEA order= s.
>>
>
> Here is the rest of the above paragraph I quoted from Erik's draft= :
>
> But while such sharing is in effect, it wouldn't be
>=C2=A0 =C2=A0 unreasonable to also consider sharing IP locators to make= it more
>=C2=A0 =C2=A0 efficient or more robust to e.g., route a video feed from= one device
>=C2=A0 =C2=A0 to another.
>
>
> What do you think?

Sure, it could be considered, but the benefits of exposing a third
party to identifier/locator mappings would have to be weighed against
the cost. The potential cost is weakened user privacy and security.
Locators will convey geo location in a mobile network, so if someone
knows identifier to locator mapping, then they know location of node
with that identifier.

=C2=A0

But more than that, knowledge of
identifier/locator mappings allow correlations to be made between
identifiers. For instance, if a device is using some number of
untrackable and uncorrelatable identifiers for privacy, knowledge of
identifier to locator mappings allows correlations to be made and the
identifiers that belong to the device can be deduced and the users can
be tracked.

=C2=A0

So you are saying that there is a cost for allowing Id/Loc map= pings.
Do you think that letting family and friends or Industrial= IoT devices that belong to my company know my locator also=C2=A0
poses similar cost or issue? What should we do?
How could this e= ffect, e.g. ILA?

Behcet

<= br>
=C2=A0

Absolutely.<= u>

=C2=A0

One reason why I po= sted this mail was to encourage the discussion of solution approaches in di= fferent=C2=A0

IdLoc protocols.

How could we treat = each of cases of Family and Friends, Industrial IoT, etc. in ILA, ILNP, and= LISP?

What about the thre= e points in Section 6?

=C2=A0

Behcet

=C2=A0

DH> I think we have= to differentiate here between IP Locator mentioned above and geolocation. = While the first used for end point routing may be statically correlated to a trackable geographic p= osition and thus allow for privacy related tracking there should be measure= s to obfuscate this mapping to the outside world as the one between name or= Identity to current location.

As such measures could serve the choices how to handle ID/locator ma= pping mentioned by Erik in sect. 6:

-=C2=A0=C2=A0 still using an ID/locator system but pointing a locato= r for some fixed anchor point,

- injecting routing prefixes for the ID prefixes into the normal rou= ting system

- not providing any stable locators across the boundary between Id/L= oc domain and rest of world =E2=80=A6

=C2=A0

I have no preference for the time being

--00000000000084ce510577ba00e2-- From nobody Thu Oct 11 01:56:03 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24703130DE2 for ; Thu, 11 Oct 2018 01:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuEVnnQTTRxN for ; Thu, 11 Oct 2018 01:55:59 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E63130DD0 for ; Thu, 11 Oct 2018 01:55:59 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id 143-v6so8090959wmf.1 for ; Thu, 11 Oct 2018 01:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7MfZpzUzHCBX6TxQMypCy/cGOOvPzbTpXFpCJFRK1TQ=; b=NUaDQRT8QuV/juaa37LpYjLUUYReitt565Gmh61yAM9VHE79FwJRJJBX/qrOg/Hikq hPHduDyzdxWwtUFMzIAa7pWK3zcBP79u3g/YEnnibyypMEoVreopY+y/HcrENgL/ZCkY n53ESIOX+fY5lAruvqmJg3gBkuK31vV1jbN/raM9nmH+cG64Tuj2W19j7KyKkxN9ezBM 2mI7tWJzgAJdGEmWVd8xoaCBfhDxccs22lXc1k7bQz12oFoHxtRoTQYOjHzbSU7NpTAB iOck5iDp4gJfZ2anSO2mNupvd0kViKA0qHvdbSq01N6sgTLPNriHmxyUsuKC1IGzZZQo Vd4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7MfZpzUzHCBX6TxQMypCy/cGOOvPzbTpXFpCJFRK1TQ=; b=emJAPp4RIiAWMkulX4DNhO1WneLj7nklrkOg7nr4vDt2j0+Essd0GiPEfbSPtjRYHx 0vBMFqXo4JfebNc2dsv47mGSn+WkE7mYkFNF1sAwARCzJ+wt4J6q/X3rEP8pp4YeoPWN BUHRWMrDpC38E2wqPw5b3G6alalHo/k31t6XAAkGxUjdItQdlVarh9NTcQ7ym1JJNcfg uw+uhfCF/IkBHn/mmcR+E3T5mEgcrYN4dR4vD5cfg5687/zF/+ta42Y2eGbs6a8xTe/D wyqDXN+p6EbYFhOc3hitE2WCWue8Ptj2odJmGYoJRBQt+yXtkZFTtUmRx+6SeM+alF9b 6RvA== X-Gm-Message-State: ABuFfogysPdLFj0k/ARrk4fYn5slYTNZuqARENqGXCNJ4Jx2/FxflLGw xIWBObVEcPr3CC7keahNNd1DmcpgfrtYSobB X-Google-Smtp-Source: ACcGV63yFWSx5Oh1Pyzj/i8eOFW9jlUc3U4gYCzocGXyT1/EpS8sCp33zbzZPflamKVo9GVEUp+9xA== X-Received: by 2002:a1c:bce:: with SMTP id 197-v6mr828652wml.15.1539248157513; Thu, 11 Oct 2018 01:55:57 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:7489:ccd2:f7c:1d15? ([2001:660:330f:a4:7489:ccd2:f7c:1d15]) by smtp.gmail.com with ESMTPSA id g76-v6sm20485525wmd.25.2018.10.11.01.55.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 01:55:55 -0700 (PDT) From: Luigi Iannone Message-Id: <86F15094-3382-4D4F-AD45-C751117C3066@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_AE64319D-20D7-402E-A321-4A1E56F4ED6C" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Thu, 11 Oct 2018 10:55:59 +0200 In-Reply-To: Cc: pidloc@ietf.org To: Behcet Sarikaya References: X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Pidloc] draft-nordmark-id-loc-privacy X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 08:56:02 -0000 --Apple-Mail=_AE64319D-20D7-402E-A321-4A1E56F4ED6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 4 Oct 2018, at 17:02, Behcet Sarikaya = wrote: >=20 [snip] >=20 > In Section 6, the draft points to some possibilities on how this = limiting can be achieved: >=20 > 1. pointing a locator for some fixed anchor point, like PGW or UPF This would be kind of a home agent, right? In this case ww will end up with possibly a long stretch in the path = (depending on mobility). > 2. injecting routing prefixes for the ID prefixes into the normal = routing system >=20 LISP has this approach described in RFC 6832. I think it is not completely disjoint from the previous point. The = proxies will become a =E2=80=9Cfixed anchor point=E2=80=9D. Or you had something else in mind?=20 > 3. not providing any stable locators across this boundary; only allow = ephemeral IP addresses per session or otherwise limited exposure. When you say =E2=80=9Cephemeral IP addresses=E2=80=9D you mean the RLOCs = or the IDs? Ciao L. >=20 > In short, the draft is coming up with a lot work to do. > We suggest that the group takes a close look into all these points and = see what we can do :-) > Regards, > Behcet & Dirk > --=20 > Pidloc mailing list > Pidloc@ietf.org > https://www.ietf.org/mailman/listinfo/pidloc --Apple-Mail=_AE64319D-20D7-402E-A321-4A1E56F4ED6C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On 4 Oct 2018, at 17:02, Behcet Sarikaya = <sarikaya2012@gmail.com> wrote:

[snip]

In Section 6, the draft points to some = possibilities on how this limiting can be = achieved:

1. pointing = a locator for some fixed anchor point, like PGW or = UPF

This would be kind of a home = agent, right?
In this case ww will end up with possibly a long = stretch in the path (depending on mobility).



2. injecting routing = prefixes for the ID prefixes into the normal routing = system

<= /div>

LISP has this approach = described in RFC 6832.

I think it is = not completely disjoint from the previous point. The proxies will become = a =E2=80=9Cfixed anchor point=E2=80=9D.

Or you had something else in mind? 

3.= not providing any stable locators across this boundary; only allow ephemeral IP = addresses per session or otherwise limited = exposure.

When you say =E2=80=9Cephem= eral IP addresses=E2=80=9D you mean the RLOCs or the IDs?

Ciao

L.



In short, the draft is coming up with a lot work = to do.
We = suggest that the group takes a close look into all these points and see = what we can do :-)
Regards,
Behcet & = Dirk
--
Pidloc mailing list
Pidloc@ietf.org
https://www.ietf.org/mailman/listinfo/pidloc

= --Apple-Mail=_AE64319D-20D7-402E-A321-4A1E56F4ED6C-- From nobody Thu Oct 11 02:27:36 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E769130DCB for ; Thu, 11 Oct 2018 02:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yiv0GATeuIku for ; Thu, 11 Oct 2018 02:27:32 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE7B129BBF for ; Thu, 11 Oct 2018 02:27:32 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id n11-v6so8751019wru.13 for ; Thu, 11 Oct 2018 02:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wPTu7PpAzvdziq3/jV7emF20z05MfpmFU4LV+7UF7oE=; b=A2EuBu/SQ6ajJHZ9V3JNG8Br5MMHFZg8FhEI4L3ilVS8UUvu8CTRtjFnzjc7QEImEW ivNI2ZfIGSCg5EZlC9zNT0x8xhwiqzHaPp+VGlLx2PI/1IcZ8sjVOns9Zt8ClxKppgUD 8NgCad1cJmj3j00XfI76XNNm32YZlGhqu9QR4JiKazEGLsQ+4kD7boOHOAbLNpWtR8RW kIsLz/AmaYxjsNsve+1fNAQTiMHqR2vyeF0OTZg0kM2X7GEiOGvu+5QpfVQFysFtnhjo 1jN8JoGteLB9rY9kcXFk3w6Mj4XNeJhvj4FcP6juexNQwcvhZcFAgkHv5uGmEvjiINLY 0QAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=wPTu7PpAzvdziq3/jV7emF20z05MfpmFU4LV+7UF7oE=; b=F9WAgPyAn5p1p9SSSHltAMFxlYqj/25DK/bEAa1K9dQS4/yAZ5dlJ7F7fWnU9dUwtb Vai55CmHOUUKTYaOorsJzoA4dNNCXBl14P6Uk5j9g2G+c8FDK7VmOpGT8y/f6X6YktBJ KrJ2wGcAhz886aKMZMwy4qJkOS8Z1HHT1UgBEoZ/laCmIjP3BWMmYK3uGY0aEZliTY8N Z91TwZGt62Et0/1gn2zsS79uu6L2uX8VLdLeJ3AAvjNz0s+YrX7nrkCkclI0UZASpkyp bfpSIGtdij01onh3/ycw0UR2Jvuzf16p1pHgsdyiIeuGS7UiYPocoX5IJDUihnD8sbk1 tsjQ== X-Gm-Message-State: ABuFfogzDrofwChS0/HY1UiF23eAOYKfNJMLGGBnf0YWMrgeP9rsjjSh nVd0srwsxTCgzgE1/1aWxUoGJQ== X-Google-Smtp-Source: ACcGV63phi+8pNKdaqxXwMnSySzAIiiPa1PMOZucXXzmPQCGbRVJK589yd/S9kvpoVhnybNkQcT8SA== X-Received: by 2002:adf:c3cd:: with SMTP id d13-v6mr866500wrg.68.1539250050525; Thu, 11 Oct 2018 02:27:30 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:7489:ccd2:f7c:1d15? ([2001:660:330f:a4:7489:ccd2:f7c:1d15]) by smtp.gmail.com with ESMTPSA id g15-v6sm19740735wrp.56.2018.10.11.02.27.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 02:27:29 -0700 (PDT) From: Luigi Iannone Message-Id: <4C08DC39-6987-4D13-B52E-59CD8A612363@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_5CDE9D80-6CE9-4B65-8273-5B35891D55ED" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Thu, 11 Oct 2018 11:27:33 +0200 In-Reply-To: Cc: Tom Herbert , pidloc@ietf.org To: sarikaya@ieee.org References: X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Pidloc] draft-nordmark-id-loc-privacy X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 09:27:34 -0000 --Apple-Mail=_5CDE9D80-6CE9-4B65-8273-5B35891D55ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 5 Oct 2018, at 17:09, Behcet Sarikaya = wrote: >=20 >=20 > Sure, it could be considered, but the benefits of exposing a third > party to identifier/locator mappings would have to be weighed against > the cost. The potential cost is weakened user privacy and security. > Locators will convey geo location in a mobile network, so if someone > knows identifier to locator mapping, then they know location of node > with that identifier. But more than that, knowledge of > identifier/locator mappings allow correlations to be made between > identifiers. For instance, if a device is using some number of > untrackable and uncorrelatable identifiers for privacy, knowledge of > identifier to locator mappings allows correlations to be made and the > identifiers that belong to the device can be deduced and the users can > be tracked. >=20 >=20 > Absolutely. >=20 > One reason why I posted this mail was to encourage the discussion of = solution approaches in different=20 > IdLoc protocols. > How could we treat each of cases of Family and Friends, Industrial = IoT, etc. in ILA, ILNP, and LISP? Not sure I follow the question here.=20 You mean how these protocol can behave in the listed scenarios or how = these protocol can avoid tracking ID? Ciao L. > What about the three points in Section 6? >=20 > Behcet >=20 > --=20 > Pidloc mailing list > Pidloc@ietf.org > https://www.ietf.org/mailman/listinfo/pidloc --Apple-Mail=_5CDE9D80-6CE9-4B65-8273-5B35891D55ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 5 Oct 2018, at 17:09, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:


Sure, it could be considered, but the benefits of exposing a third
party to identifier/locator mappings would have to be weighed against
the cost. The potential cost is weakened user privacy and security.
Locators will convey geo location in a mobile network, so if someone
knows identifier to locator mapping, then they know location of node
with that identifier. But more than that, knowledge of
identifier/locator mappings allow correlations to be made between
identifiers. For instance, if a device is using some number of
untrackable and uncorrelatable identifiers for privacy, knowledge of
identifier to locator mappings allows correlations to be made and the
identifiers that belong to the device can be deduced and the users = can
be tracked.


Absolutely.

One reason why I posted this mail = was to encourage the discussion of solution approaches in = different 
IdLoc protocols.
How could we treat each of cases of Family and Friends, = Industrial IoT, etc. in ILA, ILNP, and = LISP?

Not sure I follow the question = here. 

You mean how these = protocol can behave in the listed scenarios or how these protocol can = avoid tracking ID?

Ciao

L.


What about the three points in Section = 6?

Behcet

--
Pidloc mailing list
Pidloc@ietf.org
https://www.ietf.org/mailman/listinfo/pidloc

= --Apple-Mail=_5CDE9D80-6CE9-4B65-8273-5B35891D55ED-- From nobody Fri Oct 12 07:56:08 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0690E130DCB for ; Fri, 12 Oct 2018 07:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDTD7SWGyDXP for ; Fri, 12 Oct 2018 07:56:03 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678AD130E0C for ; Fri, 12 Oct 2018 07:56:03 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id 193-v6so13182521wme.3 for ; Fri, 12 Oct 2018 07:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to:cc; bh=E73I6ZBOqBgAnRqPlXnmW36vr8qo7r5rYykZ0/YMBJ4=; b=ADfnWdBvrVKQWo6zBd2SlkLB+xIqJmS9XaV3nqZngGRIEnSC/HxI8PM+JA+u29mNNu gicmuKjMoGuIVLLHW0TBGDD8kC64NmbvfQdmvUdDrjsz5rh55zoz3x4L8CSCq1k+z543 7HCs1P8SBvioXoBDkOvhHRpz/JVfuXXm54ott6sMM4dF/0xigGiJIMl5I8CJPdh4ocDq YhQj5xvUfiTMJ6qcIoRcxD8xLTfoTS3Lx+ErMB/lfvg6iZHCALAtJJvmLpn9vedC35sB q2N5dM+QSd3RZaVApVZDu5MUcY6gXyjkwYcdH61zifF3oAZ8IFywcueTeHapNLInue3/ eT6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:cc; bh=E73I6ZBOqBgAnRqPlXnmW36vr8qo7r5rYykZ0/YMBJ4=; b=FM9OaAbYAviAMKV1s9oO5wl1Wfeac6auRcNI/hjDgHbNcfXeddP41bIiBEBhZGEszy b/6ojlUqvjoYTH3yrZJT3q+QtFNSGpleWtjyXHg0rEsMG36FD5nB/Mun2LwfceNHzQnK sXdy61H0Y0nYnnnZGVjxlal4YOMrKJh0ws9PgP31hzVtovS6i4SWClliyRbHvcgM/Pko M59fnsyL7Z+NESafJOsffqieAvdbeCK48+xj5FkiVSQhqr777kbs9GXqWMPh97eQWZ1Y AXd7eEhyzo2tyRlPwNaes8qXBoe8Dg4/Oa7rv+h/fdeh2q0//c2PBbr5OpaYHLWxxAMu c2HA== X-Gm-Message-State: ABuFfojCoi6lwy3+Zdkqkg54fTkiQHKCGJDVPaV94ZyQbOkU41Bg+MUj xif3tI9XSHEvlIcT16srTNSSzgKsB3Vkbn0Vj12FzyZftuc= X-Google-Smtp-Source: ACcGV62M/2g8JkmFW7EYtWHxz0edMSpPKso4db42BLUwkOB81LUS3Vg6DAjnf6LrsQHxQi/8nPI47+c2WMkY/kIjgMc= X-Received: by 2002:a7b:c259:: with SMTP id b25-v6mr5262230wmj.138.1539356161697; Fri, 12 Oct 2018 07:56:01 -0700 (PDT) MIME-Version: 1.0 Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Fri, 12 Oct 2018 09:55:50 -0500 Message-ID: To: pidloc@ietf.org Cc: Dirk.von-Hugo@telekom.de Content-Type: multipart/alternative; boundary="000000000000336df50578094935" Archived-At: Subject: [Pidloc] Encoding Routing in FAST X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 14:56:06 -0000 --000000000000336df50578094935 Content-Type: text/plain; charset="UTF-8" Hi all, Tom Herbert published a draft https://tools.ietf.org/html/draft-herbert-route-fast-00 which describes a solution by which the client (mobile node) can send its locator to the sender. Tom defined the locator encoding for ILA and the network seems to be specific to ILA. However I believe this design can be generalized to other IdLoc protocols or at least the locator encoding could be reused.. Basically this draft represents a solution (ILA based) for the locator sharing cases mentioned in Erik's draft. Any comments? Behcet --000000000000336df50578094935 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Tom Herbert published a draft


which desc= ribes a solution by which the client (mobile node) can send its locator to = the sender.

Tom defined the locator encoding for I= LA and the network seems to be specific to ILA.
However I believe= this design can be generalized to other IdLoc protocols or at least the lo= cator encoding could be reused..

Basically this dr= aft represents a solution (ILA based) for the locator sharing cases mention= ed in Erik's draft.

Any comments?
Behcet
--000000000000336df50578094935-- From nobody Fri Oct 12 10:20:25 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26F7130E5A for ; Fri, 12 Oct 2018 10:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imXYGFUPJu1e for ; Fri, 12 Oct 2018 10:20:17 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C460E130E51 for ; Fri, 12 Oct 2018 10:20:17 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id l191-v6so19832254ita.4 for ; Fri, 12 Oct 2018 10:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4g+ySNdgHy/sBPIWu4eGa9wtjxmtqNrtrfJ6KY68QAs=; b=uNKzLq1ouvqmf1lvsrnGs5vBplKm4D0k6E/q5BlTwAmwmKu3/ThTYglyUyg5Zh6iy9 OYYM7GFQZM2xmZzfXlXhwLbJB5GOSYEQhVw1uAT8PFB+LYLEtH8x3JjhT4v87r9aBg6M V3xZOMXGNpMDExnEgk0yfPHdhGqizMwE+gNmdsOzkUwc0RvPUW56SZfWq9gGsqdGcG71 OxYhh2/++L++aBVB2n6uEWIATmhWASYu1mDXFyIIa4xitmIEZx1mqmiFAFlFd9k/yoU3 xc/KDld6Pw2j4LarbizYfn6A1SvjUFi0ebMzoiwU1tOzUhNGpslsSHjyYX2qL/McTzw2 fe+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4g+ySNdgHy/sBPIWu4eGa9wtjxmtqNrtrfJ6KY68QAs=; b=L3rhKx/z7y/0vWIvUtm5QK5VkW/YVc+Q2L9giIqwQaqAPFti5VPrwS1rp84bFnOMaM +/+j7pTEyTAKXKzrelOUp7NPg0OLvxgwNYU0q+trPDNXQS9G77UYFKKubB9gfAyrQ2Q1 YEf9c2UkIMOuKFn47Af1shAZF4McnFJhxqNqhP3xof89FebzWsLgnDnxJNysOqk52c64 o4pxLdMshoTvG4nwBKRF9unnoZFDXj+tdtnALEEummlku326P14iGO2kN0YVg5+hsgfk fK6Ug97y12XP7NBnTbcrjJN2Nf6j7XjS9q3FHBC7nYmmHgo5Ng0kipEjwBMBzbiClc9q JnFw== X-Gm-Message-State: ABuFfoicEn61JV78Rg/M2Q7+Xbmn8a3vFktPaTGQIyntIr5ruV6A08/t 8T1lB58dZXO9b0m5Bg5y9ATZEXGzibhnTNlLaWy96qd9 X-Google-Smtp-Source: ACcGV63sMz0poWGzwtnxPlOaLc3IDI4CdufK2tukHCYYbKelfdhwFPvlFMx2gymHmXmxIxya9uxgE9QUpT+TFHZ+CXU= X-Received: by 2002:a24:3c0a:: with SMTP id m10-v6mr5380894ita.15.1539364816692; Fri, 12 Oct 2018 10:20:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Fri, 12 Oct 2018 10:20:05 -0700 Message-ID: To: Behcet Sarikaya Cc: pidloc@ietf.org, dirk.von-hugo@telekom.de Content-Type: multipart/alternative; boundary="0000000000001441fa05780b4dae" Archived-At: Subject: Re: [Pidloc] Encoding Routing in FAST X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 17:20:22 -0000 --0000000000001441fa05780b4dae Content-Type: text/plain; charset="UTF-8" On Fri, Oct 12, 2018, 7:56 AM Behcet Sarikaya wrote: > Hi all, > > Tom Herbert published a draft > > https://tools.ietf.org/html/draft-herbert-route-fast-00 > > which describes a solution by which the client (mobile node) can send its > locator to the sender. > > Tom defined the locator encoding for ILA and the network seems to be > specific to ILA. > However I believe this design can be generalized to other IdLoc protocols > or at least the locator encoding could be reused.. > Hi Behcet, Thanks for posting and making connection. Yes, ILA is an example. Tickets can contain other types of locators or information. > > Basically this draft represents a solution (ILA based) for the locator > sharing cases mentioned in Erik's draft. > It might be a little different in that regard. FAST could encode locator for return path in a ticket. Peer just reflects ticket and doesn't know about locator, it's used to route packets in destination provider network. So locators aren't actually being shared, they're transparently carried by third parties. Actual sharing could be done, for instance a locator as the ingress point in a network might ambiguous enough to avoid privacy concerns. A ticket might just contain locator (and network overlay method). In this case peers would need to parse tickets, so the might go down path of a standardized ticket format. Tom > Any comments? > > Behcet > -- > Pidloc mailing list > Pidloc@ietf.org > https://www.ietf.org/mailman/listinfo/pidloc > --0000000000001441fa05780b4dae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Fri, Oct 12, 2018, 7:56 AM Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
Hi a= ll,

Tom Herbert published a draft

https://tools.ietf.org/html/draft-herbert-= route-fast-00

which describes a solution b= y which the client (mobile node) can send its locator to the sender.
<= div>
Tom defined the locator encoding for ILA and the network= seems to be specific to ILA.
However I believe this design can b= e generalized to other IdLoc protocols or at least the locator encoding cou= ld be reused..

Hi Behcet,

Thanks for posting and making connection.

Yes, ILA is an example. Tickets can = contain other types of locators or information.

B= asically this draft represents a solution (ILA based) for the locator shari= ng cases mentioned in Erik's draft.

It might be a li= ttle different in that regard. FAST could encode locator for return path in= a ticket. Peer just reflects ticket and doesn't know about locator, it= 's used to route packets in destination provider network. So locators a= ren't actually being shared, they're transparently carried by third= parties.

Actual sharing= could be done, for instance a locator as the ingress point in a network mi= ght ambiguous enough to avoid privacy concerns. A ticket might just contain= locator (and network overlay method). In this case peers would need to par= se tickets, so the might go down path of a standardized ticket format.

Tom
<= br>



Any comment= s?

Behcet
--
Pidloc mailing list
Pid= loc@ietf.org
https://www.ietf.org/mailman/listinfo/pidloc<= /a>
--0000000000001441fa05780b4dae-- From nobody Mon Oct 15 07:30:22 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3371130E08 for ; Mon, 15 Oct 2018 07:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ge1jgHNGbPqA for ; Mon, 15 Oct 2018 07:30:19 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74241130E81 for ; Mon, 15 Oct 2018 07:30:18 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id z204-v6so19944940wmc.5 for ; Mon, 15 Oct 2018 07:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=WKhvHAfXZ7eKyeLuNjPGG3s/iJUMpuMKa8QR7ZVqE3k=; b=JZIFY7Ug9+CIatIQbqeufG4b+BGBFDu2hwrK25EI+i6kiKVuzBcWyxvMLqZ81gef6Z uJPUOU8bGxHCDO7wr/NHzyMjR6+uIf/+X8fn+ArKeJ7nxAxQRacIpIWrpLyv/Cctpw18 CciWWn1J79cKfbmUDPzR9lZntY1Ps2HAkDJejw0Sz0OPdMwPLe4QSI/iaIPI1DireOJz xNmbC78WiQ/Jiv1gAfN4djb4PlPpetjIyjmMs/Jc4ihuJuhj9RDYq5GRbm9sUZG7gJGk 5Z7A99E5ZZwuoICiUHhQ/G2XY42nMudgpQnVrmgkRHoastBwmFMtmk47MTVbXy0eKNIB Y7og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=WKhvHAfXZ7eKyeLuNjPGG3s/iJUMpuMKa8QR7ZVqE3k=; b=VFLbTEKTxj6sza2O12nXJSYENU2/+9jJHmKZ2xWHqwbGqhD16zOwXfYQ2c/5d+Dg0Z EyzmWrmXhFwyo2Z45GAu9Dn3ABirN+W4JKmqeVd+HFxEdPtCtBvM5oQyQMutG0lwFS4A 4bYm+oAdn3BRhkFgMAkSbX8qP0+31uEjWwIBEhlU0lUI4Ak0wxDQKwls1HdqMQrGXa30 gPu2/Prg8caRYWIk6tiMUnbz4xkuB3YKaaBiGsTh8XqpNwqmddHzmL0vYfYICCUkGIoE qxyiytXSBRRq9paDyguqk7NriMogyE8PAWpHOt5OAgCaIhIPahgKJ7KW3w4Uxp37URkz zwdw== X-Gm-Message-State: ABuFfoiEFLWe6YMBTkkCgW6IOYbPtKx0Ur2b+EoF1pZGOvHlUnDCoegR Yj9tsO9Bq+pJZ83NV/D0ATzRypsyfYxfkERfcR8= X-Google-Smtp-Source: ACcGV615FZHWrJfMHM3KJgHZpsgrDy1CNUXQl3LVk52dckyN23K1VIlEBanaT4l+7Xzb7AAwA+bxW/EU6rTNccuZs0o= X-Received: by 2002:a1c:5702:: with SMTP id l2-v6mr12383143wmb.83.1539613816835; Mon, 15 Oct 2018 07:30:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Mon, 15 Oct 2018 09:30:05 -0500 Message-ID: To: Tom Herbert Cc: sarikaya@ieee.org, pidloc@ietf.org, dirk.von-hugo@telekom.de Content-Type: multipart/alternative; boundary="000000000000a4d3580578454654" Archived-At: Subject: Re: [Pidloc] Encoding Routing in FAST X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 14:30:21 -0000 --000000000000a4d3580578454654 Content-Type: text/plain; charset="UTF-8" Hi Tom, On Fri, Oct 12, 2018 at 12:20 PM Tom Herbert wrote: > > > On Fri, Oct 12, 2018, 7:56 AM Behcet Sarikaya > wrote: > >> Hi all, >> >> Tom Herbert published a draft >> >> https://tools.ietf.org/html/draft-herbert-route-fast-00 >> >> which describes a solution by which the client (mobile node) can send its >> locator to the sender. >> >> Tom defined the locator encoding for ILA and the network seems to be >> specific to ILA. >> However I believe this design can be generalized to other IdLoc protocols >> or at least the locator encoding could be reused.. >> > > Hi Behcet, > > Thanks for posting and making connection. > > Yes, ILA is an example. Tickets can contain other types of locators or > information. > >> >> Basically this draft represents a solution (ILA based) for the locator >> sharing cases mentioned in Erik's draft. >> > > It might be a little different in that regard. FAST could encode locator > for return path in a ticket. Peer just reflects ticket and doesn't know > about locator, it's used to route packets in destination provider network. > You mean source routing? Is this somehow related to SRv6? > So locators aren't actually being shared, they're transparently carried by > third parties. > > Actual sharing could be done, for instance a locator as the ingress point > in a network might ambiguous enough to avoid privacy concerns. A ticket > might just contain locator (and network overlay method). In this case peers > would need to parse tickets, so the might go down path of a standardized > ticket format. > > I don't quite understand these things well, I need to dig more into it. What I understood from you draft is that it is a UDP application, i.e. it is application layer solution, is this correct? Behcet > Tom > > > > >> Any comments? >> >> Behcet >> -- >> Pidloc mailing list >> Pidloc@ietf.org >> https://www.ietf.org/mailman/listinfo/pidloc >> > --000000000000a4d3580578454654 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,





On Fri, Oct 12, 2018, 7:56 AM Behcet = Sarikaya <sa= rikaya2012@gmail.com> wrote:
Hi all,

<= div>Tom Herbert published a draft


which describes a solution by which the client = (mobile node) can send its locator to the sender.

= Tom defined the locator encoding for ILA and the network seems to be specif= ic to ILA.
However I believe this design can be generalized to ot= her IdLoc protocols or at least the locator encoding could be reused..

Hi Behcet,

Thanks for posting and making connection.

Yes, ILA is an example. Tickets can contain other types= of locators or information.

Basically this draft= represents a solution (ILA based) for the locator sharing cases mentioned = in Erik's draft.

It might be a little different in t= hat regard. FAST could encode locator for return path in a ticket. Peer jus= t reflects ticket and doesn't know about locator, it's used to rout= e packets in destination provider network.
You mean source routing?

Is this some= how related to SRv6?

=C2=A0
So locators aren't ac= tually being shared, they're transparently carried by third parties.

Actual sharing could be do= ne, for instance a locator as the ingress point in a network might ambiguou= s enough to avoid privacy concerns. A ticket might just contain locator (an= d network overlay method). In this case peers would need to parse tickets, = so the might go down path of a standardized ticket format.


I don't quite u= nderstand these things well, I need to dig more into it.
What I u= nderstood from you draft is that it is a UDP application, i.e. it is applic= ation layer solution, is this correct?

Behcet=C2= =A0
Tom




Any comments?

<= div>Behcet
--
Pidloc mailing list
Pid= loc@ietf.org
https://www.ietf.org/mailman/listinfo/pidloc<= /a>
--000000000000a4d3580578454654-- From nobody Mon Oct 15 08:14:25 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C97F130EC2 for ; Mon, 15 Oct 2018 08:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMXSEqJXB0Vl for ; Mon, 15 Oct 2018 08:14:19 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D531130EB0 for ; Mon, 15 Oct 2018 08:14:19 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id l25-v6so14494331ioj.0 for ; Mon, 15 Oct 2018 08:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p0rhChWworyaPMLQhvXbAbUx7Z4g8eo8kx7QdcwXZSo=; b=OqO4pRXlUAcVWppIvIOVZLLAWKN0aYwidP6szGJ8lot8Dip3mr3rhZKO5Q3pRUa3Wh Nb6X0Gv5uIK4A96Jxq3s2Cj2kLwYyz35w42eo7iGFKe2J8terOpZnXUNJ+P1mC/98IH2 hsskMDQIBwwH3t/RzhUcizir+OYBTZHJoUoLwpPWkO9nBXZAiibQwsJQp1X4zlgoKRvN mXU8qmZNJbXqu+CXb7FaumrxgsCUn4JZ+acKjWzGK1b6qh+YrktBoXnazQoxGRm4OtvZ Dm2yhQvcedw8Wq3Jl43RIeTTyzBhoSGEDan0Q5MFfXt5gm5oVVOXLrmhx4Qz/17Pohpl poMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p0rhChWworyaPMLQhvXbAbUx7Z4g8eo8kx7QdcwXZSo=; b=dliI8p0hIYT38tFbR7QvBuwXoH0MrMFxpCI6h86TJyXKeRxrLSfmJU+znWkkNTisPc +kkH9BFtyg0HIJjn5Zsn9qILEj802p5ycoAhkxCGIfnrOUpgRIgqO4DQ9v5khi3n/ZrD KKK1C2JKIbskJFBhRC4HyrWAOeawK7m1fhTWf/Yj8cyzz1Ozh5bmO1X/KLtg+TTGqgGS oDc61kDTwVFB+RcLZpr/sJOkYVUbO6g46za3n4F06VWmI5mKHinz7MuCwX05WZpUA5k0 +hqQVX6nUegDHwzrf+ug6FAse+08Oe6pe3Rf0nRx/BYEIkXeBKA3e4yA0bLGHHpmRpO4 uJ4g== X-Gm-Message-State: ABuFfoiyN4exZEIm86PxRySNG5XQRbIyY/ioF0degTXV/slnC5cdjNqI OTeKvuQfWPMqI2QxD/y4ZwvG9/VTx3JEyNxH6cZlZg== X-Google-Smtp-Source: ACcGV61xhUcjwyMkyDB0LmSamFwjkkqKikd2lFvEFWwgGirh/lcSjCKn0GYRAe0fesAkenuV2OItdaE3tvQWb/waGcg= X-Received: by 2002:a5e:8d02:: with SMTP id m2-v6mr13197212ioj.122.1539616458671; Mon, 15 Oct 2018 08:14:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Mon, 15 Oct 2018 08:14:07 -0700 Message-ID: To: Behcet Sarikaya Cc: pidloc@ietf.org, dirk.von-hugo@telekom.de Content-Type: multipart/alternative; boundary="0000000000001c21ae057845e485" Archived-At: Subject: Re: [Pidloc] Encoding Routing in FAST X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 15:14:24 -0000 --0000000000001c21ae057845e485 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 15, 2018, 7:30 AM Behcet Sarikaya wrote: > Hi Tom, > > > > On Fri, Oct 12, 2018 at 12:20 PM Tom Herbert wrote: > >> >> >> On Fri, Oct 12, 2018, 7:56 AM Behcet Sarikaya >> wrote: >> >>> Hi all, >>> >>> Tom Herbert published a draft >>> >>> https://tools.ietf.org/html/draft-herbert-route-fast-00 >>> >>> which describes a solution by which the client (mobile node) can send >>> its locator to the sender. >>> >>> Tom defined the locator encoding for ILA and the network seems to be >>> specific to ILA. >>> However I believe this design can be generalized to other IdLoc >>> protocols or at least the locator encoding could be reused.. >>> >> >> Hi Behcet, >> >> Thanks for posting and making connection. >> >> Yes, ILA is an example. Tickets can contain other types of locators or >> information. >> >>> >>> Basically this draft represents a solution (ILA based) for the locator >>> sharing cases mentioned in Erik's draft. >>> >> >> It might be a little different in that regard. FAST could encode locator >> for return path in a ticket. Peer just reflects ticket and doesn't know >> about locator, it's used to route packets in destination provider network. >> > > You mean source routing? > It can be used as type of source routing, but it's more generic. The ability to specify routing and services in return path is critical. > Is this somehow related to SRv6? > Not really. SRv6 SIDs could be encoded in a ticket in a compressed form is possible. > > > >> So locators aren't actually being shared, they're transparently carried >> by third parties. >> >> Actual sharing could be done, for instance a locator as the ingress point >> in a network might ambiguous enough to avoid privacy concerns. A ticket >> might just contain locator (and network overlay method). In this case peers >> would need to parse tickets, so the might go down path of a standardized >> ticket format. >> >> > I don't quite understand these things well, I need to dig more into it. > What I understood from you draft is that it is a UDP application, i.e. it > is application layer solution, is this correct? > No, it uses IPv6 Hop-by-Hop options. No encapsulation required. Tom > Behcet > >> Tom >> >> >> >> >>> Any comments? >>> >>> Behcet >>> -- >>> Pidloc mailing list >>> Pidloc@ietf.org >>> https://www.ietf.org/mailman/listinfo/pidloc >>> >> --0000000000001c21ae057845e485 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Hi Tom,


<= br>
On Fri, Oct 12, 2018 at 12:2= 0 PM Tom Herbert <tom@quantonium.net> wrote:


On Fri, Oct 12, 2018, 7:56 AM Behcet Sarikaya <s= arikaya2012@gmail.com> wrote:
Hi all,

=
Tom Herbert published a draft


which describes a solution by which= the client (mobile node) can send its locator to the sender.
Tom defined the locator encoding for ILA and the network seems = to be specific to ILA.
However I believe this design can be gener= alized to other IdLoc protocols or at least the locator encoding could be r= eused..
<= br>
Hi Behcet,

Thanks for posting and making connection.

Yes, ILA is an example. Tickets can contain= other types of locators or information.

Basicall= y this draft represents a solution (ILA based) for the locator sharing case= s mentioned in Erik's draft.
=

It might be a little di= fferent in that regard. FAST could encode locator for return path in a tick= et. Peer just reflects ticket and doesn't know about locator, it's = used to route packets in destination provider network.

You mean source routing?

It can be us= ed as type of source routing, but it's more generic. The ability to spe= cify routing and services in return path is critical.


Is this somehow related to SRv6?

Not really. SRv= 6 SIDs could be encoded in a ticket in a compressed form is possible.
=

=C2=A0
So loc= ators aren't actually being shared, they're transparently carried b= y third parties.

Actual = sharing could be done, for instance a locator as the ingress point in a net= work might ambiguous enough to avoid privacy concerns. A ticket might just = contain locator (and network overlay method). In this case peers would need= to parse tickets, so the might go down path of a standardized ticket forma= t.


= I don't quite understand these things well, I need to dig more into it.=
What I understood from you draft is that it is a UDP application= , i.e. it is application layer solution, is this correct?
=

No, = it uses IPv6 Hop-by-Hop options. No encapsulation required.

Tom

=

Behcet=C2= =A0
Tom




Any comments?

<= div>Behcet
--
Pidloc mailing list
Pidloc@ietf.org
https://www.ietf.org/mailman/listi= nfo/pidloc
--0000000000001c21ae057845e485-- From nobody Mon Oct 15 11:46:53 2018 Return-Path: X-Original-To: pidloc@ietfa.amsl.com Delivered-To: pidloc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAD9128BAC for ; Mon, 15 Oct 2018 11:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igz9cd79LfKK for ; Mon, 15 Oct 2018 11:46:50 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C02124C04 for ; Mon, 15 Oct 2018 11:46:49 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id l6-v6so22131630wrt.1 for ; Mon, 15 Oct 2018 11:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=badKJ/9YgbjAR7o5GbDSbFQSmEWEf1XL7milRzvPcVM=; b=SqgX6PITQkLFFOWfXYteF23wjFOzJ1IUOJSlw/XBAEmsLsJDdklLKsV+//1sugR7Xu AOSXVSRns+G4DPNVRi3SGAQGFqmXve9LHpvCFIBzsdBCl6LRd9UtIOyyE682MJXWi+Uu RD88I7iInfKrjIewsK7EaErIllf1Z2zJPDldLeTB5nsZWvOr/o2ybEAi5Gzg0VtWvv5M 5tri4PUgoM1DycVl7wfKtOM95K3F3ggj5xF272QZ5WUJyCViMx6xylV2L5mV2ERPTzbl y8eURQtdum77c2VeKhpYy/jSGp2F1TeiUPSs99HjHzgBn8hJzY6MkhCVxPIB4F88ZiFU aQ+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=badKJ/9YgbjAR7o5GbDSbFQSmEWEf1XL7milRzvPcVM=; b=H9V+Xg8DZFSJ+FIq296NTY1khDx+xPUnUm5JzHxBLlCJYfyLNHmapeUpFRwwxRfgJg 8YH5/AXTTn35F5Z5zgwJTAz1us1bWDrtCuH/+9DMFalBqQREAyGV6fu/ikG3VfgtqXkU gJaHkkYxm0833on5asiBxnX16/MhFXvngMhle4KAAxeyCYm+Ag9g9xPcsqyqqiKBeGZG 5AfnjDNAUmwquBx3ll1XtVSjN4CNe0xhqvGOJEg0cFdr7ocMtN68Tc3Ogc4xeuHLXF2d h8dreOwTHDMjJxqO8GpdwRGywYY1Rzj/4+oRC0iZrV/5rl2Lq8wnvTcv/CDiphLtNfWc SDWw== X-Gm-Message-State: ABuFfoiml1f8h13VitxfauCmS2P1+HdQi+W4y6EA4/l/Y16H3uIYvPlM ryIXOlPCmihzXTClvGYSxpql6nZZ814h0MQnBcYyNx3h X-Google-Smtp-Source: ACcGV61J0dKywJf7T2yugkyLQK8R/02OOF1h4hIzAO/e4caWVP/4I4vqC6+Y7TPBcI6eudKJIj97LFeHlEe4/7lewAc= X-Received: by 2002:a5d:680b:: with SMTP id w11-v6mr14506881wru.186.1539629208414; Mon, 15 Oct 2018 11:46:48 -0700 (PDT) MIME-Version: 1.0 References: <86F15094-3382-4D4F-AD45-C751117C3066@gigix.net> In-Reply-To: <86F15094-3382-4D4F-AD45-C751117C3066@gigix.net> Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Mon, 15 Oct 2018 13:46:37 -0500 Message-ID: To: Luigi Iannone Cc: pidloc@ietf.org Content-Type: multipart/alternative; boundary="0000000000000dad7b057848dc99" Archived-At: Subject: Re: [Pidloc] draft-nordmark-id-loc-privacy X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 18:46:52 -0000 --0000000000000dad7b057848dc99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Luigi, On Thu, Oct 11, 2018 at 3:56 AM Luigi Iannone wrote: > Hi, > > On 4 Oct 2018, at 17:02, Behcet Sarikaya wrote: > > [snip] > > > In Section 6, the draft points to some possibilities on how this limiting > can be achieved: > > 1. pointing a locator for some fixed anchor point, like PGW or UPF > > > This would be kind of a home agent, right? > In this case ww will end up with possibly a long stretch in the path > (depending on mobility). > > > Here pointing to a fixed anchor means that a locator is given from the fixed anchor's address space. This is a practice in use currently in 4G networks. The end result is that UE or mobile location can not be determined precisely from such a locator. > > 2. injecting routing prefixes for the ID prefixes into the normal routing > system > > > LISP has this approach described in RFC 6832. > > I think it is not completely disjoint from the previous point. The proxie= s > will become a =E2=80=9Cfixed anchor point=E2=80=9D. > > Or you had something else in mind? > > 3. not providing any stable locators across this boundary; only allow > ephemeral IP addresses per session or otherwise limited exposure. > > > When you say =E2=80=9Cephemeral IP addresses=E2=80=9D you mean the RLOCs = or the IDs? > ephemeral means a locator which is valid only for a short period of time. It is a locator not identifier. Behcet > > Ciao > > L. > > > > In short, the draft is coming up with a lot work to do. > We suggest that the group takes a close look into all these points and se= e > what we can do :-) > Regards, > Behcet & Dirk > -- > Pidloc mailing list > Pidloc@ietf.org > https://www.ietf.org/mailman/listinfo/pidloc > > > --0000000000000dad7b057848dc99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000000dad7b057848dc99--

Hi Luigi,

On Thu, Oct 11, 2018 at 3:56 AM Luigi Iannone <ggx@gigix.net> wrote:
Hi,

On 4 Oct 2018, at 17:02, Be= hcet Sarikaya <sarikaya2012@gmail.com> wrote:

[snip]


In Section 6, the draft points to some possibilities= on how this limiting can be achieved:

1. pointing a locator fo= r some fixed anchor point, like= PGW or UPF

This would be kind of a home agent, ri= ght?
In this case ww will end up with possibly a long stretch in = the path (depending on mobility).


=
Here pointing to a fixed anchor me= ans that a locator is given from the fixed anchor's address space. This= is a practice in use currently in 4G networks.
The end result is that UE or mobile location can not be determined p= recisely from such a locator.


=C2=A0

2. injecting routing prefixes for th= e ID prefixes into the normal r= outing system
=

LISP has this approach descr= ibed in RFC 6832.

I think it is not completely dis= joint from the previous point. The proxies will become a =E2=80=9Cfixed anc= hor point=E2=80=9D.

Or you had something else in m= ind?=C2=A0

3. not providing any stable locators across this boundary; only allow ephemeral IP addresses per sess= ion or otherwise limited exposu= re.

When you say =E2=80=9Cephemeral IP addresses= =E2=80=9D you mean the RLOCs or the IDs?

ephemeral means a locator which is valid o= nly for a short period of time.
=C2=A0It = is a locator not identifier.

Behcet

Ciao

L= .


<= div dir=3D"ltr">

In short, the draft is coming up with a lot work to do.<= /div>
We suggest that the group takes a close look int= o all these points and see what we can do :-)
Regards,
Behcet & Dirk
--
Pidloc mailing list
Pidloc@ietf.org
https://www.ietf.org/mailman/listinfo/pidloc=