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

Padma Pillay-Esnault <padma.ietf@gmail.com> Thu, 05 October 2017 07:52 UTC

Return-Path: <padma.ietf@gmail.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 E421E133070; Thu, 5 Oct 2017 00:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nlsut0wadQOw; Thu, 5 Oct 2017 00:52:11 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 6116F133018; Thu, 5 Oct 2017 00:51:25 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id q124so408981wmb.0; Thu, 05 Oct 2017 00:51:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hb7FHgQH7YM+rFbe/PFhiCTPSQOZYdpSSvcxyGsBwR0=; b=SxPRc4Rdi/pQfANSedI/AP/Et5XrBjPpQkr1mH3pJti4UpPaw3QWcvLcHPwScbzLqH yilgDPMZ/xV1W51cfyBziVgIH882BZAWzZENxRRvaDiUN1oCorp+QBOaWjqHPC4KZa+F 858bWe9OV3mV83VZOfZIiBe4IY5c1v/ahBWG0fiuuzQEkNjJvDO6OSDZpoj4hKNIs6sb oXjECAclxFeJug2PiTXlFjY8+eT5KSJhGaapqArSeVXYInjLeW3rz9Dq2y7TXtXprTzk AQhCMagKjnZXbw8smCNVzOdJaUe9kC9Ljm+yFhgRo5XTWrSIhBUGv782/IVJVb4d3YqC Cgdg==
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; bh=Hb7FHgQH7YM+rFbe/PFhiCTPSQOZYdpSSvcxyGsBwR0=; b=kPe1lEOAurFLDmCbFpV4iT1pj1SqVAfICsFQFG793uWpFT55KxjL51Vca4FBuNAd07 hr2pqVNc7R0890bHB40ottdj18ncudqUWJ0w2R0miq/PEJJLoBuEjkEVK22HK32pGeip IO38gPRYwZ898IJTaTJ2aVisaj1ifp1GlJrHCXmzrkM57a/tx6XSPocirdcR3FJHoVku D4XjPbiEpjKaU4l5tmuK5t2AQVyzCeYBSpRW6jnYC6o4aXIp5HKWPfPzmwD+wVgXXwr1 V2qPGmM82BX+AWd3EK9CJ5cXm7yJhwHGi44XUV7sQevWwxS6CZl5gQwJpLHzDqdYwNjU pOhw==
X-Gm-Message-State: AHPjjUiKO1kPT2MkLr/KCJ2DdXVUiOgxBAT7AINgPPkN8HohMTU7n/r+ vDdjeU2I7PtS39mUWKxJqflptlEn6jWAmHhLjN8=
X-Google-Smtp-Source: AOwi7QAe+LOUcM2BC8Voz/iuxjim/Rv9Bp4UXWsnZfb1hhm9fX6OkM3Xbv9CUkmQbJGqrDqIdbbwL7hNKbZQDhi4exY=
X-Received: by 10.28.141.1 with SMTP id p1mr16048532wmd.68.1507189883794; Thu, 05 Oct 2017 00:51:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.173.86 with HTTP; Thu, 5 Oct 2017 00:51:22 -0700 (PDT)
In-Reply-To: <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <D7D4AEE9-3BD0-4C8F-BCC6-7185AF7D37BA@netapp.com> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net>
From: Padma Pillay-Esnault <padma.ietf@gmail.com>
Date: Thu, 5 Oct 2017 00:51:22 -0700
Message-ID: <CAG-CQxq1_tzCK_sxb-1rdjYHVyV_Zfn2-+exxitVsU85jjnaNg@mail.gmail.com>
To: Jari Arkko <jari.arkko@piuha.net>
Cc: "Eggert, Lars" <lars@netapp.com>, "ideas@ietf.org" <ideas@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="001a11469d40a1f98c055ac7fd69"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/9ICsglASYhU3uyZ3m14MQw3i6bs>
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: Thu, 05 Oct 2017 07:52:15 -0000

On Wed, Oct 4, 2017 at 2:41 PM, Jari Arkko <jari.arkko@piuha.net> wrote:

> 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.
>
> <Padma>
The goal was not to manage and track identities but have a means to protect
an identifier from misuse and abuse. The "user of an identifier"
(disclaimer - user is not a human and in this context aka identity)
typically need to authenticate to be able to update the locator in a
mapping system. This aspect was just formalized in the charter.

Looking at much of the discussions, it is important to make this
clarification in the charter.


> 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.
>
> <Padma> Actually after the discussions in the bof, it was clear that the
entities should be allowed to have multiple identifiers and identities. The
charter points to life cycle of these and there is no assumption that they
cannot be ephemeral. The management of identities here is just formalizing
what mapping systems need - an authentication of the "device using the
identifier" for the update and look up of the locators. Today we already
have identifiers/loc in infrastructure for lookups this is no different.

The goal was rather to check if that entity X that is trying to locate
entity Y is ok by entity . If not, not to honor the look up  - kind of a
"do not call" list.


> The charter text also mentions “identifier changes” in what feels
> like a special case for what I would think is rather the default.
>
> <Padma> no it is default as identifiers are best to be ephemeral for
privacy.


> I find concept of firewalls checking identity troublesome.
>

<Padma> there is no concept of enforcing firewall in the charter. The
policy per identifier or identity is based on whether a lookup should be
honored or not. Whether local firewalls (as in enterprise domains) are used
to prevent and block communication is no different than today's use.


> 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.
>
>
<Padma>
Agree that we want to do it the right. The notion autonomous nodes having
their say on when to reveal their location is a goal for this infra. The
"identities" in this context here are never revealed on the wire but only
the pseudonyms or identifiers associated.

There has been a lot of discussions on the alias and drafts which
unfortunately cannot be reflected in a charter.

One of the goals is to have better privacy and prevent easy tracking (as
with long lived identities) against eavesdroppers or outsiders.

Padma

Jari
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>