INTERNET-DRAFT                                                T. Herbert
Intended Status: Experimental                                 Quantonium
Expires: August 2018

                                                        February 3, 2018

                           Identifier groups


   This draft describes a means to create logical identifier groups to
   manage identifiers in a mapping system for identifier-locator
   protocols. An identifier group consists of identifiers that have
   similar properties in the context of the mapping system. Identifier
   groups facilitate bulk operations on the mapping system that would
   affect multiple identifiers. A primary use case for this is to
   facilitate mobility of devices that are associated with possibly
   thousands or even millions of identifiers.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright and License Notice

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

T. Herbert               Expires August 7, 2018                 [Page 1]

INTERNET DRAFT         draft-herbert-idgroups-00

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( 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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Characteristics of identifiers  . . . . . . . . . . . . . . . .  3
     2.1 Identifier addresses . . . . . . . . . . . . . . . . . . . .  3
     2.2 Desired properties . . . . . . . . . . . . . . . . . . . . .  4
     2.2 Policy mechanisms for identifiers  . . . . . . . . . . . . .  4
   3  Structure of identifier groups  . . . . . . . . . . . . . . . .  5
   4  Interfaces  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1 Management interface . . . . . . . . . . . . . . . . . . . .  7
     4.2 Query interface  . . . . . . . . . . . . . . . . . . . . . .  7
   5  Security Considerations . . . . . . . . . . . . . . . . . . . .  8
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1  Normative References  . . . . . . . . . . . . . . . . . . . 10
     7.2  Informative References  . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10

T. Herbert               Expires August 7, 2018                 [Page 2]

INTERNET DRAFT         draft-herbert-idgroups-00

1  Introduction

   This document describes identifier groups for identifier-locator
   mapping systems.

   Identifier-locator protocols include the concept of identifiers as a
   type of node addressing. Identifiers are logical endpoints of
   communications and only differ from canonical addresses in that they
   are not topological. A node may be assigned multiple ephemeral
   identifiers so that they be can used to create different source
   addresses for different communications to benefit privacy and
   anonymity. It is expected that individual end devices may have
   thousands of active ephemeral identifiers; a device that connects
   backend subnets could have millions of associated identifiers.

   An identifier-group is an group of identifiers within a mapping
   system that share some common properties. A grouping is arbitrary,
   the given application or mapping system may create identifier groups
   as needed. An identifier may belong to multiple groups, however when
   an operation is performed it must be clear as to which group
   applicable properties are be derived from. Groups may also be
   hierarchical such that groups may be members of other groups and thus
   inherit properties from their parent groups.

   A primary application of identifier groups is mobility where a device
   has a number of identifiers associated with it. When such a device
   moves in the network and is assigned a new locator, all of the
   identifiers associated with the device assume the new locator also.
   Identifier groups provide a level of indirection so that the locator
   can be set for all of the associated identifiers for the device in a
   single operation on the mapping system.

2  Characteristics of identifiers

   This section list some salient properties of identifiers that are
   relevant to a mapping system and privacy.

2.1 Identifier addresses

   Identifier addresses are full IP addresses that are either an
   identifier or contain an identifier as part of the address.
   Identifier addresses are used by endpoints to achieve communications.
   In order to reach the end host where the node indicated by an
   identifier resides, somewhere in the path an identifier-locator
   operation is performed and the packet is typically modified (either
   by encapsulation or address translation) to reach the correct node.
   At the destination node, a reverse operation is done to restore the
   originally sent packet before presenting the packet to the end node

T. Herbert               Expires August 7, 2018                 [Page 3]

INTERNET DRAFT         draft-herbert-idgroups-00

   or application.

   Identifier addresses should have the following properties:

2.2 Desired properties

      o They are composed of a global routing prefix and a suffix that
        is internal to an orgnization. This is the same property for IP
        addresses [RFC3513].

      o The registry and organization of an address can be determined by
        the network prefix. This is true for any global address.

      o The organizational bits in the address should have minimal
        hierarchy to prevent inferences. It might be reasonable to have
        an internal prefix that divides identifiers based on broad
        geographic regions, but detailed information such as location,
        department in an enterprise, or device type should not be
        encoded in a globally visible address.

      o Given two identifier addresses and no other information, the
        desired properties of correlating them are:

         o It can be inferred if they belong the same organization and
           registry. This is true for any two global IP addresses.

         o It may be inferred that they belong to the same broad
           grouping, such as a geographic region, if the information is
           encoded in the organizational bits of the address.

         o No other correlation can be established. For example, it
           cannot be inferred that the IP addresses address the same
           device, the IP addresses reside in the same subnet or
           department, or that the nodes for the two addresses have any
           geographic proximity to one another.

2.2 Policy mechanisms for identifiers

   Other than a globally routable network prefix, identifier addresses
   require no hierarchy since they are not topological. Therefore all or
   most of the organizational bits in a publicly visible address form a
   flat, non-hierarchical space. To create identifier addresses with the
   properties listed above, the bits in this space are pseudo-randomly
   assigned to form addresses.

   While the routing requirements are satisfied by the identifier-
   locator protocols and mapping system, the lack of internal hierarchy
   in addresses is a potential disruption for network deployments that

T. Herbert               Expires August 7, 2018                 [Page 4]

INTERNET DRAFT         draft-herbert-idgroups-00

   rely on address hierarchy to implement policy. For instance, an
   enterprise might implement a firewall rule base on destination
   network prefix that prevents the engineering department from talking
   to human resources.

   In order to apply such policies and still maintain the properties to
   prevent inference, a firewall could create rules based on identifier
   groups. So when a packet arrives at the firewall, the mapping system
   may be consulted and information for a group is returned. A policy
   decision, i.e. forward or drop, may be made per this information.

   In the example above, identifier groups might be created for
   engineering and human resources. The policy is expressed that members
   of the engineering group are not allowed to send to members human
   resources group. Since the groups are not encoded in the addresses
   there is no means for an external party to infer which packets belong
   to engineering and which belong to human resources. This is a privacy
   benefit compared to common method of encoding the department in the
   address hierarchy. An additional benefit is that such groupings are
   arbitrarily flexible and are not constrained by the need to format
   information into addresses (address prefixes for instance). Since the
   addresses don't contain group information, group membership can be
   changed for an address without requiring the node to change its

3  Structure of identifier groups

   Identifier groups can form a hierarchical structure within a mapping
   system domain. The diagram below illustrates a hierarchy containing
   two levels of groups and six identifier mapping entries at the
                                  |       |
                                  | Group |
                                  |       |
        +------------+          +-----+-----+          +------------+
        | Identifier |---+      |           |      +---| Identifier |
        +------------+   |  +---+---+   +---+---+  |   +------------+
        +------------+   |  |       |   |       |  |   +------------+
        | Identifier |---+--| Group |   | Group |--+---| Identifier |
        +------------+   |  |       |   |       |  |   +------------+
        +------------+   |  +-------+   +-------+  |   +------------+
        | Identifier |---+                         +---| Identifier |
        +------------+                                 +------------+

   The diagram below provides an explicit example of using an identifier

T. Herbert               Expires August 7, 2018                 [Page 5]

INTERNET DRAFT         draft-herbert-idgroups-00

   group hierarchy for mobility.

   In this scenario, we consider a bus has an onboard WIFI network.
   There are two UEs attached to the WIFI, where both have been assigned
   three identifiers.
                                 |  WIFI    |
                                 |  Bus     |
                                 |  Locator |
        +------------+           +-----+-----+            +------------+
        | Identifier |--+        |           |        +---| Identifier |
        +------------   |  +-----+---+   +---+-----+  |   +------------+
        +------------+  |  | UE      |   | UE      |  |   +------------+
        | Identifier |--+--| Locator |   | Locator |--+---| Identifier |
        +------------+  |  |         |   |         |  |   +------------+
        +------------+  |  +---------+   +---------+  |   +------------+
        | Identifier |--+                             +---| Identifier |
        +------------+                                    +------------+

   In this hierarchy, each UE has an associated group that contains all
   the identifiers for the UE. The WIFI device has an associated group
   that contains the groups for the attached UE devices. With this
   structure, each identifier has two locator mappings. The first one
   maps the identifier to the WIFI device in the bus. The second maps
   the identifier to the UE attached to the WIFI network.

   When a packet from an external network is sent to one of the
   identifiers, the mapping system is consulted to retrieve the top
   level locator to forward the packet. This locator will direct the
   packet to the WIFI router on the bus. At the bus WIFI router, the
   second level locator mapping for the identifier is consulted to
   determine the locator of the UE that has the identifier. The
   resultant locator is used to forward the packet to the appropriate UE
   device. At the UE, the identifier is used to deliver the packet to
   the appropriate application.

   As the bus moves through a mobile network, the locator for the WIFI
   changes so effectively the top level locator for all the identifiers
   for all the UEs within the bus also must be changed. Identifier
   groups allow this to be done in one operation on the mapping system.
   When passengers disembark and leave the range of the WIFI, the group
   membership of the UE is disassociated from the WIFI bus group. The UE
   may attach to another network so that the locator or group membership
   for the UE would be set appropriately.

   Note that in the above example, an identifier group hierarchy is used

T. Herbert               Expires August 7, 2018                 [Page 6]

INTERNET DRAFT         draft-herbert-idgroups-00

   to create a locator hierarchy. That is, multiple identifier locator
   operations are performed to get packets to destination. This is
   expected to be common in identifier-locator deployments. It is
   analogous to a packet going through a routing hierarchy where at each
   level the information applied became progressively more specific to
   the final destination (i.e. at each layer the prefix match is

4  Interfaces

   The mapping system interface is logically divided into the management
   interface and the query interface.

4.1 Management interface

   The management interface is used to create and manipulate mapping
   entries and identifier groups.

   The allowed operations on the management interface are:

      o Create groups

      o Set properties of a group, such as a locator or membership in
        another group in a group hierarchy

      o Change properties of a group

      o Create identifier mapping entries

      o Set identifier mapping properties such as locator or group

      o Change identifier mapping properties

      o Delete an identifier mapping entry

      o Remove all members from a group

      o Delete all identifier mappings in a group

      o Delete a group (that has no members)

   Note that there is no public interface defined that will return all
   the members of a group. This is intended to limit visibility to this
   sensitive information.

4.2 Query interface

T. Herbert               Expires August 7, 2018                 [Page 7]

INTERNET DRAFT         draft-herbert-idgroups-00

   The query interface is used by devices that require identifier to
   locator mappings. This interface is read-only.

   The basic operations in the query interface are:

      o Lookup locator for an identifier. In the case that a group
        hierarchy is present, the lookup request includes an indication
        as to which level in the hierarchy is applicable.

      o Lookup group information by group identifier. This is needed if
        the entry returned in a mapping entry indicates a group in a
        level of indirection. The internal structure for mapping entries
        which are members of the same group may reference a single group

      o Request notifications of mapping entry changes if the mapping
        system supports pub/sub model. This includes notifications that
        a group membership has changed.

      o Request notifications of group changes. For example, if the
        locator for an identifier group changes.

5  Security Considerations

   Access to mappings of group identifier to member identifiers MUST be
   strictly controlled. If this information is compromised, then privacy
   and anonymity of users could be undermined. In the case that the
   group identifiers refer to a single device, such as a UE in a mobile
   network, breach of the mapping from group identifier to identifiers
   may be sufficient to compromise individual user identities. Note that
   these concerns are not specific to identifier-locator mapping
   systems, but in any scenario where address assignment is done for

   The management interface should provide very strong authorization and
   employ encryption when communicating with the mapping system. The
   mapping system should enable security mechanisms associated with
   databases that contains sensitive information.

   The query interface is always read-only, however this should also
   have strong access authorization methods for security and privacy.

   A distributed identifier-locator mapping system should be deployed
   within a single administratively controlled domain. Low level
   information that potentially contains PII (Personally Identifiable
   Information) or specific location information should never be shared
   between administrative domains. It is conceivable that two networks
   could share a high level identifier-locator mapping system distinct

T. Herbert               Expires August 7, 2018                 [Page 8]

INTERNET DRAFT         draft-herbert-idgroups-00

   from their internal systems to support cross domain identifier-
   locator mappings. In this case, a locator hierarchy would be employed
   so as not to reveal any detailed information or PII. Specifically,
   identifier group information that refers specific devices and end
   locators for specific devices should not be visible.

T. Herbert               Expires August 7, 2018                 [Page 9]

INTERNET DRAFT         draft-herbert-idgroups-00

6  IANA Considerations

7  References

7.1  Normative References

7.2  Informative References

Author's Address

   Tom Herbert
   Santa Clara, CA


T. Herbert               Expires August 7, 2018                [Page 10]