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

"Templin, Fred L" <> Mon, 02 October 2017 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47400133059; Mon, 2 Oct 2017 09:18:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Foz7uQ2yo_Yl; Mon, 2 Oct 2017 09:18:38 -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 A05451326FE; Mon, 2 Oct 2017 09:18:38 -0700 (PDT)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v92GIXx7039117; Mon, 2 Oct 2017 09:18:37 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v92GIPdU039010 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 2 Oct 2017 09:18:25 -0700
Received: from (2002:8988:eede::8988:eede) by (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 2 Oct 2017 09:18:24 -0700
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Mon, 2 Oct 2017 09:18:25 -0700
From: "Templin, Fred L" <>
To: Christian Huitema <>, The IESG <>, "" <>
Thread-Topic: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks (ideas)
Thread-Index: AQHTO5b1XXR8U7Y2UkCpxQHITCbUoqLQumHA
Date: Mon, 2 Oct 2017 16:18:25 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_45e8993a73ef4bb9b3914f32c4609823XCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
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 16:18:41 -0000

Hi Christian,

For applications like civil aviation Air Traffic Management (ATM), we have
a case where it is desirable for Air Traffic Control (ATC) to be able to track
the mobile nodes (airplanes).

We want for ATC to be able to track airplanes wherever they happen to
be worldwide and connected over whatever available data links (satellite,
cellular, WiMAX, VHF, etc.). The mobile nodes also benefit from being
globally addressable at all times, since they are willing participants in the
global ATM service.

So, we see ID/Loc architectures as a useful tool for supporting this
safety-of-flight critical ATM service. Should it be noted that there are
use cases where mobile node tracking is indeed desirable?

Thanks - Fred

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

Fwd: Re: WG Review: IDentity Enabled Networks (ideas)


Sun, 1 Oct 2017 17:06:46 -0700


Christian Huitema <><>


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