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

Toerless Eckert <> Fri, 03 November 2017 17:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B9C513FF0F; Fri, 3 Nov 2017 10:53:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zdsrjj_Hox1d; Fri, 3 Nov 2017 10:53:03 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3344C13FF0E; Fri, 3 Nov 2017 10:53:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0E70058C4B2; Fri, 3 Nov 2017 18:52:59 +0100 (CET)
Received: by (Postfix, from userid 10463) id E996CB0D084; Fri, 3 Nov 2017 18:52:58 +0100 (CET)
Date: Fri, 3 Nov 2017 18:52:58 +0100
From: Toerless Eckert <>
To: Tom Herbert <>
Cc: Christian Huitema <>, Padma Pillay-Esnault <>, "" <>, "" <>, Dino Farinacci <>, " list" <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Ideas] [lisp] 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: Fri, 03 Nov 2017 17:53:05 -0000

Thanks, Tom, inline

On Thu, Nov 02, 2017 at 08:30:11AM -0700, Tom Herbert wrote:
> Toerless,
> That maybe true, but personal devices, such as smart phones and cars
> that are associated with individuals, are hardly going away anytime
> soon. How addresses are assigned to these devices has a material
> impact on individual privacy. Even right now there are two long
> threads on v6ops right now that are delving precisely into privacy of
> IPv6 addresses that may be relevant. This includes discussion about
> CGNAT and efforts by some governments to illegalize it because the
> privacy it gives is too strong for law enforcement.

Sure. All i was saying is that we should not dismiss solutions if they
do not help to improve privacy. It reminds me of the congestion control
principles and the fact that a lot of money is made with video in
controlled networks without congestion control. As in: "Sorry, we couldn't
build a great solution for sensor devices in manufacturing plants because
those solutions wouldn't pass the privacy bar".

I am not even aware if we have good characterizations of solutions
vs. privacy like IMHO we have for congestion control, but of course its
a more complex topic. (IMHO: lot more cases IMHO to distinguish).

That being said, i would of course love to see that we leverage IDEAs to
also create options that (could) enhance privacy, i just don't think that
we will make a lot of progress if we can not do this work in a WG but
if all the complex issues have to be resolved on pre-wg mailing lists before
even charters are accepted. This is part of whats wrong with the IETF
if i may say so.

For example, Christian contested that long lived identifiers help to
improve privacy (for device = individual case) and those arguments about
privacy had the IESG turn their opinions.

IMHO: The long-lived identifiers are meant to be functionally limited. You do
increase the bar of identifying an individual when you do this because the
web applications need to do more work to correlate application layer
information across multiple functional identifiers.

So, how & where do we even create a common understanding about the qualitative and
quantitative privacy benefits of technology options if not in a WG. Functional
identifiers just being one example. 

Even more fundamentally: If each individual application layer function requires
authentication via e.g.: government, google or facebook ID, and all those
web services are free to correlate their information in the backend, any
network layer privacy work is just like growing organic tobacco.

Which is why i really would like to know what the state of requirements/BCP etc.
is re. privacy at app layer in the IETF, because without that knowledge, i can
only define the privacy benefits of a network layer enhancement under the
ASSUMPTION of particular application behavior.

My impression of IETF policy is "you have to trust the web services
provider (not to share/correlate/abuse user/client information)" and in the
same breath "you can not trust the network service provider (to behave in the
same way)". Would love to get pointed to documents proving this impression to
be wrong. Especially the option that there can be network providers that
users may want to trust more than arbitrary web services providers should IMHO
be acknowledged. And thats definitely an option i think is worthwhile to build
solutions against. 


> Tom