idnits 2.17.1 draft-ietf-pce-pceps-00.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 (March 10, 2014) is 3671 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-00 == Outdated reference: A later version (-10) exists of draft-wu-pce-dns-pce-discovery-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: September 11, 2014 Q. Wu 6 D. Dhody 7 Huawei 8 March 10, 2014 10 Secure Transport for PCEP 11 draft-ietf-pce-pceps-00 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 September 11, 2014. 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. TCP ports . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. TLS Connection Establishment . . . . . . . . . . . . . . . 4 63 3.3. Peer Identity . . . . . . . . . . . . . . . . . . . . . . 6 64 3.4. Connection Establishment Failure . . . . . . . . . . . . . 7 65 4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. DANE Applicability . . . . . . . . . . . . . . . . . . . . 8 67 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 PCEP [RFC5440] defines the mechanisms for the communication between a 79 Path Computation Client (PCC) and a Path Computation Element (PCE), 80 or between two PCEs. These interactions include requests and replies 81 that can be critical for a sustainable network operation and adequate 82 resource allocation, and therefore appropriate security becomes a key 83 element in the PCE infrastructure. As the applications of the PCE 84 framework evolves, and more complex service patterns emerge, the 85 definition of a secure mode of operation becomes more relevant. 87 [RFC5440] analyzes in its section on security considerations the 88 potential threats to PCEP and their consequences, and discusses 89 several mechanisms for protecting PCEP against security attacks, 90 without making a specific recommendation on a particular one or 91 defining their application in depth. Moreover, [RFC6952] remarks the 92 importance of ensuring PCEP communication privacy, especially when 93 PCEP communication endpoints do not reside in the same AS, as the 94 interception of PCEP messages could leak sensitive information 95 related to computed paths and resources. 97 Among the possible solutions mentioned in these documents, Transport 98 Layer Security (TLS) [RFC5246] provides support for peer 99 authentication, and message encryption and integrity. TLS supports 100 the usage of well-know mechanisms to support key configuration and 101 exchange, and means to perform security checks on the results of PCE 102 discovery procedures via IGP ([RFC5088] and [RFC5089]). 104 This document describes a security container for the transport of 105 PCEP requests and replies, and therefore it will not interfere with 106 the protocol flexibility and extensibility. 108 This document describes how to apply TLS in securing PCE 109 interactions, including the TLS handshake mechanisms, the TLS methods 110 for peer authentication, the applicable TLS ciphersuites for data 111 exchange, and the handling of errors in the security checks. In the 112 rest of the document we will refer to this usage of TLS to provide a 113 secure transport for PCEP as "PCEPS". 115 2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Applying PCEPS 123 3.1. TCP ports 125 Since PCEP can operate either with or without TLS, it is necessary 126 for the PCEP speaker to indicate whether it wants to set up a TLS 127 connection or not. There are two main ways of achieving this: 129 o One option is to use a different port number for TLS connections 130 (for example, the port 443 used for HTTPS) 132 o The other is to use the regular port number and have the PCEP 133 speaker request that the PCE switch the connection to TLS using a 134 protocol-specific mechanism (for example, the STARTTLS for mail 135 and news protocols) 137 To avoid requiring a specific PCEP extension to request TLS, this 138 document proposes the usage of the former solution to implement 139 PCEPS. 141 The default destination port number for PCEPS is TCP/XXXX. 143 NOTE: This port has to be agreed and registered as PCEPS with IANA. 145 3.2. TLS Connection Establishment 147 PCEPS has no notion of negotiating TLS in an established connection. 148 PCEP peers MAY either discover that the other PCEP endpoint supports 149 PCEPS or can be preconfigured to use PCEPS for a given peer (see 150 section Section 4 for more details). The connection establishment 151 SHALL follow the following steps: 153 1. After completing the TCP handshake, immediately negotiate TLS 154 sessions according to [RFC5246]. The following restrictions 155 apply: 157 * Support for TLS v1.2 [RFC5246] or later is REQUIRED. 159 * Support for certificate-based mutual authentication is 160 REQUIRED. 162 * Negotiation of mutual authentication is REQUIRED. 164 * Negotiation of a ciphersuite providing for integrity 165 protection is REQUIRED. 167 * Negotiation of a ciphersuite providing for confidentiality is 168 RECOMMENDED. 170 * Support for and negotiation of compression is OPTIONAL. 172 * PCEPS implementations MUST, at a minimum, support negotiation 173 of the TLS_RSA_WITH_3DES_EDE_CBC_SHA, and SHOULD support 174 TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as 175 well. In addition, PCEPS implementations MUST support 176 negotiation of the mandatory-to-implement ciphersuites 177 required by the versions of TLS that they support. 179 2. Peer authentication can be performed in any of the following two 180 REQUIRED operation models: 182 * TLS with X.509 certificates using PKIX trust models: 184 + Implementations MUST allow the configuration of a list of 185 trusted Certification Authorities (CAs) for incoming 186 connections. 188 + Certificate validation MUST include the verification rules 189 as per [RFC5280]. 191 + Implementations SHOULD indicate their trusted CAs. For TLS 192 1.2, this is done using [RFC5246], Section 7.4.4, 193 "certificate_authorities" (server side) and [RFC6066], 194 Section 6 "Trusted CA Indication" (client side). 196 + Peer validation always SHOULD include a check on whether 197 the locally configured expected DNS name or IP address of 198 the peer that is contacted matches its presented 199 certificate. DNS names and IP addresses can be contained 200 in the Common Name (CN) or subjectAltName entries. For 201 verification, only one of these entries is to be 202 considered. The following precedence applies: for DNS name 203 validation, subjectAltName:DNS has precedence over CN; for 204 IP address validation, subjectAltName:iPAddr has precedence 205 over CN. 207 + NOTE: Consider here whether peer validation MAY be extended 208 by means of the DANE procedures, including its specs as 209 informative references. 211 + Implementations MAY allow the configuration of a set of 212 additional properties of the certificate to check for a 213 peer's authorization to communicate (e.g., a set of allowed 214 values in subjectAltName:URI or a set of allowed X509v3 215 Certificate Policies) 217 * TLS with X.509 certificates using certificate fingerprints: 218 Implementations MUST allow the configuration of a list of 219 trusted certificates, identified via fingerprint of the 220 Distinguished Encoding Rules (DER) encoded certificate octets. 221 Implementations MUST support SHA-256 as the hash algorithm for 222 the fingerprint. 224 3. Start exchanging PCEP messages. 226 To support TLS re-negotiation both peers MUST support the mechanism 227 described in [RFC5746]. Any attempt of initiate a TLS handshake to 228 establish new cryptographic parameters not aligned with [RFC5746] 229 SHALL be considered a TLS negotiation failure. 231 3.3. Peer Identity 233 Depending on the peer authentication method in use, PCEPS supports 234 different operation modes to establish peer's identity and whether it 235 is entitled to perform requests or can be considered authoritative in 236 its replies. PCEPS implementations SHOULD provide mechanisms for 237 associating peer identities with different levels of access and/or 238 authoritativeness, and they MUST provide a mechanism for establish a 239 default level for properly identified peers. Any connection 240 established with a peer that cannot be properly identified SHALL be 241 terminated before any PCEP exchange takes place. 243 In TLS-X.509 mode using fingerprints, a peer is uniquely identified 244 by the fingerprint of the presented client certificate. 246 There are numerous trust models in Public-Key Infrastructure (PKI) 247 environments, and it is beyond the scope of this document to define 248 how a particular deployment determines whether a client is 249 trustworthy. Implementations that want to support a wide variety of 250 trust models should expose as many details of the presented 251 certificate to the administrator as possible so that the trust model 252 can be implemented by the administrator. As a suggestion, at least 253 the following parameters of the X.509 client certificate should be 254 exposed: 256 o Peer's IP address 258 o Peer's fully qualified domain name (FQDN) 260 o Certificate Fingerprint 262 o Issuer 263 o Subject 265 o All X509v3 Extended Key Usage 267 o All X509v3 Subject Alternative Name 269 o All X509v3 Certificate Policies 271 In addition, a PCC MAY apply the procedures described in [RFC6698] 272 (DANE) to verify its peer identity when using DNS discovery. See 273 section Section 4.1 for further details. 275 3.4. Connection Establishment Failure 277 In case the initial TLS negotiation or the peer identity check fail 278 according to the procedures listed in this document, the peer MUST 279 immediately terminate the session. It SHOULD follow the procedure 280 listed in [RFC5440] to retry session setup along with an exponential 281 back-off session establishment retry procedure. 283 4. Discovery Mechanisms 285 A PCE can advertise its capability to support PCEPS using the IGP 286 advertisement and discovery mechanism. The PCE-CAP-FLAGS sub-TLV is 287 an optional sub-TLV used to advertise PCE capabilities. It MAY be 288 present within the PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] 289 and [RFC5089] provide the description and processing rules for this 290 sub-TLV when carried within OSPF and IS-IS, respectively. PCE 291 capability bits are defined in [RFC5088]. A new capability flag bit 292 for the PCE-CAP-FLAGS sub-TLV that can be announced as attribute to 293 distribute PCEP security support information is proposed in 294 [I-D.wu-pce-discovery-pceps-support] 296 NOTE: A new bit must be added here to advertise the PCEPS capability. 298 When DNS is used by a PCC (or a PCE acting as a client, for the rest 299 of the section, PCC refers to both) willing to use PCEPS to locate an 300 appropriate PCE [I-D.wu-pce-dns-pce-discovery], the PCC as initiating 301 entity chooses at least one of the returned FQDNs to resolve, which 302 it does by performing DNS "A" or "AAAA" lookups on the FDQN. This 303 will eventually result in an IPv4 or IPv6 address. The PCC SHALL use 304 the IP address(es) from the successfully resolved FDQN (with the 305 corresponding port number returned by the DNS SRV lookup) as the 306 connection address(es) for the receiving entity. 308 If the PCC fails to connect using an IP address but the "A" or "AAAA" 309 lookups returned more than one IP address, then the PCC SHOULD use 310 the next resolved IP address for that FDQN as the connection address. 311 If the PCC fails to connect using all resolved IP addresses for a 312 given FDQN, then it SHOULD repeat the process of resolution and 313 connection for the next FQDN returned by the SRV lookup based on the 314 priority and weight. 316 If the PCC receives a response to its SRV query but it is not able to 317 establish a PCEPS connection using the data received in the response, 318 as initiating entity it MAY fall back to lookup a PCE that uses TCP 319 as transport. 321 4.1. DANE Applicability 323 DANE [RFC6698] defines a secure method to associate the certificate 324 that is obtained from a TLS server with a domain name using DNS, 325 i.e., using the TLSA DNS resource record (RR) to associate a TLS 326 server certificate or public key with the domain name where the 327 record is found, thus forming a "TLSA certificate association". The 328 DNS information needs to be protected by DNSSEC. A PCC willing to 329 apply DANE to verify server identity MUST conform to the rules 330 defined in section 4 of [RFC6698]. 332 5. Backward Compatibility 334 Since the procedure described in this document describes a security 335 container for the transport of PCEP requests and replies carried on a 336 newly allocated TCP port there will be no impact on the base PCEP 337 and/or any further extensions. 339 6. IANA Considerations 341 NOTE: PCEPS has to be registered as TCP port XXXX. 343 No new PCEP messages or other objects are defined. 345 7. Security Considerations 347 While the application of TLS satisfies the requirement on privacy as 348 well as fine-grained, policy-based peer authentication, there are 349 security threats that it cannot address. It is advisable to apply 350 additional protection measures, in particular in what relates to 351 attacks specifically addressed to forging the TCP connection 352 underpinning TLS. TCP-AO (TCP Authentication Option [RFC5925]) is 353 fully compatible with and deemed as complementary to TLS, so its 354 usage is to be considered as a security enhancement whenever any of 355 the PCEPS peers require it, especially in the case of long-lived 356 connections. The mechanisms to configure the requirements to use 357 TCP-AO and other lower-layer protection measures, as well as the 358 association of the required crypto material (MKT in the case of 359 TCP-AO) with a particular peer are outside the scope of this 360 document. [I-D.chunduri-karp-using-ikev2-with-tcp-ao] defines a 361 method to perform such association. 363 Since computational resources required by TLS handshake and 364 ciphersuite are higher than unencrypted TCP, clients connecting to a 365 PCEPS server can more easily create high load conditions and a 366 malicious client might create a Denial-of-Service attack more easily. 368 Some TLS ciphersuites only provide integrity validation of their 369 payload, and provide no encryption. This specification does not 370 forbid the use of such ciphersuites, but administrators must weight 371 carefully the risk of relevant internal data leakage that can occur 372 in such a case, as explicitly stated by [RFC6952]. 374 When using certificate fingerprints to identify PCEPS peers, any two 375 certificates that produce the same hash value will be considered the 376 same peer. Therefore, it is important to make sure that the hash 377 function used is cryptographically uncompromised so that attackers 378 are very unlikely to be able to produce a hash collision with a 379 certificate of their choice. This document mandates support for SHA- 380 256, but a later revision may demand support for stronger functions 381 if suitable attacks on it are known. 383 8. Acknowledgements 385 This specification relies on the analysis and profiling of TLS 386 included in [RFC6614]. 388 9. References 390 9.1. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 396 "OSPF Protocol Extensions for Path Computation Element 397 (PCE) Discovery", RFC 5088, January 2008. 399 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 400 "IS-IS Protocol Extensions for Path Computation Element 401 (PCE) Discovery", RFC 5089, January 2008. 403 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 404 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 406 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 407 Housley, R., and W. Polk, "Internet X.509 Public Key 408 Infrastructure Certificate and Certificate Revocation List 409 (CRL) Profile", RFC 5280, May 2008. 411 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 412 (PCE) Communication Protocol (PCEP)", RFC 5440, 413 March 2009. 415 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 416 "Transport Layer Security (TLS) Renegotiation Indication 417 Extension", RFC 5746, February 2010. 419 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 420 Authentication Option", RFC 5925, June 2010. 422 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 423 Extension Definitions", RFC 6066, January 2011. 425 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 426 of Named Entities (DANE) Transport Layer Security (TLS) 427 Protocol: TLSA", RFC 6698, August 2012. 429 9.2. Informative References 431 [I-D.chunduri-karp-using-ikev2-with-tcp-ao] 432 Chunduri, U., Tian, A., and J. Touch, "A framework for RPs 433 to use IKEv2 KMP", 434 draft-chunduri-karp-using-ikev2-with-tcp-ao-06 (work in 435 progress), February 2014. 437 [I-D.wu-pce-discovery-pceps-support] 438 Lopez, D., Wu, Q., Dhody, D., and D. King, "IGP extension 439 for PCEP security capability support in the PCE 440 discovery", draft-wu-pce-discovery-pceps-support-00 (work 441 in progress), February 2014. 443 [I-D.wu-pce-dns-pce-discovery] 444 Wu, W., Dhody, D., King, D., Lopez, D., and J. Tantsura, 445 "Path Computation Element (PCE) Discovery using Domain 446 Name System(DNS)", draft-wu-pce-dns-pce-discovery-05 (work 447 in progress), March 2014. 449 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 450 "Transport Layer Security (TLS) Encryption for RADIUS", 451 RFC 6614, May 2012. 453 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 454 BGP, LDP, PCEP, and MSDP Issues According to the Keying 455 and Authentication for Routing Protocols (KARP) Design 456 Guide", RFC 6952, May 2013. 458 Authors' Addresses 460 Diego R. Lopez 461 Telefonica I+D 462 Don Ramon de la Cruz, 82 463 Madrid, 28006 464 Spain 466 Phone: +34 913 129 041 467 Email: diego@tid.es 469 Oscar Gonzalez de Dios 470 Telefonica I+D 471 Don Ramon de la Cruz, 82 472 Madrid, 28006 473 Spain 475 Phone: +34 913 129 041 476 Email: ogondio@tid.es 478 Qin Wu 479 Huawei 480 101 Software Avenue, Yuhua District 481 Nanjing, Jiangsu 210012 482 China 484 Email: sunseawq@huawei.com 485 Dhruv Dhody 486 Huawei 487 Leela Palace 488 Bangalore, KA 560008 489 India 491 Email: dhruv.ietf@gmail.com