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

Alexander Clemm <alexander.clemm@huawei.com> Mon, 16 October 2017 23:45 UTC

Return-Path: <alexander.clemm@huawei.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA66132403 for <ideas@ietfa.amsl.com>; Mon, 16 Oct 2017 16:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0NNhKwIjYEO for <ideas@ietfa.amsl.com>; Mon, 16 Oct 2017 16:45:50 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1120126BF0 for <ideas@ietf.org>; Mon, 16 Oct 2017 16:45:49 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQT62231; Mon, 16 Oct 2017 23:45:47 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 17 Oct 2017 00:45:45 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Mon, 16 Oct 2017 16:45:40 -0700
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Tom Herbert <tom@herbertland.com>, "ideas@ietf.org" <ideas@ietf.org>
Thread-Topic: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
Thread-Index: AQHTRqsmf6hiJoT45EuGVllvxpgrQ6LnEYrw
Date: Mon, 16 Oct 2017 23:45:39 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB67EC@sjceml521-mbx.china.huawei.com>
References: <CALx6S37N5GSVG95mOv2QKu5TZ6dRGehhTriXJ5eqTG+MQZiQGg@mail.gmail.com>
In-Reply-To: <CALx6S37N5GSVG95mOv2QKu5TZ6dRGehhTriXJ5eqTG+MQZiQGg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.48.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59E544AC.0069, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 29cc6edb49b2ff973d78594621a6b010
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/iX-O2GCRhvZNKL8DxqdW2NyfsLQ>
Subject: Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
X-BeenThere: ideas@ietf.org
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." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Oct 2017 23:45:53 -0000

Hi Tom,

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

Thanks
--- Alex

> -----Original Message-----
> From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Tom Herbert
> Sent: Monday, October 16, 2017 11:18 AM
> To: ideas@ietf.org
> Subject: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
> 
> 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.

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

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

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

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

<ALEX> Sure
</ALEX>

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

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

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

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

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

<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
> v6 ops about host prefix assignment and privacy ramifications).

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

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

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

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

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

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

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

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

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


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

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

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

<ALEX> Thanks, note taken
</ALEX> 

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

<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
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas