Subject: Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

From: "Liubingyang (Bryan)" <[email-masked]>
Date: Thu, 1 Jun 2017 08:33:46 +0000

Hi Padma,

Thanks for the well edited draft. I have a problem with the following sentence:
>> The Identity Enabled Networks (IDEAS) working group is chartered to develop a framework that provides services that can be used to address those requirements and that can be used with any identity-based protocol.

Does it mean that the IDEAS framework can be used by ALL EXISTING ID-based protocols, as well as ALL FUTURE ID-base protocols? If anybody designs a new ID protocol in IETF in the future, the protocol should follow the framework? Maybe IDEAS should have a more conservative goal than that.

Bingyang (Bryan)

From: Ideas [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Thursday, June 01, 2017 3:46 AM
To: Uma Chunduri <[email-masked]>
Cc: [email-masked]; Padma Pillay-Esnault <[email-masked]>
Subject: Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

Hi Uma

Thanks for your review!

Agree with your comments - will update

Thanks
Padma

On Wed, May 31, 2017 at 11:38 AM, Uma Chunduri <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for more refined version, which does reflect lot of discussion in the mailing-list on the charter.
Have few comments in-line below [Uma]:

--
Uma C.

From: Ideas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Padma Pillay-Esnault
Sent: Wednesday, May 31, 2017 10:51 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

Hello IDEAS

Thank you for the feedback and comments on the first Charter Proposal.
This version aims to capture your suggestions and comments.
Please note that the document went through editorial changes for consistency, clarity and balance.

I have also posted a version of it on GITHUB
https://github.com/IETF-IDEAS/Charter-Proposal/blob/master/IDEAS%20Charter%20Proposal

Your comments and feedback welcome.

Thanks
Padma

Proposed Charter

Identity-enabled solutions and applications are increasingly being considered to support mobility solutions and multi-homing across heterogeneous access networks. Likewise, Internet of Things (IOT), Machine-to-Machine (M2M) and 5G services, as well as context aware applications all can take advantage of discovery, stricter privacy and security functions.

Identifier-locator separation protocols are examples of technology that require infrastructure that allows nodes to discover the network topological location(s) of its peer(s) for packet delivery.  However, additional infrastructure is needed to address new requirements that go well beyond the traditional discovery service and mapping of identifier-to-location for packet delivery.

Examples of such requirements are:
-   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, the identifier-location pairs can be looked up without restriction and flows can be pinned by anybody to specific end systems.
[Uma]: The above depicts the gap in current identifier-location protocols rather than requirement. May be you might want to add  something similar to– “Privacy aspect is needed for looking up public identifiers and also for anonymizing the communication without being pinned by man-in-the-middle”.
-   Security: An identifier may reveal information to which the end-users may not want to be associated with. Therefore, users and network elements may wish to have a certain degree of control over this information to define who can read, write and delete it. The endpoint communications should be able to change their identifier while retaining their identity and associated policies. This indirection should help discourage unsolicited traffic or conceal their sensitive information to eavesdroppers.
-  Interoperability across id-locator infrastructures:
[Uma]: id-locator ==> identifier-locator (as ’id’ can be used for both Identity and Identifier at this point)
In IoT, often technology specific solutions drive different naming and addressing scheme leading to deploying disjoint systems. However, several IoT and 5G scenarios require that identifier-locator infrastructures are able to interoperate and exchange information when deployed over different administrative domains.
 -   Low Latency: The infrastructures must strive to minimize the latency for mission critical applications as well as quality user experience

The Identity Enabled Networks (IDEAS) working group is chartered to develop a framework that provides services that can be used to address those requirements and that can be used with any identity-based protocol.
[Uma]: identity-based protocol ==> Identifier-based protocol??
The framework includes the identifier-locator infrastructure and a common control plane for identifier related services and identifier–location separation protocols. A common control plane is required to facilitate the dynamic discovery of the various naming/addressing schemes and the communication between these heterogeneous environments
Such communication may also imply some negotiation capabilities, e.g., when several Mapping Systems are managed by different entities.

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

Features and properties:
- Registration and lifecycle management of identities associated identifiers.
- Definition of policies related to identities (e.g. access control to discovery)
- Anonymization support (e.g. identifier anonymity to eavesdroppers)
- Authenticated identity (access to framework, update of information for identifiers)
- Definition and enforcement of policies (e.g. ability to look up an identifier-locator pair, permit forwarding traffic, …)
- Identifier/locator mapping and resolution (e.g. discovery, pub/sub, multihoming..)
- Metadata support (e.g. entity or endpoint attributes and properties).
- Endpoint grouping support (e.g. negotiation to join, leave and communicate)
- Robustness of the system against DDoS attacks (e.g. policies for access, rate limiting)

The scope of system should be flexible and allow for different scopes such as local(private) or global(public). The scope of the mappings and their relevance within the scope will be taken into consideration for leaking of information. The negotiation of leaking of information from the private to global systems will be covered with the aim of minimal disruption and minimizing latency.

The working group will balance the requirements for performance of the framework to provide secured, trustworthy, and robust communication services with the minimized storage of data and privacy considerations.
The method for updating, caching and dissemination or leaking of information will be covered to ensure that state consistency and efficiency.
[Uma]: “The method for ..” ==> “A new Protocol or an existing Protocol extensions for …”
The working group will cover the management aspects of IDEAS architectural components and the services that they provide. The working group will identify gaps and make recommendations on changes needed for interface interactions between the framework and identifier-enabled protocols

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:
Overall 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
Dec 2017 Adopt WG draft for the Identity Services framework
May 2018 WGLC for the Identity Services framework
Aug 2018 Send Identity Services framework draft to the IESG

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 1 Jun 2017 08:30:03 -0700

Hi Bingyang

On Thu, Jun 1, 2017 at 1:33 AM, Liubingyang (Bryan) <[email-masked]>
wrote:

> >> The Identity Enabled Networks (IDEAS) working group is chartered to
> develop a framework that provides services that can be used to address
> those requirements and that can be used with *any* identity-based protocol
> .
>
>
>
> Does it mean that the IDEAS framework can be used by ALL EXISTING ID-based
> protocols, as well as ALL FUTURE ID-base protocols? If anybody designs a
> new ID protocol in IETF in the future, the protocol should follow the
> framework? Maybe IDEAS should have a more conservative goal than that.
>
>
>
> Bingyang (Bryan)
>
>
>
> *From:* Ideas [mailto:[email-masked]] *On Behalf Of *Padma
> Pillay-Esnault
> *Sent:* Thursday, June 01, 2017 3:46 AM
> *To:* Uma Chunduri <[email-masked]>
> *Cc:* [email-masked]; Padma Pillay-Esnault <[email-masked]>
>
> *Subject:* Re: [Ideas] Prep for BOF in July - Your input Needed on a
> Charter Proposal
>
>
>
> Hi Uma
>
>
>
> Thanks for your review!
>
>
>
> On Wed, May 31, 2017 at 11:38 AM, Uma Chunduri <[email-masked]>
> wrote:
>
> *From:* Ideas [mailto:[email-masked]] *On Behalf Of *Padma
> Pillay-Esnault
> *Sent:* Wednesday, May 31, 2017 10:51 AM
> *To:* [email-masked]
> *Cc:* Padma Pillay-Esnault <[email-masked]>
> *Subject:* Re: [Ideas] Prep for BOF in July - Your input Needed on a
> Charter Proposal
>
>
>
> Hello IDEAS
>
>
>
> Identity-enabled solutions and applications are increasingly being
> considered to support mobility solutions and multi-homing across
> heterogeneous access networks. Likewise, Internet of Things (IOT),
> Machine-to-Machine (M2M) and 5G services, as well as context aware
> applications all can take advantage of discovery, stricter privacy and
> security functions.
>
>
>
> Identifier-locator separation protocols are examples of technology that
> require infrastructure that allows nodes to discover the network
> topological location(s) of its peer(s) for packet delivery.  However,
> additional infrastructure is needed to address new requirements that go
> well beyond the traditional discovery service and mapping of
> identifier-to-location for packet delivery.
>
>
>
> -   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, the identifier-location pairs can be looked up without restriction
> and flows can be pinned by anybody to specific end systems.
>
> [Uma]: The above depicts the gap in current identifier-location protocols
> rather than requirement. May be you might want to add  something similar
> to– “Privacy aspect is needed for looking up public identifiers and also
> for anonymizing the communication without being pinned by
> man-in-the-middle”.
>
> -   Security: An identifier may reveal information to which the end-users
> may not want to be associated with. Therefore, users and network elements
> may wish to have a certain degree of control over this information to
> define who can read, write and delete it. The endpoint communications
> should be able to change their identifier while retaining their identity
> and associated policies. This indirection should help discourage
> unsolicited traffic or conceal their sensitive information to
> eavesdroppers.
>
> [Uma]: id-locator è identifier-locator (as ’id’ can be used for both
> Identity and Identifier at this point)
>
> In IoT, often technology specific solutions drive different naming and
> addressing scheme leading to deploying disjoint systems. However, several
> IoT and 5G scenarios require that identifier-locator infrastructures are
> able to interoperate and exchange information when deployed over different
> administrative domains.
>
>  -   Low Latency: The infrastructures must strive to minimize the latency
> for mission critical applications as well as quality user experience
>
>
>
> The Identity Enabled Networks (IDEAS) working group is chartered to
> develop a framework that provides services that can be used to address
> those requirements and that can be used with any identity-based protocol.
>
> [Uma]: identity-based protocol è Identifier-based protocol??
>
> The framework includes the identifier-locator infrastructure and a common
> control plane for identifier related services and identifier–location
> separation protocols. A common control plane is required to facilitate the
> dynamic discovery of the various naming/addressing schemes and the
> communication between these heterogeneous environments
>
> Such communication may also imply some negotiation capabilities, e.g.,
> when several Mapping Systems are managed by different entities.
>
>
>
> - Definition and enforcement of policies (e.g. ability to look up an
> identifier-locator pair, permit forwarding traffic, …)
>
> The scope of system should be flexible and allow for different scopes such
> as local(private) or global(public). The scope of the mappings and their
> relevance within the scope will be taken into consideration for leaking of
> information. The negotiation of leaking of information from the private to
> global systems will be covered with the aim of minimal disruption and
> minimizing latency.
>
>
>
> The working group will balance the requirements for performance of the
> framework to provide secured, trustworthy, and robust communication
> services with the minimized storage of data and privacy considerations.
>
> The method for updating, caching and dissemination or leaking of
> information will be covered to ensure that state consistency and efficiency.
>
> [Uma]: “The method for ..” è “A new Protocol or an existing
> Protocol extensions for …”
>
> The working group will cover the management aspects of IDEAS architectural
> components and the services that they provide. The working group will
> identify gaps and make recommendations on changes needed for interface
> interactions between the framework and identifier-enabled protocols
>
>
>
> 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:
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 1 Jun 2017 08:32:23 -0700

Hi Bingyang

> framework? Maybe IDEAS should have a more conservative goal than that.

How about change "with any" to "by"?
I think this should clarify that protocols could use this framework should
they wish to do so.

Thanks
Padma

---

From: "Liubingyang (Bryan)" <[email-masked]>
Date: Fri, 2 Jun 2017 01:16:52 +0000

Yes, I also think the protocols should use the framework as their will.
Another question is whether future ID protocols must be compatible with the framework, but I think we can defer answering the question to the framework RFC.

Bingyang

From: Padma Pillay-Esnault [mailto:[email-masked]]
Sent: Thursday, June 01, 2017 11:32 PM
To: Liubingyang (Bryan) <[email-masked]>
Cc: Uma Chunduri <[email-masked]>; [email-masked]
Subject: Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

Hi Bingyang

On Thu, Jun 1, 2017 at 1:33 AM, Liubingyang (Bryan) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Padma,

How about change "with any" to "by"?
I think this should clarify that protocols could use this framework should they wish to do so.

Thanks
Padma

Bingyang (Bryan)

From: Ideas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Padma Pillay-Esnault
Sent: Thursday, June 01, 2017 3:46 AM
To: Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Padma Pillay-Esnault <[email-masked]<mailto:[email-masked]>>

Hi Uma

Thanks for your review!

Thanks
Padma

--
Uma C.

Hello IDEAS

Thanks
Padma

Proposed Charter

Features and properties:

WG deliverables include:

Milestones

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 2 Jun 2017 09:42:33 -0700

Hi Bingyang

> Yes, I also think the protocols should use the framework as their will.

Absolutely.

> Another question is whether future ID protocols must be compatible with
> the framework, but I think we can defer answering the question to the
> framework RFC.
>
>
>
IMHO it is premature at this point to discuss this.

Padma

> Bingyang
>
>
>
> *From:* Padma Pillay-Esnault [mailto:[email-masked]]
> *Sent:* Thursday, June 01, 2017 11:32 PM
> *To:* Liubingyang (Bryan) <[email-masked]>
> *Cc:* Uma Chunduri <[email-masked]>; [email-masked]
>
> On Thu, Jun 1, 2017 at 1:33 AM, Liubingyang (Bryan) <
> [email-masked]> wrote:
>
> Hi Padma,
>
>
>
> _______________________________________________
> Ideas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ideas
>
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 2 Jun 2017 09:58:19 -0700

> Yes, I also think the protocols should use the framework as their will.
It sounds like a nice to have but I don't think it can be a requirement.
That would be the equivalent of saying that future versions of IP should be
compatible with RIP.

> Another question is whether future ID protocols must be compatible with
the
> framework, but I think we can defer answering the question to the
framework
> RFC.

I think we should make sure its compatible with all know ID and
virtualization protocols if possible. Probably enough there to get some
confidence IDEAS is future proof.

Tom

> On Thu, Jun 1, 2017 at 1:33 AM, Liubingyang (Bryan) <
[email-masked]>
>>> develop a framework that provides services that can be used to address
those
>>> requirements and that can be used with any identity-based protocol.
>
>
>
new
> ID protocol in IETF in the future, the protocol should follow the
framework?
> Maybe IDEAS should have a more conservative goal than that.
>
>
>
>
>
> Thanks for more refined version, which does reflect lot of discussion in
the
> mailing-list on the charter.
>
> To: [email-masked]
> Cc: Padma Pillay-Esnault <[email-masked]>
> require infrastructure that allows nodes to discover the network
topological
> location(s) of its peer(s) for packet delivery. However, additional
> infrastructure is needed to address new requirements that go well beyond
the
> traditional discovery service and mapping of identifier-to-location for
> packet delivery.
>
>
>
> - 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,
the
> identifier-location pairs can be looked up without restriction and flows
can
> be pinned by anybody to specific end systems.
>
to–
> “Privacy aspect is needed for looking up public identifiers and also for
> anonymizing the communication without being pinned by man-in-the-middle”.
>
define
> who can read, write and delete it. The endpoint communications should be
> able to change their identifier while retaining their identity and
> associated policies. This indirection should help discourage unsolicited
> traffic or conceal their sensitive information to eavesdroppers.
>
develop
> a framework that provides services that can be used to address those
> requirements and that can be used with any identity-based protocol.
>
when
> several Mapping Systems are managed by different entities.
>
>
>
services
> with the minimized storage of data and privacy considerations.
>
information
> will be covered to ensure that state consistency and efficiency.
>
> [Uma]: “The method for ..” è “A new Protocol or an existing Protocol
> extensions for …”
>