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]