idnits 2.17.1 draft-ietf-pce-pceps-17.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 (September 4, 2017) is 2426 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 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-05 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 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: March 8, 2018 D. Dhody 7 Huawei 8 September 4, 2017 10 Secure Transport for PCEP 11 draft-ietf-pce-pceps-17 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 describes the usage of Transport Layer Security (TLS) 19 to enhance PCEP security, hence the PCEPS acronym proposed for it. 20 The additional security mechanisms are provided by the transport 21 protocol supporting PCEP, and therefore they do not affect the 22 flexibility and extensibility of PCEP. 24 This document updates RFC 5440 in regards to the PCEP initialization 25 phase procedures. 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 March 8, 2018. 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 . . . . . . . . . . . . . . . . . . 7 79 3.4. TLS Connection Establishment . . . . . . . . . . . . . . 12 80 3.5. Peer Identity . . . . . . . . . . . . . . . . . . . . . . 14 81 3.6. Connection Establishment Failure . . . . . . . . . . . . 15 82 4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . 15 83 4.1. DANE Applicability . . . . . . . . . . . . . . . . . . . 16 84 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 16 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 6.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . 17 87 6.2. New Error-Values . . . . . . . . . . . . . . . . . . . . 17 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 8. Manageability Considerations . . . . . . . . . . . . . . . . 19 90 8.1. Control of Function and Policy . . . . . . . . . . . . . 19 91 8.2. Information and Data Models . . . . . . . . . . . . . . . 20 92 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 93 8.4. Verifying Correct Operations . . . . . . . . . . . . . . 20 94 8.5. Requirements on Other Protocols . . . . . . . . . . . . . 20 95 8.6. Impact on Network Operation . . . . . . . . . . . . . . . 21 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 99 10.2. Informative References . . . . . . . . . . . . . . . . . 23 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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 confidentiality, especially 120 when PCEP communication endpoints do not reside in the same 121 Autonomous System (AS), as the interception of PCEP messages could 122 leak 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, message encryption and integrity. TLS provides well- 127 known mechanisms to support key configuration and exchange, as well 128 as means to perform security checks on the results of PCE discovery 129 procedures via Interior Gateway Protocol (IGP) ([RFC5088] and 130 [RFC5089]). 132 This document describes a security container for the transport of 133 PCEP messages, and therefore it does not affect the flexibility and 134 extensibility of PCEP. 136 This document describes how to apply TLS to secure interactions with 137 PCE, including initiation of the TLS procedures, the TLS handshake 138 mechanism, the TLS methods for peer authentication, the applicable 139 TLS ciphersuites for data exchange, and the handling of errors in the 140 security checks. In the rest of the document we will refer to this 141 usage of TLS to provide a secure transport for PCEP as "PCEPS". 143 Within this document, PCEP communications are described through PCC- 144 PCE relationship. The PCE architecture also supports the PCE-PCE 145 communication, this is achieved by requesting PCE fill the role of a 146 PCC, as usual. Thus, in this document, the PCC refers to a PCC or a 147 PCE initiating the PCEP session and acting as a client. 149 2. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 3. Applying PCEPS 159 3.1. Overview 161 The steps involved in establishing a PCEPS session are as follows: 163 1. Establishment of a TCP connection. 165 2. Initiating the TLS procedures by the StartTLS message from PCE to 166 PCC and from PCC to PCE. 168 3. Negotiation and establishment of TLS connection. 170 4. Start exchanging PCEP messages as per [RFC5440]. 172 This document uses the standard StartTLS procedure in PCEP, instead 173 of using a different port for the secured session. This is done to 174 avoid requesting allocation of another port number for the PCEPS. 175 The StartTLS procedure makes more efficient use of scarce port 176 numbers and allow simpler configuration of PCEP. 178 Implementations SHOULD follow the best practices and recommendations 179 for using TLS, as per [RFC7525]. 181 It should be noted that this procedure updates what is defined in 182 section 4.2.1 and section 6.7 of [RFC5440] regarding the 183 initialization phase and the processing of messages prior to the Open 184 message. The details of processing, including backward 185 compatibility, are discussed in the following sections. 187 3.2. Initiating the TLS Procedures 189 Since PCEP can operate either with or without TLS, it is necessary 190 for a PCEP speaker to indicate whether it wants to set up a TLS 191 connection or not. For this purpose, this document specifies a new 192 PCEP message called StartTLS. Thus, the PCEP session is secured via 193 TLS from the start before exchange of any other PCEP message (that 194 includes the Open message). This document thus updates [RFC5440], 195 which required the Open message to be the first PCEP message that is 196 exchanged. In the case of a PCEP session using TLS, the StartTLS 197 message will be sent first. Also a PCEP speaker that supports PCEPS 198 MUST NOT start the OpenWait timer after the TCP establishment, 199 instead it starts a StartTLSWait timer as described in Section 3.3. 201 The PCEP speaker MAY discover that the PCEP peer supports PCEPS or 202 can be preconfigured to use PCEPS for a given peer (see Section 4 for 203 more details). An existing PCEP session cannot be secured via TLS, 204 the session MUST be closed and re-established with TLS as per the 205 procedure described in this document. 207 The StartTLS message is a PCEP message sent by a PCC to a PCE and by 208 a PCE to a PCC in order to initiate the TLS procedure for PCEP. The 209 PCC initiates the use of TLS by sending a StartTLS message. The PCE 210 agrees to the use of TLS by responding with its own StartTLS message. 211 If the PCE is configured to only support TLS, it may send the 212 StartTLS message immediately upon TCP connection establishment; 213 otherwise it MUST wait for the PCC's first message to see whether it 214 is an Open or a StartTLS message. The TLS negotiation and 215 establishment procedures are triggered once the PCEP speaker has sent 216 and received the StartTLS message. The Message-Type field of the 217 PCEP common header for the StartTLS message is set to [TBA1 by IANA]. 219 Once the TCP connection has been successfully established, the first 220 message sent by the PCC to the PCE and by the PCE to the PCC MUST be 221 a StartTLS message for the PCEPS. Note that, this is a significant 222 change from [RFC5440], where the first PCEP message is the Open 223 message. 225 A PCEP speaker receiving a StartTLS message, after any other PCEP 226 exchange has taken place (by receiving or sending any other messages 227 from either side) MUST treat it as an unexpected message and reply 228 with a PCErr message with Error-Type set to [TBA2 by IANA] (PCEP 229 StartTLS failure) and Error-value set to 1 (reception of StartTLS 230 after any PCEP exchange), and MUST close the TCP connection. 232 Any message received prior to StartTLS or Open message MUST trigger a 233 protocol error condition causing a PCErr message to be sent with 234 Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure) and Error- 235 value set to 2 (reception of a message apart from StartTLS or Open) 236 and MUST close the TCP connection. 238 If the PCEP speaker that does not support PCEPS, receives a StartTLS 239 message, it will behave according to the existing error mechanism 240 described in section 6.2 of [RFC5440] (in case message is received 241 prior to an Open message) or section 6.9 of [RFC5440] (for the case 242 of reception of unknown message). See Section 5 for more details. 244 If the PCEP speaker that only supports PCEPS connection (as a local 245 policy), receives an Open message, it MUST treat it as an unexpected 246 message and reply with a PCErr message with Error-Type set to 1 (PCEP 247 session establishment failure) and Error-value set to 1 (reception of 248 an invalid Open message or a non Open message), and MUST close the 249 TCP connection. 251 If a PCC supports PCEPS connections as well as allow non-PCEPS 252 connection (as a local policy), it MUST first try to establish PCEPS, 253 by sending StartTLS message and in case it receives an PCErr message 254 from the PCE, it MAY retry to establish connection without PCEPS by 255 sending an Open message. If a PCE supports PCEPS connections as well 256 as allow non-PCEPS connection (as a local policy), it MUST wait to 257 respond after TCP establishment, based on the message received from 258 the PCC. In case of StartTLS message, PCE MUST respond with sending 259 a StartTLS message and moving to TLS establishment procedures as 260 described in this document. In case of Open message, PCE MUST 261 respond with Open message and move to PCEP session establishment 262 procedure as per [RFC5440]. If a PCE supports PCEPS connections only 263 (as a local policy), it MAY send StartTLS message to PCC without 264 waiting to receive a StartTLS message from PCC. 266 If a PCEP speaker that is unwilling or unable to negotiate TLS 267 receives a StartTLS messages, it MUST return a PCErr message (in 268 clear) with Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure) 269 and Error-value set to: 271 o 3 (Failure, connection without TLS is not possible) if it is not 272 willing to exchange PCEP messages without the solicited TLS 273 connection, and it MUST close the TCP session. 275 o 4 (Failure, connection without TLS is possible) if it is willing 276 to exchange PCEP messages without the solicited TLS connection, 277 and it MUST close the TCP session. The receiver MAY choose to 278 attempt to re-establish the PCEP session without TLS next. The 279 attempt to re-establish the PCEP session without TLS SHOULD be 280 limited to only once. 282 If the PCEP speaker supports PCEPS and can establish a TLS connection 283 it MUST start the TLS connection negotiation and establishment steps 284 described in Section 3.4 before the PCEP initialization procedure 285 (section 4.2.1 of [RFC5440]). 287 After the exchange of StartTLS messages, if the TLS negotiation fails 288 for some reason (e.g. the required mechanisms for certificate 289 revocation checking are not available), both peers SHOULD immediately 290 close the connection. 292 A PCEP speaker that does not support PCEPS sends the Open message 293 directly, as per [RFC5440]. A PCEP speaker that supports PCEPS, but 294 has learned in the last exchange the peer's willingness to 295 reestablish session without TLS, MAY send the Open message directly, 296 as per [RFC5440]. The attempt to re-establish the PCEP session 297 without TLS SHOULD be limited to only once. 299 Given the asymmetric nature of TLS for connection establishment, it 300 is relevant to identify the roles of each of the PCEP peers in it. 301 The PCC SHALL act as TLS client, and the PCE SHALL act as TLS server 302 as per [RFC5246]. 304 As per the recommendation from [RFC7525] to avoid downgrade attacks, 305 PCEP peers that support PCEPS, SHOULD default to strict TLS 306 configuration i.e. do not allow non-TLS PCEP sessions to be 307 established. PCEPS implementations MAY provide an option to allow 308 the operator to manually override strict TLS configuration and allow 309 unsecured connections. Execution of this override SHOULD trigger a 310 warning about the security implications of permitting unsecured 311 connections. 313 3.3. The StartTLS Message 315 The StartTLS message is used to initiate the TLS procedure for a 316 PCEPS session between the PCEP peers. A PCEP speaker sends the 317 StartTLS message to request negotiation and establishment of TLS 318 connection for PCEP. On receiving a StartTLS message from the PCEP 319 peer (i.e. when the PCEP speaker has sent and received StartTLS 320 message) it is ready to start the negotiation and establishment of 321 TLS and move to steps described in Section 3.4. 323 The collision resolution procedures described in [RFC5440] for the 324 exchange of Open messages MUST be applied by the PCEP peers during 325 the exchange of StartTLS messages. 327 The format of a StartTLS message is as follows: 329 ::= 331 The StartTLS message MUST contain only the PCEP common header with 332 Message-Type field set to [TBA1 by IANA]. 334 Once the TCP connection has been successfully established, the PCEP 335 speaker MUST start a timer called StartTLSWait timer, after the 336 expiration of which, if neither StartTLS message has been received, 337 nor a PCErr/Open message (in case of failure and PCEPS not supported 338 by the peer, respectively), it MUST send a PCErr message with Error- 339 Type set to [TBA2 by IANA] and Error-value set to 5 (no StartTLS (nor 340 PCErr/Open) message received before the expiration of the 341 StartTLSWait timer) and it MUST release the TCP connection . A 342 RECOMMENDED value for StartTLSWait timer is 60 seconds. The value of 343 StartTLSWait timer MUST NOT be less than OpenWait timer. 345 +-+-+ +-+-+ 346 |PCC| |PCE| 347 +-+-+ +-+-+ 348 | | 349 | StartTLS | 350 | msg | 351 |------- | 352 | \ StartTLS | 353 | \ msg | 354 | \ ---------| 355 | \/ | 356 | /\ | 357 | / -------->| 358 | / | 359 |<------ | 360 |:::::::::TLS:::::::::| 361 |:::::Establishment:::| 362 | | 363 | | 364 |:::::::PCEP::::::::::| 365 | | 367 Figure 1: Both PCEP Speaker supports PCEPS (strict) 368 +-+-+ +-+-+ 369 |PCC| |PCE| 370 +-+-+ +-+-+ 371 | | 372 | StartTLS | 373 | msg | 374 |------- | 375 | \ StartTLS | 376 | \ msg | 377 | \ ---------| 378 | \/ | 379 | /\ | 380 | / -------->| 381 | / | 382 |<------ | 383 |:::::::::TLS:::::::::| TLS Establishment 384 |:::::Establishment:::| Failure, Both 385 | | peers close 386 session 388 Figure 2: Both PCEP Speaker supports PCEPS (strict), but cannot 389 establish TLS 391 +-+-+ +-+-+ 392 |PCC| |PCE| 393 +-+-+ +-+-+ 394 | | Does not support 395 | StartTLS | PCEPS and thus 396 | msg | sends Open 397 |------- | 398 | \ Open | 399 | \ msg | 400 | \ ---------| 401 | \/ | 402 | /\ | 403 | / -------->| 404 | / | 405 |<------ | 406 | | 407 |<--------------------| Send Error 408 | PCErr | Type=1,Value=1 409 | | (non-Open message 410 |<--------------------| received) 411 | Close | 412 ///////// TCP ///////// 413 //////re-establish///// 414 Send Open | Open | 415 this time | msg | 416 |------- | 417 | \ Open | 418 | \ msg | 419 | \ ---------| 420 | \/ | 421 | /\ | 422 | / -------->| 423 | / | 424 |<------ | 426 Figure 3: One PCEP Speaker (PCE) does not support PCEPS, while PCC 427 supports both with or without PCEPS 429 +-+-+ +-+-+ 430 |PCC| |PCE| 431 +-+-+ +-+-+ 432 | | 433 | StartTLS | 434 | msg | PCE waits 435 |-------------------->| for PCC and 436 | StartTLS | respond with 437 |<--------------------| Start TLS 438 | | 439 |:::::::::TLS:::::::::| 440 |:::::Establishment:::| 441 | | 442 | | 443 |:::::::PCEP::::::::::| 444 | | 446 Figure 4: Both PCEP Speaker supports PCEPS as well as without PCEPS 448 +-+-+ +-+-+ 449 |PCC| |PCE| 450 +-+-+ +-+-+ 451 | | 452 | StartTLS | 453 | msg | PCE waits 454 |-------------------->| for PCC 455 | PCErr | 456 |<--------------------| Send Error 457 | | Type=TBA2,Value=3 458 | | (Failure, connection 459 |<--------------------| without TLS is not 460 | Close | possible) 462 Figure 5: Both PCEP Speaker supports PCEPS as well as without PCEPS, 463 but PCE cannot start TLS negotiation 465 +-+-+ +-+-+ 466 |PCC| |PCE| 467 +-+-+ +-+-+ 468 | | 469 | Open | 470 | msg | PCE waits 471 |-------------------->| for PCC and 472 | Open | respond with 473 |<--------------------| Open 474 | | 475 |:::::::PCEP::::::::::| 476 | | 478 Figure 6: PCE supports PCEPS as well as without PCEPS, while PCC does 479 not support PCEPS 481 3.4. TLS Connection Establishment 483 Once the establishment of TLS has been agreed by the PCEP peers, the 484 connection establishment SHALL follow the following steps: 486 1. Immediately negotiate a TLS session according to [RFC5246]. The 487 following restrictions apply: 489 * Support for TLS v1.2 [RFC5246] or later is REQUIRED. 491 * Support for certificate-based mutual authentication is 492 REQUIRED. 494 * Negotiation of a ciphersuite providing for integrity 495 protection is REQUIRED. 497 * Negotiation of a ciphersuite providing for confidentiality is 498 RECOMMENDED. 500 * Support for and negotiation of compression is OPTIONAL. 502 * PCEPS implementations MUST, at a minimum, support negotiation 503 of the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC6460], and 504 SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as 505 well. Implementations SHOULD support the NIST P-256 506 (secp256r1) curve [RFC4492]. In addition, PCEPS 507 implementations MUST support negotiation of the mandatory-to- 508 implement ciphersuites required by the versions of TLS that 509 they support from TLS 1.3 onwards. 511 2. Peer authentication can be performed in any of the following two 512 REQUIRED operation models: 514 * TLS with X.509 certificates using Public-Key Infrastructure 515 Exchange (PKIX) trust models: 517 + Implementations MUST allow the configuration of a list of 518 trusted Certification Authorities (CAs) for incoming 519 connections. 521 + Certificate validation MUST include the verification rules 522 as per [RFC5280]. 524 + PCEPS implementations SHOULD incorporate revocation methods 525 (CRL downloading, OCSP...) according to the trusted CA 526 policies. 528 + Implementations SHOULD indicate their trusted CAs. For TLS 529 1.2, this is done using [RFC5246], Section 7.4.4, 530 "certificate_authorities" (server side) and [RFC6066], 531 Section 6 "Trusted CA Indication" (client side). 533 + Implementations MUST follow the rules and guidelines for 534 peer validation as defined in [RFC6125]. If an expected 535 DNS name or IP address for the peer is configured, then the 536 implementations MUST check them against the values in the 537 presented certificate. The DNS names and the IP addresses 538 can be contained in the CN-ID [RFC6125] (Common Name 539 Identifier) or the subjectAltName entries. For 540 verification, only one of these entries is considered. The 541 following precedence applies: for DNS name validation, DNS- 542 ID [RFC6125] has precedence over CN-ID; for IP address 543 validation, subjectAltName:iPAddr has precedence over CN- 544 ID. 546 + Implementations MAY allow the configuration of a set of 547 additional properties of the certificate to check for a 548 peer's authorization to communicate (e.g., a set of allowed 549 values in URI-ID [RFC6125] or a set of allowed X509v3 550 Certificate Policies). The definition of these properties 551 are out of scope of this document. 553 * TLS with X.509 certificates using certificate fingerprints: 554 Implementations MUST allow the configuration of a list of 555 certificates that are trusted to identify peers, identified 556 via fingerprint of the Distinguished Encoding Rules (DER) 557 encoded certificate octets. Implementations MUST support 558 SHA-256 as defined by [SHS] as the hash algorithm for the 559 fingerprint, but a later revision may demand support for a 560 stronger hash function. 562 3. Start exchanging PCEP messages. 564 * Once the TLS connection has been successfully established, the 565 PCEP speaker MUST start the OpenWait timer [RFC5440], after 566 the expiration of which, if no Open message has been received, 567 it sends a PCErr message and releases the TCP/TLS connection. 569 3.5. Peer Identity 571 Depending on the peer authentication method in use, PCEPS supports 572 different operation modes to establish peer's identity and whether it 573 is entitled to perform requests or can be considered authoritative in 574 its replies. PCEPS implementations SHOULD provide mechanisms for 575 associating peer identities with different levels of access and/or 576 authoritativeness, and they MUST provide a mechanism for establishing 577 a default level for properly identified peers. Any connection 578 established with a peer that cannot be properly identified SHALL be 579 terminated before any PCEP exchange takes place. 581 In TLS-X.509 mode using fingerprints, a peer is uniquely identified 582 by the fingerprint of the presented certificate. 584 There are numerous trust models in PKIX environments, and it is 585 beyond the scope of this document to define how a particular 586 deployment determines whether a peer is trustworthy. Implementations 587 that want to support a wide variety of trust models should expose as 588 many details of the presented certificate to the administrator as 589 possible so that the trust model can be implemented by the 590 administrator. At least the following parameters of the X.509 591 certificate SHOULD be exposed: 593 o Peer's IP address 595 o Peer's fully qualified domain name (FQDN) 597 o Certificate Fingerprint 599 o Issuer 601 o Subject 603 o All X509v3 Extended Key Usage 605 o All X509v3 Subject Alternative Name 607 o All X509v3 Certificate Policies 608 Note that the remote IP address used for the TCP session 609 establishment is also exposed. 611 [I-D.ietf-pce-stateful-sync-optimizations] specify a Speaker Entity 612 Identifier TLV (SPEAKER-ENTITY-ID), as an optional TLV that is 613 included in the OPEN Object. It contains a unique identifier for the 614 node that does not change during the lifetime of the PCEP speaker. 615 An implementation would thus expose the speaker entity identifier as 616 part of the X509v3 certificate's subjectAltName:otherName, so that an 617 implementation could use this identifier for the peer identification 618 trust model. 620 In addition, a PCC MAY apply the procedures described in [RFC6698] 621 DNS-Based Authentication of Named Entities (DANE) to verify its peer 622 identity when using DNS discovery. See section Section 4.1 for 623 further details. 625 3.6. Connection Establishment Failure 627 In case the initial TLS negotiation or the peer identity check fails, 628 according to the procedures listed in this document, both peers 629 SHOULD immediately close the connection. 631 The initiator SHOULD follow the procedure listed in [RFC5440] to 632 retry session setup as per the exponential back-off session 633 establishment retry procedure. 635 4. Discovery Mechanisms 637 This document does not specify any discovery mechanism for support of 638 PCEPS. Other documents, [I-D.wu-pce-discovery-pceps-support] and 639 [I-D.wu-pce-dns-pce-discovery] have made proposals: 641 o A PCE can advertise its capability to support PCEPS using the 642 IGP's advertisement mechanism of the PCE discovery information. 643 The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to advertise 644 PCE capabilities. It is present within the PCE Discovery (PCED) 645 sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] provide 646 the description and processing rules for this sub-TLV when carried 647 within OSPF and IS-IS, respectively. PCE capability bits are 648 defined in [RFC5088]. A new capability flag bit for the PCE-CAP- 649 FLAGS sub-TLV that can be announced as an attribute to distribute 650 PCEP security support information is proposed in 651 [I-D.wu-pce-discovery-pceps-support]. 653 o A PCE can advertise its capability to support PCEPS using the DNS 654 [I-D.wu-pce-dns-pce-discovery] by identifying the support of TLS. 656 4.1. DANE Applicability 658 DANE [RFC6698] defines a secure method to associate the certificate 659 that is obtained from a TLS server with a domain name using DNS, 660 i.e., using the TLSA DNS resource record (RR) to associate a TLS 661 server certificate or public key with the domain name where the 662 record is found, thus forming a "TLSA certificate association". The 663 DNS information needs to be protected by DNS Security (DNSSEC). A 664 PCC willing to apply DANE to verify server identity MUST conform to 665 the rules defined in section 4 of [RFC6698]. The implementation MUST 666 support Service certificate constraint (TLSA Certificate Usages type 667 1) with Matching type 2 (SHA2-256) as described in 668 [RFC6698][RFC7671]. The server's domain name must be authorized 669 separately, as TLSA does not provide any useful authorization 670 guarantees. 672 5. Backward Compatibility 674 The procedures described in this document define a security container 675 for the transport of PCEP requests and replies carried by a TLS 676 connection initiated by means of a specific extended message 677 (StartTLS) that does not interfere with PCEP speaker implementations 678 not supporting it. 680 A PCC that does not support PCEPS will send Open message as the first 681 message on TCP establishment. A PCE that supports PCEPS only, will 682 send StartTLS message on TCP establishment. On receiving StartTLS 683 message, PCC would consider it as an error and behave according to 684 the existing error mechanism of [RFC5440] and send PCErr message with 685 Error-Type 1 (PCEP session establishment failure) and Error-Value 1 686 (reception of an invalid Open message or a non Open message) and 687 close the session. 689 A PCC that support PCEPS will send StartTLS message as the first 690 message on TCP establishment. A PCE that does not supports PCEPS, 691 would consider receiving StartTLS message as an error and respond 692 with PCErr message (with Error-Type 1 and Error-Value 1) and close 693 the session. 695 If a StartTLS message is received at any other time by a PCEP speaker 696 that does not implement PCEPS, it would consider it as an unknown 697 message and would behave according to the existing error mechanism of 698 [RFC5440] and send PCErr message with Error-Type 2 (Capability not 699 supported) and close the session. 701 An existing PCEP session cannot be upgraded to PCEPS, the session 702 needs to be terminated and reestablished as per the procedure 703 described in this document. During the incremental upgrade, the PCEP 704 speaker SHOULD allow session establishment with and without TLS. 705 Once both PCEP speakers are upgraded to support PCEPS, the PCEP 706 session is re-established with TLS, otherwise PCEP session without 707 TLS is setup. A redundant PCE MAY also be used during the 708 incremental deployment to take over the PCE undergoing upgrade. Once 709 the upgrade is completed, support for unsecured version SHOULD be 710 removed. 712 A PCE that accepts connections with or without PCEPS, it would 713 respond based on the message received from PCC. A PCC that supports 714 connection with or without PCEPS, it would first attempt to connect 715 with PCEPS and in case of error, it MAY retry to establish connection 716 without PCEPS. For successful TLS operations with PCEP, both PCEP 717 peers in the network would need to be upgraded to support this 718 document. 720 Note that, a PCEP implementation that support PCEPS would respond 721 with PCErr message with Error-Type set to [TBA2 by IANA] (PCEP 722 StartTLS failure) and Error-value set to 2 if any other message is 723 sent before StartTLS or Open. If the sender of the invalid message 724 is a PCEP implementation that does not support PCEPS, it will not be 725 able to understand this error. A PCEPS implementation could also 726 send the PCErr message as per [RFC5440] with Error-Type "PCEP session 727 establishment failure" and Error-value "reception of an invalid Open 728 message or a non Open message" before closing the session. 730 6. IANA Considerations 732 6.1. New PCEP Message 734 IANA is requested to allocate new message types within the "PCEP 735 Messages" sub-registry of the PCEP Numbers registry, as follows: 737 Value Description Reference 738 TBA1 The Start TLS Message (StartTLS) This document 740 6.2. New Error-Values 742 IANA is requested to allocate new Error Types and Error Values within 743 the " PCEP-ERROR Object Error Types and Values" sub-registry of the 744 PCEP Numbers registry, as follows: 746 Error- 747 Type Meaning Error-value Reference 749 TBA2 PCEP StartTLS 0:Unassigned This document 750 failure 1:Reception of This document 751 StartTLS after 752 any PCEP exchange 753 2:Reception of This document 754 any other message 755 apart from StartTLS, 756 Open or PCErr 757 3:Failure, connection This document 758 without TLS is not 759 possible 760 4:Failure, connection This document 761 without TLS is 762 possible 763 5:No StartTLS message This document 764 (nor PCErr/Open) 765 before StartTLSWait 766 timer expiry 768 7. Security Considerations 770 While the application of TLS satisfies the requirement on 771 confidentiality as well as fine-grained, policy-based peer 772 authentication, there are security threats that it cannot address. 773 It may be advisable to apply additional protection measures, in 774 particular in what relates to attacks specifically addressed to 775 forging the TCP connection underpinning TLS, especially in the case 776 of long-lived connections. One of these measures is the application 777 of TCP-AO (TCP Authentication Option [RFC5925]), which is fully 778 compatible with and deemed as complementary to TLS. The mechanisms 779 to configure the requirements to use TCP-AO and other lower-layer 780 protection measures with a particular peer are outside the scope of 781 this document. 783 Since computational resources required by TLS handshake and 784 ciphersuite are higher than unencrypted TCP, clients connecting to a 785 PCEPS server can more easily create high load conditions and a 786 malicious client might create a Denial-of-Service attack more easily. 788 Some TLS ciphersuites only provide integrity validation of their 789 payload, and provide no encryption, such ciphersuites SHOULD NOT be 790 used by default. Administrators MAY allow the usage of these 791 ciphersuites after careful weighting of the risk of relevant internal 792 data leakage, that can occur in such a case, as explicitly stated by 793 [RFC6952]. 795 When using certificate fingerprints to identify PCEPS peers, any two 796 certificates that produce the same hash value will be considered the 797 same peer. Therefore, it is important to make sure that the hash 798 function used is cryptographically uncompromised, so that attackers 799 are very unlikely to be able to produce a hash collision with a 800 certificate of their choice. This document mandates support for 801 SHA-256 as defined by [SHS], but a later revision may demand support 802 for stronger functions if suitable attacks on it are known. 804 PCEPS implementations that continue to accept connections without TLS 805 are susceptible to downgrade attacks as described in [RFC7457]. An 806 attacker could attempt to remove the use of StartTLS message that 807 request the use of TLS as it pass on the wire in clear, and further 808 inject a PCErr message that suggest to attempt PCEP connection 809 without TLS. 811 The guidance given in [RFC7525] SHOULD be followed to avoid attacks 812 on TLS. 814 8. Manageability Considerations 816 All manageability requirements and considerations listed in [RFC5440] 817 apply to PCEP protocol extensions defined in this document. In 818 addition, requirements and considerations listed in this section 819 apply. 821 8.1. Control of Function and Policy 823 A PCE or PCC implementation SHOULD allow configuring the PCEP 824 security via TLS capabilities as described in this document. 826 A PCE or PCC implementation supporting PCEP security via TLS MUST 827 support general TLS configuration as per [RFC5246]. At least the 828 configuration of one of the trust models and its corresponding 829 parameters, as described in Section 3.4 and Section 3.5, MUST be 830 supported by the implementation. 832 A PCEP implementation SHOULD allow configuring the StartTLSWait timer 833 value. 835 PCEPS implementations MAY provide an option to allow the operator to 836 manually override strict TLS configuration and allow unsecure 837 connections. Execution of this override SHOULD trigger a warning 838 about the security implications of permitting unsecure connections. 840 Further, the operator needs to develop suitable security policies 841 around PCEP within his network. The PCEP peers SHOULD provide ways 842 for the operator to complete the following tasks in regards to a PCEP 843 session: 845 o Determine if a session is protected via PCEPS. 847 o Determine the version of TLS, the mechanism used for 848 authentication, and the ciphersuite in use. 850 o Determine if the certificate could not be verified, and the reason 851 for this circumstance. 853 o Inspect the certificate offered by the PCEP peer. 855 o Be warned if StartTLS procedure fails for the PCEP peers, that are 856 known to support PCEPS via configurations or capability 857 advertisements. 859 8.2. Information and Data Models 861 The PCEP MIB module is defined in [RFC7420]. The MIB module could be 862 extended to include the ability to view the PCEPS capability, TLS 863 related information as well as TLS status for each PCEP peer. 865 Further, to allow the operator to configure the PCEPS capability and 866 various TLS related parameters as well as to view the current TLS 867 status for a PCEP session, the PCEP YANG module 868 [I-D.ietf-pce-pcep-yang] is extended to include TLS related 869 information. 871 8.3. Liveness Detection and Monitoring 873 Mechanisms defined in this document do not imply any new liveness 874 detection and monitoring requirements in addition to those already 875 listed in [RFC5440] and [RFC5246]. 877 8.4. Verifying Correct Operations 879 A PCEPS implementation SHOULD log error events and provide PCEPS 880 failure statistics with reasons. 882 8.5. Requirements on Other Protocols 884 Mechanisms defined in this document do not imply any new requirements 885 on other protocols. Note that, Section 4 list possible discovery 886 mechanism for support of PCEPS. 888 8.6. Impact on Network Operation 890 Mechanisms defined in this document do not have any significant 891 impact on network operations in addition to those already listed in 892 [RFC5440], and the policy and management implications discussed 893 above. 895 9. Acknowledgements 897 This specification relies on the analysis and profiling of TLS 898 included in [RFC6614] and the procedures described for the STARTTLS 899 command in [RFC4513]. 901 We would like to thank Joe Touch for his suggestions and support 902 regarding the StartTLS mechanisms. 904 Thanks to Daniel King for reminding the authors about manageability 905 considerations. 907 Thanks to Cyril Margaria for shepherding this document. 909 Thanks to David Mandelberg for early SECDIR review comments as well 910 as re-reviewing during IETF last call. 912 Thanks to Dan Frost for the RTGDIR review and comments. 914 Thanks to Dale Worley for the Gen-ART review and comments. 916 Also thanks to Tianran Zhou for OPSDIR review. 918 Thanks to Deborah Brungard for being the responsible AD and guiding 919 the authors as needed. 921 Thanks to Mirja Kuhlewind, Eric Rescorla, Warren Kumari, Kathleen 922 Moriarty, Suresh Krishnan, Ben Campbell and Alexey Melnikov for the 923 IESG review and comments. 925 10. References 927 10.1. Normative References 929 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 930 Requirement Levels", BCP 14, RFC 2119, 931 DOI 10.17487/RFC2119, March 1997, 932 . 934 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 935 (TLS) Protocol Version 1.2", RFC 5246, 936 DOI 10.17487/RFC5246, August 2008, 937 . 939 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 940 Housley, R., and W. Polk, "Internet X.509 Public Key 941 Infrastructure Certificate and Certificate Revocation List 942 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 943 . 945 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 946 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 947 DOI 10.17487/RFC5440, March 2009, 948 . 950 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 951 Extensions: Extension Definitions", RFC 6066, 952 DOI 10.17487/RFC6066, January 2011, 953 . 955 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 956 Verification of Domain-Based Application Service Identity 957 within Internet Public Key Infrastructure Using X.509 958 (PKIX) Certificates in the Context of Transport Layer 959 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 960 2011, . 962 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 963 of Named Entities (DANE) Transport Layer Security (TLS) 964 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 965 2012, . 967 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 968 "Recommendations for Secure Use of Transport Layer 969 Security (TLS) and Datagram Transport Layer Security 970 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 971 2015, . 973 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 974 Authentication of Named Entities (DANE) Protocol: Updates 975 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 976 October 2015, . 978 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 979 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 980 May 2017, . 982 [SHS] National Institute of Standards and Technology, "Secure 983 Hash Standard (SHS), FIPS PUB 180-4", 984 DOI 10.6028/NIST.FIPS.180-4, August 2015, 985 . 988 10.2. Informative References 990 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 991 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 992 for Transport Layer Security (TLS)", RFC 4492, 993 DOI 10.17487/RFC4492, May 2006, 994 . 996 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol 997 (LDAP): Authentication Methods and Security Mechanisms", 998 RFC 4513, DOI 10.17487/RFC4513, June 2006, 999 . 1001 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1002 Zhang, "OSPF Protocol Extensions for Path Computation 1003 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 1004 January 2008, . 1006 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1007 Zhang, "IS-IS Protocol Extensions for Path Computation 1008 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 1009 January 2008, . 1011 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1012 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1013 June 2010, . 1015 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 1016 Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC6460, 1017 January 2012, . 1019 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1020 "Transport Layer Security (TLS) Encryption for RADIUS", 1021 RFC 6614, DOI 10.17487/RFC6614, May 2012, 1022 . 1024 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1025 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1026 and Authentication for Routing Protocols (KARP) Design 1027 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1028 . 1030 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1031 Hardwick, "Path Computation Element Communication Protocol 1032 (PCEP) Management Information Base (MIB) Module", 1033 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1034 . 1036 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1037 Known Attacks on Transport Layer Security (TLS) and 1038 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1039 February 2015, . 1041 [I-D.ietf-pce-stateful-sync-optimizations] 1042 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1043 and D. Dhody, "Optimizations of Label Switched Path State 1044 Synchronization Procedures for a Stateful PCE", draft- 1045 ietf-pce-stateful-sync-optimizations-10 (work in 1046 progress), March 2017. 1048 [I-D.ietf-pce-pcep-yang] 1049 Dhody, D., Hardwick, J., Beeram, V., and j. 1050 jefftant@gmail.com, "A YANG Data Model for Path 1051 Computation Element Communications Protocol (PCEP)", 1052 draft-ietf-pce-pcep-yang-05 (work in progress), June 2017. 1054 [I-D.wu-pce-dns-pce-discovery] 1055 Wu, Q., Dhody, D., King, D., Lopez, D., and J. Tantsura, 1056 "Path Computation Element (PCE) Discovery using Domain 1057 Name System(DNS)", draft-wu-pce-dns-pce-discovery-10 (work 1058 in progress), March 2017. 1060 [I-D.wu-pce-discovery-pceps-support] 1061 Lopez, D., Wu, Q., Dhody, D., and D. King, "IGP extension 1062 for PCEP security capability support in the PCE 1063 discovery", draft-wu-pce-discovery-pceps-support-07 (work 1064 in progress), March 2017. 1066 Authors' Addresses 1068 Diego R. Lopez 1069 Telefonica I+D 1070 Don Ramon de la Cruz, 82 1071 Madrid 28006 1072 Spain 1074 Phone: +34 913 129 041 1075 EMail: diego.r.lopez@telefonica.com 1076 Oscar Gonzalez de Dios 1077 Telefonica I+D 1078 Don Ramon de la Cruz, 82 1079 Madrid 28006 1080 Spain 1082 Phone: +34 913 129 041 1083 EMail: oscar.gonzalezdedios@telefonica.com 1085 Qin Wu 1086 Huawei 1087 101 Software Avenue, Yuhua District 1088 Nanjing, Jiangsu 210012 1089 China 1091 EMail: sunseawq@huawei.com 1093 Dhruv Dhody 1094 Huawei 1095 Divyashree Techno Park, Whitefield 1096 Bangalore, KA 560066 1097 India 1099 EMail: dhruv.ietf@gmail.com