Subject: LLMNR Issue 101: Comments on -43

From: Bernard Aboba <[email-masked]>
Date: Wed, 14 Sep 2005 17:20:12 -0700 (PDT)

Issue 101: Comments on -43
Submitter: Yi Zhao
Submitter email address: [email-masked]
Date first submitted: September 11, 2005
Reference: 
Document: LLMNR-43
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Section 1.2

The term "Positively resolved" is not used in -43. I suggest it be 
deleted. 

Section 2

"For example, a sender configured with a DNS server MAY send LLMNR queries
only for unqualified names or for fully qualified names within configured
zones."

I think you mean "for single-label names" instead of unqualified names, 
right? Suggest changing to: 

"For example, by default a sender MAY send LLMNR queries
only for single-label names and for fully qualified domain names
within configured zones."

Section 2.1.1

TC bit

"If the TC bit is set in an LLMNR response,
then the sender SHOULD resend the LLMNR query over TCP using the
unicast address of the responder as the destination address. If
the sender receives a response to the TCP query, then it SHOULD
discard the UDP response with the TC bit set."

Does this make sense? It is possible that the TCP query
will not be answered, in which case the sender would have discarded
the UDP response and would have nothing.  I suggest the following:

"If the TC bit is set in an LLMNR response, then the sender SHOULD 
resend the LLMNR query over TCP using the unicast address of the
responder as the destination address. If the sender receives a response
over TCP, then it SHOULD discard the UDP response with the TC bit set."

RCODE

"    If an LLMNR responder is authoritative for the name in a multicast
     query, but an error is encountered, the responder SHOULD send an
     LLMNR response with an RCODE of zero, no RRs in the answer section,
     and the TC bit set.  This will cause the query to be resent using
     TCP, and allow the inclusion of a non-zero RCODE in the response to
     the TCP query.  Responding with the TC bit set is preferable to not
     sending a response, since it enables errors to be diagnosed.
     Errors include those defined in [RFC2845], such as BADSIG(16),
     BADKEY(17) and BADTIME(18)."

This paragraph could be more descriptive. For example, you could
refer to specific TSIG errors such as RCODE=1 (FORMERR) 
(TSIG RR in an unacceptable position), or RCODE=9 (NOAUTH) 
with TSIG ERROR 17 (BADKEY) or 16 (BADSIG). 

My suggestion is to change the paragraph to the following:

" If an LLMNR responder is authoritative for the name in a multicast
query, but an error is encountered, the responder SHOULD send an
LLMNR response with an RCODE of zero, no RRs in the answer section,
and the TC bit set. This will cause the query to be resent using
TCP, and allow the inclusion of a non-zero RCODE in the response to
the TCP query. Responding with the TC bit set is preferable to not
sending a response, since it enables errors to be diagnosed. 
This may be required, for example, when an LLMNR query includes
a TSIG RR in the additional section, and the responder encounters
a problem that requires returning a non-zero RCODE. TSIG error
conditions defined in [RFC2845] include a TSIG RR in an unacceptable 
position (RCODE=1) or a TSIG RR which does not validate (RCODE=9 with 
TSIG ERROR 17 (BADKEY) or 16 (BADSIG))."

2.2 Sender Behavior

This section does not say whether retransmissions should use the same
ID field or not. If an LLMNR query is sent over multiple interfaces,
should the same ID field be used? Perhaps this is implementation
dependent?

2.3 Responder Behavior

"[a] Responders MUST listen on UDP port 5355 on the link-scope multicast
address(es) defined in Section 2, and on UDP and TCP port 5355 on
the unicast address(es) that could be set as the source address(es)
when the responder responds to the LLMNR query."

But UDP unicast queries are prohibited, no?  I suggest changing to:

"[a] Responders MUST listen on UDP port 5355 on the link-scope multicast
address(es) defined in Section 2, and on TCP port 5355 on
the unicast address(es) that could be set as the source address(es)
when the responder responds to the LLMNR query."

"An SOA RR is synthesized only when a responder has another RR in 
addition to the SOA RR; the SOA RR MUST NOT be the only RR that the
responder has." 

The specification only mentions returning the SOA in the additional
section of a negative response. In this case, the SOA RR can be
synthesized on the fly. 

