Subject: [Ideas] Your Input requested: Charter Proposal New Version

From: Padma Pillay-Esnault <[email-masked]>
Date: Sun, 6 Aug 2017 22:20:02 -0700

Dear IDEAS,

Thanks to everyone who sent their comments and feedback both on the list
and off the list.

This new version should address comments from:
-  Michael Menth. Michael, please let us know if this revision address some
of your comments on clarity.
- Alex Clemm. Alex , please chime on the revision regarding your addition.
- Tom Herbert. Tom, Some of your suggestions are incorporated in this
version.
-Tom and Alex, this version include specific working that the framework is
modular. The set of areas to be covered has been reordered to put the basic
identifier protocol common infrastructure first and then the new identity
concept and functionalities.
- Georgios Karagiannis, Uma Chundhuri. Georgios, Uma, there is still an
ongoing discussion about the framework. This version is flexible enough to
accommodate the work to be done on defining the framework.
- Uma Chundhuri. Uma, the pub/sub reference should cover the inter-grids
aspect if needed.

Please find the new version below:

IDEAS: “IDentity EnAbled networkS”

Proposed Charter

Network solutions based on the concept of Identifier-Locator separation are
increasingly considered to support mobility and multi-homing across
heterogeneous access networks. Identifier-locator separation protocols
require infrastructure that allows nodes to discover the network
topological location(s) of its peer(s) for packet delivery. A common
infrastructure and protocol could be used by identifier/locator protocols
as well as network virtualization. However, additional infrastructure and
new protocol extensions are needed to address new requirements that go well
beyond the traditional discovery service and mapping of
identifier-to-location for packet delivery.

At the same time, end users require greater privacy for their networking
information and protection from outside threats, while operators demand
greater operational efficiency. Identity-enabled networks aim to enable
networking applications and services that provide a high degree of privacy
and control of end points over their networking data, coupled with greater
inherent security than provided by today’s networks.

To this end, the working group shall:

- define a framework for the development of an identifier/locator mapping
system that provides a common solution for all identifier/locator mapping
protocols and network virtualization.

- in addition, introduce the concept of identity-identifier split and new
mechanisms that let endpoints dynamically change identifiers. These new
functionalities may, for example, facilitate anonymity through obscurity
while preventing security issues that might result from abuse, ensuring
that information about actual endpoints and their location is revealed only
on a need-to-know basis.

Some examples of the problem space are:

- Common infrastructure and primitives: The lack of a common infrastructure
is a barrier for the application of common and consistent basic networking
policies. Likewise, mapping services and infrastructure that apply to
identity-identifier as well as identifier-locator mappings reduces
operational and deployment complexity.

- Access control: Unrestricted look up on an identifier may reveal
information such as the locator to eavesdroppers. Today, there is no way to
prevent the look up of an identifier with some user defined policy or finer
grain rules.

- Privacy:  The use of long-lived and public identifiers may be desirable
for looking up a peer, however it causes privacy issues as well. Indeed,
when identifier-location pairs can be looked up without restriction, flows
can be pinned by anybody to specific end systems.  The endpoint
communications should be able to change their identifier while retaining
their identity and associated policies. The use of temporary identifiers
and access control on lookups should help discourage undesired traffic and
conceal sensitive network information of end devices to eavesdroppers.

The Identity Enabled Networks (IDEAS) working group is chartered to develop
a common framework that can be used by identifier-based protocols and
provides services to address their requirements. We refer to the common
framework providing the set of services as Generic Identity Services
(GRIDS).

The working group will identify gaps and make recommendations on changes
needed for interactions between the framework and identifier-enabled
protocols.

Specifically, the IDEAS WG is chartered to work on these areas for the
modular framework:

- Definition of primitives for interworking with identifier-location split
protocols

- Identifier/locator mapping and resolution (e.g. discovery, pub/sub,
multihoming, ...)

- Registration and lifecycle management of identities and their associated
identifiers.

- Identity authentication and authorization (e.g. access to framework,
update of information for identifiers..)

- Definition and enforcement of basic networking policies (e.g. ability to
look up an identifier-locator pair, permit forwarding traffic for
particular endpoints on a per-identity basis…)

- Identity and Identifier Metadata (fixed or slow changing)

- Management aspects and Data Models where appropriate.

The IDEAS WG will collaborate with other Working Groups to ensure
interoperability with LISP, HIP, ILA and other relevant work. Furthermore,
it will try to reuse technologies already developed when appropriate.

WG deliverables include the definition:

Generic Identity Services Framework

WG sustaining/informational documents may include:

These documents may not necessarily be published, but may be maintained in
a draft form or on a collaborative Working Group wiki to support the
efforts of the Working Group and help new comers:

- Problem statement

- Use cases

- Requirements

- Applications of the architecture for use cases

Milestones

March 2018 Adopt WG draft for the Generic Identity Services framework

August 2018 WGLC for the Generic Identity Services framework

December 2018 Send Generic Identity Services framework draft to the IESG

---

From: Yingzhen Qu <[email-masked]>
Date: Mon, 7 Aug 2017 06:42:11 +0000

Padma,

About “- Identity and Identifier Metadata (fixed or slow changing)”, I remember one of the comments we got before was to further limit the scope of metadata to just a couple of categories, for example type.

Thanks,
Yingzhen

