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.¶

Copyright Notice

Copyright (c) 2023 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

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.¶

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.¶

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.¶

6. Failed Notification with Retransmission

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

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.¶

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.¶

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:¶

• 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-Record.¶

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]:¶

• If a Map-Register is received with a nonce value that is not greater than the saved nonce, it MUST drop the Map-Register message and SHOULD log the fact that a replay attack could have occurred.¶

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).¶

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.¶

• Note that currently none of LISP specifications use timestamps.¶

11. xTR-triggered Subscription Withdrawal

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

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.¶

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.¶

Acknowledgments

Thanks to TBC.¶

Author's Address