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

Stephen Farrell <> Tue, 10 October 2017 20:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3F8A1342F6; Tue, 10 Oct 2017 13:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DMxVUYlALi-s; Tue, 10 Oct 2017 13:24:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F201B1342F2; Tue, 10 Oct 2017 13:23:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88654BE5B; Tue, 10 Oct 2017 21:23:57 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kgqo_GmMYR0C; Tue, 10 Oct 2017 21:23:52 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 80CF4BE56; Tue, 10 Oct 2017 21:23:52 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1507667032; bh=98zgoMjn5PicbyKYPdFD7+HF3dPCbiWyFI6KQTggAxU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=zUPBA61WZPLOjRV6AyEWC4owq4cKyUn1VUoxsbYVgpXWm40bAp+NIy9sYx5jdbaXx B97of6wJdvzFjl7HYwiswuvJq6jSc0YVF1M0v1/5dnshFiLGx0JjUwL5hNJ8mwuBWv N1MihwoNQlQKKAIt+73jwGVw5UlUFmaQ+Z5gDang=
To: Robert Moskowitz <>,
References: <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Tue, 10 Oct 2017 21:23:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Dx2Sb595Hahsvoe28IBbVLr9fG75tJvUn"
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: Tue, 10 Oct 2017 20:24:05 -0000

Hi Bob,

On 10/10/17 20:35, Robert Moskowitz wrote:
> Stephen, and others...
> I am on Jewish Holidays since Sept 20th and I will finally be past them
> on Oct 16th.  I do have some time between the actual Holidays to see how
> far I have fallen behind.  That said, I will attempt to address a couple
> concerns here on the IETF list for the broader audience.
> I am also concerned that some ID/Loc technologies seem to allow for PII
> to be enshrined in ID.  

"Enshrined in" isn't that clear to me (but I did say
"embedding" below which is just as bad:-). As we know,
long-lived identifiers that correlate with people can
be enough to cause problems, e.g. IMEIs and MS-ISDNs,
if exposed to other parts of the network.

> I have always been against that.  I have always
> seen a strictly one-way mapping that could take a human PII and find a
> ID for that.  Phone number lookup technologies based on LDAP have always
> supplied this.  Nothing new here, if done right. Human PII based ID
> should not be encouraged in this work, but is more the feature of an
> underlying ID/Loc technology (note, HIP does NOT do this).
> Thus this is out of scope of IDEAS.  

I don't follow how the last statement follows from the
preceeding paragraph. I also saw nothing in the charter
or the use-cases draft or in the list archive to back
up that conclusion.

> And, as I am funded to work on
> IDEAS, I will vigorously work against anything that expands what we
> already have (and maybe get this out of in ID/Loc tech that has it).


> This is about machines, and processes, have ID/Loc through some
> underlying technology (e.g. HIP, ILA, LISP) to have a common ID
> discovery and Loc back to ID (for things like HTTP redirects).  

If that's the case, then there appears to be serious confusion
in the use-cases draft at least. And "identity" seems a fairly
mad term to pick if one means processes or devices, as it pretty
much guarantees raised hackles and confusion.

> As the
> charter says, strong access control will be designed in (but of course
> no assurance of implementing).  

I don't see such a statement in the -06 charter sorry.

> Note that HIP has a course access
> control in its RVS service in that an RVS COULD ignore a redirect from
> an Initiator nore registered to the RVS.  But we need finer grain access
> control and, well it is in the charter.
> Why do this?  ID/Loc has a number of use cases, but is limited by the
> lack of discovery services (well, HIP can use DNS) and reverse discovery
> (but this is from Loc to get ID and only if authorized). We feel that
> adding in what we have learned limits ID/Loc will broaden its use.

TBH, I don't get the motivation here at all and I haven't
been enlightened by the discussion so far, nor from reading
the use-cases draft, but likely that's my fault.


