Network Working Group Z. Ali Internet-Draft C. Gaddam Intended status: Informational Cisco Systems Expires: 7 January 2027 6 July 2026 A Policy-Driven Implicit TLS Transport Profile for PCEP draft-ali-pce-implicit-tls-profile-00 Abstract RFC 8253 specifies the use of Transport Layer Security (TLS) for the Path Computation Element Communication Protocol (PCEP) by negotiating TLS using the PCEP StartTLS message exchange. This document specifies a deployment profile for PCEP in which TLS is initiated immediately following TCP connection establishment based on local policy. This document is intended to simplify deployments where secure transport is mandatory. 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 7 January 2027. Copyright Notice Copyright (c) 2026 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 Ali & Gaddam Expires 7 January 2027 [Page 1] Internet-Draft Implicit TLS Profile for PCEP July 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Policy-Driven Implicit TLS Procedure . . . . . . . . . . . . 3 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction RFC 8253 defines the use of Transport Layer Security (TLS) to secure Path Computation Element Protocol (PCEP) sessions using a StartTLS based mechanism on the existing PCEP TCP port. The StartTLS procedure performs capability negotiation before the TLS handshake. In deployments where TLS is optional, operational policy determines whether a connection may continue without TLS. This document specifies a deployment profile for PCEP in which TLS is initiated immediately following TCP connection establishment based on local policy. The target deployment model is where PCEP peers know that they operate with TLS via a policy. Specifically, in such deployments, a local policy enables initiation of TLS immediately upon TCP connection establishment on the existing PCEP port (policy- driven implicit TLS). 2. Motivation The StartTLS mechanism defined in RFC 8253 performs capability negotiation in cleartext prior to initiating the TLS handshake. In deployments where: * No transport-layer cryptographic integrity protection (e.g., TCP- AO or IPsec) is active during this phase, and * Fallback to cleartext is permitted An on-path attacker may attempt to interfere with TLS capability signaling. Ali & Gaddam Expires 7 January 2027 [Page 2] Internet-Draft Implicit TLS Profile for PCEP July 2026 When TLS is configured as mandatory and fallback to cleartext is prohibited, downgrade risk is mitigated. However, correct security behavior in a StartTLS-based design depends on explicit policy enforcement and correct operational configuration. Misconfiguration (e.g., optional TLS or permitted fallback) may result in unintended cleartext operation. In addition, the StartTLS mechanism introduces additional protocol state transitions and implementation complexity. Implementations that always require secure transport or are known to use secure transport via the management plane do not benefit from negotiating whether TLS will be used. This document defines an alternative transport profile intended to achieve the following benefits. These benefits come under the assumption that the PCEP peers know that they operate with TLS via a policy. * Reduced state transitions * Simpler implementations * Operational simplicity 3. Policy-Driven Implicit TLS Procedure In the policy-driven implicit TLS profile: * TLS is initiated immediately upon TCP establishment * No PCEP messages are exchanged prior to completion of the TLS handshake * If TLS negotiation fails, the connection is not established The procedure is depicted in the following Figure: Ali & Gaddam Expires 7 January 2027 [Page 3] Internet-Draft Implicit TLS Profile for PCEP July 2026 PCC PCE | | |------ TCP Connect ------------>| |<----- TCP Established ---------| | | |====== TLS Handshake ==========>| |<===== TLS Complete ============| | | |--------- OPEN ---------------->| |<-------- OPEN -----------------| | | |======== PCEP Messages =========| The implicit TLS profile runs using the existing PCEP TCP port assigned by IANA. This profile is intended only for deployments where both peers are administratively configured for policy-driven implicit TLS. Mixed deployments are outside the scope of this document. For deployments where transport-layer security is mandatory, the policy-driven implicit TLS profile can be used. It reduces implementation complexity and attack surface. 4. Backward Compatibility The introduction of the policy-driven implicit TLS profile does not alter the behavior of existing StartTLS or cleartext deployments. Specifically: * Implementations can support both RFC8253 and this profile through configuration. * Deployments that do not require transport-layer security continue to operate using cleartext PCEP without modification. 5. Security Considerations This document changes only the transport establishment procedure. The security properties after completion of the TLS handshake are equivalent to those obtained using RFC 8253. 6. IANA Considerations None. 7. Normative References Ali & Gaddam Expires 7 January 2027 [Page 4] Internet-Draft Implicit TLS Profile for PCEP July 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Authors' Addresses Zafar Ali Cisco Systems Email: zali@cisco.com Chennakesava Reddy Gaddam Cisco Systems Email: chgaddam@cisco.com Ali & Gaddam Expires 7 January 2027 [Page 5]