idnits 2.17.1 draft-ietf-ospf-security-extension-manual-keying-11.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 draft header indicates that this document updates RFC2328, but the abstract doesn't seem to directly say this. It does mention RFC2328 though, so this could be OK. -- The draft header indicates that this document updates RFC5709, but the abstract doesn't seem to directly say this. It does mention RFC5709 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2328, updated by this document, for RFC5378 checks: 1997-11-05) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 7, 2014) is 3456 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2574 (Obsoleted by RFC 3414) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group M. Bhatia 3 Internet-Draft Ionos Networks 4 Updates: 2328, 5709 S. Hartman 5 (if approved) Painless Security 6 Intended status: Standards Track D. Zhang 7 Expires: May 11, 2015 Huawei Technologies co., LTD. 8 A. Lindem, Ed. 9 Cisco 10 November 7, 2014 12 Security Extension for OSPFv2 when using Manual Key Management 13 draft-ietf-ospf-security-extension-manual-keying-11 15 Abstract 17 The current OSPFv2 cryptographic authentication mechanism as defined 18 in RFC 2328 and RFC 5709 is vulnerable to both inter-session and 19 intra-session replay attacks when using manual keying. Additionally, 20 the existing cryptographic authentication mechanism does not cover 21 the IP header. This omission can be exploited to carry out various 22 types of attacks. 24 This document defines changes to the authentication sequence number 25 mechanism that will protect OSPFv2 from both inter-session and intra- 26 session replay attacks when using manual keys for securing OSPFv2 27 protocol packets. Additionally, we also describe some changes in the 28 cryptographic hash computation that will eliminate attacks resulting 29 from OSPFv2 not protecting the IP header. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 11, 2015. 48 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 3 66 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 67 2. Replay Protection using Extended Sequence Numbers . . . . . . 4 68 3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . . 5 69 4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6 70 4.1. Key Selection for Unicast OSPF Packet Transmission . . . . 7 71 4.2. Key Selection for Multicast OSPF Packet Transmission . . . 8 72 4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8 73 5. Securing the IP header . . . . . . . . . . . . . . . . . . . . 9 74 6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9 75 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 The OSPFv2 cryptographic authentication mechanism as described in 86 [RFC2328] uses per-packet sequence numbers to provide protection 87 against replay attacks. The sequence numbers increase monotonically 88 so that attempts to replay stale packets can be thwarted. The 89 sequence number values are maintained as a part of neighbor adjacency 90 state. Therefore, if an adjacency is taken down, the associated 91 sequence numbers get reinitialized and neighbor adjacency formation 92 starts over again. Additionally, the cryptographic authentication 93 mechanism does not specify how to deal with the rollover of a 94 sequence number when its value wraps. These omissions can be 95 exploited by attackers to implement various replay attacks 96 ([RFC6039]). In order to address these issues, we define extensions 97 to the authentication sequence number mechanism. 99 The cryptographic authentication as described in [RFC2328] and later 100 updated in [RFC5709] does not include the IP header. This omission 101 can be exploited to launch several attacks as the source address in 102 the IP header is not protected. The OSPF specification, for 103 broadcast and NBMA (Non-Broadcast Multi-Access Networks), requires 104 implementations to use the source address in the IP header to 105 determine the neighbor from which the packet was received. Changing 106 the IP source address of a packet to a conflicting IP address can be 107 exploited to produce a number of denial of service attacks [RFC6039]. 108 If the packet is interpreted as coming from a different neighbor, the 109 received sequence number state for that neighbor may be incorrectly 110 updated. This attack may disrupt communication with a legitimate 111 neighbor. Hello packets may be reflected to cause a neighbor to 112 appear to have one-way communication. Additionally, Database 113 Description packets may be reflected in cases where the per-packet 114 sequence numbers are sufficiently divergent in order to disrupt an 115 adjacency [RFC6863]. This is referred to as the IP layer issue in 116 [RFC6862]. 118 [RFC2328] states that implementations MUST offer keyed MD5 119 authentication. It is likely that this will be deprecated in favor 120 of the stronger algorithms described in [RFC5709] and required in 121 [RFC6094]. 123 This document defines a few simple changes to the cryptographic 124 authentication mechanism, as currently described in [RFC5709], to 125 prevent such IP layer attacks. 127 1.1. Requirements Section 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC2119 [RFC2119]. 133 When used in lowercase, these words convey their typical use in 134 common language, and are not to be interpreted as described in 135 RFC2119 [RFC2119]. 137 1.2. Acknowledgments 139 Thanks to Ran Atkinson for help in the analysis of RFC 6506 errata 140 leading to clarifications in this document. 142 Thanks to Gabi Nakibly for pointing out a possible attack on p2p 143 links. 145 Thanks to Suresh Krishnan for comments made during the Gen-Art 146 review. In particular, thanks for pointing out an ambiguity in the 147 initialization of Apad. 149 Thanks to Shaun Cooley for the security directorate review. 151 Thanks to Adrian Farrel for comments during the IESG last call. 153 2. Replay Protection using Extended Sequence Numbers 155 In order to provide replay protection against both inter-session and 156 intra-session replay attacks, the OSPFv2 sequence number is expanded 157 to 64-bits with the least significant 32-bit value containing a 158 strictly increasing sequence number and the most significant 32-bit 159 value containing the boot count. OSPFv2 implementations are required 160 to retain the boot count in non-volatile storage for the deployment 161 life the OSPF router. The requirement to preserve the boot count is 162 also placed on SNMP agents by the SNMPv3 security architecture (refer 163 to snmpEngineBoots in section 2.2 of [RFC2574]). 165 Since there is no room in the OSPFv2 packet for a 64-bit sequence 166 number, it will occupy the 8 octets following the OSPFv2 packet and 167 MUST be included when calculating the OSPFv2 packet digest. These 168 additional 8 octets are not included in the OSPFv2 packet header 169 length but are included in the OSPFv2 header Authentication Data 170 length and the IPv4 packet header length. 172 The lower order 32-bit sequence number MUST be incremented for every 173 OSPF packet sent by the OSPF router. Upon reception, the sequence 174 number MUST be greater than the sequence number in the last OSPF 175 packet of that type accepted from the sending OSPF neighbor. 176 Otherwise, the OSPF packet is considered a replayed packet and 177 dropped. OSPF packets of different types may arrive out of order if 178 they are prioritized as recommended in [RFC4222]. 180 OSPF routers implementing this specification MUST use available 181 mechanisms to preserve the sequence number's strictly increasing 182 property for the deployed life of the OSPFv2 router (including cold 183 restarts). This is achieved by maintaining a boot count in non- 184 volatile storage and incrementing it each time the OSPF router loses 185 its prior sequence number state. The SNMPv3 snmpEngineBoots variable 186 [RFC2574] MAY be used for this purpose. However, maintaining a 187 separate boot count solely for OSPF sequence numbers has the 188 advantage of decoupling SNMP reinitialization and OSPF 189 reinitialization. Also, in the rare event that the lower order 32- 190 bit sequence number wraps, the boot count can be incremented to 191 preserve the strictly increasing property of the aggregate sequence 192 number. Hence, a separate OSPF boot count is RECOMMENDED. 194 3. OSPF Packet Extensions 196 The OSPF packet header includes an authentication type field, and 64- 197 bits of data for use by the appropriate authentication scheme 198 (determined by the type field). Authentication types 0, 1 and 2 are 199 defined [RFC2328]. This section defines Authentication type TBD (3 200 is recommended). 202 When using this authentication scheme, the 64-bit Authentication 203 field in the OSPF packet header as defined in section D.3 of 204 [RFC2328] and [RFC6549] is changed as shown below. The sequence 205 number is removed and the Key ID is extended to 32 bits and moved to 206 the former position of the sequence number. 208 Additionally, the 64-bit sequence number is moved to the first 64- 209 bits following the OSPFv2 packet and is protected by the 210 authentication digest. These additional 64 bits or 8 octets are 211 included in the IP header length but not the OSPF header packet 212 length. 214 Finally, the 0 field at the start of the OSPFv2 header authentication 215 is extended from 16 bits to 24 bits. 217 0 1 2 3 218 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Version # | Type | Packet length | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Router ID | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Area ID | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Checksum | Instance ID | AuType | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | 0 | Auth Data Len | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Key ID | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | 233 | OSPF Protocol Packet | 234 ~ ~ 235 | | 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Sequence Number (Boot Count) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Sequence Number (Strictly Increasing Packet Counter) | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 ~ Authentication Data ~ 244 | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 1 - Extended Sequence Number Packet Extensions 249 4. OSPF Packet Key Selection 251 This section describes how this security solution selects long-lived 252 keys from key tables. [RFC7210]. In this context, we are selecting 253 the key and corresponding Security Association (SA) as defined in 254 section 3.2 of [RFC5709]. Generally, a key used for OSPFv2 packet 255 authentication should satisfy the following requirements: 257 o For packet transmission, the key validity interval as defined by 258 SendLifetimeStart and SendLifetimeEnd must include the current 259 time. 261 o For packet reception, the key validity interval as defined by 262 AcceptLifetimeStart and AcceptLifetimeEnd must include the current 263 time. 265 o The key must be valid for the desired security algorithm. 267 In the remainder of this section, additional requirements for keys 268 are enumerated for different scenarios. 270 4.1. Key Selection for Unicast OSPF Packet Transmission 272 Assume that a router R1 tries to send a unicast OSPF packet from its 273 interface I1 to the interface I2 of a remote router R2 using security 274 protocol P via interface I at time T. First, consider the 275 circumstances where R1 and R2 are not connected with a virtual link. 276 R1 then needs to select a long long-lived symmetric key from its key 277 table. Because the key should be shared by both R1 and R2 to protect 278 the communication between I1 and I2, the key should satisfy the 279 following requirements: 281 o The Peers field is unused. OSPF authentication is interface 282 based. 284 o The Interfaces field includes the local IP address of the 285 interface for numbered interfaces or the MIB-II [RFC1213] ifIndex 286 for unnumbered interfaces. 288 o The Direction field is either "out" or "both". 290 o If multiple keys match the Interfaces field, the key with the most 291 recent SendLifetimeStart time will be selected. This will 292 facilitate graceful key rollover. 294 o The Key ID field in the OSPFv2 header (refer to figure 1) will be 295 set to the selected key's LocalKeyName. 297 When R1 and R2 are connected to a virtual link, the Interfaces field 298 must identify the virtual endpoint rather than the virtual link. 299 Since there may be virtual links to the same router, the transit area 300 ID must be part of the identifier. Hence, the key should satisfy the 301 following requirements: 303 o The Peers field is unused. OSPF authentication is interface 304 based. 306 o The Interfaces field includes both the virtual endpoint's OSPF 307 router ID and the transit area ID for the virtual link. 309 o The Direction field is either "out" or "both". 311 o If multiple keys match the Interfaces field, the key with the most 312 recent SendLifetimeStart time will be selected. This will 313 facilitate graceful key rollover. 315 o The Key ID field in the OSPFv2 header (refer to figure 1) will be 316 set to the selected key's LocalKeyName. 318 4.2. Key Selection for Multicast OSPF Packet Transmission 320 If a router R1 sends an OSPF packet from its interface I1 to a 321 multicast address (i.e., AllSPFRouters or AllDRouters), it needs to 322 select a key according to the following requirements: 324 o The Peers field is unused. OSPF authentication is interface 325 based. 327 o The Interfaces field includes the local IP address of the 328 interface for numbered interfaces or the MIB-II [RFC1213] ifIndex 329 for unnumbered interfaces. 331 o The Direction field is either "out" or "both". 333 o If multiple keys match the Interfaces field, the key with the most 334 recent SendLifetimeStart time will be selected. This will 335 facilitate graceful key rollover. 337 o The Key ID field in the OSPFv2 header (refer to figure 1) will be 338 set to the selected key's LocalKeyName. 340 4.3. Key Selection for OSPF Packet Reception 342 When Cryptographic Authentication is used, the ID of the 343 authentication key is included in the authentication field of the 344 OSPF packet header. Using this Key ID, it is straight forward for a 345 receiver to locate the corresponding key. The simple requirements 346 are: 348 o The interface on which the key was received is associated with the 349 key's interface. 351 o The Key ID obtained from the OSPFv2 packet header corresponds to 352 the neighbor's PeerKeyName. Since OSPFv2 keys are symmetric, the 353 LocalKeyName and PeerKeyName for OSPFv2 keys will be identical. 354 Hence, the Key ID will be used to select the correct local key. 356 o The Direction field is either "in" or "both". 358 5. Securing the IP header 360 This document updates the definition of the Apad constant, as it is 361 defined in [RFC5709], to include the IP source address from the IP 362 header of the OSPFv2 protocol packet. The overall cryptographic 363 authentication process defined in [RFC5709] remains unchanged. To 364 reduce the potential for confusion, this section minimizes the 365 repetition of text from RFC 5709 [RFC5709]. The changes are: 367 RFC 5709, Section 3.3, describes how the cryptographic authentication 368 must be computed. In RFC 5709, the First-Hash includes the OSPF 369 packet and Authentication Trailer. With this specification, the 64- 370 bit sequence number will be included in the First-Hash along with the 371 Authentication Trailer and OSPF packet. 373 RFC 5709, Section 3.3 also requires the OSPFv2 packet's 374 Authentication Trailer (which is the appendage described in RFC 2328, 375 Section D.4.3, Page 233, items (6)(a) and (6)(d)) to be filled with 376 the value Apad. Apad is a hexadecimal constant with the value 377 0x878FE1F3 repeated (L/4) times, where L is the length of the hash 378 being used and is measured in octets rather than bits. 380 OSPF routers sending OSPF packets must initialize the first 4 octets 381 of Apad to the value of the IP source address that would be used when 382 sending the OSPFv2 packet. The remainder of Apad will contain the 383 value 0x878FE1F3 repeated (L - 4)/4 times, where L is the length of 384 the hash, measured in octets. The basic idea is to incorporate the 385 IP source address from the IP header in the cryptographic 386 authentication computation so that any change of IP source address in 387 a replayed packet can be detected. 389 When an OSPF packet is received, implementations MUST initialize Apad 390 as the IP source address from the IP Header of the incoming OSPFv2 391 packet, repeated L/4 times, instead of the constant that's currently 392 defined in [RFC5709]. Besides changing the value of Apad, this 393 document does not introduce any other changes to the authentication 394 mechanism described in [RFC5709]. This would prevent all attacks 395 where a rogue OSPF router changes the IP source address of an OSPFv2 396 packet and replays it on the same multi-access interface or another 397 interface since the IP source address is now included in the 398 cryptographic hash computation and modification would result in the 399 OSPFv2 packet being dropped due to an authentication failure. 401 6. Mitigating Cross-Protocol Attacks 403 In order to prevent cross-protocol replay attacks for protocols 404 sharing common keys, the two octet OSPFv2 Cryptographic Protocol ID 405 is appended to the authentication key prior to use. Refer to IANA 406 Considerations (Section 9). 408 [RFC5709], Section 3.3 describes the mechanism to prepare the key 409 used in the hash computation. This document updates the sub section 410 "PREPARATION OF KEY" as follows: 412 The OSPFv2 Cryptographic Protocol ID is appended to the 413 Authentication Key (K) yielding a Protocol-Specific Authentication 414 Key (Ks). In this application, Ko is always L octets long. While 415 [RFC2104] supports a key that is up to B octets long, this 416 application uses L as the Ks length consistent with [RFC4822], 417 [RFC5310], and [RFC5709]. According to [FIPS-198], Section 3, keys 418 greater than L octets do not significantly increase the function 419 strength. Ks is computed as follows: 421 If the Protocol-Specific Authentication Key (Ks) is L octets long, 422 then Ko is equal to Ks. If the Protocol-Specific Authentication Key 423 (Ks) is more than L octets long, then Ko is set to H(Ks). If the 424 Protocol-Specific Authentication Key (Ks) is less than L octets long, 425 then Ko is set to the Protocol-Specific Authentication Key (Ks) with 426 zeros appended to the end of the Protocol-Specific Authentication Key 427 (Ks) such that Ko is L octets long. 429 Once the cryptographic key (Ko) used with the hash algorithm is 430 derived the rest of the authentication mechanism described in 431 [RFC5709] remains unchanged other than one detail that was 432 unspecified. When XORing Ko and Ipad of Opad, Ko MUST be padded with 433 zeros to the length of Ipad or Opad. It is expected that RFC 5709 434 [RFC5709] implementations perform this padding implicitly. 436 7. Backward Compatibility 438 This security extension uses a new authentication type, AuType in the 439 OSPFv2 header (refer to figure 1). When an OSPFv2 packet is received 440 and the AuType doesn't match the configured authentication type for 441 the interface, the OSPFv2 packet will be dropped as specified in RFC 442 2328 [RFC2328]. This guarantees backward compatible behavior 443 consistent with any other authentication type mismatch. 445 8. Security Considerations 447 This document rectifies the manual key management procedure that 448 currently exists within OSPFv2, as part of the Phase 1 of the KARP 449 Working Group. Therefore, only the OSPFv2 manual key management 450 mechanism is considered. Any solution that takes advantage of the 451 automatic key management mechanism is beyond the scope of this 452 document. 454 The described sequence number extension offers most of the benefits 455 of more complicated mechanisms without their attendant challenges. 456 There are, however, a couple drawbacks to this approach. First, it 457 requires the OSPF implementation to be able to save its boot count in 458 non-volatile storage. If the non-volatile storage is ever repaired 459 or upgraded such that the contents are lost or the OSPFv2 router is 460 replaced, the authentication keys MUST be changed to prevent replay 461 attacks. 463 Second, if a router is taken out of service completely (either 464 intentionally or due to a persistent failure), the potential exists 465 for reestablishment of an OSPFv2 adjacency by replaying the entire 466 OSPFv2 session establishment. However, this scenario is extremely 467 unlikely, since it would imply an identical OSPFv2 adjacency 468 formation packet exchange. Without adjacency formation, the replay 469 of OSPFv2 hello packets alone for an OSPFv2 router that has been 470 taken out of service should not result in any serious attack as the 471 only consequence is superfluous processing. Of course, this attack 472 could also be thwarted by changing the relevant manual keys. 474 This document also provides a solution to prevent certain denial of 475 service attacks that can be launched by changing the source address 476 in the IP header of an OSPFv2 protocol packet. 478 Using a single crypto sequence number can leave the router vulnerable 479 to a replay attack where it uses the same source IP address on two 480 different point-to-point unnumbered links. In such environments 481 where an attacker can actively tap the point-to-point links, its 482 recommended that the user employs different keys on each of those 483 unnumbered IP interfaces. 485 9. IANA Considerations 487 This document requests a new code point from the "OSPF Shortest Path 488 First (OSPF) Authentication Codes" registry: 490 o 3 - Cryptographic Authentication with Extended Sequence Numbers. 492 This document also requests a new code point from the "Authentication 493 Cryptographic Protocol ID" registry defined under "Keying and 494 Authentication for Routing Protocols (KARP) Parameters": 496 o TBD (3 Suggested) - OSPFv2. 498 10. References 500 10.1. Normative References 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, March 1997. 505 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 507 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 508 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 509 Authentication", RFC 5709, October 2009. 511 10.2. Informative References 513 [FIPS-198] 514 US National Institute of Standards & Technology, "The 515 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 516 198 , March 2002. 518 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 519 for Network Management of TCP/IP-based internets:MIB-II", 520 STD 17, RFC 1213, March 1991. 522 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 523 Hashing for Message Authentication", RFC 2104, 524 February 1997. 526 [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model 527 (USM) for version 3 of the Simple Network Management 528 Protocol (SNMPv3)", RFC 2574, April 1999. 530 [RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF 531 Version 2 Packets and Congestion Avoidance", BCP 112, 532 RFC 4222, October 2005. 534 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 535 Authentication", RFC 4822, February 2007. 537 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 538 and M. Fanto, "IS-IS Generic Cryptographic 539 Authentication", RFC 5310, February 2009. 541 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 542 with Existing Cryptographic Protection Methods for Routing 543 Protocols", RFC 6039, October 2010. 545 [RFC6094] Bhatia, M. and V. Manral, "Summary of Cryptographic 546 Authentication Algorithm Implementation Requirements for 547 Routing Protocols", RFC 6094, February 2011. 549 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 550 Instance Extensions", RFC 6549, March 2012. 552 [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 553 Authentication for Routing Protocols (KARP) Overview, 554 Threats, and Requirements", RFC 6862, March 2013. 556 [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security 557 According to the Keying and Authentication for Routing 558 Protocols (KARP) Design Guide", RFC 6863, March 2013. 560 [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, 561 "Database of Long-Lived Symmetric Cryptographic Keys", 562 RFC 7210, April 2014. 564 Authors' Addresses 566 Manav Bhatia 567 Ionos Networks 568 Bangalore, 569 India 571 Email: manav@ionosnetworks.com 573 Sam Hartman 574 Painless Security 576 Email: hartmans@painless-security.com 578 Dacheng Zhang 579 Huawei Technologies co., LTD. 580 Beijing, 581 China 583 Email: zhangdacheng@huawei.com 584 URI: 586 Acee Lindem (editor) 587 Cisco 588 USA 590 Email: acee@cisco.com