<?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-01"
     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 AK</code>
        </postal>

        <phone>+31 703743564</phone>

        <email>antonios.atlasis@ncia.nato.int</email>
      </address>
    </author>

    <date day="24" month="December" 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, while the first version of MLD,
      which is still in use and has not been deprecated, is defined in RFC
      2710 and is dated back in 1999. 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. The same
      is also true for the first version of MLD (now called MLDv1), which is
      still in use, defined in RFC 2710. 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 messages 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>When a node ceases to listen to a multicast address on an
          interface, it sends an MLDv1 Done message or a specially crafted
          MLDv2 Report message.</t>

          <t>All MLD packets are ICMPv6 <xref target="RFC4443">RFC4443</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>MLDv2 was designed to be interoperable with MLDv1.</t>

          <t>The main difference between MLDv1 and MLDv2 from a functionality
          perspective is that MLDv1 does not support &ldquo;source
          filtering&rdquo; (in MLDv2 nodes can report interest in traffic only
          from a set of source addresses or from all except a set source
          addresses).</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 &ldquo;Host Suppression&rdquo; feature as part of a DoS
        attack, make the launch of such an attack easier.</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"/>, clearly shows that all
        implementations except FreeBSD accept and process MLD queries sent to
        a unicast global address. This can be an exploited to completely
        bypass the legitimate MLD router and interact directly (for whatever
        purpose) with the targets (including legitimate routers and
        clients).</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. A hostile node can then send from a lower
        link-local address an MLD message and become the MLD router. This fact
        in combination with the direct interaction with the targets could be
        leveraged to mount a denial of service attack.</t>
      </section>

      <section title="Host enumeration and OS fingerprinting">
        <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
        Operating System (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 prevents 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 queries 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>.</t>

      <t>Mitigation by specific implementations:<list>
          <t>Similar to RA-guard <xref target="RFC6105">RFC6105</xref>, there
          should be a MLD-guard function in layer-2 switches; MLD queries
          (either version 1 or version 2) 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. Of
          course, this requires all nodes to support MLDv2.</t>

          <t>All nodes should be able to disable MLDv1.</t>

          <t>Control plane policing should also be implemented in order to
          avoid denial of services attacks.</t>
        </list></t>

      <t>Mitigation by a protocol update of <xref
      target="RFC2710">RFC2710</xref> and <xref
      target="RFC3810">RFC3810</xref>:<list>
          <t>MLD queries should not be accepted and processed when sent to a
          unicast address (either link-local or global scope). This requires
          update of RFC 3810 and RFC 2710.</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 and tries to mitigate them or even eliminate some of
      them by making specific suggestions for update of the protocol as well
      as by suggesting the implementation of related security mechanisms to
      layer-2 devices.</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors 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>
