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

Uma Chunduri <uma.chunduri@huawei.com> Tue, 17 October 2017 21:17 UTC

Return-Path: <uma.chunduri@huawei.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 0930313219F for <ideas@ietfa.amsl.com>; Tue, 17 Oct 2017 14:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 md1teeTliY7n for <ideas@ietfa.amsl.com>; Tue, 17 Oct 2017 14:17:08 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FCE3132331 for <ideas@ietf.org>; Tue, 17 Oct 2017 14:17:08 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQV37883; Tue, 17 Oct 2017 21:17:06 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 17 Oct 2017 22:17:05 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001; Tue, 17 Oct 2017 14:17:01 -0700
From: Uma Chunduri <uma.chunduri@huawei.com>
To: Tom Herbert <tom@herbertland.com>
CC: "ideas@ietf.org" <ideas@ietf.org>
Thread-Topic: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
Thread-Index: AQHTRqsmzhTtyxc/w0CsYMOotXbfdqLnLFXQgACJJ4CAAJq/MA==
Date: Tue, 17 Oct 2017 21:17:00 +0000
Message-ID: <25B4902B1192E84696414485F572685413514329@sjceml521-mbs.china.huawei.com>
References: <CALx6S37N5GSVG95mOv2QKu5TZ6dRGehhTriXJ5eqTG+MQZiQGg@mail.gmail.com> <25B4902B1192E84696414485F572685413513F1D@sjceml521-mbs.china.huawei.com> <CALx6S34Rui6iC4joVeMDE7YsoxMt2Zjz44FxDtyDaH0=bUEJSw@mail.gmail.com>
In-Reply-To: <CALx6S34Rui6iC4joVeMDE7YsoxMt2Zjz44FxDtyDaH0=bUEJSw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.49.175]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59E67353.001A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 29cc6edb49b2ff973d78594621a6b010
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/cZl6TCayKNLMkVlfNjqy_hY_B5U>
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 21:17:10 -0000

Coming back to the IDEAS work, one of the goals is to create a standardized mapping system with various ID services (mobility, access security, pub/sub,  grouping etc). 
There are various enterprise deployments where these services are needed and the ability to authorize  who can update mapping and who can request mapping is critical for deploying some of  these services. 
For ILA or  for DC VM mobility some of the services may not be needed or Identity is an overhead (but I saw from your responses earlier, you need authorization on who can update in a multi tenenant environments) 
and that can be made optional if not needed.  But, I see you are arguing on both sides.  If you have a better solution to address the above needs please share it.

--
Uma C.

-----Original Message-----
From: Tom Herbert [mailto:tom@herbertland.com] 
Sent: Monday, October 16, 2017 6:25 PM
To: Uma Chunduri <uma.chunduri@huawei.com>;
Cc: ideas@ietf.org
Subject: Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
...

	>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.
[Uma]: Sure, agree. And you need a mapping system with standardized interfaces and a control protocol to interact to addressing this space.

	>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.
[Uma]: There are so many cases, where  things need to be handled, which includes not only hacked but lost/stolen devices etc. There is something called revocation or disabling the device based on the auth. method used in the device by the provider.

                ...

	>* 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.
[Uma]: Obfuscation obviously doesn't solve all the evils. It has its own place and if we truly care use end to end encryption where ever is needed.
                Again, data plane constructs and mechanisms for protection are under the purview of the underlying ID/LOC protocol in question. IDEAS can only help augment some of the features needed for these protocols.

	>It's true this may be orthogonal to the design of a mapping system..
[Uma]: Yes, it's mostly orthogonal  to IDEAS.

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

[Uma]: You are right. This is exactly  what we have been arguing as well.  Any data that is sensitive will have strong access controls and not publicly exposed. 
 	Also, I am not understanding the above logic fully  - because all sorts of PII is collected in various applications or just because of the fact that you are on your cellular device your provider can track you (or how these are protected today). 
	Privacy seems more of a misnomer sometimes (from the apps, to browser to the cellular devices and this  only further proliferates with all sorts of  devices doing M2M would be on various networks soon).