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

From: Tom Herbert <[email-masked]>
Date: Mon, 16 Oct 2017 11:18:03 -0700

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

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 16 Oct 2017 23:45:39 +0000

Hi Tom,

Thank you for your review!  A couple of replies inline, <ALEX>

Thanks
--- Alex

> -----Original Message-----
> From: Ideas [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Monday, October 16, 2017 11:18 AM
> To: [email-masked]
> Subject: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
> 
> Overall, this draft is better than the previous ones, but I think still needs
> some clarifications and more discussion about security.

<ALEX> Glad to hear we are making progress! 
</ALEX>

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

<ALEX> Sure, makes sense
</ALEX>
> 
> 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.

<ALEX> Node is fine with me, but given the "pickiness" of some of the feedback, we decided to be more specific at least in this revision.  I would not mind to change it back to just "node'. 
</ALEX>

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

<ALEX> Sure
</ALEX>

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

<ALEX> If the operator chooses to, they could do it.  It depends on the use case / specific requirements.  

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

<ALEX> It refers to the use case
</ALEX> 

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

<ALEX> Authorized and authenticated.  It enables the resolution only when the communications entity agrees to reveal an identifier under which it is known (note: this would not be an IDy).  

As we tried to explain, the purpose is to let a receiver know who the source of a packet is, if the source is identified by an anonymized ID to obfuscate who it is to outside observers but not the receiver.  The sender still has the choice to obfuscate who it is even to the receiver, but then it is up to the receiver to decide if it wants to accept a packet from a source who does not want to reveal who it is.
</ALEX>

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

<ALEX> Thank you for your suggestion.  We shall look into adding it.  Can we come back to you to help us craft some text?  
</ALEX> 

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

<ALEX> This can do more!  Yes, the receiver knows its identifiers, but the sender may know only a publicly known identifier.  When sending a packet, an observer can still tell that someone is sending packets to this particular receiver.  

The "side channel" can be used to indicate to the sender which identifier it should use for the receiver.  This can be an entirely anonymized IDf, allowing to obfuscate both sender and receiver.   The side channel can be provided through GRIDS, and the IDf to use can be provided to the sender in response to a map resolution request along with the locator of the receiver.  
<ALEX>

> 
> 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.
> 
<ALEX> Sure, thanks
</ALEX> 

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

<ALEX> Do you have a better suggestion?  I do think this is an improvement over the situation that we have today.  Also, remember that we could quickly "cycle through" IDfs, in case IDfs do get compromised over time.  
</ALEX> 

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

<ALEX> 
If A wants to talk to B, A needs to have some way to refer to B.  For this, he needs to know an IDf.  This can be a well-known IDf under which B is commonly known.  It is NOT the IDy.  B's  IDy is only used by the mapping system / GRIDs to "group" the IDfs that belong to B, and for B to authenticate itself to GRIDS/  mapping system.  

To the second part of your question, we are not looking at Inter-GRIDS scenarios.  
</ALEX> 

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

<ALEX> Yes, it is opt-in.  The idea is that the node or its owner will have the ability to control who can discover or track their locator.  Today there is no such control.  This is why botnets are so successful.  
</ALEX> 

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

<ALEX>  Sure.  "Long-lived" is relative.  In the context and for the purposes of this document, it refers to a time duration that is long enough for an IDf to be "known".  In many cases, you do want other entities to be able to find you, so you need to give them something that they can use to refer to you.  
</ALEX>

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

<ALEX> Thanks, note taken
</ALEX> 

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

<ALEX> Yes, clearly there is more for the section.  At this point, we are limiting this to the statement that we are aware that there are security ramifications and that more work is needed, referring to the work that is chartered separately.   As this part gets developed further, we will expand on this section, and we will certainly indicate that mapping data is security and privacy sensitive.  At the same time, one aspect to point out is that many of the security that have been pointed out are not introduced by or even specific to IDEAS, but are artefacts of today's data planes, in many cases not secured at all. 
</ALEX>

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

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 17 Oct 2017 00:31:41 +0000

Thx for the feedback on this version. I saw Alex's responses - some more of it below.

--
Uma C.

----

	>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).
[Uma]: Yes.

	>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.
[Uma]:  It's relative. This is not new and not introduced in IDEAS.  This is nothing but HIT in HIP or EID in LISP (which are used for location resolution today).  The context of this usage is to differentiate from the one time anonymous identifiers used in the data plane.. Can clarify further.

	>This by the way is why I don't think end user devices should ever participate in identifier-locator protocols...
 [Uma]: You  are making a pretty broad statement here.  Which device uses this is orthogonal to IDEAS.   We have a host based solution (ID/LOC) HIP  and a network based solution LISP.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 16 Oct 2017 18:24:55 -0700

> Thx for the feedback on this version. I saw Alex's responses - some more of it below.
Uma,

