Lecture #8 - Routing Information Protocol - Part 2

RIPv2 Response Message Format

Since RIPv2 is effectively RIPv1 with a number of extensions, the RIP response message format remains the same, however a number of the "unused" fields have been recycled and put to use. A RIPv2 response message looks like the following:

Each RIPv2 response message can still contain up to 25 separate route entries, unless authentication is used (see later).

IP Multicasting: A Slight Digression...

RIPv2 makes use of IP multicast when sending out periodic broadcasts, rather than sending updates that are addressed to the IP limited broadcast address. This reduces the load on hosts which do not want to receive and process RIP messages. The IP multicast address for RIPv2 is 224.0.0.9.

How an Ethernet NIC Works

To understand how this works we need to examine the way in which multicast functions, especially with relation to the operation of an Ethernet Network Interface Card (NIC). A Fast Ethernet NIC generally comprises of a Medium Access Control (MAC) chip (the Data Link Layer component) and a PHY (the Physical Layer component). These are interconnected using a Media Independent Interface or MII bus (standardised as IEEE 802.3u). The idea here is that one Ethernet MAC can be used with multiple PHYs, enabling connectivity with different media.

As part of normal operation the Ethernet MAC will be programmed with a unique 6 byte MAC address - this is normally done from within the NIC device driver. Once the MAC address has been programmed the network card will only process Ethernet frames that are addressed directly to it, or to the Ethernet broadcast address (ff:ff:ff:ff:ff:ff) - all others will be ignored at the hardware level (unless the MAC is running in promiscuous mode).

Receiving an Ethernet Frame

When a Ethernet frame is received, buffered and the CRC has been validated, the NIC will signal the operating system via a hardware interrupt. This should result in the device driver servicing the NIC. At this point the IP datagram will be handed off to the host's TCP/IP stack for processing.

As a result, sending a lot of traffic to the Ethernet broadcast address will result in all hosts receiving the frame, having their NIC generate an interrupt and the IP datagram will be handed to their TCP/IP stack for processing. In the case of RIPv1, at this point a host will realise that it is not interested in the UDP datagram it has received and will discard it, however the processing overhead has already been incurred.

Configuring a Router with RIPv2

There are minimal differences when configuring a router to operate with RIPv2 instead of RIPv1. By default a Cisco router will only send RIPv1 messages, however will process both RIPv1 and RIPv2 responses. This behaviour is changed via the version command:

R1(config)#router rip
R1(config-router)#version 2

This will force the use of RIPv2, resulting in only RIPv2 messages being sent and received. A version of 1 (ie. version 1) will force only RIPv1 messages to be sent and received, whilst specifying no version will restore the default behaviour.

If we are using RIPv2 we probably want to operate using classless CIDR based addressing. This can be enabled using the ip classless command.

Authentication

If routing updates are accepted via RIP messages without authentication, your router is potentially exposed to an attacker, who could inject incorrect routing information into your routing tables. This can be minimised/avoided by using authentication.

RIPv2 includes the ability to authenticate the router sending the update. The first of the routing entries is replaced with an authentication entry, marked with an AFI of 0xffff. This reduces the number of available route entries to 24. Unfortunately, RFC1723 only details simple authentication which results in the password being sent over the network in the clear.

Most sensible routers allow for the use of MD5 based authentication. In this case a MD5 hash is calculated over the combined RIP message and authentication key. The resulting hash is sent as a trailer to the RIP message - this prevents the key from being exposed and prevents RIP messages from being modified. This requires that the first and last routing entries be used for authentication, reducing the number of available routing entries to 23. The exact process used for MD5 based authentication is detailed in RFC2082.

Due to cryptographical weaknesses that have been discovered in MD5, a SHA1 based authentication method is specified in RFC4822. This uses the same approach as for MD5 based authentication, however MD5 is replaced with a SHA1 HMAC algorithm.