Wednesday, August 15, 2012

Bug in Cisco IOS's DVMRP


 mrinfo is a handy multicast troubleshooting tool that comes with Cisco IOS (and Windows). It works by sending a DVMRP Ask Neighbors2 message to a target router and listening for the response message that is sent back.  draft-ietf-idmr-dvmrp-v3-11 contains a good explanation of what is DVMRP.
 While working on a similar (yet better ;)) implementation for Nmap's NSE, I have come across an interesting bug in Cisco IOS's implementation of DVMRP. (Tested against 12.4 and 15.0).

To demonstrate this, let's try with a simple test environment in which we have two routers:
Router1: 172.16.0.4
Router2: 172.16.0.5
both routers are connected to the same LAN via FastEthernet0/0, and have PIM enabled (mode is not important, as this was tested with both DM and SM modes.)
 When we execute the command #mrinfo 172.16.0.5 on Router1, the expected outcome happens. Router1 sends a DVMRP Ask Neighbors2 message to Router2, and the latter replies with a DVMRP Neighbors2 message.


 We could have a better perspective on how the routers are interpreting the packets with IOS's debugger using #debug ip dvmrp command. ( #terminal monitor is needed when remotely connected to the routers.) The events (sending and receiving on both sides) are shown by the debugger.



The fun comes when we think (just a bit) outside of the box and issue the #mrinfo 224.0.0.1 command. 224.0.0.1 being all hosts multicast address, means that it will be seen by Router2. When I first tried this, I hoped that mrinfo will parse all the responses from the routers that replied, but I was expecting it to just pick the first response to arrive.

In a normal way, Router1 will send the Ask Neighbors2 message, Router2 will receive the message, and respond to it with a Neighbors2 message.


Interestingly though, Router2 will set the destination address of the packet as 224.0.0.1.


As expected, Router1 will ignore the packet that has 224.0.0.1 as the source address.


Leading to the error "% Timed out receiving response"
Sending to destinations such as 224.0.0.2 (All Routers) and 224.0.0.4 (DVMRP) multicast addresses would yield the same results. This works even with 255.255.255.255 :)


Trying with another tool such as mtrace (The one I committed to Nmap, not Cisco IOS', as it is not flexible enough to let us choose which address to send to), which sends an IGMP Traceroute Query message and listens for IGMP Traceroute Response messages, we see the normal behavior: The target routers using their interfaces' addresses as the source address.


My call ? Sloppy programming in which, instead of using the interface address, the destination address of the request message is used as the source address of the response. If we got the packet, it was necessarily meant for us, right ?
Oh, and mrinfo sends those packets to multicast addresses with a TTL of 255, contrary to what RFC 3171. Another sign, that we are not using the tool as it was intended to be used as. :)

1 comment:

  1. It's amazing that you noticed this bug.
    Thanks for sharing.

    philwebservices

    ReplyDelete