idnits 2.17.1 draft-wu-lsr-pce-discovery-security-support-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 (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 (November 28, 2018) is 1975 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: June 1, 2019 Z. Wang 7 Huawei 8 D. King 9 Old Dog Consulting 10 November 28, 2018 12 IGP extension for PCEP security capability support in the PCE discovery 13 draft-wu-lsr-pce-discovery-security-support-01 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 June 1, 2019. 50 Copyright Notice 52 Copyright (c) 2018 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 2. Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 3. IGP extension for PCEP security capability support 103 [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF 104 Router Information Link State Advertisement (LSA) as defined in 105 [RFC7770] to facilitate PCE discovery using OSPF. This document 106 defines two new capability flag bits in the OSPF PCE Capability Flags 107 to indicate TCP Authentication Option (TCP-AO) support 108 [RFC5925][RFC5926], PCEP over TLS support [RFC8253] respectively. 110 Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE 111 discovery using IS-IS. This document will use the same flag for the 112 OSPF PCE Capability Flags sub-TLV to allow IS-IS to indicate TCP 113 Authentication Option (TCP-AO) support, PCEP over TLS support 114 respectively. 116 The IANA assignments for shared OSPF and IS-IS Security Capability 117 Flags are documented in Section 8.1 ("OSPF PCE Capability Flag") of 118 this document. 120 3.1. Use of PCEP security capability support for PCE discovery 122 TCP-AO, PCEP over TLS support flag bits are advertised using IGP 123 flooding. 125 o PCE supports TCP-AO: IGP advertisement SHOULD include TCP-AO 126 support flag bit. 128 o PCE supports TLS: IGP advertisement SHOULD include PCEP over TLS 129 support flag bit. 131 If PCE supports multiple security mechanisms, it SHOULD include all 132 corresponding flag bits in IGP advertisement. 134 If the client is looking for connecting with PCE server with TCP-AO 135 support, the client MUST check if TCP-AO support flag bit in the PCE- 136 CAP-FLAGS sub-TLV is set. If not, the client SHOULD NOT consider 137 this PCE. If the client is looking for connecting with PCE server 138 using TLS, the client MUST check if PCEP over TLS support flag bit in 139 the PCE-CAP-FLAGS sub-TLV is set. If not, the client SHOULD NOT 140 consider this PCE. Note that this can be overridden based on a local 141 policy at the PCC. 143 3.2. KEY-ID Sub-TLV 145 The KEY-ID sub-TLV specifies a key that can be used by the PCC to 146 identify the TCP-AO key [RFC5925]. 148 The KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried within 149 the IS-IS Router Information Capability TLV when the capability flag 150 bit of PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP 151 Authentication Option (TCP-AO) support. Similarly, this sub-TLV MAY 152 be present in the PCED TLV carried within OSPF Router Information LSA 153 when the capability flag bit of PCE-CAP-FLAGS sub-TLV in OSPF is set 154 to indicate TCP-AO support. 156 The format of the KEY-ID sub-TLV is as follows: 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 160 | Type = 6 | Length = 4 | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | KeyID | Reserved | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 KEY-ID sub-TLV format 166 Type: 6 168 Length: 4 170 KeyID: The one octed Key ID as per [RFC5925] to uniquely identify the 171 Master Key Tuple (MKT). 173 Reserved: MUST be set to zero while sending and ignored on receipt. 175 3.3. KEY-CHAIN-NAME Sub-TLV 177 The KEY-CHAIN-NAME sub-TLV specifies a keychain name that can be used 178 by the PCC to identify the keychain [RFC8177]. 180 The KEY-CHAIN-NAME sub-TLV MAY be present in the PCED sub-TLV carried 181 within the IS-IS Router Information Capability TLV when the 182 capability flag bit of PCE-CAP-FLAGS sub-TLV in IS-IS is set to 183 indicate TCP Authentication Option (TCP-AO) support. Similarly, this 184 sub-TLV MAY be present in the PCED TLV carried within OSPF Router 185 Information LSA when the capability flag bit of PCE-CAP-FLAGS sub-TLV 186 in OSPF is set to indicate TCP-AO support. 188 The format of the KEY-CHAIN-NAME sub-TLV is as follows: 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 192 | Type = 7 | Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | | 195 // Key Chain Name // 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 KEY-CHAIN-NAME sub-TLV format 200 Type: 7 202 Length: Variable 204 Key Name: The Key Chain Name contains a string to be used to identify 205 the key chain. It SHOULD be a string of printable ASCII characters, 206 without a NULL terminator. The TLV MUST be zero-padded so that the 207 TLV is 4-octet aligned. 209 4. Update to RFC5088 and RFC5089 211 Section 4 of [RFC5088] needs to be updated to allow advertisement of 212 additional PCE information carried in the Router Information LSA. 213 The following is proposed text for this change. 215 Replace the following paragraph from section 4: 217 "No additional sub-TLVs will be added to the PCED TLV in the future. 218 If a future application requires the advertisement of additional PCE 219 information in OSPF/ISIS, this will not be carried in the Router 220 Information LSA." 222 with 224 "If a future application requires the advertisement of additional PCE 225 information in OSPF, e.g., to facilitate key distribution and 226 cryptographic authentication and message integrity verification, 227 additional sub-TLVs could be added to the PCED TLV and carried in the 228 Router Information LSA." 230 Section 4 of [RFC5089] needs to be updated to allow advertisement of 231 additional PCE information carried in the Router CAPABILITY TLV. The 232 following is proposed text for this change. 234 Replace the following paragraph from section 4: 236 "No additional sub-TLVs will be added to the PCED TLV in the future. 237 If a future application requires the advertisement of additional PCE 238 information in IS-IS, this will not be carried in the CAPABILITY 239 TLV." 241 with 243 "If a future application requires the advertisement of additional PCE 244 information in IS-IS, e.g., to facilitate key distribution and 245 cryptographic authentication and message integrity verification, 246 additional sub-TLVs could be added to the PCED sub-TLV and carried in 247 the CAPABILITY TLV." 249 At a time of publication of [RFC5088] and [RFC5089] there were 250 concerns about advertising non-IGP specific information in OSPF(v3) 251 Router Information LSAs and IS-IS router capability TLV. [RFC7770] 252 added the functionality of advertising multiple instances of the 253 OSPF(v3) Router Information LSA and IS-IS support multiple CAPABILITY 254 TLV [RFC7981]. 256 5. Backward Compatibility Consideration 258 An LSR that does not support the new IGP PCE capability bits 259 specified in this document silently ignores those bits. 261 An LSR that does not support the new KEYNAME sub-TLV specified in 262 this document silently ignores the sub-TLV. 264 IGP extensions defined in this document do not introduce any new 265 interoperability issues. 267 6. Management Considerations 269 A configuration option may be provided for advertising and 270 withdrawing PCE security capability via IGP. 272 7. Security Considerations 274 This document raises no new security issues beyond those described in 275 [RFC5088] and [RFC5089]. 277 8. IANA Considerations 279 8.1. OSPF PCE Capability Flag 281 IANA is requested to allocate new bits assignments for the OSPF 282 Parameters "Path Computation Element (PCE) Capability Flags" 283 registry. 285 Bit Meaning Reference 286 xx TCP-AO Support [This.I.D] 287 xx PCEP over TLS support [This.I.D] 289 The registry is located at: https://www.iana.org/assignments/ospfv2- 290 parameters/ospfv2-parameters.xml#ospfv2-parameters-14.xml 292 8.2. PCED sub-TLV Type Indicators 294 The PCED sub-TLVs were defined in [RFC5088] and [RFC5089], but they 295 did not create a registry for it. This document requests IANA to 296 create a new top-level OSPF registry, the "PCED sub-TLV type 297 indicators" registry. This registry should be populated with - 299 Value Description Reference 300 0 Reserved [This.I.D][RFC5088] 301 1 PCE-ADDRESS [This.I.D][RFC5088] 302 2 PATH-SCOPE [This.I.D][RFC5088] 303 3 PCE-DOMAIN [This.I.D][RFC5088] 304 4 NEIG-PCE-DOMAIN [This.I.D][RFC5088] 305 6 KEY-ID [This.I.D] 306 7 KEY-CHAIN-NAME [This.I.D] 308 This registry is also used by IS-IS PCED sub-TLV. 310 9. Acknowledgments 312 The authors of this document would also like to thank Acee Lindem, 313 Julien Meuric for the review and comments. 315 10. References 317 10.1. Normative References 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, 321 DOI 10.17487/RFC2119, March 1997, 322 . 324 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 325 Zhang, "OSPF Protocol Extensions for Path Computation 326 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 327 January 2008, . 329 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 330 Zhang, "IS-IS Protocol Extensions for Path Computation 331 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 332 January 2008, . 334 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 335 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 336 June 2010, . 338 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 339 for the TCP Authentication Option (TCP-AO)", RFC 5926, 340 DOI 10.17487/RFC5926, June 2010, 341 . 343 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 344 S. Shaffer, "Extensions to OSPF for Advertising Optional 345 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 346 February 2016, . 348 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 349 for Advertising Router Information", RFC 7981, 350 DOI 10.17487/RFC7981, October 2016, 351 . 353 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 354 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 355 May 2017, . 357 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 358 Zhang, "YANG Data Model for Key Chains", RFC 8177, 359 DOI 10.17487/RFC8177, June 2017, 360 . 362 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 363 "PCEPS: Usage of TLS to Provide a Secure Transport for the 364 Path Computation Element Communication Protocol (PCEP)", 365 RFC 8253, DOI 10.17487/RFC8253, October 2017, 366 . 368 10.2. Informative References 370 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 371 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 372 DOI 10.17487/RFC5440, March 2009, 373 . 375 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 376 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 377 . 379 Appendix A. No MD5 Capability Support 381 To be compliant with Section 10.2 of RFC5440, this document doesn't 382 consider to add capability for TCP-MD5. Therefore by default, PCEP 383 Speaker in communication supports capability for TCP-MD5 (See section 384 10.2, [RFC5440]). A method to advertise TCP-MD5 Capability support 385 using IGP flooding is not required. If the client is looking for 386 connecting with PCE server with other Security capability support 387 (e.g., TLS support) than TCP-MD5, the client MUST check if flag bit 388 in the PCE- CAP-FLAGS sub-TLV for specific capability is set (See 389 section 3.1). 391 Authors' Addresses 393 Diego R. Lopez 394 Telefonica I+D 395 Spain 397 Email: diego.r.lopez@telefonica.com 399 Qin Wu 400 Huawei Technologies 401 12 Mozhou East Road, Jiangning District 402 Nanjing, Jiangsu 210012 403 China 405 Email: bill.wu@huawei.com 407 Dhruv Dhody 408 Huawei Technologies 409 Divyashree Techno Park, Whitefield 410 Bangalore, Karnataka 560037 411 India 413 Email: dhruv.ietf@gmail.com 415 Michael Wang 416 Huawei 417 12 Mozhou East Road, Jiangning District 418 Nanjing, Jiangsu 210012 419 China 421 Email: wangzitao@huawei.com 422 Daniel King 423 Old Dog Consulting 424 UK 426 Email: daniel@olddog.co.uk