PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)
updates
- rfc-5440 — Path Computation Element (PCE) Communication Protocol (PCEP)
Extracted elements (29)
PCEPS uses the StartTLS mechanism rather than a dedicated port to avoid consuming a scarce port number allocation and to simplify PCEP configuration. The StartTLS procedure allows both secured and unsecured PCEP to share the same port.
A PCEP speaker not supporting PCEPS that receives a StartTLS message before Open will respond with PCErr Error-Type 1 Error-value 1 and close the session per RFC 5440 error mechanisms. A PCEPS-capable speaker sending Error-Type 25 errors to non-PCEPS peers will not be understood by those peers.
An existing PCEP session cannot be secured via TLS; the session MUST be closed and re-established with TLS. During incremental upgrade, the PCEP speaker SHOULD allow session establishment with and without TLS; once both ends support PCEPS, the session is re-established with TLS.
A PCC supporting PCEPS but allowing non-PCEPS connections MUST first try to establish PCEPS by sending a StartTLS message; if it receives a PCErr, it MAY retry without PCEPS. Re-establishing without TLS SHOULD be limited to only one attempt.
A PCC willing to apply DANE to verify server identity MUST conform to RFC 6698 Section 4 and MUST support service certificate constraint (TLSA usage type 1) with Matching type 1 (SHA2-256).
A PCEP speaker receiving a StartTLS message after any other PCEP exchange has taken place MUST treat it as an unexpected message, reply with PCErr Error-Type 25 Error-value 1 (Reception of StartTLS after any PCEP exchange), and MUST close the TCP connection.
A PCEP speaker supporting PCEPS MUST NOT start the OpenWait timer after TCP establishment; instead it starts the StartTLSWait timer. The first message sent by the PCC to the PCE and by the PCE to the PCC MUST be a StartTLS message for PCEPS.
Any connection established with a peer that cannot be properly identified SHALL be terminated before any PCEP exchange takes place. PCEPS implementations MUST provide a mechanism for establishing a default access level for properly identified peers.
Collision resolution procedures from RFC 5440 for Open message exchange MUST be applied by PCEP peers during the exchange of StartTLS messages.
For PKIX trust model: implementations MUST allow configuration of trusted CAs; certificate validation MUST include verification rules per RFC 5280; peer validation MUST follow RFC 6125 rules, including checking DNS names or IP addresses against the certificate. DNS-ID takes precedence over CN-ID for DNS validation; subjectAltName:iPAddr takes precedence over CN-ID for IP validation.
For the certificate fingerprint trust model, implementations MUST allow configuration of a list of trusted certificate fingerprints and MUST support SHA-256 as defined by FIPS 180-4 as the hash algorithm for fingerprints.
If a PCEP speaker only supports PCEPS and receives an Open message, it MUST treat it as an unexpected message, reply with PCErr Error-Type 1 Error-value 1, and MUST close the TCP connection.
In case TLS negotiation or peer identity check fails, both peers MUST immediately close the connection. The initiator SHOULD follow RFC 5440's exponential back-off retry procedure for session re-establishment.
Once TLS is established, the PCEP speaker MUST start the OpenWait timer per RFC 5440; if no Open message is received before it expires, the speaker sends PCErr and releases the TCP/TLS connection.
PCEP peers supporting PCEPS SHOULD default to strict TLS configuration (not allowing non-TLS PCEP sessions). Implementations MAY allow operator override, but SHOULD trigger a security warning when the override is executed.
PCEPS implementations MUST, at a minimum, support negotiation of TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. Implementations SHOULD support the NIST P-256 (secp256r1) curve.
The PCC SHALL act as the TLS client and the PCE SHALL act as the TLS server per RFC 5246, reflecting the asymmetric nature of TLS connection establishment.
The StartTLSWait timer MUST be started upon TCP connection establishment. A RECOMMENDED value is 60 seconds; if it expires without receiving StartTLS, PCErr, or Open, the speaker MUST send PCErr Error-Type 25 Error-value 5 and release the TCP connection. The StartTLSWait timer MUST NOT be less than the OpenWait timer.
TLS v1.2 or later is REQUIRED. Certificate-based mutual authentication is REQUIRED. Negotiation of a ciphersuite providing integrity protection is REQUIRED; confidentiality is RECOMMENDED.
The StartTLS message is a new PCEP message (Message-Type 13) sent by both PCC and PCE to initiate TLS negotiation before any other PCEP message exchange, including the Open message. It replaces the Open message as the first PCEP message in a PCEPS session.
A new PCEP message type value 13 (StartTLS) has been allocated in the 'PCEP Messages' sub-registry of the 'Path Computation Element Protocol (PCEP) Numbers' registry.
Error-Type 25 (PCEP StartTLS failure) has been allocated in the 'PCEP-ERROR Object Error Types and Values' sub-registry with error values: 1 (StartTLS after PCEP exchange), 2 (unexpected message before StartTLS/Open), 3 (TLS required, no fallback), 4 (TLS failed, non-TLS possible), 5 (StartTLSWait timer expiry).
Ciphersuites providing only integrity without encryption SHOULD NOT be used by default; administrators MAY allow them after explicitly weighing the risk of internal data leakage, as noted in RFC 6952's analysis of PCEP confidentiality requirements.
PCEPS implementations continuing to accept non-TLS connections are susceptible to downgrade attacks per RFC 7457. An attacker can remove StartTLS messages or inject a PCErr suggesting non-TLS reconnection, since StartTLS messages are sent in the clear before TLS is established.
TLS alone cannot address all PCEP threats; TCP Authentication Option (TCP-AO) per RFC 5925 is recommended as a complementary measure against attacks that forge the underlying TCP connection, especially for long-lived PCEP connections.
TLS handshake computational overhead is higher than unencrypted TCP, making PCEPS servers easier targets for denial-of-service attacks from malicious clients creating high-load conditions.
When using certificate fingerprints for peer identification, any two certificates producing the same hash value are considered the same peer. SHA-256 is mandated, but implementations should track cryptographic advances; a future revision may require stronger hash functions.
PCEPS session initialization proceeds through four states: (1) TCP connection established, (2) StartTLS messages exchanged in both directions, (3) TLS connection negotiated and established, (4) PCEP Open messages exchanged and session active. Any deviation from this ordering triggers an error.
The StartTLS message consists solely of the PCEP common header with the Message-Type field set to 13. No additional fields or objects are included: <StartTLS Message>::= <Common Header>.