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

From: Christian Huitema <[email-masked]>
Date: Sun, 1 Oct 2017 17:06:46 -0700

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: Joe Touch <[email-masked]>
Date: Wed, 4 Oct 2017 05:59:39 -0700

On 9/29/2017 9:13 AM, The IESG wrote

...

> virtualization and multi-homing across heterogeneous access networks.

I have 20 years of experience in overlays/virtualization and multihoming
that never found the need for "Identifier-locator separation".

Encapsulation subnets have always needed their own *location* names,
i.e., they need *multiple locators at different scopes*. It doesn't
matter if you call that sort of subnet "layer 2" (e.g., Ethernet),
TRILL, LISP, or anything else (and yes, IMO, those are all *exactly* the
same thing - always have been).

Joe

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 4 Oct 2017 10:54:41 -0700

> brief statement about privacy:

Agreed.

> intermediaries, and i would like to see that as an explicit goal of the

I think there is also an aspect of "tracked by whom" which needs to be 
considered.

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.

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.

My 2 cents,
    Erik

---

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

> <Padma> Perhaps it would be worthwhile to clarify this in the charter.

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

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

> 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