1. Generic Identity Services Framework

On Aug 22, 2017, at 9:39 AM, Padma Pillay-Esnault <padma.ietf@gmail.com> wrote:

Dear All

I support the changes in text and focusing on the framework as a first delivery and then rechartering as proposed by Alvaro. 

Regarding the milestones, I propose the following modification to reflect Alvaro's comment. 

Milestones

 

Jan 2018 Adopt WG draft for the Generic Identity Services framework

 

July 2018 WGLC for the Generic Identity Services framework

 

September 2018 Send Generic Identity Services framework draft to the IESG

November 2018 Recharter 

Thanks

Padma

On Tue, Aug 22, 2017 at 1:53 AM, sam.sun.xun@gmail.com <sam.sun.xun@gmail.com> wrote:

Ditto.


Sam

-------- Original Message --------
Subject: Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round

From: christian.jacquenet@orange.com
To: Georgios Karagiannis ,"Alvaro Retana (aretana)" ,Padma Pillay-Esnault ,ideas@ietf.org
CC:

Dear all,

 

I too support the suggestion and additional text made by Alvaro, let alone the revised milestones.

 

Cheers,

 

Christian.

 

De : Ideas [mailto:ideas-bounces@ietf.org] De la part de Georgios Karagiannis
Envoyé : mardi 22 août 2017 10:22
À : Alvaro Retana (aretana); Padma Pillay-Esnault; ideas@ietf.org
Objet : Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round

 

Hi Alvaro,

 

Thanks for the clarification.

Your proposal on (1) having the Framework draft ready to be sent to IESG before November 2018 and (2) re-chartering of IDEAS WG after that, it makes very much  sense to me;

 

Best regards,

Georgios

 

 

From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Alvaro Retana (aretana)
Sent: Tuesday, August 22, 2017 4:09 AM
To: Padma Pillay-Esnault; ideas@ietf.org
Subject: Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round

 

Hi!

 

Thanks to everyone who has contributed to building a Charter. 

 

As I mentioned after the BoF [1]: “I am willing to sponsor a focused WG proposal to define a framework that reflects consensus on what is expected from the mapping system, the questions around identity persistence, privacy, etc.” – I think the text is still very wide as it attempts to go beyond defining a framework.  For example, it says that the WG will “Specify and deploy a mapping system, and related protocols…”

 

I haven’t seen discussion on the list that indicates to me that there is a common understanding on what is needed for us to take the additional step of defining solutions.  To be clear, I hope that we get to the point where a solution is defined, but the BoF failed to provide a cohesive direction, which is why I want to insist on focusing on a framework first – the faster we get done with that, the faster we can move to more work.  From a process point of view, and to facilitate discussion and approval, I would like to see the charter focus on that first step – re-chartering to include more work is an easy task.

 

Based on the current text, I’m including suggested text below.

 

The only other comment is related to the milestones: there is a long time between WGLC and sending the document to the IESG.  Ideally the work would be completed within a year – IOW, I would like the goal to be to re-charter by IETF 103 (in November of 2018).

 

 

Thanks!

 

Alvaro.

 

[1] https://mailarchive.ietf.org/arch/msg/ideas/VIBmuWm2lTpoA767qJR2elii_vA

 

 

 

 

IDEAS: “IDentity EnAbled networkS”

 

 

Network solutions based on the concept of Identifier-Locator separation are increasingly considered to support mobility, overlay networking for virtualization 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. 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.  

 

The IDEAS WG is chartered to produce a framework document that defines the expected behavior of a mapping system across the multiple existing use cases.  The framework will aim at a homogeneous behavior across use cases, and it will call out specific trade-offs that may be considered in the development of solutions.  We refer to the framework providing the set of services as Generic Identity Services (GRIDS).

 

Some of the areas that should be considered when developing the framework include:

 

- A flexible and extensible mapping system

 

- Definition of primitives for identifier-location split protocols to interact with the framework

 

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

 

- 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…)

 

- The concept of identity-identifier split and dynamic identifier changes, including anonymity and privacy.

 

 

The IDEAS WG will closely collaborate with LISP and HIP WGs. The WG will also collaborate with other WG as needed.

 

 

WG deliverables include:

 

1.       Generic Identity Services Framework

 

(2) Other 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 for identifier/locator mapping and resolution

 

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

 

- Applications of the architecture for use cases

 

- Threat model document

 

 

 

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 8/20/17, 11:02 PM, "Ideas on behalf of Padma Pillay-Esnault" <ideas-bounces@ietf.org on behalf of padma.ietf@gmail.com> wrote:

 

Dear IDEAS,

 

Thanks to everyone who sent their comments and feedback both on the list and off the list. The version below has integrated all the comments, inputs as well as discussions on the alias for the last 2 weeks. For your reference, a log of comments can be found at the end of this email.

 

Please send your comments by Thursday 08/24/2017 latest for this final round for feedback.

 

 

IDEAS: “IDentity EnAbled networkS”

