idnits 2.17.1 draft-ietf-pce-pceps-01.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 (September 10, 2014) is 3510 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-07) exists of draft-wu-pce-discovery-pceps-support-01 == Outdated reference: A later version (-10) exists of draft-wu-pce-dns-pce-discovery-06 -- Obsolete informational reference (is this intentional?): RFC 2830 (Obsoleted by RFC 4510, RFC 4511, RFC 4513) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Path Computation Element D. Lopez 3 Internet-Draft O. Gonzalez de Dios 4 Intended status: Experimental Telefonica I+D 5 Expires: March 14, 2015 Q. Wu 6 D. Dhody 7 Huawei 8 September 10, 2014 10 Secure Transport for PCEP 11 draft-ietf-pce-pceps-01 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 its flexibility and 22 extensibility. 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 March 14, 2015. 41 Copyright Notice 43 Copyright (c) 2014 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. Initiating the TLS Procedures . . . . . . . . . . . . . . 4 62 3.2. The StartTLS Message . . . . . . . . . . . . . . . . . . . 5 63 3.3. TLS Connection Establishment . . . . . . . . . . . . . . . 5 64 3.4. Peer Identity . . . . . . . . . . . . . . . . . . . . . . 6 65 3.5. Connection Establishment Failure . . . . . . . . . . . . . 7 66 4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. DANE Applicability . . . . . . . . . . . . . . . . . . . . 8 68 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 PCEP [RFC5440] defines the mechanisms for the communication between a 80 Path Computation Client (PCC) and a Path Computation Element (PCE), 81 or between two PCEs. These interactions include requests and replies 82 that can be critical for a sustainable network operation and adequate 83 resource allocation, and therefore appropriate security becomes a key 84 element in the PCE infrastructure. As the applications of the PCE 85 framework evolves, and more complex service patterns emerge, the 86 definition of a secure mode of operation becomes more relevant. 88 [RFC5440] analyzes in its section on security considerations the 89 potential threats to PCEP and their consequences, and discusses 90 several mechanisms for protecting PCEP against security attacks, 91 without making a specific recommendation on a particular one or 92 defining their application in depth. Moreover, [RFC6952] remarks the 93 importance of ensuring PCEP communication privacy, especially when 94 PCEP communication endpoints do not reside in the same AS, as the 95 interception of PCEP messages could leak sensitive information 96 related to computed paths and resources. 98 Among the possible solutions mentioned in these documents, Transport 99 Layer Security (TLS) [RFC5246] provides support for peer 100 authentication, and message encryption and integrity. TLS supports 101 the usage of well-know mechanisms to support key configuration and 102 exchange, and means to perform security checks on the results of PCE 103 discovery procedures via IGP ([RFC5088] and [RFC5089]). 105 This document describes a security container for the transport of 106 PCEP requests and replies, and therefore it will not interfere with 107 the protocol flexibility and extensibility. 109 This document describes how to apply TLS in securing PCE 110 interactions, including initiation of the TLS procedures, the TLS 111 handshake mechanisms, the TLS methods for peer authentication, the 112 applicable TLS ciphersuites for data exchange, and the handling of 113 errors in the security checks. In the rest of the document we will 114 refer to this usage of TLS to provide a secure transport for PCEP as 115 "PCEPS". 117 2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. Applying PCEPS 125 3.1. Initiating the TLS Procedures 127 Since PCEP can operate either with or without TLS, it is necessary 128 for the PCEP peer to indicate whether it wants to set up a TLS 129 connection or not. For this purpose, this document proposes a new 130 PCEP message, StartTLS, that MUST be issued by the party willing to 131 use TLS prior to any other PCEP command. PCEP peers MAY discover 132 that the other PCEP endpoint supports PCEPS or can be preconfigured 133 to use PCEPS for a given peer (see section Section 4 for more 134 details). 136 A PCEP peer receiving a StartTLS message after any PCEP exchange has 137 taken place (by receiving or sending any messages from either side) 138 MUST treat it as an unexpected message and reply with a PCErr 139 message, according to the procedure described in section 6.7 of 140 [RFC5440] for the unexpected message condition. 142 If the PCEP peer does not support PCEPS and receives a StartTLS 143 message it MUST behave as described in section 6.2 of [RFC5440] for 144 the case of any message received prior to an Open message. 146 If the PCEP peer supports PCEPS but cannot establish a TLS connection 147 for some reason (e.g. the certificate server is not responding) it 148 MUST return a PCErr message with Error-Type set to 1 (PCEP session 149 establishment failure) and Error-value set to: 151 o 3 (unacceptable and non-negotiable session characteristics) if it 152 is not willing to exchange PCEP messages without the solicited TLS 153 connection 155 o 4 (unacceptable but negotiable session characteristics) if it is 156 willing to exchange PCEP messages without the solicited TLS 157 connection 159 If the PCEP peer supports PCEPS and can establish a TLS connection it 160 MUST start the TLS connection establishment steps described in 161 section Section 3.3 below. 163 These procedures minimize the impact of PCEPS support in PCEP 164 implementations without requiring additional dedicated ports for 165 running PCEP on TLS. 167 NOTE: These procedures update what is defined in section 6.7 of 168 [RFC5440] regarding the processing of messages prior to Open. This 169 has to be explicitly discussed here 171 3.2. The StartTLS Message 173 NOTE: To be elaborated as we gather implementation experience. 175 3.3. TLS Connection Establishment 177 Once the establishment of TLS has been agreed by the PCEP peers, the 178 connection establishment SHALL follow the following steps: 180 1. Immediately negotiate TLS sessions according to [RFC5246]. The 181 following restrictions apply: 183 * Support for TLS v1.2 [RFC5246] or later is REQUIRED. 185 * Support for certificate-based mutual authentication is 186 REQUIRED. 188 * Negotiation of mutual authentication is REQUIRED. 190 * Negotiation of a ciphersuite providing for integrity 191 protection is REQUIRED. 193 * Negotiation of a ciphersuite providing for confidentiality is 194 RECOMMENDED. 196 * Support for and negotiation of compression is OPTIONAL. 198 * PCEPS implementations MUST, at a minimum, support negotiation 199 of the TLS_RSA_WITH_3DES_EDE_CBC_SHA, and SHOULD support 200 TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as 201 well. In addition, PCEPS implementations MUST support 202 negotiation of the mandatory-to-implement ciphersuites 203 required by the versions of TLS that they support. 205 2. Peer authentication can be performed in any of the following two 206 REQUIRED operation models: 208 * TLS with X.509 certificates using PKIX trust models: 210 + Implementations MUST allow the configuration of a list of 211 trusted Certification Authorities (CAs) for incoming 212 connections. 214 + Certificate validation MUST include the verification rules 215 as per [RFC5280]. 217 + Implementations SHOULD indicate their trusted CAs. For TLS 218 1.2, this is done using [RFC5246], Section 7.4.4, 219 "certificate_authorities" (server side) and [RFC6066], 220 Section 6 "Trusted CA Indication" (client side). 222 + Peer validation always SHOULD include a check on whether 223 the locally configured expected DNS name or IP address of 224 the peer that is contacted matches its presented 225 certificate. DNS names and IP addresses can be contained 226 in the Common Name (CN) or subjectAltName entries. For 227 verification, only one of these entries is to be 228 considered. The following precedence applies: for DNS name 229 validation, subjectAltName:DNS has precedence over CN; for 230 IP address validation, subjectAltName:iPAddr has precedence 231 over CN. 233 + Implementations MAY allow the configuration of a set of 234 additional properties of the certificate to check for a 235 peer's authorization to communicate (e.g., a set of allowed 236 values in subjectAltName:URI or a set of allowed X509v3 237 Certificate Policies) 239 * TLS with X.509 certificates using certificate fingerprints: 240 Implementations MUST allow the configuration of a list of 241 trusted certificates, identified via fingerprint of the 242 Distinguished Encoding Rules (DER) encoded certificate octets. 243 Implementations MUST support SHA-256 as the hash algorithm for 244 the fingerprint. 246 3. Start exchanging PCEP messages. 248 To support TLS re-negotiation both peers MUST support the mechanism 249 described in [RFC5746]. Any attempt of initiate a TLS handshake to 250 establish new cryptographic parameters not aligned with [RFC5746] 251 SHALL be considered a TLS negotiation failure. 253 3.4. Peer Identity 255 Depending on the peer authentication method in use, PCEPS supports 256 different operation modes to establish peer's identity and whether it 257 is entitled to perform requests or can be considered authoritative in 258 its replies. PCEPS implementations SHOULD provide mechanisms for 259 associating peer identities with different levels of access and/or 260 authoritativeness, and they MUST provide a mechanism for establish a 261 default level for properly identified peers. Any connection 262 established with a peer that cannot be properly identified SHALL be 263 terminated before any PCEP exchange takes place. 265 In TLS-X.509 mode using fingerprints, a peer is uniquely identified 266 by the fingerprint of the presented client certificate. 268 There are numerous trust models in Public-Key Infrastructure (PKI) 269 environments, and it is beyond the scope of this document to define 270 how a particular deployment determines whether a client is 271 trustworthy. Implementations that want to support a wide variety of 272 trust models should expose as many details of the presented 273 certificate to the administrator as possible so that the trust model 274 can be implemented by the administrator. As a suggestion, at least 275 the following parameters of the X.509 client certificate should be 276 exposed: 278 o Peer's IP address 280 o Peer's fully qualified domain name (FQDN) 282 o Certificate Fingerprint 284 o Issuer 286 o Subject 288 o All X509v3 Extended Key Usage 290 o All X509v3 Subject Alternative Name 292 o All X509v3 Certificate Policies 294 In addition, a PCC MAY apply the procedures described in [RFC6698] 295 (DANE) to verify its peer identity when using DNS discovery. See 296 section Section 4.1 for further details. 298 3.5. Connection Establishment Failure 300 In case the initial TLS negotiation or the peer identity check fail 301 according to the procedures listed in this document, the peer MUST 302 immediately terminate the session. It SHOULD follow the procedure 303 listed in [RFC5440] to retry session setup along with an exponential 304 back-off session establishment retry procedure. 306 4. Discovery Mechanisms 308 A PCE can advertise its capability to support PCEPS using the IGP 309 advertisement and discovery mechanism. The PCE-CAP-FLAGS sub-TLV is 310 an optional sub-TLV used to advertise PCE capabilities. It MAY be 311 present within the PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] 312 and [RFC5089] provide the description and processing rules for this 313 sub-TLV when carried within OSPF and IS-IS, respectively. PCE 314 capability bits are defined in [RFC5088]. A new capability flag bit 315 for the PCE-CAP-FLAGS sub-TLV that can be announced as attribute to 316 distribute PCEP security support information is proposed in 317 [I-D.wu-pce-discovery-pceps-support] 319 When DNS is used by a PCC (or a PCE acting as a client, for the rest 320 of the section, PCC refers to both) willing to use PCEPS to locate an 321 appropriate PCE [I-D.wu-pce-dns-pce-discovery], the PCC as initiating 322 entity chooses at least one of the returned FQDNs to resolve, which 323 it does by performing DNS "A" or "AAAA" lookups on the FDQN. This 324 will eventually result in an IPv4 or IPv6 address. The PCC SHALL use 325 the IP address(es) from the successfully resolved FDQN (with the 326 corresponding port number returned by the DNS SRV lookup) as the 327 connection address(es) for the receiving entity. 329 If the PCC fails to connect using an IP address but the "A" or "AAAA" 330 lookups returned more than one IP address, then the PCC SHOULD use 331 the next resolved IP address for that FDQN as the connection address. 332 If the PCC fails to connect using all resolved IP addresses for a 333 given FDQN, then it SHOULD repeat the process of resolution and 334 connection for the next FQDN returned by the SRV lookup based on the 335 priority and weight. 337 If the PCC receives a response to its SRV query but it is not able to 338 establish a PCEPS connection using the data received in the response, 339 as initiating entity it MAY fall back to lookup a PCE that uses TCP 340 as transport. 342 4.1. DANE Applicability 344 DANE [RFC6698] defines a secure method to associate the certificate 345 that is obtained from a TLS server with a domain name using DNS, 346 i.e., using the TLSA DNS resource record (RR) to associate a TLS 347 server certificate or public key with the domain name where the 348 record is found, thus forming a "TLSA certificate association". The 349 DNS information needs to be protected by DNSSEC. A PCC willing to 350 apply DANE to verify server identity MUST conform to the rules 351 defined in section 4 of [RFC6698]. 353 5. Backward Compatibility 355 The procedures described in this document define a security container 356 for the transport of PCEP requests and replies carried by a TLS 357 connection initiated by means of a specific extended message 358 (StartTLS) that does not interfere with PCEP speaker implementations 359 not supporting it. 361 6. IANA Considerations 363 NOTE: The StartTLS message is defined 365 7. Security Considerations 367 While the application of TLS satisfies the requirement on privacy as 368 well as fine-grained, policy-based peer authentication, there are 369 security threats that it cannot address. It is advisable to apply 370 additional protection measures, in particular in what relates to 371 attacks specifically addressed to forging the TCP connection 372 underpinning TLS. TCP-AO (TCP Authentication Option [RFC5925]) is 373 fully compatible with and deemed as complementary to TLS, so its 374 usage is to be considered as a security enhancement whenever any of 375 the PCEPS peers require it, especially in the case of long-lived 376 connections. The mechanisms to configure the requirements to use 377 TCP-AO and other lower-layer protection measures, as well as the 378 association of the required crypto material (MKT in the case of 379 TCP-AO) with a particular peer are outside the scope of this 380 document. [I-D.chunduri-karp-using-ikev2-with-tcp-ao] defines a 381 method to perform such association. 383 Since computational resources required by TLS handshake and 384 ciphersuite are higher than unencrypted TCP, clients connecting to a 385 PCEPS server can more easily create high load conditions and a 386 malicious client might create a Denial-of-Service attack more easily. 388 Some TLS ciphersuites only provide integrity validation of their 389 payload, and provide no encryption. This specification does not 390 forbid the use of such ciphersuites, but administrators must weight 391 carefully the risk of relevant internal data leakage that can occur 392 in such a case, as explicitly stated by [RFC6952]. 394 When using certificate fingerprints to identify PCEPS peers, any two 395 certificates that produce the same hash value will be considered the 396 same peer. Therefore, it is important to make sure that the hash 397 function used is cryptographically uncompromised so that attackers 398 are very unlikely to be able to produce a hash collision with a 399 certificate of their choice. This document mandates support for SHA- 400 256, but a later revision may demand support for stronger functions 401 if suitable attacks on it are known. 403 8. Acknowledgements 405 This specification relies on the analysis and profiling of TLS 406 included in [RFC6614] and the procedures described for the STARTTLS 407 command in [RFC2830]. 409 We would like to thank Joe Touch for his suggestions and support 410 regarding the TLS start mechanisms. 412 9. References 414 9.1. Normative References 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, March 1997. 419 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 420 "OSPF Protocol Extensions for Path Computation Element 421 (PCE) Discovery", RFC 5088, January 2008. 423 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 424 "IS-IS Protocol Extensions for Path Computation Element 425 (PCE) Discovery", RFC 5089, January 2008. 427 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 428 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 430 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 431 Housley, R., and W. Polk, "Internet X.509 Public Key 432 Infrastructure Certificate and Certificate Revocation List 433 (CRL) Profile", RFC 5280, May 2008. 435 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 436 (PCE) Communication Protocol (PCEP)", RFC 5440, 437 March 2009. 439 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 440 "Transport Layer Security (TLS) Renegotiation Indication 441 Extension", RFC 5746, February 2010. 443 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 444 Authentication Option", RFC 5925, June 2010. 446 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 447 Extension Definitions", RFC 6066, January 2011. 449 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 450 of Named Entities (DANE) Transport Layer Security (TLS) 451 Protocol: TLSA", RFC 6698, August 2012. 453 9.2. Informative References 455 [I-D.chunduri-karp-using-ikev2-with-tcp-ao] 456 Chunduri, U., Tian, A., and J. Touch, "A framework for RPs 457 to use IKEv2 KMP", 458 draft-chunduri-karp-using-ikev2-with-tcp-ao-06 (work in 459 progress), February 2014. 461 [I-D.wu-pce-discovery-pceps-support] 462 Lopez, D., Wu, Q., Dhody, D., and D. King, "IGP extension 463 for PCEP security capability support in the PCE 464 discovery", draft-wu-pce-discovery-pceps-support-01 (work 465 in progress), August 2014. 467 [I-D.wu-pce-dns-pce-discovery] 468 Wu, W., Dhody, D., King, D., Lopez, D., and J. Tantsura, 469 "Path Computation Element (PCE) Discovery using Domain 470 Name System(DNS)", draft-wu-pce-dns-pce-discovery-06 (work 471 in progress), May 2014. 473 [RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight 474 Directory Access Protocol (v3): Extension for Transport 475 Layer Security", RFC 2830, May 2000. 477 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 478 "Transport Layer Security (TLS) Encryption for RADIUS", 479 RFC 6614, May 2012. 481 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 482 BGP, LDP, PCEP, and MSDP Issues According to the Keying 483 and Authentication for Routing Protocols (KARP) Design 484 Guide", RFC 6952, May 2013. 486 Authors' Addresses 488 Diego R. Lopez 489 Telefonica I+D 490 Don Ramon de la Cruz, 82 491 Madrid, 28006 492 Spain 494 Phone: +34 913 129 041 495 Email: diego.r.lopez@telefonica.com 496 Oscar Gonzalez de Dios 497 Telefonica I+D 498 Don Ramon de la Cruz, 82 499 Madrid, 28006 500 Spain 502 Phone: +34 913 129 041 503 Email: oscar.gonzalezdedios@telefonica.com 505 Qin Wu 506 Huawei 507 101 Software Avenue, Yuhua District 508 Nanjing, Jiangsu 210012 509 China 511 Email: sunseawq@huawei.com 513 Dhruv Dhody 514 Huawei 515 Leela Palace 516 Bangalore, KA 560008 517 India 519 Email: dhruv.ietf@gmail.com