Subject: [Ideas] BOF @IETF 99 Preparation

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 9 Jun 2017 17:00:48 -0700

Dear IDEAS

Thank you all for your input and feedback!

In order to prepare for our BOF, we have a lot of work ahead as highlighted
by Alvaro's email. Therefore, we really need everyone to dedicate some time
on their schedule.

The *deadline for submission is July 3rd *for drafts.

We have several documents that need to be Updated/Created specifically to
address the concerns:

-        Charter

-        Problem Statement

-        Use Cases

-        Gap Analysis

-        Requirements

 1.      A complete review of all existing document to ensure we purge the
documents and streamline them. We need volunteers for that.

a.     * Charter – Padma, Suggest Michael M, Christian J + Please volunteer
or ack on suggestion*

b.      *Problem Statement  - Padma ,  Suggest Christian J, Axel, Guiseppe,
Yingzhen, Kiran + Please volunteer or ack on suggestion*

In particular we need to take this feedback in consideration.

A question was brought up about current deployment of existing ID/Loc
protocols (lisp, ila, etc.) and whether a common framework is needed (as
proposed) or if the community would be better served by a new protocol…or
maybe both.  IOW, we would like to see this discussion as part of the
problem description and justification for the work.

What about overlap with other SDOs? Why is the IETF the right place?

c.      *Use Cases: Suggest Tom H.,  David L., Alex, Uma… + Please
volunteer or ack on suggestion*

Need to add use cases for Identity and reorder the use case to answer the
general concerns.

d.
*New document – Need volunteers on thisGap Analysis: Suggest Bingyang,
Michael M., Albert C., Uma, Yingzhen + Please volunteer or ack on
suggestion *

The gap analysis that clearly and explicitly spells out what is needed and
a discussion of why current protocols may not be appropriate (if a new
protocol is required, for example). We have much of this material but this
need to be concise and to the point for clarity.

e.      *Requirements – Suggest Alex, Bingyang + Please Volunteer or ack on
suggestion*

Ensure we tie the Requirements document to the gap analysis and use case.

2.      Logistics for planning meetings and offshoot meetings to close AIs
if needed

a.     *USA  and Overall if needed* – *Pa**dma, Yingzhen*

b.      *Europe –** Please volunteer*
c.    *China – Bingyang*

3.      IETF Meeting Attendance
a.      Some folks have asked me for specific dates as they will join IETF
later in the week. I have included this as a special request.
b.      *Please see the overlap with conflicting groups and please let me
know so that we can add this asap to the request of the BOF meeting*

*We need to be ready by June 30th to ensure we make the deadlines for the
docs.*

Looking forward to hearing from you and working towards a successful BOF.

Thanks

Padma

---

From: Michael Menth <[email-masked]>
Date: Sat, 10 Jun 2017 10:31:55 +0200

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.

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: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Sat, 10 Jun 2017 12:47:33 -0700

Dear Michael

> base for a problem statement. Please add missing aspects!

Thanks for this write up

I think this is a good base
Agree, we should be integrate the identity aspect in the problem statement,
but also the use case and gap analysis documents more clearly.

> On the call yesterday we had a discussion about the clear definition of
identity in the PB
and this looks concise and to the point.

> be brought together in a recommended fashion.
Do you want to give a stab on the PB doc to integrate this.

I think part of this would work well also in the charter.

Thoughts?

Padma

---

From: Tom Herbert <[email-masked]>
Date: Sat, 10 Jun 2017 16:31:42 -0700

> 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

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

---

From: Michael Menth <[email-masked]>
Date: Sun, 11 Jun 2017 11:19:27 +0200

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

---

From: Tom Herbert <[email-masked]>
Date: Sun, 11 Jun 2017 09:59:35 -0700

> protocols and what pieces and extensions are missing.

Michael,

I think what you're describing is more address obfuscation than ID/loc
split, or in this case it's the identifier being obfuscated. This is
being implemented in IPwave for instance to mitigate the tracking
problem. The need for obfuscation is independent of the ID/loc.

Address obfuscation only works to the extent that there aren't other
means to track nodes. For instance, even if we were to use different
addresses for each packet of a TCP connection, the connection is
trivial to track but just correlating port numbers, sequence and ack
numbers sent in the clear. The only way to ensure privacy is encrypt
everything possible.

In ILA deployment, the intent is that protocol is not visible to
public networks. For instance, in a carrier network ILA would only be
used in the core (like GTP is only in the core today). The carrier
network already knows location anyway, so we don't address obfuscation
there. For packets going to the UE (over radio for instance) we do
need address obfuscation there like IPwave is doing, but again that
can be independent of id/loc.

