John Kristoff's blog @ Team Cymru

Security: DVMRP Ask Neighbors2: an IGMP-based DDoS/leak threat

At Team Cymru, we have got into the habit of using BLUF, bottom line up front. Allow me to do so here as well. There exists a little known IP multicast tracing and troubleshooting capability referred to as DVMRP Ask Neighbors2 (the request) and DVMRP Neighbors2 (the response) that can leak router configuration detail and be abused in amplification and reflection attacks. Now, for a fuller accounting of the story.

As I am wont to do, when I take myself out to lunch I will often bring with me some reading material, usually some recent research paper. Approximately four years ago this month, on one such dining and study occasion I happened to bring with me a paper entitled Extracting Intra-Domain Topology from mrinfo. IP multicast is a subject that has long held my attention since many of my formative years operating networks involved inter-domain IP multicast deployment. mrinfo, from the mrouted package. is a command line tool I was familiar with so this paper along with the overall theme of network discovery and measurement immediately appealed to me. After having read the paper and then after a long hiatus from IP multicast troubleshooting tools like mrinfo, I rediscovered how useful this was for mapping Internet topology not necessarily specific to IP multicast by obtaining otherwise unobtainable information from some Internet routers. Fast forward three years. In October 2013, my mind was often preoccupied with amplification and reflection attacks, but I had an opportunity to experiment with the mrinfo tool again when I almost immediately realized the Internet community had another potentially worrisome DDoS threat vector on our hands. From then on up to the present day we have set out to better understand and study all the ramifications of what many would deem to be a case of "protocol abuse" in two forms, an amplifcation and reflection threat and a network topology disclosure threat. We felt both of these threats needed to be brought to the attention of certain vendors and the Internet community so mitigation could begin before miscreants discovered and took advantage of the threats. This blog post provide some background technical material about the threats and the small part we have been playing in mitigation response.

The Internet Group Multicast Protocol (IGMP), IP protocol 2, is essentially a signaling mechanism used between hosts and local IPv4 routers. In essence, end hosts use IGMP to join and leave IP multicast groups and routers use IGMP to maintain group membership on the local network. In practice, there is no operational requirement that these group membership maintenance messages ever leave the local network. Now, I'm not one to advocate for wholesale prohibition of otherwise harmless IP datagrams across internetworks, but here is where the trouble initially begins, but first we must say something about an IP multicast routing protocol that utilizes IGMP.

A now little used and largely obsolete IP multicast routing protocol, the Distance Vector Multicast Routing Protocol (DVMRP), the first widely deployed approach to help move IP multicast data packets around an internetwork, specifies the use of IP protocol 2, making DVMRP a subset type of IGMP messages. The initial specification of DVMRP, version 1, was published as experimental IETF RFC 1075 in 1988. Some years later, work began on updating DVMRP, including bundling in support for additional features that perform "tracing and troubleshooting" capabilities. This latter effort never left Internet Draft status and was ultimately abandoned in final publication draft-ietf-idmr-dvmrp-v3-11. It is the implementation of the DVMRP Ask Neighbors2 and DVMRP Neighbors2 request and response messages in the draft specification of DVMRP that worried us. The former message is specified to be a unicast request, directed to a DVMRP router. If supported, the target router sends a DVMRP Neighbors2 response that includes, primarily, a list of logical interfaces and each interface's properties such as a local IP address and neighbor IP addresses. See Appendix B - Tracing and Troubleshooting support in the draft for further details. Not only was this feature and capability widely implemented in two of the most prominent router vendors' products, but soliciting an Ask Neighbors2 response does not require DVMRP to be running, only some other basic IP multicast component. As you might guess, not only do some routers that respond to these messages disclose information about a router an operator might otherwise wish to keep private, but because a single, small request can potentially solicit a sizable response, this tracing and troubleshooting capability makes for a novel new amplification and reflection attack vector.

