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

From: Christian Huitema <[email-masked]>
Date: Mon, 2 Oct 2017 08:55:36 -0700

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 <[email-masked]>
To: 	IETF Discussion Mailing List <[email-masked]>

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 ([email-masked]) 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Oct 2017 16:18:25 +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 [mailto:[email-masked]] On Behalf Of Christian Huitema
Sent: Monday, October 02, 2017 8:56 AM
To: The IESG <[email-masked]>; [email-masked]
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 <[email-masked]><mailto:[email-masked]>

To:

IETF Discussion Mailing List <[email-masked]><mailto:[email-masked]>

> IESG mailing list ([email-masked]<mailto:[email-masked]>) by 2017-10-09.

...

proposed WG.

--

Christian Huitema

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 Oct 2017 09:23:54 -0700

> use cases where mobile node tracking is indeed desirable?

Note Christian, in LISP you can have ephemeral and crypto EIDs. See draft-ietf-lisp-eid-anonymity-00 and draft-farinacci-lisp-ecdsa-auth-00, respectively, for details.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Mon, 2 Oct 2017 09:24:05 -0700

On Mon, Oct 2, 2017 at 8:55 AM, Christian Huitema <[email-masked]>
wrote:

> From: Christian Huitema <[email-masked]> <[email-masked]>
> To: IETF Discussion Mailing List <[email-masked]> <[email-masked]>
>
> I don't think the idea is that identifiers in ID/LOC are intended to be
constant. To the contrary, an end host should be able to use an arbitrary
identifiers to create IP addresses to achieve the exact same effect of IPv6
temporary addresses (from the application point of view the mechanism is
identical). There should be no systematic means within the network to
correlate that two packets with different source addresses are from the
same node.

There is one caveat, not so much specific to ID/LOC, but how host IPv6
address assigned is being done. It is common to assign a /64 IPv6 address
to UE. A stated benefit in security is that this makes address scanning
difficult (i.e. an attacker scanning over a 2^64 space is difficult). The
downside of this that address obfuscation for device tracking is only
effective in the upper 64 bits which means the available address space for
untrackable device addresses is much smaller. I believe that the upshot is
that more bits should be assigned to device prefix to achieve security.
This was discussed in 6man list, but is also relevant to ID/LOC.

Tom

> _______________________________________________
> Ideas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ideas
>
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 2 Oct 2017 09:27:32 -0700

> use cases where mobile node tracking is indeed desirable?
If the good guys are able to track mobile devices based on plain text
address, doesn't that mean the bad guys will be able to do that also? Seems
a little bit scary prospect to me in the context of aviation...

Tom

Thanks - Fred
>
>
>
> *From:* Ideas [mailto:[email-masked]] *On Behalf Of *Christian
> Huitema
> *Sent:* Monday, October 02, 2017 8:56 AM
> *To:* The IESG <[email-masked]>; [email-masked]
> *Subject:* [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks
> (ideas)
>
>
>
> *Subject: *
> *Date: *
> *From: *
> Christian Huitema <[email-masked]> <[email-masked]>
>
> *To: *
>
> IETF Discussion Mailing List <[email-masked]> <[email-masked]>
>
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Oct 2017 16:30:40 +0000

Hi Tom,

>If the good guys are able to track mobile devices based on plain text address, doesn't that
> mean the bad guys will be able to do that also? Seems a little bit scary prospect to me in
> the context of aviation...

There are no bad guys in this network. The underlay network is secured against
unauthorized access.

Thanks - Fred

From: Tom Herbert [mailto:[email-masked]]
Sent: Monday, October 02, 2017 9:28 AM
To: Templin, Fred L <[email-masked]>
Cc: Christian Huitema <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks (ideas)

On Mon, Oct 2, 2017 at 9:18 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi Christian,

If the good guys are able to track mobile devices based on plain text address, doesn't that mean the bad guys will be able to do that also? Seems a little bit scary prospect to me in the context of aviation...

Tom

Thanks - Fred

From: Ideas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Christian Huitema
Sent: Monday, October 02, 2017 8:56 AM
To: The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks (ideas)

-------- Forwarded Message --------
Subject:

Date:

From:

To:

...

proposed WG.

--

Christian Huitema

_______________________________________________
Ideas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ideas

---

From: Christian Huitema <[email-masked]>
Date: Mon, 2 Oct 2017 09:46:02 -0700

> Note Christian, in LISP you can have ephemeral and crypto EIDs. See draft-ietf-lisp-eid-anonymity-00 and draft-farinacci-lisp-ecdsa-auth-00, respectively, for details.

Dino, I am well aware that we (well, you) *can* engineer ID/LOC networks
to have good privacy properties. But I am also aware that if this is not
an explicit goal in the charter, we may very well end up with
architectures that have pretty bad properties. For example, most ID/LOC
architectures rely on a database that provides the up-to-date LOC for an
ID. In my bad dreams, I could see the database extended to provide other
properties of the ID, such as subscriber ID. Similarly, there was a
proposal some time ago to have a unique IPv6 identifier for every EU
citizen; that bad idea was quashed, but we could easily see something
like that resurface as on unique ID per user. That's why I would like to
see the proposed charter to be crystal clear about privacy requirements,
rather than just say that we will think about it.

-- 
Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Mon, 2 Oct 2017 09:48:27 -0700

On 10/2/2017 9:30 AM, Templin, Fred L wrote:

> address, doesn't that

Fred, that's the kind of statements that really give me pause. "Let's do
something dangerous on my network because it is well isolated and
secure." I am pretty sure that the gentle folks at Equifax were thinking
along similar lines.

-- 
Christian Huitema

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Oct 2017 16:55:09 +0000

Hi Christian,

>Fred, that's the kind of statements that really give me pause. "Let's do something dangerous
> on my network because it is well isolated and secure." I am pretty sure that the gentle folks at
> Equifax were thinking along similar lines.

Understood, but for the Aeronautical Telecommunications Network (ATN) it really
is secured at the lower layers and has to be that way. There are no connections to the
open Internet, and there can be no opportunity for rogue ATCs to come in and start
giving orders to airplanes. This is true whether/not there is a Loc/ID split architecture
in place.

Thanks - Fred

From: Christian Huitema [mailto:[email-masked]]
Sent: Monday, October 02, 2017 9:48 AM
To: Templin, Fred L <[email-masked]>; Tom Herbert <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]
Subject: Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks (ideas)