Anyway, if this is really needed, I suggest that it is defined to be
an obfuscation layer separate from id/loc. And it should be optional
and usable outside of id/loc as well.

Tom

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Sun, 11 Jun 2017 20:38:20 -0700

Hi Tom

See Below for my comments

On Sun, Jun 11, 2017 at 9:59 AM, Tom Herbert <[email-masked]> wrote:

> Hi Tom

Obfuscation is just an aspect of this. This is a bit different from the
vehicular case.

> numbers sent in the clear. The only way to ensure privacy is encrypt
Yes this is true but you will need to do DPI in you want to act not his
packet.
I am specifically thinking of the case when you have packets in flight and
you need to change the locator.
If you want to avoid anchoring mechanism to do this and all is encrypted
then you will need to decrypt to be able to do any processing.
Another example would be ID context awareness which is difficult to achieve
today as is and even more so if we start using anon identifiers that change
all the time ...

> can be independent of id/loc.
I think we are talking of two different things here.

You are right address obfuscation can be achieved by many ways.
However, if you want to have an anonymous ID and yet have someone to
discover you and initiate communication with you then there has to be some
relationship between on what you can be looked up and the actual id you use.

On the other hand there are other possible functionalities tied the
identity that we do not have today such as access control or even policies.

> and usable outside of id/loc as well.
Absolutely.
The Identity Services in the framework are in separate modules from mapping
resolution services.
As per the requirements document, for interoperability the identity service
module is not mandatory.

Hope this clarifies.

Padma

Tom

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 12 Jun 2017 19:20:41 +0000

Hi Michael,

Very good and crisp summary. I agree with most of it and would add identity would also provide benefits providers with various value added services you hinted below.
--
Uma C.

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: Sunday, June 11, 2017 2:19 AM
To: Tom Herbert <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]
Subject: Re: [Ideas] BOF @IETF 99 Preparation - problem statement

Hi Tom,

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:
>> (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,
> 
>> 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.
>>
>> 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.
>>
>> 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
>>
>> --

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 12 Jun 2017 19:19:13 +0000

Hi Tom,

Just want to add 2 specific points on top of what Padma said below –

>I think what you're describing is more address obfuscation than ID/loc split, or in this case it's the identifier being obfuscated. This is being implemented in IPwave for instance to mitigate the tracking problem. The need for obfuscation is independent of the ID/loc.

>Address obfuscation only works to the extent that there aren't other means to track nodes. For instance, even if we were to use different addresses for each packet of a TCP connection, the connection is trivial to track but just correlating port numbers,

>sequence and ack numbers sent in the clear. The only way to ensure privacy is encrypt everything possible.

Encryption for obfuscation of identifiers is a too much of a stretch. Encryption has its own place and I see it is orthogonal to Identifier obfuscation. While in an unencrypted and  obfuscated identifiers, one can see some aspects of TCP connection, what cannot be done by the eavesdropper is identifying 2 independent  communications related to a particular entity. I see this is truly  network layer anonymous communication, if we have the ability to change communication identifiers at will (while maintaining the same identifier for entire session for mobility reasons).

To achieve this a manageable entity called ‘Identity’ for an entity at a central place is needed,  where mapping and other identity related services can be provided  as hinted in GRIDS-REQs document.

>In ILA deployment, the intent is that protocol is not visible to public networks. For instance, in a carrier network ILA would only be used in the core (like GTP is only in the core today). The carrier network already knows location anyway, so we don't address obfuscation there. For packets going to the UE (over radio for

>instance) we do need address obfuscation there like IPwave is doing, but again that can be independent of id/loc.

Obfuscation at radio layer is not in our scope (it’s 3GPP stuff) and they defined ‘some provisions’ as you stated above. But we are talking about obfuscation generically though various ID/LOC protocols in the internet and beyond managed transport network in 3GPP.

>Anyway, if this is really needed, I suggest that it is defined to be an obfuscation layer separate from id/loc. And it should be optional and usable outside of id/loc as well.

I see obfuscation provided through Identity and this is indeed separate layer (above Identifier-location mapping)  at the mapping system, where Identity to Identifiers can be mapped with certain policies associated to Identity.

IMO, this has lot of potential for providers to bring in new revenues (of course if it is done correct).

--

Uma C.

