Subject: Re: LLMNR interoperability with Rendezvous?

From: Stuart Cheshire <[email-masked]>
Date: Fri, 29 Aug 2003 19:34:16 -0700

>Stuart, please provide the working group with a list with issues
>previously not discussed and a separate list of items that have been
>discussed. Please provide that list before the end of next week (Sep
>7).

The road block is the TTL incompatibility:

Rendezvous sets IP TTL=255, and checks IP TTL on reception, and discards 
packets that have lower TTLs indicating that they may originate from 
off-link attackers.

LLMNR sets IP TTL=1, and on reception discards packets that don't have IP 
TTL=1.

Aside from that difference, Rendezvous does everything that LLMNR does.
The packet formats are identical (DNS packet format).
A Rendezvous responder will respond to queries from a LLMNR querier,
and a LLMNR responder will answer queries from a Rendezvous querier,
were it not for the fact that they are both choosing to ignore and
discard each other's packets. This seems like a silly incompatibility.

Ólafur wrote:
>  the document went through numerous cycles during which issues
>  where thoroughly discussed. The issue of the TTL=1 has review
>  from the working group and that issue is not to be opened again.

So, this is the show-stopping incompatibility. We can't change 
Rendezvous's TTL handling because too many Rendezvous hardware products 
have already shipped from Apple and other companies. DNSEXT can't change 
LLMNR's TTL handling because it has been thoroughly discussed and is not 
to be opened again.

This is an impasse. Even with the best will in the world, the 
circumstances are such that it is simply not possible for either side to 
make the change to interoperate with the other.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

--
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: Olaf Kolkman <[email-masked]>
Date: Sat, 30 Aug 2003 07:31:05 +0200

Stuart Cheshire <[email-masked]> writes:
 * >Stuart, please provide the working group with a list with issues
 * >previously not discussed and a separate list of items that have been
 * >discussed. Please provide that list before the end of next week (Sep
 * >7).
 * 
 * The road block is the TTL incompatibility:

Going back to our proposal, you providing us 2 lists. We now have 1 item 
and we like to make sure:

- Is this 1 item the complete list of issues previously discussed and
  that need to be reviewed?

- Is the list of 'new items' an empty list?

We proposed the process so that the working group can make an informed
decision, based on the amount of things that need to be revisited, if
we need to go back and re-argue the issue.

No hidden surprises further down the road ;-) ?

--Olaf Kolkman
  DNSEXT Co-Chair

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Aug 2003 08:42:42 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Stuart" == Stuart Cheshire <[email-masked]> writes:
    Stuart> The road block is the TTL incompatibility:

    Stuart> Rendezvous sets IP TTL=255, and checks IP TTL on reception, and
    Stuart> discards packets that have lower TTLs indicating that they may
    Stuart> originate from off-link attackers.

    Stuart> LLMNR sets IP TTL=1, and on reception discards packets that don't
    Stuart> have IP TTL=1.

  If I'm not mistaken, the BGP protocol originally used TTL=1, but now
recommends using TTL=255 and checking that way instead.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: Ted Lemon <[email-masked]>
Date: Sun, 31 Aug 2003 11:50:02 -0400

> recommends using TTL=255 and checking that way instead.

Hm.   I was one of the people who thought that TTL=255 wasn't such a great 
idea, all other things being equal.   However, nobody ever presented any 
strong reason why we should use one over the other - it was always a matter 
of preferences and fine distinctions.

I really don't think insisting on TTL=1 is a good idea if it means we can't 
interoperate with a lot of existing devices out there, because there isn't a 
clear advantage to it.   It winds up just being a gratuitous incompatibility.

So although the time is late, and I'm not in love with the idea of reopening 
resolved issues, I think this is worth changing.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Aug 2003 12:21:26 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:

    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.

  Both depend upon the router doing something correctly.
  I can't comment on what has been broken more often. I think that there
are/were many "internet-sharing" programs for windows(95) which broke TTL=1
processing. Odds are they didn't even speak multicast, so I don't know what
the major risks are.

---

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

>   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

---

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.   
:'/

---

From: Mika Liljeberg <[email-masked]>
Date: Mon, 01 Sep 2003 00:09:00 +0300

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

Well, it is. But the participating nodes may be using their routable
addresses. :)

	MikaL