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

Brian E Carpenter <> Wed, 04 October 2017 21:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 103D61344BB; Wed, 4 Oct 2017 14:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dA4pQxONFVUd; Wed, 4 Oct 2017 14:56:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 364691323B4; Wed, 4 Oct 2017 14:56:47 -0700 (PDT)
Received: by with SMTP id m18so1115589pgd.13; Wed, 04 Oct 2017 14:56:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/o1mGaaI/C+mzDykgr1H3K1J0TNu50yE9WzF7ha9rlM=; b=lRPKpHt2JTlqTYx+W1UfRtxuH9ECbh5yj24AnINcf+qofdqustwmOHHEYSoaXvj3xS wFhxLSrhq4AdtGHKjI7eY/sq+L0NIBN0IT+o4yIBPdI4kvFcTbgU3aJpo93TS8ovWTnM ToqXmKifuYiH0VCQUzf9jImh8j6VBC18jKRLMGiMZBn+bY7JNR29Ujge70yKjJj6h6Jp 2DON4g78ZizZLPnHDq4PfSTzZl21rQ5yxDEp+ev6j9OBrxbV4sRXlezhxDOv15xkojuP 6IiaOQdGIFGBiBeJhd7gYme7qREg4qRCwyh2B68ltxSKX8UbWwxip4kjExrQ4hGtoF7B yt2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/o1mGaaI/C+mzDykgr1H3K1J0TNu50yE9WzF7ha9rlM=; b=sT4ZAiqXHRQKfcojIkxEdfFxZZhPPRKS9KZqUTjCDvINkRWcWWhFnZxVJ5MWMizN8U ScXXqm299Mj5jqwJ87oQeLxQiK+ZoLZ/ZAVwWRcqK4hnvioZlM92L9qxvVgLqolqvbxP dzCFg7GB5yzp1n51CDPjNMJkR0OysKsBP6fAgOFOfVTNF5uJJgVk6yfL/4o6jfo4QDAT rwjlYxWo4sOzbwDQs2+Mf+TmR02zfMxmHtV34xpDgbCDZQ3WheoJ2ZblL4R6zMTIcLsk /r76iwjnWgJY2miAYIszhBKqyBCNVCEITi4UKgi3elLDK6RhieHT+Ursb7R51QY7S3Vr tFYQ==
X-Gm-Message-State: AMCzsaVnwgSe7Gy7otoeAeoPIMk1lSmPG8DleD7TRrh9gRfbX/gepvkl DeZh/M7lhhpwNXJfVUDZZadzsw==
X-Google-Smtp-Source: AOwi7QARZLO4ur64GE2PoBEnSh+aN0VqqNPt8wJSNC0ceuKlEeTUjBtBtlzvmiH/yG/ExFjHrS/1Qg==
X-Received: by with SMTP id b187mr10877726pga.222.1507154206282; Wed, 04 Oct 2017 14:56:46 -0700 (PDT)
Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by with ESMTPSA id 207sm27070335pfu.0.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 14:56:45 -0700 (PDT)
To: Dino Farinacci <>
Cc: "" <>, "" <>, " list" <>
References: <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Thu, 5 Oct 2017 10:56:48 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
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 21:56:50 -0000

On 05/10/2017 09: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?

That seems reasonable, well defined and relatively uncontentious.

The current proposed charter leaves me a bit puzzled. Firstly I agree
that the name 'IDEAS' is misleading, and 'GRIDS' tramples on previous work,
and 'identity' is a red flag. But if we get past terminology distractions,
where's the meat? All the interesting stuff is relegated to drafts or a
wiki, and the output is a 'framework'. The IETF has a very mixed record
with 'framework' documents.


> 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.
> 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
> .