From: Ideas [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Sunday, June 11, 2017 8:38 PM
To: Tom Herbert <[email-masked]>
Cc: [email-masked]; Michael Menth <[email-masked]>
Subject: Re: [Ideas] BOF @IETF 99 Preparation - problem statement

Hi Tom

On Sun, Jun 11, 2017 at 9:59 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

Michael,

Obfuscation is just an aspect of this. This is a bit different from the vehicular case.

Yes this is true but you will need to do DPI in you want to act not his packet.
I am specifically thinking of the case when you have packets in flight and you need to change the locator.
If you want to avoid anchoring mechanism to do this and all is encrypted then you will need to decrypt to be able to do any processing.
Another example would be ID context awareness which is difficult to achieve today as is and even more so if we start using anon identifiers that change all the time ...

You are right address obfuscation can be achieved by many ways.
However, if you want to have an anonymous ID and yet have someone to discover you and initiate communication with you then there has to be some relationship between on what you can be looked up and the actual id you use.

On the other hand there are other possible functionalities tied the identity that we do not have today such as access control or even policies.

Absolutely.
The Identity Services in the framework are in separate modules from mapping resolution services.
As per the requirements document, for interoperability the identity service module is not mandatory.

Hope this clarifies.

Padma

Tom

>> On Sat, Jun 10, 2017 at 1:31 AM, Michael Menth <[email-masked]<mailto:[email-masked]>> wrote:
>>> Dear Padma, all,
>>>
>>> phone: (+49)-7071/29-70505<tel:%28%2B49%29-7071%2F29-70505>
>>> fax: (+49)-7071/29-5220<tel:%28%2B49%29-7071%2F29-5220>
>>> mailto:[email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> phone: (+49)-7071/29-70505<tel:%28%2B49%29-7071%2F29-70505>
> fax: (+49)-7071/29-5220<tel:%28%2B49%29-7071%2F29-5220>
> mailto:[email-masked]<mailto:[email-masked]>

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 12 Jun 2017 19:27:55 +0000

Hi Michael, I agree with your summary, which I think is very crisp.  

Hi Tom, obfuscation is one aspect, but I do think there is a little more than that because you don't want to just obfuscate, you also want aspects like metadata and policy to still work.  In other words, the overall picture is more differentiated - while you want to obfuscate identifiers to the outside, but you don't necessarily want your identity to be obfuscated.  With pure obfuscation of identifiers, you would lose all that.   

--- Alex

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Sunday, June 11, 2017 10:00 AM
To: Michael Menth <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]
Subject: Re: [Ideas] BOF @IETF 99 Preparation - problem statement

On Sun, Jun 11, 2017 at 2:19 AM, Michael Menth <[email-masked]> wrote:
> 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.
>

Michael,

Address obfuscation only works to the extent that there aren't other means to track nodes. For instance, even if we were to use different addresses for each packet of a TCP connection, the connection is trivial to track but just correlating port numbers, sequence and ack numbers sent in the clear. The only way to ensure privacy is encrypt everything possible.

In ILA deployment, the intent is that protocol is not visible to public networks. For instance, in a carrier network ILA would only be used in the core (like GTP is only in the core today). The carrier network already knows location anyway, so we don't address obfuscation there. For packets going to the UE (over radio for instance) we do need address obfuscation there like IPwave is doing, but again that can be independent of id/loc.

Tom

> 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.
>
>>> IDEAS brainstormings, documents, and email discussions. This may be 
>>> a base for a problem statement. Please add missing aspects!
>>>
>>> identifiers (Idfs), and locators may be used for future 
>>> communication using existing protocols. Missing features are identified and added.
>>>
>>> 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,
>>
>>> Both Idys and preferentially Idfs may be used for communication. 
>>> They identify the communication partner but not her location on the Internet.
>>> 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.
>>>
>>> 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
>>>
>>> --

---

From: Tom Herbert <[email-masked]>
Date: Mon, 12 Jun 2017 13:39:57 -0700

On Mon, Jun 12, 2017 at 12:19 PM, Uma Chunduri <[email-masked]> wrote:
>> split, or in this case it's the identifier being obfuscated. This is being
>> implemented in IPwave for instance to mitigate the tracking problem. The
>> need for obfuscation is independent of the ID/loc.
>
>>Address obfuscation only works to the extent that there aren't other means
>> to track nodes. For instance, even if we were to use different addresses for
>> each packet of a TCP connection, the connection is trivial to track but just
>> correlating port numbers,
>
> Encryption for obfuscation of identifiers is a too much of a stretch.
> Encryption has its own place and I see it is orthogonal to Identifier
> obfuscation. While in an unencrypted and  obfuscated identifiers, one can
> see some aspects of TCP connection, what cannot be done by the eavesdropper
> is identifying 2 independent  communications related to a particular entity.
> I see this is truly  network layer anonymous communication, if we have the
> ability to change communication identifiers at will (while maintaining the
> same identifier for entire session for mobility reasons).
>
> To achieve this a manageable entity called ‘Identity’ for an entity at a
> central place is needed,  where mapping and other identity related services
> can be provided  as hinted in GRIDS-REQs document.
>
Uma,

I understand the intent, but I am still dubious 'Identity' is actually
required and should be in the core architecture for IDEAS. This is not
a concept in any of the identifier locator protocols. Also, a host can
obfuscate addresses today just by choosing a different address from
the block they are assigned for each communication. In id/loc the same
affect could accomplished by the host getting however many identifiers
it needs to use.

>
>
>
>
>>In ILA deployment, the intent is that protocol is not visible to public
>> networks. For instance, in a carrier network ILA would only be used in the
>> core (like GTP is only in the core today). The carrier network already knows
>> location anyway, so we don't address obfuscation there. For packets going to
>> the UE (over radio for
>
> Obfuscation at radio layer is not in our scope (it’s 3GPP stuff) and they
> defined ‘some provisions’ as you stated above. But we are talking about
> obfuscation generically though various ID/LOC protocols in the internet and
> beyond managed transport network in 3GPP.
>
>
>
>>Anyway, if this is really needed, I suggest that it is defined to be an
>> obfuscation layer separate from id/loc. And it should be optional and usable
>> outside of id/loc as well.
>
>
>
> I see obfuscation provided through Identity and this is indeed separate
> layer (above Identifier-location mapping)  at the mapping system, where
> Identity to Identifiers can be mapped with certain policies associated to
> Identity.
>
That's a poor rationalization for creating a new complex protocol.

Tom

> On the other hand there are other possible functionalities tied the identity
> that we do not have today such as access control or even policies.
>
>
>

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 12 Jun 2017 21:05:57 +0000

Tom,

In-line [Uma2]:

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Monday, June 12, 2017 1:40 PM
To: Uma Chunduri <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]; Michael Menth <[email-masked]>
Subject: Re: [Ideas] BOF @IETF 99 Preparation - problem statement

On Mon, Jun 12, 2017 at 12:19 PM, Uma Chunduri <[email-masked]> wrote:
>>trivial to track but just  correlating port numbers,
>
> obfuscation. While in an unencrypted and  obfuscated identifiers, one 
> can see some aspects of TCP connection, what cannot be done by the 
> eavesdropper is identifying 2 independent  communications related to a particular entity.
> I see this is truly  network layer anonymous communication, if we have 
> the ability to change communication identifiers at will (while 
> maintaining the same identifier for entire session for mobility reasons).
>
> To achieve this a manageable entity called ‘Identity’ for an entity at 
> a central place is needed,  where mapping and other identity related 
> services can be provided  as hinted in GRIDS-REQs document.
>
Uma,

I understand the intent, 

[Uma2]:  Progress..

but I am still dubious 'Identity' is actually required and should be in the core architecture for IDEAS. 

[Uma2]:  Fair question. We would come forth with a 'small' document to address this  question (as discussed in earlier call too) and give the needed attention it deserves.

This is not a concept in any of the identifier locator protocols. 
Also, a host can obfuscate addresses today just by choosing a different address from the block they are assigned for each communication. 
In id/loc the same affect could accomplished by the host getting however many identifiers it needs to use.

[Uma2]:  Well, one can certainly do that. This would give subset of benefits (even from this aspect too) with  more manageability complexity to uniquely identify a communication entity (without any bearing or ability for any policy). 
                   But we don't need 'Identity' just for anonymization of communications and some of the  benefits are illustrated by Michael well here earlier https://www.ietf.org/mail-archive/web/ideas/current/msg00204.html 
                   Also if any new protocol/concept has only relevance at IETF and effort is worth  if it has any relevance for operators obviously (that was my intent in my earlier comment about new revenues..).

--
Uma C.

---

From: "Liubingyang (Bryan)" <[email-masked]>
Date: Tue, 13 Jun 2017 01:15:09 +0000

Hi Uma, 

I followed this thread. Most of the discussion focused on what the identity is used for. But can anybody explain what the identity is? 
By following the thread, it seems that 
1) identifier is temporary for an entity while identity is permanent; 
2) an entity can have multiple identifiers but only a unique identity;
3) identifier is used in data communication while identify is only used in control and management. 
Is my understanding correct and complete? 
Only having known what it is can people better understand how it is used. We all understand the difference between Loc and identifier, while Loc is topology dependent, identifier is topology independent. So we have little trouble understanding ID/Loc use cases. 

