RFC 8253

PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)

📅 published October 2017, from ietf

PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) 🎀

The Title Block 📋

  • RFC number: 8253
  • Authors: D. Lopez and O. Gonzalez de Dios (both from Telefonica I+D), plus Q. Wu and D. Dhody (both from Huawei)
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: October 2017
  • Updates: RFC 5440 (only for the PCEP initialization phase, more on that in the Abstract)
  • Obsoletes: nothing is listed

Abstract ✨

okay so PCEP (the Path Computation Element Communication Protocol) is the thing that lets a Path Computation Client (PCC) and a Path Computation Element (PCE) talk to each other, or lets PCEs talk to each other. this doc is all about PCEPS, which is just a fancy name for using Transport Layer Security (TLS) to make PCEP's transport secure 🔐. the extra security comes from the transport protocol that PCEP runs over, so PCEP stays just as flexible and extensible as it was, no cap 💅.

this doc also updates RFC 5440 when it comes to the PCEP initialization phase procedures 🦋

Status of This Memo 🌸

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8253.

Copyright (c) 2017 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 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.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents 📚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   5
3.  Applying PCEPS  . . . . . . . . . . . . . . . . . . . . . . .   5
  3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5
  3.2.  Initiating TLS Procedures . . . . . . . . . . . . . . . .   5
  3.3.  The StartTLS Message  . . . . . . . . . . . . . . . . . .   8
  3.4.  TLS Connection Establishment  . . . . . . . . . . . . . .  13
  3.5.  Peer Identity . . . . . . . . . . . . . . . . . . . . . .  15
  3.6.  Connection Establishment Failure  . . . . . . . . . . . .  16
4.  Discovery Mechanisms  . . . . . . . . . . . . . . . . . . . .  16
  4.1.  DANE Applicability  . . . . . . . . . . . . . . . . . . .  17
5.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .  17
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
  6.1.  New PCEP Message  . . . . . . . . . . . . . . . . . . . .  18
  6.2.  New Error-Values  . . . . . . . . . . . . . . . . . . . .  19
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
8.  Manageability Considerations  . . . . . . . . . . . . . . . .  20
  8.1.  Control of Function and Policy  . . . . . . . . . . . . .  20
  8.2.  Information and Data Models . . . . . . . . . . . . . . .  21
  8.3.  Liveness Detection and Monitoring . . . . . . . . . . . .  21
  8.4.  Verifying Correct Operations  . . . . . . . . . . . . . .  21
  8.5.  Requirements on Other Protocols . . . . . . . . . . . . .  22
  8.6.  Impact on Network Operation . . . . . . . . . . . . . . .  22
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  23
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  25
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1. Introduction 🌸

okay so PCEP ([RFC5440]) is the protocol that sets up the mechanisms for PCCs and PCEs to chat, or for two PCEs to chat with each other 💬. these conversations include requests and replies that can be super critical for keeping a network running smoothly and allocating resources properly, so security is a key piece of the PCE infrastructure 🔥. as PCE apps grow and the service patterns get more complicated, having a secure mode of operation becomes way more relevant ✨.

the Security Considerations section of [RFC5440] goes through the threats to PCEP and what they could cause 😭. it also talks about a bunch of ways to protect PCEP from attacks, but it doesn't pick one specific option or explain how to apply it in depth 🙈. then [RFC6952] points out how important it is to keep PCEP communication confidential, especially when the endpoints aren't in the same Autonomous System (AS). why? because if someone intercepts PCEP messages, they could leak sensitive info about computed paths and resources 👀.

Transport Layer Security (TLS) [RFC5246] seems like the most solid option out of everything mentioned in those docs 🔐. it supports peer authentication, message encryption, and integrity. TLS also comes with well-known ways to handle key configuration and exchange, plus ways to do security checks on the results of PCE Discovery (PCED) procedures done through the Interior Gateway Protocol (IGP) [RFC5088] [RFC5089] 🧚.

this doc describes a security container for carrying PCEP messages, so again, it doesn't affect PCEP's flexibility and extensibility 🦋.

here's what this doc covers: how to apply TLS to secure interactions with a PCE, including starting the TLS procedures, the TLS handshake mechanism, the TLS methods for peer authentication, the TLS ciphersuites that are applicable for data exchange, and how errors in the security checks get handled 💅. from here on out, we're calling this use of TLS to secure PCEP "PCEPS" 🎀.

PCEP communications are described here through a PCC-PCE relationship. the PCE architecture also supports PCE-PCE communication, and that works by asking the PCE to take on the PCC role, as usual. so in this doc, "PCC" refers to a PCC or a PCE that starts the PCEP session and acts as the client 🫶.

