diff options
Diffstat (limited to 'doc/rfc/rfc8253.txt')
| -rw-r--r-- | doc/rfc/rfc8253.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc8253.txt b/doc/rfc/rfc8253.txt new file mode 100644 index 0000000..92974c9 --- /dev/null +++ b/doc/rfc/rfc8253.txt @@ -0,0 +1,1459 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Lopez +Request for Comments: 8253 O. Gonzalez de Dios +Updates: 5440 Telefonica I+D +Category: Standards Track Q. Wu +ISSN: 2070-1721 D. Dhody + Huawei + October 2017 + + + PCEPS: Usage of TLS to Provide a Secure Transport for the + Path Computation Element Communication Protocol (PCEP) + +Abstract + + 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. + +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. + + + + + + + + + + + + +Lopez, et al. Standards Track [Page 1] + +RFC 8253 PCEPS October 2017 + + +Copyright Notice + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Lopez, et al. Standards Track [Page 2] + +RFC 8253 PCEPS October 2017 + + +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 + + + + + + + + + + + + + + + + + + + + + +Lopez, et al. Standards Track [Page 3] + +RFC 8253 PCEPS October 2017 + + +1. Introduction + + The Path Computation Element Communication Protocol (PCEP) [RFC5440] + defines the mechanisms for the communication between a Path + Computation Client (PCC) and a Path Computation Element (PCE), or + between two PCEs. These interactions include requests and replies + that can be critical for a sustainable network operation and adequate + resource allocation; therefore, appropriate security becomes a key + element in the PCE infrastructure. As the applications of the PCE + framework evolve and more complex service patterns emerge, the + definition of a secure mode of operation becomes more relevant. + + The Security Considerations section of [RFC5440] analyzes the + potential threats to PCEP and their consequences; it also discusses + several mechanisms for protecting PCEP against security attacks, + without making a specific recommendation on a particular one or + defining their application in depth. Moreover, [RFC6952] states the + importance of ensuring PCEP communication confidentiality, especially + when PCEP communication endpoints do not reside in the same + Autonomous System (AS), as the interception of PCEP messages could + leak sensitive information related to computed paths and resources. + + Transport Layer Security (TLS) [RFC5246] is one of the solutions that + seems most adequate among those mentioned in these documents, as it + provides support for peer authentication, message encryption, and + integrity. TLS provides well-known mechanisms to support key + configuration and exchange, as well as means to perform security + checks on the results of PCE Discovery (PCED) procedures via the + Interior Gateway Protocol (IGP) [RFC5088] [RFC5089]. + + This document describes a security container for the transport of + PCEP messages; therefore, it does not affect the flexibility and + extensibility of PCEP. + + This document describes how to apply TLS to secure interactions with + PCE, including initiation of the TLS procedures, the TLS handshake + mechanism, the TLS methods for peer authentication, the applicable + TLS ciphersuites for data exchange, and the handling of errors in the + security checks. In the rest of this document, we refer to this + usage of TLS to provide a secure transport for PCEP as "PCEPS". + + Within this document, PCEP communications are described through a + PCC-PCE relationship. The PCE architecture also supports PCE-PCE + communication; this is achieved by requesting the PCE to fill the + role of a PCC, as usual. Thus, in this document, the PCC refers to a + PCC or a PCE initiating the PCEP session and acting as a client. + + + + + +Lopez, et al. Standards Track [Page 4] + +RFC 8253 PCEPS October 2017 + + +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 involved in establishing a PCEPS session are as follows: + + 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 document uses the standard StartTLS procedure in PCEP instead of + using a different port for the secured session. This is done to + avoid requesting allocation of another port number for PCEPS. The + StartTLS procedure makes more efficient use of scarce port numbers + and allows simpler configuration of PCEP. + + 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. + +3.2. Initiating TLS Procedures + + Since PCEP can operate either with or without TLS, it is necessary + for a PCEP speaker to indicate whether it wants to set up a TLS + connection or not. For this purpose, this document specifies a new + PCEP message called "StartTLS". Thus, the PCEP session is secured + via TLS from the start, before the exchange of any other PCEP message + (including the Open message). This document thus updates [RFC5440], + which requires the Open message to be the first PCEP message that is + exchanged. In the case of a PCEP session using TLS, the StartTLS + + + +Lopez, et al. Standards Track [Page 5] + +RFC 8253 PCEPS October 2017 + + + message will be sent first. Also, a PCEP speaker that supports PCEPS + MUST NOT start the OpenWait timer after the TCP establishment; + instead, it starts a StartTLSWait timer as described in Section 3.3. + + The PCEP speaker MAY discover that the PCEP peer supports PCEPS or + can be preconfigured to use PCEPS for a given peer (see Section 4 for + more details). An existing PCEP session cannot be secured via TLS; + the session MUST be closed and re-established with TLS as per the + procedure described in this document. + + The StartTLS message is a PCEP message sent by a PCC to a PCE and by + a PCE to a PCC in order to initiate the TLS procedure for PCEP. The + PCC initiates the use of TLS by sending a StartTLS message. The PCE + agrees to the use of TLS by responding with its own StartTLS message. + If the PCE is configured to only support TLS, it may send the + StartTLS message immediately upon TCP connection establishment; + otherwise, it MUST wait to see if the PCC's first message is an Open + or a StartTLS message. The TLS negotiation and establishment + procedures are triggered once the PCEP speaker has sent and received + the StartTLS message. The Message-Type field of the PCEP common + header for the StartTLS message is set to 13. + + Once the TCP connection has been successfully established, the first + message sent by the PCC to the PCE and by the PCE to the PCC MUST be + a StartTLS message for PCEPS. Note that this is a significant change + from [RFC5440], where the first PCEP message is the Open message. + + A PCEP speaker receiving a StartTLS message, after any other PCEP + exchange has taken place (by receiving or sending any other messages + from either side), MUST treat it as an unexpected message and reply + 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 it MUST close the TCP connection. + + Any message received prior to the StartTLS or Open message MUST + trigger a protocol error condition causing a PCErr message to be sent + 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), and it MUST close the TCP connection. + + If the PCEP speaker that does not support PCEPS receives a StartTLS + message, it will behave according to the existing error mechanism + described in Section 6.2 of [RFC5440] (if the message is received + prior to an Open message) or Section 6.9 of [RFC5440] (if an unknown + message is received). See Section 5 for more details. + + + + + + +Lopez, et al. Standards Track [Page 6] + +RFC 8253 PCEPS October 2017 + + + If the PCEP speaker that only supports PCEPS connections (as a local + policy) receives an Open message, it MUST treat it as an unexpected + message and reply 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 it MUST close the + TCP connection. + + If a PCC supports PCEPS connections and allows non-PCEPS connections + (as a local policy), it MUST first try to establish PCEPS by sending + a StartTLS message, and in case it receives a PCErr message from the + PCE, it MAY retry to establish a connection without PCEPS by sending + an Open message. If a PCE supports PCEPS connections and allows + non-PCEPS connections (as a local policy), it MUST wait to respond + after TCP establishment, based on the message received from the PCC. + In case of a StartTLS message, the PCE MUST respond by sending a + StartTLS message and moving to TLS establishment procedures as + described in this document. In case of an Open message, the PCE MUST + respond with an Open message and move to the PCEP session + establishment procedure as per [RFC5440]. If a PCE supports PCEPS + connections only (as a local policy), it MAY send a StartTLS message + to the PCC without waiting to receive a StartTLS message from the + PCC. + + If a PCEP speaker that is unwilling or unable to negotiate TLS + receives 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: + + o 3 (Failure, connection without TLS is not possible) if it is not + willing to exchange PCEP messages without the solicited TLS + connection, and it MUST close the TCP session. + + o 4 (Failure, connection without TLS is possible) if it is willing + to exchange PCEP messages without the solicited TLS connection, + and it MUST close the TCP session. The receiver MAY choose to + attempt to re-establish the PCEP session without TLS next. + 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 exchange of StartTLS messages, if the TLS negotiation fails + for some reason (e.g., the required mechanisms for certificate + revocation checking are not available), both peers MUST immediately + close the connection. + + + +Lopez, et al. Standards Track [Page 7] + +RFC 8253 PCEPS October 2017 + + + A PCEP speaker that does not support PCEPS sends the Open message + directly, as per [RFC5440]. A PCEP speaker that supports PCEPS, but + has learned in the last exchange the peer's willingness to + re-establish the session without TLS, MAY send the Open message + directly, as per [RFC5440]. Re-establishing the PCEP session without + TLS SHOULD be limited to only one attempt. + + Given the asymmetric nature of TLS for connection establishment, it + is relevant to identify the roles of each of the PCEP peers in it. + The PCC SHALL act as the TLS client, and the PCE SHALL act as the TLS + server as per [RFC5246]. + + As per the recommendation from [RFC7525] to avoid downgrade attacks, + PCEP peers that support PCEPS SHOULD default to strict TLS + configuration, i.e., not allowing non-TLS PCEP sessions to be + established. PCEPS implementations MAY provide an option to allow + the operator to manually override strict TLS configuration and allow + unsecured connections. Execution of this override SHOULD trigger a + warning about the security implications of permitting unsecured + connections. + +3.3. The StartTLS Message + + The StartTLS message is used to initiate the TLS procedure for a + PCEPS session between the PCEP peers. A PCEP speaker sends the + StartTLS message to request negotiation and establishment of a TLS + connection for PCEP. On receiving a StartTLS message from the PCEP + peer (i.e., when the PCEP speaker has sent and received the StartTLS + message), it is ready to start the negotiation and establishment of + TLS and move to the steps described in Section 3.4. + + The collision resolution procedures described in [RFC5440] for the + exchange of Open messages MUST be applied by the PCEP peers during + the exchange of StartTLS messages. + + The format of a StartTLS message is as follows: + + <StartTLS Message>::= <Common Header> + + The StartTLS message MUST contain only the PCEP common header with + the Message-Type field set to 13. + + Once the TCP connection has been successfully established, the PCEP + speaker MUST start a timer called the "StartTLSWait timer". After + the expiration of this timer, if neither the StartTLS message nor a + PCErr/Open message (in case of failure and PCEPS not being supported + by the peer, respectively) has been received, the PCEP speaker MUST + send a PCErr message with Error-Type set to 25 (PCEP StartTLS + + + +Lopez, et al. Standards Track [Page 8] + +RFC 8253 PCEPS October 2017 + + + failure) and Error-value set to 5 (No StartTLS message (nor PCErr/ + Open) before StartTLSWait timer expiry), and it MUST release the TCP + connection. 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. + + The following figures illustrate the various interactions between a + PCC and a PCE, based on the support for the PCEPS capability, during + the PCEP session initialization. + + +-+-+ +-+-+ + |PCC| |PCE| + +-+-+ +-+-+ + | | + | StartTLS | + | msg | + |------- | + | \ StartTLS | + | \ msg | + | \ ---------| + | \/ | + | /\ | + | / -------->| + | / | + |<------ | + |:::::::::TLS:::::::::| + |:::::Establishment:::| + | | + | | + |:::::::PCEP::::::::::| + | | + + Figure 1: Both PCEP speakers support PCEPS (strict) + + + + + + + + + + + + + + + + + + +Lopez, et al. Standards Track [Page 9] + +RFC 8253 PCEPS October 2017 + + + +-+-+ +-+-+ + |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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lopez, et al. Standards Track [Page 10] + +RFC 8253 PCEPS October 2017 + + + +-+-+ +-+-+ + |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 + + + + + + + + + + + + + + +Lopez, et al. Standards Track [Page 11] + +RFC 8253 PCEPS October 2017 + + + +-+-+ +-+-+ + |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 + + + + + + + + + + + + + + + +Lopez, et al. Standards Track [Page 12] + +RFC 8253 PCEPS October 2017 + + + +-+-+ +-+-+ + |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 + + Once the establishment of TLS has been agreed upon by the PCEP peers, + the connection establishment SHALL follow the following steps: + + 1. Immediately negotiate a TLS session according to [RFC5246]. The + following restrictions apply: + + * Support for TLS v1.2 [RFC5246] or later is REQUIRED. + + * Support for certificate-based mutual authentication is + REQUIRED. + + * Negotiation of a ciphersuite providing for integrity + protection is REQUIRED. + + * Negotiation of a ciphersuite providing for confidentiality is + RECOMMENDED. + + * Support for and negotiation of compression is OPTIONAL. + + * 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]. In addition, 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. + + + + + + +Lopez, et al. Standards Track [Page 13] + +RFC 8253 PCEPS October 2017 + + + 2. Peer authentication can be performed in any of the following two + REQUIRED operation models: + + * 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. + + + Certificate validation MUST include the verification rules + as per [RFC5280]. + + + PCEPS implementations SHOULD incorporate revocation methods + (Certificate Revocation List (CRL) downloading, Online + Certificate Status Protocol (OCSP), etc.) according to the + trusted CA policies. + + + 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]). + + + 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. + + + 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. + + * 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 + + + +Lopez, et al. Standards Track [Page 14] + +RFC 8253 PCEPS October 2017 + + + 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. + + 3. Start exchanging PCEP messages. + + * 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. + +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. + + In TLS X.509 mode using fingerprints, a peer is uniquely identified + by the fingerprint of the presented certificate. + + 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: + + o Peer's IP Address + + o Peer's Fully Qualified Domain Name (FQDN) + + o Certificate Fingerprint + + o Issuer + + o Subject + + o All X.509 v3 Extended Key Usage + + + +Lopez, et al. Standards Track [Page 15] + +RFC 8253 PCEPS October 2017 + + + o All X.509 v3 Subject Alternative Name + + o All X.509 v3 Certificate Policies + + Note that the remote IP address used for the TCP session + establishment is also exposed. + + [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. + + 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. + +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. + + The initiator SHOULD follow the procedure listed in [RFC5440] to + retry session setup as per the exponential back-off session + establishment retry procedure. + +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: + + o 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]. + + + + +Lopez, et al. Standards Track [Page 16] + +RFC 8253 PCEPS October 2017 + + + o A PCE can advertise its capability to support PCEPS using DNS + [PCE-DISCOVERY-DNS] by identifying the support of TLS. + +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. + +5. Backward Compatibility + + The procedures described in this document define a security container + for the transport of PCEP requests and replies carried by a TLS + connection initiated by means of a specific extended message + (StartTLS) that does not interfere with PCEP speaker implementations + not supporting it. + + 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. + + + + +Lopez, et al. Standards Track [Page 17] + +RFC 8253 PCEPS October 2017 + + + 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 + + + + + + + + + +Lopez, et al. Standards Track [Page 18] + +RFC 8253 PCEPS October 2017 + + +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 + + 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. + + + + + +Lopez, et al. Standards Track [Page 19] + +RFC 8253 PCEPS October 2017 + + + 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. + + + +Lopez, et al. Standards Track [Page 20] + +RFC 8253 PCEPS October 2017 + + + 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: + + o Determine if a session is protected via PCEPS. + + o Determine the version of TLS, the mechanism used for + authentication, and the ciphersuite in use. + + o Determine if the certificate could not be verified and the reason + for this circumstance. + + o Inspect the certificate offered by the PCEP peer. + + o 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. + + + +Lopez, et al. Standards Track [Page 21] + +RFC 8253 PCEPS October 2017 + + +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 + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + <https://www.rfc-editor.org/info/rfc5246>. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + <https://www.rfc-editor.org/info/rfc5280>. + + [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol (PCEP)", RFC 5440, + DOI 10.17487/RFC5440, March 2009, + <https://www.rfc-editor.org/info/rfc5440>. + + [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) + Extensions: Extension Definitions", RFC 6066, + DOI 10.17487/RFC6066, January 2011, + <https://www.rfc-editor.org/info/rfc6066>. + + + + + + + + + +Lopez, et al. Standards Track [Page 22] + +RFC 8253 PCEPS October 2017 + + + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and + Verification of Domain-Based Application Service Identity + within Internet Public Key Infrastructure Using X.509 + (PKIX) Certificates in the Context of Transport Layer + Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March + 2011, <https://www.rfc-editor.org/info/rfc6125>. + + [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication + of Named Entities (DANE) Transport Layer Security (TLS) + Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August + 2012, <https://www.rfc-editor.org/info/rfc6698>. + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May + 2015, <https://www.rfc-editor.org/info/rfc7525>. + + [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based + Authentication of Named Entities (DANE) Protocol: Updates + and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, + October 2015, <https://www.rfc-editor.org/info/rfc7671>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [SHS] National Institute of Standards and Technology, "Secure + Hash Standard (SHS)", FIPS PUB 180-4, + DOI 10.6028/NIST.FIPS.180-4, August 2015, + <http://nvlpubs.nist.gov/nistpubs/FIPS/ + NIST.FIPS.180-4.pdf>. + +9.2. Informative References + + [PCE-DISCOVERY-DNS] + Wu, Q., Dhody, D., King, D., Lopez, D., and J. Tantsura, + "Path Computation Element (PCE) Discovery using Domain + Name System(DNS)", Work in Progress, draft-wu-pce-dns-pce- + discovery-10, March 2017. + + [PCE-DISCOVERY-PCEPS-SUPPORT] + Lopez, D., Wu, Q., Dhody, D., Wang, Z., and D. King, "IGP + extension for PCEP security capability support in the PCE + discovery", Work in Progress, draft-wu-pce-discovery- + pceps-support-07, March 2017. + + + + + +Lopez, et al. Standards Track [Page 23] + +RFC 8253 PCEPS October 2017 + + + [PCEP-YANG] + Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A + YANG Data Model for Path Computation Element + Communications Protocol (PCEP)", Work in Progress, + draft-ietf-pce-pcep-yang-05, July 2017. + + [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. + Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites + for Transport Layer Security (TLS)", RFC 4492, + DOI 10.17487/RFC4492, May 2006, + <https://www.rfc-editor.org/info/rfc4492>. + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol + (LDAP): Authentication Methods and Security Mechanisms", + RFC 4513, DOI 10.17487/RFC4513, June 2006, + <https://www.rfc-editor.org/info/rfc4513>. + + [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. + Zhang, "OSPF Protocol Extensions for Path Computation + Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, + January 2008, <https://www.rfc-editor.org/info/rfc5088>. + + [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. + Zhang, "IS-IS Protocol Extensions for Path Computation + Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, + January 2008, <https://www.rfc-editor.org/info/rfc5089>. + + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, DOI 10.17487/RFC5925, + June 2010, <https://www.rfc-editor.org/info/rfc5925>. + + [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport + Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC6460, + January 2012, <https://www.rfc-editor.org/info/rfc6460>. + + [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, + "Transport Layer Security (TLS) Encryption for RADIUS", + RFC 6614, DOI 10.17487/RFC6614, May 2012, + <https://www.rfc-editor.org/info/rfc6614>. + + [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of + BGP, LDP, PCEP, and MSDP Issues According to the Keying + and Authentication for Routing Protocols (KARP) Design + Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, + <https://www.rfc-editor.org/info/rfc6952>. + + + + + + +Lopez, et al. Standards Track [Page 24] + +RFC 8253 PCEPS October 2017 + + + [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. + Hardwick, "Path Computation Element Communication Protocol + (PCEP) Management Information Base (MIB) Module", + RFC 7420, DOI 10.17487/RFC7420, December 2014, + <https://www.rfc-editor.org/info/rfc7420>. + + [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing + Known Attacks on Transport Layer Security (TLS) and + Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, + February 2015, <https://www.rfc-editor.org/info/rfc7457>. + + [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., + and D. Dhody, "Optimizations of Label Switched Path State + Synchronization Procedures for a Stateful PCE", RFC 8232, + DOI 10.17487/RFC8232, September 2017, + <https://www.rfc-editor.org/info/rfc8232>. + +Acknowledgements + + This specification relies on the analysis and profiling of TLS + included in [RFC6614] and the procedures described for the StartTLS + command in [RFC4513]. + + We would like to thank Joe Touch for his suggestions and support + regarding the StartTLS mechanisms. + + Thanks to Daniel King for reminding the authors about manageability + considerations. + + Thanks to Cyril Margaria for shepherding this document. + + Thanks to David Mandelberg for early SECDIR review comments as well + as further 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. + + Also, thanks to Mirja Kuhlewind, Eric Rescorla, Warren Kumari, + Kathleen Moriarty, Suresh Krishnan, Ben Campbell, and Alexey Melnikov + for the IESG review and comments. + + + + + +Lopez, et al. Standards Track [Page 25] + +RFC 8253 PCEPS October 2017 + + +Authors' Addresses + + 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 + + + + + + + + + + + + + +Lopez, et al. Standards Track [Page 26] + |