Subject: LLMNR Issue 49: Security considerations

From: Bernard Aboba <[email-masked]>
Date: Sat, 27 Sep 2003 05:36:07 -0700 (PDT)

Issue 49: Security considerations
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: September  26, 2003
Reference:
Document: LLMNR-23
Comment type: T
Priority: S
Section: 5
Rationale/Explanation of issue:

The security considerations section needs to be updated to provide
a more complete discussion of denial of service and spoofing
attacks.

Replace Section 5 with the following:

"5. Security Considerations

LLMNR is by nature a peer-to-peer name resolution protocol. It is
therefore inherently more vulnerable than DNS, since existing DNS
security mechanisms are difficult to apply to LLMNR. While tools
exist to alllow an attacker to spoof a response to a DNS query,
spoofing a response to an LLMNR query is easier since the query
is sent to a link-scope multicast address, which can propagate
to multiple switch ports.

In order to address the security vulnerabilities, the following
mechanisms are contemplated:

[1] Scope restrictions.

[2] Usage restrictions.

[3] Cache and port separation.

[4] Authentication.

These techniques are described in the following sections.

5.1. Scope restriction

With LLMNR it is possible that hosts will allocate conflicting names for
a period of time, or that attackers will attempt to deny service to
other hosts by allocating the same name. Such attacks also allow hosts
to receive packets destined for other hosts.

Since LLMNR is typically deployed in situations where no trust model can
be assumed, it is likely that LLMNR queries and responses will be
unauthenticated. In the absence of authentication, LLMNR reduces the
exposure to such threats by utilizing queries sent to a link-scope
multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6)
fields to one (1) on both queries and responses.

A TTL of one (1) was chosen so as to limit the likelihood that LLMNR
can be used to launch denial of service attacks. For example, were
the TTL of an LLMNR Response to be set to a value larger than
one (1), an attacker could send a large volume of queries from a
spoofed source address, causing an off-link target to be deluged
with responses.

Utilizing a TTL of one (1) in LLMNR responses ensures that they
will not be forwarded off-link. Using a TTL of one (1) to set up
a TCP connection in order to send a unicast LLMNR query reduces the
likelihood of both denial of service attacks and spoofed responses.
Checking that an LLMNR query is sent to a link-scope multicast address
should prevent spoofing of multicast queries by off-link attackers.

While this limits the ability of off-link attackers to spoof LLMNR
queries and responses, it does not eliminate it. For example, it is
possible for an attacker to spoof a response to a frequent query (such
as an A/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. There also are scenarios such as public "hotspots" where
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.

5.2. Usage restrictions

As noted in Section 3, LLMNR is intended for usage in a limited set of
scenarios.

While LLMNR can be used to resolve any name, if an interface has been
configured with DNS server address(es), then LLMNR SHOULD NOT be used
as the primary name resolution mechanism on that interface, although
it MAY be used as a name resolution mechanism of last resort.

If an LLMNR query is sent whenever a DNS server does not respond
in a timely way, then an attacker can poison the LLMNR cache
by responding to the 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.

Note: enabling LLMNR for use in situations where a DNS server has been
configured will result in upgraded hosts changing their default behavior
without a simultaneous update to configuration information. Where this
is considered undesirable, LLMNR SHOULD NOT be enabled by default, so
that hosts will neither listen on the link-scope multicast address, nor
will they send queries to that address.

5.3. 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.

5.4. Authentication

LLMNR does not require use of DNSSEC, and as a result, responses to
LLMNR queries may be unauthenticated. If authentication is desired, and
a pre-arranged security configuration is possible, then IPsec ESP with a
null-transform MAY be used to authenticate LLMNR responses. 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."

--
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/>