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

Stephen Farrell <> Wed, 04 October 2017 20:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0A7D1331E7; Wed, 4 Oct 2017 13:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id or1mrK8UQpaT; Wed, 4 Oct 2017 13:46:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC38613307B; Wed, 4 Oct 2017 13:46:47 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2955BE38; Wed, 4 Oct 2017 21:46:45 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zmRSn4L3IfVf; Wed, 4 Oct 2017 21:46:43 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 0C94DBDD8; Wed, 4 Oct 2017 21:46:43 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1507150003; bh=ft2nVRVRO+f8oYspfkLGITM7ywm2L7eGJhjgi0ZsoHY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AgjvLMSQTB9jPRKX8f3kpl0kswEOrK8/U8tysRRgyck9bupHUrMTPGIaG0pRat4F4 JXPpphC93sjHDzjZpHB5e87MeySnG8aqaPpr81S0ug6hxxOvwAs3cRbtYrYU2bPy9J QLcVvrGd+2aMZUP+9SCJmCAbr6ryUnUTXIJTDtH4=
To: Dino Farinacci <>
Cc: Alexander Clemm <>, Tom Herbert <>, "" <>, "" <>, "" <>, " list" <>
References: <> <> <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Wed, 4 Oct 2017 21:46:41 +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: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Np1AnoqIqJjJGrExM86qutM1wo1WX6F7B"
Archived-At: <>
Subject: Re: [Ideas] 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, 04 Oct 2017 20:46:51 -0000

Hi Dino,

On 04/10/17 21:35, Dino Farinacci wrote:
> Adding to cc list.
> How about creating a working group that solely focuses on deployment
> of a mapping system and does not specify how and where identifiers
> are allocated?
> I have made suggestions before that such a working group should be in
> the ops area. Some examples include and are not limited to v6ops,
> dnsop, and mboned.

If there's deployment of things like LISP and HIP and folks
are interested in discussing/documenting what they've been
doing in the ops area then that seems quite reasonable sure.


