Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP)
Extracted elements (28)
Notifications are managed by the Mapping System (Map-Server) rather than by ETRs (as in RFC 9301 Section 6.1). This allows mapping changes to be detected and disseminated faster and centralizes subscription state in the infrastructure rather than at LISP sites.
PubSub enables border routers to dynamically learn and withdraw LISP EID-Prefixes for redistribution into non-LISP routing domains without requiring an additional routing protocol (e.g., BGP) on the Map-Server or static configuration, addressing a scalability and operational complexity problem observed in production deployments.
PubSub is an event-triggered mechanism, whereas TTL-based mapping refresh is a polling mechanism that generates constant signaling regardless of state changes. Production experience showed that TTL polling causes excessive signaling for negative cache entries and stale mappings during reconfiguration; PubSub eliminates these by pushing updates only when state actually changes.
PubSub requires three deployment prerequisites not mandated by baseline RFC 9301: (1) unique 128-bit xTR-ID plus 64-bit Site-ID per xTR, (2) Map-Servers configured for proxy Map-Replying, and (3) a security association between ITRs and Map-Servers. If any prerequisite is unmet, the network continues operating per RFC 9301 without PubSub.
For PubSub operation, an xTR MUST be configured with an xTR-ID and Site-ID, MUST set the I-bit to 1, and MUST include its xTR-ID and Site-ID in every Map-Request it generates. If the I-bit is set but the Site-ID and/or xTR-ID are absent, the receiver MUST drop the malformed message.
If an xTR-ID is successfully added to the subscriber list, the Map-Server MUST extract and store the nonce and ITR-RLOCs from the Map-Request, overwriting any previously stored ITR-RLOCs and/or nonce for the same xTR-ID, and MUST send a Map-Notify to confirm the subscription.
If subscription fails due to policy the Map-Server MUST respond with a Negative Map-Reply with ACT bits set to 4 (Drop/Policy-Denied); if it fails due to authentication, ACT bits MUST be set to 5 (Drop/Auth-Failure).
Map-Resolvers MUST verify that an xTR is allowed to set the N-bit to 1 and 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 perform this verification.
The Map-Server MUST use the nonce from the subscription Map-Request as the nonce for the confirming Map-Notify, and MUST sign the authentication data of that Map-Notify using its security association with the xTR.
The xTR MUST keep track of the last nonce seen in Map-Notify publications from the Map-Server per EID-Prefix. If a received Map-Notify nonce is not greater than the saved nonce, the xTR MUST drop the message and log that a replay attack may have occurred.
To remove a subscription, a valid Map-Request with the N-bit set and only one ITR-RLOC with AFI=0 (Unknown Address) signals unsubscription. The Map-Server MUST remove the subscription state and MUST send a Map-Notify to confirm the removal.
Upon receiving a publication Map-Notify the xTR MUST validate the authentication data using its security association with the Map-Server, and MUST update its Map-Cache with the mapping information carried in the Map-Notify.
Upon receiving a subscription Map-Request the Map-Server MUST verify that the nonce is strictly greater than the stored nonce for that xTR-ID. If not, the Map-Server MUST silently drop the message and SHOULD log the event as a possible replay attack.
When a mapping is updated the Map-Server MUST notify all subscribers via Map-Notify messages carrying the most up-to-date mapping information. The Map-Server increments the nonce by one for every Map-Notify sent as a publication to a given xTR-ID for a particular EID-Prefix.
When an EID-Prefix is removed from the Map-Server (withdrawn or TTL expired), the Map-Server MUST notify all its subscribers via a Map-Notify with TTL equal to 0.
When subscribing, the xTR MUST set the N-bit to 1 on each EID-Record for which it wants to receive notifications. If the xTR has an existing nonce for that EID-Prefix it MUST use that nonce incremented by one; otherwise it generates a fresh nonce per RFC 9301.
Subscription state stored at the Map-Server comprises the EID-Prefix, xTR-ID, set of ITR-RLOCs, and nonce. A single-nonce-per-xTR-ID mode is supported when a single Map-Server is deployed, but MUST be enabled consistently at both the Map-Server and all xTRs.
The I-bit (xTR-ID bit) is a new bit at position 11 in the LISP Map-Request header. When set to 1 it indicates that 128-bit xTR-ID and 64-bit Site-ID fields are appended after the final EID-Record in the Map-Request.
The N-bit (Notification-Requested bit) is a per-EID-Record bit in the Map-Request record header (bit position 1 in the Map-Request-Record). When set to 1 it specifies that the xTR wants to be notified of mapping updates for that EID-Prefix.
The PubSubKey is a soft- or hard-state security association between an ITR and a Map-Server used to authenticate Map-Notify messages. It may be a pre-shared key or derived via LISP-SEC as PubSubKey = KDF(OTK + nonce), where KDF is identified by the OTK Wrapping ID.
The xTR-ID field is a 128-bit identifier appended to the Map-Request after the last EID-Record when the I-bit is set. The Site-ID is a 64-bit field immediately following the xTR-ID. Together they uniquely identify the subscribing tunnel router within a LISP deployment.
IANA assigned the I-bit (Map-Request-I) to bit position 11 in the existing 'LISP Control Plane Header Bits: Map-Request' registry within the LISP Parameters group.
IANA created a new registry 'LISP Control Plane Header Bits: Map-Request-Record' within the LISP Parameters group. Its initial entry is the N-bit (Map-Request-N) at bit position 1; remaining bits 2–8 are Unassigned. The allocation policy is Specification Required (RFC 8126 Section 4.6).
Cache poisoning via malicious Map-Notify messages is prevented by the combination of monotonically increasing nonces and the PubSubKey security association between ITRs and Map-Servers. Integrity protection of Map-Request messages (e.g., via LISP-SEC) is RECOMMENDED to prevent xTR-ID hijacking.
Misbehaving known nodes may flood subscription requests or rapidly toggle subscription state, exhausting Map-Server resources. Mitigations include rate-limiting Map-Requests (RFC 9301 Section 5.3) and Map-Notifies (RFC 9301 Section 5.7); when the Map-Notify rate-limit threshold is reached for an xTR-ID, the Map-Server falls back to sending Map-Reply instead.
Removing subscription state can enable replay attacks by resetting the nonce baseline. The Map-Server SHOULD retain the last nonce seen per xTR-ID after unsubscription; if it cannot, it MUST require xTRs to re-establish a new security association before re-subscribing.
When using LISP-SEC to establish a PubSubKey, the Map-Server MUST verify that the One-Time Key (OTK) has not been used before; reuse triggers a Negative Map-Reply with ACT=5 (Drop/Auth-Failure). Implementations that do not track all past OTKs may use a hash, trading collision probability for storage.
The updated Map-Request carries: the standard header with I-bit at bit 11; per-record N-bit at bit 1 of the record header (8-bit field, followed by 8-bit EID mask-len and 16-bit EID-Prefix-AFI); and, when I-bit=1, a 128-bit xTR-ID followed by a 64-bit Site-ID appended after all records.