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

Robert Moskowitz <> Mon, 02 October 2017 21:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B764913336A; Mon, 2 Oct 2017 14:08:48 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xCmrITdbXMyS; Mon, 2 Oct 2017 14:08:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0EA7132125; Mon, 2 Oct 2017 14:08:44 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A0DD62202; Mon, 2 Oct 2017 17:08:42 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id j8J6kunntsQb; Mon, 2 Oct 2017 17:08:33 -0400 (EDT)
Received: from (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id AC6BD62201; Mon, 2 Oct 2017 17:08:32 -0400 (EDT)
To: Christian Huitema <>, The IESG <>,
References: <> <>
From: Robert Moskowitz <>
Message-ID: <>
Date: Mon, 2 Oct 2017 17:08:27 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------9C5086BB7819EB06DCC4FE03"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Ideas] Fwd: Fwd: Re: 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: Mon, 02 Oct 2017 21:08:48 -0000

On 10/02/2017 11:55 AM, Christian Huitema wrote:
> I just realized that I forget to copy this message to the IESG and 
> IDEAS mailing lists. Sorry.
> -------- Forwarded Message --------
> Subject: 	Fwd: Re: WG Review: IDentity Enabled Networks (ideas)
> Date: 	Sun, 1 Oct 2017 17:06:46 -0700
> From: 	Christian Huitema <>
> To: 	IETF Discussion Mailing List <>
> On 9/29/2017 9:13 AM, The IESG wrote:
> > A new IETF WG has been proposed in the Routing Area. The IESG has not made
> > any determination yet. The following draft charter was submitted, and is
> > provided for informational purposes only. Please send your comments to the
> > IESG mailing list ( by 2017-10-09.
> ...
> >
> > Network solutions based on the concept of Identifier-Locator separation are
> > increasingly considered to support mobility, overlay networking for
> > virtualization and multi-homing across heterogeneous access networks.
> The problem there is that the same properties that facilitate routing
> also facilitate tracking.
> Consider a mobile node that switches from a Wi-Fi network to a cellular
> network. In the current state of the art, there is no relation between
> the Wi-Fi address and the cellular address. Intermediaries cannot
> observe the traffic and deduce that two different flows of IP packets
> originate from the same node. In contrast, with an ID/Loc architecture,
> the two flows are associated with the same identifier, which can then be
> used to track the movements of the device.

I have been thinking about this, Christian, and I have a proposal for 
HIP that I will be starting on shortly that will cripple this tracking 
while not interfering with mobility.  In short, there is a chain of SPIs 
used.  The endpoints know the chain, and no one else. This IS a problem 
with NAT traversal, but what is NOT a problem with NAT traversal?

But as you indicated, we need to think more about privacy, as hard as 
that is...

> Similarly, consider a node that connects several times to the same
> network, and each time uses IPv6 temporary addresses. The web servers
> that it contact cannot use the IP addresses to correlate different
> connections that happened at different times. This would change if the
> identifier in an ID/LOC architecture remained constant.
> Multipath TCP and planned multipath extensions of QUIC are example of
> transport protocol that allow transport connections to use multiple
> network paths simultaneously. In both cases, there s significant work
> going on to ensure that intermediaries cannot easily associate the
> traffic on the multiple paths with a single connection. If the
> multi-homing function was delegated to an ID/LOC system, intermediaries
> could potentially observe the identifiers and associate these connections.
> In short, careless applications of the ID/LOC architecture could easily
> result in serious privacy issues. The proposed charter does include a
> brief statement about privacy:
> > - Analysis of the concepts of identity-identifier split and dynamic
> > identifier changes, including their implications on anonymity and privacy.
> > Explicitly, the framework must define privacy requirements and how potential
> > extensions/solutions should meet them.
> This is a good start, but the whole concept of "unique identifiers" is
> scary, and I would like to see this expanded. For example, I would like
> to see an explicit reference to a baseline, e.g. assuring no privacy
> downgrade compared to IPv6 temporary addresses, or assuring that hosts
> that elect to not be tracked when roaming across networks will not be. I
> also know that there have been discussions of hiding identifiers from
> intermediaries, and i would like to see that as an explicit goal of the
> proposed WG.
> -- 
> Christian Huitema
> _______________________________________________
> Ideas mailing list