Is UDP Usage in Routing Information Protocol (RIP) a Secure Practice?

Question

I know that UDP is a connectionless transport layer protocol. Since it is easy to fake your source IP and source Port in your headers, what keeps anyone from poisoning routing tables via RIP? It seems to me like I can easily flood routers with fake information messages under this circumstance.

Answer 1

Yes, plain RIP can be vulnerable to attacks. RIP was created long before the Internet was commercialized. Today, there are options for secure authentication of RIP updates. For example, RFC 4822, RIPv2 Cryptographic Authentication:

1. Introduction

   Growth in the Internet has made us aware of the need for improved authentication of routing information. RIPv2 provides for unauthenticated service (as in classical RIP), or password authentication. Both are vulnerable to passive attacks currently widespread in the Internet. Well-understood security issues exist in routing protocols [Bell89]. Cleartext passwords, originally specified for use with RIPv2, are widely understood to be vulnerable to easily deployed passive attacks [HA94].

   The original RIPv2 cryptographic authentication specification, RFC 2082 [AB97], used the Keyed-MD5 cryptographic mechanism. While there are no openly published attacks on that mechanism, some reports [Dobb96a, Dobb96b] create concern about the ultimate strength of the MD5 cryptographic hash function Further, some end users, particularly several different governments, require the use of the SHA hash function family rather than any other such function for policy reasons. Finally, the original specification uses a hashing construction widely believed to be weaker than the HMAC construction used with the algorithms added in this revision of the specification.

   This document obsoletes the original specification, RFC 2082 [AB97]. This specification differs from RFC 2082 by adding support for the SHA family of hash algorithms and the HMAC technique, while retaining the original Keyed-MD5 algorithm and mode. As the original RIPv2 Cryptographic Authentication mechanism was algorithm-independent, backwards compatibility is retained. This requirement for backwards compatibility precludes making significant protocol changes. So, this document limits changes to the addition of support for an additional family of cryptographic algorithms. The original specification has been very widely implemented, is known to be widely interoperable, and is also widely deployed.

   The authors do NOT believe that this specification is the final answer to RIPv2 authentication and encourage the reader to consult the Security Considerations section of this document for more details.

   If RIPv2 authentication is disabled, then only simple misconfigurations are detected. The original RIPv2 authentication mechanism relied upon reused cleartext passwords. Use of cleartext password authentication can protect against accidental misconfigurations if that were the only concern, but is not helpful from a security perspective. By simply capturing information on the wire -- straightforward even in a remote environment -- a hostile entity can read the cleartext RIPv2 password and use that knowledge to inject false information into the routing system via the RIPv2 routing protocol.

   This mechanism is intended to reduce the risk of a successful passive attack upon RIPv2 deployments. That is, deployment of this mechanism greatly reduces the vulnerability of the RIPv2-based routing system from a passive attack. When cryptographic authentication is enabled, we transmit the output of a keyed cryptographic one-way function in the authentication field of the RIPv2 packet, instead of sending a cleartext reusable password in the RIPv2 packet. The RIPv2 Authentication Key is known only to the authorized parties of the RIPv2 session. The RIPv2 Authentication Key is never sent over the network in the clear.

   In this way, protection is afforded against forgery or message modification. While it is possible to replay a message until the sequence number changes, a sequence number can be used to reduce replay risks. The mechanism does not provide confidentiality, since messages stay in the clear. Since the objective of a routing protocol is to advertise the routing topology, confidentiality is not normally required for routing protocols.

   Other relevant rationales for the approach are that MD5 and SHA-1 are both being used for other purposes and are therefore generally already present in IP routers, as is some form of password management.

Answer 2

Route table poisoning used to happen accidentally (and with some regularity) when RIP (v1) was commonly used as a mechanism for end hosts to find redundant gateways in the days before FHRP's (i.e HSRP) came into use. Misconfigured hosts (usually UNIX sysadmins forgetting to add the -q / quiet option to ripd) would advertise bad routing into a shared subnet. This would not only cause the other hosts in the network to start sending traffic to the wrong place but could (would) propagate through the routers to the rest of the environment.

Several elements of best-practice came out of this:

1. Use an FHRP for hosts so that they (usually) don't need anything more than a default gateway.
2. Only allow routing protocols to run on segments specifically interconnecting routers. The Cisco command passive-interface default accomplishes this for most IGP's (i.e. by default disallow routing adjacencies on any interfaces where not explicitly enabled).
3. Ideally use an IGP capable of authentication, and then actually use that authentication (this last part is still really uncommon).

So, yes, RIPv1 was (is) certainly vulnerable to receiving bad information (intentionally or otherwise). It's not necessarily the use of UDP per se that's the origin of this but rather a fundamentally obsolete protocol implementation (regardless of protocol choice) as well as bad/sloppy practice on the part of network engineers.

Answer 3

This problem can be true without proper measures. The correct way to secure this communication on the network is to require MD5 authentication.

Keep in mind authentication is NOT possible with RIPv1, only RIPv2.

Here is a Cisco doc on this for a more practical example

RIPv2 Authentication