]> Huawei Technologies

dhruv.ietf@gmail.com

sn3rd

sean@sn3rd.com

Vigil Security, LLC

516 Dranesville Road Herndon, VA 20170 US housley@vigilsec.com

Routing PCE PCEP PCEPS TLS 1.3 TLS 1.2 Early Data 0-RTT RFC 8253 defines how to protect PCEP messages with TLS 1.2. This document updates RFC 8253 to address support requirements for TLS 1.2 and TLS 1.3 and the use of TLS 1.3's early data. Discussion Venues Discussion of this document takes place on the Path Computation Element Working Group mailing list (pce@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction defines how to protect PCEP messages with TLS 1.2 . This document updates to address support requirements for TLS 1.2 and TLS 1.3 and the use of TLS 1.3's early data, which is also known as 0-RTT data. All other provisions set forth in are unchanged, including connection initiation, message framing, connection closure, certificate validation, peer identity, and failure handling.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Early Data Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3 that allows a client to send data ("early data") as part of the first flight of messages to a server. Note that TLS 1.3 can be used without early data as per . In fact, early data is permitted by TLS 1.3 only when the client and server share a Pre-Shared Key (PSK), either obtained externally or via a previous handshake. The client uses the PSK to authenticate the server and to encrypt the early data. As noted in , the security properties for early data are weaker than those for subsequent TLS-protected data. In particular, early data is not forward secret, and there is no protection against the replay of early data between connections. requires applications not use early data without a profile that defines its use. This document specifies that PCEPS implementations that support TLS 1.3 MUST NOT use early data.

Cipher Suites Implementations MUST support TLS 1.2 and are REQUIRED to support the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite . Implementations MAY implement additional TLS 1.2 cipher suites that provide mutual authentication and confidentiality as required by PCEP. Implementations SHOULD support TLS 1.3 and, if implemented, MUST prefer to negotiate TLS 1.3 over earlier versions of TLS. Implementations that support TLS 1.3 are REQUIRED to support the mandatory-to-implement cipher suites listed in . Implementations that support TLS 1.3 MAY implement additional TLS 1.3 cipher suites that provide mutual authentication and confidentiality as required by PCEP. PCEPS Implementations SHOULD follow the recommendations given in .

Security Considerations The Security Considerations of PCEP , , , and ; TLS 1.2 ; TLS 1.3 , and; apply here as well. The Path Computation Element (PCE) defined in is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed. PCEP is the communication protocol between a PCC and PCE and is defined in . Stateful PCE specifies a set of extensions to PCEP to enable control of TE-LSPs by a PCE that retains the state of the LSPs provisioned in the network (a stateful PCE). describes the setup, maintenance, and teardown of LSPs initiated by a stateful PCE without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled. introduces the architecture for PCE as a central controller TLS mutual authentication is used to ensure that only authorized users and systems are able to send and receive PCEP messages. To this end, neither the PCC nor the PCE should establish a PCEPS with TLS connection with an unknown, unexpected, or incorrectly identified peer; see . If deployments make use of a trusted list of Certification Authority (CA) certificates , then the listed CAs should only issue certificates to parties that are authorized to access the PCE. Doing otherwise will allow certificates that were issued for other purposes to be inappropriately accepted by a PCE.

IANA Considerations There are no IANA considerations.

References Normative References The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP. This document updates RFC 5440 in regards to the PCEP initialization phase procedures. This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] Mozilla This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, and 8446. This document also specifies new requirements for TLS 1.2 implementations. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Informative References The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents. Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.

Acknowledgments We would like to thank Adrian Farrel for their review.