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

Uma Chunduri <> Thu, 05 October 2017 00:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D9C8133188; Wed, 4 Oct 2017 17:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DTpNCjOJcAhQ; Wed, 4 Oct 2017 17:46:44 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92CF81344C9; Wed, 4 Oct 2017 17:46:30 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DWW22098; Thu, 05 Oct 2017 00:46:28 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 5 Oct 2017 01:46:27 +0100
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 17:46:22 -0700
From: Uma Chunduri <>
To: Jari Arkko <>, "Eggert, Lars" <>
CC: "" <>, "" <>
Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas)
Thread-Index: AQHTPUTpHf/1VBiG/k6j1YoUSQ9obKLUrfeA//+xkRA=
Date: Thu, 5 Oct 2017 00:46:21 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
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=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6c3af99f58e1567df8b7e11a874c70d8
Archived-At: <>
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Oct 2017 00:46:49 -0000


	> 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 can be leveraged here too.

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

Uma C.