2. Requirements Language 💜

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.

3. Applying PCEPS 🍓

3.1. Overview 🧚

the steps for setting up a PCEPS session go like this 👑:

  1. Establishment of a TCP connection.
  2. Initiation of the TLS procedures by the StartTLS message from PCE to PCC and from PCC to PCE.
  3. Negotiation and establishment of a TLS connection.
  4. Start exchange of PCEP messages as per [RFC5440].

this doc uses the standard StartTLS procedure in PCEP instead of a different port for the secured session 💖. the reason is that this avoids asking for another port number just for PCEPS. StartTLS uses scarce port numbers more efficiently and makes PCEP simpler to configure 🌈.

Implementations SHOULD follow the best practices and recommendations for using TLS, as per [RFC7525] ✨.

it should be noted that this procedure updates what is defined in Sections 4.2.1 and 6.7 of [RFC5440] regarding the initialization phase and the processing of messages prior to the Open message. the details of processing, including backward compatibility, are discussed in the following sections 🙈

next up: Section 3.2, "Initiating TLS Procedures," where the StartTLS handshake starts getting real 👀🔥

3.2. Initiating TLS Procedures ✨

okay so PCEP can run with TLS or without it, which means a PCEP speaker has to say whether it wants a TLS connection 🔐 bestie, this is where the StartTLS message comes in. This document defines it as a brand new PCEP message, so the PCEP session is secured via TLS from the very start 💖 that happens before any other PCEP message gets exchanged, including the Open message 😭 this document also updates [RFC5440], which said the Open message had to be the first PCEP message ever, so it's a big plot twist 🎀 when TLS is in use, the StartTLS message goes first 🌸 and a PCEP speaker that supports PCEPS MUST NOT start the OpenWait timer after TCP establishment. Instead it starts a StartTLSWait timer, as described in Section 3.3 🧚

the PCEP speaker MAY find out that its peer supports PCEPS, or it can be preconfigured to use PCEPS for a given peer (see Section 4 for more details) 👑 but an existing PCEP session can't be upgraded to TLS midway through 🙈 so the session MUST be closed and re-established with TLS, following the procedure in this document. no shortcuts, periodt 💅

the StartTLS message is a PCEP message that a PCC sends to a PCE, and a PCE sends to a PCC, to kick off the TLS procedure for PCEP ✨ the PCC starts using TLS by sending a StartTLS message 🦋 and the PCE says "yes, let's do TLS" by replying with its own StartTLS message 🫶 if the PCE is set up to only do TLS, it MAY send its StartTLS message right away once TCP is up. otherwise it MUST wait and see whether the PCC's first message is an Open or a StartTLS message 👀 the TLS negotiation and establishment steps kick off once the PCEP speaker has both sent and received the StartTLS message. the Message-Type field in the PCEP common header for StartTLS is set to 13 🍓

once TCP is successfully established, the very first message from the PCC to the PCE, and from the PCE to the PCC, MUST be a StartTLS message for PCEPS 💜 this is a major glow-up from [RFC5440], where the first PCEP message was the Open message 😤

a PCEP speaker that gets a StartTLS message after some other PCEP exchange has already happened (sending or receiving any messages from either side) MUST treat it as an unexpected message 🚫 it replies with a PCEP Error (PCErr) message with Error-Type set to 25 (PCEP StartTLS failure) and Error-value set to 1 (Reception of StartTLS after any PCEP exchange), and then it MUST close the TCP connection. yikes, main character drama 💀

any message that shows up before the StartTLS or Open message MUST trigger a protocol error condition 🚨 which causes a PCErr message with Error-Type set to 25 (PCEP StartTLS failure) and Error-value set to 2 (Reception of any other message apart from StartTLS, Open, or PCErr). then the speaker MUST close the TCP connection 🥲

if a PCEP speaker that doesn't support PCEPS gets a StartTLS message, it just follows the existing error mechanism in Section 6.2 of [RFC5440] (if the message shows up before an Open message) or Section 6.9 of [RFC5440] (if it's an unknown message) 🧸 see Section 5 for more details ✨