Or was this sentence inserted so that a responder should not respond to 
an LLMNR query for type = "ANY" if it only has an SOA RR, but 
no other RRs?

2.4 Unicast Queries and Responses

"If TCP connection setup cannot be completed in order to send a 
unicast TCP query, this is treated as a response that no records 
of the specified type and class exist for the specified name (it 
is treated the same as a response with RCODE=0 and an empty answer
section)." 

This looks wrong. If TCP connection setup cannot be completed after
a response is returned via UDP with the TC bit set, then the sender
should just use the UDP response. If TCP connection setup fails
for a PTR RR query, it means that the responder does not reside
on the link. This is equivalent to RCODE=3 (no such name), not
ROCDE=0. 

Also, as I understand it, the point of using TCP instead of
multicast UDP for PTR RR queries is to improve performance. 
Many PTR RR queries will not be answered, so that if you
use multicast UDP then the sender will retransmit, requiring
multiple timeouts. However, if TCP is used with TTL=1, 
an ICMP TTL exceeded message will be received if the
destination is off-link, so that the TCP connection can be aborted
earlier. However, this requires the implementation to
process ICMP TTL exceeded messages; TCP implementations
typically treat this as a soft error and do not abort the
connection setup. If a sender implementation cannot easily do this 
(e.g. if it does not have rights to open a raw socket),
then it seems to me that there is no advantage to using
TCP for PTR RR queries.

Suggest that Section 2.4 be changed to the following:

"2.4. Unicast Queries and Responses

Unicast queries SHOULD be sent when:

[a] A sender repeats a query after it received a response
with the TC bit set to the previous LLMNR multicast query, or

[b] The sender queries for a PTR RR of a fully formed IP address
within the "in-addr.arpa" or "ip6.arpa" zones.

Unicast LLMNR queries MUST be done using TCP and the responses MUST
be sent using the same TCP connection as the query. Senders MUST
support sending TCP queries, and responders MUST support listening
for TCP queries. If the sender of a TCP query receives a response to
that query not using TCP, the response MUST be silently discarded.

Unicast UDP queries MUST be silently discarded.

A unicast PTR RR query for an off-link address will not elicit a
response, but instead an ICMP TTL or Hop Limit exceeded message will
be received. An implementation receiving an ICMP message in response
to a TCP connection setup attempt can return immediately, treating
this as a response that no such name exists (RCODE=3 is returned).
An implementation that cannot process ICMP messages MAY
send multicast UDP queries for PTR RRs. Since TCP implementations will not
retransmit prior to RTOmin, a considerable period will elapse before
TCP retransmits multiple times, resulting in a long timeout for 
TCP PTR RR queries sent to an off-link destination."

2.5 "Off Link" Detection

"However, it is recommended that the value 255 be used for compatibility
with Apple Bonjour [Bonjour]."

Using a TTL of 255 will not make LLMNR compatible with Bonjour's mDNS. 
Or is the issue compatibility with Apple's IPv4 Link Local implementation,
which tests for TTL=255?  Perhaps this sentence should be removed? 

2.7 Retransmission and Jitter

"while increasing the value of LLMNR_TIMEOUT exponentially"

Why? Using multiplicative increase just increases the total timeout.
I suggest these words be deleted. 

"A unicast query sender considers the query answered after the first
response is received, so it only waits for LLMNR_TIMEOUT if no response
has been received."

Unicast queries are only sent over TCP not UDP. Are you saying that
a query sent over TCP should be aborted after LLMNR_TIMEOUT? This doesn't
make sense if LLMNR_TIMEOUT < RTOmin, because the TCP implementation won't
have retransmitted even once before the connection is aborted. I suggest 
that "so it only waits.." be deleted. 

"However, if the first response has the 'C' bit set, then the sender
SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses."

If a response is received with the 'C' bit set, is it sufficient to only
wait for LLMNR_TIMEOUT to receive all responses? If LLMNR_TIMEOUT is
set to a low value (100 ms) it might make sense to wait longer to collect
all responses, particularly since non-unique responses will have jitter 
added to them. I recommend this be changed to "LLMNR_TIMEOUT +
JITTER_INTERVAL." 

2.9 Use of the Authority and Additional Sections

"In queries where the 'C' bit is set, the sender SHOULD include the 
conflicting RRs in the additional section."