From: Ideas [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Sunday, August 06, 2017 10:20 PM
To: [email-masked]
Cc: Padma Pillay-Esnault <[email-masked]>
Subject: [Ideas] Your Input requested: Charter Proposal New Version

Dear IDEAS,

Thanks to everyone who sent their comments and feedback both on the list and off the list.

This new version should address comments from:
-  Michael Menth. Michael, please let us know if this revision address some of your comments on clarity.
- Alex Clemm. Alex , please chime on the revision regarding your addition.
- Tom Herbert. Tom, Some of your suggestions are incorporated in this version.
-Tom and Alex, this version include specific working that the framework is modular. The set of areas to be covered has been reordered to put the basic identifier protocol common infrastructure first and then the new identity concept and functionalities.
- Georgios Karagiannis, Uma Chundhuri. Georgios, Uma, there is still an ongoing discussion about the framework. This version is flexible enough to accommodate the work to be done on defining the framework.
- Uma Chundhuri. Uma, the pub/sub reference should cover the inter-grids aspect if needed.

Proposed Charter

Network solutions based on the concept of Identifier-Locator separation are increasingly considered to support mobility and multi-homing across heterogeneous access networks. Identifier-locator separation protocols require infrastructure that allows nodes to discover the network topological location(s) of its peer(s) for packet delivery. A common infrastructure and protocol could be used by identifier/locator protocols as well as network virtualization. However, additional infrastructure and new protocol extensions are needed to address new requirements that go well beyond the traditional discovery service and mapping of identifier-to-location for packet delivery.

At the same time, end users require greater privacy for their networking information and protection from outside threats, while operators demand greater operational efficiency. Identity-enabled networks aim to enable networking applications and services that provide a high degree of privacy and control of end points over their networking data, coupled with greater inherent security than provided by today’s networks.

To this end, the working group shall:
- define a framework for the development of an identifier/locator mapping system that provides a common solution for all identifier/locator mapping protocols and network virtualization.

- in addition, introduce the concept of identity-identifier split and new mechanisms that let endpoints dynamically change identifiers. These new functionalities may, for example, facilitate anonymity through obscurity while preventing security issues that might result from abuse, ensuring that information about actual endpoints and their location is revealed only on a need-to-know basis.

Some examples of the problem space are:
- Common infrastructure and primitives: The lack of a common infrastructure is a barrier for the application of common and consistent basic networking policies. Likewise, mapping services and infrastructure that apply to identity-identifier as well as identifier-locator mappings reduces operational and deployment complexity.

- Access control: Unrestricted look up on an identifier may reveal information such as the locator to eavesdroppers. Today, there is no way to prevent the look up of an identifier with some user defined policy or finer grain rules.

- Privacy:  The use of long-lived and public identifiers may be desirable for looking up a peer, however it causes privacy issues as well. Indeed, when identifier-location pairs can be looked up without restriction, flows can be pinned by anybody to specific end systems.  The endpoint communications should be able to change their identifier while retaining their identity and associated policies. The use of temporary identifiers and access control on lookups should help discourage undesired traffic and conceal sensitive network information of end devices to eavesdroppers.

The Identity Enabled Networks (IDEAS) working group is chartered to develop a common framework that can be used by identifier-based protocols and provides services to address their requirements. We refer to the common framework providing the set of services as Generic Identity Services (GRIDS).

The working group will identify gaps and make recommendations on changes needed for interactions between the framework and identifier-enabled protocols.

Specifically, the IDEAS WG is chartered to work on these areas for the modular framework:

- Definition of primitives for interworking with identifier-location split protocols
- Identifier/locator mapping and resolution (e.g. discovery, pub/sub, multihoming, ...)
- Registration and lifecycle management of identities and their associated identifiers.
- Identity authentication and authorization (e.g. access to framework, update of information for identifiers..)
- Definition and enforcement of basic networking policies (e.g. ability to look up an identifier-locator pair, permit forwarding traffic for particular endpoints on a per-identity basis…)
- Identity and Identifier Metadata (fixed or slow changing)
- Management aspects and Data Models where appropriate.

The IDEAS WG will collaborate with other Working Groups to ensure interoperability with LISP, HIP, ILA and other relevant work. Furthermore, it will try to reuse technologies already developed when appropriate.

WG sustaining/informational documents may include:
These documents may not necessarily be published, but may be maintained in a draft form or on a collaborative Working Group wiki to support the efforts of the Working Group and help new comers:
- Problem statement
- Use cases
- Requirements
- Applications of the architecture for use cases

Milestones

---

From: Michael Menth <[email-masked]>
Date: Mon, 7 Aug 2017 10:19:48 +0200

Hi Padma,

clarity has improved.

Thanks!

Michael

Am 07.08.2017 um 07:20 schrieb Padma Pillay-Esnault:
> -Tom and Alex, this version include specific working that the framework
> is modular. The set of areas to be covered has been reordered to put the
> basic identifier protocol common infrastructure first and then the new
> identity concept and functionalities.
> ongoing discussion about the framework. This version is flexible enough
> to accommodate the work to be done on defining the framework. 
> Network solutions based on the concept of Identifier-Locator separation
> are increasingly considered to support mobility and multi-homing across
> infrastructure and protocol could be used by identifier/locator
> protocols as well as network virtualization. However, additional
> infrastructure and new protocol extensions are needed to address new
> requirements that go well beyond the traditional discovery service and
> mapping of identifier-to-location for packet delivery. 
> 
>  
> 
> networking applications and services that provide a high degree of
> privacy and control of end points over their networking data, coupled
> with greater inherent security than provided by today’s networks.  
> 
>  
> 
> - define a framework for the development of an identifier/locator
> mapping system that provides a common solution for all
> identifier/locator mapping protocols and network virtualization.
> 
>  
> 
> - in addition, introduce the concept of identity-identifier split and
> new mechanisms that let endpoints dynamically change identifiers. These
> new functionalities may, for example, facilitate anonymity through
> obscurity while preventing security issues that might result from abuse,
> ensuring that information about actual endpoints and their location is
> revealed only on a need-to-know basis.
> 
>  
> 
> - Common infrastructure and primitives: The lack of a common
> infrastructure is a barrier for the application of common and consistent
> basic networking policies. Likewise, mapping services and infrastructure
> that apply to identity-identifier as well as identifier-locator mappings
> reduces operational and deployment complexity.
> 
>  
> 
> information such as the locator to eavesdroppers. Today, there is no way
> to prevent the look up of an identifier with some user defined policy or
> finer grain rules.
> 
>  
> 
> - Privacy:  The use of long-lived and public identifiers may be
> desirable for looking up a peer, however it causes privacy issues as
> well. Indeed, when identifier-location pairs can be looked up without
> restriction, flows can be pinned by anybody to specific end systems. 
> The endpoint communications should be able to change their identifier
> while retaining their identity and associated policies. The use of
> temporary identifiers and access control on lookups should help
> discourage undesired traffic and conceal sensitive network information
> of end devices to eavesdroppers.
> 
>  
> 
> The Identity Enabled Networks (IDEAS) working group is chartered to
> develop a common framework that can be used by identifier-based
> protocols and provides services to address their requirements. We refer
> to the common framework providing the set of services as Generic
> Identity Services (GRIDS).
> 
>  
> 
> - Definition and enforcement of basic networking policies (e.g. ability
> to look up an identifier-locator pair, permit forwarding traffic for
> interoperability with LISP, HIP, ILA and other relevant work.
> Furthermore, it will try to reuse technologies already developed when
> appropriate.
> 
>                  
> 
> These documents may not necessarily be published, but may be maintained
> in a draft form or on a collaborative Working Group wiki to support the
> _______________________________________________
> Ideas mailing list
> [email-masked]
> 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: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: Tom Herbert <[email-masked]>
Date: Mon, 7 Aug 2017 08:23:00 -0700

On Sun, Aug 6, 2017 at 10:20 PM, Padma Pillay-Esnault
<[email-masked]> wrote:
> require infrastructure that allows nodes to discover the network topological
> location(s) of its peer(s) for packet delivery. A common infrastructure and
> protocol could be used by identifier/locator protocols as well as network
> virtualization. However, additional infrastructure and new protocol
> extensions are needed to address new requirements that go well beyond the
> traditional discovery service and mapping of identifier-to-location for
> packet delivery.
>
>
>
> while preventing security issues that might result from abuse, ensuring that
> information about actual endpoints and their location is revealed only on a
> need-to-know basis.
>
Padma,

I don't think this goes far enough in terms of protections for users
against the potential abuse of something that might be able to
individually and persistently identify them on the Internet. First,
it's not clear what network layer identity means in this context. I
hope it refers to an ad hoc collection of identifiers as opposed to
the identity of individual users or devices. In any case maybe a
definition of identity might be in order here. Secondly, I think it
should be stated up front that identity cannot in any way be used to
identify individual users, it cannot be used to create a global
database of Internet users, in no way can it be used by networks or
governments to track or block individuals, nor can it ever be required
for communications. That implies network layer identities cannot
contain PII (personally identifiable information) and cannot be
permanently assigned to users or devices (in the same spirit that
Ethernet addresses were removed from IIDs because of privacy
concerns).

Thanks,
Tom

> their identity and associated policies. The use of temporary identifiers and
> access control on lookups should help discourage undesired traffic and
> look up an identifier-locator pair, permit forwarding traffic for particular
> endpoints on a per-identity basis…)
>
> These documents may not necessarily be published, but may be maintained in a
> draft form or on a collaborative Working Group wiki to support the efforts
> of the Working Group and help new comers:
>
> - Problem statement
>
> - Use cases
>
> - Requirements
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 7 Aug 2017 15:57:18 +0000

Hi,

On 7/8/2017, 17:23, "Ideas on behalf of Tom Herbert" <[email-masked] on behalf of [email-masked]> wrote:

    Padma,

    Thanks,
    Tom

When it comes to these concerns I’d strongly recommend to have a look at how identity attributes were exchanged and trust established within the ABFAB framework (https://tools.ietf.org/wg/abfab/)

Be goode,

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Mon, 7 Aug 2017 10:55:02 -0700

Hi Yingzhen 

Thanks for pointing this out. Noted for next revision 

Padma

Sent from my iPhone

> On Aug 7, 2017, at 08:57, Diego R. Lopez <[email-masked]> wrote:
> 
> Hi,
> 
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Mon, 7 Aug 2017 11:11:44 -0700

Hi Tom

Thanks for your comments.

See below <Padma>

Sent from my iPhone

> On Aug 7, 2017, at 08:23, Tom Herbert <[email-masked]> wrote:
> 
> definition of identity might be in order here.

<Padma> Good point! This portion needs more clarity.

> Secondly, I think it
<Padma> 
The network identity does not equate to an individual user. A crisp definition will greatly help clarify this.

I am not sure we can state some of the requirements as is. Anything of this sort must be worded very carefully.... 

Padma

---

From: Tom Herbert <[email-masked]>
Date: Mon, 7 Aug 2017 11:23:56 -0700

Padma,

I think this statement could be stronger and express that the common
mapping system and protocols are expected output from WG. How about
something like: "Define and develop a common mapping system, control
plane, and related protocol that provide a common solution for
identifier/locator protocols that map identifiers to locators, as well
as network virtualization protocols that map virtual to physical
addresses"

Tom

---

From: Tom Herbert <[email-masked]>
Date: Mon, 7 Aug 2017 11:23:56 -0700

Padma,

Tom

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Mon, 7 Aug 2017 13:24:32 -0700

Hi Diego

Thanks for the pointer.

Padma

Sent from my iPhone

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Mon, 7 Aug 2017 13:27:42 -0700

Hi Tom

> as network virtualization protocols that map virtual to physical
Fine with me.

Let's poll the list for consensus on this.

Thanks
Padma

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 7 Aug 2017 21:33:51 +0000

I am not sure we should restrict ourselves to mapping between identifiers and locators.

I would at a minimum want to include mappings between identifiers, and between identifiers and (for lack of a better term) groupings of identifiers.

If we take out the identity concept, we should also rename the WG.

--- Alex

From: Ideas [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Monday, August 07, 2017 1:28 PM
To: Tom Herbert <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version

Hi Tom

Padma,

Fine with me.

Thanks
Padma

Tom

---

From: Padmadevi Pillay Esnault <[email-masked]>
Date: Mon, 7 Aug 2017 21:51:43 +0000

Alex

My understanding is that Tom did NOT ask for removing of identity concept.
He asked to make the section on common infrastructure clearer with this sentence.

I agree with you that the mappings should not be restricted to 1->n

Thanks
Padma

From: Ideas [mailto:[email-masked]] On Behalf Of Alexander Clemm
Sent: Monday, August 07, 2017 2:34 PM
To: Padma Pillay-Esnault; Tom Herbert
Cc: [email-masked]
Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version

--- Alex

Hi Tom

Padma,

Fine with me.

Thanks
Padma

Tom

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 8 Aug 2017 17:42:29 +0000

OK.

If we want to have a more specific list of supported mappings, it may be useful to mention some of those other mappings as well – by means of example, mappings between identifiers.

Thanks
--- Alex

From: Padmadevi Pillay Esnault
Sent: Monday, August 07, 2017 2:52 PM
To: Alexander Clemm <[email-masked]>; Tom Herbert <[email-masked]>
Cc: [email-masked]; Padma Pillay-Esnault <[email-masked]>
Subject: RE: [Ideas] Your Input requested: Charter Proposal New Version

Alex

Thanks
Padma

Cc: [email-masked]<mailto:[email-masked]>

--- Alex

From: Ideas [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Monday, August 07, 2017 1:28 PM
To: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version

Hi Tom

Padma,

Fine with me.

Thanks
Padma

Tom

---

From: Padmadevi Pillay Esnault <[email-masked]>
Date: Tue, 8 Aug 2017 20:16:37 +0000

Sure

However, been wondering if it is best not to be so specific in the charter.
Thoughts?

Padma

From: Alexander Clemm
Sent: Tuesday, August 08, 2017 10:42 AM
To: Padmadevi Pillay Esnault; Tom Herbert
Cc: [email-masked]; Padma Pillay-Esnault
Subject: RE: [Ideas] Your Input requested: Charter Proposal New Version

OK.

Thanks
--- Alex

Alex

Thanks
Padma

--- Alex

Hi Tom

Padma,

Fine with me.

Thanks
Padma

Tom

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 8 Aug 2017 21:35:51 -0700

Hello All

Here is the latest version as of 08/08/17.

Please send your comments and feedback on the list.

Proposed Charter

- define and develop a common mapping system, control plane, and related
protocol that provide a common solution for identifier/locator protocols
that map identifiers to locators as well other new mapping combinations as
needed, as well as network virtualization protocols that map virtual to
physical addresses

- in addition, introduce the concept of identity-identifier split and new
mechanisms that let endpoints dynamically change identifiers. The common
mapping system will include identity to identifier mappings. These new
functionalities may, for example, facilitate anonymity through obscurity
while preventing security issues that might result from abuse, ensuring
that information about actual endpoints and their location is revealed only
on a need-to-know basis.

- Identity and Identifier Metadata (only fixed or slow changing, e.g. type)

WG deliverables include:

- Problem statement

- Use cases

- Requirements

Milestones

On Tue, Aug 8, 2017 at 1:16 PM, Padmadevi Pillay Esnault <[email-masked]>
wrote:

> *From:* Alexander Clemm
> *Sent:* Tuesday, August 08, 2017 10:42 AM
> *To:* Padmadevi Pillay Esnault; Tom Herbert
> *Cc:* [email-masked]; Padma Pillay-Esnault
>
> *Subject:* RE: [Ideas] Your Input requested: Charter Proposal New Version
>
>
>
> OK.
>
>
>
> If we want to have a more specific list of supported mappings, it may be
> useful to mention some of those other mappings as well – by means of
> example, mappings between identifiers.
>
>
>
> Thanks
>
> --- Alex
>
>
>
> *From:* Padmadevi Pillay Esnault
> *Sent:* Monday, August 07, 2017 2:52 PM
> *To:* Alexander Clemm <[email-masked]>; Tom Herbert <
> [email-masked]>
> *Cc:* [email-masked]; Padma Pillay-Esnault <[email-masked]>
> *Subject:* RE: [Ideas] Your Input requested: Charter Proposal New Version
>
>
>
> Alex
>
>
>
> *From:* Ideas [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Alexander Clemm
> *Sent:* Monday, August 07, 2017 2:34 PM
> *To:* Padma Pillay-Esnault; Tom Herbert
> *Cc:* [email-masked]
> *Subject:* Re: [Ideas] Your Input requested: Charter Proposal New Version
>
>
>
> I would at a minimum want to include mappings between identifiers, and
> between identifiers and (for lack of a better term) groupings of
> identifiers.
>
>
>
> *From:* Ideas [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Padma Pillay-Esnault
> *Sent:* Monday, August 07, 2017 1:28 PM
> *To:* Tom Herbert <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Ideas] Your Input requested: Charter Proposal New Version
>
>
>
> Hi Tom
>
>
>
>
>
> >

---

From: Sam Sun <[email-masked]>
Date: Wed, 9 Aug 2017 01:55:27 -0400

Padma,

The latest version looks good! Thanks for putting it all together.

A couple of questions need a bit clarification:

1) in the first item in "the IDEAS WG is chartered to work on...", what 
it means by "... interworking with identifier-location split protocols"?

2) In the deliverables, could we include some of chartered tasks here? 
For example,

    Requirements for identifier/locator mapping and resolution

    Requirements for identity authentication and authorization service 
(for GRIDS).

All the best,
Sam

On 8/9/17 12:35 AM, Padma Pillay-Esnault wrote:
> Network solutions based on the concept of Identifier-Locator 
> separation are increasingly considered to support mobility and 
> multi-homing across heterogeneous access networks. Identifier-locator 
> separation protocols require infrastructure that allows nodes to 
> discover the network topological location(s) of its peer(s) for packet 
> delivery. A common infrastructure and protocol could be used by 
> identifier/locator protocols as well as network virtualization. 
> However, additional infrastructure and new protocol extensions are 
> needed to address new requirements that go well beyond the traditional 
> discovery service and mapping of identifier-to-location for packet 
> delivery.
>
> At the same time, end users require greater privacy for their 
> networking information and protection from outside threats, while 
> operators demand greater operational efficiency. Identity-enabled 
> networks aim to enable networking applications and services that 
> provide a high degree of privacy and control of end points over their 
> networking data, coupled with greater inherent security than provided 
> by today’s networks.
>
> - define and develop a common mapping system, control plane, and 
> related protocol that provide a common solution for identifier/locator 
> protocols that map identifiers to locators as well other new mapping 
> combinations as needed, as well as network virtualization protocols 
> that map virtual to physical addresses
>
> new mechanisms that let endpoints dynamically change identifiers. The 
> common mapping system will include identity to identifier mappings. 
> These new functionalities may, for example, facilitate anonymity 
> through obscurity while preventing security issues that might result 
> from abuse, ensuring that information about actual endpoints and their 
> location is revealed only on a need-to-know basis.
>
> infrastructure is a barrier for the application of common and 
> consistent basic networking policies. Likewise, mapping services and 
> infrastructure that apply to identity-identifier as well as 
> identifier-locator mappings reduces operational and deployment complexity.
>
> information such as the locator to eavesdroppers. Today, there is no 
> way to prevent the look up of an identifier with some user defined 
> policy or finer grain rules.
>
> protocols and provides services to address their requirements. We 
> refer to the common framework providing the set of services as Generic 
> The working group will identify gaps and make recommendations on 
> changes needed for interactions between the framework and 
> identifier-enabled protocols.
>
> - Definition and enforcement of basic networking policies (e.g. 
> ability to look up an identifier-locator pair, permit forwarding 
> traffic for particular endpoints on a per-identity basis…)
>
> These documents may not necessarily be published, but may be 
> maintained in a draft form or on a collaborative Working Group wiki to 
> support the efforts of the Working Group and help new comers:
>
> - Problem statement
>
> - Use cases
>
> - Requirements
>
> On Tue, Aug 8, 2017 at 1:16 PM, Padmadevi Pillay Esnault 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Sure
>
>     *From:*Alexander Clemm
>     *Cc:* [email-masked] <mailto:[email-masked]>; Padma Pillay-Esnault
>
>
>     If we want to have a more specific list of supported mappings, it
>     may be useful to mention some of those other mappings as well – by
>     means of example, mappings between identifiers.
>
>     Thanks
>
>     --- Alex
>
>     *From:*Padmadevi Pillay Esnault
>     *To:* Alexander Clemm <[email-masked]
>     <mailto:[email-masked]>>; Tom Herbert
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Padma Pillay-Esnault
>     <[email-masked] <mailto:[email-masked]>>
>     *From:*Ideas [mailto:[email-masked]] *On Behalf Of
>     *Alexander Clemm
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     I would at a minimum want to include mappings between identifiers,
>     and between identifiers and (for lack of a better term) groupings
>     of identifiers.
>
>     *From:*Ideas [mailto:[email-masked]] *On Behalf Of *Padma
>     Pillay-Esnault
>     *To:* Tom Herbert <[email-masked] <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>

---

From: Padmadevi Pillay Esnault <[email-masked]>
Date: Wed, 9 Aug 2017 18:15:04 +0000

Hi Sam

Thanks for your feedback and review.

See below

From: Ideas [mailto:[email-masked]] On Behalf Of Sam Sun
Sent: Tuesday, August 08, 2017 10:55 PM
To: [email-masked]
Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version

Padma,

1) in the first item in "the IDEAS WG is chartered to work on...", what it means by "... interworking with identifier-location split protocols"?

[Padma Pillay Esnault] This work is to ensure that the infrastructure can interact with protocols such as LISP, HIP and ILA through the primitives it will define. How about we add some text here to make this more explicit?

2) In the deliverables, could we include some of chartered tasks here? For example,

   Requirements for identity authentication and authorization service (for GRIDS).
[Padma Pillay Esnault] Ok will add this

All the best,
Sam

Proposed Charter

To this end, the working group shall:
- define and develop a common mapping system, control plane, and related protocol that provide a common solution for identifier/locator protocols that map identifiers to locators as well other new mapping combinations as needed, as well as network virtualization protocols that map virtual to physical addresses

- in addition, introduce the concept of identity-identifier split and new mechanisms that let endpoints dynamically change identifiers. The common mapping system will include identity to identifier mappings. These new functionalities may, for example, facilitate anonymity through obscurity while preventing security issues that might result from abuse, ensuring that information about actual endpoints and their location is revealed only on a need-to-know basis.

WG deliverables include:

Milestones

On Tue, Aug 8, 2017 at 1:16 PM, Padmadevi Pillay Esnault <[email-masked]<mailto:[email-masked]>> wrote:
Sure

Padma

From: Alexander Clemm
Sent: Tuesday, August 08, 2017 10:42 AM
To: Padmadevi Pillay Esnault; Tom Herbert
Cc: [email-masked]<mailto:[email-masked]>; Padma Pillay-Esnault

OK.

Thanks
--- Alex

From: Padmadevi Pillay Esnault
Sent: Monday, August 07, 2017 2:52 PM
To: Alexander Clemm <[email-masked]<mailto:[email-masked]>>; Tom Herbert <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Padma Pillay-Esnault <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Ideas] Your Input requested: Charter Proposal New Version

