Subject: LLMNR Issue 92: Use of TCP

From: Bernard Aboba <[email-masked]>
Date: Fri, 15 Jul 2005 20:46:07 -0700 (PDT)

Issue 92: Use of TCP
Submitter: Stuart Cheshire
Submitter email address: [email-masked]
Date first submitted: May 25, 2005
Reference:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html
Document: LLMNR-40
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

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

If TCP connection setup cannot be completed after how long?

[BA] Perhaps LLMNR_TIMEOUT is an appropriate value for the timer.

[Yi Zhao]

For the case of a PTR RR query it should not be necessary to wait
for LLMNR_TIMEOUT if the destination is off-link.  As I understand
it, one reason for sending PTR queries via unicast was in order to
get immediate feedback if the destination is off-link.

However, ICMP "TTL Exceeded" is treated as a soft error by TCP, and as a
result, setting TTL=1 on TCP connections does not result in senders
receiving immediate notification if the destination address is off-link.
This issue can be better handled with unicast queries sent via UDP.

Looking over the discussion on TCP vs. UDP for unicast queries, I am
not convinced that UDP unicast queries should be outlawed.
I understand why PTR RR queries should be sent via unicast.
In order to prevent unicast queries from propagating beyond
the local link, unicast queries should have  TTL should be set to 1.

However, I do not buy the argument that using TCP improves security
significantly. Unicast PTR RR queries will only be answered by a
single host -- there is no opportunity for magnification attacks here.
Just because the response is larger than the query does not mean that
a significant DoS attack opportunity exists. Even if UDP unicast
queries are outlawed, an LLMNR sender still needs to listen for UDP
unicast responses, so the opportunity for spoofed requests and responses
still exists.

It seems to me that TCP was selected because UDP queries are to be sent
with TTL=255:

"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]."

However, LLMNR and Bonjour use different link-scope multicast addresses
and ports. in Issue 87, Stuart indicates that Bonjour compatibility has
not been tested. The protocols are very diffent. So what is the value of
this?

I would propose that the following sentences be changed from:

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

To:

"Where unicast LLMNR queries are sent using TCP, the response 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."

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