DNSSD H. Rafiee INTERNET-DRAFT Huawei Technologies Intended Status: Informational Expires: December 10, 2014 June 10, 2014 Multicast DNS (mDNS) Threat Model and Security Consideration Abstract This document describes threats associated with extending multicast DNS (mDNS) across layer 3. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 10, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Rafiee, et al. Expires December 10, 2014 [Page 1] INTERNET DRAFT mDNS Threat Model June 10, 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. mDNS Gateway is a single point of failure . . . . . . . . 4 3.2. Large Traffic Production from mDNS Gateway . . . . . . . 4 3.3. DoS attack on any node in the mDNS enabled network . . . 5 3.4. Good mDNS gateway goes bad . . . . . . . . . . . . . . . 5 3.5. Fake mDNS gateway . . . . . . . . . . . . . . . . . . . . 5 3.6. MAC address spoofing . . . . . . . . . . . . . . . . . . 5 3.6.1. possible solution . . . . . . . . . . . . . . . . . . 5 3.7. Cache Poisoning . . . . . . . . . . . . . . . . . . . . 5 3.7.1. Possible solution . . . . . . . . . . . . . . . . . . 6 3.8. Malicious update on unicast DNS . . . . . . . . . . . . . 6 3.9. Harming Privacy . . . . . . . . . . . . . . . . . . . . . 6 3.10. IP spoofing . . . . . . . . . . . . . . . . . . . . . . 6 3.11. Resource spoofing . . . . . . . . . . . . . . . . . . . 7 3.12. Internet Group Management Protocol (IGMP) Attacks . . . 7 3.13. Multicast Listener Discovery (MLD) attacks . . . . . . . 7 3.14. Fake Resource Advertisement . . . . . . . . . . . . . . 7 3.15. Dual stack attacks . . . . . . . . . . . . . . . . . . . 7 4. Possible solutions . . . . . . . . . . . . . . . . . . . . . 7 4.1. SAVI-DHCP . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. DNS over TLS . . . . . . . . . . . . . . . . . . . . . . 8 4.3. CGA-TSIG . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. DNS Security Extension . . . . . . . . . . . . . . . . . 8 4.5. SSAS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.6. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 9 8.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Rafiee, et al. Expires December 10, 2014 [Page 2] INTERNET DRAFT mDNS Threat Model June 10, 2014 1. Introduction Multicast DNS (mDNS) was proposed in [RFC6762] to allow nodes in local links to use DNS-like names for their communication without the need for global DNS servers, infrastructure and administration processes for configuration. mDNS along with service discovery (DNS-SD) [RFC6763] provides nodes with the possibility to discover other services and the names of other nodes with zero configuration, i.e., connect a node into a local link and use resources such as a printer that are available in that network. mDNS and service discovery use DNS- like query messages. The main assumption is that these services also use DNS security protocols such as DNSSEC. However, due to the limitation of DNSSEC in local link, i.e., the key authorization and configuration needed for DNSSEC, it is not easy to use this protocol for zero configuration services. This is why the current implementations use no security in local links and are vulnerable to several attacks. The purpose of this document is to introduce threat models for mDNS and service discovery and allow implementers to be aware of the possible attacks in order to mitigate them with possible solutions. Since there are already old lists of known DNS threats available in [RFC3833], here we only analyze the ones that are which is applicable to mDNS. We also introduce new possible threats that could result from extending mDNS scope. 2. Terminology Node: any host and routers in the network Attack: an action to exploit a node and allow the attacker to gain access to that node. It can be also an action to prevent a node from providing a service or using a service on the network Attacker: a person who uses any node in the network to attack other nodes using known or unknown threats Threat: Anything that has a potential to harm a node in the network Local link vulnerability: Any flaws that are the result of the assumption that a malicious node could gain access to legitimate nodes inside a local link network Wide Area Network (WAN) vulnerability: Any flaws that are the result of the assumption that a malicious node could gain access to legitimate nodes inside any local links in an enterprise network with multiple Local Area Networks (LANs) or Virtual LANs (VLANs). Host name: Fully qualified DNS Name (FQDN) of a node in the network Rafiee, et al. Expires December 10, 2014 [Page 3] INTERNET DRAFT mDNS Threat Model June 10, 2014 Constrained device: a small device with limited resources (battery, memory, etc.) 3. Threat Analysis mDNS/DNS-SD cannot use DNSSEC approaches for security purposes. This is because, as mentioned earlier, DNSSEC is not a zero config protocol and it is not compatible with the plug and play nature of mDNS/DNS-SD. This is why mDNS is vulnerable to several attacks. Most threats in this section are a result of spoofing, Denial of Service (DoS), or a combination of them. Here we explain them in different example scenarios. 3.1. mDNS Gateway is a single point of failure An mDNS gateway needs to process all queries sent to/from different networks that this gateway is connected to and filters the traffic based on the policy explained in section 3.4 [mdns-extend]. A malicious node in any of these subnets can send several queries and carry out the DoS attack on these gateways. 3.2. Large Traffic Production from mDNS Gateway There are several scnearios associated with the Large Traffic Production case. First scenario: a malicious node in any of the subnets that the gateway connects can advertise different fake services or spoof the information of the real services and replay the messages. This causes large traffic either in the local link or in other links since the gateway was also supposed to replicate the traffic to other links. Second scenario : a malicious node spoofs the legitimate service advertisements of different nodes in the network and changes the Time To Leave (TTL) value to zero. This will result in producing large traffic since the mDNS gateway needs to ask all of the service advertisers to re-advertise their service. This is an especially effective attack in a network of constrained devices because it causes more energy consumption. Third scenario: Since a hybrid proxy [hybrid-proxy] node aggregates all data and sends it back to the requester, a malicious node can generate several queries that produce large responses, spoof the source or MAC address of a victim node in this network, and forward all traffic to this victim node. Forth scenario: A malicious node can replay hybrid proxy aggregation messages [hybrid-proxy] and cause a DoS on a victim node. Rafiee, et al. Expires December 10, 2014 [Page 4] INTERNET DRAFT mDNS Threat Model June 10, 2014 3.3. DoS attack on any node in the mDNS enabled network A malicious node spoofs the MAC address and source IP address of a legitimate victim node in this network and questions several services in the link. This will result in a large traffic return to the victim node from both mDNS gateway and also the service owner. A malicious node can send a spoofed service probe message and direct all traffic to any victim node to this network (section 3.5 [mdns-extend]). Second scenario: a malicious node claims the ownership of any name that the resource requester or a node uses and does not let the nodes choose a unique desired name for their service or for the devices. 3.4. Good mDNS gateway goes bad mDNS gateway is compromised and submits wrong information to the links to which it is connected. 3.5. Fake mDNS gateway A malicious node can play a role of gateway in any of those subnets and play a Man in the Middle (MITM) attack. Since the messages sent from gateway are usually unicast, no other nodes will detect these malicious activities of this fake gateway. (section 3.8.1 [mdns-extend]). This malicious node can then respond to any DNS-SD messages and play a role of passive gateway. 3.6. MAC address spoofing In a wireless environment where [mdns-extend] is suggested to use MAC address filtering to avoid any malicious node joining to the network, a malicious node can easily spoof the MAC address of a legitimate node and join the network and perform malicious activities. 3.6.1. possible solution Filtering can be based on the signature of the public key and MAC address of the devices . This process might be through manual adding of this signature to the whitelist filter. The verification is the process of verifying the signature signed by the private key and the public key signature. This solution might require some manual step and changes on the current implementation to filter based on this signature. 3.7. Cache Poisoning Rafiee, et al. Expires December 10, 2014 [Page 5] INTERNET DRAFT mDNS Threat Model June 10, 2014 mDNS gateway stores all of the information related to the available wireless nodes in its cache. In section 3.8.1 [mdns-extend], it is not clear how mDNS gateway knows when a node leaves a wireless link. If the node sends a "leave message" to mDNS gateway, a malicious node can send this message on behalf of a legitimate node and presume that that the legitimate node does not exist in that link, thereby causing delay or possible problems in offering service to that node. Second scenario: a malicious node can send a location update message to mDNS home gateway and cause delay in offering services to a legitimate node. Third scenario: similar to Mobile IPv6 [RFC6275] possible attacks, a malicious node can start large traffic from a streaming server and then send a fake ?location update message? to the home mDNS gateway and send a update message with a different, spoofed source IP address. This will forward all of the large streaming traffic to a victim node. Forth scenario: To decrease traffic in the network [hybrid-proxy], a hybrid proxy aggregates all answers received from different resources and sends a unicast DNS message on behalf of all of the resources to the resource requester. A malicious node can play the role of hybrid proxy and poison the cache of resource requester. 3.7.1. Possible solution IPsec can prevent this attack but it is not a zero configuration protocol and it needs a way to provide the initial trust between both end points of communication. 3.8. Malicious update on unicast DNS A malicious node can spoof the content of DNS update message and add malicious records to unicast DNS. 3.9. Harming Privacy If a malicious node is in any subnet (WLAN and WAN) of a network, it can learn about all services available in this network. The combination of mDNS and DNS-SD discloses some critical information about resources in this network which might be harmful to privacy. 3.10. IP spoofing A malicious node spoofs the content of Dynamic Host Configuration Protocol (DHCP) server messages and offers its own malicious information to the nodes in the network. Rafiee, et al. Expires December 10, 2014 [Page 6] INTERNET DRAFT mDNS Threat Model June 10, 2014 3.11. Resource spoofing Resource owners in the network have permission to have the same name for load balancing. A malicious node can claim to be one of the load balanced resource devices and maliciously respond to requests. 3.12. Internet Group Management Protocol (IGMP) Attacks IGMP that is suggested to be used in network bridging scenario [mdns-x] can be maliciously used by an attacker. Spoofing and DoS attacks are two sources of attack in IGMP protocol. A complete list of these attacks can be found in [IGMP-Attack]. 3.13. Multicast Listener Discovery (MLD) attacks The same as IGMP attacks, since these are signaling protocols, a simple DoS attack can use a lot of resources and produce large traffic. This is because a malicious node can send MLD to subscribe to a large number of high-bandwidth multicast groups. It can then cause bandwidth exhaustion, leading to a DoS. It might also lead to using more CPU resources on the nodes. This will be quite critical for constrained devices. 3.14. Fake Resource Advertisement A malicious node in any subnet can advertise fake resources. The other nodes have no possibility to authenticate this node and authorize its resources. This can happen in both mDNS gateway scenario and hybrid proxy [hybrid-proxy]. 3.15. Dual stack attacks Having both IPv4 and IPv6 in the same network and trying to aggregate service discovery traffic on both IP stacks might cause new security flaws during the conversion or aggregation of this traffic. It can be similar to what explained here as an aggregated traffic or lead to a wide range of spoofing attacks. 4. Possible solutions Since spoofing is the main source of attacks for many malicious activities, using approaches that can prevent IP spoofing or provide a means of secure authentication with minimum configuration is helpful. 4.1. SAVI-DHCP Rafiee, et al. Expires December 10, 2014 [Page 7] INTERNET DRAFT mDNS Threat Model June 10, 2014 SAVI-DHCP [DHCP-SAVI] approach uses a simple mechanism in switches or devices that knows information about the ports of switches to filter any malicious traffic. This mitigates attacks on DHCP server spoofing 4.2. DNS over TLS The approaches in this category are discussed in DANE WG. It might be a good solution to automate the authentication processes or avoid spoofed DNS update messages 4.3. CGA-TSIG CGA-TSIG [cga-tsig] is another possible solution that can provide the node with secure authentication, data integrity and data confidentiality. The new version supports both IPv4 and IPv6. It provides the node with zero or minimal configuration. 4.4. DNS Security Extension Due to the manual step requirement for DNSSEC configuration on each nodes and DNS servers, it is not an ideal solution mechanism for zero config services. 4.5. SSAS SSAS [ssas] can prevent the nodes from IP spoofing. This is dissimilar to other approach, CGA [RFC3972] that can only support IPv6 networks. The new version of this document supports both IPv4 and IPv6. It also offers a solution for MAC spoofing, however, due to operational barriers, MAC spoofing solution might not work well. 4.6. IPsec IPsec is another security protection mechanism. Similar to DNSSEC, it requires manual step for the configuration of the nodes. However, recently there are some new drafts to automate this process. 5. Security Considerations There is no security consideration 6. IANA Considerations There is no IANA consideration Rafiee, et al. Expires December 10, 2014 [Page 8] INTERNET DRAFT mDNS Threat Model June 10, 2014 7. Acknowledgements The author would like to thank all those people who directly helped in improving this draft, especially John C. Klensin 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6762] Cheshire, S., Krochmal, M.,"Multicast DNS", RFC 6762, February 2013 [RFC6763] Cheshire, S., Krochmal, M., "DNS-Based Service Discovery", RFC 6763, February 2013 [RFC6275] Perkins, C., Johnson, D., Arkko, J., "Mobility Support in IPv6", RFC 6275, July 2011 [RFC3833] Atkins, D., Austein, R., "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004 8.2. Informative References [mdns-extend] Bhandari, S., Fajalia, B., Schmieder, R., Orr, S., Dutta, A., "Extending multicast DNS across local links in Campus and Enterprise networks", http://tools.ietf.org/html/draft-bhandari-dnssd-mdns-gateway-00, October 2013 [mdns-x] Otis, D., "mDNS X-link review", http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-03, April 2014 [IGMP-Attack] http://www.securemulticast.org/GSEC/gsec3_ietf53_SecureIGMP1.pdf [hybrid-proxy] Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service Discovery", http://tools.ietf.org/html/draft-cheshire-dnssd-hybrid-01, January 2014 [DHCP-SAVI] Bi, J., Wu, J., Yao, G, Baker, F.,"SAVI Solution for DHCP", http://tools.ietf.org/html/draft-ietf-savi-dhcp-23, April Rafiee, et al. Expires December 10, 2014 [Page 9] INTERNET DRAFT mDNS Threat Model June 10, 2014 2014 [cga-tsig] Rafiee, H., Loewis, M., Meinel, C.,"Transaction SIGnature (TSIG) using CGA Algorithm in IPv6", http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig , February 2014 [ssas] Rafiee, H., Meinel, C., "SSAS: a Simple Secure Addressing Scheme for IPv6 AutoConfiguration". http://tools.ietf.org/search/draft-rafiee-6man-ssas, 2013 Rafiee, et al. Expires December 10, 2014 [Page 10] INTERNET DRAFT mDNS Threat Model June 10, 2014 Authors' Addresses Hosnieh Rafiee http://www.rozanak.com Phone: +49 176 57 58 75 75 Email: ietf@rozanak.com Rafiee, et al. Expires December 10, 2014 [Page 11]