Forgotten protocol chronicles: Do not underestimate the installed base

By on 8 Apr 2024

Category: Tech matters

Tags: , ,

Blog home

Old file cabinet. Adapted from the original at Fortepan.

As a long-time network operator, frequent information security (infosec) community participant, and now researcher, I have often found myself drawn to the challenges of the installed base. All the attention in the tech industry is given to the latest software, protocols, hardware, and innovations. Meanwhile, yesterday’s deployments fade away at a snail’s pace and this is a problem.

For this write-up, I wanted to reflect on the stubborn persistence of technologies such as ISATAP, which is an early IPv6 transition mechanism and DVMRP AskNeighbors2, which is an experimental IP multicast debugging protocol.

When reading this post, I think it will be fruitful to try to come up with answers to these basic questions:

  • Who maintains and pays attention to these ‘legacy’ technologies?
  • What problems loom in these aging systems we are not dealing with?
  • How does the community respond to problems that arise in unmaintained systems?

ISATAP Hijacking: Self-inflicted MitM waiting to happen

When it comes to legacy IPv6 transition technologies, many people are unaware that they are active and enabled on their systems. For example, ISATAP, an early Windows-based IPv4 to IPv6 transition protocol mechanism is there to help a system setup an IPv6 over IPv4 tunnel.

Furthermore, some of you might be surprised to learn that these systems are relaying or trying to relay a significant portion of traffic to IPv6 over IPv4 tunnel endpoints that are controlled by parties unknown. In other words, there exists a sizable number of self-inflicted Man in the Middle (MitM) attacks waiting to happen.

My fellow researchers and I studied the prevalence and persistence of legacy IPv6 transition mechanisms such as 6to4 and ISATAP in a paper entitled ‘Plight at the End of the Tunnel: Legacy IPv6 Transition Mechanisms in the Wild‘.

Through active and passive measurement, we highlighted the traffic capture and hijack risks that persist to this day. One experiment evaluated our ability to become the IPv6 tunnel entry point for ISATAP-enabled systems. ISATAP is a domain name-based transition mechanism and is active by default on Microsoft Windows systems up until version 8.1.

What we discovered is that when there isn’t an existing usable IPv6 interface, the host will issue a DNS query with the prefix label ‘isatap’ in its default domain.

For instance, if the default domain is and we register the name, we will be able to return an associated IPv6 tunnel endpoint address to clients. To test this out, we registered several isatap names in several domains, including many popular ccTLDs. The result was that we suddenly and effectively became the first hop IPv6 tunnel router for thousands of systems all over the Internet that queried our domain names.

The non-profit organization, which I am a part of, now maintains these ISATAP domain names, sink-holing DNS queries and preventing them from being abused. The plot below shows that the total number of ISATAP queries per day is on the decline, but we still see thousands of queries per day. Last year alone we saw approximately a quarter of a million unique DNS resolvers query our nameserver for ISATAP names. We don’t know the precise number of end systems that would ultimately try to establish an ISATAP tunnel, but we assume it is still significant.

Figure 1 — The number of ISATAP DNS queries seen by in 2023.

DVMRP AskNeighbors2: DDoS potential and information leak wrapped in a neat package

Are you familiar with IP multicast technology?

My guess is that very few readers will have little more than textbook knowledge. Moreover, I bet almost none of you even know what Distance Vector Multicast Routing Protocol (DVMRP) is. DVMRP is a long-abandoned IP multicast routing protocol that runs over the Internet Group Management Protocol (IGMP).

DVMRP AskNeighbors2 specifically was a debugging message for early IP multicast-enabled networks defined in an experimental IETF Internet Draft in 2003. The specification was never formally adopted into an IETF RFC. Even though DVMRP has been dead for a long time, that didn’t stop major router vendors from widely implementing support for this one debugging message in a lot of gear that persisted for years.

Well, as a result, we ended up writing a paper about this one too entitled ‘On the Potential Abuse of IGMP‘.

In the paper, we detail the potential problem and its impact on the Internet. In hindsight, IGMP should never have been allowed to leave the LAN, but this one experimental, widely deployed debugging mechanism, infrequently used but for a handful of IP multicast experts was now out of the bag.

The problem with this protocol is that one simple request can result in multiple response packets. Sometimes the response can be several response packets. If you thought DNS reflection and amplification attacks were bad, some of the largest AskNeighbors2 responders could reach an amplification factor of one million to one!

That isn’t all. The responses contain interesting information that an attacker might want to know. Most routers would return the version of the software they were running, and a list of IP multicast-enabled interfaces configured for example. For some routers, both bits of information could be quite revealing, leaking potentially sensitive operational information that is usually off-limits to anyone but the network administrators.

Stubborn persistence and forgotten technology

Widely deployed mechanisms such as ISATAP and AskNeighbors2 can graduate to legacy status relatively quickly, but the rate at which they are replaced, dismantled, and removed from service is often a long, slow slope that can take many years. I bet if I asked you to name a legacy system or protocol that should cease to exist but persists, you’ve already thought of one.

I would also bet that I can probably tell you about a legacy system or protocol running on the Internet that you didn’t know existed or have forgotten about. Each new generation of innovators brings great technology, but at the same time, some of our history gets pushed further away from our operational consciousness. We need to occasionally wipe away the dust.

Outside of niche research efforts like my own, we must find ways to draw attention to the practice of retiring legacy systems in a formal, documented, and measured way. Until then, we’ll keep writing research papers reminding you of what you’ve forgotten about.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *