Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02

Tom Herbert <tom@herbertland.com> Tue, 17 October 2017 01:24 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0491323B8 for <ideas@ietfa.amsl.com>; Mon, 16 Oct 2017 18:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 1XxTyzEuZHSv for <ideas@ietfa.amsl.com>; Mon, 16 Oct 2017 18:24:57 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 3372F12ECEC for <ideas@ietf.org>; Mon, 16 Oct 2017 18:24:57 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id b15so165711qkg.9 for <ideas@ietf.org>; Mon, 16 Oct 2017 18:24:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cU2nXvKrDl9IgeiFUz6t/BG2XdHB7bKcMqMcuxbSB+s=; b=AVknvQQ74MNb8jaY1IAc+M9IvilGBLxjYsoXAaY9pFO0i2YKRAEJUEfQFMpvSH7EYz E5gUYgbRv1JeIf5jPV+ay+Vw215Ac6Esncz7ushbpZ0BPPvQvHz0vpM11T2wheGdb45l i0lEN1PiwRPI+GZ7eo344hEXytvi5YlgNXeYmjtZKjrAzmXq9B+rwd1APRnaR2lS6OAZ +ZPTBFUtS7GzS6gcO2AzEQIQI+383bFcSOvn6LpezTWmpWLpTdWKb6+gjqcSsx6Kfs5v Dq22PCH4oaZpT/tYjOgClAaZGPK1crL0HtGe3kX26l4rUd5eQWGUabSkSrsDFUOjaFjw 2xkw==
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:content-transfer-encoding; bh=cU2nXvKrDl9IgeiFUz6t/BG2XdHB7bKcMqMcuxbSB+s=; b=jYQ1PPuxS9KYbRojnXn/qRn5c6T0cKZWmvLQi1RXO/Uh75cAmB7RSt0DL1SlSHTZkm nqOb1gQjgOyjM474mVRlYTVopp/2oO5xrfxi7iHjIay8N0ck3s3GryWnAFXkKXvKW7DY AOTlFEnKqtXOXown1WPmDqGqiz5OALdBEdDOC9YanSn9GcFTx+A9aSTzjsIMGBFfMsvX wnQUaZmuguR5ELGHHUod79FWCEsHGTizje8MOr72ASNj/Vx3qVePqu1WC6p+/I876Phn SzfF8ZIbKCfVFSCRK+gw/AXgfKWKodmlPoOvYrzmpTa+BX00Qidvk7rtYoN+rFjpX/4T QCDg==
X-Gm-Message-State: AMCzsaVsUyR7Hcks5jl4lWX1/w52qUMxcYLLOE8dQRk89IRrvJG0HIGL 7jWT6B9QAhayDdElgDK7JIvSL4UqEuD2PLQNhmOrhPbD
X-Google-Smtp-Source: ABhQp+QimqK1fpGiwpHuk7fgjjLmCFAFzsuBr9dpZDbmxpeWzpnN3kI3fq9dXZG0B5ZxW9B1BWOdsKQImAyH5sTozlo=
X-Received: by 10.55.89.65 with SMTP id n62mr15115258qkb.51.1508203496016; Mon, 16 Oct 2017 18:24:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Mon, 16 Oct 2017 18:24:55 -0700 (PDT)
In-Reply-To: <25B4902B1192E84696414485F572685413513F1D@sjceml521-mbs.china.huawei.com>
References: <CALx6S37N5GSVG95mOv2QKu5TZ6dRGehhTriXJ5eqTG+MQZiQGg@mail.gmail.com> <25B4902B1192E84696414485F572685413513F1D@sjceml521-mbs.china.huawei.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 16 Oct 2017 18:24:55 -0700
Message-ID: <CALx6S34Rui6iC4joVeMDE7YsoxMt2Zjz44FxDtyDaH0=bUEJSw@mail.gmail.com>
To: Uma Chunduri <uma.chunduri@huawei.com>
Cc: "ideas@ietf.org" <ideas@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/rWZsErvPAgSx3M0mstcV-rJv_pQ>
Subject: Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Oct 2017 01:24:59 -0000

