idnits 2.17.1 draft-ietf-lsr-pce-discovery-security-support-04.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 RFC5088, updated by this document, for RFC5378 checks: 2006-09-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2020) is 1276 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) == Unused Reference: 'RFC7981' is defined on line 345, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 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 Telefonica I+D 4 Updates: 5088,5089 (if approved) Q. Wu 5 Intended status: Standards Track D. Dhody 6 Expires: April 24, 2021 Q. Ma 7 Huawei 8 D. King 9 Old Dog Consulting 10 October 21, 2020 12 IGP extension for PCEP security capability support in the PCE discovery 13 draft-ietf-lsr-pce-discovery-security-support-04 15 Abstract 17 When a Path Computation Element (PCE) is a Label Switching Router 18 (LSR) participating in the Interior Gateway Protocol (IGP), or even a 19 server participating in IGP, its presence and path computation 20 capabilities can be advertised using IGP flooding. The IGP 21 extensions for PCE discovery (RFC 5088 and RFC 5089) define a method 22 to advertise path computation capabilities using IGP flooding for 23 OSPF and IS-IS respectively. However these specifications lack a 24 method to advertise PCEP security (e.g., Transport Layer 25 Security(TLS), TCP Authentication Option (TCP-AO)) support 26 capability. 28 This document proposes new capability flag bits for PCE-CAP-FLAGS 29 sub-TLV that can be announced as attribute in the IGP advertisement 30 to distribute PCEP security support information. In addition, this 31 document updates RFC 5088 and RFC 5089 to allow advertisement of Key 32 ID or Key Chain Name Sub-TLV to support TCP AO security capability. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 24, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 1. Introduction 67 As described in [RFC5440], PCEP communication privacy is one 68 importance issue, as an attacker that intercepts a Path Computation 69 Element (PCE) message could obtain sensitive information related to 70 computed paths and resources. 72 Among the possible solutions mentioned in these documents, Transport 73 Layer Security (TLS) [RFC8446] provides support for peer 74 authentication, and message encryption and integrity while TCP 75 Authentication Option (TCP-AO) [RFC5925] and Cryptographic Algorithms 76 for TCP-AO [RFC5926] offer significantly improved security for 77 applications using TCP. As specified in section 4 of [RFC8253], in 78 order for a Path Computation Client (PCC) to begin a connection with 79 a PCE server using TLS or TCP-AO, PCC needs to know whether PCE 80 server supports TLS or TCP-AO as a secure transport. 82 [RFC5088] and [RFC5089] define a method to advertise path computation 83 capabilities using IGP flooding for OSPF and IS-IS respectively. 84 However these specifications lack a method to advertise PCEP security 85 (e.g., TLS) support capability. 87 This document proposes new capability flag bits for PCE-CAP-FLAGS 88 sub-TLV that can be announced as attributes in the IGP advertisement 89 to distribute PCEP security support information. In addition, this 90 document updates RFC5088 and RFC5089 to allow advertisement of Key ID 91 or Key Chain Name Sub-TLV to support TCP AO security capability. 93 Note that the PCEP Open message exchange is another way to discover 94 PCE capabilities information, but in this instance, the TCP security 95 related key parameters need to be known before the PCEP session is 96 established and the PCEP Open messages are exchanged, thus the use of 97 the PCE discovery and capabilities advertisement in the IGP needs to 98 be used. 100 2. Conventions used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 3. IGP extension for PCEP security capability support 110 [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF 111 Router Information Link State Advertisement (LSA) as defined in 112 [RFC7770] to facilitate PCE discovery using OSPF. This document 113 defines two new capability flag bits in the OSPF PCE Capability Flags 114 to indicate TCP Authentication Option (TCP-AO) support 115 [RFC5925][RFC5926], PCEP over TLS support [RFC8253] respectively. 117 Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE 118 discovery using IS-IS. This document will use the same flag for the 119 OSPF PCE Capability Flags sub-TLV to allow IS-IS to indicate TCP 120 Authentication Option (TCP-AO) support, PCEP over TLS support 121 respectively. 123 The IANA assignments for shared OSPF and IS-IS Security Capability 124 Flags are documented in Section 8.1 ("OSPF PCE Capability Flag") of 125 this document. 127 3.1. Use of PCEP security capability support for PCE discovery 129 TCP-AO, PCEP over TLS support flag bits are advertised using IGP 130 flooding. 132 o PCE supports TCP-AO: IGP advertisement SHOULD include TCP-AO 133 support flag bit. 135 o PCE supports TLS: IGP advertisement SHOULD include PCEP over TLS 136 support flag bit. 138 If PCE supports multiple security mechanisms, it SHOULD include all 139 corresponding flag bits in IGP advertisement. 141 If the client is looking for connecting with PCE server with TCP-AO 142 support, the client MUST check if TCP-AO support flag bit in the PCE- 143 CAP-FLAGS sub-TLV is set. If not, the client SHOULD NOT consider 144 this PCE. If the client is looking for connecting with PCE server 145 using TLS, the client MUST check if PCEP over TLS support flag bit in 146 the PCE-CAP-FLAGS sub-TLV is set. If not, the client SHOULD NOT 147 consider this PCE. Note that this can be overridden based on a local 148 policy at the PCC. 150 3.2. KEY-ID Sub-TLV 152 The KEY-ID sub-TLV specifies a key that can be used by the PCC to 153 identify the TCP-AO key [RFC5925]. 155 The KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried within 156 the IS-IS Router Information Capability TLV when the capability flag 157 bit of PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP 158 Authentication Option (TCP-AO) support. Similarly, this sub-TLV MAY 159 be present in the PCED TLV carried within OSPF Router Information LSA 160 when the capability flag bit of PCE-CAP-FLAGS sub-TLV in OSPF is set 161 to indicate TCP-AO support. 163 The format of the KEY-ID sub-TLV is as follows: 165 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 167 | Type = 6 | Length = 4 | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | KeyID | Reserved | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 KEY-ID sub-TLV format 173 Type: 6 175 Length: 4 177 KeyID: The one octed Key ID as per [RFC5925] to uniquely identify the 178 Master Key Tuple (MKT). 180 Reserved: MUST be set to zero while sending and ignored on receipt. 182 3.3. KEY-CHAIN-NAME Sub-TLV 184 The KEY-CHAIN-NAME sub-TLV specifies a keychain name that can be used 185 by the PCC to identify the keychain [RFC8177]. 187 The KEY-CHAIN-NAME sub-TLV MAY be present in the PCED sub-TLV carried 188 within the IS-IS Router Information Capability TLV when the 189 capability flag bit of PCE-CAP-FLAGS sub-TLV in IS-IS is set to 190 indicate TCP Authentication Option (TCP-AO) support. Similarly, this 191 sub-TLV MAY be present in the PCED TLV carried within OSPF Router 192 Information LSA when the capability flag bit of PCE-CAP-FLAGS sub-TLV 193 in OSPF is set to indicate TCP-AO support. 195 The format of the KEY-CHAIN-NAME sub-TLV is as follows: 197 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 199 | Type = 7 | Length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | | 202 // Key Chain Name // 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 KEY-CHAIN-NAME sub-TLV format 207 Type: 7 209 Length: Variable 211 Key Name: The Key Chain Name contains a string to be used to identify 212 the key chain. It SHOULD be a string of printable ASCII characters, 213 without a NULL terminator. The TLV MUST be zero-padded so that the 214 TLV is 4-octet aligned. 216 4. Update to RFC5088 and RFC5089 218 Section 4 of [RFC5088] states that no new sub-TLVs will be added to 219 the PCED TLV, and no new PCE information will be carried in the 220 Router Information LSA. This document updates [RFC5088] by allowing 221 the two new sub-TLVs defined in this document to be carried in the 222 PCED TLV of the for use in the Router Information LSA. 224 Section 4 of [RFC5089] states that no new sub-TLVs will be added to 225 the PCED TLV, and no new PCE information will be carried in the 226 Router CAPABLITY TLV. This document updates [RFC5089] by allowing 227 the two new sub-TLVs defined in this document to be carried in the 228 PCED TLV of the for use in the Router CAPABILITY TLV. 230 The introduction of the additional sub-TLVs should be viewed as an 231 exception to the [RFC5088][RFC5089] policy justified by the need to 232 know the new information prior to establishing a PCEP session. The 233 restrictions defined in [RFC5089][RFC5089] should still be considered 234 to be in place. 236 5. Backward Compatibility Consideration 238 An LSR that does not support the new IGP PCE capability bits 239 specified in this document silently ignores those bits. 241 An LSR that does not support the new KEYNAME sub-TLV specified in 242 this document silently ignores the sub-TLV. 244 IGP extensions defined in this document do not introduce any new 245 interoperability issues. 247 6. Management Considerations 249 A configuration option may be provided for advertising and 250 withdrawing PCE security capability via IGP. 252 7. Security Considerations 254 Security considerations as specified by [RFC5088] and [RFC5089] are 255 applicable to this document. 257 The information related to PCEP security is sensitive and due care 258 needs to be taken by the operator. This document defines new 259 capability bits that are susceptible to downgrade attack by toggling 260 them. The content of Key ID or Key Chain Name Sub-TLV can be tweaked 261 to enable a man-in-the-middle attack. Thus before advertisement of 262 the PCE security parameters, it MUST be insured that the IGP is 263 protected for authentication and integrity of the PCED TLV if the 264 mechanism described in this document is used. As stated in [RFC5088] 265 and [RFC5089], the IGP do not provide encryption mechanism to protect 266 the privacy of the PCED TLV, if this information can make the PCEP 267 session less secure then the operator should take that into 268 consideration. 270 8. IANA Considerations 272 8.1. OSPF PCE Capability Flag 274 IANA is requested to allocate new bits assignments for the OSPF 275 Parameters "Path Computation Element (PCE) Capability Flags" 276 registry. 278 Bit Meaning Reference 279 xx TCP-AO Support [This.I.D] 280 xx PCEP over TLS support [This.I.D] 282 The registry is located at: https://www.iana.org/assignments/ospfv2- 283 parameters/ospfv2-parameters.xml#ospfv2-parameters-14.xml 285 8.2. PCED sub-TLV Type Indicators 287 The PCED sub-TLVs were defined in [RFC5088] and [RFC5089], but they 288 did not create a registry for it. This document requests IANA to 289 create a new top-level OSPF registry, the "PCED sub-TLV type 290 indicators" registry. This registry should be populated with - 292 Value Description Reference 293 0 Reserved [This.I.D][RFC5088] 294 1 PCE-ADDRESS [This.I.D][RFC5088] 295 2 PATH-SCOPE [This.I.D][RFC5088] 296 3 PCE-DOMAIN [This.I.D][RFC5088] 297 4 NEIG-PCE-DOMAIN [This.I.D][RFC5088] 298 6 KEY-ID [This.I.D] 299 7 KEY-CHAIN-NAME [This.I.D] 301 This registry is also used by IS-IS PCED sub-TLV. 303 9. Acknowledgments 305 The authors of this document would also like to thank Acee Lindem, 306 Julien Meuric, Les Ginsberg, Aijun Wang, Adrian Farrel for the review 307 and comments. 309 The authors would also like to speical thank Michale Wang for his 310 major contributions to the initial version. 312 10. References 314 10.1. Normative References 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, 318 DOI 10.17487/RFC2119, March 1997, 319 . 321 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 322 Zhang, "OSPF Protocol Extensions for Path Computation 323 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 324 January 2008, . 326 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 327 Zhang, "IS-IS Protocol Extensions for Path Computation 328 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 329 January 2008, . 331 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 332 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 333 June 2010, . 335 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 336 for the TCP Authentication Option (TCP-AO)", RFC 5926, 337 DOI 10.17487/RFC5926, June 2010, 338 . 340 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 341 S. Shaffer, "Extensions to OSPF for Advertising Optional 342 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 343 February 2016, . 345 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 346 for Advertising Router Information", RFC 7981, 347 DOI 10.17487/RFC7981, October 2016, 348 . 350 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 351 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 352 May 2017, . 354 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 355 Zhang, "YANG Data Model for Key Chains", RFC 8177, 356 DOI 10.17487/RFC8177, June 2017, 357 . 359 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 360 "PCEPS: Usage of TLS to Provide a Secure Transport for the 361 Path Computation Element Communication Protocol (PCEP)", 362 RFC 8253, DOI 10.17487/RFC8253, October 2017, 363 . 365 10.2. Informative References 367 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 368 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 369 DOI 10.17487/RFC5440, March 2009, 370 . 372 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 373 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 374 . 376 Appendix A. No MD5 Capability Support 378 To be compliant with Section 10.2 of RFC5440, this document doesn't 379 consider to add capability for TCP-MD5. Therefore by default, PCEP 380 Speaker in communication supports capability for TCP-MD5 (See section 381 10.2, [RFC5440]). A method to advertise TCP-MD5 Capability support 382 using IGP flooding is not required. If the client is looking for 383 connecting with PCE server with other Security capability support 384 (e.g., TLS support) than TCP-MD5, the client MUST check if flag bit 385 in the PCE- CAP-FLAGS sub-TLV for specific capability is set (See 386 section 3.1). 388 Authors' Addresses 390 Diego R. Lopez 391 Telefonica I+D 392 Spain 394 Email: diego.r.lopez@telefonica.com 396 Qin Wu 397 Huawei Technologies 398 101 Software Avenue, Yuhua District 399 Nanjing, Jiangsu 210012 400 China 402 Email: bill.wu@huawei.com 404 Dhruv Dhody 405 Huawei Technologies 406 Divyashree Techno Park, Whitefield 407 Bangalore, Karnataka 560037 408 India 410 Email: dhruv.ietf@gmail.com 412 Qiufang Ma 413 Huawei 414 101 Software Avenue, Yuhua District 415 Nanjing, Jiangsu 210012 416 China 418 Email: maqiufang1@huawei.com 419 Daniel King 420 Old Dog Consulting 421 UK 423 Email: daniel@olddog.co.uk