idnits 2.17.1 draft-mahesh-karp-lmp-analysis-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 : ---------------------------------------------------------------------------- ** 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 (February 11, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 February 11, 2014 5 Expires: August 15, 2014 7 Analysis of LMP Security According to KARP Design Guide 8 draft-mahesh-karp-lmp-analysis-01.txt 10 Abstract 12 This document analyzes Link Management Protocol (LMP) according to 13 guidelines set forth in section 4.2 of KARP Design Guidelines (RFC 14 6518). 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 15, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Current Assessment of LMP . . . . . . . . . . . . . . . . . . 3 53 2.1. LMP Procedure . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. Transport Layer . . . . . . . . . . . . . . . . . . . . . 4 55 2.3. Message Integrity and Node Authentication . . . . . . . . 4 56 2.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 5 57 2.5. Out-of-order Protection . . . . . . . . . . . . . . . . . 5 58 3. Security Requirements for LMP . . . . . . . . . . . . . . . . 6 59 4. Gap Analysis for LMP . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 6 61 5. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Security Consideration . . . . . . . . . . . . . . . . . . . 7 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 66 8.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 In March 2006, the Internet Architecture Board (IAB) described an 72 attack on core routing infrastructure as an ideal attack that would 73 inflict the greatest amount of damage, in their Report from the IAB 74 workshop on Unwanted Traffic March 9-10, 2006 [RFC4948], and 75 suggested steps to tighten the infrastructure against the attack. 76 Four main steps were identified for that tightening: 78 1. Create secure mechanisms and practices for operating routers. 80 2. Clean up the Internet Routing Registry (IRR) repository, and 81 securing both the database and the access, so that it can be used 82 for routing verifications. 84 3. Create specifications for cryptographic validation of routing 85 message content. 87 4. Secure the routing protocols' packets on the wire. 89 In order to secure the routing protocols this document performs an 90 initial analysis of the current state of LMP according to the 91 requirements of KARP Design Guidelines [RFC6518]. This draft builds 92 on several previous analysis efforts into routing security: 94 o Issues with existing Cryptographic Protection Methods for Routing 95 Protocols [RFC6039] an analysis of cryptographic issues with 96 routing protocols. 98 o Analysis of OSPF Security According to KARP Design Guide 99 [RFC6863]. 101 o Analysis of BGP, LDP, PCEP, and MSDP Issues According to KARP 102 Design Guide [RFC6952] which is a analysis of the four routing 103 protocols. 105 Link Management Protocol (LMP) [RFC4204] is used to manage Traffic 106 Engineering (TE) links. According to the document, LMP can be 107 subject to a number of attacks. Some examples include: 109 o an adversary may spoof control packets 111 o an adversary may modify the control packet in transit 113 o an adversary may replay control packets 115 o an adversary may study a number of control packets and try to 116 break the key using cryptographic tools. 118 Section 2 looks at the current security state of LMP. Section 3 119 suggest an optimal security state and section 4 does an analysis of 120 the gap between the existing and the optimal security state of the 121 protocol and suggest some areas where we need to improve. 123 1.1. Abbreviations 125 LMP - Link Management Protocol 127 TE - Traffic Engineering 129 2. Current Assessment of LMP 131 This section looks at LMP procedure, the underlying transport layer 132 and security assessment associated with LMP. 134 2.1. LMP Procedure 136 The two core procedures of LMP procedure are control channel 137 management and link property correlation. Control channel management 138 is used to establish and maintain control channels between adjacent 139 nodes. This is done using a Config message exchange and a fast keep- 140 alive mechanism between the nodes. Link property correlation is used 141 to synchronize the TE link properties and verify the TE link 142 configuration. 144 Two additional procedures include link connectivity verification and 145 fault management. Link connectivity verification is used for data 146 plane discovery, Interface_Id exchange, and physical connectivity 147 verification. This is done by sending Test messages over the data 148 channel and the TestStatus messages coming back over the control 149 plane. The LMP link connectivity verification procedure is 150 coordinated using the BeginVerify message exchanged over the control 151 channel. 153 The LMP fault management procedure is based on a ChannelStatus 154 message exchange. The ChannelStatus message is sent unsolicited and 155 is used to notify an LMP neighbor about the status of one or more 156 data channels. ChannelStatusAck is used to acknowledge receipt of 157 the ChannelStatus message. Similarly, a ChannelStatusResponse 158 message is used to acknowledge receipt of a ChannelStatusRequest 159 message. 161 2.2. Transport Layer 163 Except for Test messages, all LMP packets use UDP to communicate with 164 its piers over a LMP port number. Multiple "LMP adjacencies" may be 165 formed and be active between two nodes. LMP messages are transmitted 166 reliably using Message_Ids and retransmissions. 168 Unlike TCP which can use TCP-AO [RFC5925] for message authentication, 169 UDP does not have any of authenticating packets. 171 2.3. Message Integrity and Node Authentication 173 LMP [RFC4204] recommends the use of IPSec for authentication. That 174 document also states that there is currently no requirement that LMP 175 headers or payload be encrypted. It also states that LMP endpoint 176 identity does not need to be protected. 178 To authenticate LMP, the document further states that manual keying 179 mode be supported. However, it notes that manual keying cannot 180 effectively support replay protection and automatic re-keying. It 181 therefore recommends that manual keying should only be used for 182 diagnostic purposes and only use automatic re-keying for replay 183 protection and automatic re-keying. 185 2.4. Replay Attack 187 MESSAGE_ID and MESSAGE_ID_ACK objects are included in the LMP 188 messages to support reliable message delivery. The Message_Id field 189 of the MESSAGE_ID object contains a generator selected value. This 190 value is supposed to be monotonically increasing. A value is 191 considered to be used when it has been sent in an LMP message with 192 the same CC_Id or LMP adjacency. The Message_Id field of the 193 MESSAGE_ID_ACK contains the Message_Id field of the message being 194 acknowledged. 196 Unacknowledged messages sent with the MESSAGE_ID object are to be 197 retransmitted until the message is acknowledged or until a retry 198 limit is reached. The Message_Id field is 32 bit wide and may wrap. 200 The 32-bit Message_Id number space is not large enough to guarantee 201 that the Message_Id number will not wrap around within a reasonable 202 long period. Therefore, the system is susceptible to a replay 203 attack. 205 In addition, LMP does not provide for a generation of a unique 206 monotonically increasing sequence numbers across a failure or a 207 restart. 209 2.5. Out-of-order Protection 211 LMP states that nodes processing incoming messages are supposed to 212 check to see if the newly received message is out of order messages, 213 and if so, they are to be ignored and dropped silently. 215 Specifically, if the message is a Config message, and the Message_Id 216 value is less than the largest Message_Id value previously received 217 from the sender for the CC_Id, then the message is supposed to be 218 treated as being out-of-order. If the message is a LinkSummary 219 message and the Message_Id value is less than the largest Message_Id 220 value previously received from the sender of the TE link, then the 221 message is supposed to be treated as being out-of-order. Similarly, 222 if the message is a ChannelStatus message and the Message_Id value is 223 less than the largest Message_id value previously received from he 224 sender of the specific TE link, then the receiver is supposed to 225 check for the Message_Id value previously received from the state of 226 each data channel included in the ChannelStatus message. If the 227 Message_Id value associated with at least one of the data channels 228 included in the message, the message is not supposed to be treated as 229 out-of-order. All other messages are not supposed to be treated as 230 out-of-order. 232 3. Security Requirements for LMP 234 LMP [RFC4204] states that the following requirements should be 235 applied to secure the protocol. 237 o LMP security must be able to provide authentication, integrity and 238 replay protection. 240 o Confidentiality is not needed for LMP traffic. 242 o The protection of identity of the LMP end-points is not commonly 243 required. 245 o The security mechanism should provide for a well defined key 246 management scheme. The key management scheme should be scalable 247 and should provide for automatic key rollover. 249 o The algorithm used for authentication must be cryptographically 250 sound and it should provide for algorithm agility. 252 4. Gap Analysis for LMP 254 This section outlines the differences between the current state of 255 LMP and the desired state as outlined in sections 4.1 and 4.2 of KARP 256 Design Guidelines [RFC6518]. 258 4.1. Replay Protection 260 As outlined above, LMP protocol is subject to replay attacks. 261 Solutions to replay protection include: 263 1. Maintaining Message_Id numbers in stable memory 265 2. Introducing the data from a local time clock into the generation 266 of Message_Id numbers after a restart 268 3. Introducing the timing information from a Network Recovered Clock 269 into the generation of Message_Id numbers after a restart. 271 In addition, a handshake is defined for a receiver to get the latest 272 value of a Message_Id number. Therefore, this solution is effective 273 in addressing the issues caused by the rollback of Message_Id numbers 274 across a system restart or failure. However, when a router uses the 275 approach to generating Message_Id numbers with the time information 276 from NTP, an attacker may try to deceive the router to generate a 277 Message_Id number which is less than the Message_Id numbers it used 278 to have, by sending replayed or foiled NTP information. 280 5. IANA Requirements 282 This document makes no IANA requests, and the RFC Editor may consider 283 deleting this section on publication of this document as a RFC. 285 6. Security Consideration 287 This document is all about security considerations for LMP. 289 7. Acknowledgements 291 8. References 293 8.1. Normative References 295 [RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, 296 October 2005. 298 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 299 Routing Protocols (KARP) Design Guidelines", RFC 6518, 300 February 2012. 302 8.2. Informative References 304 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 305 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 306 4948, August 2007. 308 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 309 Authentication Option", RFC 5925, June 2010. 311 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 312 with Existing Cryptographic Protection Methods for Routing 313 Protocols", RFC 6039, October 2010. 315 [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security 316 According to the Keying and Authentication for Routing 317 Protocols (KARP) Design Guide", RFC 6863, March 2013. 319 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 320 BGP, LDP, PCEP, and MSDP Issues According to the Keying 321 and Authentication for Routing Protocols (KARP) Design 322 Guide", RFC 6952, May 2013. 324 Author's Address 326 Mahesh Jethanandani 327 Ciena Corporation 328 3939 North 1st Street 329 San Jose, CA 95134 330 USA 332 Phone: +1 (408) 904-2160 333 Email: mjethanandani@gmail.com