RFC 9962: A Decentralized Locator/ID Separation Protocol Mapping System (LISP-Decent)

Abstract

This document describes how the Locator/ID Separation Protocol (LISP) Mapping System can be distributed for scale and decentralized for management, while maintaining trust among data plane nodes. This is an Informational RFC and should be used by LISP-Decent implementations to interoperate with each other.¶

1. Introduction

The LISP architecture [RFC9300] introduces two new numbering spaces that are intended to provide overlay network functionality: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). To map from EIDs to a set of RLOCs, a control plane Mapping System is used [RFC6836] [RFC8111]. These Mapping Systems are naturally distributed in their deployment for scalability but are centrally managed by a third-party entity, namely a Mapping System Provider (MSP). The entities that use the Mapping System, such as data plane LISP Tunnel Routers (xTRs), depend on and trust the MSP. They do not participate in the Mapping System other than to register and retrieve information [RFC9301].¶

This document introduces a Decentralized Mapping System (DMS) so the xTRs can participate in the Mapping System as well as use it. They can trust each other rather than rely on third-party infrastructure. The xTRs act as Map-Servers to maintain distributed state for scale and reduce the attack surface. The trust relationships between the xTRs are established through authentication and authorization procedures in [RFC9301] and [ECDSA-AUTH].¶

This design was first introduced to the LISP Working Group (WG) in January of 2018. It was presented in London in March 2018 [IETF101-PRESO] and in Prague in March 2019 [IETF104-PRESO]. This Informational document is not a standard and did not reach community consensus to make it an IETF LISP WG document.¶

The intended audience for this specification are protocol development engineers who would implement this specification in products as well network engineers who deploy the technology in operational environments.¶

This design does not conflict with those designs or contradicts any other LISP design principles produced by the working group. This solution makes no fundamental LISP changes and adheres to the specifications documented in [RFC9301].¶

By the nature of this work, this document uses IP addresses as examples. They should not be copied or used outside of a lab environment. Deployments should use addresses appropriate for their environment.¶

2. Definitions of Terms

Mapping System Provider (MSP):

Infrastructure service that deploys LISP Map-Resolvers and Map-Servers [RFC9301] and possibly LISP-ALT nodes [RFC6836] or LISP-DDT nodes [RFC8111]. ALT-nodes and DDT-nodes use different algorithms for connecting Map-Resolvers and Map-Servers together. The MSP can be managed by a separate organization other than the one that manages xTRs. This model provides a business separation between the organization that manages (and is responsible for) the control plane versus the organization that manages the data plane overlay service.¶

Decentralized Mapping System (DMS):

A mapping system entity that is managed by the xTR nodes that use it and not third-party nodes/operators. The xTRs themselves are part of the Mapping System. The state of the Mapping System is fully distributed across xTRs, decentralized, and the trust relies on the xTRs that use and participate in their own mapping system.¶

Decent-Pull-Based Mapping System:

The mapping system is pull-based, meaning that xTRs will look up and register mappings by algorithmic transformation to locate which Map-Resolvers and Map-Servers are used. It is required that the lookup and registration uses a consistent algorithmic transformation function. Map-Registers are sent to specific Map-Servers. Map-Requests are considered external lookups when sent to Map-Resolvers on xTRs that do not participate in the mapping system and the Map-Requests are considered internal lookups when they are sent to Map-Resolvers on xTRs that do participate in the mapping system.¶

Modulus Value:

This value is used in the Pull-based Mapping System. It defines the number of Map-Server sets used for the Mapping System. The modulus value is used to produce a Name Index used for a Domain Name System (DNS) lookup. The Modulus Value is chosen based on the horizontal scale-out width of the Map-Server cluster the network operator chooses to deploy.¶

Name Index:

This index value <index> is used in the Pull-based Mapping System. For a Mapping System that is configured with a Map-Server set of DNS names in the form of <name>.example.com, the Name Index is prepended to <name> to form the lookup name <index>.<name>.example.com. If the Modulus Value is 8, then the Name Indexes are 0 through 7.¶

