| Network Working Group | P. Pillay-Esnault, Ed. |
| Internet-Draft | Huawei |
| Intended status: Informational | D. Farinacci |
| Expires: January 4, 2018 | lispers.net |
| C. Jacquenet | |
| Orange | |
| U. Chunduri, Ed. | |
| Huawei | |
| T. Herbert | |
| Quantonium | |
| D. Lake | |
| Dell | |
| M. Menth | |
| U of Tuebingen | |
| D. Raychaudhuri | |
| Rutgers University | |
| D. Meyer | |
| July 3, 2017 |
Use Cases for Identity Enabled Networks
draft-padma-ideas-use-cases-01
This document describes few deployment use cases for Identity enabled networks using a GeneRic Identity Services infrastructure.
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 (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 (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.
The problem statement document for IDentity Enabled networkS (IDEAS) advocates a standardized Identity and mapping services infrastructure, secured access to that infrastructure with data integrity, different Identity(IDy) services and allowing for different Locator/Identifier data-plane solutions [IDEAS-PS].
This infrastructure is called GeneRic Identity Services (GRIDS). The GRIDS infrastructure (GRIDS-ARCH-TBD) is envisioned to support functionalities such as traditional mapping and resolution of Identifiers (IDfs), as well as secured Identity registration, subscription, privacy for Identity/Identifier data, discovery of Identifiers, updates to the system with data integrity. In addition, it is designed to allow flexible deployment with different scopes (local sub-domains/global).
This memo describes and focuses on few deployment use cases for Identity-based protocols that will benefit from such an infrastructure. The definition of and the need for Identity in IDEAS are described in a companion document [IDEAS-IDENTITY].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This document makes use of the terms that have been defined in the problem statement draft of IDEAS [IDEAS-PS]. They are included here for reader's convenience. In case of any discrepancies between the two drafts, the problem statement draft overrides.
There are several benefits of various Locator/Identifier separator protocols that they bring to IP networking. These include but not limited to mobility with session continuity, global routable address space reduction, traffic engineering to name a few. The goal of this section is not to re-list all those deployment use cases of existing IDf/LOC protocols but specify what and how IDEAS/GRIDS can enhance the existing use cases and solve new problems in different areas.
This section details specific deployment use cases of IDEAS based upon GRIDS infrastructure.
For privacy or security reasons, an entity may only want a designated list of authorized entities to look up its locators and access it. To this end, the entity can specify an access control list in the GRIDS and let the GRIDS enforce the access control when entering the locator resolution phase. For example, when Alice wants to communicate with Bob, she has to look for the Bob’s IDf in the GRIDS to get his locator. The GRIDS verifies Alice’s IDf and checks the IDf against Bob’s access control list. If Alice is authorized, the GRIDS returns Bob’s up-to-date locators; otherwise the GRIDS returns an error or a honeypot LOC to analyze further (Figure 1).
GRIDS
+---------------------+
set ACL | | lookup
+-------+ set LOC |---------------------| Alice +-----+
| Alice |-------->| Alice’s IDy| ACL |<-------| Bob |
+-------+ |---------------------| +-----+
| yes| no| | access ^ ^
| | | | denied | |
| | --|---------- |
| v | |
|---------------------| Alice’s LOC |
| Alice’s IDf| LOC |--------------
|---------------------|
| |
+---------------------+
Figure 1: Authorizing access to LOC information
An access restriction policy can also be possible at the GRIDS level for a group/class of devices identified through the metadata of the entity. A specific example is restricting access for location resolution of a vehicular entity except for the authorized manufacturer or dealers.
The GRIDS Infrastructure supports the ability to verify policies associated to an Identity through an Identifier used in the data plane. This reverse lookup provision can then trigger the execution of various actions (e.g., discarding traffic or redirecting) on the data plane nodes (routers/gateways/firewalls), according to the policies defined in IDEAS.
Receiver of the data traffic can also control anonymization through a specific policy specified by the GRIDS logic with its Identity. For example sender of the data traffic can be provided with one of the receiver's ephemeral Identifiers to use for communication, during LOC resolution response (here sender assumes to be doing LOC resolution through receiver's long-lived Identifier). Mechanisms like this can provide anonymization of the data traffic from eavesdroppers/outside observers.
IDf-based protocols currently rely upon a customized mapping infrastructure and they do not interoperate with each other. Therefore, it would be difficult to deploy multiple IDf-based protocols in the same network due to the overhead generated by the operation of various mapping functions or it is difficult to deploy a global scope with greater flexibility. Hence, only one ID protocol is usually deployed even though there exists the need to deploy specific solutions to address various contexts.
+------------------------------------------------------+ | +--------------------------------------------------+ | | | GRIDS | | | | +-------------+ +---------------+ +-----------+ | | | | |IDy | | IDf,Discovery,| | Other | | | | | |Registration | | Mapping | | ID-aware | | | | | |Lifecycle | | Resolution | | Services | | | | | +-------------+ +---------------+ +-----------+ | | | | | | | | Common Service Plane | | | +--------------------------------------------------+ | | ^ | | |CP | | | | | +--------------------------------------------------+ | | | Flexible Data Plane | | | | +--------+ +-----------+ +--------+ +----------+ | | | | | LISP | | ILA | | HIP | | New Svcs | | | | | |(Encap) | |(Translate)| |(Secure)| |(ID-Aware)| | | | | +--------+ +-----------+ +--------+ +----------+ | | | +--------------------------------------------------+ | +------------------------------------------------------+
Figure 2: The GRIDS Structure
The above diagram Figure 2 shows a unified mapping system, besides the legacy mapping and resolution services. Other services Identity can potentially bring to the IDf/LOC protocols (access restrictions for resolution, discovery with metadata or grouping services) are also supported by the mapping system. Access security and registration services improve overall security of the GRIDS as these can provide authentication of the entity through a singular Identity. This process can also establish the entity type through metadata which is needed for some of the IDy services.
Control Plane (CP) options i.e., usage of existing LOC/IDf protocols or a new GRIDS-CP or usage of both, to realize services provided by GRIDS is discussed in [IDEAS-PS].
The IoT landscape is comprised of a large variety of devices and protocols. IoT solutions cover a wide-range of protocols at varying stages of maturity, the latter may be at Layer-2/Layer-3 and usually within a single domain.
While the number of IoT use-cases is vast and diverse, there is a number of commonalities in network communications between classes of application. Some of the categories below can benefit from local GRIDS instance which can provide local authentication and security features.
Low-compute capability end devices generating small amounts of traffic with a long/short period, terminating on a central application service with no-loop/loop latency dependencies. These devices usually offload processing to a central service to which they connect. The central service may be an application hosting environment or a distributed/devolved solution (such as an Edge or FOG solution). In both cases, local GRIDS instances could be deployed for this functionality. Such devices will benefit from offloading the secure registration and access restriction policies placed at GRIDS.
Local GRIDS instance with standardized interfaces can also be deployed in enterprise networks to provide security and location based services. Here the policies applied on the Identity/Identifier can be more flexible with proprietary rules structure. These can be added on top of the minimal and standardized framework and interfaces to meet enterprise needs.
One of the key benefits of any ID-Based protocols is its ability to provide mobility. Decoupling Identifier from location provides inherent support for mobility with session continuity and hence this document doesn't describe basic mobility use case further. But it is important to note availability of a global GRIDS Infrastructure would enable such mobility for entities connected to various IP networks securely. Other key attributes such as mapping and ID services system scalability, support of low latency and secure query (GRIDS-ARCH-TBD) are some of the aspects which can determine the adoption and deployment of this essential service.
Some use cases specific to mobile networks, where the need for both Local and Global GRIDS are specified in the Appendix.
One of the services of the common mapping and ID services infrastructure is to allow discovery of the entities. Results of such discovery can be used to apply additional application services. Most of these services need secured and authenticated registration to the GRIDS (to verify for example the entity 'type' it is claiming) with an immutable and unique Identity [IDEAS-IDENTITY] by the GRIDS provider. Some of these use cases require geographical co-ordinates too be part of LOC. Examples:
Today, the cost of reestablishing both the session and any security association is prohibitive in real-time applications with mobility. The local and proximity services on the GRIDS could be leveraged to provide the session continuity and security features.
Furthermore, there are opportunities for a dynamic and adhoc network to be formed between groups of vehicles on the highway, and these networks should be able to quickly peer along the edge with different networks encountered during mobility. Essential components of publicly sharable Metadata associated with entity's IDy/IDf at GRIDS would enable these peerings. But the specifics of how this can be used (TBD) and can only be expanded after IDEAS architecture is evolved.
While access restriction policies can protect the entities from unwanted communication from unauthorized entities, how policy is specified, located and shared may cause new security threats. This aspect has to be considered during requirements and architecture.
This document has no actions for IANA.
The following individuals (by first name alphabetical order) have contributed to this document:
The authors would like to thank Kevin Smith, Alex Clemm and Yingzhen Qu for their review and input on this document.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [ASSET1] | , |
| [ASSET2] | , |
| [IDEAS-IDENTITY] | Chunduri, U., Clemm, A. and M. Menth, "Identity Use Cases in IDEAS", July 2017. |
| [IDEAS-PS] | Pillay-Esnault, P., Boucadair, M., Jacquenet, C., Fioccola, G. and A. Nennker, "Problem Statement for Identity Enabled Networks", March 2017. |
| [LISP-PRED] | Farinacci, D. and P. Pillay-Esnault, "LISP Predictive RLOCs", November 2016. |
This section contains few more use cases GRIDS or Identity can bring to IDEAS. Some of the use cases would be integrated based on the TBD architecture of IDEAS.
Whilst the term IoT encompasses a wide range of applications ranging from short, low data-rate communications through to latency-sensitive haptic control loops, the ability to reduce network overhead through the simplification and potential removal of addresses at specific points on the network has several benefits.
In a system generating small amounts of data, the relative size of the addressing which can be considered to be network operator overhead compared to the size of the data payload which is customer data can be very high to the point where the addressing and control data vastly outsizes the customer data. In a traditional IT network, this is not often the case; the address and management data is very-much smaller than the payload and is thus an acceptable tax on the overall communication. Small data IoT applications require a solution to address the imbalance which now exists between the payload and the overhead.
It is possible to imagine local services within a scope that require only a small ID within a scope and can communicate with a local GRIDS to resolve its mapping and location services if it is only communicating with local devices such as local networked sensors. Such an example could sensors be in a factory.
Trouble-shooting a complex, multi-layer network where data is handed from one encapsulation to another is complex. It is already seen in solutions such as SIP that having embedded naming structures vastly improves the ability to determine a data-path in a trouble-shooting instance. Similarly, an IDf-based solution would apply from the data producer to the consumer and can also be used to improve data-traceability thereby resulting in lower operational costs.
The presence of a GRIDS can improve on managing the data paths as they are stored in their mappings. Such improvement can be especially beneficial if GRIDS capabilities interact with a SDN-based computation logic, whose service-inferredpolicy-based decision making process may choose to redirect traffic onto alternate paths as a function of the nature of the service, the load status of the primary path, etc. Application of such dynamics can be critical for specific IoTservices, such as e-health services. Data analytics on the GRIDS may also be logging events for easier postmortem if there are issues.
A Mapping System can contribute to enforce a set of common policies for a given connectivity service by providing a global, consistent identification and resolution service to any participating device involved in the forwarding of the corresponding traffic.
For Seamless and global mobility of an entity, GRIDS can potentially offer various services that can include not only traditial mapping and resolution services based on Identifier, but protecting and honoring the entity's privacy restrictions on who can acces entity's LOC information for example.
Other services and Optimizations such as "late binding", in which identity of in-transit packets can be bound to a locator closer to the edge of the network to account for highly mobile vehicular scenarios can be further developed based on the GRIDS.
Figure 4 provides an example of the topology of a single mobile carrier network. The goal of this section is not to specify specific mobile technology arechitecture but represent the need for a standardized mapping and ID services solution, which are relevant in these domains.
UE.A, UE.B, and UE.C are devices connected to the mobile network and are themselves mobile. UE.A and UE.B are currently connected to base station Base1 and UE.C is currently connected to Base2. The base stations are connected to the radio access network (RAN) of the provider. The RAN is connected to the Internet through a transport network via providers core network (CN). Regardless of which mobile technology is used and CN is vritualized with separated control plane (5G) GRIDS instance can be deployed for all ID services.
Host1 Host1 and Host2 are hosts in the Internet that are communicating with the UEs. In this example we assume that ID functionality is handled within the network and is transparent to the UEs or hosts.
+-------+
| UE.A |-----+
+-------+ |
|
+-------+ +-----+ +-----+
| UE.B |--|Base1|-----+ __________ +--|Host1|
+-------+ +-----+ __|___ / \ | +-----+
/ \ +-----+ ( )--+
( RAN )--| CN |-- ( Internet )
\_______/ +-----+ ( )--+
+-----+ | \__________/ | +-----+
|Base2|------+ +--|Host2|
+-----+ +-----+
|
+-------+ |
| UE.C |-----+
+-------+
The role of the CN is to leverage the GRIDS, that maps destination addresses on ingress packets into the network to deliver packets to the destination. The GRIDS Infrastructure maintain a list of ID-to-LOC mappings. Hosts on the Internet only know the identifier of the mobile nodes. Depending on the dataplane solution packets forwarded from the Internet may be routed to a CN that is able to retrieve the mapping ID to the destination LOC to facilitate delivery.
Consider that Host1 sends a packet to UE.A. The destination address of the packet is the identifier address of UE.A. The packet is sent by Host1 and is forwarded across the Internet to the provider's network based on the identifier address. A CN receives the packet. The destination address of a packet (identifier) is looked up in the mapping table (local GRIDS). The return result is the LOC for UE.A. The CN modifies the packet so that the destination address is the LOC for UE.A (either by encapsulation or address translation). The packet is then forwarded to Base1. At Base1 the destination is changed back to the identifier address and forwarded to the UE.
In the case that two UEs need to communicate the process is similar. Consider that UE.A sends a packet to UE.C. Again, UE.A only knows the identifier address of UE.C. UE.A sends a packet into the network and it is forwarded to a CN. The CN maps the destination address of UE.C to its locator and forwards the packet to Base2 which translates the destination back to an identifier address.
In order to reduce latency and improve performance, a mapping cache may be implemented at or near the base stations. A mapping cache would maintain a subset of mappings in the network that are being used for communications by the attached UEs to other devices in the network. A protocol would be run between the base stations and CNs to populate and invalidate entries in the cache.
Now consider that UE.B changes locations so that it is now attached to Base2 (figure 5).
+-------+
| UE.A |-----+
+-------+ |
|
+-----+ +-----+
|Base1|----+ __________ +--|Host1|
+-----+ __|___ / \ | +-----+
| / \ +-----+ ( )--+
| ( RAN )--| CN |-- ( Internet )
V \_______/ +-----+ ( )--+
+-------+ +-----+ | \__________/ | +-----+
| UE.B |--|Base2|-----+ +--|Host2|
+-------+ +-----+ +-----+
|
+-------+ |
| UE.C |-----+
+-------+
The CNs are updated to reflect UE.B's new location. As updating location is not instantaneous across all the mapping gateways in the network, it is possible that a packet is forwarded to an old destination. Several possible solutions exist today:
Some of the above additional services can be done through local GRIDS instance in the control plane of the operator network, thus not needing any anchor based solution and avoid "Traditional Redirection" for example.
The role of GRIDS and applicability depends on the mobility scenarios specific to the mobile technology i.e., for intra RAN mobility local GRIDS instance can be used for an anchor free transport network. For seamless mobility across CN's of a same provider needs a global GRIDS Infrastructure as host can be located any where and the LOC of UE changes. This is one of the open issues of the current mobile networks.
Figure 8 presents a topology where UE.A, UE.B, and UE.C are connected to a subnet and the whole subnet may itself be mobile (for instance a Wi-Fi network on a bus). To treat the subnet as an aggregate devices, the subnet identification is reflected in the identifier address. A single mapping entry then could then represent this subnet where the identifier is the prefix for the subnet and the locator reflects the location of the subnet (Base1 in this case)
+------+
| UE.A |--+
+------+ |
+------+ | +-----+ +-----+
| UE.B |--+--|Base1|-----+ ________ +--|Host1|
+------+ | +-----+ __|___ / \ | +-----+
+------+ | / \ +-----+ ( )--+
| UE.C |--+ ( RAN )--| CN |-- ( Internet )
+------+ \_______/ +-----+ ( )--+
+-----+ | \________/ | +-----+
|Base2|-----+ +--|Host2|
+-----+ +-----+
When the subnet moves the mappings to the identifier, the prefix for the subnet is updated in the CNs (figure 9). Note that a UE could also move out of its subnet and attach to the network on its own, for instance a UE might switch from using Wi-Fi to using a mobile network. This will work if a specific mapping for UEs is allowed in the mapping database, and that mapping is preferred over the aggregate mapping since it has a longer identifier prefix.
| +-----+ +-----+
| |Base1|----+ ________ +--|Host1|
V +-----+ __|___ / \ | +-----+
+-------+ / \ +-----+ ( )--+
| UE.A |--+ ( RAN )--| CN |-- ( Internet )
+-------+ | \_______/ +-----+ ( )--+
+-------+ | +-----+ | \________/ | +-----+
| UE.B |--+--|Base2|-----+ +--|Host2|
+-------+ | +-----+ +-----+
+-------+ |
| UE.C |--+
+-------+
Similar to the case of a UE moving between carrier networks, a subnet can move between carrier networks if the networks share identifier locator mappings that include identifier prefixes. Also, subnet mobility can modify community management and therefore impact GRIDS service operation: if UE.A, UE.B, and UE.C have subscribed to different services where, for example, UE.A exchanges information with UE.B but not with UE.C, whereas, UE.C exchanges information with UE.B but not UE.A, the mobile subnet may support different “closed user groups” that may be serviced by different GRIDS. When the subnet moves, other GRIDS may be invoked to make sure communication within the said closed user groups is not disrupted.