Why? The responder will not look at the additional section, it will
just begin UNIQUEness detection. Is this only for debugging purposes?

3. Usage Model

In this section it is probably worth saying that resolvers implementing 
both DNS and LLMNR should not send DNS queries for single-label names. 
That way if a user types in "http://foo/" a DNS query will not be sent for 
"foo." although DNS queries will be composed via the searchlist. 

Suggest the following sentence be added to Section 3:

"In order to reduce unnecessary DNS queries, stub resolvers 
supporting both DNS and LLMNR SHOULD avoid sending DNS queries
for single-label names."

5.3 Authentication

Suggest deleting the paragraph starting "LLMNR does not support..."

and adding an element [c]:

"[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order
to support DNSSEC, LLMNR implementations may be configured with 
trust anchors, or they may make use of keys
obtained from DNS queries.  Since LLMNR does not support 
"delegated trust" (CD or AD bits), LLMNR implementations 
cannot make use of DNSSEC unless they are DNSSEC aware."

Section 6

I think you need to say that the rights to use an FQDN name in
LLMNR derives from the right to use the same name within DNS. 

My recommendation is that Section 6 be rewritten as follows:

"6. IANA Considerations

LLMNR requires allocation of port 5355 for both TCP and UDP.

LLMNR requires allocation of link-scope multicast IPv4 address
224.0.0.252, as well as link-scope multicast IPv6 address
FF02:0:0:0:0:0:1:3.

This specification creates two new name spaces: the LLMNR namespace
and the reserved bits in the LLMNR header. The reserved bits in the
LLMNR header are allocated by IETF Consensus, in accordance with BCP
26 [RFC2434].

In order to to avoid creating any new administrative procedures,
administration of the LLMNR namespace will piggyback on the
administration of the DNS and NETBIOS namespaces.

The rights to use a given LLMNR name are obtained coincident with
acquiring the rights to use a particular name within NETBIOS or DNS.
NETBIOS names, defined in [RFC1001], are single-label names that are
not required to be globally unique. Those wishing to use a fully
qualified domain name (FQDN) within LLMNR should first acquire the
rights to use the corresponding FQDN within DNS. Using an LLMNR name
without ownership of the corresponding name in DNS or NETBIOS creates
the possibility of conflict and therefore is to be discouraged."

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 29 Sep 2005 20:55:12 -0700 (PDT)

The proposed resolution is to accept the proposed changes, and in 
addition:

Change Section 2 to the following:

"2.  Name Resolution Using LLMNR

   LLMNR queries are sent to and received on port 5355.  The IPv4 link-
   scope multicast address a given responder listens to, and to which a
   sender sends queries, is 224.0.0.252.  The IPv6 link-scope multicast
   address a given responder listens to, and to which a sender sends all
   queries, is FF02:0:0:0:0:0:1:3.

   Typically a host is configured as both an LLMNR sender and a
   responder.  A host MAY be configured as a sender, but not a
   responder.  However, a host configured as a responder MUST act as a
   sender, if only to verify the uniqueness of names as described in
   Section 4.  This document does not specify how names are chosen or
   configured.  This may occur via any mechanism, including DHCPv4
   [RFC2131] or DHCPv6 [RFC3315].

   A typical sequence of events for LLMNR usage is as follows:

   [a]  An LLMNR sender sends an LLMNR query to the link-scope
        multicast address(es), unless a unicast query is indicated,
        as specified in Section 2.4.

   [b]  A responder responds to this query only if it is authoritative
        for the name in the query.  A responder responds to a
        multicast query by sending a unicast UDP response to the sender.
        Unicast queries are responded to as indicated in Section 2.4.

   [c]  Upon reception of the response, the sender processes it.

   The sections that follow provide further details on sender and
   responder behavior."

In Section 2.5, change:

"  For UDP queries and responses, the Hop Limit field in the IPv6 header
   and the TTL field in the IPV4 header MAY be set to any value.
   However, it is RECOMMENDED that the value 255 be used for
   compatibility with Apple Bonjour [Bonjour]."

to:

"  For UDP queries and responses, the Hop Limit field in the IPv6 header
   and the TTL field in the IPV4 header MAY be set to any value.
   However, it is RECOMMENDED that the value 255 be used for
   compatibility with early implementations of [RFC3927]."

Change Section 3 to the following:

