idnits 2.17.1 draft-ietf-pce-pceps-11.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 (January 03, 2017) is 2664 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' == Outdated reference: A later version (-10) exists of draft-wu-pce-dns-pce-discovery-09 == Outdated reference: A later version (-07) exists of draft-wu-pce-discovery-pceps-support-06 Summary: 1 error (**), 0 flaws (~~), 3 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: July 7, 2017 D. Dhody 7 Huawei 8 January 03, 2017 10 Secure Transport for PCEP 11 draft-ietf-pce-pceps-11 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 July 7, 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 . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . 14 92 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 14 93 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 14 94 8.5. Requirements on Other Protocols . . . . . . . . . . . . . 15 95 8.6. Impact on Network Operations . . . . . . . . . . . . . . 15 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 99 10.2. Informative References . . . . . . . . . . . . . . . . . 16 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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-know 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 the PCEPS establishment consists of following 155 successive steps: 157 1. Establishment of a TCP connection. 159 2. Initiating the TLS procedures by the StartTLS message from PCE to 160 PCC and from PCC to PCE. 162 3. Establishment of TLS connection. 164 4. Start exchanging PCEP messages as per [RFC5440]. 166 It should be noted that this procedure updates what is defined in 167 section 4.2.1 and section 6.7 of [RFC5440] regarding the 168 initialization phase and the processing of messages prior to the Open 169 message. The details of processing including backward compatibility 170 are discussed in the following sections. 172 3.2. Initiating the TLS Procedures 174 Since PCEP can operate either with or without TLS, it is necessary 175 for the PCEP speaker to indicate whether it wants to set up a TLS 176 connection or not. For this purpose, this document specifies a new 177 PCEP message called StartTLS. This message MUST be issued by the 178 party willing to use TLS, prior to any other PCEP message including 179 open message. This document thus updates [RFC5440] which required 180 the Open message to be the first PCEP message, since in the case of a 181 PCEP session using TLS the StartTLS message will be sent first. 183 The PCEP speaker MAY discover that the PCEP peer supports PCEPS or 184 can be preconfigured to use PCEPS for a given peer (see Section 4 for 185 more details). Thus the PCEP session is secured via TLS from the 186 start before exchange of any other PCEP message including the Open 187 message. Securing via TLS of an existing PCEP session is not 188 permitted, the session must be closed and re-established with TLS as 189 per the procedure described in this document. 191 The StartTLS message is a PCEP message sent by a PCC to a PCE and by 192 a PCE to a PCC in order to initiate the TLS procedure for PCEP. The 193 Message-Type field of the PCEP common header for the StartTLS message 194 is set to [TBA1 by IANA]. 196 Once the TCP connection has been successfully established, the first 197 message sent by the PCC to the PCE and by the PCE to the PCC MUST be 198 a StartTLS message for the PCEPS. Note this is a significant change 199 from [RFC5440] where the first PCEP message is Open. 201 A PCEP speaker receiving a StartTLS message after any other PCEP 202 exchange has taken place (by receiving or sending any other messages 203 from either side) MUST treat it as an unexpected message and reply 204 with a PCErr message with Error-Type set to [TBA2 by IANA] (PCEP 205 StartTLS failure) and Error-value set to 1 (reception of StartTLS 206 after any PCEP exchange), and MUST close the TCP connection. A PCEP 207 speaker receiving any other message apart from StartTLS, open, or 208 PCErr MUST treat it as an unexpected message and reply with a PCErr 209 message with Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure) 210 and Error-value set to 2 (reception of any other message apart from 211 StartTLS, Open, or PCErr message), and MUST close the TCP connection. 213 If the PCEP speaker that does not support PCEPS, receives a StartTLS 214 message, it MUST behave according to the existing error mechanism 215 described in section 6.2 of [RFC5440] (in case message is received 216 prior to an Open message) or section 6.9 of [RFC5440] (for the case 217 of reception of unknown message). 219 If the PCEP speaker supports PCEPS but cannot establish a TLS 220 connection for some reason (e.g. the required mechanisms for 221 certificate revocation checking are not available) it MUST return a 222 PCErr message with Error-Type set to [TBA2 by IANA] (PCEP StartTLS 223 failure) and Error-value set to: 225 o 3 (not without TLS) if it is not willing to exchange PCEP messages 226 without the solicited TLS connection, and it MUST close the TCP 227 session. 229 o 4 (ok without TLS) if it is willing to exchange PCEP messages 230 without the solicited TLS connection, and it MUST close the TCP 231 session. The peer MAY choose to re-establish the PCEP session 232 without TLS next. 234 If the PCEP speaker supports PCEPS and can establish a TLS connection 235 it MUST start the TLS connection establishment steps described in 236 Section 3.4 before the PCEP initialization procedure (section 4.2.1 237 of [RFC5440]). 239 A PCEP speaker that does not support PCEPS or has learned the peer 240 willingness to reestablish session without TLS, can send the Open 241 message directly, as per [RFC5440]. 243 Given the asymmetric nature of TLS for connection establishment it is 244 relevant to identify the roles of each of the PCEP peers in it. The 245 PCC SHALL act as TLS client, and the PCE SHALL act as TLS server, 246 according to [RFC5246]. 248 These procedures minimize the impact of PCEPS support in PCEP 249 implementations without requiring additional dedicated ports for 250 running PCEP with TLS. 252 3.3. The StartTLS Message 254 The StartTLS message is used to initiate the TLS procedure for a 255 PCEPS session between the PCEP peers. A PCEP speaker sends the 256 StartTLS message to request negotiation and establishment of TLS 257 connection for PCEP. On receiving a StartTLS message from the PCEP 258 peer (i.e. when the PCEP speaker has sent and received StartTLS 259 message) it is ready to start TLS negotiation and establishment and 260 move to steps described in Section 3.4. 262 The collision resolution procedures described in [RFC5440] for the 263 exchange of Open messages MUST be applied by the PCEP peers during 264 the exchange of StartTLS messages. 266 The format of a StartTLS message is as follows: 268 ::= 270 The StartTLS message MUST contain only the PCEP common header with 271 Message-Type field set to [TBA1 by IANA]. 273 Once the TCP connection has been successfully established and the 274 StartTLS message sent, the sender MUST start a timer called 275 StartTLSWait timer, after the expiration of which, if no StartTLS 276 message has been received, it sends a PCErr message and releases the 277 TCP connection with Error-Type set to [TBA2 by IANA] and Error-value 278 set to 5 (no StartTLS message received before the expiration of the 279 StartTLSWait timer). A RECOMMENDED value for StartTLSWait timer is 280 60 seconds. 282 +-+-+ +-+-+ 283 |PCC| |PCE| 284 +-+-+ +-+-+ 285 | | 286 | StartTLS | 287 | msg | 288 |------- | 289 | \ StartTLS | 290 | \ msg | 291 | \ ---------| 292 | \/ | 293 | /\ | 294 | / -------->| 295 | / | 296 |<------ | 297 |:::::::::TLS:::::::::| 298 |:::::Establishment:::| 299 | | 300 | | 301 |:::::::PCEP::::::::::| 302 | | 304 Figure 1: Both PCEP Speaker supports PCEPS 306 +-+-+ +-+-+ 307 |PCC| |PCE| 308 +-+-+ +-+-+ 309 | | Does not send 310 | StartTLS | StartTLS as 311 |-------------------->| cannot establish 312 | | TLS 313 | | 314 |<--------------------| Send Error 315 | PCErr | Error-Value 3/4 316 | | 318 Figure 2: Both PCEP Speaker supports PCEPS, But cannot establish TLS 319 +-+-+ +-+-+ 320 |PCC| |PCE| 321 +-+-+ +-+-+ 322 | | Does not support 323 | StartTLS | PCEPS and thus 324 | msg | sends Open 325 |------- | 326 | \ Open | 327 | \ msg | 328 | \ ---------| 329 | \/ | 330 | /\ | 331 | / -------->| 332 | / | 333 |<------ | 334 | | 335 |<--------------------| Send Error 336 | PCErr | (non-Open message 337 | | received) 339 Figure 3: One PCEP Speaker does not support PCEPS 341 3.4. TLS Connection Establishment 343 Once the establishment of TLS has been agreed by the PCEP peers, the 344 connection establishment SHALL follow the following steps: 346 1. Immediately negotiate TLS sessions according to [RFC5246]. The 347 following restrictions apply: 349 * Support for TLS v1.2 [RFC5246] or later is REQUIRED. 351 * Support for certificate-based mutual authentication is 352 REQUIRED. 354 * Negotiation of mutual authentication is REQUIRED. 356 * Negotiation of a ciphersuite providing for integrity 357 protection is REQUIRED. 359 * Negotiation of a ciphersuite providing for confidentiality is 360 RECOMMENDED. 362 * Support for and negotiation of compression is OPTIONAL. 364 * PCEPS implementations MUST, at a minimum, support negotiation 365 of the TLS_RSA_WITH_AES_128_GCM_SHA256, and SHOULD support 366 TLS_RSA_WITH_AES_256_GCM_SHA384 as well [RFC5288]. In 367 addition, PCEPS implementations MUST support negotiation of 368 the mandatory-to-implement ciphersuites required by the 369 versions of TLS that they support. 371 2. Peer authentication can be performed in any of the following two 372 REQUIRED operation models: 374 * TLS with X.509 certificates using Public-Key Infrastructure 375 Exchange (PKIX) trust models: 377 + Implementations MUST allow the configuration of a list of 378 trusted Certification Authorities (CAs) for incoming 379 connections. 381 + Certificate validation MUST include the verification rules 382 as per [RFC5280]. 384 + PCEPS implementations SHOULD incorporate revocation methods 385 (CRL downloading, OCSP...) according to the trusted CA 386 policies. 388 + Implementations SHOULD indicate their trusted CAs. For TLS 389 1.2, this is done using [RFC5246], Section 7.4.4, 390 "certificate_authorities" (server side) and [RFC6066], 391 Section 6 "Trusted CA Indication" (client side). 393 + Peer validation always SHOULD include a check on whether 394 the locally configured expected DNS name or IP address of 395 the peer that is contacted matches its presented 396 certificate. DNS names and IP addresses can be contained 397 in the Common Name (CN) or subjectAltName entries. For 398 verification, only one of these entries is to be 399 considered. The following precedence applies: for DNS name 400 validation, subjectAltName:DNS has precedence over CN; for 401 IP address validation, subjectAltName:iPAddr has precedence 402 over CN. 404 + Implementations MAY allow the configuration of a set of 405 additional properties of the certificate to check for a 406 peer's authorization to communicate (e.g., a set of allowed 407 values in subjectAltName:URI or a set of allowed X509v3 408 Certificate Policies) 410 * TLS with X.509 certificates using certificate fingerprints: 411 Implementations MUST allow the configuration of a list of 412 trusted certificates, identified via fingerprint of the 413 Distinguished Encoding Rules (DER) encoded certificate octets. 414 Implementations MUST support SHA-256 as defined by [SHS] as 415 the hash algorithm for the fingerprint. 417 3. Start exchanging PCEP messages. 419 To support TLS re-negotiation both peers MUST support the mechanism 420 described in [RFC5746]. Any attempt of initiate a TLS handshake to 421 establish new cryptographic parameters not aligned with [RFC5746] 422 SHALL be considered a TLS negotiation failure. 424 3.5. Peer Identity 426 Depending on the peer authentication method in use, PCEPS supports 427 different operation modes to establish peer's identity and whether it 428 is entitled to perform requests or can be considered authoritative in 429 its replies. PCEPS implementations SHOULD provide mechanisms for 430 associating peer identities with different levels of access and/or 431 authoritativeness, and they MUST provide a mechanism for establish a 432 default level for properly identified peers. Any connection 433 established with a peer that cannot be properly identified SHALL be 434 terminated before any PCEP exchange takes place. 436 In TLS-X.509 mode using fingerprints, a peer is uniquely identified 437 by the fingerprint of the presented certificate. 439 There are numerous trust models in PKIX environments, and it is 440 beyond the scope of this document to define how a particular 441 deployment determines whether a peer is trustworthy. Implementations 442 that want to support a wide variety of trust models should expose as 443 many details of the presented certificate to the administrator as 444 possible so that the trust model can be implemented by the 445 administrator. As a suggestion, at least the following parameters of 446 the X.509 certificate should be exposed: 448 o Peer's IP address 450 o Peer's fully qualified domain name (FQDN) 452 o Certificate Fingerprint 454 o Issuer 456 o Subject 458 o All X509v3 Extended Key Usage 459 o All X509v3 Subject Alternative Name 461 o All X509v3 Certificate Policies 463 In addition, a PCC MAY apply the procedures described in [RFC6698] 464 DNS-Based Authentication of Named Entities (DANE) to verify its peer 465 identity when using DNS discovery. See section Section 4.1 for 466 further details. 468 3.6. Connection Establishment Failure 470 In case the initial TLS negotiation or the peer identity check fail 471 according to the procedures listed in this document, the peer MUST 472 immediately terminate the session. It SHOULD follow the procedure 473 listed in [RFC5440] to retry session setup along with an exponential 474 back-off session establishment retry procedure. 476 4. Discovery Mechanisms 478 A PCE can advertise its capability to support PCEPS using the IGP 479 advertisement and discovery mechanism. The PCE-CAP-FLAGS sub-TLV is 480 an optional sub-TLV used to advertise PCE capabilities. It MAY be 481 present within the PCE Discovery (PCED) sub-TLV carried by OSPF or 482 IS-IS. [RFC5088] and [RFC5089] provide the description and 483 processing rules for this sub-TLV when carried within OSPF and IS-IS, 484 respectively. PCE capability bits are defined in [RFC5088]. A new 485 capability flag bit for the PCE-CAP-FLAGS sub-TLV that can be 486 announced as attribute to distribute PCEP security support 487 information is proposed in [I-D.wu-pce-discovery-pceps-support] 489 When DNS is used by a PCC (or a PCE acting as a client, for the rest 490 of the section, PCC refers to both) willing to use PCEPS to locate an 491 appropriate PCE [I-D.wu-pce-dns-pce-discovery], the PCC as an 492 initiating entity, chooses at least one of the returned FQDNs to 493 resolve, which it does by performing DNS "A" or "AAAA" lookups on the 494 FDQN. This will eventually result in an IPv4 or IPv6 address. The 495 PCC SHALL use the IP address(es) from the successfully resolved FDQN 496 (with the corresponding port number returned by the DNS Service 497 Record (SRV) lookup) as the connection address(es) for the receiving 498 entity. 500 If the PCC fails to connect using an IP address but the "A" or "AAAA" 501 lookups returned more than one IP address, then the PCC SHOULD use 502 the next resolved IP address for that FDQN as the connection address. 503 If the PCC fails to connect using all resolved IP addresses for a 504 given FDQN, then it SHOULD repeat the process of resolution and 505 connection for the next FQDN returned by the SRV lookup based on the 506 priority and weight. 508 If the PCC receives a response to its SRV query but it is not able to 509 establish a PCEPS connection using the data received in the response, 510 as initiating entity it MAY fall back to lookup a PCE that uses TCP 511 as transport. 513 4.1. DANE Applicability 515 DANE [RFC6698] defines a secure method to associate the certificate 516 that is obtained from a TLS server with a domain name using DNS, 517 i.e., using the TLSA DNS resource record (RR) to associate a TLS 518 server certificate or public key with the domain name where the 519 record is found, thus forming a "TLSA certificate association". The 520 DNS information needs to be protected by DNS Security (DNSSEC). A 521 PCC willing to apply DANE to verify server identity MUST conform to 522 the rules defined in section 4 of [RFC6698]. The server's domain 523 name must be authorized separately, as TLSA does not provide any 524 useful authorization guarantees. 526 5. Backward Compatibility 528 The procedures described in this document define a security container 529 for the transport of PCEP requests and replies carried by a TLS 530 connection initiated by means of a specific extended message 531 (StartTLS) that does not interfere with PCEP speaker implementations 532 not supporting it. 534 If a PCEP implementation that does not support PCEPS receives a 535 StartTLS message it MUST behave according to the existing error 536 mechanism of [RFC5440]. 538 6. IANA Considerations 540 6.1. New PCEP Message 542 Each PCEP message has a message type value. 544 One new PCEP messages is defined in this document: 546 Value Description Reference 547 TBA1 The Start TLS Message (StartTLS) This document 549 6.2. New Error-Values 551 A registry was created for the Error-type and Error-value of the PCEP 552 Error Object. Following new Error-Types and Error-Values are 553 defined: 555 Error- 556 Type Meaning Error-value Reference 558 TBA2 StartTLS Failure 0:Unassigned This document 559 1:Reception of This document 560 StartTLS after 561 any PCEP exchange 562 2:Reception of This document 563 any other message 564 apart from StartTLS, 565 Open or PCErr 566 3:Failure, connection This document 567 without TLS not 568 possible 569 4:Failure, connection This document 570 without TLS possible 571 5:No StartTLS message This document 572 before StartTLSWait 573 timer expiry 575 7. Security Considerations 577 While the application of TLS satisfies the requirement on privacy as 578 well as fine-grained, policy-based peer authentication, there are 579 security threats that it cannot address. It is advisable to apply 580 additional protection measures, in particular in what relates to 581 attacks specifically addressed to forging the TCP connection 582 underpinning TLS. TCP-AO (TCP Authentication Option [RFC5925]) is 583 fully compatible with and deemed as complementary to TLS, so its 584 usage is to be considered as a security enhancement whenever any of 585 the PCEPS peers require it, especially in the case of long-lived 586 connections. The mechanisms to configure the requirements to use 587 TCP-AO and other lower-layer protection measures, as well as the 588 association of the required crypto material (MKT in the case of TCP- 589 AO) with a particular peer are outside the scope of this document. 590 [I-D.chunduri-karp-using-ikev2-with-tcp-ao] defines a method to 591 perform such association. 593 Since computational resources required by TLS handshake and 594 ciphersuite are higher than unencrypted TCP, clients connecting to a 595 PCEPS server can more easily create high load conditions and a 596 malicious client might create a Denial-of-Service attack more easily. 598 Some TLS ciphersuites only provide integrity validation of their 599 payload, and provide no encryption. This specification does not 600 forbid the use of such ciphersuites, but administrators must weight 601 carefully the risk of relevant internal data leakage that can occur 602 in such a case, as explicitly stated by [RFC6952]. 604 When using certificate fingerprints to identify PCEPS peers, any two 605 certificates that produce the same hash value will be considered the 606 same peer. Therefore, it is important to make sure that the hash 607 function used is cryptographically uncompromised so that attackers 608 are very unlikely to be able to produce a hash collision with a 609 certificate of their choice. This document mandates support for 610 SHA-256 as defined by [SHS], but a later revision may demand support 611 for stronger functions if suitable attacks on it are known. 613 8. Manageability Considerations 615 All manageability requirements and considerations listed in [RFC5440] 616 apply to PCEP protocol extensions defined in this document. In 617 addition, requirements and considerations listed in this section 618 apply. 620 8.1. Control of Function and Policy 622 A PCE or PCC implementation MUST allow configuring the PCEP security 623 via TLS capabilities as described in this document. 625 A PCE or PCC implementation supporting PCEP security via TLS MUST 626 support general TLS configuration as per [RFC5246]. At least the 627 configuration of one of the trust models and its corresponding 628 parameters, as described in Section 3.4 and Section 3.5, MUST be 629 supported by the implementation. 631 A PCEP implementation SHOULD allow configuring the following PCEP 632 security parameters: 634 o StartTLSWait timer value 636 8.2. Information and Data Models 638 The PCEP MIB module SHOULD be extended to include PCEPS capabilities, 639 information, and status. 641 8.3. Liveness Detection and Monitoring 643 Mechanisms defined in this document do not imply any new liveness 644 detection and monitoring requirements in addition to those already 645 listed in [RFC5440] and [RFC5246]. 647 8.4. Verify Correct Operations 649 A PCEPS implementation SHOULD log error events and provide PCEPS 650 failure statistics with reasons. 652 8.5. Requirements on Other Protocols 654 Mechanisms defined in this document do not imply any new requirements 655 on other protocols. 657 8.6. Impact on Network Operations 659 Mechanisms defined in this document do not have any impact on network 660 operations in addition to those already listed in [RFC5440]. 662 9. Acknowledgements 664 This specification relies on the analysis and profiling of TLS 665 included in [RFC6614] and the procedures described for the STARTTLS 666 command in [RFC4513]. 668 We would like to thank Joe Touch for his suggestions and support 669 regarding the TLS start mechanisms. 671 Thanks to Dan King for reminding the authors about manageability 672 considerations. 674 10. References 676 10.1. Normative References 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, 680 DOI 10.17487/RFC2119, March 1997, 681 . 683 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 684 (TLS) Protocol Version 1.2", RFC 5246, 685 DOI 10.17487/RFC5246, August 2008, 686 . 688 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 689 Housley, R., and W. Polk, "Internet X.509 Public Key 690 Infrastructure Certificate and Certificate Revocation List 691 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 692 . 694 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 695 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 696 DOI 10.17487/RFC5288, August 2008, 697 . 699 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 700 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 701 DOI 10.17487/RFC5440, March 2009, 702 . 704 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 705 "Transport Layer Security (TLS) Renegotiation Indication 706 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 707 . 709 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 710 Extensions: Extension Definitions", RFC 6066, 711 DOI 10.17487/RFC6066, January 2011, 712 . 714 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 715 of Named Entities (DANE) Transport Layer Security (TLS) 716 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 717 2012, . 719 [SHS] National Institute of Standards and Technology, "Secure 720 Hash Standard (SHS), FIPS PUB 180-4", 721 DOI 10.6028/NIST.FIPS.180-4, August 2015, 722 . 725 10.2. Informative References 727 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol 728 (LDAP): Authentication Methods and Security Mechanisms", 729 RFC 4513, DOI 10.17487/RFC4513, June 2006, 730 . 732 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 733 Zhang, "OSPF Protocol Extensions for Path Computation 734 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 735 January 2008, . 737 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 738 Zhang, "IS-IS Protocol Extensions for Path Computation 739 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 740 January 2008, . 742 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 743 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 744 June 2010, . 746 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 747 "Transport Layer Security (TLS) Encryption for RADIUS", 748 RFC 6614, DOI 10.17487/RFC6614, May 2012, 749 . 751 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 752 BGP, LDP, PCEP, and MSDP Issues According to the Keying 753 and Authentication for Routing Protocols (KARP) Design 754 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 755 . 757 [I-D.wu-pce-dns-pce-discovery] 758 Wu, W., Dhody, D., King, D., Lopez, D., and J. Tantsura, 759 "Path Computation Element (PCE) Discovery using Domain 760 Name System(DNS)", draft-wu-pce-dns-pce-discovery-09 (work 761 in progress), December 2015. 763 [I-D.wu-pce-discovery-pceps-support] 764 Lopez, D., Wu, Q., Dhody, D., and D. King, "IGP extension 765 for PCEP security capability support in the PCE 766 discovery", draft-wu-pce-discovery-pceps-support-06 (work 767 in progress), August 2016. 769 [I-D.chunduri-karp-using-ikev2-with-tcp-ao] 770 Chunduri, U., Tian, A., and J. Touch, "A framework for RPs 771 to use IKEv2 KMP", draft-chunduri-karp-using-ikev2-with- 772 tcp-ao-06 (work in progress), February 2014. 774 Authors' Addresses 776 Diego R. Lopez 777 Telefonica I+D 778 Don Ramon de la Cruz, 82 779 Madrid 28006 780 Spain 782 Phone: +34 913 129 041 783 EMail: diego.r.lopez@telefonica.com 785 Oscar Gonzalez de Dios 786 Telefonica I+D 787 Don Ramon de la Cruz, 82 788 Madrid 28006 789 Spain 791 Phone: +34 913 129 041 792 EMail: oscar.gonzalezdedios@telefonica.com 793 Qin Wu 794 Huawei 795 101 Software Avenue, Yuhua District 796 Nanjing, Jiangsu 210012 797 China 799 EMail: sunseawq@huawei.com 801 Dhruv Dhody 802 Huawei 803 Divyashree Techno Park, Whitefield 804 Bangalore, KA 560066 805 India 807 EMail: dhruv.ietf@gmail.com