Network Working Group Z. Ali Internet-Draft C. Gaddam Intended status: Informational Cisco Systems Expires: 2 May 2027 A. Stone H. Bidgoli Nokia C. Lin New H3C Technologies Y. Liu China Mobile 2 November 2026 A Policy-Driven Implicit TLS Transport Profile for PCEP draft-ali-pce-implicit-tls-profile-02 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 in which TLS is initiated immediately after TCP connection establishment, on the existing PCEP port, based on an out- of-band configured policy. This profile is intended for managed deployments where TLS is mandatory and neither in-band security-mode negotiation nor fallback to cleartext is permitted. 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 2 May 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 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 Communication 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 in advance, through out-of-band administrative configuration, that they are required to use TLS. Specifically, the policy enables TLS immediately upon TCP connection establishment on the existing PCEP port (policy-driven implicit TLS). The use of the existing PCEP TCP port is a deliberate deployment choice. Operators that require TLS for PCEP sessions may wish to preserve existing port assignments, access-control rules, monitoring, and management-plane configuration while avoiding a PCEP-level StartTLS exchange. The security mode is selected by administrative configuration for the applicable peer or listener before the TCP connection is initiated or accepted; it is not detected or negotiated by inspecting the connection payload. This profile defines no new PCEP messages, objects, capabilities, or changes to the PCEP session state machine after TLS establishment. It changes the transport establishment sequence so that TLS precedes the first PCEP message. TLS implementation, identity verification, and appropriate administrative configuration remain necessary. 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 (such as 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. When TLS is configured as mandatory and fallback to cleartext is prohibited, downgrade risk is mitigated. Correct security behavior in a StartTLS-based design depends on explicit policy enforcement and correct operational configuration. Misconfiguration (for example, optional TLS or permitted fallback) may result in unintended cleartext operation. This document does not claim that RFC 8253 with mandatory TLS and correctly enforced policy is inherently insecure. Retaining the existing assigned PCEP port, rather than using a new TLS-only port, supports operational continuity. Introducing another port can require changes to peer configuration, filters, monitoring, and operating procedures. The profile therefore provides a predetermined TLS-only mode for a configured association without adding PCEP-level negotiation transitions. It does not eliminate TLS handshake processing or all deployment and configuration work. On other words, this document proposes a distinct, narrowly scoped model: retaining the assigned PCEP port while fixing the transport mode through prior bilateral administrative configuration. In deployments where secure transport is known and mandatory through the management plane, negotiating whether TLS will be used does not provide additional information about the intended security mode. The alternative profile is intended to reduce PCEP-level state transitions and simplify policy-driven secure session establishment. In such deployments, the implicit TLS profile provides the following Benefits: * 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: PCC PCE | | |------ TCP Connect ------------>| |<----- TCP Established ---------| | | |====== TLS Handshake ==========>| |<===== TLS Complete ============| | | |--------- OPEN ---------------->| |<-------- OPEN -----------------| | | |======== PCEP Messages =========| Figure 1: Policy-driven implicit TLS establishment The implicit TLS profile uses the existing IANA-assigned PCEP TCP port. This does not imply per-connection dynamic negotiation among cleartext PCEP, StartTLS, and implicit TLS. The initiating and receiving peers need compatible preconfigured modes. A mismatch results in connection establishment failure rather than automatic fallback. 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 the sequence used to establish transport security, not PCEP message formats or post-TLS PCEP state-machine behavior. The security properties after completion of the TLS handshake are equivalent to those obtained using RFC 8253. 6. IANA Considerations This document makes no IANA requests. 7. 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, . [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 Andrew Stone Nokia Email: andrew.stone@nokia.com Hooman Bidgoli Nokia Email: hooman.bidgoli@nokia.com Changwang Lin New H3C Technologies Email: linchangwang.04414@h3c.com Yisong Liu China Mobile Email: liuyisong@chinamobile.com