Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 1, 2001.

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

The current strongest authentication method for RIPv2 (RFC2453[6]) is the MD5 authentication (RFC2082[5]) which uses shared secret key to authenticate the packets. This memo explains the different security flaws we found in the anti-replay and the MACs calculation. The second part presents practical exploitations of these weaknesses: an attacker directly connected to a link, can (i) break neighborhood, (ii) flap routes and (iii) inject obsolete routes.

Table of Contents

1.  Threat model
2.  Current authentications
2.1  Description
2.2  Anti Replay Protection
2.2.1  a timestamp as sequence number
2.2.2  a counter as sequence number
2.3  MAC calculation
2.3.1  secret-suffix method
2.3.2  Unprotected IP header
2.3.3  Unprotected UDP header
2.4  Summary
3.  Exploits
3.1  breaking neighborhood
3.1.1  Higher sequence number
3.2  Route flapping
3.2.1  route flapping by repeatdely breaking the neighborhood
3.2.2  route flapping thanks to poisoned reverse
3.3  Inject obsolete routes
3.3.1  higher sequence number
3.3.2  lower sequence number
4.  Security considerations
§  References
§  Author's Address
§  Full Copyright Statement

1. Threat model

In this memo, we assume the attacker can read and write packets on the network link. He hasn't the secret key and he is unable to produce a valid MAC without it.

If the attacker knows the secret key of a link, he becomes an insider and the security of the whole routing domain is compromised. Resisting to insider's attacks requires deep modifications of the protocol and it is outside the scope of this memo.

2. Current authentications

The RIPv2's authentication is configured on a per-interface basis. Each router connected to a given link shares the same parameters (i.e. key value, key lifetime and authentication algorithm). RIP has 3 authentication methods:

1. The NULL authentication which doesnt authenticate the packet.
2. The Simple password authentication (RFC2453.4.1[6]) uses a password sent in clear in each packet. If the attacker can read the packets, he has the password and can freely forge new packets.
3. The MD5 authentication(RFC2082[5]) which uses a shared secret key to include a MAC in each packet.

Because the null and the simple password authentication are already known to be weak, we focus on the MD5 authentication.

2.1 Description

The MD5 authentication provides a secure way to authenticate the packet's generator as a key owner and some protections against packet's replay. The packets include a Message Authentication Code(MAC) calculated with the secret suffix method using MD5 (RFC1321[3]). The MAC is obtained by applying MD5 over the payload and, then, the secret key : MAC = MD5( RIP payload | secret key ). An external attacker can't generate a valid MAC because we assume it ignores the secret key and it is believed to be infeasible to recompute the key from the MAC and the packet.

The anti-replay is handled by a sequence number set in sent packets and verified during packet reception. The sequence number must be non-decreasing and is suggested to be a counter, or a timestamp (RFC2082.3.2.1[5]). A received packet is accepted only if its sequence number is greater or equal to the last one accepted from the same source.

In brief, when a router sends a packet, it sets the sequence number, stores it in a routing entry with a special address family for compatibility reason(RFC2453.5.2[6]), then computes the MAC and appends it to the packet. When a router receives a packet, it is accepted only if the MAC and the sequence number are valid. Unfortunately, the MD5 authentication has flaws in the anti-replay, the MAC algorithm, and the MAC coverage.

2.2 Anti Replay Protection

The following features of the MD5 authentication allow a packet to be replayed:

• A received packet is accepted if its sequence number is greater than or equal to the previous one (RFC2082.3.2.2[5]). For example, a packet can be replayed just after itself.
• The sequence numbers can be reused after a roll over or a boot (e.g. a packet counter RFC2082.3.2.1[5]).
• The keying is static and the sequence numbers aren't necessarily stored in a non-volatile memory. When a router goes off-line, its neighbors forget its sequence numbers and an attacker can replay its packets.

Each reason is independently sufficient to permit a packet's replay. The sequence number is the base of the anti-replay mechanism, so we present the different possibilities. RFC2082.3.2.1[5] suggests to use a timestamp or a packet counter.

2.2.1 a timestamp as sequence number

