This is a guest post from Antonios Atlasis.
Today we had the opportunity at ERNW to have a full-day discussion about MLD. The discussion was led by Jayson Salazar who writes his thesis on the topic.
For the newcomers to IPv6 world, the purpose of MLD, a subprotocol of IPv6, as defined in RFC 2710, is “to enable each IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes.” MLD was updated by MLDv2 in RFC 3810 in order to “add the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses.”
We discussed several MLD-related stuff and various potential (or …existing) security implications (which, by the way, are going to be presented at DeepSec in Vienna). However, one of the things that it attracted our attention, not from a security perspective but from an functional one is the question whether MLD is actually required to perform the Neighbor Discovery process. Up to now, none of us had thought about it. There wasn’t such a provision in the initial RFC regarding Neighbor Discovery for IPv6, but in the latest one, in RFC 4861, which obsoletes the previous, it is written in paragraph 7.2.1 that “joining the solicited-node multicast address is done using a Multicast Listener Discovery such as [MLD] or [MLDv2] protocols.” As you notice, “is done”, a kind of a fact (perhaps not in an RFC-way, strictly speaking, but at least according to human language interpretation). Again, for the newcomers to the IPv6 world the solicited-node multicast address is used during the Neighbor Discovery process to accomplish address resolution. However, nothing in the RFC about how MLD is used in the Neighbor Discovery process.
To clarify it and full of curiosity we booted-up a Linux and a FreeBSD machine and, to our surprise, we found out that MLD messages are actually sent even before the Router Solicitation and Neighbor Solicitation messages. For a such a sample traffic from a Centos 6.5 machine, please see below:
There was only one way to find out: Implement some ip6table rules to block outgoing MLDv2 Report messages (sent by the client) to clarify whether MLD is actually required for the Neighbor Discovery process or not. The following rule is more than enough:
ip6tables -I OUTPUT 1 -p icmpv6 –icmpv6-type 143 -j DROP
So, we blocked outgoing ICMPv6 type 143, which are the MLDv2 Report messages. We booted-up again Centos, and we got the following traffic:
As you can see, no MLD messages now. But still, Neighbor Discovery process takes place without any problem. As we expected, before being confused by RFC 4861.
So, why is it written in the RFC that joining the solicited-node multicast address is done using MLD? We found at least one case. When MLD snooping is enabled in the switches (which is not usually the case, by default). But, that’s another story. For the time being, we can continue relying on Neighbor Discovery without requiring MLD.
Cheers
Antonios
Nice post! I remember that we discussed this once during an IPv6 training and didn’t come to a definite result.
Frank,
thanks for the feedback.
For all readers who are further interested in operational intricacies of MLD I suggested reading this: “The network nightmare that ate my week“.
cheers
Enno
“For the time being, we can continue relying on Neighbor Discovery without requiring MLD.”
Well as you say, “for the time being”. This is a short-sighted way of looking at things. The standard requires you to register using MLD (or IGMP in IPv4) if you want to receive multicast. If you work on a single broadcast medium with no multicast optimization, you get away without registration. Until one day your switch is replaced with one that does snooping by default, or someone activates MLD snooping – then things will mysteriously start to break.
Hi Simon,
thanks for your comment.
Being a guy with an operational background in large scale enterprise networks I fully agree with the perspective that “a certain semi-proprietary feature (called [MLD|IGMP]-snooping) that certain vendors offer on a certain type of devices called switches can be quite helpful for optimizing resources/bandwidth in certain environments”.
Still let me add some points here:
a) as a security guy it hurts to see that – seemingly, as it turned out – a crappy, complex, broken-in-many-ways helper protocol called MLD might be needed to perform fundamental tasks (like ND) in IPv6 networks.
b) at times taking part in IETF meetings I would not assume that “those guys writing RFCs” would ever take a vendor feature (which is not a standard neither in the IETF nor in the IEEE world) into account when specifying something in an RFC, in particular not a functionality of switches (=> “layer 2” devices, hence usually out of scope of IETF standardization).
c) I’m not aware of any device models/images which have MLD snooping enabled by default. for a good reason that you explicitly mentioned: that might break something.
d) I estimate that 95% of entities speaking IP do so in networks which either don’t have Ethernet switches at all, or don’t have switches with a feature called MLD snooping, or switches run by admins who dont’ know the feature or, if they do, are keen to enable it.
you should not rely on assumptions on networks operated by others or judge on them…
Best
Enno
Hi Simon,
pls allow to make you aware of this presentation Jeff Wheeler gave at NANOG 58: “Layer-2 Multicast State Problems Caused by IPv6 Neighbor Discovery ND“.
best
Enno
Antonios/Enno,
Great post! I always assumed MLD was required – never thought of blocking it. A few comments though. Enno, like you I work with lots of clients. However, my domain is mostly limited to the States – so please account for this bias. My personal experience does not agree with the 95% of networks don’t use multicast snooping. I think a better way to put it could be that most networks don’t do multicast. However, at least in the States, I have seen this gradually increasing, especially in the last few years. Unified Communications and more prominently, Networked digital content distribution (Video conferencing, Online training, mass imaging, etc.) often use/require multicast support. Where multicast support is required, snooping must be used. Why? Because if you don’t enable it you’ll end up with a network meltdown. In fact, we regularly see that clients try to deploy some kind of digital content distribution over the network without multicast. This results in a broken network and setting up multicast. So, I’m not really disagreeing with you – just saying I wouldn’t write off multicast as a niche. I think its a little more prominent than that.
Next, just to make sure we’re on the same page – you’re aware of these, right?
RFC 4541 (Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches), RFC 5790 (Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols)
What do you think – right direction? Is more needed?
Finally, I know that many in the security community aren’t huge fans of MLD, especially MLDv2. However, I think multicast is really important and will become increasing common for digital content distribution. Let’s say I’m right here, what do you think is the right solution/direction to have secure multicast? Even though the MLDv2 spec is somewhat involved, it’s still much shorter than NDP. When proper penetration testing/creative exploration & attacks you don’t think the issues with the protocol can be teased out and fixed? Is Antonios going to cover some issues in his upcoming presentation?
–Jim
Hi Jim,
thanks for the comprehensive feedback. Always appreciated!
Some unordered points from my side:
a) I fully second the observation that within enterprise networks the use of multicast is rising and quite some of them use IGMP/MLD snooping to support that.
My “95%”-statement was to be read like this:
out of 100 (“random”) systems running IPv6, only some (“5%”) will be in a network that fulfills the following conditions:
– it’s based on Ethernet. AND
– it’s served by switches capable of MLD snooping. AND
– the administrator has turned it (MLD snooping) on.
Which in turn means: to perform a fundamental IPv6 mechanism (ND) the other 95% have to have a bloated, stack-wise immature protocol (MLD) enabled without a real need for that. Which, ofc, violates the simplicity principle (RFC 3439) and basis security thinking.
btw: I agree with Jeff Wheeler in his NANOG58 presentation, slide #33 in the bottom (“ND should just be broadcasted”).
b) in general I have a problem with the line of thinking/argumentation that goes like:
– for ND it’s mandatory to have MLD as well.
– MLD is helpful for a semi-proprietary optimization mechanism used in some networks and called “MLD snooping”.
– hence MLD is cool and useful.
c) I’m aware of the RFCs, but it should be noted that RFC 4541 is an “Informational” one, with a “Considerations” title.
[btw: have you observed that, at the time, none of the six switch vendors asked did support snooping in hardware (see section 4 of RFC 4541)? I leave it up to the reader what this implies… although this might have changed in the interim. Looking at the widely discussed CSAIL network meltdown story I doubt this has changed, at least in Juniper space].
As for RFC 5790: which devices do actually support/”do” that? Real question, no pun intended. I’d just like to know.
d) shameless plug here: we’ll discuss (& demo) quite some issues of common MLD implementations in our talk at DeepSec and Antonios will release a MLD-capable version of Chiron before our workshop.
Will the design-level issues be fixed? Considering my personal experience in the IETF world, I don’t think so ;-).
Last but not least, on a personal level: I won’t be able to make it to the RM v6 Summit this year, due to a conflict with my wife’s birthday ;-). So pity! we can’t meet/chat there.
Any chance you join us for next year’s IPv6 Security Summit?
thanks again & have a good one
Enno
Hi James,
thanks a lot for your thorough comments and your kind words. We are aware of the RFCs that you mentioned and I believe that we are on the same page. We share the same thoughts with you. However, please allow me not to answer to your apposite questions right now since, we have an ongoing research regarding MLD/MLDv2 the outcome of which, will answer them, as we hope. Of course, we will share this outcome promplty by various means (including blogposts) with the security community. Questions and comments like yours helps us towards this direction.
Best
Antonios
Thank you for a great post. A Cisco engineer told me that a switch with MLD snooping turned on will flood packets destined for the SNMA groups to all interfaces. This is done to avoid overcrowding the snooping table