Subject: LLMNR Issue 94: Security Considerations

From: Bernard Aboba <[email-masked]>
Date: Tue, 26 Jul 2005 00:31:20 -0700 (PDT)

Issue 94: Security Considerations
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: July 20, 2005
Reference:
Document: LLMNR-41
Comment type: T
Priority: S
Section: 5
Rationale/Explanation of issue:

The Security Considerations section appears to be out of date.  It
refers to setting TTL=1 in multicast queries (no longer recommended),
and does not mention the measures taken to avoid the reception of
LLMNR queries from off-link attackers.

Also, the authentication section does not make it clear that the
LLMNR can support existing DNS security mechanisms such as TSIG
(this has actually been implemented), provided that a suitable
trust model can be deployed.

The proposed resolution is to replace Section 5 with the following:

"5.  Security Considerations

   LLMNR is a peer-to-peer name resolution protocol designed for use on
   the local link.  While LLMNR attempts to limit the vulnerability to
   off-link senders, the risk from off-link responders is more difficult
   to contain.

   In scenarios such as public "hotspots" attackers can be present on
   the same link.  These threats are most serious in wireless networks
   such as 802.11, since attackers on a wired network will require
   physical access to the home network, while wireless attackers may
   reside outside the home.  Link-layer security can be of assistance
   against these threats if it is available.

   This section details security measures available to mitigate threats
   from on and off-link attackers.

5.1.  Authentication

   LLMNR is a peer-to-peer name resolution protocol, and as a result,
   it is often deployed in situations where no trust model can be
   assumed.  This makes it difficult to apply existing DNS security
   mechanisms to LLMNR.

   It is difficult to use DNSSEC with LLMNR since LLMNR does not support
   "delegated trust" (CD or AD bits) and LLMNR and DNS resolver
   implementations utilize separate caches.  As a result, unless LLMNR
   senders are DNSSEC aware and all required RRs can be obtained via
   LLMNR queries, use of DNSSEC with LLMNR is not feasible.

   If authentication is desired, and a pre-arranged security
   configuration is possible, then the following security mechanisms may
   be used:

[a]  LLMNR implementations MAY support TSIG and/or SIG(0) security
     mechanisms. "DNS Name Service based on Secure Multicast DNS for
     IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes the use of TSIG
     to secure LLMNR responses, based on group keys.

[b]  IPsec ESP with a null-transform MAY be used to authenticate unicast
     LLMNR queries and responses or LLMNR responses to multicast
     queries.  In a small network without a certificate authority, this
     can be most easily accomplished through configuration of a group
     pre-shared key for trusted hosts.

   Where these mechanisms cannot be supported, responses to LLMNR
   queries may be unauthenticated.

5.2.  Scope Restriction

   LLMNR is designed to prevent reception of queries sent by an off-link
   attacker.  LLMNR requires that responders receiving UDP queries check
   that they are sent to a link-scope multicast address; responders
   receiving TCP queries set TTL to one, to prevent successful setup of
   connections by an off-link sender.  However, it is possible that some
   routers may not properly implement link-scope multicast, or that
   link-scope multicast addresses may leak into the multicast routing
   system.

   While it is difficult for an off-link attacker to send a query to a
   responder,  it is still possible for an attacker to spoof a response
   to a query (such as an A or AAAA query for a popular Internet host),
   and by using a TTL or Hop Limit field larger than one (1), for the
   forged response to reach the LLMNR sender.

   Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than
   one in an LLMNR UDP response may enable denial of service attacks
   across the Internet.  However, since LLMNR responders only respond to
   queries for which they are authoritative, and LLMNR does not provide
   wildcard query support, it is believed that this threat is minimal.

5.3.  Denial of Service and Forgery

   With LLMNR it is possible that responders will allocate conflicting
   names for a period of time, and as a result LLMNR supports conflict
   detection.  Attackers may take advantage of this by allocating the
   same name, denying service to other LLMNR responders, or allowing an
   attacker to receive packets destined for other hosts.

   Since an LLMNR queries can be sent when DNS server(s) do not respond,
   an attacker can execute a denial of service attack on the DNS
   server(s) and then poison the LLMNR cache by responding to an LLMNR
   query with incorrect information.  To some extent, these
   vulnerabilities exist today, since DNS response spoofing tools are
   available that can allow an attacker to respond to a query more
   quickly than a distant DNS server.

   Since LLMNR queries are sent and responded to on the local-link, an
   attacker will need to respond more quickly to provide its own
   response prior to arrival of the response from a legitimate
   responder.  If an LLMNR query is sent for an off-link host, spoofing
   a response in a timely way is not difficult, since a legitimate
   response will never be received.

   The vulnerability is more serious if LLMNR is given higher priority
   than DNS among the enabled name resolution mechanisms.  In such a
   configuration, a denial of service attack on the DNS server would not
   be necessary in order to poison the LLMNR cache, since LLMNR queries
   would be sent even when the DNS server is available.  In addition,
   the LLMNR cache, once poisoned, would take precedence over the DNS
   cache, eliminating the benefits of cache separation.  As a result,
   LLMNR is only used as a name resolution mechanism of last resort.

5.4.  Cache and Port Separation

   In order to prevent responses to LLMNR queries from polluting the DNS
   cache, LLMNR implementations MUST use a distinct, isolated cache for
   LLMNR on each interface.  The use of separate caches is most
   effective when LLMNR is used as a name resolution mechanism of last
   resort, since this minimizes the opportunities for poisoning the
   LLMNR cache, and decreases reliance on it.

   LLMNR operates on a separate port from DNS, reducing the likelihood
   that a DNS server will unintentionally respond to an LLMNR query."

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>