Using a timestamp as sequence number forces one to either accept several successive packets with the same sequence numbers or to assume that no more than one packet is sent during a clock period.It would unnecessarily create a dependency between the clock frequency and the network throughput. RIPv2 has chosen the former and this likely causes the "greater than or equal to" vulnerability (RFC2082.3.2.2[5]).

RFC2082[5] doesn't require to store the timestamp on a stable storage. If it is, it will roll over in the future. The implementations i have seen use the number of seconds since the first january 1970, so the roll over would happen in 2038. RIPv2 will likely no more be used at this time. Nevertheless it is still possible to successfully replay a packet multiple times until the destination accepts a higher sequence number. This delay can be up to 30 seconds (default periodical update interval from RFC2453.3.8[6]) and more in case of packet loss. Not having the time on a stable storage, doesn't solve the previous vulnerability and adds a new one because sequences numbers are reused after each reboot.

2.2.2 a counter as sequence number

With a timestamp, packets played in the same time slice (e.g. pkt1 then pkt2) can be replayed in disorder (i.e. pkt2, then pkt1). Using a packet counter makes this impossible. Nevertheless the last packet (pkt2) can still be replayed.

If the counter isn't stored on a stable storage it will be reused across reboot. Even if it is, a large router may send 2^32 RIP packets during its lifetime and the sequence number would roll over. So a packet counter still has flaws.

2.3 MAC calculation

The MAC calculation of the MD5 authentication has two problems: it uses the secret-suffix method which is known to be weak and applies it only on the RIP payload, leaving the UDP and IP headers unprotected. Surprisingly, RFC2082[5] doesn't specify where the coverage starts but the implementations we checked start at the beginning of the RIP payload. We consider this behavior as a De-facto standard.

2.3.1 secret-suffix method

[9] considers the secret-suffix method possibly weak. [8] and [7] explains that an attacker may search for MD5( RIP packet ) collisions, and then use them for any key. This search is efficient because it can be parallelized and done off-line. Nevertheless, this weakness is theoretical and unlikely to be turned into an practical attack.

2.3.2 Unprotected IP header

The IP header(RFC0791.3.1[2]) isn't covered by the MAC so a modification would not be detected. If the protocol relies on its fields, it may be the base of an attack. We focus on the fields that may influence RIP and not prevent the packet from reaching the RIP layer (i.e. pass the UDP/IP layers). The matching fields are:

• The source address indicates the origin of the packet and is used by RIP to know which neighbor sent the packet(RFC2453.3.9.2[6]).
• The destination address indicates the destination of the packet. The IP layer uses it to accept or reject the packets.

2.3.3 Unprotected UDP header

An attacker can modify the UDP header (RFC0768[1]) without being detected as well. Nevertheless, the only field used by RIP is the length and any modification, shorter or longer, will cause the authentication verification to fail.

2.4 Summary

In short, a RIPv2 packet authenticated by RFC2082[5], the current strongest method, can be replayed and it can be done between routers which aren't necessarily the original ones. The anti replay protection has several flaws (see Anti Replay Protection) and the MAC don't cover the UDP and IP headers (see MAC calculation). The next section describes the attacks we found based on these vulnerabilities.

3. Exploits

Using the weaknesses described in Anti Replay Protection and in MAC calculation, an attacker directly connected to a single link, can (i) break neighborhood (A neighborhood is the term we use to designate 2 routers seeing each other), (ii) flap routes and (iii) inject obsolete routes.

3.1 breaking neighborhood

The router's neighborhood is the base of the anti-replay of MD5 authentication in RIPv2 and we present an attack able to break it using packet replay and ip address spoofing. An attacker can break the neighborhood between R1 and R2 by preventing R1 from seeing R2:

1. The attacker obtains a packet with a sequence number higher than R2 one (see Higher sequence number).
2. It replays it to R1 faking the R2 source address, R1 accepts it.
3. R1 no more accepts legitimates packets from R2 as their sequence numbers are lower than the last accepted one.
4. R1 eventually breaks the neighborhood considering R2 unreachable.

3.1.1 Higher sequence number

As this attack assumes the attacker has a packet with a higher sequence number, this section explains how to obtain such packet.