Alex

Thanks
Padma

--- Alex

Hi Tom

Padma,

Fine with me.

Thanks
Padma

Tom

Ideas mailing list

[email-masked]<mailto:[email-masked]>

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 9 Aug 2017 21:49:29 +0000

This version sounds fine to me.

Thanks
--- Alex

From: Padma Pillay-Esnault [mailto:[email-masked]]
Sent: Tuesday, August 08, 2017 9:36 PM
To: Padmadevi Pillay Esnault <[email-masked]>
Cc: Alexander Clemm <[email-masked]>; Tom Herbert <[email-masked]>; [email-masked]
Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version

Hello All

Proposed Charter

WG deliverables include:

Milestones

Padma

From: Alexander Clemm

OK.

Thanks
--- Alex

Alex

Thanks
Padma

--- Alex

Hi Tom

Padma,

Fine with me.

Thanks
Padma

Tom

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 9 Aug 2017 22:25:13 +0000

Some comments in-line [Uma]:

BR,

--
Uma C.

Cc: Tom Herbert <[email-masked]>; [email-masked]; Alexander Clemm <[email-masked]>

Hello All

Proposed Charter

To this end, the working group shall:
- define and develop a common mapping system, control plane, and related protocol that provide a common solution for identifier/locator protocols that map identifiers to locators as well other new mapping combinations as needed, as well as network virtualization protocols that map virtual to physical addresses
[Uma]: Looks fine and the term” control plane”   can be dropped from the above sentence.  #1

