RFC 9437
Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP)
RFC 9437: Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP) 💖
okay bestie, let's get into this one 🦋 It's a Standards Track doc from the IETF, so it's the real deal and not just vibes. It was written by A. Rodriguez-Natal (Cisco), V. Ermagan (Google), A. Cabellos (UPC/BarcelonaTech), S. Barkai (Nexar), and M. Boucadair (Orange). It's dated August 2023 and it's giving ISSN 2070-1721 energy 🎀 The title block doesn't say it obsoletes or updates anything, so this is a fresh extension and not a redo.
The whole point is adding Publish/Subscribe (PubSub) to the LISP control plane, so the Mapping System can tell routers about mapping changes instead of them just asking over and over 🔥
Abstract ✨
This document specifies an extension to the Locator/ID Separation Protocol (LISP) control plane to enable Publish/Subscribe (PubSub) operation.
Status of This Memo 🌸
This is an Internet Standards Track document, so it's officially approved. It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the IESG. More info on Internet Standards is in Section 2 of RFC 7841 💅
You can check status, errata, and feedback at https://www.rfc-editor.org/info/rfc9437.
Copyright Notice 🧚
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as of the publication date. Please read those carefully, bestie, because they cover your rights and restrictions. Code Components pulled from this doc must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🙈
Table of Contents 🍓
1. Introduction
1.1. Scope of Applicability
2. Terminology and Requirements Notation
3. Deployment Requirements
4. Map-Request PubSub Additions
5. Mapping Request Subscribe Procedures
6. Mapping Notification Publish Procedures
7. Security Considerations
7.1. Security Association between ITR and Map-Server
7.2. DDoS Attack Mitigation
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Sample PubSub Deployment Experiences
A.1. PubSub as a Monitoring Tool
A.2. Mitigating Negative Map-Cache Entries
A.3. Improved Mobility Latency
A.4. Enhanced Reachability with Dynamic Redistribution of
Prefixes
A.5. Better Serviceability
Acknowledgments
Contributors
Authors' Addresses1. Introduction 🦋
1.1. Scope of Applicability 💜
So, LISP splits IP addresses into two namespaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) 🌈 [RFC9300] and [RFC9301] cover the details. It uses a map-and-encapsulate (a.k.a., map-and-encap) approach that depends on two things: a Mapping System (basically a distributed database that stores and shares EID-RLOC mappings), and LISP Tunnel Routers (xTRs) that encapsulate and decapsulate data packets based on what those mappings say ✨
Ingress Tunnel Routers (ITRs), Re-encapsulating Tunnel Routers (RTRs), and Proxy Ingress Tunnel Routers (PITRs) grab EID-to-RLOC mapping info from the Mapping System by sending an explicit request message. Section 6.1 of [RFC9301] explains how Egress Tunnel Routers (ETRs) can tell ITRs/RTRs/PITRs about mapping changes 🎀 This doc adds the PubSub extension, which lets the Mapping System notify ITRs/RTRs/PITRs about mapping changes. When it's used, changes get notified faster and get managed in the Mapping System instead of at the LISP sites 🔥
Here's the general flow when an ITR/RTR/PITR wants to hear about mapping changes for a given EID-Prefix:
- The ITR/RTR/PITR builds a Map-Request for that EID-Prefix with the Notification-Requested bit (N-bit) set, and it also includes its xTR-ID and Site-ID 💅
- The Map-Request gets forwarded to one of the Map-Servers the EID-Prefix is registered with 🧚
- The Map-Server creates subscription state for the ITR/RTR/PITR on the EID-Prefix 🌸
- The Map-Server sends a Map-Notify to the ITR/RTR/PITR to confirm the subscription was created, then waits for an acknowledgement of the notification 🍓
- The ITR/RTR/PITR sends back a Map-Notify-Ack to acknowledge it successfully got the Map-Notify 🫶
- When the EID-Prefix's mapping changes, the Map-Server sends a Map-Notify to each ITR/RTR/PITR on the subscription list 😭
- Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the Map-Notify it received 💀
This operation gets repeated for every EID-Prefix the ITRs/RTRs/PITRs want to hear about. An ITR/RTR/PITR can set the N-bit for several EID-Prefixes in one Map-Request 👑 Also, the steps above only show the simplest scenario, and the doc covers the details for this and other scenarios later on 🙈
If you want sample flows to see PubSub in action, check out [FLOW-EXAMPLES] 🦋
1.1. Scope of Applicability 💅
Okay, now the scope part. The PubSub procedure here is meant for contexts with controlled access to the Map-Server. How a deployment controls that access is up to the deployment, so it's out of scope for this doc 🌈 But the Map-Resolvers and Map-Servers still need to be configured with the info required to make sure at least the following:
- Map-Resolvers MUST verify that an xTR is allowed to (1) set the N-bit to 1 and (2) use the xTR-ID, Site-ID, and ITR-RLOCs included in a Map-Request.
- Map-Servers MUST only accept subscription requests from Map-Resolvers that verify Map-Requests as previously described.
Okay bestie, those MUSTs are serious. Map-Resolvers have to check the xTR's permissions, and Map-Servers can only accept subscriptions from resolvers that did that check 💀
2. Terminology and Requirements Notation 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, just like here ✨
The document uses the terms defined in Section 3 of [RFC9300] 🧚
3. Deployment Requirements 🌸
Okay so, on top of the general assumptions and expectations [RFC9301] already makes for LISP deployments, this doc adds these deployment requirements:
- A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is assigned to each xTR 🍓
- Map-Servers are configured to proxy Map-Replying (i.e., they are solicited to generate and send Map-Reply messages) for the mappings they serve 🫶
- A security association (e.g., a PubSubKey) is required between the ITRs and the Map-Servers (see Section 7.1) 😭
If a requirement isn't met, a subscription can't be established, and the network just keeps running without this enhancement 💀 Configuring xTR-IDs and Site-IDs is out of scope here. If you want an example of how these identifiers get provisioned to LISP nodes, check out [LISP-YANG] 🙈
Part 1 of 5. More coming soon, bestie 🫶
4. Map-Request PubSub Additions ✨
Okay so, here's the updated Map-Request that makes PubSub possible 💅. This doc gives a new meaning to one of the reserved bits (see Section 8), so you'll see it in the diagram below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|R|I| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI n | ITR-RLOC Address n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |N| Reserved | EID mask-len | EID-Prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ xTR-ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Site-ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Map-Request with I-bit, N-bit, xTR-ID, and Site-IDHere's what's added to the Map-Request message from Section 5.2 of [RFC9301] 🎀:
xTR-ID bit (I-bit): This bit is set to 1 to say that the 128-bit xTR-ID and 64-bit Site-ID fields are there in the Map-Request message. For PubSub, an xTR MUST be configured with an xTR-ID and Site-ID, and it MUST set the I-bit to 1 and include its xTR-ID and Site-ID in the Map-Request messages it generates. If the I-bit is set but the Site-ID and/or xTR-ID are missing, a receiver can catch the error because, after processing that last EID-Record, there are no bytes left over from processing the message. In that case, the receiver SHOULD log a malformed Map-Request and MUST drop the message. 🙈
Notification-Requested bit (N-bit): The N-bit of an EID-Record is set to 1 to say that the xTR wants to be notified of updates for that EID-Prefix. 🔔
xTR-ID field: If the I-bit is set, this field gets added to the Map-Request message as shown in Figure 1, starting right after the final Record in the message (or the Map-Reply Record, if there is one). The xTR-ID is specified in Section 5.6 of [RFC9301].
Site-ID field: If the I-bit is set, this field gets added to the Map-Request message as shown in Figure 1, right after the xTR-ID field. The Site-ID is defined in Section 5.6 of [RFC9301].
5. Mapping Request Subscribe Procedures 🦋
So the xTR subscribes to changes for a given EID-Prefix by sending a Map-Request to the Mapping System with the N-bit set on the EID-Record. It builds the Map-Request following Section 5.3 of [RFC9301], and also does the following:
- The xTR MUST set the I-bit to 1 and append its xTR-ID and Site-ID to the Map-Request.
- The xTR MUST set the N-bit to 1 for the EID-Record it wants to subscribe to.
- If the xTR has a nonce associated with the EID-Prefix, it MUST use that nonce increased by one in the Map-Request. Otherwise, it generates a nonce as described in Section 5.2 of [RFC9301]. It is RECOMMENDED that the xTR use persistent storage to keep its nonce state. If the xTR doesn't have persistent storage and doesn't have a nonce associated with the EID-Prefix, it MUST reset the nonce using the procedure in Section 7.1, so it can successfully create a new security association with the Map-Server. 🔐
The Map-Request gets forwarded to the right Map-Server through the Mapping System. This document does not assume that a Map-Server is pre-assigned to handle the subscription state for a given xTR. The Map-Server that receives the Map-Request is the one responsible for notifying that specific xTR about future mapping changes for the subscribed mapping records. 💌
When the Map-Server gets the Map-Request, it processes it as described in Section 8.3 of [RFC9301]. On top of that, unless the xTR is using the procedure in Section 7.1 to create a new security association, the Map-Server MUST verify that the nonce in the Map-Request is greater than the stored nonce (if there is one) associated with the xTR-ID (and EID-Prefix, when that applies). Otherwise, the Map-Server MUST silently drop the Map-Request message and SHOULD log the event to record that a replay attack could have occurred. 🚨 Then, once it's processed, for the EID-Record with the N-bit set to 1, the Map-Server adds the xTR-ID from the Map-Request to the list of xTRs that have asked to be subscribed to that EID-Prefix.
If an xTR-ID is successfully added to the subscriber list for an EID-Prefix, the Map-Server MUST extract the nonce and ITR-RLOCs from the Map-Request and store the association between the EID-Prefix, xTR-ID, ITR-RLOCs, and nonce. Any state already present for the same xTR-ID regarding ITR-RLOCs and/or nonce MUST be overwritten. When the LISP deployment has a single Map-Server, that Map-Server can be configured to keep a single nonce per xTR-ID for all EID-Prefixes (when this option is used, it MUST be enabled at the Map-Server and at all xTRs). 🧩
If the xTR-ID gets added to the list, the Map-Server MUST send a Map-Notify message back to the xTR to acknowledge the successful subscription. The Map-Server builds that Map-Notify according to Sections 5.5 and 5.7 of [RFC9301], with these extra considerations:
- The Map-Server MUST use the nonce from the Map-Request as the nonce for the Map-Notify.
- The Map-Server MUST use its security association with the xTR (Section 7.1) to sign the authentication data of the Map-Notify. The xTR MUST use that security association to verify the received authentication data.
- The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs received in the Map-Request (which one is implementation specific).
Just a reminder: the initial transmission and retransmission of Map-Notify messages by a Map-Server follow the procedure in Section 5.7 of [RFC9301]. Some state changes can cause an overload that hits things like the outbound capacity of a Map-Server 😬. A similar problem can happen when a huge number of state entries get updated at the same time. To stop these kinds of meltdowns, Map-Servers SHOULD be configured with policies that control the maximum number of subscriptions and also the pace of Map-Notify messages. For example, the Map-Server might be told to limit the resources dedicated to unsolicited Map-Notify messages to a small fraction (e.g., less than 10%) of its overall processing and forwarding capacity. The exact details of such policies are deployment and implementation specific. Likewise, this document doesn't specify which notifications take precedence when these policies are enforced. ⚖️
When the xTR gets a Map-Notify with a nonce that matches one in its list of outstanding Map-Request messages sent with an N-bit set, it knows that the Map-Notify is acknowledging a successful subscription. The xTR processes this Map-Notify as described in Section 5.7 of [RFC9301], and MUST use the Map-Notify to populate its Map-Cache with the returned EID-Prefix and RLOC-set. As a reminder, following Section 5.7 of [RFC9301], the xTR has to send a Map-Notify-Ack back to the Map-Server. If the Map-Server doesn't receive the Map-Notify-Ack after exhausting the Map-Notify retransmissions described in Section 5.7 of [RFC9301], the Map-Server can remove the subscription state. If the Map-Server does remove the subscription state, and there's no explicit policy saying otherwise, it SHOULD notify the xTR by sending a single Map-Notify with the same nonce, but with Loc-Count = 0 (and Loc-AFI = 0) and ACT bits set to 5 "Drop/Auth-Failure". It is OPTIONAL for the xTR to update its Map-Cache entry for the EID-Prefix (if there is one) based on this Map-Notify. This message is especially useful when Map-Notifies are successfully received by an xTR, but the matching Map-Notify-Acks get lost on the way to the Map-Server. xTR implementations can use this signal to try to reinstall their subscription state instead of hanging onto stale mappings. 🔄
A subscription for an xTR-ID can fail for a bunch of reasons 😅. For example, it can fail because of local configuration policies (like accept and drop lists of subscribers), because the Map-Server has run out of resources to dedicate to subscriptions for that EID-Prefix (e.g., the number of subscribers is more than the Map-Server can handle), or because the xTR tried to establish a new security association (Section 7.1) and didn't succeed.
If the subscription request fails, the Map-Server sends a Map-Reply to the originator of the Map-Request, as described in Section 8.3 of [RFC9301], with these extra considerations:
- If the subscription request fails due to policy (e.g., for explicitly configured subscriptions, as described later in this section), the Map-Server MUST respond to the Map-Request with a Negative Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT bits set to 4 "Drop/Policy-Denied".
- If the subscription request fails due to authentication (e.g., when a new security association is being established, as described in Section 7.1), the Map-Server MUST respond to the Map-Request with a Negative Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT bits set to 5 "Drop/Auth-Failure".
- If the subscription request fails for any other reason, the Map-Server MUST follow Section 8.3 of [RFC9301] with no changes. 💜
okay so the xTR handles any Map-Reply or Negative Map-Reply the way Section 8.1 of [RFC9301] describes 💅, with a few extra vibes. If an xTR gets a Negative Map-Reply with ACT bits set to 4 "Drop/Policy-Denied" or 5 "Drop/Auth-Failure" as a response to a subscription request, it is OPTIONAL for the xTR to update its Map-Cache entry for the EID-Prefix (if any) 🦋. And if the subscription fails, for whatever reason, it's up to the xTR's implementation to try again 🔁
If the Map-Server gets a subscription request for an EID-Prefix that isn't in the mapping database, it SHOULD follow the same logic from Section 8.4 of [RFC9301] 🧚 and create a temporary subscription state for the xTR-ID. That state goes to the least specific prefix that matches the original query and doesn't match any EID-Prefix that exists in the LISP-capable infrastructure. Or, the Map-Server can decide the subscription request fails and send a Negative Map-Reply following Section 8.3 of [RFC9301]. Either way, the TTL of the temporary subscription state or the Negative Map-Reply SHOULD be configurable, and 15 minutes is RECOMMENDED ⏰
The subscription state can also be created explicitly through configuration at the Map-Server 🎀 (this is possible when a pre-shared security association exists, see Section 7). This happens using a bunch of methods that are outside the scope of this document. If there's no nonce that can be used for the explicit subscription state when the explicit subscription is configured (for example, from a different subscription already established with the same xTR when a single nonce is kept per xTR-ID), then both the xTR and Map-Server MUST be configured with the initial nonce 🔐. It is RECOMMENDED to have a configuration option that enables (or disables) the xTR to accept publication information for EID-Prefixes it didn't explicitly subscribe to 🌸. By default, the xTR is allowed to modify explicitly configured subscription state using the procedures in this section. However, this MAY be disabled at the Map-Server via configuration 🙈. If the Map-Server is set to not allow xTRs to modify explicitly configured subscriptions, and an xTR tries to do so anyway, this triggers a Negative Map-Reply with ACT bits set to 4 "Drop/Policy-Denied", as described earlier in this section 💀
Here's how removing a subscription works 🗑️
- If a valid Map-Request with the N-bit set to
1only has one ITR-RLOC withAFI = 0(i.e., Unknown Address), the Map-Server MUST remove the subscription state for that xTR-ID (unless this is disabled via configuration, see the previous paragraph) ✨ - If the subscription state is removed, the Map-Server MUST send a Map-Notify to the source RLOC of the Map-Request 📬
- If the subscription removal fails due to configuration, this triggers a Negative Map-Reply with ACT bits set to 4 "Drop/Policy-Denied" as described earlier in this section. In this case, the Map-Server sends the Negative Map-Reply to the source RLOC of the Map-Request 🙅♀️
- Removing subscription state at the Map-Server can lead to replay attacks 😭 To soften this, the Map-Server SHOULD keep the last nonce seen per xTR-ID (and EID-Prefix, when applicable) 🛡️
- If the Map-Server does not keep the last nonces seen, then the Map-Server MUST require the xTRs to subscribe using the procedure described in Section 7.1 to create a new security association with the Map-Server 🔑
If the Map-Server receives a Map-Request asking to remove a subscription for an EID-Prefix that has no subscription state for that xTR-ID, and the EID-Prefix is covered by a less-specific EID-Prefix that does have subscription state for that xTR-ID, the Map-Server SHOULD stop publishing updates about this more-specific EID-Prefix to that xTR. It stops until the xTR subscribes to the more-specific EID-Prefix 🦋. The same authentication, integrity protection, and nonce check considerations described in this section and Section 7 for Map-Requests that update subscription state also apply to Map-Requests that remove subscription state 🫶
When an EID-Prefix is removed from the Map-Server (either explicitly withdrawn or because its TTL expired), the Map-Server notifies its subscribers (if any) with a Map-Notify whose TTL is equal to 0 🌈
6. Mapping Notification Publish Procedures ✨
The publish procedure is done with Map-Notify messages that the Map-Server sends to xTRs 📨 The xTRs acknowledge receipt of Map-Notifies by sending Map-Notify-Ack messages back to the Map-Server 💌 Here's the full mechanism, bestie:
When a mapping stored in a Map-Server gets updated (for example, via a Map-Register from an ETR), the Map-Server MUST notify the subscribers of that mapping by sending Map-Notify messages with the most up-to-date mapping information 🔥 If subscription state exists in the Map-Server for a less-specific EID-Prefix and a more-specific EID-Prefix gets updated, the Map-Notify is sent with the more-specific EID-Prefix mapping to the subscribers of the less-specific EID-Prefix mapping 🪄 The Map-Notify message sent to each subscriber as a result of an update event follows the encoding and logic defined in Section 5.7 of [RFC9301] for Map-Notify, except for the following:
- The Map-Notify MUST be sent to one of the ITR-RLOCs associated with the xTR-ID of the subscriber (which one is implementation specific) 🎯
- The Map-Server increments the nonce by one every time it sends a Map-Notify as publication to an xTR-ID for a particular EID-Prefix ➕
- The Map-Server MUST use its security association with the xTR to compute the authentication data of the Map-Notify 🔐
When the xTR receives a Map-Notify with an EID that isn't local to the xTR, the xTR knows that the Map-Notify is updating an entry in its Map-Cache 🧠 The xTR MUST keep track of the last nonce seen in a Map-Notify received as a publication from the Map-Server for the EID-Prefix 📝 When the LISP deployment has a single Map-Server, the xTR can be configured to keep track of a single nonce for all EID-Prefixes (when used, this option MUST be enabled at the Map-Server and all xTRs) 🧩 If a Map-Notify received as a publication has a nonce value that is not greater than the saved nonce, the xTR drops the Map-Notify message and logs the fact that a replay attack could have occurred 🚨 The same considerations discussed in Section 5.6 of [RFC9301] regarding Map-Register nonces apply here for Map-Notify nonces 🤓
The xTR processes the received Map-Notify as specified in Section 5.7 of [RFC9301], with the following considerations:
- The xTR MUST use its security association with the Map-Server (Section 7.1) to validate the authentication data on the Map-Notify 🛂
- The xTR MUST use the mapping information carried in the Map-Notify to update its internal Map-Cache 🗺️
- If, after following Section 5.7 of [RFC9301] regarding retransmission of Map-Notify messages, the Map-Server has not received the Map-Notify-Ack, it can try sending the Map-Notify to a different ITR-RLOC for that xTR-ID 🔄
- If the Map-Server tries all the ITR-RLOCs without receiving a response, it may stop trying to send the Map-Notify 🫡
7. Security Considerations 🛡️
Generic security considerations related to LISP control messages are discussed in Section 9 of [RFC9301] 📚
In the particular case of PubSub, cache poisoning via malicious Map-Notify messages is avoided by using the nonce and the security association between the ITRs and the Map-Servers 🙅♀️ It's giving protection, periodt 💖
It is RECOMMENDED to follow the guidance from the last paragraph of Section 9 of [RFC9301] to ensure integrity protection of Map-Request messages (for example, to prevent xTR-ID hijacking) 👑
7.1. Security Association between ITR and Map-Server 🔐
Since Map-Notifies from the Map-Server to the ITR need to be authenticated, there's a need for a soft-state or hard-state security association (for example, a PubSubKey) between the ITRs and the Map-Servers 🧁 For some controlled deployments, it might be possible to have a shared PubSubKey (or set of keys) between the ITRs and the Map-Servers 🤝 However, if pre-shared keys aren't used in the deployment, LISP Security (LISP-SEC) [RFC9303] can be used as follows to create a security association between the ITR and the Map-Server 🌷
First, when the ITR sends a Map-Request with the N-bit set as described in Section 5, the ITR also performs the steps described in Section 6.4 of [RFC9303] 🎬 The ITR can then generate a PubSubKey by deriving a key from the One-Time Key (OTK) and the Map-Request's nonce, as follows: PubSubKey = KDF(OTK + nonce), where KDF is the Key Derivation Function indicated by the OTK Wrapping ID. If the OTK Wrapping ID equals NULL-KEY-WRAP-128, then the PubSubKey is the OTK 🧮 Note that, unlike the pre-shared PubSubKey, this generated PubSubKey is different for each EID-Prefix an ITR subscribes to (since the ITR uses a different OTK per Map-Request) 🌈
When the Map-Server receives the Map-Request, it follows the procedure specified in Section 5 with the following considerations: the Map-Server MUST verify that the OTK has not been used before 🕵️♀️ If the Map-Server verifies the OTK and cannot determine that the OTK has not been used before, the subscription request fails due to authentication. This triggers a Negative Map-Reply with ACT bits set to 5 "Drop/Auth-Failure", as described in Section 5 🙃 The xTR might try again with a different OTK after receiving this Negative Map-Reply 🔁 Note that a Map-Server implementation may decide not to keep track of all past OTKs and instead use some form of hash. In that case, hash collisions are handled as if the OTK has been reused. Such an implementation needs to balance the hash length with the rate of collisions expected for the particular deployment; this is implementation specific ⚖️ If the Map-Server has to reply with a Map-Reply for any other reason (for example, if PubSub is not supported or a subscription is not accepted), then it follows the normal LISP-SEC procedure described in Section 5.7 of [RFC9303]. No PubSubKey, security association, or subscription state is created when the Map-Server responds with any Map-Reply message 🙅♀️
Otherwise, if the Map-Server has to reply with a Map-Notify (for example, because the subscription was accepted) to a received Map-Request, the following extra steps take place 🎉
- The Map-Server extracts the OTK and the OTK Wrapping ID from the LISP-SEC Encapsulated Control Message (ECM) Authentication Data 🔍
- The Map-Server generates a PubSubKey by deriving a key from the OTK, as described before for the ITR. This is the same PubSubKey derived at the ITR that is used to establish a security association between the ITR and the Map-Server 🗝️
- The PubSubKey can now be used to sign and authenticate any Map-Notify between the Map-Server and the ITR for the subscribed EID-Prefix. This includes the Map-Notify sent as a confirmation to the subscription. When the ITR wants to update the security association for that Map-Server and EID-Prefix, it once again follows the procedure described in this section 💫
Note that if the Map-Server replies with a Map-Notify, none of the regular LISP-SEC steps regarding Map-Reply described in Section 5.7 of [RFC9303] occur 🧐
7.2. DDoS Attack Mitigation 🛡️💖
Okay bestie, let's talk about DDoS, because PubSub has some pretty solid defenses here 💅. If PubSub is deployed under the scope of applicability from Section 1.1, only known nodes can join the PubSub deployment 🔒. Attacks that replay messages from unknown nodes get shut down by the nonce and the security association between the ITRs and the Map-Servers 🙅♀️. The tricky part is misbehaving known nodes, who can flood a Map-Server with massive subscription requests and drain its resources 😭. Constantly flipping the state of a subscription counts as an attack vector too, so it's a whole vibe to watch for 👀.
To handle all of this, Section 5.3 of [RFC9301] covers rate-limiting Map-Requests, and Section 5.7 of [RFC9301] covers rate-limiting Map-Notifies 🚦. One thing to know: if the Map-Notify rate-limit threshold gets hit for a particular xTR-ID, the Map-Server will ignore any extra subscription requests from that xTR-ID 🙈. It then falls back to the behavior described in [RFC9301] when it gets a Map-Request from that xTR-ID, which means it sends a Map-Reply (i.e., the Map-Server will send a Map-Reply) ✨.
8. IANA Considerations 🎀
IANA assigned a brand new bit from the "LISP Control Plane Header Bits: Map-Request" registry, which lives in the "Locator/ID Separation Protocol (LISP) Parameters" group of registries [IANA-LISP] 🌸. Here's the lineup:
+===========+===============+==========+=============+===========+
| Spec Name | IANA Name | Bit | Description | Reference |
| | | Position | | |
+===========+===============+==========+=============+===========+
| I | Map-Request-I | 11 | xTR-ID Bit | RFC 9437 |
+-----------+---------------+----------+-------------+-----------+
Table 1: Addition to the Map-Request Header Bits RegistryIANA also made a new registry called "LISP Control Plane Header Bits: Map-Request-Record", tucked into that same "Locator/ID Separation Protocol (LISP) Parameters" group of registries [IANA-LISP] 🧚. Its starting content is in Table 2 👇.
+====+===============+========+========================+===========+
|Spec| IANA Name |Bit | Description | Reference |
|Name| |Position| | |
+====+===============+========+========================+===========+
|N | Map-Request-N |1 | Notification-Requested | RFC 9437 |
| | | | Bit | |
+----+---------------+--------+------------------------+-----------+
Table 2: Initial Content of LISP Control Plane Header Bits:
Map-Request-Record RegistryThe remaining bits (i.e., bit positions 2-8) are Unassigned 🫶.
New bits in this registry get allocated under the "Specification Required" policy (Section 4.6 of [RFC8126]) 📜. Requests get reviewed by one or more designated experts, and those experts should check whether the proposed registration duplicates anything that already exists and whether the description is detailed enough and actually fits what the registry is for 🔍. These checks sit on top of the ones in Section 4.6 of [RFC8126], such as the proposed registration "must be documented in a permanent and readily available public specification" 📚. The designated experts approve or deny the request and tell IANA what they decided. If they deny it, they should explain why and, where it makes sense, suggest how to make the request work 💡.
9. References 📚
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>.
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
Ed., "Locator/ID Separation Protocol (LISP) Control
Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/info/rfc9301>.
[RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
"Locator/ID Separation Protocol Security (LISP-SEC)",
RFC 9303, DOI 10.17487/RFC9303, October 2022,
<https://www.rfc-editor.org/info/rfc9303>.9.2. Informative References
[EID-MOBILITY]
Portoles, M., Ashtaputre, V., Maino, F., Moreno, V., and
D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified
Control Plane", Work in Progress, Internet-Draft, draft-
ietf-lisp-eid-mobility-12, 4 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
eid-mobility-12>.
[FLOW-EXAMPLES]
Boucadair, M., "LISP PubSub Flow Examples", Work in
Progress, Internet-Draft, draft-boucadair-lisp-pubsub-
flow-examples-03, 10 February 2023,
<https://datatracker.ietf.org/doc/html/draft-boucadair-
lisp-pubsub-flow-examples-03>.
[GB-ATN] Haindl, B., Lindner, M., Moreno, V., Portoles, M., Maino,
F., and B. Venkatachalapathy, "Ground-Based LISP for the
Aeronautical Telecommunications Network", Work in
Progress, Internet-Draft, draft-haindl-lisp-gb-atn-09, 27
March 2023, <https://datatracker.ietf.org/doc/html/draft-
haindl-lisp-gb-atn-09>.
[IANA-LISP]
IANA, "Locator/ID Separation Protocol (LISP) Parameters",
<https://www.iana.org/assignments/lisp-parameters/>.
[LISP-YANG]
Ermagan, V., Rodriguez-Natal, A., Coras, F., Moberg, C.,
Rahman, R., Cabellos, A., and F. Maino, "LISP YANG Model",
Work in Progress, Internet-Draft, draft-ietf-lisp-yang-19,
2 March 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-lisp-yang-19>.
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
Protocol Internet Groper (LIG)", RFC 6835,
DOI 10.17487/RFC6835, January 2013,
<https://www.rfc-editor.org/info/rfc6835>.
[UBERLAY] Moreno, V., Farinacci, D., Rodriguez-Natal, A., Portoles-
Comeras, M., Maino, F., and S. Hooda, "Uberlay
Interconnection of Multiple LISP overlays", Work in
Progress, Internet-Draft, draft-moreno-lisp-uberlay-06, 28
September 2022, <https://datatracker.ietf.org/doc/html/
draft-moreno-lisp-uberlay-06>.Appendix A. Sample PubSub Deployment Experiences 🌈
Some LISP production networks have been running different flavors of PubSub for a while now 🍓. The subsections below are a little inventory of experience lessons from those deployments 💜.
A.1. PubSub as a Monitoring Tool 👀
Some LISP deployments use PubSub to keep an eye on EID-Prefixes, especially EID-to-RLOC mappings 🔭. Some LISP implementations extended the LISP Internet Groper ('lig') [RFC6835] tool to use PubSub for this. The extension is meant to support an interactive mode in 'lig' and to request a subscription for the EID you care about 💖. If the RLOCs change, the Map-Server sends a notification, and then the 'lig' client shows that change to the user 🔔.
A.2. Mitigating Negative Map-Cache Entries 🧊
Section 8.1 of [RFC9301] suggests two TTL values for Negative Map-Replies: a 15-minute TTL if the EID-Prefix doesn't exist, or a 1-minute TTL if the prefix exists but hasn't been registered ⏰. Those numbers come from the original operational experience of the LISP protocol designers, but negative cache entries had two unintended effects that showed up in production 💀.
First, if an xTR keeps getting traffic for a negative EID destination (i.e., an EID-Prefix with no RLOCs associated with it), it tries to resolve that destination again as soon as the cached state expires, even when nothing has changed on the Map-Server 🔁. This was seen often in networks with a lot of traffic headed outside the LISP network. It can cause excessive resolution signaling, since the same state keeps getting fetched just because the cache expired 📶. PubSub relaxes those TTL values so negative mapping entries can be cached for longer, which stops unnecessary refreshes and cuts signaling way down in these scenarios 🙌. Basically, a TTL-based schema is a "polling mechanism" that creates more signaling, while PubSub is an "event-triggered mechanism" that costs some state 🧠.
Second, if the state really does change on the Map-Server, TTL-based updates can keep the xTR's cached state from updating until the TTL runs out 😤. This happened during configuration (or reconfiguration) periods, when EID-Prefixes that are no longer negative weren't getting traffic yet because stale Map-Cache entries were still sitting around the network 🌀. With PubSub turned on, stale caches can get updated as soon as the state changes ⚡.
A.3. Improved Mobility Latency 🏃♀️💨
Networks running PubSub saw better convergence time during mobility events than LISP networks running [RFC9301] alone 🚀. As described in Section 4.1.2.1 of [EID-MOBILITY], LISP can rely on data-driven Solicit-Map-Requests (SMRs) to make sure the network eventually converges 🔄. In general, PubSub converges faster for two reasons: (1) there's no need to wait for a data-triggered event, and (2) it produces less signaling than the SMR-based flow 🙌. One catch: when a Map-Server running PubSub has to update a large number of subscribers at once (i.e., when a popular mapping changes), SMR-based convergence may be faster for a small subset of subscribers, namely the ones who receive PubSub updates last 🐢. Deployment experience shows that data-driven SMRs and PubSub complement each other, and together they give you a fast, resilient network even when mobility events are happening 🦋.
Experience also showed that not every LISP entity on the network has to implement PubSub to get the benefits 🫧. In scenarios with a lot of traffic coming from outside the LISP network, turning on PubSub in the border routers significantly improves mobility latency overall 👑. Even when edge xTRs don't implement PubSub and traffic flows between EID-Prefixes at the edge, those xTRs still converge based on data-driven events and SMR-triggered updates 💜.
A.4. Enhanced Reachability with Dynamic Redistribution of Prefixes ✨
Okay so, LISP networks need to talk to other networks, and those networks might or might not be running LISP 🌐. Some of these setups look a lot like the ones in [GB-ATN] and [UBERLAY]. Here's the thing though: when people connected LISP to other networks, they realized that in lots of deployments, the spot where it meets the other domains isn't the Mapping System at all. It's the border router of the LISP site 🚪. So the border router has to know about the LISP prefixes so it can redistribute them to the other networks. People have tried a bunch of approaches over the years 💅
First, Map-Servers were put right next to the border routers. Iconic, but it didn't scale well, because border routers grow at a different pace than Map-Servers 📉. Second, people split the Map-Servers and border routers apart and set up LISP entries on the border by hand. That was a mess whenever anything changed 😩. Third, you can use a routing protocol (BGP, for example) to redistribute LISP prefixes from the Map-Servers to a border router. Slay in theory, but it comes with some side effects. Mainly, the Map-Servers have to run an extra protocol, which eats resources and needs proper configuration 🙃. So once PubSub was around, deployments started using it so border routers could dynamically learn the prefixes they need to redistribute, with no extra protocols and no extra configuration on the network 🦋.
So basically, PubSub can be used to discover EID-Prefixes so they can be imported into other routing domains that don't use LISP 🎀. It works the other way too: PubSub can also be used to discover when EID-Prefixes need to be withdrawn from other routing domains 🧚. In a typical deployment, a border router withdraws an EID-Prefix it has been announcing to external routing domains if it gets a notification that the RLOC-set for that EID-Prefix is now empty. Main character energy for the border router, honestly 👑
A.5. Better Serviceability 🌸
Okay, EID-to-RLOC mappings can have a super long TTL, sometimes on the order of several hours ⏳. When that TTL expires, the xTR checks whether these entries are being used, and it removes any entry that isn't being used 🧹. The catch with a really long Map-Cache TTL is that (if PubSub isn't in the picture) when a mapping changes but nobody's using it, the cache just sits there, stale 💀. That's because no data traffic gets sent to the old location to trigger an SMR-based Map-Cache update, as described in Section 4.1.2.1 of [EID-MOBILITY] 🙈. If the network operator runs a show command on a router to check the Map-Cache state, the router will display multiple entries waiting to expire, but with stale RLOC information 😭. That can be really confusing for operators, especially when they're debugging problems 🔍. With PubSub, the Map-Cache gets updated with the correct RLOC information, even when it's not being used or waiting to expire. Lowkey the best part, because it makes debugging way easier 💜
Acknowledgments 🫶
We would like to thank Marc Portoles, Balaji Venkatachalapathy, Bernhard Haindl, Luigi Iannone, and Padma Pillay-Esnault for their great suggestions and help regarding this document 🌈.
Many thanks to Alvaro Retana for the careful AD review 💖.
Thanks to Chris M. Lonvick for the security directorate review, Al Morton for the OPS-DIR review, Roni Even for the Gen-ART review, Mike McBride for the rtg-dir review, Magnus Westerlund for the tsv directorate review, and Sheng Jiang for the int-dir review ✨.
Thanks to John Scudder, Erik Kline, Lars Eggert, Warren Kumari, Martin Duke, Murray Kucherawy, Éric Vyncke, Robert Wilton, Zaheduzzaman Sarker, and Roman Danyliw for the IESG review 🙌.
This work was partly funded by the ANR LISP-Lab project #ANR-13-INFR-009 https://anr.fr/Projet-ANR-13-INFR-0009 🇫🇷💅.
Contributors 🎀
- Dino Farinacci, lispers.net, San Jose, CA, United States of America, Email:
farinacci@gmail.com💖 - Johnson Leong, Email:
johnsonleong@gmail.com🌸 - Fabio Maino, Cisco, San Jose, CA, United States of America, Email:
fmaino@cisco.com🦋 - Christian Jacquenet, Orange, Rennes, France, Email:
christian.jacquenet@orange.com🧚 - Stefano Secci, Cnam, France, Email:
stefano.secci@cnam.fr⭐
Authors' Addresses 💜
- Alberto Rodriguez-Natal, Cisco, Barcelona, Spain, Email:
natal@cisco.com👑 - Vina Ermagan, Google, United States of America, Email:
ermagan@gmail.com🌈 - Albert Cabellos, UPC/BarcelonaTech, Barcelona, Spain, Email:
acabello@ac.upc.edu🍓 - Sharon Barkai, Nexar, Email:
sharon.barkai@getnexar.com🔥 - Mohamed Boucadair, Orange, Rennes, France, Email:
mohamed.boucadair@orange.com✨
📦 where this page comes from
- ietf: rfc9437 2023-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms