[Ideas] Comments on draft-ccm-ideas-identity-use-cases-02

[Tom Herbert <[e-mail]>]

I reviewed the revised draft and have included comments on various
sections below.

Overall, this draft is better than the previous ones, but I think
still needs some clarifications and more discussion about security.


Abstract:

"IDentity-EnAbled networkS (IDEAS) introduce the concept of Identity
(IDy) into networking."

Identity is already used in networking. For instance, identity is part
of X.509 certs exchanged in TLS for instance. Maybe this should be
"into the networking layer"

2. Acronyms

"Communications Entity" I don't think this term is necessary to
define, "node" should suffice. A node is any endpoint of communication
and can be real or virtual. An identifier is a non-topological
identification of a node.

"Locator" definition really doesn't say way a locator is.

"MS" Why "traditional"? Can't this be just be any mapping server? The
acronym also conflict the use of MS in section 1 which denotes it to
be Mapping System not Mapping Server. Mapping system should probably
have its own acronym also.

3. Uses for IDy

"IDy representing the communications entity enables authentication
(AUTH) with the mapping and Identity services infrastructure."

It is not clear to me what the relationship between IDy and other
forms of identity that are commonly used for authentication. For
instance, if a mobile network operator choose might chose to control
access to all of its devices based on certificates, X.509 identity,
and TLS/DTLS. In this case, does IDy == X.509 identity?

"IDy provides de-anonymization for various data plane ephemeral
Identifiers, if required, and enables resolution of"

What does "if required" mean here. Is this referring to the
requirements of framework, or per use case, per deployment, etc...

"which communications entity is behind these identifiers for
legitimate users (entities itselfin some cases)."

I'm don't know what "legitimate users" means. Maybe it means authorized parties?

I think the most critical use case isn't described here. It is in
mobility where a devices may have many thousands of identifiers
assigned to it. When the device moves, all the identifiers must move
with it and want this to be performed in one operation in the
infrastructure. Without the ability to perform a group operation,
identifier-locator might not be able to scale. Today this is done by
virtue of moving a device prefix, but device prefixes do not have
reasonable privacy or security properties (see ongoing discussion in
v6 ops about host prefix assignment and privacy ramifications).

4. IDy in IDEAS

"An IDy identifies a Communications Entity."

So does an IDf :-)

The diagram is good and makes the relationships clear.

5.1 Privacy

"This allows a communications entity to reveal "who it is" to the
receiver if it chooses to do so,"

Since the receiver already knows all of it's identifiers, it can
inform other parties it's communicating "who it is" using its side
channel communications. I don't see why the mapping system needs to be
involved here.

Also, several places in this document seem to assume that
communicating endpoints have implemented identifier-locator protocols
and can access a common mapping system. I think that is much more the
exception than the rule. Consider that a mobile network may implement
mapping system to facilitate mobility of devices in the network. A
communicating node on the Internet should not care about that and
identifier-locator must be transparent to the communication.

5.2.  Unified Policies

I think it's easier to say that identity provides an equivalent
(although more flexible) mechanism for network policy than prefix
based policy mechanisms in use today.

"some requesting groups may receive an empty response from GRIDS
Infrastructure for IDfs referring to a certain IDy"

This is very weak security. All it takes is one node leaking
information to the rest of the world to break this. The fact that
someone keeps their name out of the phone book doesn't mean they won't
get barraged by sales calls.

5.2.1 Access Restriction Policies

The first paragraph here is redundant with end of previous paragraph.

"A communications entity may define that it wants to communicate only
with certain other entities.  To achieve this, a communications entity
MAY define a rule regarding who can request and obtain its IDf."

I think I'm missing something basic here. If host A wants to talk to
host B, is the idea that host A first needs to know the identity of
host B? And then uses the identity to lookup identifiers? If so, how
does host A find the identity of host B? DNS? What if host A is a
random node on the Internet and host B is node in a mobile network
that has the mapping system for which host A doesn't talk to?

"The GRIDS Infrastructure with may be a means to find a set of
communications entities with certain associated metadata, provided
that they have agreed to be searchable"

So being searchable is opt-in then? What does it mean that they
"agreed to be searchable"? Is this a box that is an end user checks
off when they sign up for carrier service?

5.4.  Access Security and Manageability

"There are various possible scenarios on why a long-lived IDfs by a
communications entity has to be withdrawn."

The phrase "long-lived" is ill-defined. Not just in this document, but
I've noticed this popping up in other WGs. The obvious problem is that
there is no common definition of the time it takes something to be
long-lived. Someone might say a day, another an hour, a minute, a
second, ten milliseconds etc. In identifier-locator, it may be that a
node wants to use a different identifier in every connection it
creates which is the best privacy it can get.

The only reasonable answer may be that the node being assigned
identifiers or identities controls their life cycle. So from the POV
of the mapping system there doesn't need to be any distinction between
long-lived and ephemeral. Persistent identifiers may be needed for
servers.

5.5.  Delay-Tolerant Networking (DTN)

I'm not sure why this is relevant here. Proxies already exist for
various purposes, the use of identifier-locator shouldn't have any
bearing on that.

8.  Security Considerations

This section needs to be expanded considerably.

Statements like "This abstraction gives significant security
benefits..." aren't very interesting in this section-- this should be
in the motivation section. What is interesting in this section are the
potential security risks, threats, and mitigations that are created by
the proposal.

"The IDy concept and data stored in GRIDS are intended for routing and
forwarding purposes only."

This is intent, but it's pretty obvious that the system could be used
for other purposes. For instance, a mapping system could be used to
track the geo-location of the device. There may be legal justification
for that, but nevertheless, this is an example if the data being used
in GRIDs for purposes other than routing or forwarding.

"They are in no way intended and must not be used to store human-
identifiable information, personal identifiers, and the like."

A major use case of identifier-locator protocols is going to be
mobility in public wireless networks. The preponderance of devices in
these networks today are personal devices that typically have a 1-1
correspondence between the device and a human user. So if a such a
device is being tracked, then the human behind them is being tracked.
If someone has access to the mapping system information (e.g. they can
get all the IDfs for an IDy) the only missing piece of information
needed to track individuals is the name of the user. Since identifiers
are public, all they need to do is match one identifier to a name.
This is easily done of they have access to an authenticated service
where users login-- there are many examples of such services and there
are companies that already implement this sort tracking within their
own services. What we don't want is a means to enable tracking across
the whole Internet.

The tracking problem is two fold.

First, if I know all of the identifiers for a user's device then a I
can track the users network communications by IP address. This can be
done in the network with packet traces or server logs.

Secondly, if I have access to the locator information for a device
then I will know the physical location of the device with pretty good
accuracy. Since, the there's a human user of the device then I know
where they are. This by the way is why I don't think end user devices
should ever participate in identifier-locator protocols, doing so
would make is easy to determine locations of individuals and hence
enable stalkers everywhere!

All of this is not to say the data should not be collected, to the
contrary it is probably a necessity to make identifier-locator
protocols useful and improve privacy. It's also true, that this sort
of data (like device to location) must already be maintained in mobile
networks, and there are already services that are designed to track
location of humans (e.g. Life360). The controversy arises from the
fact that this is being introduced into IP (much broader use case),
its defining defining a potentially common standard means to access
the data, and unlike services seems to be opt-out more than opt-in
from users POV.

I suggest that the security section acknowledges that the data in a
mapping system is HIGHLY sensitive and then highlight appropriately
strong methods to protect the data and limit the scope of
dissemination.

Tom