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.
The purpose of this blog post is to elucidate how and why MLD, an IPv6 protocol
we’ve been lately talking quite a bit about, is an unnecessarily complex beast
. This article should also serve to summarize a couple of points we’ve mentioned
during our talks about MLD but which because of time constraints never make it
into the main discussion. We’ve talked about
other aspects of MLD in previous posts.
So, have a look at those if this is a topic which you find interesting. Without
further ado, let’s start for today.
Based on recent research in the ERNW IPv6 lab and with
our MLD talk looming
we’ve put together a (as we think) comprehensive document discussing how to
thoroughly test MLD implementations in various components (network devices or
servers/clients). We hope it can contribute to a better understanding of the
protocol and that it can serve as either a checklist for your own environment or
as a source of inspiration for researchers looking at MLD themselves.
On Thursday the 20^(th) Enno, Jayson and I had the pleasure to present our
latest research results regarding MLD at
Deepsec 2014, both from vendors’
implementation perspective as well as regarding protocol design flaws (some
preliminary results as well as our testing methodology were discussed
here and
here).
For refreshing out memory, in a nutshell, the purpose of MLD, a subprotocol of
IPv6, is to inform routers about the presence of nodes which are interested in
receiving specific multicast traffic
(RFC 2710). The newer version of MLD,
MLDv2 adds the ability for source address selection
(RFC 3810).
Next week, at DeepSec, we’re going to give a
talk about Multicast Listener Discovery
(MLD), a component of IPv6 which is realized by means of ICMPv6 messages. There
are two versions of MLD (mainly specified in RFC 2710 and RFC 3810 respectively)
and while MLD is technically implemented by ICMPv6 exchanges, these
specifications describe a whole set of rules and communication formats, hence we
can safely talk about “the MLD protocol”.
Now, you might ask: how does one tackle the task of examining the security “of a
protocol”?
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.”