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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 29 September 2017 18:32 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 15B0713337F; Fri, 29 Sep 2017 11:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 mjbuD14hRmDF; Fri, 29 Sep 2017 11:31:59 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6511330B3; Fri, 29 Sep 2017 11:31:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7B900BE49; Fri, 29 Sep 2017 19:31:57 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3hNP43zzLAW; Fri, 29 Sep 2017 19:31:54 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 62FDABE47; Fri, 29 Sep 2017 19:31:54 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1506709914; bh=JTX1cwCe+J9hw1MasflHMohnEpZMmuy1YEOem39iHT8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CNyBEr6cvtIShIx1qUN6L/DgjNgCD7WWkftSKmzSN3OfZh10PTpKTrGWv3UpszdkT Jd7dJT3utrNPDiSftwAAble7znMz1FfSOiQioCZ7VlhjUmhgsAP9mdKUMqumR382/A N6hWS2LoAaJHYGG0foge+xsT1+x3/iseCWdaH8OM=
To: ietf@ietf.org, IETF-Discussion <ietf@ietf.org>
Cc: ideas@ietf.org
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>
Date: Fri, 29 Sep 2017 19:31:52 +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: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RlRX6nSbKAsBVsnxfxLLScFnIHJG2q9jA"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/Oz1LRmzSy0DlGyG8K_HjzPTGuWg>
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: Fri, 29 Sep 2017 18:32:02 -0000

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 (iesg@ietf.org) by 2017-10-09.
> 
> IDentity Enabled Networks (ideas)
> -----------------------------------------------------------------------
> Current status: Proposed WG
> 
> Chairs:
>   Padma Pillay-Esnault <padma.ietf@gmail.com>
> 
> Assigned Area Director:
>   Alvaro Retana <aretana@cisco.com>
> 
> Routing Area Directors:
>   Alia Atlas <akatlas@gmail.com>
>   Alvaro Retana <aretana@cisco.com>
>   Deborah Brungard <db3546@att.com>
> 
> Mailing list:
>   Address: ideas@ietf.org
>   To subscribe: https://www.ietf.org/mailman/listinfo/ideas
>   Archive: https://mailarchive.ietf.org/arch/browse/ideas/
> 
> Group page: https://datatracker.ietf.org/group/ideas/
> 
> Charter: https://datatracker.ietf.org/doc/charter-ietf-ideas/
> 
> 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
> 
> 
>