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

Toerless Eckert <> Wed, 01 November 2017 17:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AA1013F9AA; Wed, 1 Nov 2017 10:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FDvC12faLQUP; Wed, 1 Nov 2017 10:21:51 -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 4905C13F991; Wed, 1 Nov 2017 10:21:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5560358C4F6; Wed, 1 Nov 2017 18:21:46 +0100 (CET)
Received: by (Postfix, from userid 10463) id 405ABB0D054; Wed, 1 Nov 2017 18:21:46 +0100 (CET)
Date: Wed, 1 Nov 2017 18:21:46 +0100
From: Toerless Eckert <>
To: Christian Huitema <>
Cc: Padma Pillay-Esnault <>, "" <>, " list" <>, Dino Farinacci <>, "" <>
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: Wed, 01 Nov 2017 17:21:54 -0000

On Wed, Oct 11, 2017 at 12:34:19PM -0700, Christian Huitema wrote:
> Some thing you should be hearing is that "long term identity of device"
> has almost the same privacy properties as "long term identity of the
> device's owner". You may think that identifying a random piece of
> hardware is no big deal, but it turns out that the network activity and
> network locations of that piece of hardware can be associated to those
> of its human owner. So you need the same kind of protection for these
> device identifiers as for human identifiers.

Sure, but i don't think it can be generalized:

There will be more and more non-individually owned nodes in public and
corporate infrastructures where requirements will be quite different
from those derived from individual human privacy.

If lets say those long term identifiers do not provide good human
privacy protection but good communications security properties and
managed transpacency for regulators then they could still be a great
benefit for those class of nodes.


Trying to get more privacy into network layer is like making
tobacco more organic. You can get buried in the organic section
of the graveyard after you die of lung cancer. Great success!

Aka: Where is the IETF on any warnings, architectures or recommendations
on the actual application layer:

"Inhaling of this web page / IoT device will expose your personal
 activities related to it, social security number and credit card
 information to a "trusted set" of 1000 collaborating web services
 companies of which 10 at least have already been fined several times
 for leaking your information - and then made even more money out of it"

(sorry, just can't get beyond the fact that equifax is not making
 money out of their leakage...)

Should come with every mayor web page and IoT device.


Venting aside, i'd actually love to understand better if/what IETF
does for privacy inside eg: a TLS payload, besides sipbrandy/dprive/perc ?


> -- 
> Christian Huitema

> _______________________________________________
> Ideas mailing list