Re: [Ideas] Your Input requested: Charter Proposal New Version

Tom Herbert <tom@herbertland.com> Mon, 07 August 2017 15:23 UTC

Return-Path: <tom@herbertland.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 1D7871324D4 for <ideas@ietfa.amsl.com>; Mon, 7 Aug 2017 08:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 EEFWwDgBTf8E for <ideas@ietfa.amsl.com>; Mon, 7 Aug 2017 08:23:03 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C500132494 for <ideas@ietf.org>; Mon, 7 Aug 2017 08:23:03 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id v105so3158420wrb.0 for <ideas@ietf.org>; Mon, 07 Aug 2017 08:23:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0QUlGefqiwKcllCte35B0jQy193nYo/N8SQx9w5Bxog=; b=Jhx3cIOHunTE3mxY4oD3KjsCvM/w6IMUgVbwrKZvBOqHQy16NysVagc+SPIzPzFXXI 4QAE6EBbiYV0HSPOHXjzRqTBoowNQqoE0R7s9IMs99gxE/RI0CC4Ok6QSEvWZw+wp8dW z0GeFM6unaKfk274jzQlyqhq2RNs/rJK9Mxq2LtU+COAZdeBmHTY1UGBZjjJ9TP1nKDY H0sWvk6KTvAmq5N6iKfKd02IVE0rCdENz7ovZB26lw3XiEElYQI757VfZ2G++MC35wU/ mJlcqo5I59t6QA0ZfeOvnxclW7g2LD/UEL+uwhtyisyh3kgkRdtaRmGHYR8hZOtFmTem 2Fjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0QUlGefqiwKcllCte35B0jQy193nYo/N8SQx9w5Bxog=; b=SzecrMY0wLi8xle0WAF/Nxi9ccn8VGWEmrjiGqXyJq7NbvaRP5zZHlUZgzz7uZJ6aQ GT534KYToI8lEvb727qEdVzmonUiZ89CRK2e0odDhelCI6GlCuh9LrwN+QodjXh0iCpG GEv31LcUdSFdhypVKv8KXY3OZ0VLBYJJ/BPJiRp19WnOiD+wC3LX8jUPnzjBVc1LsmNL YpBtb62wThsh0dKSC2ASMgEce8JFdGedBPWkK97xHxnJwjBHyj4RoFfs3pC0qkTUWAKo egaKBhzvMqcjoSZ1cKeN2exhWr1PWYjNyeZRamQYjxE/QAAOB+6JaUFScjzgRB3aQQ66 3KUA==
X-Gm-Message-State: AHYfb5gzh/Mykp02oGffxuyX9HF7fP9q/zN5mZd+LpLM3WtE6OvobeTH VwhUDPe0uuSGepWxw+gqhvnjGSn4MpFF
X-Received: by 10.223.152.147 with SMTP id w19mr675786wrb.118.1502119381434; Mon, 07 Aug 2017 08:23:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.135.156 with HTTP; Mon, 7 Aug 2017 08:23:00 -0700 (PDT)
In-Reply-To: <CAG-CQxpxDXxLXdu0a2GdBRfTFLM_C+jqCz58HoNim52C7Yzr8g@mail.gmail.com>
References: <CAG-CQxpxDXxLXdu0a2GdBRfTFLM_C+jqCz58HoNim52C7Yzr8g@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 07 Aug 2017 08:23:00 -0700
Message-ID: <CALx6S34hbV5D84RZQ1+V3zFz+VNeJsDn0rsr-PN6Wg4b1gdSpA@mail.gmail.com>
To: Padma Pillay-Esnault <padma.ietf@gmail.com>
Cc: ideas@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/j5PhkJFbf5gPos4atgYwY63Uk6w>
Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version
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: Mon, 07 Aug 2017 15:23:06 -0000

