Subject: Re: LLMNR interoperability with Rendezvous?

From: Mika Liljeberg <[email-masked]>
Date: Sun, 31 Aug 2003 21:48:08 +0300

On Sun, 2003-08-31 at 19:21, Michael Richardson wrote:
> >>>>> "Ted" == Ted Lemon <[email-masked]> writes:
>     >> If I'm not mistaken, the BGP protocol originally used TTL=1, but now
>     >> recommends using TTL=255 and checking that way instead.
> 
>     Ted> Hm.  I was one of the people who thought that TTL=255 wasn't such a
>     Ted> great idea, all other things being equal.  However, nobody ever
>     Ted> presented any strong reason why we should use one over the other -
>     Ted> it was always a matter of preferences and fine distinctions.
> 
>   TTL=1 depends upon the routers dropping at exactly the right time.
>   TTL=255 is locally checkable, but requires that link-local multicast works.

I think that in practise the choise of TTL only has relevance with
unicast queries and responses sent to non link-local destination
addresses. If the destination address is link-local (including
multicast), setting or checking the TTL has little value. We might as
well do what rendezvous does.

As for unicast to non link-local destinations addresses:

- Setting TTL=1 makes sense with TCP, since it prevents a TCP connection
from being created with an off-link peer. A smart TCP implementation
will abort the connection attempt immediately when receiving the time
exceeded ICMP error from the local router. This is generally better than
timing out.

- For UDP unicast, setting and checking TTL=255 gives good protection
against off-link attackers. This makes good sense for responses as it
will guard against cache poisoning attempts by off-link attackers. We
will also never leak responses off-link if we check TTL=255 in query
packets.

- However, if we use TTL=255 in queries we *will* leak query packets
off-link and we will lose the rapid "time exceeded" response from the
local router. The ICMP error response was considered desirable with
reverse queries. In many cases a reverse query will yield no response
from DNS. This causes the resolver to fall back on LLMNR and typically
the query will fail after the LLMNR sender times out.

If we touch the TTL rules we will have to rethink some of these issues,
including the rules that tells us when to use unicast.

	MikaL

--
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: Ted Lemon <[email-masked]>
Date: Sun, 31 Aug 2003 16:54:03 -0400

> As for unicast to non link-local destinations addresses:

Hm, I guess I need to read the latest draft.   I thought LLMNR was link-local.   
:'/