• If the R2 sequence number is a time since a fixed date (typically number of second since 01/01/70), it will likely be much higher than sequences numbers reset at each reboot (e.g. packet counter or time since reboot). If R2 hasn't the highest time of the router connected to the link, an attacker can take a packet from a source with a time ahead from the R2 one. Else an attacker may hope the R2 clock will drift and the R2 administrator will adjust it, but it is unlikely.
• If the R2 sequence number is reset as each reboot (e.g. packet counter or time since reboot), the attacker may use a packet from a previous boot or from another router with a higher sequence number (e.g. longer boot or time since a fixed date).

3.2 Route flapping

It is possible to flap routes by (i) repeatdely breaking neighborhood (see route flapping by repeatdely breaking the neighborhood) if the attacker has a packet with a higher sequence number or by (ii) using poisoned reverse (see route flapping thanks to poisoned reverse) if all the routers have similar sequence numbers.

The consequences of flapping a route is to have suboptimal routing. Moreover, in the AS(autonomous system), each trigger update consumes network when it is flooded, and CPU when it triggers a route recalculation. Outside the AS, the cost of this attack will depend on the protocols used. If the route is exported with BGP, it may be dampened (RFC1771.apx6[4]).

3.2.1 route flapping by repeatdely breaking the neighborhood

If an attacker uses the breaking neighborhood method, it may break the neighborhood between R1 and R2, so all the R1 routes using R2 as next hop will be timed out and advertised as infinite. R1 will send triggered update on each of the connected links and the AS will try to converge to a slower route no more using R2. After a short moment (WORK: how long), R1 forgets the fake R2 sequence number, accepts again the R2 packets. As R2 offers a faster route, R1 uses it as next hop and sends a triggered update to announce the change. then the attacker breaks the neighborhood again and the route is flapping.

3.2.2 route flapping thanks to poisoned reverse

If the all routers have similar values of sequences number, an attacker can't use them for breaking a neighborhood but can still do route flapping thanks to the poisoned reverse(RFC2453.3.4.3[6]).

If the router R1 uses a router R2 as next hop for a route, it will advertise this route with a infinite metric on the link between R1 and R2. It prevents from creating 2 hops loop. An attacker can replay the packet with infinite metric back to R1 and fakes the R2 source address, so R1 will accept the packet and update its metric to infinite. The next periodic update from R2 will be accepted as well and R1 will update again with a real metric. If the attacker does it again, the route is flapping.

3.3 Inject obsolete routes

An attacker can inject obsolete routes by (i) capturing a packet advertising a route with a given metric (say X), (ii) then waiting for this route to be announced with a metric Y different than X, and (iii) replays the packet with the metric X. The effect of this attack depends on the sequence number of the replayed packet compared to the current one of the connected routers: (i) if the replayed packet has a smaller sequence number, Y needs to be greater than X or (ii) if it has a greaters one, it can be done independantly of Y.

3.3.1 higher sequence number

If the sequence number of the replayed packet is greater than the current one of connected routers, the attacker sends the packet faking the source address of the current next hop. The packet will be accepted and the new metric will be used, even if it is higher than the former one.

3.3.2 lower sequence number

If the sequence number of the replayed packet is lower, the attacker can still fake an unused source address. The destination will accept it because they have no memory of a sequence number. If the replayed metric X is lower than the current one Y, they will use the new fake router as next hop and the attacker can perform any man in the middle attacks (e.g. traffic analysis, black-holes). The attraction of the black-hole depends on the metric delta (i.e Y-X).

4. Security considerations

This memo presents weaknesses in the current strongest method of authentication. The MD5 authentication anti-replay was known to be weak but its flaws were believed harmless. We found a new flaw in the MAC calculation which allows an attacker to fake the source and destination IP addresses. Combined, these weaknesses allow efficient DoS and the injection of obsolete routes. We present some of the attacks but we strongly suspect there are others as well.

We have designed the "anti-replay authentication" (WORK: ref) that fixes these flaws, without, to the best of our knowledge, adding new ones. This method isn't described in this draft, because it isn't yet fully specified in the RIP context. The MAC covers the IP header preventing an attacker from forging it. This method provides a new way to handle anti-replay with static key which is safe across reset. Keeping the core structure of the MD5 authentication, it can be easily plugged in an existing implementation so we think it may be a good replacement of the MD5 authentication.

References

Author's Address

Full Copyright Statement

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC editor function is currently provided by the Internet Society.