On Sun, Aug 6, 2017 at 10:20 PM, Padma Pillay-Esnault
<padma.ietf@gmail.com> wrote:
> Dear IDEAS,
>
> Thanks to everyone who sent their comments and feedback both on the list and
> off the list.
>
> This new version should address comments from:
> -  Michael Menth. Michael, please let us know if this revision address some
> of your comments on clarity.
> - Alex Clemm. Alex , please chime on the revision regarding your addition.
> - Tom Herbert. Tom, Some of your suggestions are incorporated in this
> version.
> -Tom and Alex, this version include specific working that the framework is
> modular. The set of areas to be covered has been reordered to put the basic
> identifier protocol common infrastructure first and then the new identity
> concept and functionalities.
> - Georgios Karagiannis, Uma Chundhuri. Georgios, Uma, there is still an
> ongoing discussion about the framework. This version is flexible enough to
> accommodate the work to be done on defining the framework.
> - Uma Chundhuri. Uma, the pub/sub reference should cover the inter-grids
> aspect if needed.
>
> Please find the new version below:
>
> IDEAS: “IDentity EnAbled networkS”
>
>
>
> Proposed Charter
>
>
>
> Network solutions based on the concept of Identifier-Locator separation are
> increasingly considered to support mobility 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.
>
>
>
> At the same time, end users require greater privacy for their networking
> information and protection from outside threats, while operators demand
> greater operational efficiency. Identity-enabled networks aim to enable
> networking applications and services that provide a high degree of privacy
> and control of end points over their networking data, coupled with greater
> inherent security than provided by today’s networks.
>
>
>
> To this end, the working group shall:
>
> - define a framework for the development of an identifier/locator mapping
> system that provides a common solution for all identifier/locator mapping
> protocols and network virtualization.
>
>
>
> - in addition, introduce the concept of identity-identifier split and new
> mechanisms that let endpoints dynamically change identifiers. These new
> functionalities may, for example, facilitate anonymity through obscurity
> while preventing security issues that might result from abuse, ensuring that
> information about actual endpoints and their location is revealed only on a
> need-to-know basis.
>
Padma,

I don't think this goes far enough in terms of protections for users
against the potential abuse of something that might be able to
individually and persistently identify them on the Internet. First,
it's not clear what network layer identity means in this context. I
hope it refers to an ad hoc collection of identifiers as opposed to
the identity of individual users or devices. In any case maybe a
definition of identity might be in order here. Secondly, I think it
should be stated up front that identity cannot in any way be used to
identify individual users, it cannot be used to create a global
database of Internet users, in no way can it be used by networks or
governments to track or block individuals, nor can it ever be required
for communications. That implies network layer identities cannot
contain PII (personally identifiable information) and cannot be
permanently assigned to users or devices (in the same spirit that
Ethernet addresses were removed from IIDs because of privacy
concerns).

Thanks,
Tom

>
>
> Some examples of the problem space are:
>
> - Common infrastructure and primitives: The lack of a common infrastructure
> is a barrier for the application of common and consistent basic networking
> policies. Likewise, mapping services and infrastructure that apply to
> identity-identifier as well as identifier-locator mappings reduces
> operational and deployment complexity.
>
>
>
> - Access control: Unrestricted look up on an identifier may reveal
> information such as the locator to eavesdroppers. Today, there is no way to
> prevent the look up of an identifier with some user defined policy or finer
> grain rules.
>
>
>
> - Privacy:  The use of long-lived and public identifiers may be desirable
> for looking up a peer, however it causes privacy issues as well. Indeed,
> when identifier-location pairs can be looked up without restriction, flows
> can be pinned by anybody to specific end systems.  The endpoint
> communications should be able to change their identifier while retaining
> their identity and associated policies. The use of temporary identifiers and
> access control on lookups should help discourage undesired traffic and
> conceal sensitive network information of end devices to eavesdroppers.
>
>
>
> The Identity Enabled Networks (IDEAS) working group is chartered to develop
> a common framework that can be used by identifier-based protocols and
> provides services to address their requirements. We refer to the common
> framework providing the set of services as Generic Identity Services
> (GRIDS).
>
>
>
> The working group will identify gaps and make recommendations on changes
> needed for interactions between the framework and identifier-enabled
> protocols.
>
>
>
> Specifically, the IDEAS WG is chartered to work on these areas for the
> modular framework:
>
>
>
> - Definition of primitives for interworking with identifier-location split
> protocols
>
> - Identifier/locator mapping and resolution (e.g. discovery, pub/sub,
> multihoming, ...)
>
> - Registration and lifecycle management of identities and their associated
> identifiers.
>
> - Identity authentication and authorization (e.g. access to framework,
> update of information for identifiers..)
>
> - Definition and enforcement of basic networking policies (e.g. ability to
> look up an identifier-locator pair, permit forwarding traffic for particular
> endpoints on a per-identity basis…)
>
> - Identity and Identifier Metadata (fixed or slow changing)
>
> - Management aspects and Data Models where appropriate.
>
>
>
> The IDEAS WG will collaborate with other Working Groups to ensure
> interoperability with LISP, HIP, ILA and other relevant work. Furthermore,
> it will try to reuse technologies already developed when appropriate.
>
>
>
> WG deliverables include the definition:
>
> Generic Identity Services Framework
>
>
>
> WG sustaining/informational documents may include:
>
> These documents may not necessarily be published, but may 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:
>
> - Problem statement
>
> - Use cases
>
> - Requirements
>
> - Applications of the architecture for use cases
>
>
>
> Milestones
>
> March 2018 Adopt WG draft for the Generic Identity Services framework
>
> August 2018 WGLC for the Generic Identity Services framework
>
> December 2018 Send Generic Identity Services framework draft to the IESG
>
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>