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