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

Robert Moskowitz <> Tue, 03 October 2017 12:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4122D134CCB; Tue, 3 Oct 2017 05:43:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hIvQgqD8YXld; Tue, 3 Oct 2017 05:43:28 -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 DBE641344D1; Tue, 3 Oct 2017 05:43:27 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 021F96219A; Tue, 3 Oct 2017 08:43:26 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 9DtmrccqejbN; Tue, 3 Oct 2017 08:43:16 -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 942426216F; Tue, 3 Oct 2017 08:43:14 -0400 (EDT)
To: Uma Chunduri <>, Christian Huitema <>, The IESG <>, "" <>
References: <> <> <>
From: Robert Moskowitz <>
Message-ID: <>
Date: Tue, 3 Oct 2017 08:43:10 -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="------------E54625CD2FB2C6508D3D4735"
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: Tue, 03 Oct 2017 12:43:31 -0000

On 10/02/2017 08:30 PM, Uma Chunduri wrote:
> Hi Christian,
> In-Line [Uma]:
> --
> Uma C.
> *From:*Ideas [] *On Behalf Of *Christian 
> Huitema
> *Sent:* Monday, October 02, 2017 8:56 AM
> *To:* The IESG <>rg>;
> *Subject:* [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks 
> (ideas)
> 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.
> 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.
> [Uma]: Mobility tracking as you explained could be important and 
> should be considered in the threat analysis.
>                Thanks for pointing the efforts in MPTCP/QUIC to 
> mitigate this.
>   If the
> multi-homing function was delegated to an ID/LOC system, intermediaries
> could potentially observe the identifiers and associate these connections.
> [Uma]: True, but I would note this is respective data plane protocol 
>  mechanism that should address this is in-line with Robert’s response 
> (sounds like very good proposal to start with) ..
> 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.
> [Uma]: I am not sure how this can be goal of IDEAS, which mostly talks 
> about control plane aspects.

This is really hard.  One party has to have its identity in the clear to 
start the control plane, otherwise you have this great DOS attack.  We 
went through this discussion in the early days of HIP. This is why the 
Responder's HIT is in the clear; the Initiator's can be hidden.  Well 
the HI can.

But once you have state between the peers, much can be done.  With HIP I 
have to change the HIT derivation to allow for a chain of HITs off the 
HI that Eve cannot connect.  But this raises challenges for NAT traversal...

I can do this for HIP; I don't know, yet, how to make this general for