> Cheers, Dino
>> On Oct 4, 2017, at 12:45 PM, Stephen Farrell
>> <> wrote:
>> Hiya,
>> TL;DR - I am now even more convinced that this ought not go ahead.
>> (Sorry;-)
>> On 04/10/17 19:48, Alexander Clemm wrote:
>>> There were a couple of things raised in the overall thread that
>>> I just wanted to quickly respond to:
>>> Clearly privacy is an important issue and concern.  The current 
>>> charter proposal includes a requirement for a detailed analysis
>>> of this aspect.  If this aspect needs to be expanded, sure, let's
>>> do this.
>> TBH, I don't think that'd help, for me at least. I don't see any
>> way in which such permanent strings representing identity can be
>> defined to be usable as claimed and not be perniciously privacy
>> invasive. So some promises to ponder the problem in charter text
>> wouldn't do it for me. (And tbh, I've seen that can kicked down
>> that road before, so I'm skeptical of such promises in general.)
>>> Everyone seems to be jumping up and down regarding the use of
>>> the term of "identity" as if a foregone conclusion that this is a
>>> synonym for "privacy invasion".   However: - "Identity" does not
>>> imply "personal identity".  Really, this is an identifier scheme
>>> for endpoints.
>> Sorry, what I assume is the relevant draft [1] says the "identity" 
>> (denoted "IDy") is a "Unique and Permanent Identity" and that 
>> "Networks may treat traffic differently depending on the IDy of 
>> source or destination" and also seems to envisage a large logical 
>> database of everyone's IDy's: "Identity also allows to have
>> metadata associated it to be applied, regardless of which IDf is
>> used to refer it." (Where IDf is the identifier that'll later be
>> mapped to a locator via, I assume, HIP or LISP or similar.)
>> I think it's entirely correct to jump up and down about the privacy
>> consequences of the above. (Not to mention the potential censorship
>> and discriminatory aspects.)
>> [1]
>>> Perhaps even "identity" is a misnomer.
>> Well, it was presumably your choice (where your == some set of the
>> proponents). If that's a mistake, then it seems a fairly fatal one
>> - to get the name wrong for an effort all about mapping names to
>> identifiers;-)
>>> If you will, identity as conceived in the context of IDEAS is a
>>> second level of identifier that does not have to be exposed over
>>> the data plane - Because of this, it may result in greater
>>> privacy than existing schemes, not less.
>> I see that argument in [1] but I'm not buying it tbh. To get that
>> level of protection from such an indirection, one would have to
>> have something like Tor hidden services and perhaps one would have
>> to *not* standardise the mapping from human meaningful identifiers
>> to those used as IDf, and esp. not the reverse mapping. Defining
>> that reverse mapping cannot but be privacy invasive afaics. (There
>> could maybe be ways to define how an already hashed human
>> meaningful identifier could then be further hashed to become an IDy
>> but I don't really see the point of that at all, other than to just
>> standardise something for the fun of the process.)
>>> It enables you, for example, to obfuscate endpoints to outside
>>> observers as you wouldn't need to use personal unique long-lived
>>> identifiers, quite the contrary. - There is also a security
>>> dimension here. If I am victim of a phishing attack because my
>>> network information (like today) is exposed to botnets,
>> (Nit: that says nothing about being a victim of, only of being a
>> target of, an attempted attack. Speaking of victims also tends not
>> to lead to more objective analysis, so I think it's better to not
>> go there unless it's relevant, which I don't think is the case
>> here, because...)
>> I don't understand what network information you mean. If you mean
>> email addresses, and are proposing that the email ecosystem change
>> to use some IDf or LOC values, that doesn't seem at all realistic
>> to me. If you don't mean email addresses then I don't see how any
>> lower layer change will affect attempted phishes. The routing area
>> is probably also the entirely wrong venue for any real
>> anti-phishing effort.
>> That really wasn't a good example;-)
>>> phishers etc who can hide from me (but not I from them) and
>>> remain anonymous or impersonate legitimate users, I do consider
>>> this a very serious threat also to my privacy.  How can IETF
>>> counteract such threats?  I think that IDEAS, if done right, can
>>> provide a contribution here.
>> I don't see that at all. Unless I'm mistaken that seems like 
>> wishful thinking to me.
>>> One aspect that has been missing from the discussion is the
>>> question whether there is a distinction between the network
>>> provider who provides GRIDS services and an outside attacker /
>>> observer.  I think this distinction is important.  The way I see
>>> it, if done right (sure, big "if", and requiring detailed
>>> analysis), IDEAS as I would envision it can contribute greatly to
>>> provide greater security and privacy from outside attackers.  At
>>> the same time, as it is currently envisioned, there clearly is a
>>> trust relationship between an entity and the provider of "its"
>>> GRIDS services.  The mapping database will have information about
>>> locator-identifier and identifier-identifier mappings, so GRIDS
>>> will know which identifiers its endpoints are using.  Clearly, if
>>> this trust is abused because the provider cannot be trusted, if
>>> you are concerned that it sells your endpoint’s information to
>>> the mob or a suppressive government, there is an issue.  However,
>>> when concerned about this scenario, it seems to me one would have
>>> equal reason to e.g. not trust your mobile service provider
>>> either, who can track you, knows your location, and has your 
>>> customer data.
>> ISTM that introducing that GRIDS thing makes matters worse and not 
>> better, because, as you yourself say, it is clear that whoever has 
>> access to the GRIDS information would be better able to track
>> people compared to now.
>> I would prefer to see fewer long lived identifiers in networking 
>> and not more, and this proposal introduces more long lived
>> identifiers (erroneously calling those identities).
>> Regardless of what one thinks of them, given that things like HIP
>> and LISP exist, and try tackle the ID/LOC split, I see no benefit 
>> adding this extra layer of indirection with a privacy invasive 
>> "Unique and Permanent" identifier which seems to be the only 
>> non-overlapping part of this work - in fact I only see downsides.
>> Cheers, S.
>>> --- Alex
>>>> -----Original Message----- From: Ideas 
>>>> [] On Behalf Of 
>>>> Sent: Wednesday, October 04, 2017
>>>> 9:35 AM To: Cc:; 
>>>>; Subject: Re: [Ideas] WG 
>>>> Review: IDentity Enabled Networks (ideas)
>>>> On Wednesday, 4 October 2017, Tom Herbert wrote:
>>>>> On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker 
>>>>> <> wrote:
>>>>>> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell 
>>>>>> <> wrote:
>>>>>>> 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.
>>>>>> +1
>>>>>> I know how to restrict the work to 'meaningless'
>>>>>> identifiers, require that the identifiers be the output of
>>>>>> a cryptographic algorithm.
>>>>>> Now strictly speaking, this only limits scope to
>>>>>> identifiers that are indexical as opposed to rendering them
>>>>>> meaningless but I think that was the sense of it.
>>>>>> Nöth proposed a trichotemy of identifiers as follows
>>>>>> * Identity, the signifier is the signified (e.g. data:
>>>>>> URI)
>>>>>> * Indexical, the signifier is related to the signified by a
>>>>>>  systematic relationship, (e.g. ni URIs, SHA256Data), PGP 
>>>>>> fingerprints etc.)
>>>>>> * Names,  the signifier is the related to the signified by
>>>>>> a purely conventional relationship, (e.g. to
>>>>>> its owner)
>>>>>> There is a big difference between attempting to manage 
>>>>>> indexical signifiers and names. Especially when the people 
>>>>>> trying to do so refuse to read any of the literature on 
>>>>>> semiotics.
>>>>>> Names are problematic because the only way that a
>>>>>> conventional relationship can be implemented is through
>>>>>> some sort of registration infrastructure and we already
>>>>>> have one of those and the industry that manages it has a
>>>>>> marketcap in the tens of billions.
>>>>>> Identifiers do lead to tractable solutions. But, this
>>>>>> proposal looks a bit unfocused for IRTF consideration, an
>>>>>> IETF WG? Really?
>>>>> Identifiers are equivalent to addresses in that they indicate
>>>>> a node in the network for the purposes of end to end 
>>>>> communications. The only difference between identifiers and 
>>>>> addresses is that identifiers are not topological. Virtual 
>>>>> addresses in network virtualization are also identifiers. So
>>>>> the security properties are the same when considering
>>>>> privacy. For instance, if applications use temporary
>>>>> addresses for privacy, it would have equivalent properties
>>>>> using temporary identifiers. In fact from the application POV
>>>>> this would be transparent. It could get a pool of apparently
>>>>> random addresses to choose from as source of communication,
>>>>> it shouldn't know or even care if the addresses are
>>>>> identifiers.
>>>>> Identity is a completely separate concept from identifiers.
>>>>> Is not required in any of the identifier/locator protocols
>>>>> and AFAIK none of them even mention the term. There is no
>>>>> association of an identity of user behind and identifier any
>>>>> more than there is an association of identity behind IP
>>>>> address. The fact that the words "identifier" and "identity"
>>>>> share a common prefix is an unfortunate happenstance :-).
>>>> Yes. But doesn't that mean either the name of this effort is
>>>> wildly misleading or else the effort is hugely problematic from
>>>> a privacy POV? Either way, istm this ought not proceed.
>>>> S.
>>>>> Tom
>>>> _______________________________________________ Ideas mailing
>>>> list
>> _______________________________________________ Ideas mailing list