Version 8/20/2017 - Proposed Charter

                 

Network solutions based on the concept of Identifier-Locator separation are increasingly considered to support mobility, overlay networking for virtualization 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. 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.   

 

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

 

To this end, the working group shall:

- Specify and deploy a mapping system, and related protocol that provide a solution for existing 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

- 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.

 

The problem space is:

 

- Common infrastructure and primitives: The lack of a common infrastructure is a barrier for the application of 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 specify a framework that can be used by identifier-based protocols and provides services to address their requirements. We refer to the 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:

                 

- Specify a mapping system supporting the mapping combinations as needed

- Definition of primitives for identifier-location split protocols to interact with the framework

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

- 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 e.g. type)

- Management aspects and Data Models where appropriate.

 

The IDEAS WG will collaborate with LISP WG and HIP WG to extend their control planes if needed to meet the framework requirements.  The WG will also collaborate with other WG for any other relevant work. Furthermore, the WG will try to reuse technologies already developed when appropriate.

                 

WG deliverables include:

Generic Identity Services Framework

Other 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 for identifier/locator mapping and resolution

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

- Applications of the architecture for use cases

- Threat model document 

 

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

 

 

Modification Log and Comments

 

Comments on the 08/08/2017 Version 

Sam Sun:

1) In the first item in "the IDEAS WG is chartered to work on...", what it means by "... interworking with identifier-location split protocols"? CLOSED
2) In the deliverables, could we include some of chartered tasks here? For example,
- Requirements for identifier/locator mapping and resolution CLOSED

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

 

Alex Clemm: 

This version sounds fine to me.

 

Uma Chunduri: 

Looks fine and the term” control plane”   can be dropped from the above sentence.  #1  CLOSED

This list doesn’t capture #1 in the earlier description and IMO that should be listed too CLOSED

 

Lan Gao:

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. CLOSED

 

Bob Moskowitz: 

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. CLOSED

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

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

Dino Farinacci:

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

 

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”. CLOSED

 

> - 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? CLOSED

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. CLOSED

Shreyasee Mukherjee: 

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.   CLOSED

 

-  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. CLOSED

 

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>. REJECTED – Email discussion -Too specific but this is implied by the addition above.

 

Generic Identity Services Framework – should this be defined further in terms of API, syntax/semantics, mapping service query/response/update protocol, etc.? REJECTED per comments on alias

 

Di Ma:

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 CLOSED

 

D. Raychaudhuri: 

I reviewed the charter document and feel that it is a good start.  My main comments are:

(1) I agree with the concept of an identity-identifier split, which is necessary for an important set of applications requiring dynamic change of identifier. Realizing this will require something similar to a trusted “name certification service”  [cf. “MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet, ACM MC2R, July 2012] in addition to a dynamic name-to-locator mapping/resolution service [cf. ”DMap: A Shared Hosting Scheme for Dynamic Identifier to Locator Mappings in the Global Internet”, ICDCS 2012]

(2) A key requirement for the mapping service is the ability to support multiple types of resolution including identifier to identifier (i.e. recursive), identifier to group of identifiers, identifier to single locator, identifier to a list of locators, etc.  We have found the recursive identifier resolution capability to be very useful for scaling and new service creation.  CLOSED

(3) The final output of the WG at the end of the doc should be filled in a bit further in terms of specific APIs and query/response/update protocol definitions to be included in the spec. 

REJECTED by email discussion

Bob M.: You really don't want a starting charter this specific.  You can have wording about working on an API, but APIs have always been a sore item in the IETF.  Also this is why I2NSF talks about Interfaces and capablities, not APIs.  Leave the specitivity for the workgroup, not try and get the post-BOF to complete the work to start the workgroup.

(4) While I realize that the current charter’s scope is intentionally limited to defining general-purpose control plane support, the spec could be of greater value by defining or linking one or more specific identifier-based routing (data plane) protocols compatible with the IDEAS infrastructure. 

Bob M.:This comes out in the workgroup, and if necessary then you do a charter revision.  I need to talk to you separately about TAPS...

Albert Cabellos: 

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

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

 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. CLOSED

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

 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:" CLOSED

 

 

Comments on the 08/06/2017 Version 

 

Yingzhen Qu:

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. CLOSED

 

Michael Menth : 

Clarity has improved.

 

Tom Herbert/Diego Lopez:

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/)

CLOSED - The charter now mentions to collaborate with other group for relevant work.

 

 

Tom Herbert:

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" CLOSED with modifications from Albert, Dino, Uma

 

Alex Clemm: 

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.  CLOSED

 

 

 

Comments on the 08/02/201 Version 

 

-  Michael Menth: Michael, please let us know if this revision address some of your comments on clarity. CLOSED

- Alex Clemm. Alex , please chime on the revision regarding your addition. CLOSED

- Tom Herbert. Tom, Some of your suggestions are incorporated in this version. CLOSED

-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. CLOSED

- 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.CLOSED

 

 

 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas