MLD Considered Harmful

Multicast Listener Discovery (MLD) protocol is well hidden deep in the bowels of IPv6 protocol stack and most of us tend to gloss over it when we discuss IPv6 neighbor discovery process… until MLD raises its ugly head to bite an unsuspecting network administrator.

The problems with MLD are not new (and I wrote exhaustively about them a while ago), but it’s always nice to see other people raise awareness of broken IPv6 features like Enno Rey and his security team did during the IPv6 Security Summit (part of Troopers 15 conference).

They managed to demonstrate two exploits of MLD:

  • You can hose a router CPU with MLD flood (no big news, you can do the same with ARP… but you can do way more damage with MLD because it's more complex);
  • Due to the fact that most routers respond to MLD messages sent to any destination IPv6 addresses they own, you can disrupt a multicast stream on a LAN even when the layer-2 switches use full complement of IPv6 first-hop security features by pretending to be another MLD-capable router (you’ll have to watch Enno’s presentation to get the details).

The easiest solution to the first issue (if you have no other use for IPv6 multicast than neighbor discovery) is to disable MLD on layer-3 switches (no ipv6 mld router on Cisco IOS) to reduce the CPU load, and disable MLD snooping on layer-2 switches. Stopping the second exploit would require MLD guard, and I’m not aware of any vendor having that functionality.

However, a follow-up discussion revealed way more disconcerting facts: it would be easy to stop MLD flooding attacks with control-plane protection, but unfortunately most routers (or layer-3 switches) don’t handle IPv6 data-to-control-plane traffic classification too well.

For example, Nexus 6000 allows you to match on IPv6 NA/ND/RA/RS messages, but not on MLD messages. On the other hand, ASR 9000 allows you to rate-limit ICMPv6 messages sent to the router (which include MLD messages, but also neighbor discovery messages). Can it distinguish between ND and MLD messages? I don’t know. What are other vendors doing? Please chime in – write a comment!

3 comments:

  1. Somewhat similar to the 'temper your McGyver streak' post of yours, I'm tempted to say that it would be better to start designing a new (or old ARP-like) protocol for this instead of trying to fix MLD with a lot of patches to network software.
    The randomly-generated addresses are a security asset that I would not be willing to give up, though.
  2. Great threads on the topic here:
    http://nanog.markmail.org/thread/vyztrje3ndhwxi2s
    http://nanog.markmail.org/thread/hdtrnob3ujsj2xcx
    https://www.ietf.org/mail-archive/web/v6ops/current/msg19877.html [there are several other threads with the same subject: https://www.ietf.org/mail-archive/web/v6ops/current/mail4.html)

    The short of it: lots of canyon sized gaps in most products.
  3. For the dual stack edge / dmz deployments I have done in the past, everything is hard coded, the addresses, even custom Link Locals for location id, turn off RD, use the flow label as a tag per zone for integrity and apply some policers when we get some erratic v6 numbers. From the address we know who is who, zone, and who doesn't belong between all zones. Kind of like a custom LAA job. Interesting on the MLD issues on larger enterprise side. I recall the issue but haven't been involved in any enterprise dual stack or green field deployments where the numbers are big enough to cause an issue. Great post for an update on the issue and the link to Occasionally Coherent blog about this.
Add comment
Sidebar