[Uma]: This list doesn’t capture #1 in the earlier description and IMO that should be listed too

WG deliverables include:

WG sustaining/informational documents may include:
These documents may not necessarily be published, but may be maintained in a draft form or on a collaborative Working Group wiki to support the efforts of the Working Group and help new comers:
- Problem statement
- Use cases
- Requirements
- Applications of the architecture for use cases
[Uma]: Are you saying an Architecture document (framework as listed in the Milestones below??) else I see “Applications of the architecture for use cases” is bit confusing.

Milestones

Padma

From: Alexander Clemm

OK.

Thanks
--- Alex

Alex

Thanks
Padma

--- Alex

Hi Tom

Padma,

Fine with me.

Thanks
Padma

Tom

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 9 Aug 2017 22:30:12 +0000

In-line

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Diego R. Lopez
Sent: Monday, August 07, 2017 8:57 AM
To: Tom Herbert <[email-masked]>; Padma Pillay-Esnault <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version

Hi,

    Padma,

    Thanks,
    Tom

[Uma]: Though  this is not about SSOs or application stuff, thanks for the pointer. 
                I always believed EAP has a role to play for IDy auth procedures and lot of concerns brought out here (especially related to Identity-privacy) are effectively taken care with existing mechanisms. 

Be goode,

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 9 Aug 2017 22:58:08 +0000

