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

[Shreyasee Mukherjee <[e-mail]>]

Dear Padma,

This version reads well. Professor Ray and we at WINLAB had a few minor
comments. We agree with Alex's previous comment on including some notion
that the mapping system should have the flexibility of mapping not just
identifiers to locators but also allow mapping identifiers to other
identifiers. This is a powerful tool and we have looked into how such
recursive mapping of identifiers allows newer network services to be
enabled such as context-aware multicast. This can also be extended to
support privacy concerns wherein an identifier could map into a whitelist
or blacklist of identifiers for lookup queries. In that regard, our
comments to the charter proposal are provided inline.

Thank you,
Shreyasee

>
> ---------- Forwarded message ----------
> From: Alexander Clemm <[e-mail]>
> To: Padma Pillay-Esnault <[e-mail]>, Padmadevi Pillay Esnault
> <[e-mail]>
> Cc: Tom Herbert <[e-mail]>, "[e-mail]" <[e-mail]>
> Bcc:
> Date: Wed, 9 Aug 2017 21:49:29 +0000
> Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version
>
> This version sounds fine to me.
>
>
>
> Thanks
>
> --- Alex
>
>
>
> *From:* Padma Pillay-Esnault [mailto:[e-mail]]
> *Sent:* Tuesday, August 08, 2017 9:36 PM
> *To:* Padmadevi Pillay Esnault <[e-mail]>
> *Cc:* Alexander Clemm <[e-mail]>; Tom Herbert <
> [e-mail]>; [e-mail]
> *Subject:* Re: [Ideas] Your Input requested: Charter Proposal New Version
>
>
>
> Hello All
>
>
>
> Here is the latest version as of 08/08/17.
>
>
>
> Please send your comments and feedback on the list.
>
>
>
>
>
> 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. Identifier-locator
> protocols are also useful for additional services involving dynamic
> association of a name to a set of network addresses - these include dynamic
> multicast, cloud service anycast and context-aware IoT queries.
>


> A common infrastructure and protocol could be used by identifier/locator
> protocols as well as for 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 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.
>

-  In addition to resolving an identifier to a set of network addresses,
the mapping system should be able to support a recursive mode in which an
identifier <IDf> can be mapped to multiple identifiers <IDf1>, <IDf2>,
…<IDfn>.  This is useful for incorporating hierarchies associated with the
ontology tree of the information being accessed, as well as for scaling of
multicast services involving mapping of a single identifier to large
numbers of network addresses.


>
>
> 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. The API should be
> sufficiently general to enable various modes of resolution including
> identifier to network address <IDf> à <NA>, identifier to multiple
> network addresses <IDf> à <NA1>, <NA2>, …<NAn>, and identifier to one or
> more identifiers <IDf> à <IDf1>, <IDf2>, …<IDfn>.
>
>
>
> - 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 (only fixed or slow changing, e.g. type)
>
> - 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:
>
> Generic Identity Services Framework – should this be defined further in
> terms of API, syntax/semantics, mapping service query/response/update
> protocol, etc.?
>
>
>
> 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
>
>
>
> On Tue, Aug 8, 2017 at 1:16 PM, Padmadevi Pillay Esnault <[e-mail]>
> wrote:
>
> 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:* [e-mail]; 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 <[e-mail]>; Tom Herbert <
> [e-mail]>
> *Cc:* [e-mail]; Padma Pillay-Esnault <[e-mail]>
> *Subject:* RE: [Ideas] Your Input requested: Charter Proposal New Version
>
>
>
> 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:[e-mail] <[e-mail]>] *On
> Behalf Of *Alexander Clemm
> *Sent:* Monday, August 07, 2017 2:34 PM
> *To:* Padma Pillay-Esnault; Tom Herbert
> *Cc:* [e-mail]
> *Subject:* Re: [Ideas] Your Input requested: Charter Proposal New Version
>
>
>
> 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:[e-mail] <[e-mail]>] *On
> Behalf Of *Padma Pillay-Esnault
> *Sent:* Monday, August 07, 2017 1:28 PM
> *To:* Tom Herbert <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [Ideas] Your Input requested: Charter Proposal New Version
>
>
>
> Hi Tom
>
>
>
>
>
> >
> > 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.
> >
>
> 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"
>
>
>
> Fine with me.
>
>
>
> Let's poll the list for consensus on this.
>
>
>
> Thanks
>
> Padma
>
>
>
> Tom
>
>
>
>
>
> _______________________________________________
> Ideas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ideas
>
>