Fred, that's the kind of statements that really give me pause. "Let's do something dangerous on my network because it is well isolated and secure." I am pretty sure that the gentle folks at Equifax were thinking along similar lines.

--

Christian Huitema

---

From: Tom Herbert <[email-masked]>
Date: Mon, 2 Oct 2017 10:04:20 -0700

On Mon, Oct 2, 2017 at 9:55 AM, Templin, Fred L
<[email-masked]> wrote:
>> something dangerous
Fred,

That may be true for your use case, but we can never define IETF
protocols on the basis that something at a lower layer will secure
them.

Tom

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Oct 2017 17:08:46 +0000

Hi Tom,

> -----Original Message-----
> Sent: Monday, October 02, 2017 10:04 AM

IPv6 Neighbor Discovery [RFC4861] is a prominent example of an
IETF protocol that relies on lower layer security.

Thanks - Fred

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 2 Oct 2017 17:08:27 -0400

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

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 3 Oct 2017 00:30:12 +0000

Hi Christian,

In-Line [Uma]:

--
Uma C.

-------- Forwarded Message --------
Subject:

Date:

From:

To:

...

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

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

that elect to not be tracked when roaming across networks will not be.

 I

proposed WG.

[Uma]: I am not sure how this can be goal of IDEAS, which mostly talks about control plane aspects.

--

Christian Huitema

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 3 Oct 2017 08:43:10 -0400

On 10/02/2017 08:30 PM, Uma Chunduri wrote:
>
> Hi Christian,
>
> In-Line [Uma]:
>
> --
>
> Uma C.
>
> *From:*Ideas [mailto:[email-masked]] *On Behalf Of *Christian 
> Huitema
> Christian Huitema <[email-masked]> <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> IETF Discussion Mailing List <[email-masked]> <mailto:[email-masked]>
>
> > IESG mailing list ([email-masked] <mailto:[email-masked]>) by 2017-10-09.
> ...
> >
> [Uma]: Mobility tracking as you explained could be important and 
> should be considered in the threat analysis.
> [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) ..

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

Bob

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 5 Oct 2017 00:04:50 -0700

> I think there is also an aspect of "tracked by whom" which needs to be
> considered.
>
> <Padma> Perhaps it would be worthwhile to clarify this in the charter.

> Today a user is likely to have different concerns about being tracked by
> e.g., Facebook or Google when the are logged in the their account then
> being track by a 3rd party such as an ISP or nation state. In the same way
> an (industrial) IoT device might need to be tracked by the owner of that
> device, without it being trackable by a 3rd party.
>
> There might be an implicit assumption in the IDEAS work that there will be
> a globally id->loc database readable by all, the same way we think of the
> global DNS. But I think that this would be overly limiting and push us into
> a black or white privacy vs. functionality discussion.
>
>

> Elsewhere I see IETF protocols like EVPN which is used to advertise
> (factory assigned and permanent) Ethernet MAC addresses in BGP, which is
> global. However, the way that protocol is deployed the distribution of the
> EVPN routes are constrained (by BGP configuration) to the domain which
> should have access to such information. The notion of having a
> distribution/lookup/mapping technology which is capable of being global,
> i.e., not tied to technology, but where the information sharing is
> restricted by policy makes a lot of sense to me. This policy could be some
> notion of closed user groups.
>
> <Padma>
Yes the point was to restrict information to eavesdroppers or share with
need to know.

> Thus I think we should collectivity look at a combination of approaches
> which includes the MP-TCP-like locator agility with its privacy protection
> and also cryptographically strong identifiers in IDEAS with privacy
> protection designed in from day one.
>
> <Padma> Agree

> My 2 cents,
>    Erik

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 5 Oct 2017 09:28:23 -0700

> could potentially observe the identifiers and associate these connections.

Christian, just to be clear, in LISP, temporary/ephemeral EIDs can be used for the public case. For a private use case, one uses crypto-EID authentication to regsiter and to get mappings from the mapping database (can be used within a closed user-group VPN). And both for the public and private case, crypto-EIDs can be used so a hash is pretty opaque to trackers. And there is no reason you cannot use a set of private/public key pairs and crypto hashes to send packets.

So there are solutions to this. And they are implmented and ARE NOT complicated.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 5 Oct 2017 09:30:50 -0700

> an explicit goal in the charter, we may very well end up with

Agree 100%.

> rather than just say that we will think about it.

Well, your dream is going to come true. There will be an IPv6 EID per IoT device.  ;-)

Dino