idnits 2.17.1 draft-ietf-karp-ospf-analysis-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 : ---------------------------------------------------------------------------- ** 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 (March 3, 2011) is 4802 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-opsec-routing-protocols-crypto-issues' is defined on line 428, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-karp-crypto-key-table-00 == Outdated reference: A later version (-10) exists of draft-ietf-karp-design-guide-00 == Outdated reference: A later version (-07) exists of draft-ietf-karp-threats-reqs-01 == Outdated reference: A later version (-07) exists of draft-ietf-opsec-routing-protocols-crypto-issues-06 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hartman 3 Internet-Draft Painless Security 4 Intended status: Informational D. Zhang 5 Expires: September 4, 2011 Huawei 6 March 3, 2011 8 Analysis of OSPF Security According to KARP Design Guide 9 draft-ietf-karp-ospf-analysis-00.txt 11 Abstract 13 This document analyzes OSPFv2 and OSPFv3 according to the guidelines 14 set forth in section 4.2 of draft-ietf-karp-design-guide. 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 September 4, 2011. 33 Copyright Notice 35 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements to Meet . . . . . . . . . . . . . . . . . . . 3 52 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4 53 2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. Impacts of OSPF Replays . . . . . . . . . . . . . . . . . . . 7 57 4. Gap Analysis and Specific Requirements . . . . . . . . . . . . 9 58 5. Solution Work . . . . . . . . . . . . . . . . . . . . . . . . 10 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 60 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 66 1. Introduction 68 This document performs the initial analysis of the current state of 69 OSPFv2 and OSPFv3 according to the requirements of 70 [I-D.ietf-karp-design-guide]. This draft builds on several previous 71 analysis efforts into routing security. The OPSEC working group put 72 together [RFC6039] an analysis of cryptographic issues with routing 73 protocols. Earlier, the RPSEC working group put together 74 [I-D.ietf-rpsec-ospf-vuln] a detailed analysis of OSPF 75 vulnerabilities. 77 OSPF meets many of the requirements expected from a manually keyed 78 routing protocol. Integrity protection is provided with modern 79 cryptographic algorithms. Algorithm agility is provided: the 80 algorithm can be changed as part of re-keying an interface or peer. 81 Intra-connection re-keying is provided by the specifications, 82 although apparently some implementations have trouble with this in 83 practice. OSPFv2 security does not interfeer with prioritization of 84 packets. 86 However, some gaps remain between the current state and the 87 requirements for manually keyed routing security expressed in 88 [I-D.ietf-karp-threats-reqs] the requirements. This document 89 explores these gaps and proposes directions for addressing the gaps. 91 1.1. Requirements to Meet 93 There are a number of requirements described in section 3 of 94 [I-D.ietf-karp-threats-reqs] thatt OSPF does not currently meet: 96 Secure Simple PSKs: Today, OSPF directly uses the key as specified. 97 Related key attacks such as those described in section 4.1 of 98 [I-D.hartman-karp-ops-model] are possible. 100 Replay Protection: OSPFv3 has no replay protection at all. OSPFv2 101 has most of the mechanisms necessary for intra-connection replay 102 protection. Unfortunately, OSPFv2 does not securely identify the 103 neighbor with whom replay protection state is associated in all 104 cases. This weakness can be used to create significant denial-of- 105 service issues using intra-connection replays. OSPFv2 has no 106 inter-connection replay protection; this creates significant 107 denial-of-service opportunities. 109 Packet Prioritization: OSPFv3 uses IPsec to process packets. This 110 complicates implementations that wish to process some packets such 111 as hellos and acknowledgements above others. In addition, if 112 IPsec replay mechanisms were used, packets would need to be 113 processed at least by IPsec even if they were low priority. 115 Neighbor Identification: In some cases, OSPF identifies a neighbor 116 based on the IP address. This is never protected with OSPFv2 and 117 is not typically protected with OSPFv3. 119 The remainder of this document explains the details of how these 120 requirements fail to be met and proposes mechanisms for addressing 121 them. 123 1.2. Requirements notation 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2. Current State 131 This section describes the security mechanisms built into OSPFv2 and 132 OSPFv3. There are two goals to this section. First, this section 133 gives a brief explanation of the OSPF security mechanisms to those 134 familiar with connectionless integrity mechanisms but not with OSPF. 135 Second, this section explains the background necessary to understand 136 how OSPF fails to meet some of the requirements proposed for routing 137 security. 139 2.1. OSPFv2 141 Appendix D of [RFC2328] describes the basic procedure for 142 cryptographic authentication in OSPFv2. An authentication data field 143 in the OSPF packet header contains a key ID, the length of the 144 authentication data and a sequence number. A message authentication 145 code (MAC) is appended to the OSPF packet. This code protects all 146 fields of the packet including the sequence number but not the IP 147 header. 149 RFC 2328 defined the use of a keyed-MD5 MAC. While MD5 has not been 150 broken as a MAC, it is not the algorithm of choice for new MACs. 152 However, RFC 5709 [RFC5709] adds support for the SHA [FIPS180] family 153 of hashes to OSPFv2. The cryptographic authentication described in 154 RFC 5709 meets modern standards for per-packet integrity protection. 155 Thus, OSPFv2 meets the requirement for strong algorithms. Since 156 multiple algorithms are defined and a new algorithm can be selected 157 with each key, OSPFv2 meets the requirement for algorithm agility. 158 In order to provide cryptographic algorithms beleived to have a 159 relatively long useful life, RFC 5709 mandates support for SHA-2 160 rather than SHA-1. 162 These security services provide integrity protection on each packet. 163 In addition, limited replay detection is provided. The sequence 164 number is non-decreasing. So, once a router has increased its 165 sequence number, an attacker cannot replay an old packet. 166 Unfortunately, sequence numbers are not required to increase for each 167 packet. For instance, because existing OSPF security solutions do 168 not specify how to set the sequence number, it is possible that some 169 implementation use, e.g., "seconds since reboot" as their sequence 170 numbers. The sequence numbers is thus only increased by every 171 second. Also, no mechanism is provided to deal with the loss of 172 anti-replay state; if sequence numbers are reused when a router 173 reboots, then inter-connection replays are streight forward. Also, 174 because the IP header is not protected, the sequence number may not 175 be associated with the right neighbor; this opens up opportunities 176 for outsiders to perform replay attacks. See Section 3 for analysis 177 of these attacks. 179 The mechanism provides good support for key rollover. There is a key 180 ID; in addition mechanisms are described for managing key lifetimes 181 and starting the use of a new key in an orderly manner. Performing 182 orderly key rollover requires that implementations support accepting 183 a new key for received packets before using that key to generate 184 packets. Section D.3 of RFC 2328 requires this support in the form 185 of four configurable lifetimes for each key: two lifetimes control 186 the beginning and ending period for acceptance while two lifetimes 187 control the beginning and ending period for generation. This 188 provides a superset of the functionality in the key table 189 [I-D.ietf-karp-crypto-key-table] regarding lifetime. 191 The OSPFv2 replay mechanism does not handle packet priorities as 192 described. If packets are processed out-of-order, then if the 193 sequence number increases, packets processed later will be discarded. 195 2.2. OSPFv3 197 RFC 4552 [RFC4552] describes how the authentication header and 198 encapsulating security payload mechanism can be used to protect 199 OSPFv3 packets. This mechanism provides per-packet integrity and 200 optional confidentiality using a wide variety of cryptographic 201 algorithms. Because OSPF uses multicast traffic, only manual key 202 management is supported. This mechanism meets requirements related 203 to algorithm selection and agility. 205 The Security Parameter Index (SPI) provides an identifier for the 206 security association. This along with other IPsec facilities 207 provides a mechanism for moving from one key to another, meeting the 208 key rollover requirements. 210 Because manual keying is used, no replay protection is provided for 211 OSPFv3. Thus the intra-connection and inter-connection replay 212 requirements are not met. 214 There is another serious problem with the OSPFv3 security: rather 215 than being integrated into OSPF, it is based on IPsec. In practice, 216 this has lead to deployment problems. 218 OSPF implementations generally prioritize packets in order to 219 minimize disruption when router resources such as CPU or memory 220 experience contention. When IPsec is used with OSPFv3, the offset of 221 the packet type, which is used to prioritize packets, depends on what 222 integrity transform is used. For this reason, prioritizing packets 223 may be more complex for OSPFv3. One approach is to establish per-SPI 224 filters to find the packet type and act accordingly. 226 3. Impacts of OSPF Replays 228 As discussed, neither version of OSPF meets the requirements of 229 inter-connection or intra-connection replay protection. This section 230 discusses the impacts of OSPF replays. 232 In OSPFv2, two facilities limit the scope of replay attacks. First, 233 when cryptographic authentication is used, each packet includes a 234 sequence number that is non-decreasing. In the current 235 specifications, the sequence number is remembered as part of an 236 adjacency: if an attacker can cause an adjacency to go down, then 237 replay state is lost. Database Description packets also include a 238 per-LSA sequence number that is part of the information that is 239 flooded. Even if a packet is replayed, the per-LSA sequence number 240 will prevent an old LSA from being installed. Unlike the per-packet 241 sequence number, the per-LSA sequence number must increase when an 242 LSA is changed. As a result, replays cannot be used to install old 243 routing information. 245 While the LSA sequence number provides some defense, there are a 246 number of attacks that are possible because of a per-packet replay. 247 The RPSEC analysis [I-D.ietf-rpsec-ospf-vuln] describes a number of 248 attacks that are possible because of per-packet replays. The most 249 serious appear to be attacks against Hello packets, which may cause 250 an adjacency to fail. Other attacks may cause excessive flooding or 251 excessive use of CPU. 253 Another serious attack concerns Database Description packets. In 254 addition to the per-packet sequence number that is part of 255 cryptographic authentication for OSPFv2 and the per-LSA sequence 256 numbers, Database Description packets also include a Database 257 Description sequence number. If a Database Description packet with 258 the incorrect sequence number is received, then the database exchange 259 process will be restarted. 261 The per-packet OSPFv2 sequence number can be used to reduce the 262 window in which a replay is valid. A receiver will harmlessly reject 263 a packet whose per-packet sequence number is older than the one most 264 recently received from a neighbor. Replaying the most recent packet 265 from a neighbor does not appear to create problems. So, if the per- 266 packet sequence number is incremented on every packet sent, then 267 replay attacks should not disrupt OSPFv2. Unfortunately, OSPFv2 does 268 not have a procedure for dealing with sequence numbers reaching the 269 maximum age. It may be possible to figure out a set of rules 270 sufficient to disrupt the damage of packet replays while minimizing 271 the use of the sequence number space. 273 As mentioned previously, when an adjacency is dropped, replay state 274 is lost. So, after rebooting or when all adjacencies are lost, a 275 router may allow its sequence number to decrease. An attacker can 276 cause significant damage by replaying a packet captured before the 277 sequence number decrease at a time after the sequence number 278 decrease. If this happens, then the replayed packet will be accepted 279 and the sequence number will be updated. However, the legitimate 280 sender will be using a lower sequence number, so legitimate packets 281 will be rejected. A similar attack is possible in cases where OSPF 282 identifies a neighbor based on source address. An attacker can 283 change the source address of a captured packet and replay it. If the 284 attacker causes a replay from a neighbor with a high sequence number 285 to appear to be from a low sequence number neighbor, then 286 connectivity with that neighbor will be disrupted until the adjacency 287 fails. 289 OSPFv3 lacks the per-packet sequence number but has the per-LSA 290 sequence number. As such, OSPFv3 has no defense against denial of 291 service attacks that exploit replay. 293 4. Gap Analysis and Specific Requirements 295 The design guide requires each design team to enumerate a set of 296 requirements for the routing protocol. The only concerns identified 297 with OSPF are areas where it fails to meet general requirements 298 outlined in the threats and requirements document. This section 299 explains how some of these general requirements map specifically onto 300 the OSPF protocol and enumerates the specific gaps that need to be 301 addressed. 303 There is a general requirement for inter-connection replay 304 protection. In the context of OSPF, this means that if an adjacency 305 goes down between two neighbors and later is re-established, 306 replaying packets from before the adjacency went down cannot disrupt 307 the adjacency. In the context of OSPF, intra-connection replay 308 protection means that replaying a packet cannot prevent an adjacency 309 from forming or disrupt an adjacency. Meeting the requirements for 310 intra-connection and inter-connection replay protection is a 311 significant gap between the optimal state and where OSPF is today. 313 Since OSPF uses fields in the IP header, the general requirement to 314 protect the IP header and handle neighbor identification applies. 315 This is another gap that needs to be addressed. Because the replay 316 protection will depend on neighbor identification, the replay 317 protection cannot be adequately adressed without handling this issue 318 as well. 320 In order to encourage deployment of OSPFv3 security, an 321 authentication option is required that does not have the deployment 322 challenges of IPsec. 324 In order to support the requirement for simple preshared keys, OSPF 325 needs to make sure that when the same key is used for two different 326 purposes, no problems result. 328 In order to support packet prioritization, the information needed to 329 prioritize OSPF packets (the packet type) MUST be at a constant 330 location in the packet. 332 5. Solution Work 334 A security solution will be developed for OSPFv2 and OSPFv3 based on 335 the OSPFv2 cryptographic authentication option. This solution will 336 have the following improvements over the existing OSPFv2 option: 338 Detect liveness of neighbors by adding additional information to 339 the Hello exchanges in order to detect inter-connection replay 341 Add a form of simple key derivation so that if the same preshared 342 key is used for OSPF and other purposes, related key attacks do 343 not result 345 Support OSPFv3 authentication without use of IPsec 347 Specify processing rules sufficient to permit replay detection and 348 packet prioritization 350 Emphasize requirements already present in the OSPF specification 351 sufficient to permit key migration without disrupting adjacencies 353 Specify the proper use of the key table for OSPF 355 Protect the source IP address 357 Require that sequence numbers be incremented on each packet 359 6. Security Considerations 361 This memo discusses and compiles vulnerabilities in the existing OSPF 362 cryptographic handling. 364 In analyzing proposed improvements to OSPF per-packet security, it is 365 desirable to consider how these improvements interact with potential 366 improvements in overall routing security. For example, the impact of 367 replay attacks currently depends on the LSA sequence number 368 mechanism. If cryptographic protections against insider attackers 369 are considered by future work, then that work will need to provide a 370 solution that meets the needs of the per-packet replay defense as 371 well as protection of routing data from insider attack. RFC 2154 372 [RFC2154] provides an experimental solution for end-to-end protection 373 of routing data in OSPF. It may be beneficial to consider how 374 improvements to the per-packet protections would interact with such a 375 mechanism to future-proof these mechanisms. 377 7. Acknowledgments 379 Funding for Sam Hartman's work on this memo is provided by Huawei. 381 The authors would like to thank Ran Atkinson, Michael Barnes, and 382 Manav Bhatia for valuable comments. 384 8. References 386 8.1. Normative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 393 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 394 for OSPFv3", RFC 4552, June 2006. 396 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 397 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 398 Authentication", RFC 5709, October 2009. 400 8.2. Informative References 402 [FIPS180] US National Institute of Standards and Technology, "Secure 403 Hash Standard (SHS)", August 2002. 405 [I-D.hartman-karp-ops-model] 406 Hartman, S. and D. Zhang, "Operations Model for Router 407 Keying", draft-hartman-karp-ops-model-01 (work in 408 progress), October 2010. 410 [I-D.ietf-karp-crypto-key-table] 411 Housley, R. and T. Polk, "Database of Long-Lived Symmetric 412 Cryptographic Keys", draft-ietf-karp-crypto-key-table-00 413 (work in progress), November 2010. 415 [I-D.ietf-karp-design-guide] 416 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 417 Routing Protocols (KARP) Design Guidelines", 418 draft-ietf-karp-design-guide-00 (work in progress), 419 February 2010. 421 [I-D.ietf-karp-threats-reqs] 422 Lebovitz, G., Bhatia, M., and R. White, "The Threat 423 Analysis and Requirements for Cryptographic Authentication 424 of Routing Protocols' Transports", 425 draft-ietf-karp-threats-reqs-01 (work in progress), 426 October 2010. 428 [I-D.ietf-opsec-routing-protocols-crypto-issues] 429 Jaeggli, J., Hares, S., Bhatia, M., Manral, V., and R. 430 White, "Issues with existing Cryptographic Protection 431 Methods for Routing Protocols", 432 draft-ietf-opsec-routing-protocols-crypto-issues-06 (work 433 in progress), June 2010. 435 [I-D.ietf-rpsec-ospf-vuln] 436 Jones, E. and O. Moigne, "OSPF Security Vulnerabilities 437 Analysis", draft-ietf-rpsec-ospf-vuln-02 (work in 438 progress), June 2006. 440 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 441 Digital Signatures", RFC 2154, June 1997. 443 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 444 with Existing Cryptographic Protection Methods for Routing 445 Protocols", RFC 6039, October 2010. 447 Authors' Addresses 449 Sam Hartman 450 Painless Security 452 Email: hartmans-ietf@mit.edu 454 Dacheng Zhang 455 Huawei 457 Email: zhangdacheng@huawei.com