This problem I highlighted would only exist on public networks where
end user devices are not under complete control of the
infrastructure-- i.e. smart phones on a public carrier network. In a
private data center for instance, where all hosts can be controlled,
there is no issue in running identifier-locator on hosts and that in
fact is a common deployment of network virtualization.

The exploit I'm conjecturing would work like this:

* Suppose that a UE (e.g. a smartphone) participating in an
identifier/locator protocols is hacked.
* The only thing the hacker does is to tap all packets sent or
received on wireless network interface.
* In order to be able to tap packets all a user needs to do is "root"
the Android device (that is gain root access) and then run tcpdump.
This is not difficult to do, there are instructions on the web how to
set this up.
* Once tcpdump is running, the hacker can now see the locators of
destinations the device is sending packets and can easily correlate
those packets to the higher level communications. It can also derive
their device's locator by looking at received packets.
* The hacker can then just drive around sending traffic between two
devices in their car. From this, they can create a geo map of
locators. The granularity of this map is the granularity of the
locators. Presumably, locators might refer to eNodeBs, so smaller
cells yield more accurate locator to physical location mapping.
* Given that one hacker can do this, then thousands will do it and web
sites will spring up that provide locator geo maps in a mash up.
* Efforts to obfuscate or rotate identifiers does not help much here.
Obfuscation complicates routing in the network such that translations
need to happen anyway. Periodic rotation of locators is defeated if
there are enough devices doing the mapping to keep the maps up to
date.
* The net effect is that this enables stalkers. An individual simply
initiates a communication with their target. For instance, this could
be a chat or phone call. If in doing this the locators for the device
belonging to the target are made visible to the hacker, then the
physical location of the target can be deduced using the locator geo
maps described above to the accuracy of the locator to physical world
maps.

It's true this may be orthogonal to the design of a mapping system or
identifier-locator protocol, however it does illustrate the dangers of
not adequately protecting sensitive information. Anyone who works at
companies like Apple and Google that regularly collect device
geo-location can vouch that it is among the most sensitive of all the
PII they collect. Accordingly, they implement extremely strong access
controls to the point that even that only a tiny number of employees
can directly access the data.

Tom

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 17 Oct 2017 21:17:00 +0000

Coming back to the IDEAS work, one of the goals is to create a standardized mapping system with various ID services (mobility, access security, pub/sub,  grouping etc). 
There are various enterprise deployments where these services are needed and the ability to authorize  who can update mapping and who can request mapping is critical for deploying some of  these services. 
For ILA or  for DC VM mobility some of the services may not be needed or Identity is an overhead (but I saw from your responses earlier, you need authorization on who can update in a multi tenenant environments) 
and that can be made optional if not needed.  But, I see you are arguing on both sides.  If you have a better solution to address the above needs please share it.

--
Uma C.

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Monday, October 16, 2017 6:25 PM
To: Uma Chunduri <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
...

	>This problem I highlighted would only exist on public networks where end user devices are not under complete control of the
	>infrastructure-- i.e. smart phones on a public carrier network.

	> In a private data center for instance, where all hosts can be controlled, there is no issue in running identifier-locator on hosts and that in fact is a common deployment of network virtualization.
[Uma]: Sure, agree. And you need a mapping system with standardized interfaces and a control protocol to interact to addressing this space.

	>* Suppose that a UE (e.g. a smartphone) participating in an identifier/locator protocols is hacked.
[Uma]: There are so many cases, where  things need to be handled, which includes not only hacked but lost/stolen devices etc. There is something called revocation or disabling the device based on the auth. method used in the device by the provider.

                ...

	>Obfuscation complicates routing in the network such that translations need to happen anyway. Periodic rotation of locators is defeated if there are enough devices doing the mapping to keep the maps up to date.
[Uma]: Obfuscation obviously doesn't solve all the evils. It has its own place and if we truly care use end to end encryption where ever is needed.
                Again, data plane constructs and mechanisms for protection are under the purview of the underlying ID/LOC protocol in question. IDEAS can only help augment some of the features needed for these protocols.

	>It's true this may be orthogonal to the design of a mapping system..
[Uma]: Yes, it's mostly orthogonal  to IDEAS.

                > Anyone who works at companies like Apple and Google that regularly collect device geo-location can vouch that it is among the most sensitive of all the PII they collect. 
	>Accordingly, they implement extremely strong access controls to the point that even that only a tiny number of employees can directly access the data.

[Uma]: You are right. This is exactly  what we have been arguing as well.  Any data that is sensitive will have strong access controls and not publicly exposed. 
 	Also, I am not understanding the above logic fully  - because all sorts of PII is collected in various applications or just because of the fact that you are on your cellular device your provider can track you (or how these are protected today). 
	Privacy seems more of a misnomer sometimes (from the apps, to browser to the cellular devices and this  only further proliferates with all sorts of  devices doing M2M would be on various networks soon).