We might express some outrage that this little known capability, never formally ratified in an IETF RFC has not only been widely implemented, but has lay lurking as a potential problem for years. We may also be inclined to fret about this threat existing on some of the largest, most well connected and vital pieces of equipment on the Internet. These reactions may be justified, and we do not want to belittle the issue, but we think the potential for widespread abuse may not be as bad as we have seen with other recently disclosed threats through the NTP or the DNS. Two reasons lead us to this belief. First, we believe the changes, fixes or other approaches to limiting abuse are more easily and likely deployed when compared to other protocol abuse threats. By in large, IGMP does not need to transit routers so as a last resort, network-wide filtering of IGMP is not only feasible, but with the exception of being able to use a tool like mrinfo, come with few adverse side effects. Second, it turns out that some networks and some widely deployed network gear already do not forward IGMP messages so widespread scanning and ultimately attacks, will presumably never be able to travel along certain paths of the Internet.

According to our initial research, we believe at least tens of thousands of Internet routers as of this writing will respond to Ask Neighbors2 request messages. While many routers provide minimal responses, many will amplify the request with large or multiple responses, in some cases we have seen an amplification factor of over 100 to 1. While we have discovered numerous responders and have cataloged a number of interesting properties about many routers and responses we have seen, we have partnered with the good folks at The ICSI Networking and Security Group to perform more rigorous and detailed analysis of our findings. We hope to have a proper research paper related to this work appear soon. In the meantime, I'll close with a few final technical details, how to go about mitigating the issue and a warm thank you to a couple of vendor security teams.

The two vendors that are most associated with support for IP multicast routing are Cisco Systems, Inc. and Juniper Networks. Both of these vendors have long supported the DVMRP tracing and troubleshooting features in many of their products. While this capability is not enabled by default, it does not require DVMRP specifically to be activated. For instance, on many Cisco products, simply enabling PIM (a more modern and common suite of IP multicast routing protocols) on any interface will suffice. Likewise on Juniper, PIM on an interface or enabling the igmp protocols group globally will do. We are unfamiliar with other implementations, but based on our experience with the Internet-enabled IP multicast infrastructure, we suspect others will be relatively uncommon.

Where Cisco and Juniper routers support and respond to DVMRP Ask Neighbors2 requests, there are some distinct behaviors they each exhibit. Cisco equipment will limit each IP datagram response to 576 bytes, but send as many messages as necessary to provide a complete list of interface detail. Cisco also encodes the major and minor IOS version numbers in the associated named fields in the DVMRP Neighbors2 response header. Juniper will fragment it's responses. It is worth pointing out, that as a result of correspondence with both Cisco and Juniper, both vendors are in the process of deprecating and removing support for the DVMRP troubleshooting and tracing feature in future versions of their software.

Mitigation of this issue is relatively straightforward. Short of completely disabling any and all IP multicast capabilities, both Cisco and Juniper have provided simple configuration guidelines that should be easily applicable in practically all environments. For Cisco equipment, as documented in The Multicast Security Tool Kit, the following statements can be applied in global configuration mode (be sure to use an access-list number that works for you).

    ip multicast mrinfo-filter 52
    access-list 52 deny any

For Juniper networks, the following firewall filter to the loopback interface can be applied:

    filter igmp {
        term igmp_accept {
            from {
                destination-address {
                 protocol igmp;
            then accept;
        term igmp_drop {
            from {
                protocol igmp;
            then {

The configuration guidelines outlined above are those that are recommended by Cisco and Juniper respectively. Both behave and operate slightly differently and this difference should be noted by network operators. A Juniper device will still respond to Ask Neighbors2 requests directed to a IP multicast group address, but will not forward unicast-directed Ask Neighbors2 probes. The Cisco mrinfo-filter directive prevents only the local router from responding to Ask Neighbors2 requests, but may forward unicast-directed probes to other networks and hosts. To limit unicast forwarding on a Cisco device, an access-list on an interface could be used to mimc the behavior of the Juniper filter:

interface FastEthernet 0/0
 ip address
 ip access-group 101 in
access-list 101 permit igmp any
access-list 101 deny igmp any any

Today, in the security track at NANOG 62 we present a brief talk entitled DVMRP Ask Neighbors2: an IGMP-based DDoS leak/threat, in coordination with bulletins released by both Cisco and Juniper. Let me end by expressing our gratitude and appreciation for a pleasant experience working with both Cisco PSIRT and Juniper SIRT. The representatives we worked with throughout the last year, as we made progress and plans to publicly discuss this threat, handled our concerns with the utmost professionalism and seriousness. We thank them for their cooperation and are happy to report both exhibited an ability to address the issue completely, discretely and in coordinated fashion.

posted at 2:49 pm | permanent link