Hi Uma,

        Padma,

        Thanks,
        Tom

ABFAB was not about SSO, but about using user identities to allow their access to network services while protecting user privacy. And among those services you could consider any kind of application or connectivity service…

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:        +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 9 Aug 2017 23:26:55 +0000

Hi Diego,

In-line [Uma1]:

-----Original Message-----
From: Diego R. Lopez [mailto:[email-masked]] 
Sent: Wednesday, August 09, 2017 3:58 PM
To: Uma Chunduri <[email-masked]>; Tom Herbert <[email-masked]>; Padma Pillay-Esnault <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version

Hi Uma,

        Padma,

        Thanks,
        Tom

[Uma1]: Thanks for the correction.  Yes, what is needed for IDEAS is to access AUTH to GRIDS by entity and also simple policy  at Identity (referring Identity through Identifier in the packet regardless of which Identifier of the entity is used). 
                  Sure, we ought to re-use any existing and well defined mechanisms for this purpose.

---

From: Lan Gao <[email-masked]>
Date: Thu, 10 Aug 2017 09:31:22 +0800

I agree with Sam. Specific chartered tasks or a statement referencing the
chartered tasks should be added to the Deliverables as the current document
only implies that they will be met by the Generic Identity Services
Framework.

Regards,

Lan Gao

