INTERNET-DRAFT T. Herbert Intended Status: Experimental Quantonium Expires: August 2018 February 3, 2018 Identifier groups draft-herbert-idgroups-00 Abstract 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. 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 http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 address. 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 leaves. +-------+ | | | 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 longer). 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 membership 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 structure. 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 devices. 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 Quantonium Santa Clara, CA USA Email: tom@quantonium.net T. Herbert Expires August 7, 2018 [Page 10]