Bingyang (Bryan) 

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Uma Chunduri
Sent: Tuesday, June 13, 2017 5:06 AM
To: Tom Herbert <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]; Michael Menth <[email-masked]>
Subject: Re: [Ideas] BOF @IETF 99 Preparation - problem statement

Tom,

In-line [Uma2]:

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]]
Sent: Monday, June 12, 2017 1:40 PM
To: Uma Chunduri <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]; Michael Menth <[email-masked]>
Subject: Re: [Ideas] BOF @IETF 99 Preparation - problem statement

Uma,

I understand the intent, 

[Uma2]:  Progress..

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 13 Jun 2017 05:16:44 +0000

Hi Bingyang,

Very good summary. 
See my replies below [Uma]:

--
Uma C.

-----Original Message-----
From: Liubingyang (Bryan) 
Sent: Monday, June 12, 2017 6:15 PM
To: Uma Chunduri <[email-masked]>; Tom Herbert <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]; Michael Menth <[email-masked]>
Subject: RE: [Ideas] BOF @IETF 99 Preparation - problem statement

Hi Uma, 

I followed this thread. Most of the discussion focused on what the identity is used for. 
But can anybody explain what the identity is? 

[Uma]: One way to see - Identity 'uniquely' identifies a communication entity (any device with mobility for example, vehicular, IOT etc..) and an abstracted qualifier further dissociated from the identifier in ID/LOC protocols. 

