Subject: Re: [llmnr-design] Strawman -18 draft

From: Randy Bush <[email-masked]>
Date: Thu, 1 May 2003 14:08:13 -0700

in dns, it is legal for a client to send a tcp request without first
having sent udp and received a tc bit.

--
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: Mika Liljeberg <[email-masked]>
Date: 01 May 2003 23:28:42 +0300

On Thu, 2003-05-01 at 16:19, Bernard Aboba wrote:
> In order to resolve Issues 33-36, I've put together a strawman -18 draft,
> including the potential fixes described in the minutes of the last
> conference call.  Comments welcome:
> 
> http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-18.txt

I'm almost sorry I brought up issue 33. :-) I wanted to make things
simpler and they got more complex. Anyway, a few comments follow.

Sections 2.1 and 2.2 do not explicitly state what to do with received
unicast UDP query/response packets. Presumably they should be discarded
(except for the special optional empty response with TC bit set,
described in section 2.3)? This implies destination address checks for
all received UDP packets.

Section 2.2:

        "A responder listens on UDP port TBD on the link-scope multicast
        address(es) and on ports TBD on the unicast address(es) that
        could be set as the source address(es) when the responder
        responds to the LLMNR query.  A responder MUST listen on both
        the UDP and TCP ports TBD unless it is impossible for a response
        to be sent with the TC bit set, in which case the responder MAY
        listen only on UDP port TBD.  The host configured as a responder
        MUST act as a sender to verify the uniqueness of names as
        described in Section 4."

Only one port number is needed, since UDP and TCP can share the same
port number.

Section 2.3:

        "In composing a response to a unicast LLMNR query, the responder
        MUST set the Hop Limit field in the IPv6 header and the TTL
        field in IPv4 header of the response to 1.  Since unicast LLMNR
        queries and responses to those queries MUST be sent using TCP,
        spoofing a response would require hijacking a TCP connection on
        the local link."

With the TCP listener, the TTL=1 setting should be set on the listen
socket so that the SYN-ACK packets will have TTL=1. This prevents an
incoming connection from being formed if someone tries to connect from
off-link, since the sender will not receive any SYN-ACK packets.

        "Senders MUST support sending TCP queries, and Responders MUST
        listen on TCP port TBD, unless it is impossible  for a response
        to the supported queries to be sent with the TC bit set."

Does this mean that TCP is optional in both sender and responder or just
responder? The wording is not quite clear on this.

Note that, since TCP is optional in the responder, it is more efficient
to just send all queries with multicast in the first place, rather than
try TCP first and fall back on multicast if responder does not support
TCP. (No, I don't propose to make TCP mandatory. Simple devices might
not implement the TCP protocol at all.)

        "If an ICMP "Time Exceeded" message is received in response to a
        unicast 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)."

Careful here. The UDP sender should verify that the ICMP error payload
contains a valid DNS query packet, which matches a query that is
currently in progress. Otherwise this can be turned into a DoS attack.

I'm not sure if the last bit is worth mentioning but it's good to
realize that if the ICMP error response doesn't have enough payload to
identify the query the sender will have to fall back on a timeout. The
same thing will happen with TCP implementations that follow RFC1122 to
the letter and ignore the "ICMP Time Exceeded" error also during the TCP
connect phase, rather than aborting the connection immediately.

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 02 May 2003 00:42:44 +0300

Randy,

> having sent udp and received a tc bit.

I'm not sure I understand your point. Is that a response to one of my
comments?

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 02 May 2003 01:03:31 +0300

On Fri, 2003-05-02 at 00:46, Randy Bush wrote:
> note that this would allow a server to be udp only

Sure. That was a direct quote from draft-18. I still don't know which
part of my comments you're responding to, though. :-)

	MikaL

---

From: Randy Bush <[email-masked]>
Date: Thu, 1 May 2003 14:46:36 -0700

randy

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 May 2003 04:32:34 -0000

> having sent udp and received a tc bit.

False. Your suggested behavior violates the following crystal-clear
requirement in RFC 1123, section 6.1.3.2: ``A DNS resolver or server
that is sending a non-zone-transfer query MUST send a UDP query first.''
TCP is for truncated packets and zone transfers.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Derek Atkins <[email-masked]>
Date: 02 May 2003 00:32:50 -0400

> part of my comments you're responding to, though. :-)

I suspect the comment is about the part that states "unless it is
impossible for a response to be sent with the TC bit set, in which
case the responder MAY listen only on UDP port TBD."  My reading of
this (which concurs with Randy's) is that it makes it possible to
create a server that ONLY listens on UDP, which would violate the
existing dns spec which allows a client to make its initial request
using TCP (even if the response would not have the TC bit set).

In this particular case, the client would make a TCP request, and TCP
would fail -- what does/should it do?  IMHO you should remove the text
I quoted above.

> 	MikaL

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com