Internet DRAFT - draft-padma-ideas-problem-statement
draft-padma-ideas-problem-statement
Network Working Group P. Pillay-Esnault, Ed.
Internet-Draft Huawei
Intended status: Informational M. Boucadair
Expires: January 4, 2018 Orange
G. Fioccola
Telecom Italia
C. Jacquenet
Orange
A. Nennker
Deutsche Telekom
July 3, 2017
Problem Statement for Identity Enabled Networks
draft-padma-ideas-problem-statement-03
Abstract
This problem statement examines how existing protocols that separate
identifiers from their location may benefit from the concept of
identity. The proposal laid out herein advocates for a standardized
identity/identifier network infrastructure that provides a framework
to support identity services in addition to enhancing existing
identifier/location mapping and resolution services.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
Pillay-Esnault, et al. Expires January 4, 2018 [Page 1]
Internet-Draft July 2017
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Key Problems . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Tracking Prevention . . . . . . . . . . . . . . . . . 5
3.1.2. Privacy against Eavesdroppers . . . . . . . . . . . . 5
3.1.3. Identifier Right to be Forgotten . . . . . . . . . . 6
3.2. Common Infrastructure and Primitives . . . . . . . . . . 6
3.3. Allocation Schemes Guidance . . . . . . . . . . . . . . . 7
4. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Future Studies . . . . . . . . . . . . . . . . . . . . . 8
5. Relationship between IDEAS and other IETF Working Groups . . 8
5.1. LISP WG . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. HIP WG . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. NVO3 WG . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Companion Documents . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
11. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
While the separation of identifier from the location is not a new
concept, existing solutions such as Host Identity Protocol (HIP)
[RFC7401] , Location/Separation Protocol (LISP) [RFC6830] and
Identifier-Locator Addressing (ILA) [ILA] for IPv6, may benefit from
a higher layer abstraction that separates the identity of an entity
from its associated identifier(s).
In identifier and Location split protocols, identifiers (IDf) are
used for decoupling the identifier and the location information at
Pillay-Esnault, et al. Expires January 4, 2018 [Page 2]
Internet-Draft July 2017
the network layer. Typically, a IDf represents an end-point
communication tied to an entity. Usually, IDfs are long-lived and
may or may not be routable. However, locators (LOC) may be transient
and associated with the location of the entity. The LOCs are
routable network addresses (e.g. IPv4, IPv6 addresses). The IDfs
are mapped to LOCs for forwarding purposes. Modification of LOC
information is handled by an a mapping system that updates the IDf/
LOC mappings.
In order to communicate with a device, the initiator relies on a
mapping system that is designed to process lookup requests on a
network IDf and return the LOC(s). While the mapping system fulfills
its functionality, this mode of operation has some drawbacks.
The entities update the system with their (IDf,LOC) bindings. In
some cases, it may register the LOC of a forwarding element such as a
proxy or HIP Rendezvous Server. Regardless, it is assumed that once
the entities have registered their (IDF,LOC(s)) tuple to the system,
this information is available to all with access to the mapping
system. Any request for this information would then be readily
available without any discrimination. For example, a public entity
needs to have its IDf public to be discovered by clients. However,
it might not be always desirable that some devices (e.g. home
cameras) are visible to all without any control.
Privacy and security requirements of entities suggest the use of some
mechanism to authenticate entities that can dynamically discover them
and prevent unwanted communication. In existing architectures it is
possible to authenticate IDf, however they are not permanently
attached to the entity. This is crucial in a multi-provider and/or
multi-domain scenario, related for example to a complex end-to-end
service.
Therefore the concept of an identity(IDy) tied to an entity and to
its lifecycle should be considered. The IDy is intended to be used
for identifying and authenticating an entity. Likewise, the IDy
information should not be carried in clear in packet headers. The
Section 3 of this document will describe how this IDy may be used.
Furthermore, it would be beneficial to generalize this Identity
concept across protocols that may benefit from it. Therefore there
is a need for a system which shares some common control plane for
services commonly used such as look-ups or updates.
This document examines the possible changes and improvements needed
to address these challenges in Identity Enabled networkS (IDEAS). It
describes the problem statement and advocates for a standardized
extensible common control plane for IDf/LOC protocols that supports:
Pillay-Esnault, et al. Expires January 4, 2018 [Page 3]
Internet-Draft July 2017
Identity services (including registration and authentication)
Management of access credentials based on IDy
Look-ups with restrictions
Mapping, and resolution services on IDfs
2. Definition of Terms
Entity: An entity is a communication endpoint. It can be a
device, a node, or a (software) process, that needs to be
identified and locatable/reachable. Such entity will have one or
more communication interfaces. An entity may have multiple IDfs
simultaneously that are NOT associated with any particular
interface(s). It is reached by the resolution of one or more of
its IDfs to one or more LOCs.
Identity (IDy): The essence of "being" of a specific entity. An
IDy is not to be confused with an IDf: while an IDf may be used to
refer to an entity, an IDf's lifecycle is not necessarily tied to
the lifecycle of the IDy it is referencing. On the other hand,
the IDy's lifecycle is inherently tied to the lifecycle of the
entity itself.
Identifier (IDf): An IDf denotes information to unambiguously
identify an entity or an entity group within a given scope. An
IDf is the equivalent of an End point identifier (EID) in LISP or
Host Identity Tag (HIT) in HIP. It may be visible in
communications.
Locator (LOC): A locator is a routable network address. It may be
associated with an IDf and used for communication on the network
layer according to LOC/IDf split principle. A LOC is the
equivalent of a Routing Locator (RLOC) in LISP or an IP address in
HIP.
Metadata (META): Data associated with an IDy and its IDfs in the
framework. The metadata is to be used for storing long-lived slow
changing information such as the nature of the entity (e.g. camera
or phone).
IDy/IDf mapping: One IDy may be associated to multiple IDfs. The
IDfs are mapped to one IDy.
Identifier-based: When an entity is only reachable through one or
more communication access then a protocol or a solution is said to
Pillay-Esnault, et al. Expires January 4, 2018 [Page 4]
Internet-Draft July 2017
be identifier-based if it uses an ID-LOC decoupling and a mapping
system (MS) as base components of the architecture.
GeneRic Identity Services (GRIDS): GRIDS is a set of services to
manage the lifecycle of ID[y|f]s, to map and resolve IDfs and
LOCs, and to associate META with entities. It is a distributed
system that stores the IDy, IDf, the associated LOC(s), and META
in the form of tuples (ID, LOC, and META). Meta queries are
supported and queries are restricted to authenticated and
authorized IDys.
IDentity Enabled Networks (IDEAS): IDEAS are networks that support
the IDf/IDy decoupling as well as IDf /LOC decoupling using GRIDS.
Reaching an entity is achieved by the resolution of IDf(s) to
LOC(s).
Scope: Domain of applicability or usability of an IDfs and IDys.
The scope may be global or limited, e.g., considered local with
geographic proximity or private within an administrative domain.
3. Key Problems
3.1. Privacy
3.1.1. Tracking Prevention
Access to a mapping system may reveal the location and other
sensitive information about an entity to the requestor of a look-up
on an IDf. Repeated look-ups on the mapping system may be misused
for tracking IDfs of an entity or mount an attack.
To preserve its privacy, the entity or infrastructure may restrict
access for look-ups for certain IDfs or IDys or entity with specific
meta. (E.g. nature of an entity stored in meta as a camera).
Currently, even if look-ups on the mapping systems were modified not
to return a result if the requestor is barred, it would be easily
defeated if the requestor changes its IDf. However, if all IDfs of
an entity are associated with the IDy, then the requestor entity
cannot easily defeat the aforementioned filtering rule by just
changing its IDf.
3.1.2. Privacy against Eavesdroppers
Eavesdroppers may observe the traffic and deduce the flows between
two IDfs or entities. To protect its privacy, an entity may choose
additional temporary IDfs for communications.
Pillay-Esnault, et al. Expires January 4, 2018 [Page 5]
Internet-Draft July 2017
However, this mechanism makes discovery difficult and the entity must
at least have a long-lived IDf for this purpose.
The use of obfuscation is another solution to protect the source and
destination IDf however this implies extra processing or DPI for
functionalities such as late binding.
The use of IDy as an indirection to the actual IDfs used on the wire
present the advantage of having the source and destination ephemeral
IDfs in clear but authorized use may still maps these to the IDy.
The IDy of an entity must not be revealed in packets. Therefore,
encrypting the control plane mechanisms (requests and replies) is
required to avoid eavesdroppers to deduce who are the peers of
communication flows.
3.1.3. Identifier Right to be Forgotten
The control of the IDy/IDf mappings can restrict access to selected
requesting IDys/IDfs and also limit that access over time to
implement an "identifier right to be forgotten".
The advantage of this method is that entities may use IDfs for
communication to better protect their IDy. Only authorized
communication partners can find out the corresponding IDys. The
concept of IDy proposed by IDEAS helps to provide privacy in
communication in a similar way as IPv6 privacy extension minimizes
the risk of being tracked by a stable MAC address. To that end,
access restriction is needed for mapping system requests that also
need to be encrypted to avoid eavesdropping.
3.2. Common Infrastructure and Primitives
Currently, each of the IDf-based protocols uses its own specific
mapping databases. While IDf-based data plane mechanisms may serve
fundamentally different objectives and may not need to interoperate,
there is a potential benefit in providing them with a common
interface for common services such as IDy/IDf registration,
discovery, update, resolution and access control policy.
Furthermore, the lack of a common infrastructure with standardized
invocation interfaces has the following downsides:
a. An impediment for the deployment of IDf-based. Indeed, it would
be inefficient to deploy several specialized mapping/ resolution
network databases within the same administrative domain.
Furthermore, there will be additional expense and overhead to
administer multiple proprietary mapping systems.
Pillay-Esnault, et al. Expires January 4, 2018 [Page 6]
Internet-Draft July 2017
b. Difficulty to have an overall view of the network. If multiple
IDf-based solutions with distinct mapping systems are deployed,
troubleshooting may be difficult as the information may be
located in different places.
c. Complex Management due to disjoint information spread over
several mapping systems. Operations such as merging networks are
error prone and more challenging to detect and fix.
Additionally, there will be considerable management overhead
whenever devices migrate.
d. Barriers to the enforcement of common and consistent policies.
For example, in cross-platform IoT networking, brokering services
may be needed to enforce routing/security/QoS/TE policies on
behalf of partnering structures - service provider, energy
provider, content provider, etc.
The common infrastructure may be supported within limited or private
scopes. In addition support of private instances provides the
necessary separation for specific users or applications.
3.3. Allocation Schemes Guidance
Currently, there is no consistent guidance or allocation scheme for
non-IP address format public IDfs across all protocols. Each
protocol has historically assigned their IDfs independently, be it
structured or not. An agreed scheme or a collision detection
mechanism within a scope may facilitate cross-domain communication in
the future. This would simplify the implementation of some use cases
to facilitate cross-silo communications or to better address the
merging of networks.
The support of several allocation schemes by carving specific ranges
within a name space and recycling should be explored for the future
mapping systems. The operations and ease of deployment should also
be considered as they may influence policy enforcement schemes
related to the allocation of IDfs of the use of relevant META.
4. Scopes
4.1. In Scope
The scope of this work is on the network layer (layer 3). The
network identities that may be alphanumerical are assumed to map to
numerical IDfs as in LISP, HIP or ILA. The LOCs are assumed to be
IPv4 or IPv6 addresses.
The META is assumed to be tied to the IDy or IDf and slow changing.
Pillay-Esnault, et al. Expires January 4, 2018 [Page 7]
Internet-Draft July 2017
While the issues described in the document may be generalized to a
broader scope, IDEAS is focused on delivering functionalities at the
network layer only.
4.2. Out of Scope
The following are out of scope for this effort:
o The resolution or mapping of domain names or any application level
naming or directories (like URIs ...).
o META information with rapid changes
4.3. Future Studies
Other network addressing schemes may be considered for future
studies.
5. Relationship between IDEAS and other IETF Working Groups
This document is meant to encourage the IETF community to investigate
the opportunity of a new specification effort to address some
specific problems from an IDy Enabled Networks standpoint in general.
The focus is to find a common solution and infrastructure that can be
shared by current protocols and facilitate the introduction of new
IDy-based services while avoiding rehashing the same problems again
each time a new service pops up.
We propose to address these problems with a GeneRic IDentity Services
(GRIDS) infrastructure which includes standardized access and
multiple services. The services include secured registration,
discovery, updates with data integrity, mapping and resolution
capabilities, define relationships between identities or group of
identities, access control policy and security.
Some other working groups are already working to address some
specific limitations or enhancement of identifier-based protocols but
do not take IDy requirements as highlighted in this document into
consideration. These working groups include LISP, HIP and NVO3.
Protocols and architectures defined by these WGs may assume a mapping
system or other resolution techniques, but they are not currently
covering the other services mentioned in this document.
Pillay-Esnault, et al. Expires January 4, 2018 [Page 8]
Internet-Draft July 2017
5.1. LISP WG
The LISP WG has been working on multiple mapping systems (ALT, DDT)
for the LISP control plane and the primary function of this mapping
system is to map and resolve the IDf to IP addresses (EID/RLOC
mapping). LISP WG is also looking at Casssandra and blockchain.
Though some requirements are common,GRIDS has new specific
requirements described in [IDEAS-REQ].
5.2. HIP WG
The HIP WG has based its IDy to IDf resolution service on DNS.
Operational IDf to Loc for fast mobility with low latency is handled
by HIP-RVS [RFC8005] and specific HIP Mobility Notification messaging
[RFC8046].
5.3. NVO3 WG
The NV03 WG has been working on a mapping of VN names to VN IDs in
the network virtualization space and their requirements differ from
the wireless broadband requirements and cross-silo communications
that have been mentioned in this document.
6. Companion Documents
There are three companion documents:
o Use Cases for Identity Enabled Networks [IDEAS-USE]
o Requirements for Generic Identity Services in Identity Enabled
Networks [IDEAS-REQ]
o Identity Use Cases in IDEAS [IDEAS-IDY]
o Gap Analysis for Identity Enabled Networks [IDEAS-GAP]
7. Security Considerations
Due to the sensitivity of IDy tied to IDf and LOC, there is a need to
pay attention to security ramifications. In particular, the security
goals should include confidentiality, possible encryption for
integrity of sensitive data and privacy.
8. IANA Considerations
This document has no actions for IANA.
Pillay-Esnault, et al. Expires January 4, 2018 [Page 9]
Internet-Draft July 2017
9. Contributors
The following individuals (by first name alphabetical order) have
contributed to this document:
o Albert Cabellos
o Alex Clemm
o Dino Farinacci
o Georgios Karagiannis
o Jim Guichard
o Michael Menth
o Robert Moskowitz
o Tom Herbert
o Uma Chunduri
This present document is based on an extract of the first version of
the draft. The authors and their affiliations on the original
document are: D. Farinacci (lispers.net), D. Meyer (Brocade), D.
Lake (Cisco Systems), T. Herbert (Facebook), M. Menth (University
of Tuebingen), Dipenkar Raychaudhuri (Rutgers University) and Julius
Mueller (ATT).
10. Acknowledgments
The authors would like to thank Stewart Bryant, David Lake, Bingyang
Liu, Dave Meyer, Dipenkar Raychaudhuri, Yingzhen Qu, and Onur Ozan
Koyluoglu for their review and input on this document. The authors
would like to thank Jean-Michel Esnault, Renwei Li, Lin Han, Kiran
Makhijani Erik Nordmark, Burjiz Pithawala, and Jeff Tansura who
participated in numerous discussions.
This document was produced using Marshall Rose's xml2rfc tool.
11. Informative References
[IDEAS-GAP]
Qu, Y., Cabellos, A., Moskowitz, R., Liu, B., and A.
Stockmayer, "Identity Use Cases in IDEAS", July 2017,
<https://tools.ietf.org/html/draft-xyz-ideas-gap-analysis-
00/>.
Pillay-Esnault, et al. Expires January 4, 2018 [Page 10]
Internet-Draft July 2017
[IDEAS-IDY]
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-REQ]
Pillay-Esnault, P., Clemm, A., Farinacci, D., and D.
Meyer, "Requirements for Generic Resilient Identity
Services in Identity Enabled Networks", March 2017,
<https://datatracker.ietf.org/doc/draft-padma-ideas-req-
grids/>.
[IDEAS-USE]
Pillay-Esnault, P., Farinacci, D., Herbert, T., Jacquenet,
C., Lake, D., Menth, M., Meyer, D., and D. Raychaudhuri,
"Use Cases for Identity Enabled Networks", March 2017,
<https://datatracker.ietf.org/doc/draft-padma-ideas-use-
cases-00/>.
[ILA] Herbert, T., "Identifier-locator addressing for network
virtualization", March 2016,
<https://datatracker.ietf.org/doc/draft-herbert-
nvo3-ila/>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>.
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
October 2016, <http://www.rfc-editor.org/info/rfc8005>.
[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility
with the Host Identity Protocol", RFC 8046,
DOI 10.17487/RFC8046, February 2017,
<http://www.rfc-editor.org/info/rfc8046>.
Authors' Addresses
Pillay-Esnault, et al. Expires January 4, 2018 [Page 11]
Internet-Draft July 2017
Padma Pillay-Esnault (editor)
Huawei
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: padma.ietf@gmail.com
Mohamed Boucadair
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Giuseppe Fioccola
Telecom Italia
Email: giuseppe.fioccola@telecomitalia.it
Christian Jacquenet
Orange
Rennes 35000
France
Email: christian.jacquenet@orange.com
Axel Nennker
Deutsche Telekom
Email: Axel.Nennker@telekom.de
Pillay-Esnault, et al. Expires January 4, 2018 [Page 12]