Multicast DNS (mDNS) Threat Model and Security Consideration
draft-rafiee-dnssd-mdns-threatmodel-00

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
              <draft-rafiee-dnssd-mdns-threatmodel-00.txt>

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]