idnits 2.17.1 draft-ietf-ospf-security-extension-manual-keying-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 8, 2014) is 3671 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group M. Bhatia 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track S. Hartman 5 Expires: October 10, 2014 Painless Security 6 D. Zhang 7 Huawei Technologies co., LTD. 8 A. Lindem 9 Ericsson 10 April 8, 2014 12 Security Extension for OSPFv2 when using Manual Key Management 13 draft-ietf-ospf-security-extension-manual-keying-07 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 draft proposes 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 October 10, 2014. 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. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 The OSPFv2 cryptographic authentication mechanism as described in 85 [RFC2328] uses per-packet sequence numbers to provide protection 86 against replay attacks. The sequence numbers increase monotonically 87 so that attempts to replay stale packets can be thwarted. The 88 sequence number values are maintained as a part of neighbor adjacency 89 state. Therefore, if an adjacency is taken down, the associated 90 sequence numbers get reinitialized and neighbor adjacency formation 91 starts over again. Additionally, the cryptographic authentication 92 mechanism does not specify how to deal with the rollover of a 93 sequence number when its value wraps. These omissions can be 94 exploited by attackers to implement various replay attacks 95 ([RFC6039]). In order to address these issues, we propose extensions 96 to the authentication sequence number mechanism. 98 The cryptographic authentication as described in [RFC2328] and later 99 updated in [RFC5709] does not include the IP header. This omission 100 can be exploited to launch several attacks as the source address in 101 the IP header is not protected. The OSPF specification, for 102 broadcast and NBMA (Non-Broadcast Multi-Access Networks), requires 103 implementations to use the source address in the IP header to 104 determine the neighbor from which the packet was received. Changing 105 the IP source address of a packet to a conflicting IP address can be 106 exploited to produce a number of denial of service attacks [RFC6039]. 107 If the packet is interpreted as coming from a different neighbor, the 108 received sequence number state for that neighbor may be incorrectly 109 updated. This attack may disrupt communication with a legitimate 110 neighbor. Hello packets may be reflected to cause a neighbor to 111 appear to have one-way communication. Additionally, Database 112 Description packets may be reflected in cases where the per-packet 113 sequence numbers are sufficiently divergent in order to disrupt an 114 adjacency [RFC6863]. This is referred to as the IP layer issue in 115 [RFC6862]. 117 [RFC2328] states that implementations MUST offer keyed MD5 118 authentication. It is likely that this will be deprecated in favor 119 of the stronger algorithms described in [RFC5709] and required in 120 [RFC6094]. 122 This draft proposes a few simple changes to the cryptographic 123 authentication mechanism, as currently described in [RFC5709], to 124 prevent such IP layer attacks. 126 1.1. Requirements Section 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC2119 [RFC2119]. 132 When used in lowercase, these words convey their typical use in 133 common language, and are not to be interpreted as described in 134 RFC2119 [RFC2119]. 136 1.2. Acknowledgments 138 Thanks to Ran Atkinson for help in the analysis of RFC 6506 errata 139 leading to clarifications in this document. 141 2. Replay Protection using Extended Sequence Numbers 143 In order to provide replay protection against both inter-session and 144 intra-session replay attacks, the OSPFv2 sequence number is expanded 145 to 64-bits with the least significant 32-bit value containing a 146 strictly increasing sequence number and the most significant 32-bit 147 value containing the boot count. OSPFv2 implementations are required 148 to retain the boot count in non-volatile storage for the deployment 149 life the OSPF router. The requirement to preserve the boot count is 150 also placed on SNMP agents by the SNMPv3 security architecture (refer 151 to snmpEngineBoots in [RFC4222]). 153 Since there is no room in the OSPFv2 packet for a 64-bit sequence 154 number, it will occupy the 8 octets following the OSPFv2 packet and 155 MUST be included when calculating the OSPFv2 packet digest. These 156 additional 8 bytes are not included in the OSPFv2 packet header 157 length but are included in the OSPFv2 header Authentication Data 158 length and the IPv4 packet header length. 160 The lower order 32-bit sequence number MUST be incremented for every 161 OSPF packet sent by the OSPF router. Upon reception, the sequence 162 number MUST be greater than the sequence number in the last OSPF 163 packet of that type accepted from the sending OSPF neighbor. 164 Otherwise, the OSPF packet is considered a replayed packet and 165 dropped. OSPF packets of different types may arrive out of order if 166 they are prioritized as recommended in [RFC3414]. 168 OSPF routers implementing this specification MUST use available 169 mechanisms to preserve the sequence number's strictly increasing 170 property for the deployed life of the OSPFv3 router (including cold 171 restarts). This is achieved by maintaining a boot count in non- 172 volatile storage and incrementing it each time the OSPF router loses 173 its prior sequence number state. The SNMPv3 snmpEngineBoots variable 174 [RFC4222] MAY be used for this purpose. However, maintaining a 175 separate boot count solely for OSPF sequence numbers has the 176 advantage of decoupling SNMP reinitialization and OSPF 177 reinitialization. Also, in the rare event that the lower order 32- 178 bit sequence number wraps, the boot count can be incremented to 179 preserve the strictly increasing property of the aggregate sequence 180 number. Hence, a separate OSPF boot count is RECOMMENDED. 182 3. OSPF Packet Extensions 184 The OSPF packet header includes an authentication type field, and 64- 185 bits of data for use by the appropriate authentication scheme 186 (determined by the type field). Authentication types 0, 1 and 2 are 187 defined [RFC2328]. This section of this defines Authentication type 188 TBD (3 is recommended). 190 When using this authentication scheme, the 64-bit Authentication 191 field in the OSPF packet header as defined in section D.3 of 192 [RFC2328] is changed as shown below. The sequence number is removed 193 and the Key ID is extended to 32 bits and moved to the former 194 position of the sequence number. 196 Additionally, the 64-bit sequence number is moved to the first 64- 197 bits following the OSPFv2 packet and is protected by the 198 authentication digest. These additional 64 bits or 8 octets are 199 included in the IP header length but not the OSPF header packet 200 length. 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Version # | Type | Packet length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Router ID | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Area ID | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Checksum | AuType | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | 0 | Auth Data Len | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Key ID | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | | 218 | OSPF Protocol Packet | 219 ~ ~ 220 | | 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Sequence Number (Boot Count) | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Sequence Number (Strictly Increasing Packet Counter) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | 228 ~ Authentication Data ~ 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 1 - Extended Sequence Number Packet Extensions 234 4. OSPF Packet Key Selection 236 This section describes how the proposed security solution selects 237 long-lived keys from key tables. [I-D.ietf-karp-crypto-key-table]. 238 Generally, a key used for OSPFv2 packet authentication should satisfy 239 the following requirements: 241 o For packet transmission, the key validity interval as defined by 242 SendLifetimeStart and SendLifetimeEnd must include the current 243 time. 245 o For packet reception, the key validity interval as defined by 246 AcceptLifetimeStart and AcceptLifetimeEnd must include the current 247 time. 249 o The key must be valid for the desired security algorithm. 251 In the remainder of this section, additional requirements for keys 252 are enumerated for different scenarios. 254 4.1. Key Selection for Unicast OSPF Packet Transmission 256 Assume that a router R1 tries to send a unicast OSPF packet from its 257 interface I1 to the interface I2 of a remote router R2 using security 258 protocol P via interface I at time T. First, consider the 259 circumstances where R1 and R2 are not connected with a virtual link. 260 R1 then needs to select a long long-lived symmetric key from its key 261 table. Because the key should be shared by both R1 and R2 to protect 262 the communication between I1 and I2, the key should satisfy the 263 following requirements: 265 o The Peers field is unused. OSPF authentication is interface 266 based. 268 o The Interfaces field includes the local IP address of the 269 interface for numbered interfaces or the MIB-II [RFC1213] ifIndex 270 for unnumbered interfaces. 272 o The Direction field is either "out" or "both". 274 o If multiple keys match the Interfaces field, the key with the most 275 recent SendLifetimeStart time will be selected. This will 276 facilitate graceful key rollover. 278 o The Key ID field in the OSPFv2 header (refer to figure 1) will be 279 set to the selected key's LocalKeyName. 281 When R1 and R2 are connected to a virtual link, the Interfaces field 282 must identify the virtual endpoint rather than the virtual link. 283 Since there may be virtual links to the same router, the transit area 284 ID must be part of the identifier. Hence, the key should satisfy the 285 following requirements: 287 o The Peers field is unused. OSPF authentication is interface 288 based. 290 o The Interfaces field includes both the virtual endpoint's OSPF 291 router ID and the transit area ID for the virtual link. 293 o The Direction field is either "out" or "both". 295 o If multiple keys match the Interfaces field, the key with the most 296 recent SendLifetimeStart time will be selected. This will 297 facilitate graceful key rollover. 299 o The Key ID field in the OSPFv2 header (refer to figure 1) will be 300 set to the selected key's LocalKeyName. 302 4.2. Key Selection for Multicast OSPF Packet Transmission 304 If a router R1 sends an OSPF packet from its interface I1 to a 305 multicast address (i.e., AllSPFRouters or AllDRouters), it needs to 306 select a key according to the following requirements: 308 o The Peers field is unused. OSPF authentication is interface 309 based. 311 o The Interfaces field includes the local IP address of the 312 interface for numbered interfaces or the MIB-II [RFC1213] ifIndex 313 for unnumbered interfaces. 315 o The Direction field is either "out" or "both". 317 o If multiple keys match the Interfaces field, the key with the most 318 recent SendLifetimeStart time will be selected. This will 319 facilitate graceful key rollover. 321 o The Key ID field in the OSPFv2 header (refer to figure 1) will be 322 set to the selected key's LocalKeyName. 324 4.3. Key Selection for OSPF Packet Reception 326 When Cryptographic Authentication is used, the ID of the 327 authentication key is included in the authentication field of the 328 OSPF packet header. Using this Key ID, it is straight forward for a 329 receiver to locate the corresponding key. The simple requirements 330 are: 332 o The interface on which the key was received is associated with the 333 key's interface. 335 o The Key ID obtained from the OSPFv2 packet header corresponds to 336 the neighbor's PeerKeyName. Since OSPFv2 keys are symmetric, the 337 LocalKeyName and PeerKeyName for OSPFv2 keys will be identical. 338 Hence, the Key ID will be used to select the correct local key. 340 o The Direction field is either "in" or "both". 342 5. Securing the IP header 344 This document updates the definition of the Apad constant, as it is 345 defined in [RFC5709], to include the IP source address from the IP 346 header of the OSPFv2 protocol packet. The overall cryptographic 347 authentication process defined in [RFC5709] remains unchanged. To 348 reduce the potential for confusion, this section minimizes the 349 repetition of text from RFC 5709 [RFC5709]. The changes are: 351 RFC 5709, Section 3.3, describes how the cryptographic authentication 352 must be computed. It requires the OSPFv2 packet's Authentication 353 Trailer (which is the appendage described in RFC 2328, Section D.4.3, 354 Page 233, items (6)(a) and (6)(d)) to be filled with the value Apad. 355 Apad is a hexadecimal constant with the value 0x878FE1F3 repeated 356 (L/4) times, where L is the length of the hash being used and is 357 measured in octets rather than bits. 359 OSPF routers sending OSPF packets must initialize Apad to the value 360 of the IP source address that would be used when sending an OSPFv2 361 packet, repeated L/4 times, where L is the length of the hash, 362 measured in octets. The basic idea is to incorporate the IP source 363 address from the IP header in the cryptographic authentication 364 computation so that any change of IP source address in a replayed 365 packet can be detected. 367 When an OSPF packet is received, implementations MUST initialize Apad 368 as the IP source address from the IP Header of the incoming OSPFv2 369 packet, repeated L/4 times, instead of the constant that's currently 370 defined in [RFC5709]. Besides changing the value of Apad, this 371 document does not introduce any other changes to the authentication 372 mechanism described in [RFC5709]. This would prevent all attacks 373 where a rogue OSPF router changes the IP source address of an OSPFv2 374 packet and replays it on the same multi-access interface or another 375 interface since the IP source address is now included in the 376 cryptographic hash computation and modification would result in the 377 OSPFv2 packet being dropped due to an authentication failure. 379 6. Mitigating Cross-Protocol Attacks 381 In order to prevent cross-protocol replay attacks for protocols 382 sharing common keys, the two octet OSPFv2 Cryptographic Protocol ID 383 is appended to the authentication key prior to use. Refer to IANA 384 Considerations (Section 8). 386 [RFC5709], Section 3.3 describes the mechanism to prepare the key 387 used in the hash computation. This document updates the sub section 388 "PREPARATION OF KEY" as follows: 390 The OSPFv2 Cryptographic Protocol ID is appended to the 391 Authentication Key (K) yielding a Protocol-Specific Authentication 392 Key (Ks). In this application, Ko is always L octets long. While 393 [RFC2104] supports a key that is up to B octets long, this 394 application uses L as the Ks length consistent with [RFC4822], 395 [RFC5310], and [RFC5709]. According to [FIPS-198], Section 3, keys 396 greater than L octets do not significantly increase the function 397 strength. Ks is computed as follows: 399 If the Protocol-Specific Authentication Key (Ks) is L octets long, 400 then Ko is equal to Ks. If the Protocol-Specific Authentication Key 401 (Ks) is more than L octets long, then Ko is set to H(Ks). If the 402 Protocol-Specific Authentication Key (Ks) is less than L octets long, 403 then Ko is set to the Protocol-Specific Authentication Key (Ks) with 404 zeros appended to the end of the Protocol-Specific Authentication Key 405 (Ks) such that Ko is L octets long. 407 Once the cryptographic key (Ko) used with the hash algorithm is 408 derived the rest of the authentication mechanism described in 409 [RFC5709] remains unchanged other than one detail that was 410 unspecified. When XORing Ko and Ipad of Opad, Ko MUST be padded with 411 zeros to the length of Ipad or Opad. It is expected that RFC 5709 412 [RFC5709] implementations perform this padding implicitly. 414 7. Security Considerations 416 This document rectifies the manual key management procedure that 417 currently exists within OSPFv2, as part of the Phase 1 of the KARP 418 Working Group. Therefore, only the OSPFv2 manual key management 419 mechanism is considered. Any solution that takes advantage of the 420 automatic key management mechanism is beyond the scope of this 421 document. 423 The proposed sequence number extension offers most of the benefits of 424 more complicated mechanisms without their attendant challenges. 425 There are, however, a couple drawbacks to this approach. First, it 426 requires the OSPF implementation to be able to save its boot count in 427 non-volatile storage. If the non-volatile storage is ever repaired 428 or upgraded such that the contents are lost or the OSPFv2 router is 429 replaced, the authentication keys MUST be changed to prevent replay 430 attacks. 432 Second, if a router is taken out of service completely (either 433 intentionally or due to a persistent failure), the potential exists 434 for reestablishment of an OSPFv2 adjacency by replaying the entire 435 OSPFv2 session establishment. However, this scenario is extremely 436 unlikely, since it would imply an identical OSPFv2 adjacency 437 formation packet exchange. Without adjacency formation, the replay 438 of OSPFv2 hello packets alone for an OSPFv2 router that has been 439 taken out of service should not result in any serious attack as the 440 only consequence is superfluous processing. Of course, this attack 441 could also be thwarted by changing the relevant manual keys. 443 This document also provides a solution to prevent certain denial of 444 service attacks that can be launched by changing the source address 445 in the IP header of an OSPFv2 protocol packet. 447 8. IANA Considerations 449 This document requests a new code point from the "OSPF Shortest Path 450 First (OSPF) Authentication Codes" registry: 452 o 3 - Cryptographic Authentication with Extended Sequence Numbers. 454 This document also requests a new code point from the "Authentication 455 Cryptographic Protocol ID" registry defined under "Keying and 456 Authentication for Routing Protocols (KARP) Parameters": 458 o 2 - OSPFv2. 460 9. References 462 9.1. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 469 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 470 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 471 Authentication", RFC 5709, October 2009. 473 9.2. Informative References 475 [FIPS-198] 476 US National Institute of Standards & Technology, "The 477 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 478 198 , March 2002. 480 [I-D.ietf-karp-crypto-key-table] 481 Housley, R., Polk, T., Hartman, S., and D. Zhang, 482 "Database of Long-Lived Symmetric Cryptographic Keys", 483 draft-ietf-karp-crypto-key-table-10 (work in progress), 484 December 2013. 486 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 487 for Network Management of TCP/IP-based internets:MIB-II", 488 STD 17, RFC 1213, March 1991. 490 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 491 Hashing for Message Authentication", RFC 2104, 492 February 1997. 494 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 495 (USM) for version 3 of the Simple Network Management 496 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 498 [RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF 499 Version 2 Packets and Congestion Avoidance", BCP 112, 500 RFC 4222, October 2005. 502 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 503 Authentication", RFC 4822, February 2007. 505 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 506 and M. Fanto, "IS-IS Generic Cryptographic 507 Authentication", RFC 5310, February 2009. 509 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 510 with Existing Cryptographic Protection Methods for Routing 511 Protocols", RFC 6039, October 2010. 513 [RFC6094] Bhatia, M. and V. Manral, "Summary of Cryptographic 514 Authentication Algorithm Implementation Requirements for 515 Routing Protocols", RFC 6094, February 2011. 517 [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 518 Authentication for Routing Protocols (KARP) Overview, 519 Threats, and Requirements", RFC 6862, March 2013. 521 [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security 522 According to the Keying and Authentication for Routing 523 Protocols (KARP) Design Guide", RFC 6863, March 2013. 525 Authors' Addresses 527 Manav Bhatia 528 Alcatel-Lucent 529 Bangalore, 530 India 532 Phone: 533 Email: manav.bhatia@alcatel-lucent.com 535 Sam Hartman 536 Painless Security 538 Email: hartmans@painless-security.com 540 Dacheng Zhang 541 Huawei Technologies co., LTD. 542 Beijing, 543 China 545 Phone: 546 Fax: 547 Email: zhangdacheng@huawei.com 548 URI: 550 Acee Lindem 551 Ericsson 552 301 Midenhall Way 553 Cary, NC 27513 554 USA 556 Phone: 557 Email: acee.lindem@ericsson.com