Is Using UDP in RIP Secure? – Routing and Security Analysis

riproutingSecurityudp

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.

Best Answer

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.

Related Topic