idnits 2.17.1 draft-ietf-pce-pceps-13.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 (Using the creation date from RFC5440, updated by this document, for RFC5378 checks: 2005-11-29) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 20, 2017) is 2526 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-02 Summary: 2 errors (**), 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 Updates: 5440 (if approved) Telefonica I+D 5 Intended status: Standards Track Q. Wu 6 Expires: November 21, 2017 D. Dhody 7 Huawei 8 May 20, 2017 10 Secure Transport for PCEP 11 draft-ietf-pce-pceps-13 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 This document updates RFC 5440 regarding the PCEP initialization 25 phase specification. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 21, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 75 3. Applying PCEPS . . . . . . . . . . . . . . . . . . . . . . . 4 76 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3.2. Initiating the TLS Procedures . . . . . . . . . . . . . . 4 78 3.3. The StartTLS Message . . . . . . . . . . . . . . . . . . 6 79 3.4. TLS Connection Establishment . . . . . . . . . . . . . . 8 80 3.5. Peer Identity . . . . . . . . . . . . . . . . . . . . . . 10 81 3.6. Connection Establishment Failure . . . . . . . . . . . . 11 82 4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . 11 83 4.1. DANE Applicability . . . . . . . . . . . . . . . . . . . 12 84 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 6.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . 12 87 6.2. New Error-Values . . . . . . . . . . . . . . . . . . . . 13 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 8. Manageability Considerations . . . . . . . . . . . . . . . . 14 90 8.1. Control of Function and Policy . . . . . . . . . . . . . 14 91 8.2. Information and Data Models . . . . . . . . . . . . . . . 15 92 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 93 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 94 8.5. Requirements on Other Protocols . . . . . . . . . . . . . 15 95 8.6. Impact on Network Operation . . . . . . . . . . . . . . . 16 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 99 10.2. Informative References . . . . . . . . . . . . . . . . . 17 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 102 1. Introduction 104 The Path Computation Element Communication Protocol (PCEP) [RFC5440] 105 defines the mechanisms for the communication between a Path 106 Computation Client (PCC) and a Path Computation Element (PCE), or 107 between two PCEs. These interactions include requests and replies 108 that can be critical for a sustainable network operation and adequate 109 resource allocation, and therefore appropriate security becomes a key 110 element in the PCE infrastructure. As the applications of the PCE 111 framework evolves, and more complex service patterns emerge, the 112 definition of a secure mode of operation becomes more relevant. 114 [RFC5440] analyzes in its section on security considerations the 115 potential threats to PCEP and their consequences, and discusses 116 several mechanisms for protecting PCEP against security attacks, 117 without making a specific recommendation on a particular one or 118 defining their application in depth. Moreover, [RFC6952] remarks the 119 importance of ensuring PCEP communication privacy, especially when 120 PCEP communication endpoints do not reside in the same Autonomous 121 System (AS), as the interception of PCEP messages could leak 122 sensitive information related to computed paths and resources. 124 Among the possible solutions mentioned in these documents, Transport 125 Layer Security (TLS) [RFC5246] provides support for peer 126 authentication, and message encryption and integrity. TLS supports 127 the usage of well-known mechanisms to support key configuration and 128 exchange, and means to perform security checks on the results of PCE 129 discovery procedures via Interior Gateway Protocol (IGP) ([RFC5088] 130 and [RFC5089]). 132 This document describes a security container for the transport of 133 PCEP messages, and therefore they do not affect the flexibility and 134 extensibility of PCEP. 136 This document describes how to apply TLS in securing PCE 137 interactions, including initiation of the TLS procedures, the TLS 138 handshake mechanisms, the TLS methods for peer authentication, the 139 applicable TLS ciphersuites for data exchange, and the handling of 140 errors in the security checks. In the rest of the document we will 141 refer to this usage of TLS to provide a secure transport for PCEP as 142 "PCEPS". 144 2. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 3. Applying PCEPS 152 3.1. Overview 154 The steps involved in establishing a PCEPS session are as follows: 156 1. Establishment of a TCP connection. 158 2. Initiating the TLS procedures by the StartTLS message from PCE to 159 PCC and from PCC to PCE. 161 3. Establishment of TLS connection. 163 4. Start exchanging PCEP messages as per [RFC5440]. 165 Implementations SHOULD follow the best practices and recommendations 166 for using TLS, as per [RFC7525]. 168 It should be noted that this procedure updates what is defined in 169 section 4.2.1 and section 6.7 of [RFC5440] regarding the 170 initialization phase and the processing of messages prior to the Open 171 message. The details of processing including backward compatibility 172 are discussed in the following sections. 174 3.2. Initiating the TLS Procedures 176 Since PCEP can operate either with or without TLS, it is necessary 177 for the PCEP speaker to indicate whether it wants to set up a TLS 178 connection or not. For this purpose, this document specifies a new 179 PCEP message called StartTLS. Thus the PCEP session is secured via 180 TLS from the start before exchange of any other PCEP message (that 181 includes the Open message). This document thus updates [RFC5440], 182 which required the Open message to be the first PCEP message. In the 183 case of a PCEP session using TLS the StartTLS message will be sent 184 first. 186 The PCEP speaker MAY discover that the PCEP peer supports PCEPS or 187 can be preconfigured to use PCEPS for a given peer (see Section 4 for 188 more details). Securing via TLS of an existing PCEP session is not 189 permitted, the session MUST be closed and re-established with TLS as 190 per the procedure described in this document. 192 The StartTLS message is a PCEP message sent by a PCC to a PCE and by 193 a PCE to a PCC in order to initiate the TLS procedure for PCEP. The 194 Message-Type field of the PCEP common header for the StartTLS message 195 is set to [TBA1 by IANA]. 197 Once the TCP connection has been successfully established, the first 198 message sent by the PCC to the PCE and by the PCE to the PCC MUST be 199 a StartTLS message for the PCEPS. Note this is a significant change 200 from [RFC5440] where the first PCEP message is the Open message. 202 A PCEP speaker receiving a StartTLS message, after any other PCEP 203 exchange has taken place (by receiving or sending any other messages 204 from either side) MUST treat it as an unexpected message and reply 205 with a PCErr message with Error-Type set to [TBA2 by IANA] (PCEP 206 StartTLS failure) and Error-value set to 1 (reception of StartTLS 207 after any PCEP exchange), and MUST close the TCP connection. A PCEP 208 speaker receiving any other message apart from StartTLS, open, or 209 PCErr as the first message, MUST treat it as an unexpected message 210 and reply with a PCErr message with Error-Type set to [TBA2 by IANA] 211 (PCEP StartTLS failure) and Error-value set to 2 (reception of any 212 other message apart from StartTLS, Open, or PCErr message), and MUST 213 close the TCP connection. 215 If the PCEP speaker that does not support PCEPS, receives a StartTLS 216 message, it MUST behave according to the existing error mechanism 217 described in section 6.2 of [RFC5440] (in case message is received 218 prior to an Open message) or section 6.9 of [RFC5440] (for the case 219 of reception of unknown message). 221 After the exchange of startTLS messages, if a PCEP speaker cannot 222 establish a TLS connection for some reason (e.g. the required 223 mechanisms for certificate revocation checking are not available), it 224 MUST return a PCErr message (in clear) with Error-Type set to [TBA2 225 by IANA] (PCEP StartTLS failure) and Error-value set to: 227 o 3 (not without TLS) if it is not willing to exchange PCEP messages 228 without the solicited TLS connection, and it MUST close the TCP 229 session. 231 o 4 (ok without TLS) if it is willing to exchange PCEP messages 232 without the solicited TLS connection, and it MUST close the TCP 233 session. The peer MAY choose to re-establish the PCEP session 234 without TLS next. 236 If the PCEP speaker supports PCEPS and can establish a TLS connection 237 it MUST start the TLS connection establishment steps described in 238 Section 3.4 before the PCEP initialization procedure (section 4.2.1 239 of [RFC5440]). 241 A PCEP speaker that does not support PCEPS or has learned the peer 242 willingness to reestablish session without TLS, can send the Open 243 message directly, as per [RFC5440]. 245 Given the asymmetric nature of TLS for connection establishment it is 246 relevant to identify the roles of each of the PCEP peers in it. The 247 PCC SHALL act as TLS client, and the PCE SHALL act as TLS server, 248 according to [RFC5246]. 250 These procedures minimize the impact of PCEPS support in PCEP 251 implementations without requiring additional dedicated ports for 252 running PCEP with TLS. 254 As per the recommendation from [RFC7525] to avoid downgrade attacks, 255 PCEP peers that support PCEPS, SHOULD default to strict TLS 256 configuration i.e. do not allow non-TLS PCEP sessions to be 257 established. PCEPS implementations MAY provide an option to allow 258 the operator to manually override strict TLS configuration and allow 259 unsecured connections. Execution of this override SHOULD trigger a 260 warning about the security implications of permitting unsecured 261 connections. 263 3.3. The StartTLS Message 265 The StartTLS message is used to initiate the TLS procedure for a 266 PCEPS session between the PCEP peers. A PCEP speaker sends the 267 StartTLS message to request negotiation and establishment of TLS 268 connection for PCEP. On receiving a StartTLS message from the PCEP 269 peer (i.e. when the PCEP speaker has sent and received StartTLS 270 message) it is ready to start TLS negotiation and establishment and 271 move to steps described in Section 3.4. 273 The collision resolution procedures described in [RFC5440] for the 274 exchange of Open messages MUST be applied by the PCEP peers during 275 the exchange of StartTLS messages. 277 The format of a StartTLS message is as follows: 279 ::= 281 The StartTLS message MUST contain only the PCEP common header with 282 Message-Type field set to [TBA1 by IANA]. 284 Once the TCP connection has been successfully established and the 285 StartTLS message sent, the sender MUST start a timer called 286 StartTLSWait timer, after the expiration of which, if no StartTLS 287 message has been received, it MUST send a PCErr message and releases 288 the TCP connection with Error-Type set to [TBA2 by IANA] and Error- 289 value set to 5 (no StartTLS message received before the expiration of 290 the StartTLSWait timer). A RECOMMENDED value for StartTLSWait timer 291 is 60 seconds. 293 +-+-+ +-+-+ 294 |PCC| |PCE| 295 +-+-+ +-+-+ 296 | | 297 | StartTLS | 298 | msg | 299 |------- | 300 | \ StartTLS | 301 | \ msg | 302 | \ ---------| 303 | \/ | 304 | /\ | 305 | / -------->| 306 | / | 307 |<------ | 308 |:::::::::TLS:::::::::| 309 |:::::Establishment:::| 310 | | 311 | | 312 |:::::::PCEP::::::::::| 313 | | 315 Figure 1: Both PCEP Speaker supports PCEPS 317 +-+-+ +-+-+ 318 |PCC| |PCE| 319 +-+-+ +-+-+ 320 | | Does not send 321 | StartTLS | StartTLS as 322 |-------------------->| cannot establish 323 | | TLS 324 | | 325 |<--------------------| Send Error 326 | PCErr | Error-Value 3/4 327 | | 329 Figure 2: Both PCEP Speaker supports PCEPS, But cannot establish TLS 330 +-+-+ +-+-+ 331 |PCC| |PCE| 332 +-+-+ +-+-+ 333 | | Does not support 334 | StartTLS | PCEPS and thus 335 | msg | sends Open 336 |------- | 337 | \ Open | 338 | \ msg | 339 | \ ---------| 340 | \/ | 341 | /\ | 342 | / -------->| 343 | / | 344 |<------ | 345 | | 346 |<--------------------| Send Error 347 | PCErr | (non-Open message 348 | | received) 350 Figure 3: One PCEP Speaker does not support PCEPS 352 3.4. TLS Connection Establishment 354 Once the establishment of TLS has been agreed by the PCEP peers, the 355 connection establishment SHALL follow the following steps: 357 1. Immediately negotiate TLS sessions according to [RFC5246]. The 358 following restrictions apply: 360 * Support for TLS v1.2 [RFC5246] or later is REQUIRED. 362 * Support for certificate-based mutual authentication is 363 REQUIRED. 365 * Negotiation of mutual authentication is REQUIRED. 367 * Negotiation of a ciphersuite providing for integrity 368 protection is REQUIRED. 370 * Negotiation of a ciphersuite providing for confidentiality is 371 RECOMMENDED. 373 * Support for and negotiation of compression is OPTIONAL. 375 * PCEPS implementations MUST, at a minimum, support negotiation 376 of the TLS_RSA_WITH_AES_128_GCM_SHA256, and SHOULD support 377 TLS_RSA_WITH_AES_256_GCM_SHA384 as well [RFC5288]. In 378 addition, PCEPS implementations MUST support negotiation of 379 the mandatory-to-implement ciphersuites required by the 380 versions of TLS that they support. 382 2. Peer authentication can be performed in any of the following two 383 REQUIRED operation models: 385 * TLS with X.509 certificates using Public-Key Infrastructure 386 Exchange (PKIX) trust models: 388 + Implementations MUST allow the configuration of a list of 389 trusted Certification Authorities (CAs) for incoming 390 connections. 392 + Certificate validation MUST include the verification rules 393 as per [RFC5280]. 395 + PCEPS implementations SHOULD incorporate revocation methods 396 (CRL downloading, OCSP...) according to the trusted CA 397 policies. 399 + Implementations SHOULD indicate their trusted CAs. For TLS 400 1.2, this is done using [RFC5246], Section 7.4.4, 401 "certificate_authorities" (server side) and [RFC6066], 402 Section 6 "Trusted CA Indication" (client side). 404 + Peer validation always SHOULD include a check on whether 405 the locally configured expected DNS name or IP address of 406 the peer that is contacted matches its presented 407 certificate. DNS names and IP addresses can be contained 408 in the Common Name (CN) or subjectAltName entries. For 409 verification, only one of these entries is to be 410 considered. The following precedence applies: for DNS name 411 validation, subjectAltName:DNS has precedence over CN; for 412 IP address validation, subjectAltName:iPAddr has precedence 413 over CN. 415 + Implementations MAY allow the configuration of a set of 416 additional properties of the certificate to check for a 417 peer's authorization to communicate (e.g., a set of allowed 418 values in subjectAltName:URI or a set of allowed X509v3 419 Certificate Policies) 421 * TLS with X.509 certificates using certificate fingerprints: 422 Implementations MUST allow the configuration of a list of 423 trusted certificates, identified via fingerprint of the 424 Distinguished Encoding Rules (DER) encoded certificate octets. 425 Implementations MUST support SHA-256 as defined by [SHS] as 426 the hash algorithm for the fingerprint. 428 3. Start exchanging PCEP messages. 430 To support TLS re-negotiation both peers MUST support the mechanism 431 described in [RFC5746]. Any attempt to initiate a TLS handshake to 432 establish new cryptographic parameters not aligned with [RFC5746] 433 SHALL be considered a TLS negotiation failure. 435 3.5. Peer Identity 437 Depending on the peer authentication method in use, PCEPS supports 438 different operation modes to establish peer's identity and whether it 439 is entitled to perform requests or can be considered authoritative in 440 its replies. PCEPS implementations SHOULD provide mechanisms for 441 associating peer identities with different levels of access and/or 442 authoritativeness, and they MUST provide a mechanism for establishing 443 a default level for properly identified peers. Any connection 444 established with a peer that cannot be properly identified SHALL be 445 terminated before any PCEP exchange takes place. 447 In TLS-X.509 mode using fingerprints, a peer is uniquely identified 448 by the fingerprint of the presented certificate. 450 There are numerous trust models in PKIX environments, and it is 451 beyond the scope of this document to define how a particular 452 deployment determines whether a peer is trustworthy. Implementations 453 that want to support a wide variety of trust models SHOULD expose as 454 many details of the presented certificate to the administrator as 455 possible so that the trust model can be implemented by the 456 administrator. At least the following parameters of the X.509 457 certificate SHOULD be exposed: 459 o Peer's IP address 461 o Peer's fully qualified domain name (FQDN) 463 o Certificate Fingerprint 465 o Issuer 467 o Subject 469 o All X509v3 Extended Key Usage 470 o All X509v3 Subject Alternative Name 472 o All X509v3 Certificate Policies 474 [I-D.ietf-pce-stateful-sync-optimizations] specify a Speaker Entity 475 Identifier TLV (SPEAKER-ENTITY-ID), as an optional TLV that MAY be 476 included in the OPEN Object. It contains a unique identifier for the 477 node that does not change during the lifetime of the PCEP speaker. 478 An implementation would thus expose the speaker entity identifier as 479 part of the X509v3 certificate, so that an implementation could use 480 this identifier for the peer identification trust model. 482 In addition, a PCC MAY apply the procedures described in [RFC6698] 483 DNS-Based Authentication of Named Entities (DANE) to verify its peer 484 identity when using DNS discovery. See section Section 4.1 for 485 further details. 487 3.6. Connection Establishment Failure 489 In case the initial TLS negotiation or the peer identity check fails, 490 according to the procedures listed in this document, the peer MUST 491 first send a PCErr message as per Section 3.2 and then terminate the 492 session. It SHOULD follow the procedure listed in [RFC5440] to retry 493 session setup along with an exponential back-off session 494 establishment retry procedure. 496 4. Discovery Mechanisms 498 A PCE can advertise its capability to support PCEPS using the IGP 499 advertisement and discovery mechanism. The PCE-CAP-FLAGS sub-TLV is 500 an optional sub-TLV used to advertise PCE capabilities. It MAY be 501 present within the PCE Discovery (PCED) sub-TLV carried by OSPF or 502 IS-IS. [RFC5088] and [RFC5089] provide the description and 503 processing rules for this sub-TLV when carried within OSPF and IS-IS, 504 respectively. PCE capability bits are defined in [RFC5088]. A new 505 capability flag bit for the PCE-CAP-FLAGS sub-TLV that can be 506 announced as attribute to distribute PCEP security support 507 information is proposed in [I-D.wu-pce-discovery-pceps-support] 509 When DNS is used by a PCC (or a PCE acting as a client, for the rest 510 of the section, PCC refers to both) willing to use PCEPS to locate an 511 appropriate PCE [I-D.wu-pce-dns-pce-discovery], the PCC as an 512 initiating entity, chooses at least one of the returned FQDNs to 513 resolve, which it does by performing DNS "A" or "AAAA" lookups on the 514 FDQN. This will eventually result in an IPv4 or IPv6 address. The 515 PCC SHALL use the IP address(es) from the successfully resolved FDQN 516 (with the corresponding port number returned by the DNS Service 517 Record (SRV) lookup) as the connection address(es) for the receiving 518 entity. 520 If the PCC fails to connect using an IP address but the "A" or "AAAA" 521 lookups returned more than one IP address, then the PCC SHOULD use 522 the next resolved IP address for that FDQN as the connection address. 523 If the PCC fails to connect using all resolved IP addresses for a 524 given FDQN, then it SHOULD repeat the process of resolution and 525 connection for the next FQDN returned by the SRV lookup based on the 526 priority and weight. 528 If the PCC receives a response to its SRV query but it is not able to 529 establish a PCEPS connection using the data received in the response, 530 as initiating entity it MAY fall back to lookup a PCE that uses TCP 531 as transport. 533 4.1. DANE Applicability 535 DANE [RFC6698] defines a secure method to associate the certificate 536 that is obtained from a TLS server with a domain name using DNS, 537 i.e., using the TLSA DNS resource record (RR) to associate a TLS 538 server certificate or public key with the domain name where the 539 record is found, thus forming a "TLSA certificate association". The 540 DNS information needs to be protected by DNS Security (DNSSEC). A 541 PCC willing to apply DANE to verify server identity MUST conform to 542 the rules defined in section 4 of [RFC6698]. The server's domain 543 name must be authorized separately, as TLSA does not provide any 544 useful authorization guarantees. 546 5. Backward Compatibility 548 The procedures described in this document define a security container 549 for the transport of PCEP requests and replies carried by a TLS 550 connection initiated by means of a specific extended message 551 (StartTLS) that does not interfere with PCEP speaker implementations 552 not supporting it. 554 If a PCEP implementation that does not support PCEPS receives a 555 StartTLS message, would behave according to the existing error 556 mechanism of [RFC5440]. 558 6. IANA Considerations 560 6.1. New PCEP Message 562 IANA is requested to allocate new message types within the "PCEP 563 Messages" sub-registry of the PCEP Numbers registry, as follows: 565 Value Description Reference 566 TBA1 The Start TLS Message (StartTLS) This document 568 6.2. New Error-Values 570 IANA is requested to allocate new Error Types and Error Values within 571 the " PCEP-ERROR Object Error Types and Values" sub-registry of the 572 PCEP Numbers registry, as follows: 574 Error- 575 Type Meaning Error-value Reference 577 TBA2 StartTLS Failure 0:Unassigned This document 578 1:Reception of This document 579 StartTLS after 580 any PCEP exchange 581 2:Reception of This document 582 any other message 583 apart from StartTLS, 584 Open or PCErr 585 3:Failure, connection This document 586 without TLS not 587 possible 588 4:Failure, connection This document 589 without TLS possible 590 5:No StartTLS message This document 591 before StartTLSWait 592 timer expiry 594 7. Security Considerations 596 While the application of TLS satisfies the requirement on privacy as 597 well as fine-grained, policy-based peer authentication, there are 598 security threats that it cannot address. It may be advisable to 599 apply additional protection measures, in particular in what relates 600 to attacks specifically addressed to forging the TCP connection 601 underpinning TLS, especially in the case of long-lived connections. 602 One of these measures is the application of TCP-AO (TCP 603 Authentication Option [RFC5925]), which is fully compatible with and 604 deemed as complementary to TLS. The mechanisms to configure the 605 requirements to use TCP-AO and other lower-layer protection measures 606 with a particular peer are outside the scope of this document. 608 Since computational resources required by TLS handshake and 609 ciphersuite are higher than unencrypted TCP, clients connecting to a 610 PCEPS server can more easily create high load conditions and a 611 malicious client might create a Denial-of-Service attack more easily. 613 Some TLS ciphersuites only provide integrity validation of their 614 payload, and provide no encryption. This specification does not 615 forbid the use of such ciphersuites, but administrators must weight 616 carefully the risk of relevant internal data leakage that can occur 617 in such a case, as explicitly stated by [RFC6952]. 619 When using certificate fingerprints to identify PCEPS peers, any two 620 certificates that produce the same hash value will be considered the 621 same peer. Therefore, it is important to make sure that the hash 622 function used is cryptographically uncompromised so that attackers 623 are very unlikely to be able to produce a hash collision with a 624 certificate of their choice. This document mandates support for 625 SHA-256 as defined by [SHS], but a later revision may demand support 626 for stronger functions if suitable attacks on it are known. 628 The guidance given in [RFC7525] SHOULD be followed to avoid attacks 629 on TLS. 631 8. Manageability Considerations 633 All manageability requirements and considerations listed in [RFC5440] 634 apply to PCEP protocol extensions defined in this document. In 635 addition, requirements and considerations listed in this section 636 apply. 638 8.1. Control of Function and Policy 640 A PCE or PCC implementation MUST allow configuring the PCEP security 641 via TLS capabilities as described in this document. 643 A PCE or PCC implementation supporting PCEP security via TLS MUST 644 support general TLS configuration as per [RFC5246]. At least the 645 configuration of one of the trust models and its corresponding 646 parameters, as described in Section 3.4 and Section 3.5, MUST be 647 supported by the implementation. 649 A PCEP implementation SHOULD allow configuring the following PCEP 650 security parameters: 652 o StartTLSWait timer value 654 PCEPS implementations MAY provide an option to allow the operator to 655 manually override strict TLS configuration and allow unsecured 656 connections. Execution of this override SHOULD trigger a warning 657 about the security implications of permitting unsecured connections. 659 Further, the operator need to develop suitable security policies 660 around PCEP, within his network. Further the PCEP peers SHOULD 661 provide ways for the operator to complete following tasks: 663 o Determine if a PCEP session is protected via PCEPS. 665 o Determine the version of TLS, mechanism for authentication used. 667 o Determine if the certificate cannot be verified and the cipher 668 suite used. 670 o Inspect the certificate offered by the PCEP peer. 672 o Be warned if StartTLS procedure fails for the PCEP peers, that are 673 known to support PCEPS (via configurations or capability 674 advertisements). 676 8.2. Information and Data Models 678 The PCEP MIB module SHOULD be extended to include PCEPS capabilities, 679 information, and status. 681 An implementation SHOULD allow the operator to configure the PCEPS 682 capability and various TLS related parameters, as well as allow to 683 view the current TLS status for a PCEP session. To serve this 684 purpose, the PCEP YANG module [I-D.ietf-pce-pcep-yang] can be 685 extended to include TLS related configuration and state. 687 8.3. Liveness Detection and Monitoring 689 Mechanisms defined in this document do not imply any new liveness 690 detection and monitoring requirements in addition to those already 691 listed in [RFC5440] and [RFC5246]. 693 8.4. Verify Correct Operations 695 A PCEPS implementation SHOULD log error events and provide PCEPS 696 failure statistics with reasons. 698 8.5. Requirements on Other Protocols 700 Mechanisms defined in this document do not imply any new requirements 701 on other protocols. 703 8.6. Impact on Network Operation 705 Mechanisms defined in this document do not have any significant 706 impact on network operations in addition to those already listed in 707 [RFC5440]. 709 A legacy PCEP implementation that does not support PCEPS, can exist 710 in the network with the PCEPS implementations. On receiving a 711 StartTLS message, a legacy implementation would behave according to 712 the existing error mechanism of [RFC5440]. 714 9. Acknowledgements 716 This specification relies on the analysis and profiling of TLS 717 included in [RFC6614] and the procedures described for the STARTTLS 718 command in [RFC4513]. 720 We would like to thank Joe Touch for his suggestions and support 721 regarding the TLS start mechanisms. 723 Thanks to Dan King for reminding the authors about manageability 724 considerations. 726 Thanks to Cyril Margaria for shepherding this document. 728 Thanks to Dan Frost for the RTGDIR review. 730 10. References 732 10.1. Normative References 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, 736 DOI 10.17487/RFC2119, March 1997, 737 . 739 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 740 (TLS) Protocol Version 1.2", RFC 5246, 741 DOI 10.17487/RFC5246, August 2008, 742 . 744 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 745 Housley, R., and W. Polk, "Internet X.509 Public Key 746 Infrastructure Certificate and Certificate Revocation List 747 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 748 . 750 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 751 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 752 DOI 10.17487/RFC5288, August 2008, 753 . 755 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 756 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 757 DOI 10.17487/RFC5440, March 2009, 758 . 760 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 761 "Transport Layer Security (TLS) Renegotiation Indication 762 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 763 . 765 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 766 Extensions: Extension Definitions", RFC 6066, 767 DOI 10.17487/RFC6066, January 2011, 768 . 770 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 771 of Named Entities (DANE) Transport Layer Security (TLS) 772 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 773 2012, . 775 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 776 "Recommendations for Secure Use of Transport Layer 777 Security (TLS) and Datagram Transport Layer Security 778 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 779 2015, . 781 [SHS] National Institute of Standards and Technology, "Secure 782 Hash Standard (SHS), FIPS PUB 180-4", 783 DOI 10.6028/NIST.FIPS.180-4, August 2015, 784 . 787 10.2. Informative References 789 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol 790 (LDAP): Authentication Methods and Security Mechanisms", 791 RFC 4513, DOI 10.17487/RFC4513, June 2006, 792 . 794 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 795 Zhang, "OSPF Protocol Extensions for Path Computation 796 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 797 January 2008, . 799 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 800 Zhang, "IS-IS Protocol Extensions for Path Computation 801 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 802 January 2008, . 804 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 805 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 806 June 2010, . 808 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 809 "Transport Layer Security (TLS) Encryption for RADIUS", 810 RFC 6614, DOI 10.17487/RFC6614, May 2012, 811 . 813 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 814 BGP, LDP, PCEP, and MSDP Issues According to the Keying 815 and Authentication for Routing Protocols (KARP) Design 816 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 817 . 819 [I-D.ietf-pce-stateful-sync-optimizations] 820 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 821 and D. Dhody, "Optimizations of Label Switched Path State 822 Synchronization Procedures for a Stateful PCE", draft- 823 ietf-pce-stateful-sync-optimizations-10 (work in 824 progress), March 2017. 826 [I-D.ietf-pce-pcep-yang] 827 Dhody, D., Hardwick, J., Beeram, V., and j. 828 jefftant@gmail.com, "A YANG Data Model for Path 829 Computation Element Communications Protocol (PCEP)", 830 draft-ietf-pce-pcep-yang-02 (work in progress), March 831 2017. 833 [I-D.wu-pce-dns-pce-discovery] 834 Wu, Q., Dhody, D., King, D., Lopez, D., and J. Tantsura, 835 "Path Computation Element (PCE) Discovery using Domain 836 Name System(DNS)", draft-wu-pce-dns-pce-discovery-10 (work 837 in progress), March 2017. 839 [I-D.wu-pce-discovery-pceps-support] 840 Lopez, D., Wu, Q., Dhody, D., and D. King, "IGP extension 841 for PCEP security capability support in the PCE 842 discovery", draft-wu-pce-discovery-pceps-support-07 (work 843 in progress), March 2017. 845 Authors' Addresses 847 Diego R. Lopez 848 Telefonica I+D 849 Don Ramon de la Cruz, 82 850 Madrid 28006 851 Spain 853 Phone: +34 913 129 041 854 EMail: diego.r.lopez@telefonica.com 856 Oscar Gonzalez de Dios 857 Telefonica I+D 858 Don Ramon de la Cruz, 82 859 Madrid 28006 860 Spain 862 Phone: +34 913 129 041 863 EMail: oscar.gonzalezdedios@telefonica.com 865 Qin Wu 866 Huawei 867 101 Software Avenue, Yuhua District 868 Nanjing, Jiangsu 210012 869 China 871 EMail: sunseawq@huawei.com 873 Dhruv Dhody 874 Huawei 875 Divyashree Techno Park, Whitefield 876 Bangalore, KA 560066 877 India 879 EMail: dhruv.ietf@gmail.com