Hash Mask:

The Hash Mask is used in the Pull-based Mapping System. It is a mask value with 1 bit left justified. The mask is used to select what high-order bits of an EID-prefix are used in the hash function.¶

Decent-Push-Based Mapping System:

The Mapping System is push-based, meaning that xTRs will push registrations via IP multicast to a group of Map-Servers and do local lookups acting as their own Map-Resolvers.¶

Replication List Entry (RLE):

An RLOC-record format that contains a list of RLOCs that an Ingress Tunnel Router (ITR) replicates multicast packets on a multicast overlay. The RLE format is specified in [RFC8060]. RLEs are used with the Decent-Push-based Mapping System.¶

Group Address EID:

An EID-record format that contains IPv4 (0.0.0.0/0, G) or IPv6 (0::/0, G) state. This state is encoded as a Multicast Info Type LISP Canonical Address Format (LCAF) specified in [RFC8060]. Members of a seed-group send Map-Registers for (0.0.0.0/0, G) or (0::/0, G) with an RLOC-record that RLE encodes its RLOC address. Details are specified in [RFC8378].¶

Seed-Group:

A set of Map-Servers joined to a multicast group for the Decent-Push-based Mapping System or are mapped by DNS names in a Pull-based Mapping System. A core seed-group is used to bootstrap a set of LISP-Decent xTRs so they can learn about each other and use each other's Mapping System service. A seed-group can be pull-based to bootstrap the Decent-Push-based Mapping System. That is, a set of DNS mapped Map-Servers can be used to join the mapping system's IP multicast group.¶

3. Overview

The clients of the DMS are also the providers of mapping state, see [RFC9301] for formal details. Clients are typically Egress Tunnel Routers (ETRs) that Map-Register EID-to-RLOC mapping state to the mapping database system. ITRs are clients in that they send Map-Requests to the mapping database system to obtain EID-to-RLOC mappings that are cached for data plane use. When xTRs participate in a DMS, they are also acting as Map-Resolvers and Map-Servers using the protocol machinery defined in LISP control plane specifications [RFC9301], [RFC9303], and [ECDSA-AUTH]. The xTRs are not required to run the database mapping transport system protocols specified in [RFC6836] or [RFC8111].¶

This document will describe two decentralized and distributed mapping system mechanisms. A Decent-Push-based Mapping System uses IP multicast so xTRs can find each other by locally joining an IP multicast group. A Decent-Pull-based Mapping System uses DNS with an algorithmic transformation function so xTRs can find each other.¶

The document proposes two approaches to provide state/bandwidth, ease of configurability, and robustness/complexity trade-offs. When the Decent-Push-based approach is used, there is less messaging involved. xTRs can multicast a single Map-Register message that goes to all Map-Servers joined to the multicast group. When Map-Servers are added to or removed from the Map-Server cluster group, the Mapping System updates quickly with little human intervention. In the push model, all mapping state is stored in all Map-Servers so there is robustness achieved through redundancy. However, this requires a multicast underlay in nodes between all xTRs and Map-Servers. When a multicast underlay is not available, the Decent-Pull-based approach can be used with the help of the DNS. This approach uses less state overall among the Map-Servers (they each have different Mapping System state) and the ITRs know which Map-Server to ask by using the hashing techniques described later in this document.¶

This document does not describe any compatibility with other mapping systems. The design is intentional so that all xTRs and Map-Servers support this specification. Moreover, all xTRs and Map-Servers MUST support either the pull-based or push-based algorithms. They cannot be mixed. When both are used, they are completely discrete Mapping Systems just like they would be using one of the LISP WG Mapping System designs. An implementation can decide to implement only the pull-based approach or the push-based approach and still be compliant with this specification.¶

4. Decent-Push-Based Mapping System

