Re: [Ideas] BOF @IETF 99 Preparation - problem statement

[Michael Menth <[e-mail]>]

Hi Tom,

we have alreaday LISP, ILA, and ILNP for implentation of Loc/ID split.
We have DNS and DDT as mapping systems used in these contexts.
So, there is already quite some support for basic Loc/ID split.

What's missing is an adequate protection of IDs in the above mentioned
context. When communicating with a unique ID, communication becomes
trackable like in the early days of IPv6. IPv6 privacy extensions solved
that problem. But with IPv6 we don't know whom we are talking to. So
what's desirable is a permanent ID for an identity which can be mapped
to various temporary IDs that are used for communication. A mapping
system associates identities and identifiers but can be queried only by
authorized identifiers. That means, communication becomes transparent to
authorized users while protecting privacy against others. However, we
need to explore how these objectives can be achieved with current
protocols and what pieces and extensions are missing.

That mechanism may be an enabler for true Loc/ID split as it allows to
use a permanent ID for identity (think of user contract) and a temporary
ID for each communication, for certain time spans, or devices. Permanent
IDs are not acceptable for privacy concerns in many use cases, e.g.,
automotive. As the temporary ID may be looked up by a provider, it may
be possible to apply per-identiy policies to traffic. If an identifier
is corrupt or gets attacked, of if a device gets lost or is exchanged,
the corresponding identifier may be substituted by another.

This is the filtered result of several telcos with proponents of IDEAS.
It requires some effort to clearly outline the potential of IDEAS in
various use cases as we're looking really beyond Loc/ID split.

Best wishes,

Michael


Am 11.06.2017 um 01:31 schrieb Tom Herbert:
> On Sat, Jun 10, 2017 at 1:31 AM, Michael Menth <[e-mail]> wrote:
>> Dear Padma, all,
>>
>> I've tried to condense the essence of what I perceived from multiple
>> IDEAS brainstormings, documents, and email discussions. This may be a
>> base for a problem statement. Please add missing aspects!
>>
>> IDentity-EnAbled networkS (IDEAS) describes how identities (Idys),
>> identifiers (Idfs), and locators may be used for future communication
>> using existing protocols. Missing features are identified and added.
>>
>> An Idy is a permanent ID (PID) to uniquely identify an entity. To
>> protect its privacy, an entity may choose additional temporary IDs
>> (TIDs) for communications, so-called Idfs. A mapping system maps these
>> Idfs to their Idy so that communication partners may look up an Idf's
>> Idy. To preserve its privacy, the entity controls the mapping system and
>> may restrict access to it for certain Idfs or Idys.
>>
> Hi Michael,
> 
> I'm not following we need to have both identities and identifiers nor
> what the operational difference would be. This seems like a lot of
> complexity to me.
> 
> In ILA for instance, there are just identifiers and locators. The
> management plane creates identifiers on request (every task gets a
> unique identifier for instance). The mapping system maps identifiers
> to locators. Identifiers identify something but we really don't care
> what they identify. The same object could be assigned multiple
> identifiers for privacy as you describe below, but the mapping system
> shouldn't care about that. Identifiers can be registered in the
> mapping system, and then unregistered when they are no longer used--
> so there's no concept of permanent or temporary identifiers.
> Uniqueness of identifiers is a key attribute. For security, we need
> tight control over who can modify the mappings and who's allowed to
> query.
> 
> Can you maybe elaborate on how identities would make things better in
> the scenario I described?
> 
> Tom
> 
>> Both Idys and preferentially Idfs may be used for communication. They
>> identify the communication partner but not her location on the Internet.
>> To denote the location of an entity, one or more locators are needed
>> that describe how the Idy/Idf can be reached. A mapping system allows to
>> look up the locators so that traffic can be sent to the Idy/Idf. This is
>> the well-known Loc/ID split providing benefits such as improved mobility
>> (e.g. for VMs in a datacenter), Internet-scale SDN, improved traffic
>> engineering and other flexibility aspects.
>>
>> The advantage of that system is that entities may use Idfs for
>> communication to better protect their Idy. Only authorized communication
>> partners can find out the corresponding Idys behind. Entities can avoid
>> being tracked on the Internet by using multiple Idfs or by regularly
>> changing Idfs. The control of the Idy/Idf mappings can restrict access
>> to selected requesting Idys/Idfs and also limit that access over time to
>> implement a right to be forgotten.
>>
>> The concept improves the current LISP protocol by adding privacy in
>> communication in a similar way as IPv6 privacy extension avoid being
>> tracked by a stable MAC address. To that end, access restriction is
>> needed for mapping system requests which also need to be encrypted to
>> avoid eavesdropping. Therefore, a major protocol definition effort is
>> needed for the mapping system that provides the Idf/Idy mapping. Other
>> aspects of this concept can be assembled from existing pieces but should
>> be brought together in a recommended fashion.
>>
> 
>> Michael
>>
>> --
>> Prof. Dr. habil. Michael Menth
>> University of Tuebingen
>> Faculty of Science
>> Department of Computer Science
>> Chair of Communication Networks
>> Sand 13, 72076 Tuebingen, Germany
>> phone: [phone]
>> fax: [phone]
>> mailto:[e-mail]
>> http://kn.inf.uni-tuebingen.de
>>
>> _______________________________________________
>> Ideas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ideas
> 
> _______________________________________________
> Ideas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ideas
> 

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: [phone]
fax: [phone]
mailto:[e-mail]
http://kn.inf.uni-tuebingen.de