Internet-Draft LISP PubSub Examples February 2023
Boucadair Expires 11 August 2023 [Page]
Workgroup:
Locator/ID Separation Protocol
Internet-Draft:
draft-boucadair-lisp-pubsub-flow-examples-01
Published:
Intended Status:
Informational
Expires:
Author:
M. Boucadair
Orange

LISP PubSub Flow Examples

Abstract

This document provides a set of flow examples to illustrate the use of LISP PubSub specification.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the Locator/ID Separation Protocol Working Group mailing list (lisp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/lisp/.

Source for this draft and an issue tracker can be found at https://github.com/boucadair/lisp-pubsub-flow-examples.

Status of This Memo

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 https://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 11 August 2023.

Table of Contents

1. Introduction

This document provides a set of flow examples as a companion to the LISP PubSub specification [I-D.ietf-lisp-pubsub]. The document is meant to illustrate and assess the behavior of LISP control nodes under specific conditions.

The examples use a simplified/simple setup for the sake of illustration.

2. Terminology

This document uses the terms defined in [I-D.ietf-lisp-pubsub].

The following terms and notations are used in this document:

init_nonce:

the nonce that is initially included in a Map-Request to create a subscription.

initial subscription request:

the Map-Request that was used to create the initial subscription. This request has the nonce value set to init_nonce.

nonce++:

incremented nonce by 1.

init_key_id:

the key identifier that was used in the Map-Request with init_nonce.

trans_count:

retransmission counter as per Section 5.7 of [RFC9301].

trans_timer:

retransmission timer as per Section 5.7 of [RFC9301].

AT:

Attacker

3. Initial Successful Subscription

Figure 1 shows the example a successful subscription. The example assumes that a security association is in place between the xTR ad the Map-Server (Section 7.1 of [I-D.ietf-lisp-pubsub]) and that all integrity-protection checks are successfully passed.

xTR MS Generate a new key Map-Request(init_nonce, and an initial init_key_id,..) Security/integrity nonce. Store them protection check. locally for this No State for this subscription xTR-ID/EID is found Create the sub and Map-Notify(init_nonce, store init_nonce, ,...) init_key_id, ... Security/integrity protection check. Check that rcv Map-Notify-Ack(init_nonce nonce == init_nonce ,...) Confirm the sub and Security/integrity wait for notifs protection checks. This subscription is now ACKed
Figure 1: An Example of Successful Initial Subscription

4. Successful Notification

Figure 2 illustrates the example of a successful delivery of notification updates that match an existing subscription state. This example assumes that a security association is in place between the xTR and the Map-Server (Section 7.1 of [I-D.ietf-lisp-pubsub]) and that all subsequent integrity-protection checks are successfully passed.

xTR MS Security/integrity Map-Notify(nonce ...) Update is triggered protection check. Increment the nonce Check that rcv Set trans_count and nonce >= local trans_timer nonce + 1 Confirms the notif and update the Map-Notify-Ack(nonce ..) Security/integrity entry protection checks. This notification is now ACKed
Figure 2: An Example of Successful Notification

5. Successful Notification with Retransmission

Unlike the example depicted in Figure 2, Figure 3 illustrates the behavior that is experienced when a subset of Map-Notify messages are lost during their transfer. This example assumes that at least one of these Map-Notify messages is received by the target xTR.

xTR MS Map-Notify(nonce, ...) Update is triggered Increment the nonce Set trans_count and trans_timer Map-Notify(nonce, ...) Increment trans_count and reset trans_timer Security/integrity Map-Notify(nonce, ...) Increment protection check. trans_count and Check that rcv reset trans_timer nonce >= local nonce + 1 Confirms the notif Map-Notify-Ack(nonce,... Security/integrity and update the protection checks. entry This notification is now ACKed
Figure 3: An Example of Successful Notification with Retransmission

6. Failed Notification with Retransmission

Figure 4 assumes that, due to network conditions, all Map-Notifies are lost.

xTR MS Map-Notify(nonce, ...) Update is triggered Increment the nonce Set trans_count and trans_timer Map-Notify(nonce, ...) Increment trans_count and reset trans_timer Map-Notify(nonce, ...) Increment trans_count and reset trans_timer
Figure 4: An Example of Failed Notification Delivery

Note that no specific action is currently specified in [I-D.ietf-lisp-pubsub] when such a failure occurs. That is, the entry is kept active and future updates will trigger new Map-Notify cycles. Also, the current specification does not recommend a behavior (e.g., regular refreshes) so that the xTR avoids maintaining stale mappings. Such details are implementation specific (see, for example, Section 7). In order to accommodate Map-Notify message lost, the nonce checks on the xTR should not be on the exact match vs "nonce + 1"; messages with "received nonce >= local nonce + 1" should be accepted.

7. Successful Subscription Update

Figure 5 illustrates the example of successful update of an existing subscription. The triggers for such a refresh are implementation specific.

xTR MS Increment the last Map-Request(nonce, ...) Security/integrity seen nonce protection check. Found an entry for this xTR-ID Map-Notify(nonce,...) Check that rcv Security/integrity nonce >= local protection check. nonce + 1 Check that rcv nonce == snd nonce Confirm the sub and Map-Notify-Ack(nonce,...) wait for notifs Security/integrity protection check. This subscription update is ACKed
Figure 5: An Example of Successful Subscription Update

8. Failed Subscription with Lost Map-Notify-Ack

This example is similar to Section 3, except that the Map-Notify-Ack is not delivered to the Map-Server. The Map-Server retransmits the Map-Notify 3 times, and then removes the subscription. A Map-Notify to explicitly indicate the reason for such a removal is also generated by the Map-Server. If the xTR receives this Map-Notify, the xTR may decide to send the Map-Request to reinstall back the removed state. The procedure to reinstall the state is similar to Figure 1.

xTR MS Generate a new key Map-Request(init_nonce, and an initial init_key_id,..) Security/integrity nonce. Store them protection check. locally for this No State for this subscription xTR-ID/EID is found Create the sub and store init_nonce, Map-Notify(init_nonce,...) init_key_id, ... Security/integrity Set trans_count and protection check. trans_timer Check that rcv nonce == init_nonce Map-Notify-Ack(init_nonce,...) Confirm the sub and wait for notifs Map-Notify(nonce, ...) Increment trans_count and reset trans_timer Map-Notify(nonce, ...) Increment trans_count and reset trans_timer Map-Notify(nonce, AFI, ACT,...) Remove the subscri- ption ...
Figure 6: An Example of Failed Initial Subscription

9. Bootstrapping an xTR

When first bootrsapped, an xTR may delete any (stale) state that might be associated with its provisioned xTR-ID and security association. To that aim, the xTR sends a Map-Request that has only one ITR-RLOC with AFI = 0.

A Map-Notify will be sent back by the Map-Server even if no subscription is found.

10. Stale Subscriptions

For various reasons, an xTR may lose its subscriptions (or at least the nonce of a subscription). Note that losing the nonce is not compliant with the following from the PubSub specification:

If the same key is used, the Map-Request is likely to be rejected by the Map-Server and, thus, stale subscriptions will be maintained by the Map-Server. The request is silently discarded by the Map-Server. This behavior is similar to thsi behavior in [RFC9301]:

xTR MS Map-Request(nonce, init_key_id,..) Security/integrity protection check. A state for xTR-ID/EID is found but the nonce check fails: rcv nonce < local nonce + 1. Discard the packet
Figure 7: An Example of Stale Subscriptions

If the Map-Server stores all the key-ids that were used by an xTR for its subscriptions, the Map-Server may accept overriding an existing state without enforcing the nonce check but if and only if a new key is used (see Figure 8).

xTR MS Map-Request(nonce, new key_id, ...) Security/integrity protection check. A state for Map-Notify (nonce, ...) xTR-ID/EID is found but the new auth key is used, the state is updated
Figure 8: An Example of Stale Subscriptions Avoidance with New KEys

However, the approach in Figure 8 may have scalability issues as the Map-Server must store all the key identifiers that were ever used. Otherwise, an attacker can replay a message for which the key-id is not stored anymore by the Map-Server. This issue is not encountered if LISP-SEC messages are timestamped.

11. xTR-triggered Subscription Withdrawal

Figure 9 illustrates the observed exchange to successfully delete a subscription.

xTR MS Increment the last Map-Request(nonce, AF=0...) Security/integrity seen nonce protection check. Found an entry for this xTR-ID Map-Notify(nonce,...) Check that rcv Security/integrity nonce >= local protection check. nonce + 1 Check that rcv nonce == snd nonce Send Map-Notfiy-ACK Map-Notify-Ack(nonce,...) Security/integrity protection check. This withdrawal is confirmed
Figure 9: An Example of Successful Subscription Withdrawal

12. 'Map-Server'-triggered Subscription Withdrawal

Figure 10 illustrates the observed exchange to notify the withdrawal of a subscription at the initiative of the Map-Server.

xTR MS Security/integrity Map-Notify(nonce, TTL=0, ...) Update is triggered protection check. Increment the nonce Check that rcv Set trans_count and nonce >= local trans_timer nonce + 1 Confirms the notif and remove the Map-Notify-Ack(nonce, ...) Security/integrity entry protection checks. This notification is now ACKed
Figure 10: An Example of Successful Notification of Subscription withdrawal

12.1. Replay Attacks

12.1.1. Replayed Subscription (Update)

Figure 11 shows the example of a replayed subscription request. The request will be silently dropped the Map-Server because of nonce check failure.

AT MS Map-Request(init_nonce, init_key_id,..) Security/integrity protection check. A state is for xTR-ID/EID is found xTR but the nonce check fails: rcv nonce < local nonce + 1. Discard the packet
Figure 11: An Example of Handling of Replayed Initial Subscription

Note that legitimate Map-Requests issued from the authentic xTR may be blocked as a side effect of enforcing a rate-lmit of the replayed messages. An example is shown in Figure 12.

AT MS Map-Request(init_nonce, init_key_id,..) Security/integrity protection check. ... A state is found xTR-ID/EID is found but the nonce check fails: rcv nonce < local nonce + 1 (more requests) Rate-limit xTR-ID requests is reached xTR Map-Request(...) Discard
Figure 12: An Example of Handling of Replayed Initial Subscription

If replayed attacks are not counted as part of the rate-limit policy, legitimate Map-Requests will be procecced as illustrate in Figure 13.

AT MS Map-Request(init_nonce, init_key_id,..) Security/integrity protection check. ... A state is found xTR-ID/EID is found but the nonce check fails: rcv nonce < local nonce + 1 xTR Map-Request(...) Process
Figure 13: An Example of Handling of Replayed Initial Subscription

12.1.2. Replayed Withdrawal

Figure 14 depicts the example of the exchange that occurs when an attacker sends a replayed withdrawal request. The request will be silently discared by the Map-Server.

AT MS Map-Request(nonce, AFI=0,...) Security/integrity protection check. A state is found xTR-ID/EID is found xTR but the nonce check fails: rcv nonce < local nonce + 1 Discard the packet
Figure 14: An Example of Handling of Replayed Removal of a Subscription

12.1.3. Replayed Notification Updates

Figure 15 illustrates the observed exchange when a replayed notification update is sent by a misbehaving node (AT) to an xTR.

xTR AT Security/integrity Map-Notify(nonce, TTL=0, ...) protection check. Check that rcv nonce >= local nonce + 1 Discard the message because the nonce checks failed
Figure 15: An Example of Replayed Notification of Subscription Withdrawal

13. Explicit Subscriptions

TBC.

14. Security Considerations

This document does not introduce any security considerations beyond those already discussed in [I-D.ietf-lisp-pubsub].

15. IANA Considerations

This document does not make any request to IANA.

16. Normative References

[I-D.ietf-lisp-pubsub]
Rodriguez-Natal, A., Ermagan, V., Cabellos-Aparicio, A., Barkai, S., and M. Boucadair, "Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP)", Work in Progress, Internet-Draft, draft-ietf-lisp-pubsub-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-10>.
[RFC9301]
Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., "Locator/ID Separation Protocol (LISP) Control Plane", RFC 9301, DOI 10.17487/RFC9301, , <https://www.rfc-editor.org/rfc/rfc9301>.

Acknowledgments

Thanks to TBC.

Author's Address

Mohamed Boucadair
Orange
35000 Rennes
France