Proposed Resolution of LLMNR Issue 78: UNIQUEness probing

[Bernard Aboba <aboba@internaut.com>]

LLMNR Issue 78, raised during the AD review, concerns the reliability of
the LLMNR uniqueness verification mechanism.  The LLMNR Issues list is
available at:

http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

A version of the LLMNR specification with the proposed resolution of Issue
78 included is available at:

http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-38.txt

A discussion of the issue and the proposed resolution follows.

There are two major scenarios in which LLMNR does not detect name
conflicts:

1. When two or more hosts with conflicting names are simultaneously
verifying uniqueness. As currently specified, LLMNR will allow conflicting
hosts to conclude that no conflict exists, since a responder cannot answer
a query until it has verified uniqueness. If two hosts are simultaneously
probing uniqueness, then neither can respond to each other's queries.

2. When a previously partitioned network heals, revealing one or more
name conflicts. As currently specified, LLMNR does not detect these
conflicts since uniqueness verification is not done periodically and
responses are sent via unicast, not multicast.

Several approaches suggest themselves:

a) Have senders include their UNIQUE RRs within all queries.
This would allow another host receiving such a query
to determine if a conflict was present. This not only
addresses scenario 1, but also scenario 2.

b) Add a UNIQUE flag to queries, to distinguish
uniqueness verification probes. While this would
address scenario 1 by allowing hosts to recognize
a conflict during uniqueness verification, it would
not help with Scenario 2.

c) Attempt to utilize the source address to distinguish
uniqueness verification queries. However, since LLMNR
queries can be sent from any address, there is no way
to determine whether a uniqueness verification probe
is being sent, based on the source address.

d) On receipt of a query for a UNIQUE name, have a
sender backoff further queries for a random time period.

The problem with this approach is that uniqueness
verification is done for each UNIQUE RR. In the event that
two or more hosts conflict with respect to multiple RRs,
all conflicts need to be resolved the same way. A simple
random backoff strategy does not achieve this, because
LLMNR-37 Section 4 only says that:

"If a response is received, the responder MUST NOT use the
UNIQUE resource record in response to LLMNR queries."

Therefore a random backoff strategy could result in
conflicting hosts splitting ownership of the UNIQUE RRs,
which is undesirable.

As a result, it appears that approach a) is the most
general one.

The proposed resolution is as follows:

At the end of Section 2.2, add the following text:

"In order to enable conflict detection, senders SHOULD
include UNIQUE RRs within the additional section of LLMNR queries."

In Section 2.3, change:

"[g] If a responder is authoritative for a name, it SHOULD respond with
RCODE=0 and an empty answer section, if the type of query does not
match a RR that the responder has."

To:

"[g] Responders MUST check the additional section of LLMNR queries for
potential name conflicts, as described in Section 4.1 and 4.2, regardless
of whether the responder is authoritative for the name being
queried.

[h] If a responder is authoritative for a name, it SHOULD respond with
RCODE=0 and an empty answer section, if the type of query does not
match a RR that the responder has."

In Section 2.9, change:

" In LLMNR, the additional section is only intended for use by EDNS0,
TSIG and SIG(0). As a result, senders MAY only include pseudo RR-
types in the additional section of a query; responders MUST ignore
the additional section of queries containing other RR types.

Senders MUST NOT cache RRs from the authority or additional section
of a response as answers, though they may be used for other purposes
such as negative caching."

To:

"Senders MUST NOT cache RRs from the authority or additional section
of a response as answers, though they may be used for other purposes
such as negative caching. Responders MUST NOT cache RRs from the
authority or additional section of a query as answers."

Replace Section 4 with the following:

"4. Conflict resolution

The uniqueness of a resource record depends on the nature of the name
in the query and type of the query. For example it is expected that:

- multiple hosts may respond to a query for an SRV type record
- multiple hosts may respond to a query for an A or AAAA type
record for a cluster name (assigned to multiple hosts in
the cluster)
- only a single host may respond to a query for an A or AAAA
type record for a name.

By default, a responder SHOULD be configured to behave as though all
RRs are UNIQUE on each interface on which LLMNR is enabled.

When name conflicts are detected, they SHOULD be logged. To detect
duplicate use of a name, an administrator can use a name resolution
utility which employs LLMNR and lists both responses and responders.
This would allow an administrator to diagnose behavior and
potentially to intervene and reconfigure LLMNR responders who should
not be configured to respond to the same name.

4.1. Uniqueness Verification

Prior to including a UNIQUE resource record in a response, for each
UNIQUE resource record in a given interface's configuration, the host
MUST verify that there is no other host within the scope of LLMNR
query propagation that can return a resource record for the same
name, type and class on that interface. Once a responder has
verified the uniqueness of a UNIQUE resource record, if it receives
an LLMNR query for that resource record, it MUST respond.

Uniqueness verification is carried out when the host:

- starts up or is rebooted
- wakes from sleep (if the network interface was inactive
during sleep)
- is configured to respond to LLMNR queries on an interface
enabled for transmission and reception of IP traffic
- is configured to respond to LLMNR queries using additional
UNIQUE resource records
- verifies the acquisition of a new IP address and configuration
on an interface

To verify uniqueness, a responder MUST send an LLMNR query for each
UNIQUE resource record, placing its own UNIQUE resource record(s) in
the additional section. The responder can use the UNIQUE resource
record in response to LLMNR queries if both of the following
conditions are satisfied:

- No response is received after a suitable number of attempts
(see Section 2.7) AND
- No LLMNR query is received containing a conflicting resource
record within the additional section.

If a response is received, or if an LLMNR query is received
containing a conflicting resource record within the additional
section, the responder MUST NOT use the UNIQUE resource record in
response to LLMNR queries.