if a PCEP speaker that only supports PCEPS connections (that's a local policy thing 🔒) gets an Open message, it MUST treat it as an unexpected message 🙅‍♀️ it replies with a PCErr message with Error-Type set to 1 (PCEP session establishment failure) and Error-value set to 1 (reception of an invalid Open message or a non Open message), and then it MUST close the TCP connection. not it 💅

if a PCC supports PCEPS and also allows non-PCEPS connections (local policy again 💭), it MUST try PCEPS first by sending a StartTLS message. if it gets a PCErr message back from the PCE, it MAY retry without PCEPS by sending an Open message 🌈 if a PCE supports PCEPS and allows non-PCEPS connections (local policy, iykyk), it MUST wait to respond after TCP establishment, depending on what message it gets from the PCC 🫧 if that's a StartTLS message, the PCE MUST respond with its own StartTLS message and move on to the TLS establishment procedures described in this document 🔐 if it's an Open message, the PCE MUST respond with an Open message and move on to the PCEP session establishment procedure from [RFC5440] 🦋 and if a PCE only supports PCEPS connections (local policy), it MAY send a StartTLS message to the PCC without waiting for a StartTLS message from the PCC first 🚀

⚠️ if a PCEP speaker is unwilling or unable to negotiate TLS and gets a StartTLS message, it MUST return a PCErr message (in the clear) with Error-Type set to 25 (PCEP StartTLS failure) and Error-value set to one of the two options below. no vibes-based guessing here 😤
  • 3 (Failure, connection without TLS is not possible) if it's not willing to exchange PCEP messages without the solicited TLS connection. In this case it MUST close the TCP session 🚪
  • 4 (Failure, connection without TLS is possible) if it is willing to exchange PCEP messages without the solicited TLS connection. In this case it MUST also close the TCP session. The receiver MAY choose to try re-establishing the PCEP session without TLS next, and re-establishing the PCEP session without TLS SHOULD be limited to only one attempt 🔁

if the PCEP speaker supports PCEPS and can establish a TLS connection, it MUST start the TLS connection negotiation and establishment steps described in Section 3.4 before the PCEP initialization procedure (see Section 4.2.1 of [RFC5440]) 🎀

after the StartTLS messages have been exchanged, if the TLS negotiation fails for some reason (for example, the mechanisms needed for certificate revocation checking aren't available), both peers MUST immediately close the connection 🛑 no awkward lingering, bye bye 👋

a PCEP speaker that doesn't support PCEPS just sends the Open message directly, as per [RFC5440] 🧁 a PCEP speaker that does support PCEPS, but learned in the last exchange that its peer is willing to re-establish the session without TLS, MAY send the Open message directly too, as per [RFC5440] 🌷 and again, re-establishing the PCEP session without TLS SHOULD be limited to only one attempt ✨

since TLS is asymmetric when it comes to connection establishment, it's important to know which PCEP peer plays which role 🎭 the PCC SHALL act as the TLS client, and the PCE SHALL act as the TLS server, as per [RFC5246] 🫶

as recommended in [RFC7525] to avoid downgrade attacks 🥷, PCEP peers that support PCEPS SHOULD default to strict TLS configuration, which means not allowing non-TLS PCEP sessions to be established 🔒 PCEPS implementations MAY provide an option that lets the operator manually override strict TLS configuration and allow unsecured connections. if someone uses that override, it SHOULD trigger a warning about the security implications of permitting unsecured connections ⚠️🌸

3.3. The StartTLS Message ✨

okay so the StartTLS message is the thing that kicks off the TLS procedure for a PCEPS session between the PCEP peers 💅. A PCEP speaker sends it to ask for TLS to be negotiated and set up for PCEP 🔐. When a PCEP speaker has both sent and received a StartTLS message, it's ready to start negotiating and establishing TLS, and then it moves on to the steps in Section 3.4 🦋.

The collision resolution procedures in [RFC5440] for exchanging Open messages MUST be applied by the PCEP peers during the exchange of StartTLS messages 💜. No skipping this one, bestie 🙈.

Here's the format of a StartTLS message 🎀:

<StartTLS Message>::= <Common Header>

A StartTLS message MUST contain only the PCEP common header, with the Message-Type field set to 13 🍓. That's the whole message, no extras, no cap 🧚.

Once the TCP connection is successfully established, the PCEP speaker MUST start a timer called the "StartTLSWait timer" ⏰. If that timer expires and the speaker has received neither a StartTLS message nor a PCErr/Open message (the PCErr/Open is for when something failed, or when the peer doesn't support PCEPS) 😭, then the PCEP speaker MUST send a PCErr message with Error-Type set to 25 (PCEP StartTLS failure) and Error-value set to 5 (No StartTLS message (nor PCErr/Open) before StartTLSWait timer expiry) 💀. It MUST also release the TCP connection, and that's the end of that 🥀. A RECOMMENDED value for the StartTLSWait timer is 60 seconds ⭐. The value of the StartTLSWait timer MUST NOT be less than that of the OpenWait timer 👑, so don't go lower than that, periodt.

The figures below show the different ways a PCC and a PCE can interact during PCEP session initialization, depending on whether they support the PCEPS capability 🌈. Lowkey the best part of this whole section 🫶.

                  +-+-+                 +-+-+
                  |PCC|                 |PCE|
                  +-+-+                 +-+-+
                    |                     |
                    | StartTLS            |
                    | msg                 |
                    |-------              |
                    |       \   StartTLS  |
                    |        \  msg       |
                    |         \  ---------|
                    |          \/         |
                    |          /\         |
                    |         /  -------->|
                    |        /            |
                    |<------              |
                    |:::::::::TLS:::::::::|
                    |:::::Establishment:::|
                    |                     |
                    |                     |
                    |:::::::PCEP::::::::::|
                    |                     |

            Figure 1: Both PCEP speakers support PCEPS (strict)
                  +-+-+                 +-+-+
                  |PCC|                 |PCE|
                  +-+-+                 +-+-+
                    |                     |
                    | StartTLS            |
                    | msg                 |
                    |-------              |
                    |       \   StartTLS  |
                    |        \  msg       |
                    |         \  ---------|
                    |          \/         |
                    |          /\         |
                    |         /  -------->|
                    |        /            |
                    |<------              |
                    |:::::::::TLS:::::::::| TLS Establishment
                    |:::::Establishment:::| Failure; both
                    |                     | peers close
                                            the session

      Figure 2: Both PCEP speakers support PCEPS (strict) but cannot
                               establish TLS
                  +-+-+                 +-+-+
                  |PCC|                 |PCE|
                  +-+-+                 +-+-+
                    |                     |  Does not support
                    | StartTLS            |  PCEPS and thus
                    | msg                 |  sends Open
                    |-------              |
                    |       \   Open      |
                    |        \  msg       |
                    |         \  ---------|
                    |          \/         |
                    |          /\         |
                    |         /  -------->|
                    |        /            |
                    |<------              |
                    |                     |
                    |<--------------------| Send Error
                    |       PCErr         | Type=1,Value=1
                    |                     | (non-Open message
                    |<--------------------|  received)
                    |       Close         |
                    ///////// TCP /////////
                    //////re-establish/////
          Send Open | Open                |
          this time | msg                 |
                    |-------              |
                    |       \   Open      |
                    |        \  msg       |
                    |         \  ---------|
                    |          \/         |
                    |          /\         |
                    |         /  -------->|
                    |        /            |
                    |<------              |

     Figure 3: PCE does not support connection with PCEPS, whereas PCC
                 supports connection with or without PCEPS
                  +-+-+                 +-+-+
                  |PCC|                 |PCE|
                  +-+-+                 +-+-+
                    |                     |
                    | StartTLS            |
                    | msg                 | PCE waits
                    |-------------------->| for PCC and
                    |            StartTLS | responds with
                    |<--------------------| Start TLS
                    |                     |
                    |:::::::::TLS:::::::::|
                    |:::::Establishment:::|
                    |                     |
                    |                     |
                    |:::::::PCEP::::::::::|
                    |                     |

   Figure 4: Both PCEP speakers support connection with or without PCEPS
                  +-+-+                 +-+-+
                  |PCC|                 |PCE|
                  +-+-+                 +-+-+
                    |                     |
                    | StartTLS            |
                    | msg                 | PCE waits
                    |-------------------->| for PCC
                    |               PCErr |
                    |<--------------------| Send Error
                    |                     | Type=25,Value=3
                    |                     | (Failure, connection
                    |<--------------------|  without TLS is not
                    |       Close         |  possible)

      Figure 5: Both PCEP speakers support connection with or without
                PCEPS, but PCE cannot start TLS negotiation
                  +-+-+                 +-+-+
                  |PCC|                 |PCE|
                  +-+-+                 +-+-+
                    |                     |
                    | Open                |
                    | msg                 | PCE waits
                    |-------------------->| for PCC and
                    |                Open | responds with
                    |<--------------------| Open
                    |                     |
                    |:::::::PCEP::::::::::|
                    |                     |

   Figure 6: PCE supports connection with or without PCEPS, whereas PCC
                  does not support connection with PCEPS

3.4. TLS Connection Establishment ✨

Okay so once the PCEP peers have agreed to do TLS, the connection setup SHALL go through these steps 💅

  1. Immediately negotiate a TLS session according to [RFC5246]. These are the restrictions, bestie 🎀
    • Support for TLS v1.2 [RFC5246] or later is REQUIRED. No cap, this is the baseline 👑
    • Support for certificate-based mutual authentication is REQUIRED. Both sides prove who they are 🫶
    • Negotiation of a ciphersuite providing for integrity protection is REQUIRED. Your data can't be secretly messed with 🔒
    • Negotiation of a ciphersuite providing for confidentiality is RECOMMENDED. Keeping things private is highkey the move 🤫
    • Support for and negotiation of compression is OPTIONAL. Totally your call 🦋
    • PCEPS implementations MUST, at a minimum, support negotiation of the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC6460] and SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as well. Implementations SHOULD support the NIST P-256 (secp256r1) curve [RFC4492]. On top of that, PCEPS implementations MUST support negotiation of the mandatory-to-implement ciphersuites required by the versions of TLS that they support from TLS 1.3 onwards. The ciphersuite lineup is giving main character energy 🌈
  2. Peer authentication can be performed in any of the following two REQUIRED operation models. Two options, both essential 💜
    • TLS with X.509 certificates using Public-Key Infrastructure Exchange (PKIX) trust models:
      • Implementations MUST allow the configuration of a list of trusted Certification Authorities (CAs) for incoming connections. Make a guest list of who you trust 📝
      • Certificate validation MUST include the verification rules as per [RFC5280]. Check everything, periodt 🔍
      • PCEPS implementations SHOULD incorporate revocation methods (Certificate Revocation List (CRL) downloading, Online Certificate Status Protocol (OCSP), etc.) according to the trusted CA policies. Revocation is the plot twist you want to be ready for 😭
      • Implementations SHOULD indicate their trusted CAs. For TLS 1.2, this is done using certificate_authorities on the server side (see Section 7.4.4 of [RFC5246]) and the TrustedAuthorities extension on the client side (see Section 6 of [RFC6066]). Say who you trust out loud 📣
      • Implementations MUST follow the rules and guidelines for peer validation as defined in [RFC6125]. If an expected DNS name or IP address for the peer is configured, then the implementations MUST check them against the values in the presented certificate. The DNS names and the IP addresses can be contained in the Common Name Identifier (CN-ID) [RFC6125] or the subjectAltName entries. For verification, only one of these entries is considered. The following precedence applies: for DNS name validation, DNS-ID [RFC6125] has precedence over CN-ID, and for IP address validation, subjectAltName:iPAddr has precedence over CN-ID. Precedence rules are a whole vibe 💅
      • Implementations MAY allow the configuration of a set of additional properties of the certificate to check for a peer's authorization to communicate (e.g., a set of allowed values in URI-ID [RFC6125] or a set of allowed X.509 v3 Certificate Policies). The definitions of these properties are out of scope of this document. Extra checks are optional, and that's a whole different story 🧚
    • TLS with X.509 certificates using certificate fingerprints: Implementations MUST allow the configuration of a list of certificates that are trusted to identify peers, identified via the fingerprint of certificate octets encoded by the Distinguished Encoding Rules (DER). Implementations MUST support SHA-256 as defined by [SHS] as the hash algorithm for the fingerprint, but a later revision may demand support for a stronger hash function. Fingerprints are the lowkey simple option, and SHA-256 is the baseline 🍓
  3. Start exchanging PCEP messages. Time to chat 💬
    • Once the TLS connection has been successfully established, the PCEP speaker MUST start the OpenWait timer [RFC5440]; after the expiration of this timer, if no Open message has been received, the PCEP speaker sends a PCErr message and releases the TCP/TLS connection. If the Open message doesn't show up in time, it's a PCErr and a goodbye 👋

3.5. Peer Identity 🪪

Depending on the peer authentication method in use, PCEPS supports different operation modes to establish a peer's identity and whether it is entitled to perform requests or can be considered authoritative in its replies. PCEPS implementations SHOULD provide mechanisms for associating peer identities with different levels of access and/or authoritativeness, and they MUST provide a mechanism for establishing a default level for properly identified peers. Any connection established with a peer that cannot be properly identified SHALL be terminated before any PCEP exchange takes place. No mystery peers allowed, bestie 🚫

In TLS X.509 mode using fingerprints, a peer is uniquely identified by the fingerprint of the presented certificate. The fingerprint is basically the peer's ID card 🪪

There are numerous trust models in PKIX environments, and it is beyond the scope of this document to define how a particular deployment determines whether a peer is trustworthy. Implementations that want to support a wide variety of trust models should expose as many details of the presented certificate to the administrator as possible so that the trust model can be implemented by the administrator. At least the following parameters of the X.509 certificate SHOULD be exposed:

  • Peer's IP Address
  • Peer's Fully Qualified Domain Name (FQDN)
  • Certificate Fingerprint
  • Issuer
  • Subject
  • All X.509 v3 Extended Key Usage
  • All X.509 v3 Subject Alternative Name
  • All X.509 v3 Certificate Policies

Note that the remote IP address used for the TCP session establishment is also exposed. Even the IP address spills the tea 🫣

[RFC8232] specifies a Speaker Entity Identifier TLV (SPEAKER-ENTITY-ID) as an optional TLV that is included in the OPEN object. It contains a unique identifier for the node that does not change during the lifetime of the PCEP speaker. An implementation would thus expose the speaker entity identifier as part of the X.509 v3 certificate's subjectAltName:otherName, so that an implementation could use this identifier for the peer identification trust model. A permanent name tag, iconic 🌸

In addition, a PCC MAY apply the procedures described in "DNS-Based Authentication of Named Entities (DANE)" [RFC6698] to verify its peer identity when using DNS discovery. See Section 4.1 for further details. DANE is an optional extra layer, and it's giving extra verified 🧁

3.6. Connection Establishment Failure 💀

In case the initial TLS negotiation or the peer identity check fails, according to the procedures listed in this document, both peers MUST immediately close the connection. If the handshake or the identity check flops, it's an instant ghost 👻

The initiator SHOULD follow the procedure listed in [RFC5440] to retry session setup as per the exponential back-off session establishment retry procedure. Try again, but give it some space 🌙

4. Discovery Mechanisms 🧭

This document does not specify any discovery mechanism for support of PCEPS. [PCE-DISCOVERY-PCEPS-SUPPORT] and [PCE-DISCOVERY-DNS] make the following proposals:

  • A PCE can advertise its capability to support PCEPS using the IGP's advertisement mechanism of the PCED information. The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to advertise PCE capabilities. It is present within the PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] provide the description and processing rules for this sub-TLV when carried within OSPF and IS-IS, respectively. PCE capability bits are defined in [RFC5088]. A new capability flag bit for the PCE-CAP-FLAGS sub-TLV that can be announced as an attribute to distribute PCEP security support information is proposed in [PCE-DISCOVERY-PCEPS-SUPPORT]. IGP ads, but make it secure 📡
  • A PCE can advertise its capability to support PCEPS using DNS [PCE-DISCOVERY-DNS] by identifying the support of TLS. Put it in DNS and let the internet gossip 🗣️

4.1. DANE Applicability 🔐

DANE [RFC6698] defines a secure method to associate the certificate that is obtained from a TLS server with a domain name using DNS, i.e., using the TLSA DNS resource record (RR) to associate a TLS server certificate or public key with the domain name where the record is found, thus forming a "TLSA certificate association". The DNS information needs to be protected by DNS Security (DNSSEC). A PCC willing to apply DANE to verify server identity MUST conform to the rules defined in Section 4 of [RFC6698]. The implementation MUST support service certificate constraint (TLSA certificate usages type 1) with Matching type 1 (SHA2-256) as described in [RFC6698] and [RFC7671]. The server's domain name must be authorized separately, as TLSA does not provide any useful authorization guarantees. DANE only goes so far, so the name needs its own check 🫠

5. Backward Compatibility ✨

Okay so this section is all about how PCEPS plays nice with older PCEP speakers 🦋 The big idea: the security container is built so it doesn't mess with implementations that don't speak PCEPS at all. Honestly, that's so iconic of them 💅

A PCC that does not support PCEPS will send an Open message as the first message on TCP establishment. 🌸 A PCE that only supports PCEPS will send a StartTLS message on TCP establishment. 🫶 The PCC would consider the received StartTLS message as an error and behave according to the existing error mechanism of [RFC5440], i.e., it would send a PCErr message with Error-Type 1 (PCEP session establishment failure) and Error-value 1 (reception of an invalid Open message or a non Open message) and close the session. 😭

A PCC that support PCEPS will send a StartTLS message as the first message on TCP establishment. 🎀 A PCE that does not support PCEPS would consider receiving a StartTLS message as an error, respond with a PCErr message with Error-Type 1 (PCEP session establishment failure) and Error-value 1 (reception of an invalid Open message or a non Open message), and close the session. 💀

If a StartTLS message is received at any other time by a PCEP speaker that does not implement PCEPS, it would consider it as an unknown message and would behave according to the existing error mechanism of [RFC5440], i.e., it would send a PCErr message with Error-Type 2 (Capability not supported) and close the session. 🙈

An existing PCEP session cannot be upgraded to PCEPS; the session needs to be terminated and re-established as per the procedure described in this document. 🧚 During the incremental upgrade, the PCEP speaker SHOULD allow session establishment with and without TLS. Once both PCEP speakers are upgraded to support PCEPS, the PCEP session is re-established with TLS; otherwise, a PCEP session without TLS is set up. A redundant PCE MAY also be used during the incremental deployment to take over the PCE undergoing upgrade. Once the upgrade is completed, support for the unsecured version SHOULD be removed. 👑

A PCE that accepts connections with or without PCEPS would respond based on the message received from the PCC. A PCC that supports connection with or without PCEPS would first attempt to connect with PCEPS, and in case of error, it MAY retry to establish connection without PCEPS. For successful TLS operations with PCEP, both PCEP peers in the network would need to be upgraded to support this document. 🍓

Note that a PCEP implementation that supports PCEPS would respond with a PCErr message with Error-Type set to 25 (PCEP StartTLS failure) and Error-value set to 2 (Reception of any other message apart from StartTLS, Open, or PCErr) if any other message is sent before a StartTLS or Open message. If the sender of the invalid message is a PCEP implementation that does not support PCEPS, it will not be able to understand this error. A PCEPS implementation could also send the PCErr message as per [RFC5440] with Error-Type 1 (PCEP session establishment failure) and Error-value 1 (reception of an invalid Open message or a non Open message) before closing the session. 🌈

6. IANA Considerations 🎀

6.1. New PCEP Message 🦋

The following new message type has been allocated within the "PCEP Messages" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry:

   Value      Description                    Reference
   -------------------------------------------------------
   13         StartTLS                       This document

6.2. New Error-Values 💅

The following new error types and error values have been allocated within the "PCEP-ERROR Object Error Types and Values" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry:

   Error-Type   Meaning           Error-value             Reference
   ---------------------------------------------------------------------
    25          PCEP StartTLS     0: Unassigned            This document
                failure
                                  1: Reception of          This document
                                  StartTLS after
                                  any PCEP exchange

                                  2: Reception of          This document
                                  any other message
                                  apart from StartTLS,
                                  Open, or PCErr

                                  3: Failure, connection   This document
                                  without TLS is not
                                  possible

                                  4: Failure, connection   This document
                                  without TLS is
                                  possible

                                  5: No StartTLS message   This document
                                  (nor PCErr/Open)
                                  before StartTLSWait
                                  timer expiry

7. Security Considerations 🔥

Okay bestie, this part is SERIOUS, so read it carefully 🙈

While the application of TLS satisfies the requirement on confidentiality as well as fine-grained, policy-based peer authentication, there are security threats that it cannot address. It may be advisable to apply additional protection measures, in particular in what relates to attacks specifically addressed to forging the TCP connection underpinning TLS, especially in the case of long-lived connections. One of these measures is the application of the TCP Authentication Option (TCP-AO) [RFC5925], which is fully compatible with and deemed as complementary to TLS. The mechanisms to configure the requirements to use TCP-AO and other lower-layer protection measures with a particular peer are outside the scope of this document. ✨

Since computational resources required by the TLS handshake and ciphersuite are higher than unencrypted TCP, clients connecting to a PCEPS server can more easily create high-load conditions, and a malicious client might create a denial-of-service attack more easily. 😭

Some TLS ciphersuites only provide integrity validation of their payload and provide no encryption; such ciphersuites SHOULD NOT be used by default. Administrators MAY allow the usage of these ciphersuites after careful weighting of the risk of relevant internal data leakage that can occur in such a case, as explicitly stated by [RFC6952]. 🫶

When using certificate fingerprints to identify PCEPS peers, any two certificates that produce the same hash value will be considered the same peer. Therefore, it is important to make sure that the hash function used is cryptographically uncompromised, so that attackers are very unlikely to be able to produce a hash collision with a certificate of their choice. This document mandates support for SHA-256 as defined by [SHS], but a later revision may demand support for stronger functions if suitable attacks on it are known. 🔐

PCEPS implementations that continue to accept connections without TLS are susceptible to downgrade attacks as described in [RFC7457]. An attacker could attempt to remove the use of StartTLS messages that request the use of TLS as it pass on the wire in clear and could also attempt to inject a PCErr message that suggests attempting PCEP connection without TLS. 💀

The guidance given in [RFC7525] SHOULD be followed to avoid attacks on TLS. 🌸

8. Manageability Considerations 🧚

All manageability requirements and considerations listed in [RFC5440] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply. 🍓

8.1. Control of Function and Policy 👑

A PCE or PCC implementation SHOULD allow configuring the PCEP security via TLS capabilities as described in this document.

A PCE or PCC implementation supporting PCEP security via TLS MUST support general TLS configuration as per [RFC5246]. At least the configuration of one of the trust models and its corresponding parameters, as described in Sections 3.4 and 3.5, MUST be supported by the implementation. 🎀

A PCEPS implementation SHOULD allow configuring the StartTLSWait timer value.

PCEPS implementations MAY provide an option to allow the operator to manually override strict TLS configuration and allow unsecure connections. Execution of this override SHOULD trigger a warning about the security implications of permitting unsecure connections. ⚠️

Further, the operator needs to develop suitable security policies around PCEP within his network. The PCEP peers SHOULD provide ways for the operator to complete the following tasks in regards to a PCEP session:

  • Determine if a session is protected via PCEPS.
  • Determine the version of TLS, the mechanism used for authentication, and the ciphersuite in use.
  • Determine if the certificate could not be verified and the reason for this circumstance.
  • Inspect the certificate offered by the PCEP peer.
  • Be warned if the StartTLS procedure fails for the PCEP peers that are known to support PCEPS via configurations or capability advertisements. 🦋

8.2. Information and Data Models 🌈

The PCEP MIB module is defined in [RFC7420]. The MIB module could be extended to include the ability to view the PCEPS capability, TLS-related information, and the TLS status for each PCEP peer.

Further, to allow the operator to configure the PCEPS capability and various TLS-related parameters as well as to view the current TLS status for a PCEP session, the PCEP YANG module [PCEP-YANG] is extended to include TLS-related information. 💜

8.3. Liveness Detection and Monitoring 💖

Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440] and [RFC5246].

8.4. Verifying Correct Operations ⭐

A PCEPS implementation SHOULD log error events and provide PCEPS failure statistics with reasons.

8.5. Requirements on Other Protocols 🧚

Mechanisms defined in this document do not imply any new requirements on other protocols. Note that Section 4 lists possible discovery mechanisms for support of PCEPS. 🫶

8.6. Impact on Network Operation 🍓

Mechanisms defined in this document do not have any significant impact on network operations in addition to those already listed in [RFC5440] and on the policy and management implications discussed above. 🌸

9. References 📚

9.1. Normative References 📚

Okay bestie, the references are the receipts 🧾✨ Here are the normative ones, the stuff you need to read before this spec makes sense:

9.2. Informative References 💡

These ones are the extra reading, the "ooh, tell me more" pile 📖:

Acknowledgements 🫶

Okay the shoutouts are my favourite part, so let's go 💖

This spec leans on the analysis and profiling of TLS in [RFC6614], plus the StartTLS procedures described in [RFC4513]. Huge thanks to Joe Touch for the suggestions and support on the StartTLS stuff 🙌

Thanks to Daniel King for nudging the authors about manageability considerations ✨

Thanks to Cyril Margaria for shepherding this document 🎀

Thanks to David Mandelberg for the early SECDIR review comments, and for sticking around for more review during IETF last call 🔍

Thanks to Dan Frost for the RTGDIR review and comments 🛤️

Thanks to Dale Worley for the Gen-ART review and comments 🧵

Thanks to Tianran Zhou for the OPSDIR review 🌷

Thanks to Deborah Brungard for being the responsible AD and guiding the authors as needed 👑

And also, thanks to Mirja Kuhlewind, Eric Rescorla, Warren Kumari, Kathleen Moriarty, Suresh Krishnan, Ben Campbell, and Alexey Melnikov for the IESG review and comments. The whole squad showed up 🥹💅

Authors' Addresses 📮

Here's how to reach the authors, bestie:

Diego R. Lopez
Telefonica I+D
Don Ramon de la Cruz, 82
Madrid  28006
Spain

Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com
Oscar Gonzalez de Dios
Telefonica I+D
Don Ramon de la Cruz, 82
Madrid  28006
Spain

Phone: +34 913 129 041
Email: oscar.gonzalezdedios@telefonica.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu  210012
China

Email: sunseawq@huawei.com
Dhruv Dhody
Huawei
Divyashree Techno Park, Whitefield
Bangalore, KA  560066
India

Email: dhruv.ietf@gmail.com

That's the whole RFC, periodt 🌈💅✨

📦 where this page comes from