One document matched: draft-vyncke-pim-mld-security-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2710 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2710.xml">
<!ENTITY RFC3810 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3810.xml">
<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC4541 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4541.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC6105 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6105.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-vyncke-pim-mld-security-00"
ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="MLD Security">MLD Security</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Eric Vyncke" initials="E" surname="Vyncke">
<organization>Cisco</organization>
<address>
<postal>
<street>De Kleetlaan 6a</street>
<city>Diegem</city>
<country>Belgium</country>
<code>1831</code>
</postal>
<phone>+32 2 778 4677</phone>
<email>evyncke@cisco.com</email>
</address>
</author>
<author fullname="Enno Rey" initials="E" surname="Rey">
<organization>ERNW</organization>
<address>
<postal>
<street>Carl-Bosch-Str. 4</street>
<city>Heidelberg</city>
<country>Germany</country>
<code>69115</code>
</postal>
<phone>+49 6221 480390</phone>
<email>erey@ernw.de</email>
</address>
</author>
<author fullname="Antonios Atlasis" initials="A" surname="Atlasis">
<organization>NCI Agency</organization>
<address>
<postal>
<street>Oude Waalsdorperweg 61</street>
<city>The Hague</city>
<country>The Netherlands</country>
<code>2597 AK69115</code>
</postal>
<phone>+31 703743564</phone>
<email>antonios.atlasis@ncia.nato.int</email>
</address>
</author>
<date day="25" month="June" year="2015"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>IP Multicast</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>IPv6</keyword>
<keyword>MLD</keyword>
<keyword>Security</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>The latest version of Multicast Listener Discovery protocol is
defined in RFC 3810, dated back in 2004. New security research has
exhibited new vulnerabilities in MLD, both remote and local attack
vectors. This document describes those vulnerabilities and proposes
specific mitigation techniques.</t>
<!-- -->
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Multicast Listener Discovery protocol version 2 (MLDv2) <xref
target="RFC3810">RFC3810</xref> has a security section but it was not
exhaustive and the focus was only on local forged MLD packets. This
document goes beyond those attacks.</t>
<t>For the reader who is not familiar with MLDv2, here are the main
points:<list>
<t>Multicast routers send MLD queries which are either generic
(query about all multicast group) sent to ff02::1 (link-scope all
nodes) or specific (query about a specific group) sent to this
multicast group. Query message can also be sent to a unicast
address.</t>
<t>Multicast members reply to MLDv2 queries with reports sent to
ff02::16 (link-scope all MDLDv2 routers). In version 1 of MLD <xref
target="RFC2710">RFC2710</xref>, the reports are sent to the
multicast group being reported. Reports can be transmitted twice or
more in order to ensure that the MLD router gets at least one
report.</t>
<t>All MLD packets are ICMPv6 <xref target="RFC4443">RFC443</xref>
messages sent with a hop-limit of 1, from a link-local address and
there is no authentication</t>
<t>MLD messages received with a hop-limit greater than 1 should be
discarded</t>
<t>Neighbor Discovery Protocol <xref target="RFC4861">RFC4861</xref>
requires nodes to become member of the respective solicited-node
multicast groups for all their link-scope and global-scope
addresses</t>
<t>Switches are assumed to implement MLD snooping <xref
target="RFC4541">RFC4541</xref> to learn where to forward multicast
packets. It must be noted though that implementations of MLD
snooping do not act on link-local multicast groups such as
solicited-node multicast group: they simply forward all packets
destined to a link-local multicast group to all port in the same
layer-2 network</t>
<t>Every IPv6 node must support MLD</t>
</list>This document is heavily based on previous research: <xref
target="Troopers2015"/>.</t>
</section>
<section title="Local Vulnerabilities">
<t/>
<section title="Downgrading to MLDv1">
<t>A single MLDv1 report message is enough to downgrade all MLD nodes
(hosts and routers) to the version 1 protocol. This could be used to
force a MLD host to reply with MLDv1 reports sent to the multicast
group rather than to ff02::16. This downgrade to MLDv1 could also be
used to transmit the MLDv1 report with a 'done' operation to remove a
listener (stopping the multicast traffic on the subnet). Another
consequence of downgrading to MLDv1 can be the fact that an attacker
can also used “Host Suppression” feature as part of a DoS
attack.</t>
</section>
<section title="Queries sent to unicast address">
<t>Section 5.1.15 of <xref target="RFC3810">RFC3810</xref>, specifies
that for debugging purposes, nodes must accept and process queries
sent to any of their addresses (including unicast). Lab testing,
described in <xref target="Troopers2015"/>, cleary show that all
implementations except FreeBSD accept and process MLD queries sent to
a unicast global address. An attacker can then completely bypass the
MLD router.</t>
</section>
<section title="Win the election">
<t>When there are multiple MLD routers in a layer-2 domain, the one
with the lowest IPv6 address wins the election and becomes the
designated MLD router. An hostile node can then send from a lower
link-local address a MLD message and become the MLD router. This could
be leveraged to mount a denial of service attack.</t>
</section>
<section title="Host enumeration">
<t>Some hosts try to prevent host enumeration by not responding to
ICMPv6 echo request messages sent to any multicast group. But, the
same hosts must reply to any MLD queries including the generic one
sent to ff02::1, this allows for MLD host enumeration. As hosts join
different groups based on their operating system (specific groups for
Microsoft Windows for example), the MLD report can also help for OS
fingerprinting.</t>
</section>
<section title="Flooding of MLD messages">
<t>If an implementation does not rate limit in hardware the rate of
processed MLD messages, then they are vulnerable to a CPU exhaustion
denial of services. If a node does not limit the number of states
associated to MLD, then this node is vulnerable to a memory exhaustion
denial of services.</t>
</section>
<section title="Amplification">
<t>Nodes usually join multiple groups (for example, Microsoft Windows
8.1 joins 4 groups). Therefore a forged generic MLDv1 query will force
those nodes to transmit MLDv1 reports for each of their groups (in our
example 4); furthermore, many implementations send MLD reports twice
(in our example 8 in total). MLDv2 is a little better because reports
are sent to ff02::16 and not to the multicast group.</t>
</section>
</section>
<section title="Remote Vulnerabilities">
<t>MLD messages with hop-limit different than 1 should be discarded but
nothing prevent a hostile party located n hops away from the victim to
send any MLD messages with a hop-limit set to n+1. Therefore, a remote
hostile party can mount attacks against MLD (especially because
implementations process MLD quaries sent to a global unicast
address).</t>
</section>
<section title="Mitigations">
<t>This section proposes some mitigation techniques that could be used
to prevent the above attacks. This section is not a specification of any
kind, the words 'should' is plain English and is not related to <xref
target="RFC2119">RFC2119</xref>.<list>
<t>Similar to RA-guard <xref target="RFC6105">RFC6105</xref>, there
should be a MLD-guard function in layer-2 switches; MLD queries received
on ports attached to non multicast routers should be discarded. Switches
could also block all MLDv1 packets in order to prevent the downgrading
of MLD version.</t>
<t>MLD queries should not be accepted and processed when sent to a
unicast address (either link-local or global scope).</t>
<t>All nodes should be able to disabled MLDv1.</t>
<t>Control plane policing should also be implemented in order to avoid
denial of services attacks.</t>
<t>To mitigate the remote attacks, the hop-limit should have been set to
255 and MLD nodes should discard packets with a hop-limit different than
255.</t>
</list></t>
</section>
<section title="IANA Considerations">
<t>This document contains no IANA considerations.</t>
</section>
<section title="Security Considerations">
<t>Thi document describes multiple vulnerabilities that have been
described above.</t>
</section>
<section title="Acknowledgements">
<t>The author would like to thank Stig Venaas for some discussions on
this topic.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2710;
&RFC3810;
</references>
<references title="Informative References">
<reference anchor="Troopers2015"
target="https://www.troopers.de/media/filer_public/7c/35/7c35967a-d0d4-46fb-8a3b-4c16df37ce59/troopers15_ipv6secsummit_atlasis_rey_salazar_mld_considered_harmful_final.pdf">
<front>
<title>MLD Considered Harmful</title>
<author fullname="Enno Rey" initials="E" surname="Rey">
<organization/>
</author>
<author fullname="Antonios Atlasis" initials="A" surname="Atlasis">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="Jason Salazar" initials="J" surname="Salazar">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<date month="" year="2015"/>
</front>
</reference>
&RFC2119;
&RFC4443;
&RFC4541;
&RFC4861;
&RFC6105;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:55:14 |