idnits 2.17.1 draft-vyncke-pim-mld-security-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 24, 2015) is 3046 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Multicast E. Vyncke 3 Internet-Draft Cisco 4 Intended status: Informational E. Rey 5 Expires: June 26, 2016 ERNW 6 A. Atlasis 7 NCI Agency 8 December 24, 2015 10 MLD Security 11 draft-vyncke-pim-mld-security-01 13 Abstract 15 The latest version of Multicast Listener Discovery protocol is 16 defined in RFC 3810, dated back in 2004, while the first version of 17 MLD, which is still in use and has not been deprecated, is defined in 18 RFC 2710 and is dated back in 1999. New security research has 19 exhibited new vulnerabilities in MLD, both remote and local attack 20 vectors. This document describes those vulnerabilities and proposes 21 specific mitigation techniques. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 26, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Local Vulnerabilities . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Downgrading to MLDv1 . . . . . . . . . . . . . . . . . . 3 60 2.2. Queries sent to unicast address . . . . . . . . . . . . . 4 61 2.3. Win the election . . . . . . . . . . . . . . . . . . . . 4 62 2.4. Host enumeration and OS fingerprinting . . . . . . . . . 4 63 2.5. Flooding of MLD messages . . . . . . . . . . . . . . . . 4 64 2.6. Amplification . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Remote Vulnerabilities . . . . . . . . . . . . . . . . . . . 5 66 4. Mitigations . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 8.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 The Multicast Listener Discovery protocol version 2 (MLDv2) RFC3810 78 [RFC3810] has a security section but it was not exhaustive and the 79 focus was only on local forged MLD packets. The same is also true 80 for the first version of MLD (now called MLDv1), which is still in 81 use, defined in RFC 2710. This document goes beyond those attacks. 83 For the reader who is not familiar with MLDv2, here are the main 84 points: 86 Multicast routers send MLD queries which are either generic (query 87 about all multicast group) sent to ff02::1 (link-scope all nodes) 88 or specific (query about a specific group) sent to this multicast 89 group. Query messages can also be sent to a unicast address. 91 Multicast members reply to MLDv2 queries with reports sent to 92 ff02::16 (link-scope all MDLDv2 routers). In version 1 of MLD 93 RFC2710 [RFC2710], the reports are sent to the multicast group 94 being reported. Reports can be transmitted twice or more in order 95 to ensure that the MLD router gets at least one report. 97 When a node ceases to listen to a multicast address on an 98 interface, it sends an MLDv1 Done message or a specially crafted 99 MLDv2 Report message. 101 All MLD packets are ICMPv6 RFC4443 [RFC4443] messages sent with a 102 hop-limit of 1, from a link-local address and there is no 103 authentication. 105 MLD messages received with a hop-limit greater than 1 should be 106 discarded. 108 Neighbor Discovery Protocol RFC4861 [RFC4861] requires nodes to 109 become member of the respective solicited-node multicast groups 110 for all their link-scope and global-scope addresses. 112 Switches are assumed to implement MLD snooping RFC4541 [RFC4541] 113 to learn where to forward multicast packets. It must be noted 114 though that implementations of MLD snooping do not act on link- 115 local multicast groups such as solicited-node multicast group: 116 they simply forward all packets destined to a link-local multicast 117 group to all port in the same layer-2 network. 119 MLDv2 was designed to be interoperable with MLDv1. 121 The main difference between MLDv1 and MLDv2 from a functionality 122 perspective is that MLDv1 does not support "source filtering" (in 123 MLDv2 nodes can report interest in traffic only from a set of 124 source addresses or from all except a set source addresses). 126 Every IPv6 node must support MLD. 128 This document is heavily based on previous research: [Troopers2015]. 130 2. Local Vulnerabilities 132 2.1. Downgrading to MLDv1 134 A single MLDv1 report message is enough to downgrade all MLD nodes 135 (hosts and routers) to the version 1 protocol. This could be used to 136 force a MLD host to reply with MLDv1 reports sent to the multicast 137 group rather than to ff02::16. This downgrade to MLDv1 could also be 138 used to transmit the MLDv1 report with a 'done' operation to remove a 139 listener (stopping the multicast traffic on the subnet). Another 140 consequence of downgrading to MLDv1 can be the fact that an attacker 141 can also used "Host Suppression" feature as part of a DoS attack, 142 make the launch of such an attack easier. 144 2.2. Queries sent to unicast address 146 Section 5.1.15 of RFC3810 [RFC3810], specifies that for debugging 147 purposes, nodes must accept and process queries sent to any of their 148 addresses (including unicast). Lab testing, described in 149 [Troopers2015], clearly shows that all implementations except FreeBSD 150 accept and process MLD queries sent to a unicast global address. 151 This can be an exploited to completely bypass the legitimate MLD 152 router and interact directly (for whatever purpose) with the targets 153 (including legitimate routers and clients). 155 2.3. Win the election 157 When there are multiple MLD routers in a layer-2 domain, the one with 158 the lowest IPv6 address wins the election and becomes the designated 159 MLD router. A hostile node can then send from a lower link-local 160 address an MLD message and become the MLD router. This fact in 161 combination with the direct interaction with the targets could be 162 leveraged to mount a denial of service attack. 164 2.4. Host enumeration and OS fingerprinting 166 Some hosts try to prevent host enumeration by not responding to 167 ICMPv6 echo request messages sent to any multicast group. But, the 168 same hosts must reply to any MLD queries including the generic one 169 sent to ff02::1, this allows for MLD host enumeration. As hosts join 170 different groups based on their operating system (specific groups for 171 Microsoft Windows for example), the MLD report can also help for 172 Operating System (OS) fingerprinting. 174 2.5. Flooding of MLD messages 176 If an implementation does not rate limit in hardware the rate of 177 processed MLD messages, then they are vulnerable to a CPU exhaustion 178 denial of services. If a node does not limit the number of states 179 associated to MLD, then this node is vulnerable to a memory 180 exhaustion denial of services. 182 2.6. Amplification 184 Nodes usually join multiple groups (for example, Microsoft Windows 185 8.1 joins 4 groups). Therefore a forged generic MLDv1 query will 186 force those nodes to transmit MLDv1 reports for each of their groups 187 (in our example 4); furthermore, many implementations send MLD 188 reports twice (in our example 8 in total). MLDv2 is a little better 189 because reports are sent to ff02::16 and not to the multicast group. 191 3. Remote Vulnerabilities 193 MLD messages with hop-limit different than 1 should be discarded but 194 nothing prevents a hostile party located n hops away from the victim 195 to send any MLD messages with a hop-limit set to n+1. Therefore, a 196 remote hostile party can mount attacks against MLD (especially 197 because implementations process MLD queries sent to a global unicast 198 address). 200 4. Mitigations 202 This section proposes some mitigation techniques that could be used 203 to prevent the above attacks. This section is not a specification of 204 any kind, the words 'should' is plain English and is not related to 205 RFC2119 [RFC2119]. 207 Mitigation by specific implementations: 209 Similar to RA-guard RFC6105 [RFC6105], there should be a MLD-guard 210 function in layer-2 switches; MLD queries (either version 1 or 211 version 2) received on ports attached to non multicast routers 212 should be discarded. Switches could also block all MLDv1 packets 213 in order to prevent the downgrading of MLD version. Of course, 214 this requires all nodes to support MLDv2. 216 All nodes should be able to disable MLDv1. 218 Control plane policing should also be implemented in order to 219 avoid denial of services attacks. 221 Mitigation by a protocol update of RFC2710 [RFC2710] and RFC3810 222 [RFC3810]: 224 MLD queries should not be accepted and processed when sent to a 225 unicast address (either link-local or global scope). This 226 requires update of RFC 3810 and RFC 2710. 228 To mitigate the remote attacks, the hop-limit should have been set 229 to 255 and MLD nodes should discard packets with a hop-limit 230 different than 255. 232 5. IANA Considerations 234 This document contains no IANA considerations. 236 6. Security Considerations 238 Thi document describes multiple vulnerabilities that have been 239 described above and tries to mitigate them or even eliminate some of 240 them by making specific suggestions for update of the protocol as 241 well as by suggesting the implementation of related security 242 mechanisms to layer-2 devices. 244 7. Acknowledgements 246 The authors would like to thank Stig Venaas for some discussions on 247 this topic. 249 8. References 251 8.1. Normative References 253 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 254 Listener Discovery (MLD) for IPv6", RFC 2710, 255 DOI 10.17487/RFC2710, October 1999, 256 . 258 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 259 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 260 DOI 10.17487/RFC3810, June 2004, 261 . 263 8.2. Informative References 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, 267 DOI 10.17487/RFC2119, March 1997, 268 . 270 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 271 Control Message Protocol (ICMPv6) for the Internet 272 Protocol Version 6 (IPv6) Specification", RFC 4443, 273 DOI 10.17487/RFC4443, March 2006, 274 . 276 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 277 "Considerations for Internet Group Management Protocol 278 (IGMP) and Multicast Listener Discovery (MLD) Snooping 279 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 280 . 282 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 283 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 284 DOI 10.17487/RFC4861, September 2007, 285 . 287 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 288 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 289 DOI 10.17487/RFC6105, February 2011, 290 . 292 [Troopers2015] 293 Rey, E., Atlasis, A., and J. Salazar, "MLD Considered 294 Harmful", 2015, . 299 Authors' Addresses 301 Eric Vyncke 302 Cisco 303 De Kleetlaan 6a 304 Diegem 1831 305 Belgium 307 Phone: +32 2 778 4677 308 Email: evyncke@cisco.com 310 Enno Rey 311 ERNW 312 Carl-Bosch-Str. 4 313 Heidelberg 69115 314 Germany 316 Phone: +49 6221 480390 317 Email: erey@ernw.de 319 Antonios Atlasis 320 NCI Agency 321 Oude Waalsdorperweg 61 322 The Hague 2597 AK 323 The Netherlands 325 Phone: +31 703743564 326 Email: antonios.atlasis@ncia.nato.int