Periodically carrying out uniqueness verification in an attempt to
detect name conflicts is not necessary, wastes network bandwidth, and
may actually be detrimental. For example, if network links are joined
only briefly, and are separated again before any new communication is
initiated, temporary conflicts are benign and no forced
reconfiguration is required. Triggering a reconfiguration in this
case would not serve any useful purpose. LLMNR responders SHOULD NOT
periodically attempt uniqueness verification.

4.2. Conflict Detection and Defense

Hosts on disjoint network links may configure the same name for use
with LLMNR. If these separate network links are later joined or
bridged together, then there may be multiple hosts which are now on
the same link, trying to use the same name. These conflicts may not
be detected by the uniqueness verification procedure described in
Section 4.1.

In order to be able to detect conflicts arising from healing of a
network partition, conflict detection is an ongoing process. Since
LLMNR responses are always sent via unicast, only LLMNR queries can
be used to detect name conflicts. When conflicting hosts attempt to
communicate with any other host on the network, they will at some
point multicast an LLMNR query which will enable the conflict to be
detected. Conflict detection requires LLMNR responders to check the
additional section of a query for conflicting resource records, in
addition to examining the query section in order to determine whether
to respond.

Whenever an LLMNR responder receives an LLMNR query with resource
records in the additional section, the responder checks the resource
records against the UNIQUE resource records configured on the
interface on which the query was received. If the resource record is
found to contain the same name as in a UNIQUE resource record of the
same type, but the source IP address within the LLMNR query does not
match an IP address configured on that interface, then this indicates
a conflict.

An LLMNR responder MUST NOT ignore conflicting LLMNR queries. An
LLMNR responder MUST respond to conflicting LLMNR queries as
described in either [a] or [b] below:

[a] Upon detecting a conflict, an LLMNR responder MAY elect to
immediately stop using the conflicting UNIQUE resource record in
response to LLMNR queries.

The responder MAY also elect to configure a new name. However,
since name reconfiguration may be disruptive, this is not required,
and a responder may have been configured to respond to multiple
names so that alternative names may already be available.

[b] If a responder currently has active TCP connections or other
reasons to prefer to keep using the name, and it has not seen any
other conflicting LLMNR queries within the last DEFEND_INTERVAL
seconds, then it MAY elect to defend its name, by recording the
time that the conflicting LLMNR query was received, and then
sending multicast queries for its UNIQUE resource records, with its
UNIQUE resource records included in the additional section.

Having done this, an LLMNR responder can then continue to use the
name normally without any further special action. However, if this
is not the first conflicting LLMNR query the responder has seen,
and the time recorded for the previous conflicting LLMNR query is
recent, within DEFEND_INTERVAL, then the LLMNR responder MUST
immediately cease using the conflicting resource records.

This is necessary to ensure that two hosts do not get stuck in an
endless loop with both hosts trying to defend the same name.

4.3. Considerations for Multiple Interfaces

A multi-homed host may elect to configure LLMNR on only one of its
active interfaces. In many situations this will be adequate.

However, should a host need to configure LLMNR on more than one of
its active interfaces, there are some additional precautions it MUST
take. Implementers who are not planning to support LLMNR on multiple
interfaces simultaneously may skip this section.

Where a host is configured to issue LLMNR queries on more than one
interface, each interface maintains its own independent LLMNR
resolver cache, containing the responses to LLMNR queries.

A multi-homed host checks the uniqueness of UNIQUE records as
described in Sections 4.1 and 4.2. The situation is illustrated in
figure 1.

---------- ----------
 |       | |       |
[A]    [myhost] [myhost]

Figure 1. Link-scope name conflict

In this situation, the multi-homed myhost will probe for, and defend,
its host name on both interfaces. A conflict will be detected on one
interface, but not the other. The multi-homed myhost will not be
able to respond with a host RR for "myhost" on the interface on the
right (see Figure 1). The multi-homed host may, however, be
configured to use the "myhost" name on the interface on the left.

Since names are only unique per-link, hosts on different links could
be using the same name. If an LLMNR client sends requests over
multiple interfaces, and receives replies from more than one, the
result returned to the client is defined by the implementation. The
situation is illustrated in figure 2.

---------- ----------
 |       | |       |
[A]    [myhost]   [A]


Figure 2. Off-segment name conflict

If host myhost is configured to use LLMNR on both interfaces, it will
send LLMNR queries on both interfaces. When host myhost sends a
query for the host RR for name "A" it will receive a response from
hosts on both interfaces.

Host myhost cannot distinguish between the situation shown in Figure
2, and that shown in Figure 3 where no conflict exists.

    [A]
    | |
----- -----
    | |
  [myhost]

Figure 3. Multiple paths to same host

This illustrates that the proposed name conflict resolution mechanism
does not support detection or resolution of conflicts between hosts
on different links. This problem can also occur with unicast DNS
when a multi-homed host is connected to two different networks with
separated name spaces. It is not the intent of this document to
address the issue of uniqueness of names within DNS.

4.4. API issues

[RFC2553] provides an API which can partially solve the name
ambiguity problem for applications written to use this API, since the
sockaddr_in6 structure exposes the scope within which each scoped
address exists, and this structure can be used for both IPv4 (using
v4-mapped IPv6 addresses) and IPv6 addresses.

Following the example in Figure 2, an application on 'myhost' issues
the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
interfaces and the resolver library will return a list containing
multiple addrinfo structures, each with an associated sockaddr_in6
structure. This list will thus contain the IPv4 and IPv6 addresses
of both hosts responding to the name 'A'. Link-local addresses will
have a sin6_scope_id value that disambiguates which interface is used
to reach the address. Of course, to the application, Figures 2 and 3
are still indistinguishable, but this API allows the application to
communicate successfully with any address in the list."

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