Lecture #8 - Routing Information Protocol - Part 2
Routing Information Protocol - Version 2 (RIPv2)
In order to address a number of shortcomings in RIP version 1, a number of protocol extensions are defined in RFC1723, collectively forming RIP version 2 (RIPv2). The current specification for RIPv2 is defined in RFC2453, which obsoletes RFC1723.
The significant changes with RIPv2 include:
- All RIP route entries now carry a subnet mask, effectively making it a classless protocol.
- A RIP route entry now specifies a next hop router. This allows a RIP router to advertise a network that is reachable via another router.
- Multicast addressing is now used for periodic broadcasts, reducing load on hosts that do not want to receive RIP messages.
- Authentication for RIP messages is now supported.
- Routes can now be marked as being either internal or external, through the use of a route tag.
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).
Things to Note
- The value of the Version field in a RIPv2 message is 0x02 (surprisingly!). The Command field retains the same values as for RIPv1 (0x01 = Request, 0x02 = Response).
- The Route Tag field allows routes that should be advertised externally or those that have been redistributed (imported) from an external source to be tagged. This information is not used by RIPv2, rather it enables improved route tracking and sharing (see later lecture on route redistribution).
- The Subnet Mask field contains the subnet mask for the advertised route. This means that routing is classless and CIDR based addressing can be carried within the RIPv2 response messages.
- The Next Hop field specifies the address of the next hop router for this route. This allows for another router to be advertised as the next hop for a route, without it needing to run RIP itself. Setting the next hop to the IPv4 "unknown" address (0.0.0.0) results in RIPv1-like behaviour and the next hop is implied as the router sending the response.
Off the Wire
The following is a RIPv2 response message captured "off the wire" from a nearby network, minus the link-level header - the IP and UDP encapsulation however remain intact:
45c0 0034 a264 0000 0111 2a8d 0a01 01fe e000 0009 0208 0208 0020 f590 0202 0000 0002 0000 0a01 0300 ffff ff00 0a01 01fc 0000 0002
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.
Multicast and Ethernet
IP multicast addresses are mapped to a set of Ethernet MAC addresses. Any host that wants to receive IP datagrams addressed to a specific IP multicast address will ask their Ethernet MAC chip to also receive frames that are addressed to MAC address that corresponds with the IP multicast address. This is known as a multicast filter.
This means that only NICs that have been programmed with an appropriate multicast filter will now receive and process these frames, thus avoiding unnecessary load on other hosts. Any host that does not want to receive datagrams addressed to this IP multicast address will now ignore the Ethernet frames at a hardware level, rather than discarding them when performing TCP/UDP processing.
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.
A more fine grained control is provided via the ip rip send and
ip rip receive commands on a per interface basis. For example,
we could configure a router to use RIPv2 by default, however instruct it
to only send and receive RIPv1 messages on Ethernet0/0:
R1(config)#interface Ethernet0/0 R1(config-if)#ip address 192.168.0.0 255.255.255.0 R1(config-if)#ip rip send version 1 R1(config-if)#ip rip receive version 1 R1(config-if)#exit R1(config)# R1(config)#router rip R1(config-router)#version 2 R1(config-router)#network 192.168.0.0
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.
Configuring RIP Authentication
Authentication can be configured using the following:
key chain mykeychain key 1 key-string mekmitasdigoat interface Ethernet0/0 ip rip authentication key-chain mykeychain ip rip authentication mode md5
References
RFC1723: RIP Version 2 Carrying Additional Information
RFC2082: RIP-2 MD5 Authentication