Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Feb 2004 00:56:46 -0800 (PST)

> Scaling yes, "fast fail" no - the TTL cannot cause anything to happen
> faster than it otherwise would (well, the packet may get discarded in
> the net quicker, but as you can't rely upon getting an ICMP back, this
> is essentially invisible).

You can't rely on getting an ICMP back, but if one is received then it can
be treated as though a response was received with RCODE=0 and an empty
answer section, assuming that the ICMP error payload can be verified.
This is described in Section 2.4.

>
>   | Setting TTL=1 ensures not only that these queries don't escape the local
>   | link
>
> Yes (though personally in this case I'm not sure that matters, in general
> I think the in-addr.arpa (and in6.arpa) trees are a mistake, and if we want
> to know someone's name, we should just ask them - wherever they are).

The concern was that the volume of these queries could be substantial.
Today's hosts do send PTR queries, and frequently (up to 30% of the time)
do not receive an answer to them.  Setting TTL=255 on unicast queries will
cause bandwidth to be consumed on other links, which is hard to justify
for a link-local protocol.

> I certainly agree that TTL checking for security purposes (in the
> "did this packet originate on the local link", for as much security
> as that affords, which isn't much) is useful only when receiving
> responses.

Exactly.  That's why this discussion should really be about responses,
not queries.  If there is to be a "compromise" I believe that it should be
to set TTL=255 on responses and (optionally) check on the sender, while
*always* setting TTL=1 on queries.

>   | However, if DNS DISCOVER opcode were to be implemented on top of LLMNR
>
> The DISCOVER opcode shouldn't be implemented anywhere - but again, that's
> another discussion.

If that's the WG consensus, then I believe that we can dismiss the DoS
arguments against setting TTL=255 on Responses, since this really can't be
used to do much harm with a conformant LLMNR implementation.

--
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: Andras Salamon <[email-masked]>
Date: Thu, 26 Feb 2004 16:42:16 +0200

On Thu, Feb 26, 2004 at 12:56:46AM -0800, Bernard Aboba wrote:
> If there is to be a "compromise" I believe that it should be

Sounds reasonable to me.

-- Andras Salamon                   [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Feb 2004 12:54:17 -0500

> for a link-local protocol.

Can you explain how this is going to happen, in the case of a unicast?

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Feb 2004 11:59:13 -0800 (PST)

> Can you explain how this is going to happen, in the case of a unicast?

In normal operation, hosts send DNS PTR RR queries, and can either
receive no response, or can receive a response with RCODE=3 (NXDOMAIN).
Studies show that this can occur with as much as 30% of all PTR RR
queries, since very often administrators neglect to configure these
RRs.

In these circumstances, (see Section 2) an LLMNR PTR RR query will
be sent via unicast, as described in Section 2.4.  Since the
destination might not be resident on the local link, if the query
has TTL=255, then it could be sent to any destination on the Internet and
will traverse links other than the local one to reach that destination.
By setting TTL=1 on unicast queries, this problem is avoided.  If
there is a default route, the gateway will typically send an
ICMP "Time Exceeded" message if the destination is non-local.  If
the host is attached to an adhoc network, then it will ARP for the
destination, and if there is no response, an error will be returned.