On Mon, Oct 16, 2017 at 5:31 PM, Uma Chunduri <uma.chunduri@huawei.com>; wrote:
> Thx for the feedback on this version. I saw Alex's responses - some more of it below.
>
> --
> Uma C.
>
> ----
>
>         >I think the most critical use case isn't described here. It is in mobility where a devices may have many thousands of identifiers assigned to it. When the device moves, all the identifiers must move
>                > with it and want this to be performed in one operation in the infrastructure. Without the ability to perform a group operation, identifier-locator might not be able to scale. Today this is done by virtue
>                >of moving a device prefix, but device prefixes do not have reasonable privacy or security properties (see ongoing discussion in v6 ops about host prefix assignment and privacy ramifications).
> [Uma]: Yes.
>
>         >The phrase "long-lived" is ill-defined. Not just in this document, but I've noticed this popping up in other WGs. The obvious problem is that there is no common definition of the time it takes something to be long-lived.
>                 >Someone might say a day, another an hour, a minute, a second, ten milliseconds etc. In identifier-locator, it may be that a node wants to use a different identifier in every connection it creates which is the best privacy it can get.
> [Uma]:  It's relative. This is not new and not introduced in IDEAS.  This is nothing but HIT in HIP or EID in LISP (which are used for location resolution today).  The context of this usage is to differentiate from the one time anonymous identifiers used in the data plane.. Can clarify further.
>
>         >This by the way is why I don't think end user devices should ever participate in identifier-locator protocols...
>  [Uma]: You  are making a pretty broad statement here.  Which device uses this is orthogonal to IDEAS.   We have a host based solution (ID/LOC) HIP  and a network based solution LISP.
>
Uma,

This problem I highlighted would only exist on public networks where
end user devices are not under complete control of the
infrastructure-- i.e. smart phones on a public carrier network. In a
private data center for instance, where all hosts can be controlled,
there is no issue in running identifier-locator on hosts and that in
fact is a common deployment of network virtualization.

The exploit I'm conjecturing would work like this:

* Suppose that a UE (e.g. a smartphone) participating in an
identifier/locator protocols is hacked.
* The only thing the hacker does is to tap all packets sent or
received on wireless network interface.
* In order to be able to tap packets all a user needs to do is "root"
the Android device (that is gain root access) and then run tcpdump.
This is not difficult to do, there are instructions on the web how to
set this up.
* Once tcpdump is running, the hacker can now see the locators of
destinations the device is sending packets and can easily correlate
those packets to the higher level communications. It can also derive
their device's locator by looking at received packets.
* The hacker can then just drive around sending traffic between two
devices in their car. From this, they can create a geo map of
locators. The granularity of this map is the granularity of the
locators. Presumably, locators might refer to eNodeBs, so smaller
cells yield more accurate locator to physical location mapping.
* Given that one hacker can do this, then thousands will do it and web
sites will spring up that provide locator geo maps in a mash up.
* Efforts to obfuscate or rotate identifiers does not help much here.
Obfuscation complicates routing in the network such that translations
need to happen anyway. Periodic rotation of locators is defeated if
there are enough devices doing the mapping to keep the maps up to
date.
* The net effect is that this enables stalkers. An individual simply
initiates a communication with their target. For instance, this could
be a chat or phone call. If in doing this the locators for the device
belonging to the target are made visible to the hacker, then the
physical location of the target can be deduced using the locator geo
maps described above to the accuracy of the locator to physical world
maps.

It's true this may be orthogonal to the design of a mapping system or
identifier-locator protocol, however it does illustrate the dangers of
not adequately protecting sensitive information. Anyone who works at
companies like Apple and Google that regularly collect device
geo-location can vouch that it is among the most sensitive of all the
PII they collect. Accordingly, they implement extremely strong access
controls to the point that even that only a tiny number of employees
can directly access the data.

Tom

>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas