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!
The randomly-generated addresses are a security asset that I would not be willing to give up, though.
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.