[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02                                                      
Network Working Group                                   U. Chunduri, Ed.
Internet-Draft                                                  A. Clemm
Intended status: Informational                                    Huawei
Expires: April 13, 2018                                         M. Menth
                                                 University of Tuebingen
                                                        October 10, 2017

                      Identity Use Cases in IDEAS


   IDentity-EnAbled networkS (IDEAS) introduce the concept of Identity
   (IDy) into networking.  An IDy represents a high-level identifier
   representing a collection of identifiers of a device, node, or
   process used for communication purposes.  It is used for
   authentication purposes and never revealed in data plane packets.
   This document summarizes some conceptual use cases to illustrate the
   usefulness of IDEAS.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC2119 [RFC2119].

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 https://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 April 13, 2018.

Chunduri, et al.         Expires April 13, 2018                 [Page 1]

Internet-Draft         Identity Use Cases in IDEAS          October 2017

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://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.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Uses for IDy  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  IDy in IDEAS  . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  IDy Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Unified Policies  . . . . . . . . . . . . . . . . . . . .   7
       5.2.1.  Access Restriction Policies . . . . . . . . . . . . .   7
     5.3.  Uses of Metadata  . . . . . . . . . . . . . . . . . . . .   8
     5.4.  Access Security and Manageability . . . . . . . . . . . .   8
     5.5.  Delay-Tolerant Networking (DTN) . . . . . . . . . . . . .   8
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   An Internet Protocol (IP) [RFC0791] address signifies both a
   Communications Entity's (Section 2) Location and its Identification.
   Location and Identification separation protocols, for example HIP
   [RFC7401] and LISP [RFC6830], introduced the concept of Identifier
   and separated this information from the Locator (IP address in this

   The Location/Identifier split separates Location and Identification
   function for a specific networking device, i.e., the Identifier
   denotes a device while the Locator denotes a routable network

Chunduri, et al.         Expires April 13, 2018                 [Page 2]

Internet-Draft         Identity Use Cases in IDEAS          October 2017

   interface.  With Location/Identifier split, multiple benefits in
   networking can be realized, e.g., in the areas of mobility, network
   virtualization, traffic engineering, security, software-defined
   networking, and others.

   IDEAS goes one step further and makes a distinction between IDy and
   Identifier, and introduces an IDy/Identifier split.  The abstraction
   of an IDy and the corresponding split from Identifiers can bring
   additional benefits that can be combined with Location/Identifier
   separation.  The abstraction applies at the network layer, like
   Locator/Identifier, and is not related to transport or application
   Identities.  Any use of identifiers in the data plane is governed by
   the respective ID/Locator protocols, such as LISP and HIP.

   An IDy serves as a collection of identifiers that are associated with
   the same endpoint.  It is used to identify and authenticate the
   communications entity, but not revealed in packet headers.  It is not
   to be confused with a personal identity, does not represent human-
   identifiable information, and does not imply an exclusive nor long-
   lived binding with an endpoint.  Its potential benefits are in the
   areas of privacy i.e., the ability to have multiple identifiers for
   the same communications entity which can be used for anonymous
   communication, access controls at the Mapping System (MS) to expose
   mapping information only to authorized requestors, and application of
   various policies uniformly across Identifiers pertaining to the same
   IDy.  IDy also enables easier and more efficient management of
   various aspects at the mapping system, as related Identifiers can be
   referred to in groups.

2.  Acronyms

          Communications Entity: A device, node, or software process
          used for IP-based (in some case Layer-2 based) data

          GRIDS: GeneRic Identity Services - a mapping and Identity
          services system that will be defined in the context of IDEAS.
          This goes beyond traditional mapping of Location/Identifier
          and can include Identity based services(e.g. policy/metadata/
          grouping service).

          HIP: Host Identity Protocol

          IDf: Identifier - denotes information to unambiguously
          identify a communications entity within a given scope.
          Examples HIP HIT [RFC7401] and LISP EID [RFC6830].  There is
          no constraint on the format, obfuscation or routability of an

Chunduri, et al.         Expires April 13, 2018                 [Page 3]

Internet-Draft         Identity Use Cases in IDEAS          October 2017

          IDy: Identity - an identifier for a communications entity that
          MAY be assigned by the GRIDS-provider and that is used by the
          provider to identify and authenticate the communications
          entity, but that is not revealed in the packet headers.

          LOC: Locator, for example, IPv4/IPv6 based

          LISP: The Locator/ID Separation Protocol

          Metadata: Metadata is network-related data about an IDy.  The
          metadata may contain information such as the type of the
          communications entity.

          MS: Traditional Mapping Server for LOC/IDf protocols (e.g.
          HIP RVS, LISP-DDT)

3.  Uses for IDy

   A communications entity can use multiple Identifiers for anonymous
   communication in the data plane [I-D.ietf-lisp-eid-anonymity] or for
   other reasons, for example to representing different locators
   simultaneously.  When multiple Identifiers are in use, the notion of
   Layer-3 IDy helps in the following ways.

   a.  IDy representing the communications entity enables authentication
       (AUTH) with the mapping and Identity services infrastructure.
       While it is possible to do AUTH on Identifiers those are NOT
       permanently associated to the communications entity.  Moreover,
       AUTH operation is a relatively expensive and inefficient
       procedure (compared to LOC resolution for example) and can cause
       excessive startup delays for many applications.

   b.  Data plane anonymization allows entities to communicate
       anonymously from the outside observers.  IDy provides de-
       anonymization for various data plane ephemeral Identifiers, if
       required, and enables resolution of which communications entity
       is behind these identifiers for legitimate users (entities itself
       in some cases).

   c.  IDy enables managing access restriction policies and metadata in
       simplified and more efficient manner.  An example of metadata is
       the type of communications entity, such as whether it is an IoT
       device, a connected vehicle, a server, an end user device.
       Managing the association between metadata or policy on the basis
       of IDy (that represents a collection of identifiers used by the
       communications entity) is greatly simplified and reduces the
       chances of error and inconsistencies compared to having to
       enumerate each identifier individually and having to update

Chunduri, et al.         Expires April 13, 2018                 [Page 4]

Internet-Draft         Identity Use Cases in IDEAS          October 2017

       policies and metadata whenever identifiers are changed.  It also
       allows certain policies (e.g. metadata-based policies) to be
       applied regardless of which of an IDy's Identifiers happens to be
       used in data plane communication by the communications entity.
       Without IDy, any access restrictions kept on Identifiers would be
       easily defeated if the peer communications entity simply changes
       the Identifier.

   The above requirements for having a stable network layer IDy is
   further detailed in Section 5.  Section 5 also shows how another
   abstraction of IDy from Identifiers help to enable various services
   in the data communication with in IDEAS.

4.  IDy in IDEAS

   An IDy identifies a Communications Entity.  IDy MAY be unicoded or an
   ASCII string, which MAY have a partial structure (depends on the
   authentication method selected) and MAY be given by the provider of
   the IDy services.  Typically, an IDy SHOULD NOT be revealed
   unencrypted on the wire or shared with other entities to make IDy a
   private enclave.

   IDy is used for authentication of the Communications Entity and it
   MAY be represented by multiple Identifiers (IDf's) in the data plane.
   IDy can be seen as a 'first order Identifier' of a communications
   entity with certain properties (for example not used in data plane)
   and with certain additional attributes which are common to all
   Identifiers of a communications entity.  In that sense, an IDf can be
   seen as a 'second order identifier' that is anchored in, and refers
   to, a first-order identifier.

   Access to the [IDy, IDf] mapping information may be restricted to a
   defined set of communication entities.  Even when access is
   authorized, IDy information is not exposed directly but information
   about the collection of IDfs grouped under the same IDy.  For
   example, given an IDf, a requestor that is authorized to do so (for
   example, a communications peer) may look up a designated well-known
   IDf that belongs to the same communications entity.  Likewise, using
   the mapping, given an IDf, policies and metadata associated with
   IDf's IDy can be accessed.  These communication patterns leverage
   GeneRic ID Services (GRIDS), in which locator/identifier mappings are
   maintained along with IDf, IDy, and locator associations, and which
   provide various services associated with those mappings.  In the
   following (Section 5) various IDy use cases point out benefits of IDy
   in IDEAS.

   The following diagram Figure 1 illustrates a simplified relation of
   Identity , Identifier, and Locator [IDy, IDf, LOC].

Chunduri, et al.         Expires April 13, 2018                 [Page 5]

Internet-Draft         Identity Use Cases in IDEAS          October 2017

     | Identity (IDy)       | Policy           | Metadata |   MI     |
              |                     |                    |
              V                     V                    V
     +------------------------+ +--------------+   +-------------------+
     |Identifier(IDf)-1 | LOC1| | IDf-2 | LOC2 |...| IDf-n| LOC1..LOCm |
     |(long-lived)            | | (ephemeral)  |   |                   |
     +------------------------+ +--------------+   +-------------------+

          MI -  Management and Security Information

           Figure 1: Identity, Identifier, Locator Relationship

5.  IDy Use Cases

   The uses for the IDy concept can be described by a few simple use
   cases, as specified below.

5.1.  Privacy

   To communicate with a device on a network, a LOC is needed.  In
   current [IDf, LOC] protocols, a Mapping Server (MS) stores the
   [IDf,LOC] mapping.  The resolution request or lookup of an IDf to the
   MS will return the LOC.

   Generally, a communications entity with a certain IDy may use various
   Identifiers for communication.  Only the Identifier is visible on the
   wire.  Changing the IDf frequently makes it hard to track the
   communications entity by outside observers and thus improves privacy
   of the communication entities.

   While it may be desirable to change the IDf every now and then for
   privacy purposes, the notion of IDy in addition to IDf can be
   important for several reasons.  For example, it allows to apply the
   same policy for a communications entity of a given IDy regardless
   which of IDfs that are associated with the IDy are used.  It allows
   senders to use anonymized and fast-changing identifiers over the wire
   that make tracking difficult, while still allowing a receiver to look
   up a known or long-lived identifier or metadata of the same
   communications entity, if authorized by the sender.

   It should be noted that a communications entity will never be allowed
   to look up another communication entity's IDy.  However, depending on
   authorization policy, it may be able to look up another IDf that is
   designated as a "well known" IDf and associated with the same IDy.

Chunduri, et al.         Expires April 13, 2018                 [Page 6]

Internet-Draft         Identity Use Cases in IDEAS          October 2017

   This allows a communications entity to reveal "who it is" to the
   receiver if it chooses to do so, while obfuscating this information
   to observers.

5.2.  Unified Policies

   Networks today treat traffic differently depending on properties such
   as source or destination.  E.g., certain traffic may access the
   network directly, other traffic may need to pass a firewall, or other
   traffic is entirely blocked.  Likewise, some traffic may be treated
   with different Quality of Service.

   Similarly, the use of alternative IDfs for the same system may allow
   for different treatment of traffic for the same system depending on
   how the system is referred to, whereas in other cases, the same
   policy should be applied regardless which of a set of IDfs (related
   through a common IDy) is used.  This can be leveraged by combining
   the enforcement of network policies with policies that guide
   selective mapping responses.  E.g., some requesting groups may
   receive an empty response from GRIDS Infrastructure for IDfs
   referring to a certain IDy, others receive an IDf resulting in strict
   security treatment of future traffic, and trusted groups receive an
   IDf resulting in rather loose security treatment.

5.2.1.  Access Restriction Policies

   A communications entity may define that it wants to communicate only
   with certain other entities.  To achieve this, a communications
   entity MAY define a rule regarding who can request and obtain its
   IDf.  The GRIDS Infrastructure will send a negative or empty response
   when it detects that the combination of resolution query and its
   initiator does not pass the rule validation test.  One example of
   this policy is, restriction of LOC resolution and hence allowing data
   traffic from only from the dealer/manufacturer of a vehicular node.

   Moreover, network-based access control may filter based on IDfs which
   are visible in the traffic, but this can be done simply through an
   association related to the IDy, which allows to check (proper
   authorization assumed) whether an IDf is associated with the same IDy
   as another, well-known IDf.  (The IDy itself is never revealed.)  By
   basing access control on the notion of IDy, respectively an IDy's
   collection of IDfs, enforcement and maintainability of access control
   rules is greatly simplified as there is no need to track IDf changes
   or the introduction of new IDfs for the same IDy.

Chunduri, et al.         Expires April 13, 2018                 [Page 7]

Internet-Draft         Identity Use Cases in IDEAS          October 2017

5.3.  Uses of Metadata

   The GRIDS Infrastructure is envisioned to store Metadata (Section 2)
   and provide some search functionality.  The GRIDS Infrastructure with
   may be a means to find a set of communications entities with certain
   associated metadata, provided that they have agreed to be searchable
   (allow discovery of a designated well-known IDf).  E.g., it may be
   possible to find out current well-known IDfs of a set of deployed
   devices of particular type.  This allows to locate them via [IDf,
   LOC] mappings and possibly manage them.

   IDy also allows to have associated metadata applied, regardless of
   which IDf is used to refer to the communications entity.  This
   association makes the management of metadata easier, because it does
   not need to be maintained separately and redundantly for every IDf.

5.4.  Access Security and Manageability

   As secure registration between a commmunications entity and GRIDS
   would be an expensive operation, this SHOULD be restricted to IDy and
   (ephemeral) IDfs can be generated and can be given rather securely
   using the same secure channel.

   IDy allows separation of lifecycle of IDy to be different from
   Identifiers, which enables to extend the "right-to-be-forgotten"
   concerning personal data to network identifier data, if required.
   There are various possible scenarios on why a long-lived IDfs by a
   communications entity has to be withdrawn.  Common cases involved
   lost/stolen device or misused Identifiers for example.

5.5.  Delay-Tolerant Networking (DTN)

   Entities may be only temporarily reachable.  When they are not
   reachable, proxies may be used to receive their traffic.  To that
   end, using an IDy, a communications entity MAY register one of the
   IDfs of its proxy with the GRIDS Infrastructure that this node can,
   e.g., receive traffic for that node and later forward to it when the
   node is again online.  A major application field may be in the IoT
   with mobile and intermittently connected devices

6.  Acknowledgements

   Thanks to Padma Pillay-Esnault for so many conversations around IDy
   and its potential uses in IDEAS.  The authors would like to thank
   detailed reviews and suggestions from Dino Farinacci, Joel Halpern,
   Jeff Tantsura, Jim Guichard, Christian Huitema, Dave Meyers, Robert
   Moskowitz, Georgios Karagiannis, Liu Bingyang and Yangfei.  We also

Chunduri, et al.         Expires April 13, 2018                 [Page 8]

Internet-Draft         Identity Use Cases in IDEAS          October 2017

   acknowledge the constructive and useful feedback from the IDEAS BOF
   and mailing list.

7.  IANA Considerations

   This document has no actions for IANA.

8.  Security Considerations

   This document further abstracts IDy from the Identifier in current
   Identifier/Locator protocols.  This abstraction gives significant
   security benefits and enables networks to facilitate anonymization of
   communications on the wire and to allow communications entities to
   control access to their locator information, as specified in
   [I-D.padma-ideas-problem-statement].  The IDy concept and data stored
   in GRIDS are intended for routing and forwarding purposes only.  They
   are in no way indended and must not be used to store human-
   identifiable information, personal identifiers, and the like.  A
   separate threat analysis detailing security and privacy aspects of
   the IDy concept and data maintained in GRIDS will be done in a
   separate document under the IDEAS charter.

9.  References

9.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

9.2.  Informative References

              Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP
              EID Anonymity", draft-ietf-lisp-eid-anonymity-00 (work in
              progress), August 2017.

              Pillay-Esnault, P., Boucadair, M., Fioccola, G.,
              Jacquenet, C., and A. Nennker, "Problem Statement for
              Identity Enabled Networks", draft-padma-ideas-problem-
              statement-03 (work in progress), July 2017.

Chunduri, et al.         Expires April 13, 2018                 [Page 9]

Internet-Draft         Identity Use Cases in IDEAS          October 2017

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013,

   [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,

Authors' Addresses

   Uma Chunduri (editor)
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: uma.chunduri@huawei.com

   Alexander Clemm
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: ludwig@clemm.org

   Michael Menth
   University of Tuebingen

   Email: menth@uni-tuebingen.de

Chunduri, et al.         Expires April 13, 2018                [Page 10]