idnits 2.17.1 draft-ietf-pce-pceps-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2016) is 2963 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2830 (Obsoleted by RFC 4510, RFC 4511, RFC 4513) == Outdated reference: A later version (-10) exists of draft-wu-pce-dns-pce-discovery-09 -- No information found for draft-wu-pce-discovery-pceps-support - is the name correct? Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Lopez 3 Internet-Draft O. Gonzalez de Dios 4 Intended status: Experimental Telefonica I+D 5 Expires: September 9, 2016 Q. Wu 6 D. Dhody 7 Huawei 8 March 8, 2016 10 Secure Transport for PCEP 11 draft-ietf-pce-pceps-09 13 Abstract 15 The Path Computation Element Communication Protocol (PCEP) defines 16 the mechanisms for the communication between a Path Computation 17 Client (PCC) and a Path Computation Element (PCE), or among PCEs. 18 This document describe the usage of Transport Layer Security (TLS) to 19 enhance PCEP security, hence the PCEPS acronym proposed for it. The 20 additional security mechanisms are provided by the transport protocol 21 supporting PCEP, and therefore they do not affect the flexibility and 22 extensibility of PCEP. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 9, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 3. Applying PCEPS . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Initiating the TLS Procedures . . . . . . . . . . . . . . 4 63 3.3. The StartTLS Message . . . . . . . . . . . . . . . . . . . 6 64 3.4. TLS Connection Establishment . . . . . . . . . . . . . . . 8 65 3.5. Peer Identity . . . . . . . . . . . . . . . . . . . . . . 10 66 3.6. Connection Establishment Failure . . . . . . . . . . . . . 11 67 4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . . 11 68 4.1. DANE Applicability . . . . . . . . . . . . . . . . . . . . 12 69 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 6.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 12 72 6.2. New Error-Values . . . . . . . . . . . . . . . . . . . . . 13 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 8. Manageability Considerations . . . . . . . . . . . . . . . . . 14 75 8.1. Control of Function and Policy . . . . . . . . . . . . . . 14 76 8.2. Information and Data Models . . . . . . . . . . . . . . . 14 77 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 14 78 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 79 8.5. Requirements on Other Protocols . . . . . . . . . . . . . 15 80 8.6. Impact on Network Operations . . . . . . . . . . . . . . . 15 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 PCEP [RFC5440] defines the mechanisms for the communication between a 89 Path Computation Client (PCC) and a Path Computation Element (PCE), 90 or between two PCEs. These interactions include requests and replies 91 that can be critical for a sustainable network operation and adequate 92 resource allocation, and therefore appropriate security becomes a key 93 element in the PCE infrastructure. As the applications of the PCE 94 framework evolves, and more complex service patterns emerge, the 95 definition of a secure mode of operation becomes more relevant. 97 [RFC5440] analyzes in its section on security considerations the 98 potential threats to PCEP and their consequences, and discusses 99 several mechanisms for protecting PCEP against security attacks, 100 without making a specific recommendation on a particular one or 101 defining their application in depth. Moreover, [RFC6952] remarks the 102 importance of ensuring PCEP communication privacy, especially when 103 PCEP communication endpoints do not reside in the same Autonomous 104 System (AS), as the interception of PCEP messages could leak 105 sensitive information related to computed paths and resources. 107 Among the possible solutions mentioned in these documents, Transport 108 Layer Security (TLS) [RFC5246] provides support for peer 109 authentication, and message encryption and integrity. TLS supports 110 the usage of well-know mechanisms to support key configuration and 111 exchange, and means to perform security checks on the results of PCE 112 discovery procedures via Interior Gateway Protocol (IGP) ([RFC5088] 113 and [RFC5089]). 115 This document describes a security container for the transport of 116 PCEP requests and replies, and therefore they do not affect the 117 flexibility and extensibility of PCEP. 119 This document describes how to apply TLS in securing PCE 120 interactions, including initiation of the TLS procedures, the TLS 121 handshake mechanisms, the TLS methods for peer authentication, the 122 applicable TLS ciphersuites for data exchange, and the handling of 123 errors in the security checks. In the rest of the document we will 124 refer to this usage of TLS to provide a secure transport for PCEP as 125 "PCEPS". 127 2. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3. Applying PCEPS 135 3.1. Overview 137 The steps involved in the PCEPS establishment consists of following 138 successive steps: 140 1. Establishment of a TCP connection. 142 2. Initiating the TLS procedures by the StartTLS message from PCE to 143 PCC and from PCC to PCE. 145 3. Establishment of TLS connection. 147 4. Start exchanging PCEP messages as per [RFC5440]. 149 It should be noted that this procedure updates what is defined in 150 section 6.7 of [RFC5440] regarding the processing of messages prior 151 to the Open message. The details of processing including backward 152 compatibility are discussed in the following sections. 154 3.2. Initiating the TLS Procedures 156 Since PCEP can operate either with or without TLS, it is necessary 157 for the PCEP speaker to indicate whether it wants to set up a TLS 158 connection or not. For this purpose, this document proposes a new 159 PCEP message called StartTLS. This message MUST be issued by the 160 party willing to use TLS, prior to any other PCEP message. The PCEP 161 speaker MAY discover that the PCEP peer supports PCEPS or can be 162 preconfigured to use PCEPS for a given peer (see Section 4 for more 163 details). Thus the PCEP session is secured via TLS from the start 164 before exchange of any other PCEP message including the Open message. 165 Securing via TLS of an existing PCEP session is not permitted, the 166 session must be closed and re-established with TLS as per the 167 procedure described in this document. 169 The StartTLS message is a PCEP message sent by a PCC to a PCE and by 170 a PCE to a PCC in order to initiate the TLS procedure for PCEP. The 171 Message-Type field of the PCEP common header for the StartTLS message 172 is set to [TBA1 by IANA]. 174 Once the TCP connection has been successfully established, the first 175 message sent by the PCC to the PCE and by the PCE to the PCC MUST be 176 a StartTLS message for the PCEPS. Note this is a significant change 177 from [RFC5440] where the first PCEP message is Open. 179 A PCEP speaker receiving a StartTLS message after any other PCEP 180 exchange has taken place (by receiving or sending any other messages 181 from either side) MUST treat it as an unexpected message and reply 182 with a PCErr message with Error-Type set to [TBA2 by IANA] (PCEP 183 StartTLS failure) and Error-value set to 1 (reception of StartTLS 184 after any PCEP exchange), and MUST close the TCP connection. A PCEP 185 speaker receiving any other message apart from StartTLS or PCErr MUST 186 treat it as an unexpected message and reply with a PCErr message with 187 Error-Type set to [TBA2 by IANA](PCEP StartTLS failure) and Error- 188 value set to 2 (reception of non-StartTLS or non-PCErr message), and 189 MUST close the TCP connection. 191 If the PCEP speaker that does not support PCEPS, receives a StartTLS 192 message, it MUST behave according to the existing error mechanism 193 described in section 6.2 of [RFC5440] (in case message is received 194 prior to an Open message) or section 6.9 of [RFC5440] (for the case 195 of reception of unknown message). 197 If the PCEP speaker supports PCEPS but cannot establish a TLS 198 connection for some reason (e.g. the required mechanisms for 199 certificate revocation checking are not available) it MUST return a 200 PCErr message with Error-Type set to [TBA2 by IANA] (PCEP StartTLS 201 failure) and Error-value set to: 203 o 3 (not without TLS) if it is not willing to exchange PCEP messages 204 without the solicited TLS connection, and it MUST close the TCP 205 session. 207 o 4 (ok without TLS) if it is willing to exchange PCEP messages 208 without the solicited TLS connection, and it MUST close the TCP 209 session. The peer MAY choose to re-establish the PCEP session 210 without TLS next. 212 If the PCEP speaker supports PCEPS and can establish a TLS connection 213 it MUST start the TLS connection establishment steps described in 214 Section 3.4 before the PCEP initialization procedure (section 4.2.1 215 of [RFC5440]). 217 Given the asymmetric nature of TLS for connection establishment it is 218 relevant to identify the roles of each of the PCEP peers in it. The 219 PCC SHALL act as TLS client, and the PCE SHALL act as TLS server, 220 according to [RFC5246]. 222 These procedures minimize the impact of PCEPS support in PCEP 223 implementations without requiring additional dedicated ports for 224 running PCEP with TLS. 226 3.3. The StartTLS Message 228 The StartTLS message is used to initiate the TLS procedure for a 229 PCEPS session between the PCEP peers. A PCEP speaker sends the 230 StartTLS message to request negotiation and establishment of TLS 231 connection for PCEP. On receiving a StartTLS message from the PCEP 232 peer (i.e. when PCEP speaker has sent and received StartTLS message) 233 it is ready to start TLS negotiation and establishment and move to 234 steps described in Section 3.4. 236 The collision resolution procedures described in [RFC5440] for the 237 exchange of Open messages MUST be applied by the PCEP peers during 238 the exchange of StartTLS messages. 240 The format of a StartTLS message is as follows: 242 ::= 244 The StartTLS message MUST contain only the PCEP common header with 245 Message-Type field set to [TBA1 by IANA]. 247 Once the TCP connection has been successfully established and the 248 StartTLS message sent, the sender MUST start a timer called 249 StartTLSWait timer, after the expiration of which, if no StartTLS 250 message has been received, it sends a PCErr message and releases the 251 TCP connection with Error-Type set to [TBA2 by IANA] and Error-value 252 set to 5 (no StartTLS message received before the expiration of the 253 StartTLSWait timer). A RECOMMENDED value for StartTLSWait timer is 254 60 seconds. 256 +-+-+ +-+-+ 257 |PCC| |PCE| 258 +-+-+ +-+-+ 259 | | 260 | StartTLS | 261 | msg | 262 |------- | 263 | \ StartTLS | 264 | \ msg | 265 | \ ---------| 266 | \/ | 267 | /\ | 268 | / -------->| 269 | / | 270 |<------ | 271 |:::::::::TLS:::::::::| 272 |:::::Establishment:::| 273 | | 274 | | 275 |:::::::PCEP::::::::::| 276 | | 278 Figure 1: Both PCEP Speaker supports PCEPS 280 +-+-+ +-+-+ 281 |PCC| |PCE| 282 +-+-+ +-+-+ 283 | | Does not send 284 | StartTLS | StartTLS as 285 |-------------------->| cannot establish 286 | | TLS 287 | | 288 |<--------------------| Send Error 289 | PCErr | Error-Value 3/4 290 | | 292 Figure 2: Both PCEP Speaker supports PCEPS, But cannot establish TLS 293 +-+-+ +-+-+ 294 |PCC| |PCE| 295 +-+-+ +-+-+ 296 | | Does not support 297 | StartTLS | PCEPS and thus 298 | msg | sends Open 299 |------- | 300 | \ Open | 301 | \ msg | 302 | \ ---------| 303 | \/ | 304 | /\ | 305 | / -------->| 306 | / | 307 |<------ | 308 | | 309 |<--------------------| Send Error 310 | PCErr | (non-Open message 311 | | received) 313 Figure 3: One PCEP Speaker does not support PCEPS 315 3.4. TLS Connection Establishment 317 Once the establishment of TLS has been agreed by the PCEP peers, the 318 connection establishment SHALL follow the following steps: 320 1. Immediately negotiate TLS sessions according to [RFC5246]. The 321 following restrictions apply: 323 * Support for TLS v1.2 [RFC5246] or later is REQUIRED. 325 * Support for certificate-based mutual authentication is 326 REQUIRED. 328 * Negotiation of mutual authentication is REQUIRED. 330 * Negotiation of a ciphersuite providing for integrity 331 protection is REQUIRED. 333 * Negotiation of a ciphersuite providing for confidentiality is 334 RECOMMENDED. 336 * Support for and negotiation of compression is OPTIONAL. 338 * PCEPS implementations MUST, at a minimum, support negotiation 339 of the TLS_RSA_WITH_AES_128_GCM_SHA256, and SHOULD support 340 TLS_RSA_WITH_AES_256_GCM_SHA384 as well [RFC5288]. In 341 addition, PCEPS implementations MUST support negotiation of 342 the mandatory-to-implement ciphersuites required by the 343 versions of TLS that they support. 345 2. Peer authentication can be performed in any of the following two 346 REQUIRED operation models: 348 * TLS with X.509 certificates using Public-Key Infrastructure 349 Exchange (PKIX) trust models: 351 + Implementations MUST allow the configuration of a list of 352 trusted Certification Authorities (CAs) for incoming 353 connections. 355 + Certificate validation MUST include the verification rules 356 as per [RFC5280]. 358 + PCEPS implementations SHOULD incorporate revocation methods 359 (CRL downloading, OCSP...) according to the trusted CA 360 policies. 362 + Implementations SHOULD indicate their trusted CAs. For TLS 363 1.2, this is done using [RFC5246], Section 7.4.4, 364 "certificate_authorities" (server side) and [RFC6066], 365 Section 6 "Trusted CA Indication" (client side). 367 + Peer validation always SHOULD include a check on whether 368 the locally configured expected DNS name or IP address of 369 the peer that is contacted matches its presented 370 certificate. DNS names and IP addresses can be contained 371 in the Common Name (CN) or subjectAltName entries. For 372 verification, only one of these entries is to be 373 considered. The following precedence applies: for DNS name 374 validation, subjectAltName:DNS has precedence over CN; for 375 IP address validation, subjectAltName:iPAddr has precedence 376 over CN. 378 + Implementations MAY allow the configuration of a set of 379 additional properties of the certificate to check for a 380 peer's authorization to communicate (e.g., a set of allowed 381 values in subjectAltName:URI or a set of allowed X509v3 382 Certificate Policies) 384 * TLS with X.509 certificates using certificate fingerprints: 385 Implementations MUST allow the configuration of a list of 386 trusted certificates, identified via fingerprint of the 387 Distinguished Encoding Rules (DER) encoded certificate octets. 388 Implementations MUST support SHA-256 as defined by [SHS] as 389 the hash algorithm for the fingerprint. 391 3. Start exchanging PCEP messages. 393 To support TLS re-negotiation both peers MUST support the mechanism 394 described in [RFC5746]. Any attempt of initiate a TLS handshake to 395 establish new cryptographic parameters not aligned with [RFC5746] 396 SHALL be considered a TLS negotiation failure. 398 3.5. Peer Identity 400 Depending on the peer authentication method in use, PCEPS supports 401 different operation modes to establish peer's identity and whether it 402 is entitled to perform requests or can be considered authoritative in 403 its replies. PCEPS implementations SHOULD provide mechanisms for 404 associating peer identities with different levels of access and/or 405 authoritativeness, and they MUST provide a mechanism for establish a 406 default level for properly identified peers. Any connection 407 established with a peer that cannot be properly identified SHALL be 408 terminated before any PCEP exchange takes place. 410 In TLS-X.509 mode using fingerprints, a peer is uniquely identified 411 by the fingerprint of the presented certificate. 413 There are numerous trust models in PKIX environments, and it is 414 beyond the scope of this document to define how a particular 415 deployment determines whether a peer is trustworthy. Implementations 416 that want to support a wide variety of trust models should expose as 417 many details of the presented certificate to the administrator as 418 possible so that the trust model can be implemented by the 419 administrator. As a suggestion, at least the following parameters of 420 the X.509 certificate should be exposed: 422 o Peer's IP address 424 o Peer's fully qualified domain name (FQDN) 426 o Certificate Fingerprint 428 o Issuer 430 o Subject 431 o All X509v3 Extended Key Usage 433 o All X509v3 Subject Alternative Name 435 o All X509v3 Certificate Policies 437 In addition, a PCC MAY apply the procedures described in [RFC6698] 438 DNS-Based Authentication of Named Entities (DANE) to verify its peer 439 identity when using DNS discovery. See section Section 4.1 for 440 further details. 442 3.6. Connection Establishment Failure 444 In case the initial TLS negotiation or the peer identity check fail 445 according to the procedures listed in this document, the peer MUST 446 immediately terminate the session. It SHOULD follow the procedure 447 listed in [RFC5440] to retry session setup along with an exponential 448 back-off session establishment retry procedure. 450 4. Discovery Mechanisms 452 A PCE can advertise its capability to support PCEPS using the IGP 453 advertisement and discovery mechanism. The PCE-CAP-FLAGS sub-TLV is 454 an optional sub-TLV used to advertise PCE capabilities. It MAY be 455 present within the PCE Discovery (PCED) sub-TLV carried by OSPF or 456 IS-IS. [RFC5088] and [RFC5089] provide the description and 457 processing rules for this sub-TLV when carried within OSPF and IS-IS, 458 respectively. PCE capability bits are defined in [RFC5088]. A new 459 capability flag bit for the PCE-CAP-FLAGS sub-TLV that can be 460 announced as attribute to distribute PCEP security support 461 information is proposed in [I-D.wu-pce-discovery-pceps-support] 463 When DNS is used by a PCC (or a PCE acting as a client, for the rest 464 of the section, PCC refers to both) willing to use PCEPS to locate an 465 appropriate PCE [I-D.wu-pce-dns-pce-discovery], the PCC as an 466 initiating entity, chooses at least one of the returned FQDNs to 467 resolve, which it does by performing DNS "A" or "AAAA" lookups on the 468 FDQN. This will eventually result in an IPv4 or IPv6 address. The 469 PCC SHALL use the IP address(es) from the successfully resolved FDQN 470 (with the corresponding port number returned by the DNS Service 471 Record (SRV) lookup) as the connection address(es) for the receiving 472 entity. 474 If the PCC fails to connect using an IP address but the "A" or "AAAA" 475 lookups returned more than one IP address, then the PCC SHOULD use 476 the next resolved IP address for that FDQN as the connection address. 477 If the PCC fails to connect using all resolved IP addresses for a 478 given FDQN, then it SHOULD repeat the process of resolution and 479 connection for the next FQDN returned by the SRV lookup based on the 480 priority and weight. 482 If the PCC receives a response to its SRV query but it is not able to 483 establish a PCEPS connection using the data received in the response, 484 as initiating entity it MAY fall back to lookup a PCE that uses TCP 485 as transport. 487 4.1. DANE Applicability 489 DANE [RFC6698] defines a secure method to associate the certificate 490 that is obtained from a TLS server with a domain name using DNS, 491 i.e., using the TLSA DNS resource record (RR) to associate a TLS 492 server certificate or public key with the domain name where the 493 record is found, thus forming a "TLSA certificate association". The 494 DNS information needs to be protected by DNS Security (DNSSEC). A 495 PCC willing to apply DANE to verify server identity MUST conform to 496 the rules defined in section 4 of [RFC6698]. The server's domain 497 name must be authorized separately, as TLSA does not provide any 498 useful authorization guarantees. 500 5. Backward Compatibility 502 The procedures described in this document define a security container 503 for the transport of PCEP requests and replies carried by a TLS 504 connection initiated by means of a specific extended message 505 (StartTLS) that does not interfere with PCEP speaker implementations 506 not supporting it. 508 If a PCEP implementation that does not support PCEPS receives a 509 StartTLS message it MUST behave according to the existing error 510 mechanism of [RFC5440]. 512 6. IANA Considerations 514 6.1. New PCEP Message 516 Each PCEP message has a message type value. 518 One new PCEP messages is defined in this document: 520 Value Description Reference 521 TBA1 The Start TLS Message (StartTLS) This document 523 6.2. New Error-Values 525 A registry was created for the Error-type and Error-value of the PCEP 526 Error Object. Following new Error-Types and Error-Values are 527 defined: 529 Error- 530 Type Meaning Error-value Reference 532 TBA2 StartTLS Failure 0:Unassigned This document 533 1:Reception of This document 534 StartTLS after 535 any PCEP exchange 536 2:Reception of This document 537 non-StartTLS 538 or non-PCErr message 539 3:Failure, connection This document 540 without TLS not 541 possible 542 4:Failure, connection This document 543 without TLS possible 544 5:No StartTLS message This document 545 before StartTLSWait 546 timer expiry 548 7. Security Considerations 550 While the application of TLS satisfies the requirement on privacy as 551 well as fine-grained, policy-based peer authentication, there are 552 security threats that it cannot address. It is advisable to apply 553 additional protection measures, in particular in what relates to 554 attacks specifically addressed to forging the TCP connection 555 underpinning TLS. TCP-AO (TCP Authentication Option [RFC5925]) is 556 fully compatible with and deemed as complementary to TLS, so its 557 usage is to be considered as a security enhancement whenever any of 558 the PCEPS peers require it, especially in the case of long-lived 559 connections. The mechanisms to configure the requirements to use 560 TCP-AO and other lower-layer protection measures, as well as the 561 association of the required crypto material (MKT in the case of 562 TCP-AO) with a particular peer are outside the scope of this 563 document. [I-D.chunduri-karp-using-ikev2-with-tcp-ao] defines a 564 method to perform such association. 566 Since computational resources required by TLS handshake and 567 ciphersuite are higher than unencrypted TCP, clients connecting to a 568 PCEPS server can more easily create high load conditions and a 569 malicious client might create a Denial-of-Service attack more easily. 571 Some TLS ciphersuites only provide integrity validation of their 572 payload, and provide no encryption. This specification does not 573 forbid the use of such ciphersuites, but administrators must weight 574 carefully the risk of relevant internal data leakage that can occur 575 in such a case, as explicitly stated by [RFC6952]. 577 When using certificate fingerprints to identify PCEPS peers, any two 578 certificates that produce the same hash value will be considered the 579 same peer. Therefore, it is important to make sure that the hash 580 function used is cryptographically uncompromised so that attackers 581 are very unlikely to be able to produce a hash collision with a 582 certificate of their choice. This document mandates support for SHA- 583 256 as defined by [SHS], but a later revision may demand support for 584 stronger functions if suitable attacks on it are known. 586 8. Manageability Considerations 588 All manageability requirements and considerations listed in [RFC5440] 589 apply to PCEP protocol extensions defined in this document. In 590 addition, requirements and considerations listed in this section 591 apply. 593 8.1. Control of Function and Policy 595 A PCE or PCC implementation MUST allow configuring the PCEP security 596 via TLS capabilities as described in this document. 598 A PCE or PCC implementation supporting PCEP security via TLS MUST 599 support general TLS configuration as per [RFC5246]. At least the 600 configuration of one of the trust models and its corresponding 601 parameters, as described in Section 3.4 and Section 3.5, MUST be 602 supported by the implementation. 604 A PCEP implementation SHOULD allow configuring the following PCEP 605 security parameters: 607 o StartTLSWait timer value 609 8.2. Information and Data Models 611 The PCEP MIB module SHOULD be extended to include PCEPS capabilities, 612 information, and status. 614 8.3. Liveness Detection and Monitoring 616 Mechanisms defined in this document do not imply any new liveness 617 detection and monitoring requirements in addition to those already 618 listed in [RFC5440] and [RFC5246]. 620 8.4. Verify Correct Operations 622 A PCEPS implementation SHOULD log error events and provide PCEPS 623 failure statistics with reasons. 625 8.5. Requirements on Other Protocols 627 Mechanisms defined in this document do not imply any new requirements 628 on other protocols. 630 8.6. Impact on Network Operations 632 Mechanisms defined in this document do not have any impact on network 633 operations in addition to those already listed in [RFC5440]. 635 9. Acknowledgements 637 This specification relies on the analysis and profiling of TLS 638 included in [RFC6614] and the procedures described for the STARTTLS 639 command in [RFC2830]. 641 We would like to thank Joe Touch for his suggestions and support 642 regarding the TLS start mechanisms. 644 Thanks to Dan King for reminding the authors about manageability 645 considerations. 647 10. References 649 10.1. Normative References 651 [RFC2119] Bradner, S., "Key words 652 for use in RFCs to 653 Indicate Requirement 654 Levels", BCP 14, 655 RFC 2119, DOI 10.17487/ 656 RFC2119, March 1997, . 660 [RFC5246] Dierks, T. and E. 661 Rescorla, "The Transport 662 Layer Security (TLS) 663 Protocol Version 1.2", 664 RFC 5246, DOI 10.17487/ 665 RFC5246, August 2008, . 670 [RFC5288] Salowey, J., Choudhury, 671 A., and D. McGrew, "AES 672 Galois Counter Mode 673 (GCM) Cipher Suites for 674 TLS", RFC 5288, 675 DOI 10.17487/RFC5288, 676 August 2008, . 680 [RFC5440] Vasseur, JP., Ed. and 681 JL. Le Roux, Ed., "Path 682 Computation Element 683 (PCE) Communication 684 Protocol (PCEP)", 685 RFC 5440, DOI 10.17487/ 686 RFC5440, March 2009, . 690 [RFC5088] Le Roux, JL., Ed., 691 Vasseur, JP., Ed., 692 Ikejiri, Y., and R. 693 Zhang, "OSPF Protocol 694 Extensions for Path 695 Computation Element 696 (PCE) Discovery", 697 RFC 5088, DOI 10.17487/ 698 RFC5088, January 2008, < 699 http:// 700 www.rfc-editor.org/info/ 701 rfc5088>. 703 [RFC5089] Le Roux, JL., Ed., 704 Vasseur, JP., Ed., 705 Ikejiri, Y., and R. 706 Zhang, "IS-IS Protocol 707 Extensions for Path 708 Computation Element 709 (PCE) Discovery", 710 RFC 5089, DOI 10.17487/ 711 RFC5089, January 2008, < 712 http:// 713 www.rfc-editor.org/info/ 714 rfc5089>. 716 [RFC5280] Cooper, D., Santesson, 717 S., Farrell, S., Boeyen, 718 S., Housley, R., and W. 719 Polk, "Internet X.509 720 Public Key 721 Infrastructure 722 Certificate and 723 Certificate Revocation 724 List (CRL) Profile", 725 RFC 5280, DOI 10.17487/ 726 RFC5280, May 2008, . 730 [RFC5746] Rescorla, E., Ray, M., 731 Dispensa, S., and N. 732 Oskov, "Transport Layer 733 Security (TLS) 734 Renegotiation Indication 735 Extension", RFC 5746, 736 DOI 10.17487/RFC5746, 737 February 2010, . 741 [RFC5925] Touch, J., Mankin, A., 742 and R. Bonica, "The TCP 743 Authentication Option", 744 RFC 5925, DOI 10.17487/ 745 RFC5925, June 2010, . 749 [RFC6066] Eastlake 3rd, D., 750 "Transport Layer 751 Security (TLS) 752 Extensions: Extension 753 Definitions", RFC 6066, 754 DOI 10.17487/RFC6066, 755 January 2011, . 759 [RFC6698] Hoffman, P. and J. 760 Schlyter, "The DNS-Based 761 Authentication of Named 762 Entities (DANE) 763 Transport Layer Security 764 (TLS) Protocol: TLSA", 765 RFC 6698, DOI 10.17487/ 766 RFC6698, August 2012, . 771 [SHS] National Institute of 772 Standards and 773 Technology, "Secure Hash 774 Standard (SHS), FIPS PUB 775 180-4", DOI 10.6028/ 776 NIST.FIPS.180-4, 777 August 2015, . 782 10.2. Informative References 784 [RFC2830] Hodges, J., Morgan, R., 785 and M. Wahl, 786 "Lightweight Directory 787 Access Protocol (v3): 788 Extension for Transport 789 Layer Security", 790 RFC 2830, DOI 10.17487/ 791 RFC2830, May 2000, . 795 [RFC6614] Winter, S., McCauley, 796 M., Venaas, S., and K. 797 Wierenga, "Transport 798 Layer Security (TLS) 799 Encryption for RADIUS", 800 RFC 6614, DOI 10.17487/ 801 RFC6614, May 2012, . 805 [RFC6952] Jethanandani, M., Patel, 806 K., and L. Zheng, 807 "Analysis of BGP, LDP, 808 PCEP, and MSDP Issues 809 According to the Keying 810 and Authentication for 811 Routing Protocols (KARP) 812 Design Guide", RFC 6952, 813 DOI 10.17487/RFC6952, 814 May 2013, . 818 [I-D.wu-pce-dns-pce-discovery] Wu, W., Dhody, D., King, 819 D., Lopez, D., and J. 820 Tantsura, "Path 821 Computation Element 822 (PCE) Discovery using 823 Domain Name 824 System(DNS)", draft-wu- 825 pce-dns-pce-discovery-09 826 (work in progress), 827 December 2015. 829 [I-D.wu-pce-discovery-pceps-support] Lopez, D., Wu, Q., 830 Dhody, D., King, D., and 831 Z. Wang, "IGP extension 832 for PCEP security 833 capability support in 834 the PCE discovery", draf 835 t-wu-pce-discovery- 836 pceps-support-05 (work 837 in progress), 838 February 2016. 840 [I-D.chunduri-karp-using-ikev2-with-tcp-ao] Chunduri, U., Tian, A., 841 and J. Touch, "A 842 framework for RPs to use 843 IKEv2 KMP", draft- 844 chunduri-karp-using- 845 ikev2-with-tcp-ao-06 846 (work in progress), 847 February 2014. 849 Authors' Addresses 851 Diego R. Lopez 852 Telefonica I+D 853 Don Ramon de la Cruz, 82 854 Madrid, 28006 855 Spain 857 Phone: +34 913 129 041 858 EMail: diego.r.lopez@telefonica.com 859 Oscar Gonzalez de Dios 860 Telefonica I+D 861 Don Ramon de la Cruz, 82 862 Madrid, 28006 863 Spain 865 Phone: +34 913 129 041 866 EMail: oscar.gonzalezdedios@telefonica.com 868 Qin Wu 869 Huawei 870 101 Software Avenue, Yuhua District 871 Nanjing, Jiangsu 210012 872 China 874 EMail: sunseawq@huawei.com 876 Dhruv Dhody 877 Huawei 878 Divyashree Techno Park, Whitefield 879 Bangalore, KA 560037 880 India 882 EMail: dhruv.ietf@gmail.com