idnits 2.17.1 draft-wu-lsr-pce-discovery-security-support-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 (August 23, 2018) is 2066 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) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6006 (Obsoleted by RFC 8306) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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 Intended status: Standards Track Q. Wu 5 Expires: February 24, 2019 D. Dhody 6 Z. Wang 7 Huawei 8 D. King 9 Old Dog Consulting 10 August 23, 2018 12 IGP extension for PCEP security capability support in the PCE discovery 13 draft-wu-lsr-pce-discovery-security-support-00 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 capability. 27 This document proposes new capability flag bits for PCE-CAP-FLAGS 28 sub-TLV that can be announced as attribute in the IGP advertisement 29 to distribute PCEP security support information. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 24, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 1. Introduction 65 As described in [RFC5440], PCEP communication privacy is one 66 importance issue, as an attacker that intercepts a Path Computation 67 Element (PCE) message could obtain sensitive information related to 68 computed paths and resources. 70 Among the possible solutions mentioned in these documents, Transport 71 Layer Security (TLS) [RFC5246] provides support for peer 72 authentication, and message encryption and integrity while TCP 73 Authentication Option (TCP-AO) [RFC5925] and Cryptographic Algorithms 74 for TCP-AO [RFC5926] offer significantly improved security for 75 applications using TCP. As specified in section 4 of [RFC8253], in 76 order for a Path Computation Client(PCC) to begin a connection with a 77 PCE server using TLS or TCP-AO, PCC SHOULD know whether PCE server 78 supports TLS or TCP-AO as a secure transport. 80 [RFC5088] and [RFC5089] define a method to advertise path computation 81 capabilities using IGP flooding for OSPF and IS-IS respectively. 82 However [RFC5088] and [RFC5089] lacks a method to advertise PCEP 83 security (e.g., TLS) support capability. 85 This document proposes new capability flag bits for PCE-CAP-FLAGS 86 sub-TLV that can be announced as attributes in the IGP advertisement 87 (defined in [RFC5088] and [RFC5089]) to distribute PCEP security 88 support information. 90 2. Conventions used in this document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC2119 [RFC2119]. 96 3. IGP extension for PCEP security capability support 98 The PCE-CAP-FLAGS sub-TLV is defined in section 4.5 of [RFC5088] and 99 [RFC5089] as an optional sub-TLV used to advertise PCE capabilities. 100 In this section, we extend the PCE-CAP-FLAGS sub-TLV to include the 101 capability and indications that are described for PCEP security 102 (e.g., TLS) support in the current document. 104 In the PCE-CAP-FLAGS sub-TLV defined in [RFC5088] and [RFC5089], nine 105 capability flags defined in [RFC5088] (as per [RFC4657]) and two 106 capability flags defined [RFC5557], [RFC6006] are included and 107 follows the following format: 109 o TYPE: 5 110 o LENGTH: Multiple of 4 111 o VALUE: This contains an array of units of 32 bit flags with 112 the most significant bit as 0. Each bit represents one PCE 113 capability. 115 and the processing rule of these flag bits are defined in [RFC5088] 116 and [RFC5089]. In this document, we define two new capability flag 117 bits that indicate TCP Authentication Option (TCP-AO) support, PCEP 118 over TLS support respectively as follows: 120 Bit Capability Description 121 xx TCP AO Support 122 xx PCEP over TLS support 124 3.1. Use of PCEP security capability support for PCE discovery 126 TCP-AO, PCEP over TLS support flag bits are advertised using IGP 127 flooding. 129 o PCE supports TCP-AO: IGP advertisement SHOULD include TCP-AO 130 support flag bit. 132 o PCE supports TLS: IGP advertisement SHOULD include PCEP over TLS 133 support flag bit. 135 If PCE supports multiple security mechanisms, it SHOULD include all 136 corresponding flag bits in IGP advertisement. 138 If the client is looking for connecting with PCE server with TCP-AO 139 support, the client MUST check if TCP-AO support flag bit in the PCE- 140 CAP-FLAGS sub-TLV is set. If not, the client SHOULD NOT consider 141 this PCE. If the client is looking for connecting with PCE server 142 using TLS, the client MUST check if PCEP over TLS support flag bit in 143 the PCE-CAP-FLAGS sub-TLV is set. If not, the client SHOULD NOT 144 consider this PCE. 146 4. Backward Compatibility Consideration 148 An LSR that does not support the new IGP PCE capability bits 149 specified in this document silently ignores those bits. 151 IGP extensions defined in this document do not introduce any new 152 interoperability issues. 154 5. Management Considerations 156 A configuration option may be provided for advertising and 157 withdrawing PCE security capability via IGP. 159 6. Security Considerations 161 This document raises no new security issues beyond those described in 162 [RFC5088] and [RFC5089]. 164 7. IANA Considerations 166 IANA is requested to allocate a new bit in "PCE Security Capability 167 Flags" registry for PCEP Security support capability. 169 Bit Meaning Reference 170 xx TCP-AO Support [This.I.D] 171 xx PCEP over TLS support [This.I.D] 173 8. References 175 8.1. Normative References 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", March 1997. 180 [RFC5088] Le Roux, JL., "OSPF Protocol Extensions for Path 181 Computation Element (PCE) Discovery", RFC 5088, January 182 2008. 184 [RFC5089] Le Roux, JL., "IS-IS Protocol Extensions for Path 185 Computation Element (PCE) Discovery", RFC 5089, January 186 2008. 188 [RFC5925] Touch , J., "The TCP Authentication Option", RFC 5925, 189 June 2010. 191 [RFC5926] Gregory Lebovitz, G., "Cryptographic Algorithms for the 192 TCP Authentication Option (TCP-AO)", RFC 5926, June 2010. 194 [RFC8253] R. Lopez, D., "PCEPS: Usage of TLS to Provide a Secure 195 Transport for the Path Computation Element Communication 196 Protocol (PCEP)", RFC 8253, October 2017. 198 8.2. Informative References 200 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 201 Communication Protocol Generic Requirements", RFC 4657, 202 September 2006. 204 [RFC5246] Dierks, T., "The Transport Layer Security (TLS) Protocol 205 Version 1.2", RFC 5246, August 2008. 207 [RFC5440] Le Roux, JL., "Path Computation Element (PCE) 208 Communication Protocol (PCEP)", RFC 5440, March 2009. 210 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 211 Computation Element Communication Protocol (PCEP) 212 Requirements and Protocol Extensions in Support of Global 213 Concurrent Optimization", RFC 5557, July 2009. 215 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 216 and J. Meuric, "Extensions to the Path Computation Element 217 Communication Protocol (PCEP) for Point-to-Multipoint 218 Traffic Engineering Label Switched Paths", RFC 6006, 219 September 2010. 221 Appendix A. Appendix A: No MD5 Capability Support 223 To be compliant with Section 10.2 of RFC5440, this document doesn't 224 consider to add capability for TCP-MD5. Therefore by default, PCEP 225 Speaker in communication supports capability for TCP-MD5 (See section 226 10.2,[RFC5440]). A method to advertise TCP-MD5 Capability support 227 using IGP flooding is not required. If the client is looking for 228 connecting with PCE server with other Security capability support 229 (e.g., TLS support) than TCP-MD5, the client MUST check if flag bit 230 in the PCE- CAP-FLAGS sub-TLV for specific capability is set (See 231 section 3.1). 233 Authors' Addresses 234 Diego R. Lopez 235 Telefonica I+D 236 Spain 238 Email: diego.r.lopez@telefonica.com 240 Qin Wu 241 Huawei Technologies 242 12 Mozhou East Road, Jiangning District 243 Nanjing, Jiangsu 210012 244 China 246 Email: bill.wu@huawei.com 248 Dhruv Dhody 249 Huawei Technologies 250 Divyashree Techno Park, Whitefield 251 Bangalore, Karnataka 560037 252 India 254 Email: dhruv.ietf@gmail.com 256 Michael Wang 257 Huawei 258 12 Mozhou East Road, Jiangning District 259 Nanjing, Jiangsu 210012 260 China 262 Email: wangzitao@huawei.com 264 Daniel King 265 Old Dog Consulting 266 UK 268 Email: daniel@olddog.co.uk