On Thu, Aug 10, 2017 at 7:26 AM, Uma Chunduri <[email-masked]>
wrote:

> To: Uma Chunduri <[email-masked]>; Tom Herbert <
> [email-masked]>; Padma Pillay-Esnault <[email-masked]>
> Cc: [email-masked]
>     When it comes to these concerns I’d strongly recommend to have a look
> at how identity attributes were exchanged and trust established within the
> ABFAB framework (https://tools.ietf.org/wg/abfab/)
>
>                     I always believed EAP has a role to play for IDy auth
> procedures and lot of concerns brought out here (especially related to
> Identity-privacy) are effectively taken care with existing mechanisms.
>
> ABFAB was not about SSO, but about using user identities to allow their
> access to network services while protecting user privacy. And among those
> services you could consider any kind of application or connectivity service…
>
> [Uma1]: Thanks for the correction.  Yes, what is needed for IDEAS is to
> access AUTH to GRIDS by entity and also simple policy  at Identity
> (referring Identity through Identifier in the packet regardless of which
> Identifier of the entity is used).

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 10 Aug 2017 10:18:03 -0700

Dear Lan Gao

Thanks for your review. Will take this input.

Thanks
Padma

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 10 Aug 2017 16:24:24 -0400

About time I weighed in on this.

Basically I am comfortable with the charter content.  It has to be a 
amalgam of different approaches so no one can be completely on board 
with it.  Really that proof will be in the output; we have to start with 
some goals tacked to the wall.

If I would change anything it is in the 2nd para, and that is general 
info which can be wordsmithed til the cows come home (as they say).  But 
to put my fork in it:

"At the same time"  ?? what time?  The 1st para really does not define a 
time.  Just drop it and start with "End users ..."

"and operators demand"  Don't make them competitative requirements. They 
just are.

"Identity-enabled networks aim to enable'  They do?  Just drop the "aim 
to" and I think it is a stronger, yet valid, statement.

For me, the rest can stand to get us off the starting block.

Bob

On 08/07/2017 01:20 AM, Padma Pillay-Esnault wrote:
> -Tom and Alex, this version include specific working that the 
> framework is modular. The set of areas to be covered has been 
> reordered to put the basic identifier protocol common infrastructure 
> first and then the new identity concept and functionalities.
> - Georgios Karagiannis, Uma Chundhuri. Georgios, Uma, there is still 
> an ongoing discussion about the framework. This version is flexible 
> enough to accommodate the work to be done on defining the framework.
> new mechanisms that let endpoints dynamically change identifiers.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 10 Aug 2017 21:11:38 -0700

> Please send your comments and feedback on the list.

Enclosed are my brief comments. Sorry for the delay but I’m on vacation.

> At the same time, end users require greater privacy for their networking information and protection from outside threats, while operators demand greater operational efficiency. Identity-enabled net…

I would add “… control of end points over their identity address, location address, and data coupled with …”.

> - define and develop a common mapping system, control plane, and related protocol that provide a common solution for identifier/locator protocols that map identifiers to locators as well other new…

I don’t know why there the use of the word “common” appears throughout. The charter really shouldn't intend to interoperate existing locator/ID split protocols so I would say “define and deploy a mapping system”.

And the existing locator/ID split protocols have their respective control-planes optimized for the tradeoffs they set out to design. Having something that works for all of them, to attempt interoperation, not only doesn’t make sense, but will make them run inefficiently and probably make them not useful.

> - Definition of primitives for interworking with identifier-location split protocols

This isn’t useful to anyone. Having a HIP host talk to a LISP host solves nothing. It just creates complexity. And what if the LISP host has an IPv4 EID? 

This will cause a misinterpretation of the usefulness of locator/id split. I believe this should not be in the charter.

> - Management aspects and Data Models where appropriate.

The above items are all useful and need to be defined and more importantly deployed, so we can experiment with the solutions that meet the requirements of this working group.

> The IDEAS WG will collaborate with other Working Groups to ensure interoperability with LISP, HIP, ILA and other relevant work. Furthermore, it will try to reuse technologies already developed when…

I think the IDEAS WG should work with these working groups to make sure their control planes are extended to meet the requirements from IDEAS. But not to make them interoperate.

Dino

---

From: Di Ma <[email-masked]>
Date: Mon, 14 Aug 2017 11:14:34 +0800

Dear Padma,

I think prospects described in IDEAS charter are promising since people fancy anonymity in connecting to different network environments, via identity/identifier separation. 

Yet by doing so, we would introduce new risk into the Internet.  Threat model is therefore indispensable to provide a basis for the design of future IDEAS security mechanisms. 

I suggest a threat model document as one of WG deliverables.

Di  Ma
RPSTIR
https://bgpsecurity.net

> 在 2017年8月7日，13:20，Padma Pillay-Esnault <[email-masked]> 写道：
> 
> Dear IDEAS,
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Mon, 14 Aug 2017 11:51:48 -0700

Dear Bob

On Thu, Aug 10, 2017 at 1:24 PM, Robert Moskowitz <[email-masked]>
wrote:

> amalgam of different approaches so no one can be completely on board with
> it.  Really that proof will be in the output; we have to start with some
> goals tacked to the wall.
>
> Agree

> If I would change anything it is in the 2nd para, and that is general info
> which can be wordsmithed til the cows come home (as they say).  But to put
> my fork in it:
>
> I will let Alex respond to these comments as he proposed the above
sentence.

> to" and I think it is a stronger, yet valid, statement.
Ok will change this

> For me, the rest can stand to get us off the starting block.

Good.

Thanks for your review and input.

Padma

> develop a common framework that can be used by identifier-based protocols
> and provides services to address their requirements. We refer to the common
> Ideas mailing [email-masked]://www.ietf.org/mailman/listinfo/ideas
>
>
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Mon, 14 Aug 2017 11:56:52 -0700

> address, and data coupled with …”.

OK I will massage this paragraph and also taking into account the comment
from Bob regarding the first sentence.

> I don’t know why there the use of the word “common” appears throughout.
> The charter really shouldn't intend to interoperate existing locator/ID
> split protocols so I would say “define and deploy a mapping system”.

You are right. We are not trying to interoperate existing protocols but the
common is from the infrastructure perspective. Noted your comment will go
over this.

And the existing locator/ID split protocols have their respective
> control-planes optimized for the tradeoffs they set out to design. Having
> something that works for all of them, to attempt interoperation, not only
> doesn’t make sense, but will make them run inefficiently and probably make
> them not useful.
>
>
See my above comment.

> This isn’t useful to anyone. Having a HIP host talk to a LISP host solves
> nothing. It just creates complexity. And what if the LISP host has an IPv4
> EID?
>
> ok will explain this better, the interworking is protocol and infra not
between protocols
Will need to make this clearer int he text

> This will cause a misinterpretation of the usefulness of locator/id split.
> I believe this should not be in the charter.
>
> The above items are all useful and need to be defined and more importantly
> deployed, so we can experiment with the solutions that meet the
> requirements of this working group.
>
> I think the IDEAS WG should work with these working groups to make sure
> their control planes are extended to meet the requirements from IDEAS. But
> not to make them interoperate.
>
>
Sure we are in agreement will reword for clarity

Thanks for your review and feedback

Padma

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 14 Aug 2017 11:59:30 -0700

Thanks Padma. As well as taking the lead on all this.

Dino

> On Aug 14, 2017, at 11:56 AM, Padma Pillay-Esnault <[email-masked]> wrote:
> 
> 
> 
> OK I will massage this paragraph and also taking into account the comment from Bob regarding the first sentence.
>  
> 
> You are right. We are not trying to interoperate existing protocols but the common is from the infrastructure perspective. Noted your comment will go over this. 
>  
> ok will explain this better, the interworking is protocol and infra not between protocols

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Mon, 14 Aug 2017 12:07:45 -0700

Dear Di Ma,

Thank you for your review and feedback,

On Sun, Aug 13, 2017 at 8:14 PM, Di Ma <[email-masked]> wrote:

> Dear Padma,
>
> I think prospects described in IDEAS charter are promising since people
> fancy anonymity in connecting to different network environments, via
> identity/identifier separation.
>
> Yet by doing so, we would introduce new risk into the Internet.  Threat
> model is therefore indispensable to provide a basis for the design of
> future IDEAS security mechanisms.
>

<Padma> While I do not believe we are introducing new risks with the proper
caution but we should certainly be careful not to inadvertently do so.

IMHO, a threat model would be an interesting document for the wg.
I would like to poll the wg to see what people think of this suggestion.

Thanks
Padma

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 14 Aug 2017 21:25:19 +0000

Re: “At the same time”:  I thought it is clear that this refers not to the timeline of some specific events, but if this may cause confusion, just rephrase it to something “also” (e.g. “End users also require greater privacy…”)

Cheers
--- Alex

From: Padma Pillay-Esnault [mailto:[email-masked]]
Sent: Monday, August 14, 2017 11:52 AM
To: Robert Moskowitz <[email-masked]>; Alexander Clemm <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version

Dear Bob

On Thu, Aug 10, 2017 at 1:24 PM, Robert Moskowitz <[email-masked]<mailto:[email-masked]>> wrote:
About time I weighed in on this.

Basically I am comfortable with the charter content.  It has to be a amalgam of different approaches so no one can be completely on board with it.  Really that proof will be in the output; we have to start with some goals tacked to the wall.
Agree

If I would change anything it is in the 2nd para, and that is general info which can be wordsmithed til the cows come home (as they say).  But to put my fork in it:

"At the same time"  ?? what time?  The 1st para really does not define a time.  Just drop it and start with "End users ..."

"and operators demand"  Don't make them competitative requirements.  They just are.
I will let Alex respond to these comments as he proposed the above sentence.

"Identity-enabled networks aim to enable'  They do?  Just drop the "aim to" and I think it is a stronger, yet valid, statement.
Ok will change this

Good.

Padma

Bob

Proposed Charter

Milestones

Ideas mailing list

---

From: Albert Cabellos <[email-masked]>
Date: Fri, 18 Aug 2017 14:59:52 +0900

Hi all

I agree -in general- with the charter in its current form, below you can
find some comments inline:

> identifier-to-location for packet delivery.

I suggest also mentioning overlay networking for virtualization as a
use-case.

> protocols and network virtualization.

specify instead of define? (same across the charter, specify instead of
develop, etc)
'for *existing* identifier/locator mapping' --> 'all' might be too generic
and not realizable.

> that information about actual endpoints and their location is revealed only

why 'in addition'? The itemization already implicitly states: 'in
addition'.

> Some examples of the problem space are:

why 'some examples'? This looks very vague. From my understanding below you
have a solid and complete definition of the problem state. I suggest
rewriting to "The problem space is:"