Re: [Pidloc] draft-nordmark-id-loc-privacy

Behcet Sarikaya <sarikaya2012@gmail.com> Fri, 05 October 2018 15:10 UTC

Return-Path: <sarikaya2012@gmail.com>
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 <pidloc@ietfa.amsl.com>; 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 <pidloc@ietfa.amsl.com>; 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 <pidloc@ietf.org>; Fri, 5 Oct 2018 08:10:10 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id x12-v6so13911617wru.8 for <pidloc@ietf.org>; 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: <CAC8QAcf-w6QhFXAf9c2y69-aWjwoLWJvuPP0Wgp4iT=Qz9+6tQ@mail.gmail.com> <CAPDqMeos1-=xTAdnOw893C3RkiM9wrt7_njg+jDEasHa-kz1zg@mail.gmail.com> <CAC8QAcct_h7Ti+U0U0McF2GSii+ynJZQg4ZO_2058XhPm6dy4w@mail.gmail.com> <CAPDqMepFhwFwU_G6Wnj+wdtKXT7BX1mPMwQpVkJEEY688FoXVQ@mail.gmail.com>
In-Reply-To: <CAPDqMepFhwFwU_G6Wnj+wdtKXT7BX1mPMwQpVkJEEY688FoXVQ@mail.gmail.com>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Fri, 05 Oct 2018 10:09:57 -0500
Message-ID: <CAC8QAcdLqj1zMuitq-88dmHEZ5YXyYwR7ytwJftdcPwBn1wnDg@mail.gmail.com>
To: Tom Herbert <tom@quantonium.net>
Cc: pidloc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ca870405777caaf9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pidloc/HhyGD7exAytvct21jb29vYYU3jU>
Subject: Re: [Pidloc] draft-nordmark-id-loc-privacy
X-BeenThere: pidloc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <pidloc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pidloc>, <mailto:pidloc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pidloc/>
List-Post: <mailto:pidloc@ietf.org>
List-Help: <mailto:pidloc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pidloc>, <mailto:pidloc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Oct 2018 15:10:13 -0000

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

>
>