Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)

Uma Chunduri <uma.chunduri@huawei.com> Thu, 05 October 2017 00:46 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 3D9C8133188; Wed, 4 Oct 2017 17:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 DTpNCjOJcAhQ; Wed, 4 Oct 2017 17:46:44 -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 92CF81344C9; Wed, 4 Oct 2017 17:46:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWW22098; Thu, 05 Oct 2017 00:46:28 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 5 Oct 2017 01:46:27 +0100
Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 17:46:22 -0700
From: Uma Chunduri <uma.chunduri@huawei.com>
To: Jari Arkko <jari.arkko@piuha.net>, "Eggert, Lars" <lars@netapp.com>
CC: "ideas@ietf.org" <ideas@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas)
Thread-Index: AQHTPUTpHf/1VBiG/k6j1YoUSQ9obKLUrfeA//+xkRA=
Date: Thu, 05 Oct 2017 00:46:21 +0000
Message-ID: <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <D7D4AEE9-3BD0-4C8F-BCC6-7185AF7D37BA@netapp.com> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net>
In-Reply-To: <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.49.159]
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.59D580E4.00C1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6c3af99f58e1567df8b7e11a874c70d8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/hXdwAWk-g7uucTcagMDla5csLl4>
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)
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: Thu, 05 Oct 2017 00:46:49 -0000

Jari,

	> Secondly, I’m have similar concerns to Christian, Lars, Stephen and others.
	> More specifically, at the BOF the goal seemed to be creation of infrastructures to manage and track identities, and to bind them to entities that assigned them. 
                > I am not at all sure that’s a desirable direction. And the charter says little about the assumptions behind the work.
	>To expand a bit on these concerns, the proposed work doesn’t consider at all the types of identifier operations that work on ephemeral identities (e.g., HIP, MP-TCP). 
                >It would be sad if we created systems that forced us to manage identifiers from some infrastructure when all we needed to do in a particular case was “prove that you are 
                >the same entity as in the other connection”, which can be done e2e and requires no infrastructure, or permanent identifiers.


I hope you agree, when we talk about a mapping system - it's important 

     - Who can update the mappings 
     - Who can access the mappings 

Both needs AUTH and hence an Identity (EAP or whatever mechanism with anonymous or pseudonymous access) & provider ==> essentially an access ID.
If you don't restrict who can access the mapping (2nd question) one would get a primitive system, but the ability to provide some control is useful for lot of scenarios (including lot of IoT/Vehicular nodes having mobility and multi-access). 
In any case, you should still restrict who can update whose mappings.

You need this "standardized" system with well-defined interfaces  for
   a.  lot of local IoT/enterprise deployments and 
   b.  can be  extended through a federated system where only mapping of Identifiers and locations can be shared among providers for further reachability (central to any mobility system, regardless of which ID/LOC protocol).

With regard to privacy concerns raised, I still believe there are IETF approved solutions like https://tools.ietf.org/wg/abfab/ can be leveraged here too.

What data plane identifier is another aspect and that is governed by ID/LOC protocols.

--
Uma C.