Subject: LLMNR Issue 34: Unicast over TCP only

From: Bernard Aboba <[email-masked]>
Date: Wed, 23 Apr 2003 11:25:28 -0700 (PDT)

Issue 34: Unicast over TCP only
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: April 22, 2003
Reference:
Document: LLMNR-17
Comment type: T
Priority: S
Section: 2.3, 2.6
Rationale/Explanation of issue:

Doing unicast queries only over TCP will make LLMNR more
resilient against spoofing.

In Section 2.3, change:

"A sender MUST NOT send a unicast LLMNR query except when:

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

b. The sender's LLMNR cache contains an NS resource record that
enables the sender to send a query directly to the hosts
authoritative for the name in the query.

If a TC (truncation) bit is set in the response, then the sender MAY use
the response if it contains all necessary information, or the sender MAY
discard the response and resend the query over TCP or using EDNS0 with
larger window using the unicast address of the responder. The RA
(Recursion Available) bit in the header of the response MUST NOT be set.
If the RA bit is set in the response header, the sender MUST ignore it."

To:

"Unicast LLMNR queries MUST be sent using TCP and TTL=1. Responses
to unicast LLMNR queries also MUST be sent using TCP (using the
same connection as the query) and TTL=1. If
the response to a unicast LLMNR query is not sent using TCP,
the query sender MUST silently discard the response. Unicast
queries sent using UDP also MUST be silently discarded by the
responder.

Unicast queries SHOULD be sent when:

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

b. The sender's LLMNR cache contains an NS resource record that
enables the sender to send a query directly to the hosts
authoritative for the name in the query.

c. The sender queries for a PTR RR.

If a TC (truncation) bit is set in the response, then the sender MAY use
the response if it contains all necessary information, or the sender MAY
discard the response and resend the query over TCP using the unicast
address of the responder. The RA (Recursion Available) bit in the header
of the response MUST NOT be set. If the RA bit is set in the response
header, the sender MUST ignore the RA bit."
In section 2.6, change:

"In order to avoid synchronization, LLMNR queries and responses are
delayed by a time uniformly distributed between 0 and 200 ms.

If the LLMNR query is not resolved within the timeout interval
(LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in
order to assure themselves that the query has been received by a host
capable of responding to the query. Since a sender cannot know
beforehand whether it will receive no response, one response, or more
than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in order
to collect all possible responses, rather than considering the query
answered after the first response is received.

LLMNR implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT) on a per-interface basis, using the algorithms described
in [RFC2988], with a minimum timeout value of 300 ms. Retransmission
SHOULD NOT be attempted more than 3 times."

To:

"In order to avoid synchronization, LLMNR queries and responses are
delayed by a time uniformly distributed between 0 and 200 ms.

If a multicast LLMNR query is not resolved within the timeout interval
(LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a multicast
query in order to assure themselves that the multicast query has been
received by a host capable of responding to the query.
Since a multicast query sender cannot know
beforehand whether it will receive no response, one response, or more
than one response to a multicast query, it SHOULD wait for LLMNR_TIMEOUT
in order to collect all possible responses, rather than considering the
multicast query answered after the first response is received.

LLMNR implementations SHOULD dynamically estimate the timeout value
for multicast queries (LLMNR_TIMEOUT) on a per-interface basis,
using the algorithms described in [RFC2988], with a minimum timeout value
of 300 ms. Retransmission of multicast queries SHOULD NOT be attempted more
than 3 times. Since unicast LLMNR queries must be sent using TCP, for these
queries, retransmission behavior is handled by the transport layer."

--
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: Joshua Graessley <[email-masked]>
Date: Thu, 24 Apr 2003 09:45:38 -0700

If unicast TCP queries with a TTL of 1 are used, it seems quite likely 
that PTR queries using LLMNR that could have succeeded will fail in 
cases where more than one ip subnet is present on the local link. If my 
machine does not have a routing entry, it will send the packet to the 
router, which will presumably decrement the TTL and put the packet back 
on the same link. Since the TTL is set to 1 my packet would be dropped. 
If I sent the same query using multicast, the device on the same link 
would have a chance to respond.

This TTL=1 setting may get us in a bind of a response to an LLMNR query 
sets the TC bit and the source address of the response is on a 
different subnet.

I also think that for queries in certain domains, LLMNR should always 
be used. It makes sense to use LLMNR for queries with names ending in 
"254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa.".

I oppose issue 33, 34 and 35.

-josh

---

From: Mika Liljeberg <[email-masked]>
Date: 24 Apr 2003 21:40:01 +0300

Josh,

> would have a chance to respond.

This seems a bit far fetched. Do you have a real world example in mind?

Note that if we want to support something like this, we really have no
choice but try all PTR queries with LLMNR, since there is no way to tell
which destination addresses the default router might bounce back to the
local link.

> "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa.".

I think I agree, although I would reverse this and say that it does not
make sense to send these PTR queries to a DNS server, so that phase may
be skipped.

	MikaL

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 24 Apr 2003 16:57:50 -0700

> which destination addresses the default router might bounce back to the

At home, I have a network with a NAT and a few global IP addresses. 
Both subnets are on the same network. I would like to be able to use 
LLMNR to resolve the names of devices with global addresses from 
devices that have NAT addresses. There are a lot of problems with this 
setup and some tweaks to routing tables would make the TTL 1 rule work. 
My concern is that if the two devices can get information using 
multicast queries, but then fail if the TC bit is set because of the 
TTL requirement, it might be a little difficult to understand what's 
going on. Then again, resolving a name to a private address won't do 
much good without the proper routing configuration on the local 
machines.

So no, I can't think of a real world example.

-josh