PIM Working Group Y. Liu Internet Draft X. Xu Intended status: Standards Track China Mobile Expires: November 30, 2024 C. Lin New H3C Technologies May 31, 2024 Multicast Source Discovery Protocol (MSDP) Send Hold Timer draft-liu-pim-msdp-sendholdtimer-01 Abstract This document defines the SendHoldTimer and the SendHoldTimer_Expires event in the MSDP protocol. The implementation of SendHoldTimer helps to address the situation where the local system detects that the remote system has not processed MSDP messages but has not terminated the MSDP session. According to this document, when the SendHoldTimer expires, the local system should close the MSDP session connection, rather than relying on the remote system to initiate the session closure. This document updates RFC3618. 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 November 30, 2024. Copyright Notice Copyright (c) 2024 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 (http://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 Liu, et al. Expire November 30, 2024 [Page 1] Internet-Draft MSDP Send Hold Timer May 2024 document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 1.1. Conventions and Terminology...............................3 2. Problem Statement..............................................3 3. SendHoldTimer - Changes to RFC 3618............................4 3.1. Changes to Timers.........................................4 3.2. Changes to MSDP Connection State Machine..................4 4. Security Considerations........................................6 5. IANA Considerations............................................6 6. References.....................................................7 6.1. Normative References......................................7 6.2. Informative References....................................7 Authors' Addresses................................................8 Liu, et al. Expires November 30, 2024 [Page 2] Internet-Draft MSDP Send Hold Timer May 2024 1. Introduction This document defines the SendHoldTimer and SendHoldTimer_Expires mechanisms for MSDP [RFC3618], as defined in Section 5 of that specification. The failure to terminate blocked MSDP sessions may lead to Denial of Service (DoS) attacks, resulting in the inability to generate and convey multicast source information, thereby disrupting normal multicast forwarding. This specification aims to address this situation by requiring the termination of sessions when the local system detects that the remote system is unable to process any MSDP messages during the SendHoldTime. With this specification, blocked connections can be terminated by the remote system and also by the local system between MSDP devices. 1.1. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Problem Statement An example of a network failure scenario is when an established MSDP session, running over TCP [RFC9293], between MSDP peers is disrupted due to one peer declaring a zero-sized TCP receive window (RCV.WND) to the other peer. This zero-sized TCP receive window prevents the local system from sending critical MSDP messages such as KEEPALIVE and SA messages to the remote peer via the network socket. In the absence of an implementation of the SendHoldTimer concept, a failed or overwhelmed remote peer can lead to a continuous accumulation of data on the MSDP socket of the local system, resulting in the inability to transmit multicast source information and consequently affecting the normal multicast forwarding. Normally, MSDP implementations are unable to observe the current receive window size of the underlying subsystem (such as TCP) or the peer, and there are no MSDP mechanisms to terminate such blocked sessions. As a result, MSDP implementations are unable to handle this situation consistently. This document provides a mechanism that allows MSDP implementations to detect whether the TCP socket between MSDP peers is making Liu, et al. Expires November 30, 2024 [Page 3] Internet-Draft MSDP Send Hold Timer May 2024 progress (data is being transmitted) or is stalled. In the case of a stall, the MSDP session can be restarted to restore the normal operation of the MSDP protocol. 3. SendHoldTimer - Changes to RFC 3618 3.1. Changes to Timers In Chapter 5, timers for the MSDP protocol are defined. Add descriptions for [SendHoldTimer] and [SendHoldTime]. Next Text: 5.7 Send Hold Timer Once the MSDP Peer transitions to the UP state, the MSDP Peer initiates the [SendHoldTimer] with a timeout value of [SendHoldTime]. When sending KeepAlive messages or SA messages to the peer, the [SendHoldTimer] is reset to [SendHoldTime]. It is recommended that [SendHoldTime] be consistent with [HoldTime- Period]. Upon expiration of the [SendHoldTimer], the MSDP session will be terminated. 3.2. Changes to MSDP Connection State Machine Chapter 11 describes the finite state machine for MSDP. In this chapter, add the event "Send Hold Timer Expired" and specify that upon handling this event, the TCP connection should be closed. The specific modification is as follows: Old Text: 11.1. Events ... E10) Any other error detected Next Text: 11.1. Events ... E10) Any other error detected E11) Send Hold Timer expired Liu, et al. Expires November 30, 2024 [Page 4] Internet-Draft MSDP Send Hold Timer May 2024 Modify the state machine diagram to include the handling of the "Send Hold Timer Expired" event. --------------->+----------+ / | DISABLED |<---------- | ------>+----------+ \ | / |E1->A1 | | | | | | | V |E7->A7 | | +----------+ E3->A3 +--------+ | | | INACTIVE |------->| LISTEN | | | +----------+ +--------+ | | E2->A2| ^ |E5->A5 | | | | | | |E7->A6 V |E6 | | \ +------------+ | | ------| CONNECTING | | | +------------+ | E7->A8 | |E4->A4 | E8->A8 | | | E9->A8 | V | E11->A8 \ +-------------+ / --------------| ESTABLISHED |<--------- +-------------+ | ^ | | E10->A9 \______/ Modify the state machine diagram to include the handling of Send Hold Timer expiration in the "Establish" state. Old Text: E7->A8 E8->A8 E9->A8 Next Text: E7->A8 E8->A8 E9->A8 E11->A8 Changes to Peer-specific Events: Add handling of the event for successful sending of KeepAlive or SA messages. Liu, et al. Expires November 30, 2024 [Page 5] Internet-Draft MSDP Send Hold Timer May 2024 Old Text: 11.3. Peer-specific Events ... *) KeepAlive timer expired: -> Send KeepAlive TLV -> Set KeepAlive timer to [KeepAlive-Period] Next Text: 11.3. Peer-specific Events ... *) KeepAlive timer expired: -> Send KeepAlive TLV -> Set KeepAlive timer to [KeepAlive-Period] *) KeepAlive or SA TLV sended: -> Set Send Hold Timer to [SendHoldTime] 4. Security Considerations This specification addresses the potential vulnerability of MSDP to attacks where MSDP peers pretend to be unable to process MSDP messages, causing the MSDP protocol to malfunction. In other aspects, this specification does not alter the security characteristics of MSDP. 5. IANA Considerations This document does not request any IANA modifications. Liu, et al. Expires November 30, 2024 [Page 6] Internet-Draft MSDP Send Hold Timer May 2024 6. References 6.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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC3618] D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003, . 6.2. Informative References Liu, et al. Expires November 30, 2024 [Page 7] Internet-Draft MSDP Send Hold Timer May 2024 Authors' Addresses Yi Liu China Mobile China Email: liuyi4@ha.chinamobile.com Xiaolei Xu China Mobile China Email: xuxiaolei@ha.chinamobile.com Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Liu, et al. Expires November 30, 2024 [Page 8]