[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LLMNR Issue 94: Security Considerations
Issue 94: Security Considerations
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>