Subject: Proposed Resolution of LLMNR Issue 92: Use of TCP

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Jul 2005 15:04:32 -0700 (PDT)

The text of Issue 92 is enclosed below.  This and other LLMNR Issues are
tracked at:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

The proposed resolution is to reject the issue.

The issue relates to the recommended value of an application timer on TCP
queries.   Application layer timers are not defined for DNS clients,  so
I'm not clear why LLMNR would need to define it either.

The other part of this issue is whether to allow UDP queries for PTR RRs.

LLMNR is designed so as to prohibit queries from
off-link senders, in order to prevent the protocol from being exploited
by a worm if implementation vulnerabilities were discovered. Therefore
the only types of queries allowed are UDP queries to a link-scope
multicast address or TCP queries with TTL=1.  So you could conceivably
use UDP multicast for a PTR RR query, but not UDP unicast.
UDP multicast PTR RR queries are not prohibited, since
Section 2.0 says:

"A sender SHOULD send LLMNR queries for PTR RRs via unicast, as
specified in Section 2.4."

Since multicast PTR RR queries are already legal there is no change
required to support them.

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