< draft-padma-ideas-req-grids-00.txt   draft-padma-ideas-req-grids-01.txt >
Network Working Group P. Pillay-Esnault, Ed. Network Working Group P. Pillay-Esnault
Internet-Draft A. Clemm Internet-Draft A. Clemm
Intended status: Informational Huawei Intended status: Informational Huawei
Expires: September 14, 2017 D. Farinacci Expires: January 4, 2018 D. Farinacci
lispers.net lispers.net
D. Meyer D. Meyer
Brocade Brocade
March 13, 2017 July 3, 2017
Requirements for Generic Resilient Identity Services in Identity Enabled Requirements for Generic Identity Services in Identity Enabled Networks
Networks draft-padma-ideas-req-grids-01
draft-padma-ideas-req-grids-00
Abstract Abstract
This document describes requirements for the Generic Resilient This document describes requirements for the Generic Identity
Identity Services infrastructure for Identity-Enabled Networks. Services infrastructure for Identity-Enabled Networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Requirements for Generic Resilient Identity Services (GRIDS) 5 5. Requirements for Generic Identity Services (GRIDS) . . . . . 6
5.1. Mapping Services . . . . . . . . . . . . . . . . . . . . 5 5.1. Mapping Services . . . . . . . . . . . . . . . . . . . . 6
5.2. Identity Services and Identifiers . . . . . . . . . . . . 6 5.2. Identity Services and Identifiers . . . . . . . . . . . . 6
5.3. Subscription Services . . . . . . . . . . . . . . . . . . 7 5.3. Subscription Services . . . . . . . . . . . . . . . . . . 9
5.4. Distribution and Redundancy . . . . . . . . . . . . . . . 8 5.4. Metadata Support and Services . . . . . . . . . . . . . . 9
5.5. Scale and Performance . . . . . . . . . . . . . . . . . . 8 5.5. Distribution and Redundancy . . . . . . . . . . . . . . . 10
5.6. GRIDS Security . . . . . . . . . . . . . . . . . . . . . 10 5.6. Scale and Performance . . . . . . . . . . . . . . . . . . 11
5.7. Ability to support multiple instances . . . . . . . . . . 11 5.7. GRIDS Security . . . . . . . . . . . . . . . . . . . . . 13
5.8. GRIDS Extensions . . . . . . . . . . . . . . . . . . . . 11 5.8. Ability to support multiple instances . . . . . . . . . . 14
5.8.1. Grouping Support . . . . . . . . . . . . . . . . . . 12 5.9. GRIDS Extensions . . . . . . . . . . . . . . . . . . . . 14
5.8.2. Metadata Support . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document specifies requirements for Generic Resilient ID This document specifies requirements for Generic Identity Services
Services (GRIDS) that provide a cornerstone of Identity-Enabled (GRIDS) that provide a cornerstone of Identity-Enabled Networks.
Networks. GRIDS includes services to maintain mappings between GRIDS includes services to maintain mappings between Identifiers and
Identifiers and Locators and to resolve mappings by Identifier. In Locators and to resolve mappings by Identifier. In addition, GRIDS
addition, GRIDS includes services to manage the lifecycle of includes services to manage the lifecycle of Identifiers as used in
Identifiers as used in an Identity-Enabled Network, specifically an Identity-Enabled Network, specifically services to register
services to register Identifiers. Identifiers.
There are additional services that GRIDS can be extended with. There are additional services that GRIDS can be extended with.
Examples include services to maintain metadata about endpoints that Examples include services to maintain metadata about endpoints that
are referenced by Identifiers as well as support for Identity-based are referenced by Identifiers as well as support for Identity-based
network access control. However, in order to not overburden GRIDS network access control. Because those services enable a lot of
development, this document focuses on core requirements that will be value-added functionality, important requirements for those services
mandatory to support for GRIDS. Requirements for add-on features are specified here as well. In order to not overburden GRIDS
will be specified in future documents. development, this document focuses on core requirements.
The requirements are rooted in and derived from the problem statement The requirements are rooted in and derived from the problem statement
and use case documents for Identity Enabled Networks [IDEAS-PS] and use case documents [IDEAS-USE][IDEAS-IDENTITY] for
[IDEAS-PS][IDEAS-USE]. Identity Enabled Networks. A gap analysis of existing solutions can
be found in [IDEAS-GAP].
2. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Definition of Terms 3. Definition of Terms
This document makes use of terms which for the most part have been This document makes use of terms which for the most part have been
already defined in the problem statement draft of IDEAS [IDEAS-PS]. already defined in the problem statement draft of IDEAS [IDEAS-PS].
They are included here for reader convenience. In case of any They are included here for reader convenience. In case of any
discrepancies between the two drafts, the problem statement draft discrepancies between the two drafts, the problem statement draft
overrides. overrides.
E.164: An ITU-T recommendation that defines the international o Entity : An entity is a communication endpoint. It can be a
public telephone numbering plan.
Entity : An entity is a communication endpoint. It can be a
device, a node, or a (software) process, that needs to be device, a node, or a (software) process, that needs to be
identified. An entity may have one or multiple Identifiers identified. An entity may have one or multiple Identifiers
simultaneously. An entity is reached by the resolution of one or simultaneously. An entity is reached by the resolution of one or
more of its Identifiers to one or more Locators. more of its Identifiers to one or more Locators.
Entity Collection: A set of entities with its own Identifier, o Entity Collection: A set of entities with its own Identifier,
e.g., a multicast group, or an ad-hoc vehicular network that needs e.g., a multicast group, or an ad-hoc vehicular network that needs
to be uniquely identified (e.g., a train entity may represent a to be uniquely identified (e.g., a train entity may represent a
Closed User Group (CUG) and may contain all the passengers' Closed User Group (CUG) and may contain all the passengers'
devices that share the same fate for connectivity). devices that share the same fate for connectivity).
Generic Resilient Identity Services (GRIDS): GRIDS is a set of o Generic Identity Services (GRIDS): GRIDS is a set of services to
services to manage the lifecycle of IDs, to map and resolve manage the lifecycle of IDs, to map and resolve Identifiers and
Identifiers and Locators, and to associate metadata (META) with Locators, and to associate metadata (META) with entities and
entities and entity collections. It is a distributed system that entity collections. It is a distributed system that stores the
stores the ID, the associated LOC(s), and metadata (META) in the ID, the associated LOC(s), and metadata (META) in the form of
form of tuples (ID, LOC, and META). tuples (ID, LOC, and META).
GRIDS-IS (GRIDS Identity Services): The subset of GRIDS that is o GRIDS-IS (GRIDS Identity Services): The subset of GRIDS that is
responsible for managin the lifecycle of Identifiers and responsible for managin the lifecycle of Identifiers and
Identities. Identities.
GRIDS-MS (GRIDS Mapping Services): The subset of GRIDS that is o GRIDS-MS (GRIDS Mapping Services): The subset of GRIDS that is
responsible for mapping and resolving Identifiers and Locators. responsible for mapping and resolving Identifiers and Locators.
GRIDS-SS (GRIDS Subscription Services): The subset of GRIDS that o GRIDS-SS (GRIDS Subscription Services): The subset of GRIDS that
lets clients subscribe to information updates. lets clients subscribe to information updates.
Identifier (ID): denotes information to unambiguously identify an o Identifier (IDf): denotes information to unambiguously identify an
entity within a given scope. There is no constraint on the entity within a given scope. There is no constraint on the
format, obfuscation or routability of an ID. The ID may or may format, obfuscation or routability of an IDf. The IDf may or may
not be present in the packet whose format is defined by ID-based not be present in the packet whose format is defined by ID-based
protocols. protocols.
Identifier-based (ID-based): When an entity is only reachable o Identifier-based (ID-based): When an entity is only reachable
through one or more communication access then a protocol or a through one or more communication access then a protocol or a
solution is said to be ID-based if it uses an ID-LOC decoupling solution is said to be ID-based if it uses an ID-LOC decoupling
and a mapping system (MS) as base components of the architecture. and a mapping system (MS) as base components of the architecture.
Identity: the essence of "being" of a specific entity. An o Identity (IDy): the essence of "being" of a specific entity. An
Identity is not to be confused with an Identifier: while an Identity is not to be confused with an Identifier: while an
Identifier may be used to refer to an entity, an Identifier's Identifier may be used to refer to an entity, an Identifier's
lifecycle is not necessarily tied to the lifecycle of the Identity lifecycle is not necessarily tied to the lifecycle of the Identity
it is referencing. On the other hand, the Identity's lifecycle is it is referencing. On the other hand, the Identity's lifecycle is
inherently tied to the lifecycle of the entity itself. inherently tied to the lifecycle of the entity itself.
Identity-capable (ID-capable): An application is said to be ID- o Identity-capable (ID-capable): An application is said to be ID-
capable if it makes use of an Identifier of an entity to establish capable if it makes use of an Identifier of an entity to establish
communication. For example, an application that initiates its communication. For example, an application that initiates its
sessions using an ID. An application may use an IP-address as a sessions using an ID. An application may use an IP-address as a
proxy for an ID if the network resolves this ambiguity. We regard proxy for an ID if the network resolves this ambiguity. We regard
such an application as being ID-capable. such an application as being ID-capable.
IDentity Enabled Networks (IDEAS): IDEAS are networks that support o IDentity Enabled Networks (IDEAS): IDEAS are networks that support
the Identifier/Locator decoupling. Reaching an entity is achieved the Identifier/Locator decoupling. Reaching an entity is achieved
by the resolution of Identifier(s) to Locator(s). by the resolution of Identifier(s) to Locator(s).
IMEI: International Mobile Equipment Identity, a unique digit code o Locator (LOC): denotes information that is topology-dependent and
used to identify a mobile device.
Locator (LOC): denotes information that is topology-dependent and
which is used to forward packets to a given entity attached to a which is used to forward packets to a given entity attached to a
network. An entity can be reached using one or multiple Locators; network. An entity can be reached using one or multiple Locators;
these Locators may have a limited validity lifetime. these Locators may have a limited validity lifetime.
Metadata (META): Metadata is data about an Identity. The metadata o Metadata (META): Metadata is data about an Identity. The metadata
may contain information such as the nature of the entity for may contain information such as the nature of the entity for
example. example.
Scope: denotes the domain of applicability or usability of an ID. o Scope: denotes the domain of applicability or usability of an ID.
A scope may be limited (e.g., considered local with geographic A scope may be limited (e.g., considered local with geographic
proximity, or private within an administrative domain) or be proximity, or private within an administrative domain) or be
global. global.
User Equipment (UE): A user equipment is an entity per definition o User Equipment (UE): A user equipment is an entity per definition
in [IDEAS-PS] in [IDEAS-PS]
5G: Fifth generation wireless broadband technology [NEWS-3GPP].
4. Background 4. Background
The key components of GRIDS are GRIDS Mapping Services, or GRIDS-MS, Identity-Enabled Networks introduce the concept of Identity into
and GRIDS Identity Services, or GRIDS-IS. networking. This concept includes an Identity/Identifier split,
which complements existing Locator/Identifier separation
technologies.
GRIDS-MS provides services to maintain and resolve mappings between Identity-Enabled Networks are enabled by a set of core services that
Identifiers and Locators. are provided by common control infrastructure. Both the services and
the infrastructure that provides them are referred to as GRIDS,
GeneRic IDentity Services. GRIDS comprises several key components.
Those components include the following:
GRIDS-IS provides services to register Identifiers and maintain o GRIDS-MS (Mapping Services) provides services to maintain and
bindings between Identifiers and Identities. resolve mappings between Identifiers and Locators.
o GRIDS-IS (Identity and Identifier Services) provides services to
register Identifiers and maintain bindings between Identifiers and
Identities, as we well as manage their overall lifecycle.
o GRIDS-SS (Subscription Services) provides services that let
clients subscribe to updates regarding mappings and Identifiers
that they are interested in.
o GRIDS-Meta (Metadata Services) provides services to manage
metadata about Identities and Identifiers.
The requirements defined in this document do not imply a particular
solution. Specifically, they do not imply that infrastructure used
to address those requirements would need to be defined or built from
scratch. Instead, where possible, existing technologies, components,
and services will be used to address the requirements defined in this
document. Also, it should be noted that it is possible to introduce
additional components that provide value-added functions. One
example would be Grouping Services that support groupings of entities
and include mechanisms needed to manage Entity Groups.
In the following, requirements are denoted by REQ-xx=n, where "xx" In the following, requirements are denoted by REQ-xx=n, where "xx"
refers to a specific requirements section and "n" refers to the refers to a specific requirements section and "n" refers to the
number of the requirement. In some cases, optional requirements are number of the requirement. In some cases, optional requirements are
specified and designated as OPT-xx-n. Non-requirements (i.e. aspects specified and designated as OPT-xx-n. Non-requirements (i.e. aspects
that might be considered candidates for requirements, but that are that might be considered candidates for requirements, but that are
specifically not required to be supported at this point for various specifically not required to be supported at this point for various
reasons) are designated as NON-REQ-xx-n. reasons) are designated as NON-REQ-xx-n.
5. Requirements for Generic Resilient Identity Services (GRIDS) 5. Requirements for Generic Identity Services (GRIDS)
5.1. Mapping Services 5.1. Mapping Services
REQ-MS-10: GRIDS-MS needs to maintain mappings between Identifiers REQ-MS-10: GRIDS-MS needs to maintain mappings between Identifiers
and Locators. and Locators.
REQ-MS-20: GRIDS-MS needs to provide services that allow clients to REQ-MS-20: GRIDS-MS needs to provide services that allow clients to
resolve a Locator for a given Identifier. resolve a Locator for a given Identifier.
REQ-MS-30: GRIDS-MS MUST be able to support different models for REQ-MS-30: GRIDS-MS MUST be able to support different models for
authoritative mapping ownership, authorizing only the legitimate authoritative mapping ownership, authorizing only the legitimate
owner (or an entity acting on the owner's behalf) to update mapping owner (or an entity acting on the owner's behalf) to update mapping
data. Specifically, GRIDS-MS MUST be able to support (1) a model in data. Specifically, GRIDS-MS MUST be able to support (1) a model in
which clients of a certain Identity can update mapping data for their which clients of a certain Identity can update mapping data for their
Identifier, and (2) a model in which clients with a certain Locator Identifier, and (2) a model in which clients with a certain Locator
can update mapping data with that Locator. can update mapping data with that Locator.
REQ-MS-40: GRIDS-MS MUST be able to support policy-based REQ-MS-40: GRIDS-MS MUST be able to support policy-based
authorization for access to mapping services and to mapping authorization for access to mapping services and to mapping
information associated with specific Identities. information that is associated with specific Identities.
Authorization MUST be provided on the basis of the client's identity
that is accessing the service, or (in the case of an intermediary
client such as a tunnel gateway) on whose behalf the service is being
accessed.
Not every client will be entitled to every piece of mapping Not every client will be entitled to every piece of mapping
information. This allows GRIDS to be set up such that information is information. This allows GRIDS to be set up such that information is
only available on a "need-to-know" basis to clients, facilitating the only available on a "need-to-know" basis to clients, facilitating the
protection of private information for systems involved. protection of private information for systems involved.
5.2. Identity Services and Identifiers 5.2. Identity Services and Identifiers
REQ-IS-10: GRIDS MUST support IDs with the following characteristics REQ-IS-10: GRIDS MUST support IDfs and IDys with the following
characteristics
o Variable length ID o Variable length ID
o Fixed length o Fixed length
o Structured o Structured
o Unstructured o Unstructured
REQ-IS-20: GRIDS MUST provide proper separation between the concepts REQ-IS-20: GRIDS MUST provide proper separation between the concepts
of "Identity" and "Identifier". of "Identity" and "Identifier".
An Identity is synonymous to the being of an entity that can An Identity is synonymous to the being of an entity that can
communicate in an Identity-Enabled Network. Identity information communicate in an Identity-Enabled Network. Identity information
needs to be strongly secured and is generally kept private. Identity needs to be strongly secured and is generally kept private. Identity
is represented by a special type of Identifier that is never exposed is represented by a special type of Identifier that is not expected
over-the-wire in regular data plane communications in the network. to ever be exposed over-the-wire in regular data plane communications
An Identifier, on the other hand, is a reference to an Identity in the network. An Identifier, on the other hand, is a reference to
respectively associated Entity. An Identifier will in generally be an Identity respectively associated Entity. An Identifier will in
public and constitutes how an Identity will be known to others, generally be public and constitutes how an Identity will be known to
including other Entities that wish to communicate with the Entity others, including other Entities that wish to communicate with the
designated by the Identifier. Identifiers MAY also be included in Entity designated by the Identifier. Identifiers MAY also be
data plane packets. An example of an Identity would be the IMEI that included in data plane packets.
is associated with a cell phone that is assigned by the equipment
manufacturer. An example of an Identifier, on the other hand, would
be the E.164 telephone number that is associated with the device. An
Identity can be associated with multiple Identifiers. A Locator is a
concept that is associated with an Identity; however, Locators are
resolved by Identifier. In other words, an Identity's Locator is the
same and returned regardless which Identifier is used in a mapping or
resolution request to refer to it.
REQ-IS-30: GRIDS MUST support IDs that refer to User Endpoints of a An Identity can be associated with multiple Identifiers. It should
be noted that Locators are associated with Identifiers, not Identity.
An Identity does require a representation itself, which resembles in
effect a "special" Identifier. Therefore, one question that is often
asked concerns how Identifier and Identity really differ. One way in
which to asnwer is that a regular Identifier always refers to another
Identifier, whereas the Identity does not. In that sense, the
Identity constitutes the root of a "tree" (generally flat with one
level of hierarchy only, but not precluding multiple levels) of
Identifiers that all belong to and reference the same Identity.
REQ-IS-30: GRIDS MUST support IDfs that refer to User Endpoints of a
given Identity. given Identity.
REQ-IS-40: GRIDS MUST support a model in which multiple Identifiers REQ-IS-40: GRIDS MUST support a model in which multiple Identifiers
can be associated with the same Identity. Identifier referring to can be associated with the same Identity. GRIDS-IS MUST NOT have
the same Identity will resolve to the same Locator. GRIDS-IS MUST inherent limitations with regards to the number of Identifiers that
NOT have inherent limitations with regards to the number of may be simultaneously associated with the same Identity.
Identifiers that may be simultaneously associated with the same
Identity.
REQ-IS-50: GRIDS-IS MUST support the secure registration of new REQ-IS-50: GRIDS-IS MUST support the secure registration of new
Identities. Identities.
"Secure" refers to mechanisms such as strong encryption and mutual "Secure" refers to mechanisms such as strong encryption and mutual
authentication. authentication.
REQ-IS-60: GRIDS-IS MUST support the secure unregistration / REQ-IS-60: GRIDS-IS MUST support the secure unregistration /
revocation of an Identity revocation of an Identity
REQ-IS-70: GRIDS-IS MUST support the registration of new Identifiers REQ-IS-70: GRIDS-IS MUST support the registration of new Identifiers
(independent of the associated Identity) (independent of registration of the associated Identity)
REQ-IS-80: GRIDS-IS MUST support the unregistration / revocation of REQ-IS-80: GRIDS-IS MUST support the unregistration / revocation of
Identifiers (independent of unregistration of the associated Identifiers (independent of unregistration of the associated
Identity) Identity)
REQ-IS-90: GRIDS MUST allow for the possibility to support other IDs REQ-IS-90: GRIDS MUST allow for the possibility to support other IDs
(i.e. IDs not tied to the Identity of a User Endpoint) in the (i.e. IDs not tied to the Identity of a User Endpoint) in the
future, such as Group IDs (see also GRIDS Extensions). future, such as Group IDs.
REQ-IS-100: GRIDS-IS MUST support a model in which Identifiers are REQ-IS-100: GRIDS-IS MUST support a model in which Identifiers are
registered by a client representing the Identity that the ID is registered by a client representing the Identity that the IDf is
associated with (e.g., a User Endpoint). GRIDS-IS MUST provide associated with (e.g., a User Endpoint). GRIDS-IS MUST provide
mechanisms that prevent usage of identifiers in ways that result in mechanisms that prevent usage of identifiers in ways that result in
amgibuities with regards to determining an Identifier's associated amgibuities with regards to determining an Identifier's associated
Identity. To this end, GRIDS-IS MUST either prevent duplicate Identity. To this end, GRIDS-IS MUST either prevent duplicate
assignment of IDs, specifically assignment of the same ID to multiple assignment of IDfs, specifically assignment of the same IDf to
Identities, or in case duplicate assignment occurs, ensure that an multiple Identities, or in case duplicate assignment occurs, ensure
ID's associated Identity is clear depending on the context, such as a that an IDf's associated Identity is clear depending on the context,
local scope. such as a local scope.
It is to be determined whether GRIDS-IS should prevent recycling of It is to be determined whether GRIDS-IS should prevent recycling of
IDs that had been assigned previously, even if since unregistered, or IDfs that had been assigned previously, even if since unregistered,
if it should provide a warning when such an ID is reassigned. or if it should provide a warning when such an IDf is reassigned.
REQ-IS-110: GRIDS-IS MUST support a model in which Identifiers are REQ-IS-110: GRIDS-IS MUST support a model in which Identifiers are
assigned and registered by an authority. assigned and registered by an authority.
REQ-IS-120: GRIDS-IS MUST support the notion of an Identifier
preference, providing a service that allows a client to resolve which
Identifier it should when directing communication at a given
destination. The Identifier used can be simply the same Identfier
used by the client to refer to the destination in the resolution
request, or it can be an alternative Identifier, such as an ephemeral
Identifier. This capability SHOULD be provided in a manner that is
integrated with GRIDS-MS, combining the resolution of Identifier with
Locator information.
Such a capability is useful to enable anonymization of communciation
traffic by obfuscating identifiers. For example, a client could
request a Locator for a given, well-known Identifier for a
destination, such as an Identifier listed in a public directory.
GRIDS could indicate to not use the well-known Identifier, but (for
example) an ephemeral Identifier instead, returned (for example)
together with a Locator in response to a mapping resolution request.
REQ-IS-130: GRIDS-IS MUST be able to support different models for
authoritative ownership of Identifier preferences, authorizing only
the legitimate owner (or an entity acting on the owner's behalf) to
update preference data. Specifically, GRIDS-IS MUST be able to
support a model in which clients of a given Identity can update their
own Identity preference data.
5.3. Subscription Services 5.3. Subscription Services
REQ-SS-10: GRIDS-SS MUST allow clients to subscribe to updates for REQ-SS-10: GRIDS-SS MUST allow clients to subscribe to updates for
information that they are entitled to resolve. Specifically, GRIDS- information that they are entitled to resolve. Specifically, GRIDS-
SS MUST provide support for pushing updates about Locators for SS MUST provide support for pushing updates about Locators for
mappings that are of interest to a client with minimal incurred mappings that are of interest to a client with minimal incurred
delay. delay. GRIDS-SS MUST also provide suppport for pushing updates about
preferred Identifiers of entities to whose mapping information the
client is subscribed to.
5.4. Distribution and Redundancy 5.4. Metadata Support and Services
Metadata can be tremendously useful for Identity-Enabled Networks, as
indicated in both Problem Statement and Use Cases. Therefore, GRIDS
SHOULD support Metadata Services (GRIDS-Meta) that allow to store and
retrieve certain metadata associated with Identities, as well as
metadata associated with Identifiers. The metadata supported has
several properties in common:
o It is slow changing and does not impose significant requirements
with regards to update rates that would have to be supported
o It does not impose significant requirements with regards to
latency of propagation of updates
o It is low in size and volume
GRIDS-Meta will have to support requirements that include the
following:
o Req-Meta-10: When GRIDS-Meta is supported, it MUST provide support
for associating metadata with a given Identity. An example of
metadata associated with an Identity is the type of endpoint (e.g.
a mobile device, an IoT device, or a compute server).
o Req-Meta-20: When GRIDS-Meta is supported, it MUST provide support
for associating metadata with a given Identifier (that is not
automatically associated with other Identifiers that belong to the
same Identity). An example of metadata associated with an
Identifier would be information about which Groupings the
Identifier belongs to, or whether the Identifier is considered a
publicly known Identifier that should, for example, be listed in a
public directory.
o Req-Meta-30: When GRIDS-Meta is supported, it MUST provide support
that allows a client to retrieve metadata for an Entity as
identified by a given Identifier. The retrieved metadata should
include both metadata associated with the particular Identifier,
and metadata associated with the Identity that is referred to by
the Identifier.
o Req-Meta-50: GRIDS-Meta MUST support for differentiation between
public metadata that is generally accessible and can be shared
across GRIDS boundaries, and private metadata that is accessible
only on a need-to-know basis.
o Example of private metadata includes any metadata that ties an
identity to personal information (such as customer data regarding
the real-world owner of a communications entity.) Example of
public metadata includes metadata such as the type of endpoint
(e.g. a mobile device, an IoT device, a compute server), or which
Identifier constitutes a publicly known Identfier that should be
listed in publicly accessible directories.
o Req-Meta-60: When GRIDS-Meta is supported, it MUST support a
notion of ownership of metadata, and give the owner of the
metadata full control over security rules that guide who can
access that metadata.
o Req-Meta-70: When GRIDS-Meta is supported, it MUST support the
definition and enforcement of security policies that guide who is
authorized to retrieve metadata, and who is authorized to modify
metadata.
5.5. Distribution and Redundancy
REQ-DR-10: GRIDS MUST be robust and very highly available. REQ-DR-10: GRIDS MUST be robust and very highly available.
REQ-DR-20: Any maintenance or upgrades to GRIDS MUST NOT affect REQ-DR-20: Any maintenance or upgrades to GRIDS MUST NOT affect
availability of GRIDS services. availability of GRIDS services.
REQ-DR-30: GRIDS MUST support implementation using a distributed and REQ-DR-30: GRIDS MUST support implementation using a distributed and
redundant architecture. Specifically, failure of individual redundant architecture. Specifically, failure of individual
components MUST NOT bring down GRIDS as a whole. components MUST NOT bring down GRIDS as a whole.
skipping to change at page 8, line 29 skipping to change at page 11, line 7
be robust, distributed and provide redundancy. The mapping system be robust, distributed and provide redundancy. The mapping system
design and architecture must avoid being single points of failure and design and architecture must avoid being single points of failure and
MUST enforce resiliency. MUST enforce resiliency.
Furthermore, it should be noted that the format of the Identifier may Furthermore, it should be noted that the format of the Identifier may
or may not play a role in how any underlying servers used to or may not play a role in how any underlying servers used to
implement GRIDS might be distributed. It is conceivable that such implement GRIDS might be distributed. It is conceivable that such
distribution and placement of GRIDS components and data maintained by distribution and placement of GRIDS components and data maintained by
GRIDS will be affected by usage patterns. GRIDS will be affected by usage patterns.
5.5. Scale and Performance 5.6. Scale and Performance
REQ-SP-10: GRIDS MUST support very large scale. REQ-SP-10: GRIDS MUST support very large (Internet-level) scale.
It is anticipated that GRIDS MUST be able to handle from the start It is anticipated that GRIDS MUST be able to handle from the start
billions of distinct Identifiers and mapping entries and allow for billions of distinct Identifiers and mapping entries and allow for
substatiantial future growth. While this document makes no substatiantial future growth. While this document makes no
statements about GRIDS architecture, it should be noted that GRIDS statements about GRIDS architecture, it should be noted that GRIDS
will likely not be provided by monolithic infrastructure but by means will likely not be provided by monolithic infrastructure but by means
of multiple distributed and interconnected components. of multiple distributed and interconnected components.
REQ-SP-20: GRIDS MUST scale in a way such that increases in the REQ-SP-20: GRIDS MUST scale in a way such that increases in the
number of Identifiers and mapping entries do not negatively degrade number of Identifiers and mapping entries do not negatively degrade
performance. Performance characteristics SHOULD be independent of performance. Performance characteristics SHOULD be independent of
scale. If such constant scale performance characteristics cannot be scale. If such constant scale performance characteristics cannot be
provided, performance MUST NOT degrade worse than on logaritmically provided, performance MUST NOT degrade in worse than logarithmic
based on the number of Entities. manner based on the number of Entities.
REQ-SP-30: A characterization of GRIDS performance at scale, as well REQ-SP-30: A characterization of GRIDS performance at scale, as well
as associated GRIDS performance objectives, MUST include the as associated GRIDS performance objectives, MUST include the
following parameters: following parameters:
o TR: Time to resolve a Locator by Identifier, in three variants to o TR: Time to resolve a Locator by Identifier, in three variants to
characterize normal case, performance determinism, and "bottom characterize normal case, performance determinism, and "bottom
case" behavior: case" behavior:
* mean * mean
skipping to change at page 10, line 28 skipping to change at page 13, line 4
It should be noted that this document does not mandate a particular It should be noted that this document does not mandate a particular
implementation architecture. However, in order to be able to meet implementation architecture. However, in order to be able to meet
the ambitious performance and scale requirements imposed by GRIDS, we the ambitious performance and scale requirements imposed by GRIDS, we
note that an architecture that leverages principles of distribution, note that an architecture that leverages principles of distribution,
hierarchy, and aggregation may help to achieve these goals. hierarchy, and aggregation may help to achieve these goals.
Specifically, we note that in order to meet low latency goals, Specifically, we note that in order to meet low latency goals,
architectural considerations SHOULD include support for predictive architectural considerations SHOULD include support for predictive
and proactive dissemination and caching of data to locations that are and proactive dissemination and caching of data to locations that are
close to clients that need to consume and interact with it. close to clients that need to consume and interact with it.
Conceivably, this may also involve application of data analytics and Conceivably, this may also involve application of data analytics and
machine learning techniques. machine learning techniques.
5.6. GRIDS Security 5.7. GRIDS Security
REQ-SEC-10: GRIDS needs to be robust against direct and indirect REQ-SEC-10: GRIDS needs to be robust against direct and indirect
attacks. If any component of GRIDS is attacked, the system needs to attacks. If any component of GRIDS is attacked, the system needs to
degrade gracefully. degrade gracefully.
REQ-SEC-20: GRIDS The addition and removal of components of the REQ-SEC-20: GRIDS The addition and removal of components of the
mapping system must be performed in a secure matter so as to not mapping system must be performed in a secure matter so as to not
violate the integrity and operation of the system and service it violate the integrity and operation of the system and service it
provides. provides.
skipping to change at page 11, line 31 skipping to change at page 14, line 10
REQ-SEC-80: GRIDS MUST support cryptographic signing of information REQ-SEC-80: GRIDS MUST support cryptographic signing of information
that it provides to allow clients to verify if the provided that it provides to allow clients to verify if the provided
information is authentic. information is authentic.
REQ-SEC-90: GRIDS MUST support message rate-limiting and other REQ-SEC-90: GRIDS MUST support message rate-limiting and other
heuristics must be part of the foundational support of the mapping heuristics must be part of the foundational support of the mapping
system to protect GRIDS from sudden overloaded conditions and system to protect GRIDS from sudden overloaded conditions and
mitigate the effects of potential attacks. mitigate the effects of potential attacks.
5.7. Ability to support multiple instances 5.8. Ability to support multiple instances
REQ-MI-10: GRIDS SHOULD be deployable in a private space and provide REQ-MI-10: GRIDS SHOULD be deployable in a private space and provide
data isolation. For example, GRIDS MUST NOT require a company to data isolation. For example, GRIDS MUST NOT require a company to
expose all of its ID as public IDs if the company does not wish to do expose all of its IDf as public IDfs if the company does not wish to
so. do so.
Because Identifiers are unique only within a given GRIDS instance, it Because Identifiers are unique only within a given GRIDS instance, it
should be noted that by using multiple isolated instances of GRIDS, should be noted that by using multiple isolated instances of GRIDS,
it is conceivable that overlapping IDs can be supported. However it is conceivable that overlapping IDfs can be supported. However
this is not encouraged. One way in which this can be avoided is by this is not encouraged. One way in which this can be avoided is by
by allocating private ranges for experimental use in the ID name by allocating private ranges for experimental use in the IDf name
space, and requiring GRIDS to not assign any IDs in an allocated space, and requiring GRIDS to not assign any IDfs in an allocated
Identifier space. Identifier space.
5.8. GRIDS Extensions REQ-MI-20: GRIDS MUST support a distinction between "private" GRIDS
data that is refined in scope to a given GRIDS instance, and "public"
GRIDS MUST be designed in such a way to allow future extensions. The GRIDS data whose scope can be global. Specifically, private GRIDS
following are examples of extensions that GRIDS will likely have to data MUST NOT be shared beyond GRIDS boundaries, whereas public GRIDS
support (and which likely will be specified) in the future, but whose data can be (and may have to be) shared across multiple GRIDS
support is not required from the outset. instances.
5.8.1. Grouping Support
GRIDS MAY support Group IDs that represent groupings of User
Endpoints. There are multiple applications as well as multiple types
of groupings, for example administrative groupings (used to
facilitate management), groupings that represent collections of User
Endpoints that temporarily or permanently share the same fate (such
as devices in the same railroad car that all use a communications
gateway with the same locator), and groupings that represent
multihomed endpoints (which include endpoints that mutually protect
each other in case of failures).
For Group IDs to be supported, GRIDS will have to support
requirements that include the following:
o Resolution of a group Identifiers returns list of all Locators of For example, some metadata may be private, such as metadata tieing an
Identifiers in the ID Group identity to personal information (such as customer data regarding the
real-world owner of a communications entity.) Other metadata may be
public, such as the type of endpoint (e.g. a mobile device, an IoT
device, a compute server) that is associated with an entity.
Likewise, the list of Identifiers that are in use or "claimed"
constitute public GRIDS data (but not who those Identifiers are
assigned to).
o Group ID Management Services: Adding and Removing IDs from the 5.9. GRIDS Extensions
group, as well as querying group members
5.8.2. Metadata Support GRIDS MUST be designed in such a way to allow future extensions and
services.
A mapping server could be a place to store metadata of interest that An example of a future extension concerns grouping services,
will facilitate deploying new capabilities such as context awareness involving Group IDs that represent groupings of User Endpoints.
in next generation applications and protocols. As always there are There are multiple applications as well as multiple types of
tradeoffs on the type of metadata stored and its usage. It is groupings, for example administrative groupings (used to facilitate
assumed that the metadata use is directly related to the use cases management), groupings that represent collections of User Endpoints
described in the document. For this reason, GRIDS MAY support that temporarily or permanently share the same fate (such as devices
metadata extensions that allow to associate metadata with a given in the same railroad car that all use a communications gateway with
Identity. For metadata to be supported, GRIDS will have to support the same locator), and groupings that represent multihomed endpoints
requirements that include the following: (which include endpoints that mutually protect each other in case of
failures).
o Metadata Management Services that allow a client to associate The following are examples of requirements that GRIDS will have to
metadata with a given Identity support if grouping is to be supported as a feature. It should be
noted the following list is incomplete, merely indicative of the
types of requirements that will be associated with providing Grouping
Services:
o Metadata Retrieval Services that allow a client to retrieve o GRIDS SHOULD support group identifiers, used to designate
metadata for a given Identifier groupings of endpoints.
o Support for the definition and enforcement of policies that guide o GRIDS SHOULD support Group ID (G-ID) Management Services: Adding
who is authorized to access (retrieve and modify) metadata and removing identifiers from the group, as well as querying group
members.
o Support for differentiation for different types of metadata, for o GRIDS SHOULD support a type of group used to designate a group of
example, public metadata that is generally accessible (such as the endpoints that share the same fate, i.e. that are (temporarily or
type of endpoint of a given Identity) vs private metadata that is permanently) assoicated with the same Locator. GRIDS Grouping
accessible only on a need-to-know basis. Services SHALL integrated with GRIDS-MS in such a way that for an
Identifier that is part of a group, the Locator of the Group takes
precedence over (or determines) the Identfier's "native" Locator
(which it would be associated with, if not part of the group).
6. Security Considerations 6. Security Considerations
Due to the sensitivity of Identity tied to Identifier and location Due to the sensitivity of Identity tied to Identifier and location
data there is a need to pay attention to security ramifications. In data there is a need to pay attention to security ramifications. In
particular, the security goals should include confidentiality, particular, the security goals should include confidentiality,
possible encryption for integrity of sensitive data and privacy. possible encryption for integrity of sensitive data and privacy.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 13, line 25 skipping to change at page 15, line 49
8. Contributors 8. Contributors
This present document is based on an extract of the first version of This present document is based on an extract of the first version of
the draft. The authors and their affiliations on the original the draft. The authors and their affiliations on the original
document are: D. Farinacci (lispers.net), D. Meyer (Brocade), D. document are: D. Farinacci (lispers.net), D. Meyer (Brocade), D.
Lake (Cisco Systems), T. Herbert (Facebook), M. Menth (University Lake (Cisco Systems), T. Herbert (Facebook), M. Menth (University
of Tuebingen), Dipenkar Raychaudhuri (Rutgers University), Julius of Tuebingen), Dipenkar Raychaudhuri (Rutgers University), Julius
Mueller (ATT) and Padma Pillay-Esnault (Huawei). Mueller (ATT) and Padma Pillay-Esnault (Huawei).
There are two companion documents also extracted from the -00 version There are two companion documents that were extracted from the -00
of this document: Problem Statement in IDEAS [IDEAS-PS] and GRIDS version of this document: Problem Statement in IDEAS [IDEAS-PS] and
Requirements [IDEAS-USE] which regroups all the authors above. GRIDS Requirements [IDEAS-USE] which regroups all the authors above.
Uma Chunduri Uma Chunduri
Yingzhen Qu
Rutgers University: Parishad Karimi and Shreyasee Mukherjee Rutgers University: Parishad Karimi and Shreyasee Mukherjee
9. Acknowledgments 9. Acknowledgments
This document was produced using Marshall Rose's xml2rfc tool. This document was produced using Marshall Rose's xml2rfc tool.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References 10.2. Informative References
[IDEAS-GAP]
Qu, Y., Caballos, A., Moskowitz, R., Liu, B., and A.
Stockmayer, "Gap Analysis for Identity Enabled Networks",
July 2017, <https://tools.ietf.org/html/draft-xyz-ideas-
gap-analysis-00/>.
[IDEAS-IDENTITY]
Chunduri, U., Clemm, A., and M. Menth, "Identity Use Cases
in IDEAS", June 2017, <https://tools.ietf.org/html/draft-
ccm-ideas-identity-use-cases-00/>.
[IDEAS-PS] [IDEAS-PS]
Pillay-Esnault, P., Boucadair, M., Jacquenet, C., Pillay-Esnault, P., Boucadair, M., Jacquenet, C.,
Fioccola, G., and A. Nennker, "Problem Statement for Fioccola, G., and A. Nennker, "Problem Statement for
Identity Enabled Networks", March 2017, Identity Enabled Networks", July 2017,
<https://datatracker.ietf.org/doc/draft-padma-ideas- <https://datatracker.ietf.org/doc/draft-padma-ideas-
problem-statement/>. problem-statement/>.
[IDEAS-USE] [IDEAS-USE]
Pillay-Esnault, P., Farinacci, D., Herbert, T., Jacquenet, Pillay-Esnault, P., Farinacci, D., Herbert, T., Jacquenet,
C., Lake, D., Menth, M., Meyer, D., and D. Raychaudhuri, C., Lake, D., Menth, M., Meyer, D., and D. Raychaudhuri,
"Use Cases for Identity Enabled Networks", March 2017, "Use Cases for Identity Enabled Networks", July 2017,
<https://datatracker.ietf.org/doc/draft-padma-ideas-use- <https://datatracker.ietf.org/doc/draft-padma-ideas-use-
cases-00/>. cases-01/>.
[NEWS-3GPP]
3GPP, "3GPP News",
<http://www.3gpp.org/news-events/3gpp-news>.
Authors' Addresses Authors' Addresses
Padma Pillay-Esnault (editor) Padma Pillay-Esnault
Huawei Huawei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: padma.ietf@gmail.com Email: padma.ietf@gmail.com
Alexander Clemm Alexander Clemm
Huawei Huawei
2330 Central Expressway 2330 Central Expressway
 End of changes. 71 change blocks. 
179 lines changed or deleted 302 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/