"3.  Usage Model

   LLMNR is a peer-to-peer name resolution protocol that is not intended
   as a replacement for DNS.  By default, an LLMNR sender SHOULD send
   LLMNR queries only for single-label names.  In order to reduce
   unnecessary DNS queries, stub resolvers supporting both DNS and LLMNR
   SHOULD avoid sending DNS queries for single-label names.  An LLMNR
   sender SHOULD NOT be enabled to send a query for any name, except
   where security mechanisms (described in Section 5.3) can be utilized.

   If LLMNR is given higher priority than DNS among the enabled name
   resolution mechanisms, 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, and queries SHOULD NOT be sent unless one of the following
   conditions are met:

   [1] No manual or automatic DNS configuration has been performed.
       If DNS server address(es) have been configured, a
       host SHOULD attempt to reach DNS servers over all protocols
       on which DNS server address(es) are configured, prior to sending
       LLMNR queries.  For dual stack hosts configured with DNS server
       address(es) for one protocol but not another, this implies that
       DNS queries SHOULD be sent over the protocol configured with
       a DNS server, prior to sending LLMNR queries.

   [2] All attempts to resolve the name via DNS on all interfaces
       have failed after exhausting the searchlist.  This can occur
       because DNS servers did not respond, or because they
       responded to DNS queries with RCODE=3 (Authoritative Name
       Error) or RCODE=0, and an empty answer section.  Where a
       single resolver call generates DNS queries for A and AAAA RRs,
       an implementation MAY choose not to send LLMNR queries if any
       of the DNS queries is successful.  An LLMNR query SHOULD only
       be sent for the originally requested name;  a searchlist
       is not used to form additional LLMNR queries.

   Since LLMNR is a secondary name resolution mechanism, its usage is in
   part determined by the behavior of DNS implementations.  In general,
   robust DNS resolver implementations are more likely to avoid
   unnecessary LLMNR queries.

   As noted in [DNSPerf], even when DNS servers are configured, a
   significant fraction of DNS queries do not receive a response, or
   result in negative responses due to missing inverse mappings or NS
   records that point to nonexistent or inappropriate hosts.  This has
   the potential to result in a large number of unnecessary LLMNR
   queries.

   [RFC1536] describes common DNS implementation errors and fixes.  If
   the proposed fixes are implemented, unnecessary LLMNR queries will be
   reduced substantially, and so implementation of [RFC1536] is
   recommended.

   For example, [RFC1536] Section 1 describes issues with retransmission
   and recommends implementation of a retransmission policy based on
   round trip estimates, with exponential backoff.  [RFC1536] Section 4
   describes issues with failover, and recommends that resolvers try
   another server when they don't receive a response to a query.  These
   policies are likely to avoid unnecessary LLMNR queries.

   [RFC1536] Section 3 describes zero answer bugs, which if addressed
   will also reduce unnecessary LLMNR queries.

   [RFC1536] Section 6 describes name error bugs and recommended
   searchlist processing that will reduce unnecessary RCODE=3
   (authoritative name) errors, thereby also reducing unnecessary LLMNR
   queries."

Change the last paragraph in Section 5.2 to the following:

"  This vulnerablity can be reduced by limiting use of LLMNR to
   resolution of single-label names as described in Section 3, or by
   implementation of authentication (see Section 5.3)."

Change Section 5.3 to the following:

"5.3.  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.  Howeverm where a pre-arranged security configuration is
   possible, the following security mechanisms may be used:

[a]  LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
     [RFC2931] 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, based on group keys.  While group
     keys can be used to demonsrate membership in a group, they do not
     protect against forgery by an attacker that is a member of the
     group.

[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.  As with TSIG, this does not
     protect against forgery by an attacker with access to the group
     pre-shared key.

[c]  LLMNR implementations MAY support DNSSEC [RFC4033].  In order to
     support DNSSEC, LLMNR implementations MAY be configured with trust
     anchors, or they MAY make use of keys obtained from DNS queries.
     Since LLMNR does not support "delegated trust" (CD or AD bits),
     LLMNR implementations cannot make use of DNSSEC unless they are
     DNSSEC aware.  Unlike approaches [a] or [b], DNSSEC permits a
     responder to demonstrate ownership of a name, not just membership
     within a trusted group.  As a result, it enables protection against
     forgery."