Internet DRAFT - draft-etienne-ripv2-auth-flaws
draft-etienne-ripv2-auth-flaws
Network Working Group J. Etienne
Internet-Draft May 2001
Expires: October 30, 2001
Flaws in RIPv2 packet's authentication
draft-etienne-ripv2-auth-flaws-00.txt
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 October 30, 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.
Etienne Expires October 30, 2001 [Page 1]
Internet-Draft RIPv2 authentication flaws May 2001
Table of Contents
1. Threat model . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Current authentications . . . . . . . . . . . . . . . . . . 4
2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Anti Replay Protection . . . . . . . . . . . . . . . . . . . 5
2.2.1 a timestamp as sequence number . . . . . . . . . . . . . . . 5
2.2.2 a counter as sequence number . . . . . . . . . . . . . . . . 5
2.3 MAC calculation . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 secret-suffix method . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Unprotected IP header . . . . . . . . . . . . . . . . . . . 6
2.3.3 Unprotected UDP header . . . . . . . . . . . . . . . . . . . 6
2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 breaking neighborhood . . . . . . . . . . . . . . . . . . . 8
3.1.1 Higher sequence number . . . . . . . . . . . . . . . . . . . 8
3.2 Route flapping . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1 route flapping by repeatdely breaking the neighborhood . . . 9
3.2.2 route flapping thanks to poisoned reverse . . . . . . . . . 9
3.3 Inject obsolete routes . . . . . . . . . . . . . . . . . . . 9
3.3.1 higher sequence number . . . . . . . . . . . . . . . . . . . 10
3.3.2 lower sequence number . . . . . . . . . . . . . . . . . . . 10
4. Security considerations . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
Etienne Expires October 30, 2001 [Page 2]
Internet-Draft RIPv2 authentication flaws May 2001
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.
Etienne Expires October 30, 2001 [Page 3]
Internet-Draft RIPv2 authentication flaws May 2001
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.
Etienne Expires October 30, 2001 [Page 4]
Internet-Draft RIPv2 authentication flaws May 2001
2.2 Anti Replay Protection
The following features of the MD5 authentication allow a packet to
be replayed:
o 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.
o The sequence numbers can be reused after a roll over or a boot
(e.g. a packet counter RFC2082.3.2.1[5]).
o 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
Etienne Expires October 30, 2001 [Page 5]
Internet-Draft RIPv2 authentication flaws May 2001
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:
o 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]).
o 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.
Etienne Expires October 30, 2001 [Page 6]
Internet-Draft RIPv2 authentication flaws May 2001
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 Section 2.2) and the MAC don't
cover the UDP and IP headers (see Section 2.3). The next section
describes the attacks we found based on these vulnerabilities.
Etienne Expires October 30, 2001 [Page 7]
Internet-Draft RIPv2 authentication flaws May 2001
3. Exploits
Using the weaknesses described in Section 2.2 and in Section 2.3, 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 Section 3.1.1).
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.
o 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.
o 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 Section 3.2.1) if the attacker has a packet with a
higher sequence number or by (ii) using poisoned reverse (see
Etienne Expires October 30, 2001 [Page 8]
Internet-Draft RIPv2 authentication flaws May 2001
Section 3.2.2) 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 Section 3.1 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.
Etienne Expires October 30, 2001 [Page 9]
Internet-Draft RIPv2 authentication flaws May 2001
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).
Etienne Expires October 30, 2001 [Page 10]
Internet-Draft RIPv2 authentication flaws May 2001
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.
Etienne Expires October 30, 2001 [Page 11]
Internet-Draft RIPv2 authentication flaws May 2001
References
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 28 August
1980.
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, Sep 1981.
[3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[5] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication", RFC
2082, January 1997.
[6] Malkin, G.S., "RIP Version 2", STD 56, RFC 2453, November 1998.
[7] Bellare, M., Canetti, R. and H. Crawczyk, "Keying hash function
for Message Authentication", Advances in cryptology Crypto 96
vol 1109, 1996.
[8] Preneel, B. and P. Van Oorshot, "MDX-MAC and building fast MACs
from hash functions", Advances in cryptology Crypto 96 , 1995.
[9] Kaliski, B. and M. Robshaw, "Message authentication with MD5",
Cryptobyte Vol1 no1, 1995.
Author's Address
Jerome Etienne
EMail: jme@off.net
URI: http://w3.arobas.net/~jetienne
Etienne Expires October 30, 2001 [Page 12]
Internet-Draft RIPv2 authentication flaws May 2001
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.
Etienne Expires October 30, 2001 [Page 13]
