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

Jari Arkko <> Wed, 04 October 2017 21:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C884B1321A2; Wed, 4 Oct 2017 14:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iriUvU7EiX4y; Wed, 4 Oct 2017 14:41:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B2D9E1344C9; Wed, 4 Oct 2017 14:41:49 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D05602D0E1; Thu, 5 Oct 2017 00:41:48 +0300 (EEST) (envelope-from
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r1fbW5q2eaWE; Thu, 5 Oct 2017 00:41:48 +0300 (EEST)
Received: from [] ( [IPv6:2001:14b8:1829::130]) by (Postfix) with ESMTPS id 155572CE21; Thu, 5 Oct 2017 00:41:48 +0300 (EEST) (envelope-from
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jari Arkko <>
In-Reply-To: <>
Date: Thu, 5 Oct 2017 00:41:47 +0300
Cc: "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: "Eggert, Lars" <>
X-Mailer: Apple Mail (2.3273)
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: Wed, 04 Oct 2017 21:41:52 -0000

I was a bit surprised to see this come out of the IESG for 
review, given that we had fairly serious discussions about the
problems of the proposed approaches at the BOF, but I see little 
attention on those issues in the charter.

But, to state my opinion about working group being created with this
charter, I have comments from two directions.

First, from the point of view of “do we need this” or “do I need this”,
I’m a “meh”. If the HIP and LISP folk and everyone else were
screaming for this, and we had enough deployment that we saw the 
issues that the charter proposes, then sure. Not sure that’s case.

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.

The charter text also mentions “identifier changes” in what feels
like a special case for what I would think is rather the default.

I find concept of firewalls checking identity troublesome.

Now, I’m not opposed to creating a working group in the IETF in this
area, and to support various infrastructure needs of say mobility or
multihoming or anycast protoocols, but if we do it, we need to do
it right. Dino’s suggestion of mapping systems without the manage/
create aspect might be one potential useful direction. Another
way to think about this space is to consider nodes to have autonomy
in how they manage and create their identities, when they reveal
or do not reveal identities. Then we could ask what
helpful tasks might an infrastructure provide on top of that, e.g., 
mapping services or forwarding agent type designs.