idnits 2.17.1 draft-mahesh-karp-rsvp-te-analysis-02.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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-mahesh-karp-rsvp-te-analysis-01', but the file name used is 'draft-mahesh-karp-rsvp-te-analysis-02' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 16, 2013) is 3814 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2385' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC5926' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC2409' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC3547' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC5082' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC5925' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC5961' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'RFC6862' is defined on line 368, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 2 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Working Group M. Jethanandani 3 Internet-Draft Ciena Corporation 4 Intended status: Informational D. Zhang 5 Expires: May 20, 2014 Huawei Technologies co., LTD. 6 November 16, 2013 8 Analysis of RSVP-TE Security According to KARP Design Guide 9 draft-mahesh-karp-rsvp-te-analysis-01.txt 11 Abstract 13 This document analyzes Resource reSerVation Protocol-Traffic 14 Engineering (RSVP-TE) according to guidelines set forth in section 15 4.2 of KARP Design Guidelines (RFC 6518). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 20, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Current Assessment of RSVP-TE . . . . . . . . . . . . . . . . 4 54 2.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 4 55 2.1.1. UDP Encapsulation . . . . . . . . . . . . . . . . . . 4 56 2.2. Keying Mechanism . . . . . . . . . . . . . . . . . . . . 4 57 2.3. Message Integrity and Node Authentication . . . . . . . . 5 58 2.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 5 59 2.5. Out of Order Protection . . . . . . . . . . . . . . . . . 6 60 2.6. Denial of Service Attack Protection . . . . . . . . . . . 6 61 3. Gap Analysis for RSVP-TE . . . . . . . . . . . . . . . . . . 6 62 4. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Security Consideration . . . . . . . . . . . . . . . . . . . 7 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 7.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 In March 2006, the Internet Architecture Board (IAB) described an 73 attack on core routing infrastructure as an ideal attack that would 74 inflict the greatest amount of damage, in their Report from the IAB 75 workshop on Unwanted Traffic March 9-10, 2006 [RFC4948], and 76 suggested steps to tighten the infrastructure against the attack. 77 Four main steps were identified for that tightening: 79 1. Create secure mechanisms and practices for operating routers. 81 2. Clean up the Internet Routing Registry (IRR) repository, and 82 securing both the database and the access, so that it can be used 83 for routing verifications. 85 3. Create specifications for cryptographic validation of routing 86 message content. 88 4. Secure the routing protocols' packets on the wire. 90 In order to secure the routing protocols this document performs an 91 initial analysis of the current state of RSVP-TE according to the 92 requirements of KARP Design Guidelines [RFC6518]. This draft builds 93 on several previous analysis efforts into routing security: 95 o Issues with existing Cryptographic Protection Methods for Routing 96 Protocols [RFC6039] an analysis of cryptographic issues with 97 routing protocols. 99 o Analysis of OSPF Security According to KARP Design Guide 100 [RFC6863]. 102 o Analysis of BGP, LDP, PCEP, and MSDP Issues According to KARP 103 Design Guide [RFC6952] which is a analysis of the four routing 104 protocols. 106 Resource reSerVation Protocol (RSVP) [RFC2205] is a resource 107 reservation setup protocol designed for an integrated services. RSVP 108 Security Properties [RFC4230] indicates the unfeasibility of using 109 IPSec to secure RSVP signaling messages. RSVP Cryptographic 110 Authentication [RFC2747] describes the format and use of RSVP's 111 INTEGRITY objects to provide hop-by-hop integrity and authentication 112 of RSVP messages. RSVP-TE: Extensions to RSVP for LSP Tunnels 113 [RFC3209] is an extension of the RSVP protocol to establish Multi- 114 Protocol Label Switching (MPLS) Label Switch Paths (LSPs). RSVP-TE 115 signaling messages are used to establish both intra- and inter-domain 116 TE LSPs. The security mechanisms for RSVP, RSVP Cryptographic 117 Authentication [RFC2747] can be used by RSVP-TE to provide the 118 security protection for the RSVP-TE message transportation. 119 Therefore, the rest of the document will focus on the current state 120 of security efforts for RSVP and assume that will apply to RSVP-TE 121 also. 123 Section 2 looks at the current security state of RSVP-TE. Section 3 124 does an analysis of the gap between the existing and the optimal 125 security state of the protocol and suggest some areas where we need 126 to improve. 128 1.1. Abbreviations 130 BGP - Border Gateway Protocol 132 DoS - Denial of Service 134 KARP - Key and Authentication for Routing Protocols 136 KDF - Key Derivation Function 138 KEK - Key Encrypting Key 140 KMP - Key Management Protocol 142 LDP - Label Distribution Protocol 143 LSP - Label Switch Path 145 MAC - Message Authentication Code 147 MKT - Master Key Tuple 149 MPLS - Multi Protocol Label Switching 151 MSDP - Multicast Source Distribution Protocol 153 MD5 - Message Digest algorithm 5 155 PCEP - Path Computation Element Protocol 157 RSVP - Resource reSerVation Protocol 159 TCP - Transmission Control Protocol 161 UDP - User Datagram Protocol 163 2. Current Assessment of RSVP-TE 165 This section looks at RSVP-TE and the underlying transport protocol 166 and key mechanisms built for the protocol. 168 2.1. Transport Layer 170 RSVP operates on top of IPv4 or IPv6, occupying the place of a 171 transport protocol in the protocol stack. However, RSVP does not 172 transport application data but is rather an Internet control 173 protocol, like ICMP, IGMP, or routing protocols. 175 2.1.1. UDP Encapsulation 177 An RSVP implementation generally requires the ability to perform 178 "raw" network I/O. However, some systems may not support raw network 179 I/O. To use RSVP, such hosts must encapsulate RSVP messages in UDP. 181 2.2. Keying Mechanism 183 Section 7 of RSVP Cryptographic Authentication discusses the 184 possibility of using Kerberos to generate and distribute RSVP 185 authentication keys. However, the design of Automated Key Management 186 (AKM) mechanism for RSVP is still incomplete. There is no other AKM 187 solution proposed at this time. If anything, manual key management 188 is used. 190 The protocol states that manual keying should be supported and states 191 the need for a key management protocol to distribute keys. It even 192 states that the Key Identifier be the hook between RSVP and the key 193 management protocol. But it deliberately excludes defining a 194 integrated key management protocol technique in the document. It 195 does define a key lifetime that should be recorded for all systems 196 although how they are presented e.g. using the start time and the end 197 time of the key life period, is not specified. It even advises that 198 the keys should be changed on a regular basis and that multiple keys 199 should be used to transition from one key to another. 201 2.3. Message Integrity and Node Authentication 203 RSVP-TE makes use of RSVP Cryptographic Authentication [RFC2747]. 204 Note that there is currently no RSVP-TE specific security mechanism. 205 It is required that RSVP-TE headers and payload be authenticated, but 206 there is no requirement that RSVP-TE headers be encrypted. 208 RSVP Cryptographic Authentication [RFC2747] defines the use HMAC-MD5 209 for both message integrity and node authentication. The length of 210 the keyed digests is 128 bits. In these cases RSVP checksum can be 211 disabled in lieu of message digest. In addition, no algorithm 212 agility is supported. 214 2.4. Replay Protection 216 RSVP uses 64 bit monotonically increasing sequence numbers to prevent 217 against replay attacks. The sequence number space is large enough to 218 guarantee that a sequence number will never reach its maximum and 219 roll back within a reasonable long period. 221 The solution provides three approaches to generate unique 222 monotonically increasing sequence numbers across a failure or a 223 restart. The solutions include: 225 1. Maintaining sequence numbers in stable memory 227 2. Introducing the data from a local time clock into the generation 228 of sequence numbers after a restart 230 3. Introducing the timing information from a Network Recovered Clock 231 into the generation of sequence numbers after a restart. 233 In addition, a handshake is defined for a receiver to get the latest 234 value of a sequence number. Therefore, this solution is effective in 235 addressing the issues caused by the rollback of sequence numbers 236 across a system restart or failure. However, when a router uses the 237 approach to generating sequence numbers with the time information 238 from NTP, an attacker may try to deceive the router to generate a 239 sequence number which is less than the sequence numbers it used to 240 have, by sending replayed or foiled NTP information. 242 2.5. Out of Order Protection 244 To address the issue of out-of-order message delivery, the solution 245 proposed in RSVP Cryptographic Authentication [RFC2747] allows 246 administrators to specify a sequence number window corresponding to 247 the worst case reordering behavior. Instead of requiring the 248 sequence number of an incoming packet to be strictly larger than the 249 ones previously received, a packet will be accepted if its sequence 250 number is within the window. 252 2.6. Denial of Service Attack Protection 254 RSVP does not explicitly mention Denial of Service (DoS) attacks and 255 how to prevent against it. However, a RSVP-TE node does know the 256 peers that it should be communicating with and can therefore accept 257 packets from known hosts only. This feature can largely mitigate the 258 security risks caused by DoS attacks. 260 3. Gap Analysis for RSVP-TE 262 This section outlines the differences between the current state of 263 RSVP-TE and the desired state as outlined in sections 4.1 and 4.2 of 264 KARP Design Guidelines [RFC6518]. 266 In RSVP Cryptographic Authentication [RFC2747], only the usage of MD5 267 to generate digests for RSVP-TE messages is defined. In order to 268 fulfill the requirement of supporting strong algorithms and 269 cryptographic algorithm agility, at least the support of SHA-2 and 270 the ability to indicate additional algorithms needs to be provided.. 272 In addition, in RSVP Cryptographic Authentication [RFC2747], three 273 approaches to generating unique monotonically increasing sequence 274 numbers across a failure and restart are introduced, but no approach 275 is mandated. However, as mentioned above, when using Network 276 Recovered Clocks into the generation of sequence numbers, the 277 capability of RSVP-TE in tolerating inter-connection replay attacks 278 will largely rely on the security of network timing protocols. 279 Therefore, in future this approach should not be recommended. 281 4. IANA Requirements 283 This document makes no IANA requests, and the RFC Editor may consider 284 deleting this section on publication of this document as a RFC. 286 5. Security Consideration 288 This document is all about security considerations for RSVP-TE. 290 6. Acknowledgements 292 The authors would like to thank Sean Turner for his review and 293 comments on the draft. 295 7. References 297 7.1. Normative References 299 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 300 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 301 Functional Specification", RFC 2205, September 1997. 303 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 304 Signature Option", RFC 2385, August 1998. 306 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 307 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 308 Tunnels", RFC 3209, December 2001. 310 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 311 for the TCP Authentication Option (TCP-AO)", RFC 5926, 312 June 2010. 314 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 315 Routing Protocols (KARP) Design Guidelines", RFC 6518, 316 February 2012. 318 7.2. Informative References 320 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 321 Hashing for Message Authentication", RFC 2104, February 322 1997. 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, March 1997. 327 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 328 (IKE)", RFC 2409, November 1998. 330 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 331 Authentication", RFC 2747, January 2000. 333 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 334 Group Domain of Interpretation", RFC 3547, July 2003. 336 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 337 Properties", RFC 4230, December 2005. 339 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 340 Protocol 4 (BGP-4)", RFC 4271, January 2006. 342 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 343 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 344 4948, August 2007. 346 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 347 Specification", RFC 5036, October 2007. 349 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 350 Pignataro, "The Generalized TTL Security Mechanism 351 (GTSM)", RFC 5082, October 2007. 353 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 354 (PCE) Communication Protocol (PCEP)", RFC 5440, March 355 2009. 357 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 358 Authentication Option", RFC 5925, June 2010. 360 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 361 Robustness to Blind In-Window Attacks", RFC 5961, August 362 2010. 364 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 365 with Existing Cryptographic Protection Methods for Routing 366 Protocols", RFC 6039, October 2010. 368 [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 369 Authentication for Routing Protocols (KARP) Overview, 370 Threats, and Requirements", RFC 6862, March 2013. 372 [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security 373 According to the Keying and Authentication for Routing 374 Protocols (KARP) Design Guide", RFC 6863, March 2013. 376 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 377 BGP, LDP, PCEP, and MSDP Issues According to the Keying 378 and Authentication for Routing Protocols (KARP) Design 379 Guide", RFC 6952, May 2013. 381 Authors' Addresses 383 Mahesh Jethanandani 384 Ciena Corporation 385 3939 North First Street 386 San Jose, CA 95134 387 USA 389 Phone: +1 (408) 904-2160 390 Email: mjethanandani@gmail.com 392 Dacheng Zhang 393 Huawei Technologies co., LTD. 394 Beijing 395 China 397 Email: zhangdacheng@huawei.com