> Bob
> On 09/29/2017 02:31 PM, Stephen Farrell wrote:
>> As currently described, I oppose creation of this working
>> group on the basis that it enables and seemingly encourages
>> embedding identifiers for humans as addresses. Doing so
>> would have significant privacy downsides, would enable
>> new methods for censorship and discrimination, and could
>> be very hard to mitigate should one wish to help protect
>> people's privacy, as I think is current IETF policy.
>> If the work precluded the use of any identifiers that
>> strongly map to humans then I'd be ok with it being done
>> as it'd then only be a waste of resources. But I don't
>> know how that could be enforced so I think it'd be better
>> to just not do this work at all.
>> S.
>> On 29/09/17 17:13, The IESG wrote:
>>> A new IETF WG has been proposed in the Routing Area. The IESG has not
>>> made
>>> any determination yet. The following draft charter was submitted, and is
>>> provided for informational purposes only. Please send your comments
>>> to the
>>> IESG mailing list ( by 2017-10-09.
>>> IDentity Enabled Networks (ideas)
>>> -----------------------------------------------------------------------
>>> Current status: Proposed WG
>>> Chairs:
>>>    Padma Pillay-Esnault <>
>>> Assigned Area Director:
>>>    Alvaro Retana <>
>>> Routing Area Directors:
>>>    Alia Atlas <>
>>>    Alvaro Retana <>
>>>    Deborah Brungard <>
>>> Mailing list:
>>>    Address:
>>>    To subscribe:
>>>    Archive:
>>> Group page:
>>> Charter:
>>> Network solutions based on the concept of Identifier-Locator
>>> separation are
>>> increasingly considered to support mobility, overlay networking for
>>> virtualization and multi-homing across heterogeneous access networks.
>>> Identifier-locator separation protocols require infrastructure that
>>> allows
>>> nodes to discover the network topological location(s) of its peer(s) for
>>> packet delivery. A common infrastructure and protocol could be used by
>>> identifier/locator protocols as well as network virtualization. However,
>>> additional infrastructure and new protocol extensions are needed to
>>> address
>>> new requirements that go well beyond the traditional discovery
>>> service and
>>> mapping of identifier-to-location for packet delivery.
>>> Identifier-locator
>>> protocols are also useful for additional services involving dynamic
>>> association of a name to a set of network addresses - these include
>>> dynamic
>>> multicast, cloud service anycast and context-aware IoT queries.
>>> The IDEAS WG is chartered to produce a framework document that
>>> defines the
>>> expected behavior of a mapping system across the multiple existing
>>> use cases.
>>>   The framework will aim at a homogeneous behavior across use cases,
>>> and it
>>> will call out specific trade-offs that may be considered in the
>>> development
>>> of solutions.  We refer to the framework providing the set of
>>> services as
>>> Generic Identity Services (GRIDS).
>>> Some of the areas that must be considered when developing the framework
>>> include:
>>> - Description of interfaces for different protocols to interact with the
>>> framework (e.g. id-loc split protocols, management protocols, etc)
>>> - Description of identifier/locator mapping resolution and mapping
>>> update
>>> (e.g. discovery, pub/sub, multi-homing, ...)
>>> - Registration and lifecycle management of identities and their
>>> associated
>>> identifiers.
>>> - Identity authentication and authorization (e.g. access to
>>> framework, update
>>> of information for identifiers..)
>>> - Description of required basic network policies and policy
>>> enforcement needs
>>> (e.g. ability to look up an identifier-locator pair, permit forwarding
>>> traffic for particular endpoints on a per-identity basis, etc.)
>>> - Analysis of the concepts of identity-identifier split and dynamic
>>> identifier changes, including their implications on anonymity and
>>> privacy.
>>> Explicitly, the framework must define privacy requirements and how
>>> potential
>>> extensions/solutions should meet them.
>>> - Security analysis of the complete system, including authentication,
>>> authorization requirements and protection of any metadata.
>>> - Operational and deployment considerations
>>> The IDEAS WG will closely coordinate with the LISP and HIP WGs (and with
>>> others as needed) in order to keep them well-informed of the
>>> progress.  Any
>>> extension to existing protocols that is identified while developing the
>>> framework document will be carried out in the responsible WG for that
>>> protocol; any extension work to be done in this WG will require
>>> re-chartering.
>>> WG deliverables include:
>>> (1) Generic Identity Services Framework
>>> (2) Other WG sustaining/informational documents may include:
>>> - Problem statement
>>> - Use cases
>>> - Requirements for identifier/locator mapping and resolution
>>> - Requirements for identity authentication and authorization service
>>> (for
>>> GRIDS) - Applications of the architecture for use cases - Threat model
>>> document
>>> These documents will not be published as RFCs, but will be maintained
>>> in a
>>> draft form or on a collaborative Working Group wiki to support the
>>> efforts of
>>> the Working Group and help new comers.
>>> Milestones
>>> January 2018 Adopt WG draft for the Generic Identity Services framework
>>> July 2018 WGLC for the Generic Identity Services framework
>>> September 2018 Send Generic Identity Services framework draft to the
>>> IESG
>>> November 2018 Recharter or Close
>> _______________________________________________
>> Ideas mailing list