One document matched: draft-ietf-pce-pceps-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5440 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY RFC5088 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5088.xml">
<!ENTITY RFC5089 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5089.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5746 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5746.xml">
<!ENTITY RFC5925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5925.xml">
<!ENTITY RFC6066 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
<!ENTITY RFC6614 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6614.xml">
<!ENTITY RFC6952 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6952.xml">
<!ENTITY RFC6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY I-D.wu-pce-dns-pce-discovery SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wu-pce-dns-pce-discovery">
<!ENTITY I-D.wu-pce-discovery-pceps-support SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wu-pce-discovery-pceps-support">
<!ENTITY I-D.chunduri-karp-using-ikev2-with-tcp-ao SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.chunduri-karp-using-ikev2-with-tcp-ao">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- <?rfc strict="yes" ?> -->
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" docName="draft-ietf-pce-pceps-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<front>
<title>Secure Transport for PCEP</title>
<author fullname="Diego R. Lopez" initials="D. R." surname="Lopez">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz, 82</street>
<city>Madrid</city>
<region></region>
<code>28006</code>
<country>Spain</country>
</postal>
<phone>+34 913 129 041</phone>
<email>diego@tid.es</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dios">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz, 82</street>
<city>Madrid</city>
<region></region>
<code>28006</code>
<country>Spain</country>
</postal>
<phone>+34 913 129 041</phone>
<email>ogondio@tid.es</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody">
<organization>Huawei</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>KA</region>
<code>560008</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="10" month="March" year="2014" />
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>Path Computation Element</workgroup>
<keyword>PCE, PCEP, security, authentication, encryption, TLS</keyword>
<abstract>
<t>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 describe the usage of Transport Layer Security (TLS) to enhance PCEP security, hence the PCEPS acronym proposed for it. The additional security mechanisms are provided by the transport protocol supporting PCEP, and therefore they do not affect its flexibility and extensibility.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>PCEP <xref target="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, and therefore appropriate security becomes a key element in the PCE infrastructure. As the applications of the PCE framework evolves, and more complex service patterns emerge, the definition of a secure mode of operation becomes more relevant.</t>
<t><xref target="RFC5440"/> analyzes in its section on security considerations the potential threats to PCEP and their consequences, and 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, <xref target="RFC6952"/> remarks the importance of ensuring PCEP communication privacy, especially when PCEP communication endpoints do not reside in the same AS, as the interception of PCEP messages could leak sensitive information related to computed paths and resources.</t>
<t>Among the possible solutions mentioned in these documents, Transport Layer Security (TLS) <xref target="RFC5246"/> provides support for peer authentication, and message encryption and integrity. TLS supports the usage of well-know mechanisms to support key configuration and exchange, and means to perform security checks on the results of PCE discovery procedures via IGP (<xref target="RFC5088"/> and <xref target="RFC5089"/>).</t>
<t>This document describes a security container for the transport of PCEP requests and replies, and therefore it will not interfere with the protocol flexibility and extensibility.</t>
<t>This document describes how to apply TLS in securing PCE interactions, including the TLS handshake mechanisms, 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 the document we will refer to this usage of TLS to provide a secure transport for PCEP as "PCEPS".</t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
<section title="Applying PCEPS">
<section title="TCP ports">
<t>Since PCEP can operate either with or without TLS, it is necessary for the PCEP speaker to indicate whether it wants to set up a TLS connection or not. There are two main ways of achieving this:
<list style="symbols">
<t>One option is to use a different port number for TLS connections (for example, the port 443 used for HTTPS)</t>
<t>The other is to use the regular port number and have the PCEP speaker request that the PCE switch the connection to TLS using a protocol-specific mechanism (for example, the STARTTLS for mail and news protocols)</t>
</list>
To avoid requiring a specific PCEP extension to request TLS, this document proposes the usage of the former solution to implement PCEPS.</t>
<t>The default destination port number for PCEPS is TCP/XXXX.</t>
<t>NOTE: This port has to be agreed and registered as PCEPS with IANA.</t>
</section>
<section title="TLS Connection Establishment">
<t>PCEPS has no notion of negotiating TLS in an established connection. PCEP peers MAY either discover that the other PCEP endpoint supports PCEPS or can be preconfigured to use PCEPS for a given peer (see section <xref target="Discovery"/> for more details). The connection establishment SHALL follow the following steps:
<list style="numbers">
<t>After completing the TCP handshake, immediately negotiate TLS sessions according to <xref target="RFC5246"/>. The following restrictions apply:
<list style="symbols">
<t>Support for TLS v1.2 <xref target="RFC5246"/> or later is REQUIRED.</t>
<t>Support for certificate-based mutual authentication is REQUIRED.</t>
<t>Negotiation of mutual authentication is REQUIRED.</t>
<t>Negotiation of a ciphersuite providing for integrity protection is REQUIRED.</t>
<t>Negotiation of a ciphersuite providing for confidentiality is RECOMMENDED.</t>
<t>Support for and negotiation of compression is OPTIONAL.</t>
<t>PCEPS implementations MUST, at a minimum, support negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA, and SHOULD support TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as well. In addition, PCEPS implementations MUST support negotiation of the mandatory-to-implement ciphersuites required by the versions of TLS that they support.</t>
</list></t>
<t>Peer authentication can be performed in any of the following two REQUIRED operation models:
<list style="symbols">
<t>TLS with X.509 certificates using PKIX trust models:
<list style="symbols">
<t>Implementations MUST allow the configuration of a list of trusted Certification Authorities (CAs) for incoming connections.</t>
<t>Certificate validation MUST include the verification rules as per <xref target="RFC5280"/>.</t>
<t>Implementations SHOULD indicate their trusted CAs. For TLS 1.2, this is done using <xref target="RFC5246"/>, Section 7.4.4, "certificate_authorities" (server side) and <xref target="RFC6066"/>, Section 6 "Trusted CA Indication" (client side).</t>
<t>Peer validation always SHOULD include a check on whether the locally configured expected DNS name or IP address of the peer that is contacted matches its presented certificate. DNS names and IP addresses can be contained in the Common Name (CN) or subjectAltName entries. For verification, only one of these entries is to be considered. The following precedence applies: for DNS name validation, subjectAltName:DNS has precedence over CN; for IP address validation, subjectAltName:iPAddr has precedence over CN.</t>
<t>NOTE: Consider here whether peer validation MAY be extended by means of the DANE procedures, including its specs as informative references.</t>
<t> 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 subjectAltName:URI or a set of allowed X509v3 Certificate Policies)</t>
</list></t>
<t>TLS with X.509 certificates using certificate fingerprints: Implementations MUST allow the configuration of a list of trusted certificates, identified via fingerprint of the Distinguished Encoding Rules (DER) encoded certificate octets. Implementations MUST support SHA-256 as the hash algorithm for the fingerprint.</t>
</list></t>
<t>Start exchanging PCEP messages.</t>
</list></t>
<t>To support TLS re-negotiation both peers MUST support the mechanism described in <xref target="RFC5746"/>. Any attempt of initiate a TLS handshake to establish new cryptographic parameters not aligned with <xref target="RFC5746"/> SHALL be considered a TLS negotiation failure.</t>
</section>
<section title="Peer Identity">
<t>Depending on the peer authentication method in use, PCEPS supports different operation modes to establish 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 establish 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.</t>
<t>In TLS-X.509 mode using fingerprints, a peer is uniquely identified by the fingerprint of the presented client certificate.</t>
<t>There are numerous trust models in Public-Key Infrastructure (PKI) environments, and it is beyond the scope of this document to define how a particular deployment determines whether a client 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. As a suggestion, at least the following parameters of the X.509 client certificate should be exposed:
<list style="symbols">
<t>Peer's IP address</t>
<t>Peer's fully qualified domain name (FQDN)</t>
<t>Certificate Fingerprint</t>
<t>Issuer</t>
<t>Subject</t>
<t>All X509v3 Extended Key Usage</t>
<t>All X509v3 Subject Alternative Name</t>
<t>All X509v3 Certificate Policies</t>
</list></t>
<t>In addition, a PCC MAY apply the procedures described in <xref target="RFC6698"/> (DANE) to verify its peer identity when using DNS discovery. See section <xref target="DANE"/> for further details.</t>
</section>
<section title="Connection Establishment Failure">
<t>In case the initial TLS negotiation or the peer identity check fail according to the procedures listed in this document, the peer MUST immediately terminate the session. It SHOULD follow the procedure listed in <xref target="RFC5440"/> to retry session setup along with an exponential back-off session establishment retry procedure.</t>
</section>
</section>
<section anchor="Discovery" title="Discovery Mechanisms">
<t>A PCE can advertise its capability to support PCEPS using the IGP advertisement and discovery mechanism. The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to advertise PCE capabilities. It MAY be present within the PCED sub-TLV carried by OSPF or IS-IS. <xref target="RFC5088"/> and <xref target="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 <xref target="RFC5088"/>. A new capability flag bit for the PCE-CAP-FLAGS sub-TLV that can be announced as attribute to distribute PCEP security support information is proposed in <xref target="I-D.wu-pce-discovery-pceps-support"/></t>
<t>NOTE: A new bit must be added here to advertise the PCEPS capability.</t>
<t>When DNS is used by a PCC (or a PCE acting as a client, for the rest of the section, PCC refers to both) willing to use PCEPS to locate an appropriate PCE <xref target="I-D.wu-pce-dns-pce-discovery"/>, the PCC as initiating entity chooses at least one of the returned FQDNs to resolve, which it does by performing DNS "A" or "AAAA" lookups on the FDQN. This will eventually result in an IPv4 or IPv6 address. The PCC SHALL use the IP address(es) from the successfully resolved FDQN (with the corresponding port number returned by the DNS SRV lookup) as the connection address(es) for the receiving entity.</t>
<t>If the PCC fails to connect using an IP address but the "A" or "AAAA" lookups returned more than one IP address, then the PCC SHOULD use the next resolved IP address for that FDQN as the connection address. If the PCC fails to connect using all resolved IP addresses for a given FDQN, then it SHOULD repeat the process of resolution and connection for the next FQDN returned by the SRV lookup based on the priority and weight.</t>
<t>If the PCC receives a response to its SRV query but it is not able to establish a PCEPS connection using the data received in the response, as initiating entity it MAY fall back to lookup a PCE that uses TCP as transport.</t>
<section anchor="DANE" title="DANE Applicability">
<t>DANE <xref target="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 DNSSEC. A PCC willing to apply DANE to verify server identity MUST conform to the rules defined in section 4 of <xref target="RFC6698"/>.</t>
</section>
</section>
<section anchor="Backward" title="Backward Compatibility">
<t>Since the procedure described in this document describes a security container for the transport of PCEP requests and replies carried on a newly allocated TCP port there will be no impact on the base PCEP and/or any further extensions.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>NOTE: PCEPS has to be registered as TCP port XXXX.</t>
<t>No new PCEP messages or other objects are defined.</t>
</section>
<section title="Security Considerations">
<t>While the application of TLS satisfies the requirement on privacy as well as fine-grained, policy-based peer authentication, there are security threats that it cannot address. It is advisable to apply additional protection measures, in particular in what relates to attacks specifically addressed to forging the TCP connection underpinning TLS. TCP-AO (TCP Authentication Option <xref target="RFC5925"/>) is fully compatible with and deemed as complementary to TLS, so its usage is to be considered as a security enhancement whenever any of the PCEPS peers require it, especially in the case of long-lived connections. The mechanisms to configure the requirements to use TCP-AO and other lower-layer protection measures, as well as the association of the required crypto material (MKT in the case of TCP-AO) with a particular peer are outside the scope of this document. <xref target="I-D.chunduri-karp-using-ikev2-with-tcp-ao"/> defines a method to perform such association.</t>
<t>Since computational resources required by 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.</t>
<t>Some TLS ciphersuites only provide integrity validation of their payload, and provide no encryption. This specification does not forbid the use of such ciphersuites, but administrators must weight carefully the risk of relevant internal data leakage that can occur in such a case, as explicitly stated by <xref target="RFC6952"/>.</t>
<t>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, but a later revision may demand support for stronger functions if suitable attacks on it are known.</t>
</section>
<section title="Acknowledgements">
<t>This specification relies on the analysis and profiling of TLS included in <xref target="RFC6614"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC5246;
&RFC5440;
&RFC5088;
&RFC5089;
&RFC5280;
&RFC5746;
&RFC5925;
&RFC6066;
&RFC6698;
</references>
<references title="Informative References">
&RFC6614;
&RFC6952;
&I-D.wu-pce-dns-pce-discovery;
&I-D.wu-pce-discovery-pceps-support;
&I-D.chunduri-karp-using-ikev2-with-tcp-ao;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:53:20 |