[Uma]: Your understanding is correct  of course. 'Control and management' can be further expanded ...

Only having known what it is can people better understand how it is used. We all understand the difference between Loc and identifier, while Loc is topology dependent, identifier is topology independent. 

[Uma]: Identity too is topology independent like identifier and as its been discussed its abstracted from Identifier.

So we have little trouble understanding ID/Loc use cases. 

[Uma]: Michael  M. and some of us had a quick discussion and the identity usefulness  are in the area of security, policy/metadata specific use cases and anonymization (would be elaborated soon as specified below).

Bingyang (Bryan)

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Uma Chunduri
Sent: Tuesday, June 13, 2017 5:06 AM
To: Tom Herbert <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]; Michael Menth <[email-masked]>
Subject: Re: [Ideas] BOF @IETF 99 Preparation - problem statement

Tom,

In-line [Uma2]:

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]]
Sent: Monday, June 12, 2017 1:40 PM
To: Uma Chunduri <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]; Michael Menth <[email-masked]>
Subject: Re: [Ideas] BOF @IETF 99 Preparation - problem statement

Uma,

I understand the intent, 

[Uma2]:  Progress..

--
Uma C.

---

From: "Liubingyang (Bryan)" <[email-masked]>
Date: Tue, 13 Jun 2017 06:10:29 +0000

Very clear, thank you Uma. 

Thanks
Bingyang (Bryan)

-----Original Message-----
From: Uma Chunduri 
Sent: Tuesday, June 13, 2017 1:17 PM
To: Liubingyang (Bryan) <[email-masked]>; Tom Herbert <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]; Michael Menth <[email-masked]>
Subject: RE: [Ideas] BOF @IETF 99 Preparation - problem statement

Hi Bingyang,

Very good summary. 

--
Uma C.

-----Original Message-----
From: Liubingyang (Bryan)
Sent: Monday, June 12, 2017 6:15 PM
To: Uma Chunduri <[email-masked]>; Tom Herbert <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]; Michael Menth <[email-masked]>
Subject: RE: [Ideas] BOF @IETF 99 Preparation - problem statement

Hi Uma, 

Bingyang (Bryan)

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Uma Chunduri
Sent: Tuesday, June 13, 2017 5:06 AM
To: Tom Herbert <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]; Michael Menth <[email-masked]>
Subject: Re: [Ideas] BOF @IETF 99 Preparation - problem statement

Tom,

In-line [Uma2]:

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]]
Sent: Monday, June 12, 2017 1:40 PM
To: Uma Chunduri <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]; Michael Menth <[email-masked]>
Subject: Re: [Ideas] BOF @IETF 99 Preparation - problem statement

Uma,

I understand the intent, 

[Uma2]:  Progress..

--
Uma C.