idnits 2.17.1 draft-ietf-karp-ospf-analysis-04.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.) ** There is 1 instance of too long lines in the document, the longest one being 26 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 6, 2012) is 4342 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 463, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-karp-crypto-key-table-02 == Outdated reference: A later version (-10) exists of draft-ietf-karp-ops-model-02 == Outdated reference: A later version (-07) exists of draft-ietf-karp-threats-reqs-05 == Outdated reference: A later version (-11) exists of draft-ietf-ospf-security-extension-manual-keying-02 -- Obsolete informational reference (is this intentional?): RFC 6506 (Obsoleted by RFC 7166) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KARP S. Hartman 3 Internet-Draft Painless Security 4 Intended status: Informational D. Zhang 5 Expires: December 8, 2012 Huawei Technologies co. ltd 6 June 6, 2012 8 Analysis of OSPF Security According to KARP Design Guide 9 draft-ietf-karp-ospf-analysis-04.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 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 8, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements to Meet . . . . . . . . . . . . . . . . . . . 3 58 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4 59 2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Impacts of OSPF Replays . . . . . . . . . . . . . . . . . . . 6 63 4. Gap Analysis and Specific Requirements . . . . . . . . . . . . 8 64 5. Solution Work . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 This document performs the initial analysis of the current state of 75 OSPFv2 and OSPFv3 according to the requirements of [RFC6518]. This 76 draft builds on several previous analysis efforts into routing 77 security. The OPSEC working group put together [RFC6039] an analysis 78 of cryptographic issues with routing protocols. Earlier, the RPSEC 79 working group put together [I-D.ietf-rpsec-ospf-vuln] a detailed 80 analysis of OSPF vulnerabilities. 82 OSPF meets many of the requirements expected from a manually keyed 83 routing protocol. Integrity protection is provided with modern 84 cryptographic algorithms. Algorithm agility is provided: the 85 algorithm can be changed as part of re-keying an interface or peer. 86 Intra-connection re-keying is provided by the specifications, 87 although apparently some implementations have trouble with this in 88 practice. OSPFv2 security does not interfere with prioritization of 89 packets. 91 However, some gaps remain between the current state and the 92 requirements for manually keyed routing security expressed in 93 [I-D.ietf-karp-threats-reqs] the requirements. This document 94 explores these gaps and proposes directions for addressing the gaps. 96 1.1. Requirements to Meet 98 There are a number of requirements described in section 3 of 99 [I-D.ietf-karp-threats-reqs] that OSPF does not currently meet: 101 Secure Simple PSKs: Today, OSPF directly uses the key as 102 specified. Related key attacks such as those described in section 103 4.1 of [I-D.ietf-karp-ops-model] are possible. 105 Replay Protection: OSPFv3 has no replay protection at all. OSPFv2 106 has most of the mechanisms necessary for intra-connection replay 107 protection. Unfortunately, OSPFv2 does not securely identify the 108 neighbor with whom replay protection state is associated in all 109 cases. This weakness can be used to create significant denial-of- 110 service issues using intra-connection replays. OSPFv2 has no 111 inter-connection replay protection; this creates significant 112 denial-of-service opportunities. 114 Packet Prioritization: OSPFv3 uses IPsec to process packets. This 115 complicates implementations that wish to process some packets such 116 as hellos and acknowledgements above others. In addition, if 117 IPsec replay mechanisms were used, packets would need to be 118 processed at least by IPsec even if they were low priority. 120 Neighbor Identification: In some cases, OSPF identifies a neighbor 121 based on the IP address. This is never protected with OSPFv2 and 122 is not typically protected with OSPFv3. 124 The remainder of this document explains the details of how these 125 requirements fail to be met and proposes mechanisms for addressing 126 them. 128 1.2. Requirements notation 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 2. Current State 136 This section describes the security mechanisms built into OSPFv2 and 137 OSPFv3. There are two goals to this section. First, this section 138 gives a brief explanation of the OSPF security mechanisms to those 139 familiar with connectionless integrity mechanisms but not with OSPF. 140 Second, this section explains the background necessary to understand 141 how OSPF fails to meet some of the requirements proposed for routing 142 security. 144 2.1. OSPFv2 146 Appendix D of [RFC2328] describes the basic procedure for 147 cryptographic authentication in OSPFv2. An authentication data field 148 in the OSPF packet header contains a key ID, the length of the 149 authentication data and a sequence number. A message authentication 150 code (MAC) is appended to the OSPF packet. This code protects all 151 fields of the packet including the sequence number but not the IP 152 header. 154 RFC 2328 defined the use of a keyed-MD5 MAC. While MD5 has not been 155 broken as a MAC, it is not the algorithm of choice for new MACs. 157 However, RFC 5709 [RFC5709] adds support for the SHA [FIPS180] family 158 of hashes to OSPFv2. The cryptographic authentication described in 159 RFC 5709 meets modern standards for per-packet integrity protection. 160 Thus, OSPFv2 meets the requirement for strong algorithms. Since 161 multiple algorithms are defined and a new algorithm can be selected 162 with each key, OSPFv2 meets the requirement for algorithm agility. 163 In order to provide cryptographic algorithms believed to have a 164 relatively long useful life, RFC 5709 mandates support for SHA-2 165 rather than SHA-1. 167 These security services provide integrity protection on each packet. 168 In addition, limited replay detection is provided. The sequence 169 number is non-decreasing. So, once a router has increased its 170 sequence number, an attacker cannot replay an old packet. 171 Unfortunately, sequence numbers are not required to increase for each 172 packet. For instance, because existing OSPF security solutions do 173 not specify how to set the sequence number, it is possible that some 174 implementation use, e.g., "seconds since reboot" as their sequence 175 numbers. The sequence numbers is thus only increased by every 176 second. Also, no mechanism is provided to deal with the loss of 177 anti-replay state; if sequence numbers are reused when a router 178 reboots, then inter-connection replays are straight forward. In 179 [I-D.ietf-ospf-security-extension-manual-keying], the OSPFv2 sequence 180 number is expanded to 64-bits with the least significant 32-bit value 181 containing a strictly increasing sequence number and the most 182 significant 32-bit value containing the boot count. The boot count 183 is retained in non-volatile storage for the deployment life of a OSPF 184 router. Therefore, the sequence number will never decrease even 185 after a cold reboot. 187 Also, because the IP header is not protected, the sequence number may 188 not be associated with the right neighbor; this opens up 189 opportunities for outsiders to perform replay attacks. See Section 3 190 for analysis of these attacks. In 191 [I-D.ietf-ospf-security-extension-manual-keying], this issue is 192 addressed by changing the definition of Apad from a constant defined 193 in [RFC5709] to the source address from the IP header of the OSPFv2 194 protocol packet. In this way, the source address from the IP header 195 is incorporated in the cryptographic authentication computation, and 196 any change of the IP source address will be detected. 198 The mechanism provides good support for key rollover. There is a key 199 ID; in addition mechanisms are described for managing key lifetimes 200 and starting the use of a new key in an orderly manner. Performing 201 orderly key rollover requires that implementations support accepting 202 a new key for received packets before using that key to generate 203 packets. Section D.3 of RFC 2328 requires this support in the form 204 of four configurable lifetimes for each key: two lifetimes control 205 the beginning and ending period for acceptance while two lifetimes 206 control the beginning and ending period for generation. This 207 provides a superset of the functionality in the key table 208 [I-D.ietf-karp-crypto-key-table] regarding lifetime. 210 The OSPFv2 replay mechanism does not handle packet priorities as 211 described. If packets are processed out-of-order, then if the 212 sequence number increases, packets processed later will be discarded. 214 2.2. OSPFv3 216 RFC 4552 [RFC4552] describes how the authentication header and 217 encapsulating security payload mechanism can be used to protect 218 OSPFv3 packets. This mechanism provides per-packet integrity and 219 optional confidentiality using a wide variety of cryptographic 220 algorithms. Because OSPF uses multicast traffic, only manual key 221 management is supported. This mechanism meets requirements related 222 to algorithm selection and agility. 224 The Security Parameter Index (SPI) provides an identifier for the 225 security association. This along with other IPsec facilities 226 provides a mechanism for moving from one key to another, meeting the 227 key rollover requirements. 229 Because manual keying is used, no replay protection is provided for 230 OSPFv3. Thus the intra-connection and inter-connection replay 231 requirements are not met. 233 There is another serious problem with the OSPFv3 security: rather 234 than being integrated into OSPF, it is based on IPsec. In practice, 235 this has lead to deployment problems. 237 OSPF implementations generally prioritize packets in order to 238 minimize disruption when router resources such as CPU or memory 239 experience contention. When IPsec is used with OSPFv3, the offset of 240 the packet type, which is used to prioritize packets, depends on what 241 integrity transform is used. For this reason, prioritizing packets 242 may be more complex for OSPFv3. One approach is to establish per-SPI 243 filters to find the packet type and act accordingly. 245 3. Impacts of OSPF Replays 247 As discussed, neither version of OSPF meets the requirements of 248 inter-connection or intra-connection replay protection. This section 249 discusses the impacts of OSPF replays. 251 In OSPFv2, two facilities limit the scope of replay attacks. First, 252 when cryptographic authentication is used, each packet includes a 253 sequence number that is non-decreasing. In the current 254 specifications, the sequence number is remembered as part of an 255 adjacency: if an attacker can cause an adjacency to go down, then 256 replay state is lost. Database Description packets also include a 257 per-LSA sequence number that is part of the information that is 258 flooded. Even if a packet is replayed, the per-LSA sequence number 259 will prevent an old LSA from being installed. Unlike the per-packet 260 sequence number, the per-LSA sequence number must increase when an 261 LSA is changed. As a result, replays cannot be used to install old 262 routing information. 264 While the LSA sequence number provides some defense, there are a 265 number of attacks that are possible because of a per-packet replay. 266 The RPSEC analysis [I-D.ietf-rpsec-ospf-vuln] describes a number of 267 attacks that are possible because of per-packet replays. The most 268 serious appear to be attacks against Hello packets, which may cause 269 an adjacency to fail. Other attacks may cause excessive flooding or 270 excessive use of CPU. 272 Another serious attack concerns Database Description packets. In 273 addition to the per-packet sequence number that is part of 274 cryptographic authentication for OSPFv2 and the per-LSA sequence 275 numbers, Database Description packets also include a Database 276 Description sequence number. If a Database Description packet with 277 the incorrect sequence number is received, then the database exchange 278 process will be restarted. 280 The per-packet OSPFv2 sequence number can be used to reduce the 281 window in which a replay is valid. A receiver will harmlessly reject 282 a packet whose per-packet sequence number is older than the one most 283 recently received from a neighbor. Replaying the most recent packet 284 from a neighbor does not appear to create problems. So, if the per- 285 packet sequence number is incremented on every packet sent, then 286 replay attacks should not disrupt OSPFv2. Unfortunately, OSPFv2 does 287 not have a procedure for dealing with sequence numbers reaching the 288 maximum age. It may be possible to figure out a set of rules 289 sufficient to disrupt the damage of packet replays while minimizing 290 the use of the sequence number space. 292 As mentioned previously, when an adjacency is dropped, replay state 293 is lost. So, after rebooting or when all adjacencies are lost, a 294 router may allow its sequence number to decrease. An attacker can 295 cause significant damage by replaying a packet captured before the 296 sequence number decrease at a time after the sequence number 297 decrease. If this happens, then the replayed packet will be accepted 298 and the sequence number will be updated. However, the legitimate 299 sender will be using a lower sequence number, so legitimate packets 300 will be rejected. A similar attack is possible in cases where OSPF 301 identifies a neighbor based on source address. An attacker can 302 change the source address of a captured packet and replay it. If the 303 attacker causes a replay from a neighbor with a high sequence number 304 to appear to be from a low sequence number neighbor, then 305 connectivity with that neighbor will be disrupted until the adjacency 306 fails. 308 OSPFv3 lacks the per-packet sequence number but has the per-LSA 309 sequence number. As such, OSPFv3 has no defense against denial of 310 service attacks that exploit replay. 312 4. Gap Analysis and Specific Requirements 314 The design guide requires each design team to enumerate a set of 315 requirements for the routing protocol. The only concerns identified 316 with OSPF are areas where it fails to meet general requirements 317 outlined in the threats and requirements document. This section 318 explains how some of these general requirements map specifically onto 319 the OSPF protocol and enumerates the specific gaps that need to be 320 addressed. 322 There is a general requirement for inter-connection replay 323 protection. In the context of OSPF, this means that if an adjacency 324 goes down between two neighbors and later is re-established, 325 replaying packets from before the adjacency went down cannot disrupt 326 the adjacency. In the context of OSPF, intra-connection replay 327 protection means that replaying a packet cannot prevent an adjacency 328 from forming or disrupt an adjacency. Meeting the requirements for 329 intra-connection and inter-connection replay protection is a 330 significant gap between the optimal state and where OSPF is today. 332 Since OSPF uses fields in the IP header, the general requirement to 333 protect the IP header and handle neighbor identification applies. 334 This is another gap that needs to be addressed. Because the replay 335 protection will depend on neighbor identification, the replay 336 protection cannot be adequately addressed without handling this issue 337 as well. 339 In order to encourage deployment of OSPFv3 security, an 340 authentication option is required that does not have the deployment 341 challenges of IPsec. 343 In order to support the requirement for simple preshared keys, OSPF 344 needs to make sure that when the same key is used for two different 345 purposes, no problems result. 347 In order to support packet prioritization, the information needed to 348 prioritize OSPF packets (the packet type) MUST be at a constant 349 location in the packet. 351 5. Solution Work 353 A security solution will be developed for OSPFv2 and OSPFv3 based on 354 the OSPFv2 cryptographic authentication option. This solution will 355 have the following improvements over the existing OSPFv2 option: 357 Address most inter-connection replay attacks by splitting the 358 sequence number and requiring preservation of state so that the 359 sequence number increases on every packet. 361 Add a form of simple key derivation so that if the same preshared 362 key is used for OSPF and other purposes, cross-protocol attacks do 363 not result 365 Support OSPFv3 authentication without use of IPsec 367 Specify processing rules sufficient to permit replay detection and 368 packet prioritization 370 Emphasize requirements already present in the OSPF specification 371 sufficient to permit key migration without disrupting adjacencies 373 Specify the proper use of the key table for OSPF 375 Protect the source IP address 377 Require that sequence numbers be incremented on each packet 379 The key components of this solution work are already underway. 380 OSPFv3 now supports an authentication option [RFC6506] that meets the 381 requirements of this section, except that it does not describe how 382 the key tables are used for OSPF. OSPFv2 is being enhanced 383 [I-D.ietf-ospf-security-extension-manual-keying] to protect the 384 source address, provide inter-connection replay and describe how to 385 use the key table. 387 6. Security Considerations 389 This memo discusses and compiles vulnerabilities in the existing OSPF 390 cryptographic handling. 392 In analyzing proposed improvements to OSPF per-packet security, it is 393 desirable to consider how these improvements interact with potential 394 improvements in overall routing security. For example, the impact of 395 replay attacks currently depends on the LSA sequence number 396 mechanism. If cryptographic protections against insider attackers 397 are considered by future work, then that work will need to provide a 398 solution that meets the needs of the per-packet replay defense as 399 well as protection of routing data from insider attack. RFC 2154 400 [RFC2154] provides an experimental solution for end-to-end protection 401 of routing data in OSPF. It may be beneficial to consider how 402 improvements to the per-packet protections would interact with such a 403 mechanism to future-proof these mechanisms. 405 Implementations have a number of options in minimizing the potential 406 denial of service impact of OSPF cryptographic authentication. The 407 Generalized TTL Security Mechanism (GTSM) [RFC5082] might be 408 appropriate for OSPF packets other than those traversing virtual 409 links. Using this mechanism requires support of the sender; new OSPF 410 cryptographic authentication could specify this behavior if desired. 411 Alternatively implementations can limit the source addresses from 412 which they accept packets. Non-hello packets need only be accepted 413 from existing neighbors. If a system is under attack hello packets 414 from existing neighbors could be prioritized over hellos from new 415 neighbors. These mechanisms can be considered to limit the potential 416 impact of denial of service attacks on the cryptographic 417 authentication mechanism itself. 419 7. Acknowledgements 421 Funding for Sam Hartman's work on this memo is provided by Huawei. 423 The authors would like to thank Ran Atkinson, Michael Barnes, and 424 Manav Bhatia for valuable comments. 426 8. References 428 8.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, March 1997. 433 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 435 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 436 for OSPFv3", RFC 4552, June 2006. 438 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 439 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 440 Authentication", RFC 5709, October 2009. 442 8.2. Informative References 444 [FIPS180] US National Institute of Standards and Technology, "Secure 445 Hash Standard (SHS)", August 2002. 447 [I-D.ietf-karp-crypto-key-table] 448 Housley, R. and T. Polk, "Database of Long-Lived Symmetric 449 Cryptographic Keys", draft-ietf-karp-crypto-key-table-02 450 (work in progress), October 2011. 452 [I-D.ietf-karp-ops-model] 453 Hartman, S. and D. Zhang, "Operations Model for Router 454 Keying", draft-ietf-karp-ops-model-02 (work in progress), 455 April 2012. 457 [I-D.ietf-karp-threats-reqs] 458 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 459 Routing Protocols (KARP) Overview, Threats, and 460 Requirements", draft-ietf-karp-threats-reqs-05 (work in 461 progress), May 2012. 463 [I-D.ietf-opsec-routing-protocols-crypto-issues] 464 Jaeggli, J., Hares, S., Bhatia, M., Manral, V., and R. 465 White, "Issues with existing Cryptographic Protection 466 Methods for Routing Protocols", 467 draft-ietf-opsec-routing-protocols-crypto-issues-07 (work 468 in progress), August 2010. 470 [I-D.ietf-ospf-security-extension-manual-keying] 471 Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, 472 "Security Extension for OSPFv2 when using Manual Key 473 Management", 474 draft-ietf-ospf-security-extension-manual-keying-02 (work 475 in progress), April 2012. 477 [I-D.ietf-rpsec-ospf-vuln] 478 Jones, E. and O. Moigne, "OSPF Security Vulnerabilities 479 Analysis", draft-ietf-rpsec-ospf-vuln-02 (work in 480 progress), June 2006. 482 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 483 Digital Signatures", RFC 2154, June 1997. 485 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 486 Pignataro, "The Generalized TTL Security Mechanism 487 (GTSM)", RFC 5082, October 2007. 489 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 490 with Existing Cryptographic Protection Methods for Routing 491 Protocols", RFC 6039, October 2010. 493 [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting 494 Authentication Trailer for OSPFv3", RFC 6506, 495 February 2012. 497 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 498 Routing Protocols (KARP) Design Guidelines", RFC 6518, 499 February 2012. 501 Authors' Addresses 503 Sam Hartman 504 Painless Security 506 Email: hartmans-ietf@mit.edu 507 URI: http://www.painless-security.com/ 509 Dacheng Zhang 510 Huawei Technologies co. ltd 511 Huawei Building No.3 Xinxi Rd., Shang-Di Information Industrial Base Hai-Dian District, Beijing 512 China 514 Email: zhangdacheng@huawei.com