The xTRs are organized in a mapping-system group. The group is identified by an IPv4 or IPv6 multicast group address or using a Decent-Pull-based approach described in Section 5. When using multicast, the xTRs join the same multicast group and receive LISP control plane messages addressed to the group. Messages sent to the multicast group are distributed when the underlay network supports IP multicast [RFC6831] or via the overlay multicast mechanism described in [RFC8378]. When overlay multicast is used and LISP Map-Register messages are sent to the group, they are LISP data encapsulated with an instance-ID set to 0xffffff in the LISP header. The inner header of the encapsulated packet has the destination address set to the multicast group address and the outer header that is prepended has the destination address set to the RLOC of Mapping System group member. The members of the Mapping System group are kept in the LISP data plane map-cache so packets for the group can be replicated to each member RLOC.¶

All xTRs in a Mapping System group will store the same registered mappings and maintain the state as Map-Servers normally do. The members are not only receivers of the multicast group, but they also send packets to the group.¶

                        xTR1
 Map-Request    +--------------------+
(always local)  |  +-----+  +-----+  |
   +---------------| ITR |  | ETR |-------------+
   |            |  +-----+  +-----+  |          |
   |            |                    |          |  Map-Register to
   |            |      +-------+     |          |  EID 233.252.1.1
   +------------------>| MR/MS |<---------------+  encapsulated to
                |      +-------+     |          | RLOCs xTR1, xTR2,
                +--------------------+          |     and xTR3
                                                |
                           +--------------------+------------+
                           |                                 |
                           |                                 |
                +----------v---------+            +----------v---------+
                |     +--------+     |            |     +--------+     |
                |     |  MR/MS |     |            |     |  MR/MS |     |
                |     +--------+     |            |     +--------+     |
                |  +-----+  +-----+  |            |  +-----+  +-----+  |
                |  | ITR |  | ETR |  |            |  | ITR |  | ETR |  |
                |  +-----+  +-----+  |            |  +-----+  +-----+  |
                +--------------------+            +--------------------+
                         xTR2                              xTR3

           ____________                 -----------
          /   core     \  233.252.2.2  /  layer-1  \
         | seed-group   | ----------> |      I      |
         |  233.252.1.1 |             |     / \     |
          \____________/              |    J---K    |
               |                       \___________/
               | 233.252.3.3
               |
               v
           ---------
          / layer-2 \
         |     X     |
         |    / \    |
         |   Y---Z   |
          \_________/

Configured in xTRs A, B, and C (they make up the core seed-group):
  233.252.1.1 -> RLE: A, B, C

core seed-group DMS, mapping state in A, B, and C:
  233.252.2.2 -> RLE: I, J, K
  233.252.3.3 -> RLE: X, Y, Z

layer-1 seed-group DMS (inter-continental), mapping state in I, J, K:
   EID1 -> RLOCs: i(1), j(2)
   ...
   EIDn -> RLOCs: i(n), j(n)

layer-2 seed-group DMS (intra-continental), mapping sate in X, Y, Z::
   EIDa -> RLOCs: x(1), y(2)
   ...
   EIDz -> RLOCs: x(n), y(n)

6. Security Considerations

Refer to Section 9 of [RFC9301] for a complete list of security mechanisms as well as pointers to threat analysis documents.¶

Where DNS is deployed for the Pull-based Mapping System, it is recommended to use DNSSEC [RFC9364] to add more security to the DNS lookup system.¶

Replay attacks, spoofing, and trust relationships are discussed in detail in [RFC9301] and [RFC9303].¶

7. IANA Considerations

This document has no IANA actions.¶

8. References

Acknowledgments

The authors would like to thank the LISP WG for their review and acceptance of this draft.¶

The authors would also like to give a special thanks to Roman Shaposhnik for several discussions that occurred before the initial draft of this document.¶

Eliot Lear and Victor Moreno are appreciated for their efforts proofreading the draft before publication as an RFC.¶