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

[Padma Pillay-Esnault <[e-mail]>]

Hi Bingyang


On Thu, Jun 1, 2017 at 6:16 PM, Liubingyang (Bryan) <[e-mail]>
wrote:

> 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:[e-mail]]
> *Sent:* Thursday, June 01, 2017 11:32 PM
> *To:* Liubingyang (Bryan) <[e-mail]>
> *Cc:* Uma Chunduri <[e-mail]>; [e-mail]
>
> *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) <
> [e-mail]> wrote:
>
> 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.
>
>
>
>
>
> 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:[e-mail]] *On Behalf Of *Padma
> Pillay-Esnault
> *Sent:* Thursday, June 01, 2017 3:46 AM
> *To:* Uma Chunduri <[e-mail]>
> *Cc:* [e-mail]; Padma Pillay-Esnault <[e-mail]>
>
>
> *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 <[e-mail]>
> 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:[e-mail]] *On Behalf Of *Padma
> Pillay-Esnault
> *Sent:* Wednesday, May 31, 2017 10:51 AM
> *To:* [e-mail]
> *Cc:* Padma Pillay-Esnault <[e-mail]>
> *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
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Ideas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ideas
>
>