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