Network Working Group C. Lin Internet Draft New H3C Technologies Intended status: Standards Track Expires: February 10, 2025 August 13, 2024 Path Computation Element (PCE) Communication Protocol (PCEP) Send Hold Timer draft-lin-pcep-sendholdtimer-01 Abstract This document defines the SendHoldTimer and SendHoldTimer_Expires events in the PCEP protocol. The implementation of SendHoldTimer helps address situations where a local system detects that a remote system has not terminated the PCEP session despite not processing PCEP messages. As per this document, when the SendHoldTimer expires, the local system should close the PCEP connection rather than solely relying on the remote system to terminate the session. This document provides updates to RFC5440. 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 February 10, 2025. 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 Lin, et al. Expires February 10, 2025 [Page 1] Internet-Draft PCEP Send Hold Timer August 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 5440............................4 3.1. Architectural.............................................4 3.2. CLOSE Object..............................................5 3.3. PCEP Finite State Machine (FSM)...........................6 4. Security Considerations........................................7 5. IANA Considerations............................................7 6. Acknowledgements...............................................7 7. References.....................................................7 7.1. Normative References......................................7 Authors' Addresses................................................8 Lin, et al. Expires November 2024 [Page 2] Internet-Draft PCEP Send Hold Timer August 2024 1. Introduction As described in [I-D.ietf-idr-bgp-sendholdtimer], any upper-layer protocol that uses TCP for transport can encounter similar situations where the remote system is unable to read TCP data due to a failure, leading to an inability to terminate the BGP connection. PCEP also requires a BGP-like send timeout mechanism [I-D.ietf-idr- bgp-sendholdtimer] to resolve this issue. This document defines the SendHoldTimer and SendHoldTimer_Expires mechanisms in PCEP [RFC5440]. The failure to terminate a blocked PCEP session may result in a denial-of-service (DoS) attack, inhibiting the generation and delivery of essential PCEP messages such as PCReq, PCEPReplies, and PCNtf messages, consequently disrupting the normal PCE path computation function. This specification aims to address this issue by requiring the termination of the session at the local system when it detects that the remote system is unable to process any PCEP messages during the SendHoldTime period. With the SendHoldTimer mechanism specified in this document, a blocked connection between PCC and PCE devices can be closed by the remote system, and it will also be closed locally if blocked. 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: Since PCEP operates over TCP [RFC9293], a session is established between a PCC and a PCP. The PCC sends a PCReq message to the PCE to request path computation, and the PCC responds to the PCReq message with a PCRep message, used for traffic path selection. In an established state between the PCC and PCE, there may be a situation where one party declares a zero-size TCP receive window (RCV.WND) to the other. This zero-size TCP receive window prevents the local system from sending crucial PCEP messages such as KEEPALIVE, PCReq, PCRep, PCErr, and PCNtf messages to the remote peer through the network socket. Lin, et al. Expires November 2024 [Page 3] Internet-Draft PCEP Send Hold Timer August 2024 In implementations lacking the SendHoldTimer concept, a failed or overloaded remote peer may result in a continuous accumulation of data on the local system's PCEP socket, affecting path selection, and potentially leading to forwarding failures and traffic loss. In typical scenarios, PCEP implementations cannot observe the current receive window size of the underlying subsystem (such as TCP) or the peer, and there is no PCEP mechanism to terminate such a blocked session. Consequently, PCEP implementations are unable to consistently handle this situation. This document provides a mechanism that enables PCEP implementations to detect whether the TCP socket between the PCC and PCE is active (data is being transmitted) or stalled. In the event of a stall, the PCEP session can be restarted to restore normal operation of the PCEP protocol. 3. SendHoldTimer - Changes to RFC 5440 3.1. Architectural Chapter 4 introduces the framework of the PCEP protocol, including the SendHoldTimer and SendHoldTimer_Expires mechanisms. After the PCEP session state transitions to UP, the SendHoldTimer timer is initiated for this PCEP session, with [SendHoldTime] representing the timer's timeout value. This determines the duration for which the PCEP state is maintained when unable to transmit messages to its peer, and if this time is exceeded, the TCP connection will be terminated. PCC and PCE can configure the value of SendHoldTime independently for each peer. Following the successful transmission of various messages, including KeepAlive, PCReq, and PCRep, the SendHoldTimer needs to be reset. In the event of a detected timeout of the SendHoldTimer, there is an option to immediately send a Close message with the reason "SendHoldTimer_Expires," which is an addition in this document. The specific modification is as follows: In the original document, it is required to ensure that any outstanding PCReq messages are sent before actively closing the session. However, when TCP is blocked and messages cannot be successfully transmitted, for the SendHoldTimer_Expires event, it is permissible to immediately send a Close message with the reason "SendHoldTimer_Expires." Lin, et al. Expires November 2024 [Page 4] Internet-Draft PCEP Send Hold Timer August 2024 The description in 4.2. Architectural Protocol Overview: Old Text: Each PCEP message is regarded as a single transmission unit and parts of messages MUST NOT be interleaved. So, for example, a PCC sending a PCReq and wishing to close the session, must complete sending the request message before starting to send a Close message. Next Text: Each PCEP message is regarded as a single transmission unit and parts of messages MUST NOT be interleaved. So, for example, a PCC sending a PCReq and wishing to close the session, must complete sending the request message before starting to send a Close message. In special cases, if a timeout of the SendHoldTimer is detected, it is permissible to immediately send a Close message with the reason "SendHoldTimer_Expires." 3.2. CLOSE Object In the Reason Value defined in the CLOSE Object in section 7.17, a new value "SendHoldTimer expired" is added. Reasons Value Meaning 1 No explanation provided 2 DeadTimer expired 3 Reception of a malformed PCEP message 4 Reception of an unacceptable number of unknown requests/replies 5 Reception of an unacceptable number of unrecognized PCEP messages TBD SendHoldTimer expired (This Document) Lin, et al. Expires November 2024 [Page 5] Internet-Draft PCEP Send Hold Timer August 2024 3.3. PCEP Finite State Machine (FSM) Appendix A. PCEP Finite State Machine (FSM), the handling in the UP state requires adding processing for SendHoldTimer. Old Text: If the TCP connection fails, the system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State. Next Text: If the TCP connection fails, or SendHoldTimer Expires, the system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State. In "UP State", the handling of sending PECP message succeed is revised as follows: Old Text: UP State: In the UP state, the PCEP peer starts exchanging PCEP messages according to the session characteristics. If the Keepalive timer expires, the system restarts the Keepalive timer and sends a Keepalive message. UP State: In the UP state, the PCEP peer starts exchanging PCEP messages according to the session characteristics. If the Keepalive timer expires, the system restarts the Keepalive timer and sends a Keepalive message. Restart the SendHoldTimer every time a PCEP message, including KeepAlive, PCReq, and PCRep, is successfully sent. Lin, et al. Expires November 2024 [Page 6] Internet-Draft PCEP Send Hold Timer August 2024 4. Security Considerations This specification addresses the issue of potential attacks on PCEP routers, where PCEP peers pretend to be unable to process PCEP messages, thereby disrupting the normal operation of the PCEP protocol. In all other respects, this specification does not alter the security features of PCEP. 5. IANA Considerations In the Reason Value defined in the CLOSE Object, a new value "SendHoldTimer expired" is added. 6. Acknowledgements The authors wish to thank Job Snijders, Ben Cartwright-Cox, and Yingzhen Qu for their work on the BGP Send Hold Timer concept. 7. References 7.1. Normative References [I-D.ietf-idr-bgp-sendholdtimer] Snijders, J., Cartwright-Cox, B., and Y. Qu, "Border Gateway Protocol 4 (BGP-4) Send Hold Timer", Work in Progress, Internet-Draft, draft-ietf-idr- bgp-sendholdtimer, [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, . [RFC5440] JP. Vasseur, Ed.., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009, . Lin, et al. Expires November 2024 [Page 7] Internet-Draft PCEP Send Hold Timer August 2024 Authors' Addresses Changwang Lin New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com Lin, et al. Expires November 2024 [Page 8]