idnits 2.17.1 draft-manral-rpsec-existing-crypto-04.txt: -(523): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 729. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Historic RFC: RFC 1058 ** Obsolete normative reference: RFC 1388 (Obsoleted by RFC 1723) ** Obsolete normative reference: RFC 1723 (Obsoleted by RFC 2453) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 3567 (Obsoleted by RFC 5304) ** Obsolete normative reference: RFC 2082 (Obsoleted by RFC 4822) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'IKE') (Obsoleted by RFC 5996) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Vishwas Manral 2 Internet-Draft IP Infusion 3 Expires: November 2007 Russ White 4 Cisco Systems 5 Manav Bhatia 6 Alcatel-Lucent 8 Issues with existing Cryptographic Protection Methods for Routing 9 Protocols 11 draft-manral-rpsec-existing-crypto-04.txt 13 Status of this Memo 15 Distribution of this memo is unlimited. 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 Routing protocols often use cryptographic mechanisms to authenticate 40 data being received from a neighboring router has not been modified 41 in transit, and actually originated from the neighboring router 42 purporting to have originating the data. Most of the cryptographic 43 mechanisms rely on hash algorithms applied to the data in the routing 44 protocol packet, which means the data is transported, in the clear, 45 along with the has signature based on the data itself. These 46 mechanisms rely on the manual configuration of the keys used to seed, 47 or build, these hash based signatures. This document outlines some 48 of the problems with manual keying of these cryptographic algorithms. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119] 56 Table of Contents 58 1. Problem Statement..............................................2 59 2. Open Shortest Path First (OSPFv2)..............................3 60 2.1 Management Issues with OSPF................................4 61 2.2 Technical Issues with OSPF.................................4 62 3. Open Shortest Path First (OSPFv3)..............................5 63 3.1 Management Issues with OSPFv3..............................6 64 3.2 Technical Issues with OSPFv3...............................6 65 4. Intermediate System � Intermediate System (IS-IS)..............7 66 4.1 Management Issues with IS-IS...............................7 67 4.2 Technical Issues with IS-IS................................8 68 5. Border Gateway Protocol (BGP)..................................9 69 5.1 Management Issues with BGP.................................9 70 5.2 Technical Issues with BGP.................................10 71 6. The Routing Information Protocol (RIP)........................10 72 7. Security Considerations.......................................12 73 8. Acknowledgements..............................................12 74 9. IANA Considerations...........................................12 75 10. References...................................................12 76 10.1 Normative References.....................................12 77 10.2 Informative References...................................13 78 11. Contributor's Address........................................14 79 12. Author's Addresses...........................................14 81 1. Problem Statement 83 Routing protocols, such as OSPF [RFC2740] [RFC2328], IS-IS [RFC1195], 84 and BGP [BGP], rely on various mechanisms to create a cryptographic 85 digest of each transmitted routing protocol. Generally, these digests 86 are the results of a hash algorithm, such as [MD5], across the 87 contents of the packet being transmitted, using a private key as the 88 hash base (or seed). These digests are recomputed by the receiving 89 router, using the same key as the originating router used to create 90 the hash, and compared with the transmitted digest to verify: 92 o That the router originating this piece of data is authorized to 93 peer with the local router, and to transmit routing data. This 94 generally protects against falsely generated routing data being 95 injected into a routing system by rogue systems. 97 o That the data has not been changed while transiting between the 98 two neighboring routers. 100 These sorts of authentication methods are not generally used to 101 protect the confidentiality of information being exchanged between 102 routers, since this information (entries in the routing table) is 103 generally freely available in many other context; if anyone has 104 access to the physical media between two routers exchanging routing 105 data, they will also probably have other ways to capture or otherwise 106 discover the contents of the routing tables in those routers. 108 The main problems with the authentication mechanisms in use today 109 revolve around: 111 o Manual configuration of shared secret keys, especially in large 112 scale networks, poses a major management problem, especially as 113 there is generally no way to gracefully move from one secret key 114 to another. 116 o In some cases, when manual keys are configured, some forms of 117 replay protection are disabled, allowing the routing protocol to 118 be attacked. 120 In fact, the MD5 digest algorithm was not designed to be used in the 121 way most routing protocols are using it, which can leads to serious 122 security implications in the future. 124 A preimage attack would enable someone to find an input message that 125 causes a hash function to produce a particular output. In contrast, a 126 collision attack finds two messages with the same hash, but the 127 attacker can't pick what the hash will be. The collisions against 128 MD4, MD5,HAVAL-128, and RIPEMD were found by the Chinese researcher 129 Xiaoyun Wang with co-authors Dengguo Feng, Xuejia Lai, and Hongbo Yu. 131 The collision vulnerability, does not introduce any obvious or known 132 attacks on routing protocols. However pre-image attacks could cause 133 problems. 135 Protocols themselves have some inbuilt protection against collision 136 attacks. A lot of values for a lot fields in the protocol are 137 invalid. For example for OSPF the LSA type can be from 1 to 11. Any 138 other value in the field will result in the packet being dropped. 140 Assume two packets M and M' are generated which have the same hash. 141 The above condition will further reduce the probability of the two 142 messages also being correct messages from the protocol perspective as 143 a lot of values are themselves not valid. 145 2. Open Shortest Path First (OSPFv2) 147 OSPF [RFC2328] describes the use of an MD5 digest with OSPF packets. 148 MD5 keys are manually configured. The OSPF packet Header includes an 149 authentication type field as well as 64-bits of data for use by the 150 appropriate authentication scheme. OSPF also provides for a non- 151 decreasing sequence number to be included in each OSPF protocol 152 packet to protect against replay attacks. 154 2.1 Management Issues with OSPF 156 According to the OSPF specification [RFC2328], digests are applied 157 to packets transmitted between adjacent neighbors, rather than being 158 applied to the routing information originated by a router (digests 159 are not applied at the LSA level, but rather at the packet level). 160 [RFC2328] states that any set of OSPF routers adjacent across a 161 single link may use a different key to build MD5 digests than the key 162 used to build MD5 digests on any other link. Thus, MD5 keys may be 163 configured, and changed, on a per-link basis in an OSPF network. 165 OSPF does not specify a mechanisms to negotiate keys, nor does it 166 specify any mechanism to negotiate the hash algorithms to be used. 168 With the proliferation of the number of hash algorithms, as well as 169 the need to continuously upgrade the algorithms, manually configuring 170 the information becomes very tedious. 172 2.2 Technical Issues with OSPF 174 While OSPF provides relatively strong protection through the 175 inclusion of MD5 signatures, with additional data and sequence 176 numbers, in transmitted packets, there are still two possible attacks 177 against OSPF: 179 o The sequence number is initialized to zero when forming an 180 adjacency with a newly discovered neighbor, and is also set to 181 zero whenever the neighbor is brought down. If the 182 cryptographically protected packets of a router that is brought 183 down(for administrative or other reasons) are stored by a 184 malicious router. The new router could replay the packets from 185 the previous session thus forcing traffic through the malicious 186 router. Dropping of such packets by the router could result in 187 blackholes. Also wrongly forwarding packets could result in 188 routing loops. 190 o OSPF allows multiple packets with the same sequence number. 191 This could mean the same packet can be replayed many times before 192 the next legitimate packet is sent. An attacker may resend the 193 same packet repeatedly until the next hello packet is transmitted 194 and received, which means the hello interval determines the attack 195 window. 197 o OSPF does not specify the use of any particular hash algorithm, 198 however the use of only MD5 is specified in the document. Most 199 OSPF implementations only support MD5. 201 Recently, attacks on collision-resistance properties of MD5 and 202 SHA-1 hash functions have been discovered; [HASH-ATTACK] 203 summarizes the discoveries. The attacks on MD5 are practical on 204 any modern computer. For this reason the use of algorithms needs 205 to be discouraged. 207 o OSPF on a broadcast network shares the same key between all 208 neighbors on a broadcast network. Some OSPF packets are sent on 209 multicast address. 211 This allows spoofing by any malicious neighbor very easy. 212 Possession of the key itself is used as an identity check. There 213 is no other identity check used. A neighbor could send a packet 214 specifying the packet came from some other neighbor and there 215 would be no way in which the attacked router could figure out the 216 identity of the packet sender. 218 o OSPF neighbors on the broadcast, NBMA and point to multipoint 219 networks are identified by the IP address in the IP header. 220 Because the IP header is not covered by the MAC in the 221 cryptographic authentication scheme as described in RFC 2328, an 222 attack can be made exploiting this vulnerability. 224 Assume the following scenario. 226 R1 sends an authenticated HELLO to R2. This HELLO is captured 227 and replayed back to R1, changing the source IP in the IP header 228 to that of R2. 230 R1 not finding itself in HELLO would deduce that the connection is 231 not bidirectional and would bring down the adjacency. 233 3. Open Shortest Path First (OSPFv3) 235 OSPFv3 [RFC2740] relies on the IP Authentication Header described in 236 [AH] and the IP Encapsulating Payload described in [ESP] to 237 cryptographically sign routing information passed between routers. 238 When using ESP, a null encryption algorithm is used, so the data 239 carried in the OSPFv3 packets is signed, but not encrypted. This 240 provides data origin authentication for adjacent routers, and data 241 integrity which gives the assurance data transmitted by a router has 242 not changed in transit. 244 However it does not provide confidentiality of the information 245 transmitted. [OSPF-AUTH] mandates the use of ESP with null encryption 246 for authentication and also does encourages the use of 247 confidentiality to protect the privacy of the routing information 248 transmitted, using [ESP] encryption. 250 [OSPF-AUTH] describes OSPFv3's use of [AH] and [ESP], and specifies 251 that only manual keying of routing information may be used. 253 3.1 Management Issues with OSPFv3 255 [OSPF-AUTH] discusses, at length, the reasoning behind using manually 256 configured keys, rather than some automated key management protocol 257 such as [IKE]. The primary problem is that all current key 258 management mechanisms are designed for one-to-one correlation of 259 keys, while OSPF adjacencies are formed on a one-to-many basis. This 260 forces the system administrator to use manually configured SAs and 261 cryptographic keys to provide the authentication and, if desired, 262 confidentiality services. 264 OSPFv3 security document [OSPF-AUTH] states that 266 As it is not possible as per the current standards to provide 267 complete replay protection while using manual keying, the proposed 268 solution will not provide protection against replay attacks. 270 The primary administrative issue with manually configured SA's and 271 keys in the OSPFv3 case is the simple management issue of maintaining 272 matching sets of keys on all routers within a network. [OSPF-AUTH] 273 does not require that all OSPFv3 routers have the same key configured 274 for every neighbor, so each set of neighbors connected to a single 275 link could have a different key configured. While this makes it 276 easier to change the keys, by forcing the system administrator to 277 only change the keys on the routers on a single link, the process of 278 manual configuration for all the routers in a network to change the 279 keys used for OSPFv3 digests and confidentiality on a periodic basis 280 can be difficult. 282 3.2 Technical Issues with OSPFv3 284 The primary technical concern with the current specifications for 285 OSPFv3 is that when manual SA and key management is used, [AH] 286 specifies, in section 3.3.2, Sequence Number Generation: "The sender 287 assumes anti-replay is enabled as a default, unless otherwise 288 notified by the receiver (see 3.4.3) or if the SA was configured 289 using manual key management". Replayed OSPFv3 packets can cause 290 several failures in a network, including: 292 o Replaying hello packets with an empty neighbor list can cause all 293 the neighbor adjacencies with the sending router to be reset, 294 disrupting network communications. 296 o Replaying hello packets from early in the designated router 297 election process on broadcast links can cause all the neighbor 298 adjacencies with the sending router to be reset, disrupting 299 network communications. 301 o Replaying database description (DB-Description) packets can cause 302 all FULL neighbor adjacencies with the sending router to be reset, 303 disrupting network communications. 305 o Replaying link state request (LS-Request) packets can cause all 306 FULL neighbor adjacencies with the sending router to be reset, 307 disrupting network communications. 309 o Capturing a full adjacency process (from two-way all the way to 310 FULL state), and then replaying this process when the router is no 311 longer attached can cause a false adjacency to be formed, allowing 312 an attacker to attract and black hole traffic. 314 o OSPFv3 on a broadcast network shares the same key between all 315 neighbors on a broadcast network. Some OSPF packets are sent on 316 multicast address. 318 This allows spoofing by any malicious neighbor very easy. 319 Possession of the key itself is used as an identity check. There 320 is no other identity check used. A neighbor could send a packet 321 specifying the packet came from some other neighbor and there 322 would be no way in which the attacked router could figure out the 323 identity of the packet sender. 325 4. Intermediate System � Intermediate System (IS-IS) 327 IS-IS [RFC1195] uses HMAC-MD5 authentication with manual keying, as 328 described in [RFC3567]. There is no provision within IS-IS to 329 encrypt the body of a routing protocol message. 331 4.1 Management Issues with IS-IS 333 [RFC3567] states that each LSP generated by an intermediate system is 334 signed with the HMAC-MD5 algorithm using a key manually defined by 335 the network administrator. Since authentication is performed on the 336 LSPs transmitted by an intermediate system, rather than on the 337 packets transmitted to a specific neighbor, it is implied that all 338 the intermediate systems within a single flooding domain must be 339 configured with the same key for authentication to work correctly. 340 The initial configuration of manual keys for authentication within an 341 IS-IS network is simplified by a state where LSPs containing HMAC-MD5 342 authentication TLVs are accepted, but the digest is not validated. 343 Once an initial set of keys are configured on all routers, however, 344 changing those keys becomes much more difficult. 346 IS-IS [RFC1195] does not specify a mechanisms to negotiate keys, nor 347 does it specify any mechanism to negotiate the hash algorithms to be 348 used. 350 With the proliferation of the number of hash algorithms, as well as 351 the need to continuously upgrade the algorithms, manually configuring 352 the information becomes very tedious. 354 4.2 Technical Issues with IS-IS 356 [RFC3567] states: "This mechanism does not prevent replay attacks, 357 however, in most cases, such attacks would trigger existing 358 mechanisms in the IS-IS protocol that would effectively reject old 359 information." The few case where existing mechanisms in the IS-IS 360 protocol would not effectively reject old information is the case of 361 the hello packets (IIHs) used to discover neighbors and SNP packets. 363 As described in IS-IS [RFC1195], a list of known neighbors is 364 included in each hello transmitted by an intermediate system, to 365 ensure two-way communications with any specific neighbor before 366 exchanging link state databases. 368 IS-IS does not provide a sequence number. Hence IS-IS packets are 369 liable to replay attacks. As any packet can be replayed at any point 370 of time, as long as the keys used are the same. 372 A hello packet containing a digest within a TLV, and an empty 373 neighbor list, could be replayed, causing all adjacencies with the 374 original transmitting intermediate system to be restarted. 376 A replay of an old CSNP packets could cause LSP's to be flooded, thus 377 causing an LSP storm. 379 IS-IS specifies the use of the hash algorithm HMAC-MD5 to protect 380 IS-IS PDU's. 382 IS-IS does not have a notion of Key ID. During Key rollover, each 383 message received has to be checked for integrity against all keys 384 that are valid. A DoS attack may be caused by sending IS-IS packets 385 with random hashes. This will cause the IS-IS packet to be checked 386 for authentication, with all possible keys. Thus increasing the 387 amount of processing required. 389 Recently, attacks on collision-resistance properties of MD5 and SHA-1 390 hash functions have been discovered; [HASH-ATTACK] summarizes the 391 discoveries. The attacks on MD5 are practical on any modern computer. 392 For this reason the use of algorithms needs to be discouraged. 394 HMAC's are not susceptible to any known collision-reduction attack. 395 However IS-IS should provide a way to upgrade to other stronger 396 algorithms. 398 IS-IS on a broadcast network shares the same key between all 399 neighbors on a broadcast network. Some IS-IS PDU's are sent on link- 400 layer multicast address. 402 This makes spoofing by any malicious neighbor very easy. Possession 403 of the key itself is used as an identity check. There is no other 404 identity check used. A neighbor could send a packet specifying the 405 packet came from some other neighbor and there would be no way in 406 which the attacked router could figure out the identity of the packet 407 sender. 409 As the lifetime is not covered in the authentication, an ISIS router 410 can receive its own self generated LSP segment with zero lifetime 411 remaining. In that case, if it has a copy with non zero life time, 412 then it purges the LSP i.e. it increments the current sequence number 413 and floods *all* the segments again. Its much worse in ISIS, as there 414 exists only one LSP (other than the pseudonode LSPs for the LANs on 415 which its the DIS). 417 This way you force the router to flood all segments, which can be 418 quite a lot if the number of routes is large. It also causes the 419 sequence number of all the LSPs to increase fast. If the sequence 420 number increases to the maximum (0xFFFFFFFF), the IS-IS process must 421 shut down for at around 20+ minutes (MaxAge + ZeroAgeLifetime) to 422 allow the old LSPs to age out of all the router databases. 424 5. Border Gateway Protocol (BGP) 426 BGP uses TCP [RFC0793] for transporting routing information between 427 BGP speakers which have formed an adjacency, as described in 428 [RFC2385], with suggestions for choosing MD5 keys described in 429 [RFC3562]. 431 It is common to use the TCP MD5 signature option as described in 432 [RFC2385] for providing data origin authentication and data integrity 433 protection of these BGP packets. with suggestions for choosing MD5 434 key length described in [RFC3562]. There is no provision for 435 confidentiality for any of these BGP messages. 437 This problem is made worse by the nature of the environment where BGP 438 is typically used, between autonomous networks (under different 439 administrative control). While routers running interior gateway 440 protocols may all be configured using the same keys, and have their 441 key rollover policies coordinated or set by the same administrative 442 authority, two BGP peering BGP speakers may be in different 443 administrative domains, with different policies for key strength, 444 rollover times, etc. An autonomous system must often support a large 445 number of keys on different BGP borders, since each connecting AS 446 represents a different administrative entity. 448 5.1 Management Issues with BGP 450 Each pair of BGP speakers forming an adjacency may have a different 451 MD5 shared key, facilitating the configuration and changing of keys 452 across a large scale network. Manual configuration and maintenance 453 of cryptographic keys on all routers is a challenge in any large 454 scale environment, however. Most BGP implementations will accept BGP 455 packets with a bad digest for the hold interval negotiated between 456 BGP peers at peering startup, allowing MD5 keys to be changed without 457 impacting the operation of the network. This technique does, 458 however, allow some short period of time during which an attacker may 459 inject BGP packets with false MD5 digests into the network, and can 460 expect those packets to be accepted, even though their MD5 digests 461 are not valid. 463 5.2 Technical Issues with BGP 465 Since BGP relies on TCP [RFC0793] for transporting data between BGP 466 speakers, BGP can rely on TCP's protections against data corruption 467 and replay to prevent replay attacks against BGP sessions. A great 468 deal of research has gone into the difficulty or ease with which an 469 attacker can overcome these protections, including [TCP-WINDOW] and 470 [BGP-ATTACK]. Most implementations of BGP have modified their TCP 471 implementations to resolve the security vulnerabilities described in 472 these references, where possible. 474 However, as mentioned earlier, MD5 is vulnerable to collision 475 attacks, and can be attacked through several means, such as those 476 explored in [MD5-ATTACK]. 478 Though it is can be argued that the collision attacks do not have a 479 practical implication in this scenario, the use of MD5 is 480 discouraged. 482 Routers performing cryptographic processing of packets in software 483 may be easier to attack. An attacker may be able to transmit enough 484 traffic with false digests to a router that the router's processor 485 and memory resources are consumed, causing the router to be unable to 486 perform normal processing. This is particularly problematic at 487 connections to devices not under local administrative control. 489 6. The Routing Information Protocol (RIP) 491 RIP [RFC1058] does not provide for any authentication or 492 authorization of routing data, and thus is vulnerable to any of the 493 various attacks against routing protocols. 495 RIPv2 [RFC1388, RFC1723] provides for authenticating packets by 496 carrying a digest. The information is there in RIP-2 MD5 497 Authentication [RFC2082]. [RFC4822] obsoletes [RFC2082] and adds 498 details of how the SHA family of hash algorithms can be used with 499 RIPv2 Cryptographic Authentication, whereas [RFC2082] only specified 500 the use of Keyed-MD5. 502 o The sequence number is initialized to zero, at the beginning of 503 time, and is also set to zero whenever the neighbor is brought 504 down. If the cryptographically protected packets of a router that 505 is brought down (for administrative or other reasons) are stored 506 by a malicious router. The new router could replay the packets 507 from the previous session thus forcing traffic through the 508 malicious router. Dropping of such packets by the router could 509 result in blackholes. Also wrongly forwarding packets could 510 result in routing loops. 512 o RIPv2 allows multiple packets with the same sequence number. 513 This could mean the same packet can be replayed many times before 514 the next legitimate packet is sent. An attacker may resend the 515 same packet repeatedly until the next hello packet is transmitted 516 and received, which means the hello interval determines the attack 517 window. 519 o RIPv2 does not specify the use of any particular hash algorithm, 520 RIP implementations only support MD5. MD5 is vulnerable to 521 attacks. 523 o RIPv2 cryptographic authentication as defined in RFC 4822 doesn�t 524 cover the UDP and the IP headers. Its thus possible for an 525 attacker to modify the fields in the above headers without any of 526 the routers getting to know about it. 528 There isn't much that can be done by modifying the UDP header as 529 RIP only uses it to compute the length of the RIP packet. Any 530 changes introduced in the UDP header would fail the RIP 531 authentication, and this attack will thus, not work. 533 However, RIP uses the source IP address from the IP header to 534 determine the RIP neighbor from which its learnt the RIP Updates. 535 This can be used by an attacker to disrupt the RIP routing 536 Sessions between two routers R1 and R2, as shown in the following 537 examples: 539 Scenario 1: 541 R1 sends an authenticated RIP message to R2 with a cryptographic 542 sequence num X. 544 The attacker merely needs get hold of a higher sequence number 545 packet from the LAN. It could also be a packet originated by R2 546 either from this session, or from some earlier session. 548 The attacker can then replay this packet to R2 by changing the 549 source IP to that of R1. 551 R2 would now no longer accept any more RIP Updates from R1 as 552 those would have a lower cryptographic sequence number. After 180 553 secs (or less), R2 would time out R1 and bring down the RIP 554 session. 556 Scenario 2: 558 R1 announces a route with cost C1 to R2. This packet can be 559 captured by an attacker. Later, if this cost changes and R1 560 announces this with some other cost C2, the attacker can replay 561 the captured packet by modifying the source IP to some new 562 arbitrary IP address. It can this way masquerade as some other 563 router. 565 R2 will accept this route and the router as a new gateway, and 566 would use the non existent router as a nexthop for that network. 567 This would obviously only work if C1 < C2. 569 7. Security Considerations 571 This draft outlines security issues arising from the manual keying of 572 cryptographic keys for various routing protocols. No changes to any 573 protocols are proposed in this draft, and no new security 574 requirements result. 576 8. Acknowledgements 578 We would like to acknowledge Sam Hartman, Ran Atkinson, Steve Kent 579 and Brian Wies for their initial comments on this draft. Merike Kaeo 580 reviewed many sections of the draft and gave a lot of useful 581 comments. 583 9. IANA Considerations 585 This document places no requests to IANA. 587 Note to RFC Editor: this section may be removed on publication as an 588 RFC. 590 10. References 592 10.1 Normative References 594 [AH] Kent, S., "IP Authentication Header", 595 RFC 4302, December 2005. 597 [BGP] Rekhter , Y., Li, T., and S. Hares, "A Border Gateway 598 Protocol 4 (BGP-4)", RFC 4271, January 2006. 600 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 601 RFC 4303, December 2005. 603 [OSPF-AUTH] Gupta, M. and N. Melam, "Authentication/Confidentiality 604 for OSPFv3", RFC 4552, January 2006 606 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 607 RFC 793, September 1981. 609 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 610 June 1988. 612 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 613 dual environments", RFC 1195, December 1990. 615 [RFC1388] Malkin, G., "RIP Version 2 Carrying Additional 616 Information", RFC 1388, January 1993. 618 [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional 619 Information", STD 56, RFC 1723, November 1994. 621 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 622 Requirement Levels", BCP 14, RFC 2119, March 1997. 624 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 626 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP 627 MD5 Signature Option", RFC 2385, August 1998. 629 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 630 RFC 2740, December 1999. 632 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 633 Intermediate System (IS-IS) Cryptographic 634 Authentication", RFC 3567, July 2003. 636 [RFC2082] F. Baker and R. Atkinson, "RIP-2 MD5 Authentication", RFC 637 2082, January 1997 639 [RFC4822] R. Atkinson and M. Fanto, "RIPv2 Cryptographic 640 Authentication", RFC 4822, February 2007 642 10.2 Informative References 644 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 645 1321, April 1992 647 [BGP-ATTACK] Convery, S. and M. Franz, "BGP Vulnerability Testing: 648 Separating Fact from FUD v1.00", June 2003. 650 [TCP-WINDOW] Watson, T., "TCP Reset Spoofing", October 2003. 652 [HASH-ATTACK] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 653 Hashes in Internet Protocols", RFC4270, November 2005. 655 [MD5-ATTACK] Wang, X. et al., "Collisions for Hash Functions MD4, 656 MD5, HAVAL-128 and RIPEMD", August 2004, 657 http://eprint.iacr.org/2004/199 659 [RFC3562] Leech, M., "Key Management Considerations for the TCP 660 MD5 Signature Option", RFC 3562, July 2003. 662 [IKE] Kaufman, C., "The Internet Key Exchange (IKEv2) 663 Protocol", RFC 4306, December 2005 665 11. Contributor's Address 667 Sue Hares 668 NextHop 669 USA 670 Email: shares@nexthop.com 672 12. Author's Addresses 674 Manav Bhatia 675 Alcatel-Lucent 676 Bangalore, India 677 Email: manav@alcatel-lucent.com 679 Vishwas Manral 680 IP Infusion 681 Almora, Uttarakhand 682 India 683 Email: vishwas@ipinfusion.com 685 Russ White 686 Cisco Systems 687 RTP North Carolina 688 USA 689 Email: riw@cisco.com 691 Full Copyright Statement 693 Copyright (C) The IETF Trust (2007). 695 This document is subject to the rights, licenses and restrictions 696 contained in BCP 78, and except as set forth therein, the authors 697 retain all their rights. 699 This document and the information contained herein are provided on an 700 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 701 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 702 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 703 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 704 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 705 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 707 Intellectual Property 709 The IETF takes no position regarding the validity or scope of any 710 Intellectual Property Rights or other rights that might be claimed 711 to pertain to the implementation or use of the technology described 712 in this document or the extent to which any license under such rights 713 might or might not be available; nor does it represent that it has 714 made any independent effort to identify any such rights. Information 715 on the procedures with respect to rights in RFC documents can be 716 found in BCP 78 and BCP 79. 718 Copies of IPR disclosures made to the IETF Secretariat and any 719 assurances of licenses to be made available, or the result of an 720 attempt made to obtain a general license or permission for the use 721 of such proprietary rights by implementers or users of this 722 specification can be obtained from the IETF on-line IPR repository 723 at http://www.ietf.org/ipr. 725 The IETF invites any interested party to bring to its attention any 726 copyrights, patents or patent applications, or other proprietary 727 rights that may cover technology that may be required to implement 728 this standard. Please address the information to the IETF at ietf- 729 ipr@ietf.org.