Right now, I’m in Buenos Aires for IETF95 where, amongst others, an Internet-Draft authored by Eric Vyncke, Antonios Atlasis and myself will be presented (and hopefully discussed) in two working groups. In the following I want to quickly lay out why we think this is an important contribution.
As some of you may remember about two years ago we started an internal research project on the IPv6 “helper procotol” Multicast Listener Discovery (MLD) and its security properties. One outcome of this research project was Jayson Salazar‘s excellent thesis on the topic (the full document can be found here), another outcome were the related talks we gave at DeepSec 2014 and at Troopers15.
When looking at MLD in practice (read: in the lab built with several Cisco devices and encompassing main COTS host operating systems) we noted
- that pretty much all of them had MLD enabled by default (we think that the reason for this might be the somewhat ambiguous wording in RFC 4861, sect. 7.2.1 where it’s stated that “[j]oining the solicited-node multicast address is done [highlighted by ed.] using a Multicast Listener Discovery such as [MLD] or [MLDv2]”, which in turn could lead implementors to the assumption that MLD is strictly needed for proper functioning of ND which, as we showed here, might not be correct. [see also RFC 6434 section 5.10 which seems to follow that interpretation].
- most OSs did not strictly adhere to all parts of the specifications and deviated from those here+there, e.g. by accepting MLD packets with a hop-limit > 1. Actually a combination of issues meant that MLD packets could be sent to router interfaces from remote subnets which is clearly not intended as of the core MLD specifications (RFCs 2710 and 3810).
- in general MLD is susceptible to a number of attacks, incl. straightforward DoS attacks against devices (we managed to render a Cisco ASR-1002 unusable by just sending MLD packets from one single source) and amplification attacks on the local link. More details in this post or the above sources.
Overall we think that some additional security controls might be needed to ensure network stability and performance in the face of MLD. We hence suggest
- to introduce a switch port based feature called “mld-guard” which blocks MLD queries (ICMPv6 type 130) from unauthorized sources, similar to RA guard.
- some modifications of MLD specifics, most notably no reception of MLD packets on unicast addresses (which RFC 3810 currently permits, “for debugging purposes”) and an another way of handling the hop-limit (send packets with hop-limit 255 and discard all which don’t have 255 upon reception).
The draft can be found here and we’re happy to receive any type of feedback.
Have a great day
Enno
Hi,
Thanks for great stuff on IPv6 security! I’d like to clarify one thing about the source of the requirement for sending MLD reports for solicited-node multicasts. It goes back to the original MLD specification in RFC2710:
MLD messages are never sent for multicast addresses whose scope is 0 (reserved) or 1 (node-local).
MLD messages ARE sent for multicast addresses whose scope is 2 (link-local), including Solicited-Node multicast addresses [ADDR-ARCH], except for the link-scope, all-nodes address (FF02::1).
This requirement is still in effect as it has not been changed by any later RFC. I believe the idea is that the MLD snooping switches should filter ALL multicasts except for FF02::1. Of course, it comes at a way high price (yes, I have read “The network nightmare that ate my week”), but AFAIK it hasn’t been amended in any way yet.