Subject: LLMNR Issue 39: Name conflict detection algorithm

From: Bernard Aboba <[email-masked]>
Date: Mon, 12 May 2003 12:46:12 -0700 (PDT)

Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: May 12, 2003
Reference: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue 39
Document: LLMNR-18
Comment type: T
Priority: S
Section: 4
Rationale/Explanation of issue:

It isn't clear to me that the name conflict detection mechanism
defined in Section 4 makes sense. Here is what it says:

"The name conflict detection mechanism doesn't prevent name
conflicts when previously partitioned segments are connected by a
bridge. In such a situation, name conflicts are detected when a sender
receives more than one response to its LLMNR multicast query.
In this case, the sender sends the first response that it received to all
responders that responded to this query except the first one, using UDP
unicast. A host that receives a query response containing a UNIQUE resource record that it
owns, even if it didn't send such a query, MUST verify that no other
host within the LLMNR scope is authoritative for the same name, using
the mechanism described above. Based on the result, the host detects
whether there is a name conflict and acts accordingly."

I don't like the idea of sending unsolicited UDP responses. The
goal here is to enable hosts involved in a conflict to become
aware of it more quickly.

A potential alternative is to mandate that hosts send an LLMNR query
for their own name at some convenient interval (every 30 seconds?)

--
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: Joshua Graessley <[email-masked]>
Date: Mon, 12 May 2003 14:20:02 -0700

> for their own name at some convenient interval (every 30 seconds?)

It seems another alternative might be to send all responses using 
multicast instead of unicast. This would give hosts a chance to detect 
conflicts much quicker. The same trick is used with IPv4LL and ARP. The 
ARP responses are broadcast to facilitate in quicker discovery of 
conflicts. The multicast responses could be used to populate a local 
LLMNR cache on all hosts possibly reducing the number of queries that 
must be sent.

-josh

---

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

On Mon, 2003-05-12 at 22:46, Bernard Aboba wrote:
> unicast.

We no longer need to do this, since responses are now sent to a single
multicast group. All responders will hear the responses from all other
responders.

>  A host that receives a query response containing a UNIQUE resource record that it

A conflict won't matter until someone queries a name. Once that happens,
conflict detection occurs pretty much immediately, since all responders
hear the responses from all other responders.

> for their own name at some convenient interval (every 30 seconds?)

That would be wasteful.

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 13 May 2003 00:54:28 +0300

> multicast group. All responders will hear the responses from all other

Oops, looks like I jumped ahead of things, responses are currently sent
using unicast. But as Joshua also suggested, we could just use
multicast.

	MikaL

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 12 May 2003 15:07:50 -0700 (PDT)

> multicast group. All responders will hear the responses from all other

It is *requests* that are sent to a single multicast group, not
responses -- which are sent unicast. So all responders will *not* hear the
responses.

> hear the responses from all other responders.

That isn't the way the protocol works.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 12 May 2003 15:16:30 -0700 (PDT)

> > for their own name at some convenient interval (every 30 seconds?)

Wouldn't it also be wasteful to send all responses to the same
multicast group?

---

From: Joshua Graessley <[email-masked]>
Date: Mon, 12 May 2003 16:04:40 -0700

> Wouldn't it also be wasteful to send all responses to the same

The response packet has to be sent. If it's sent using multicast 
instead of unicast it will reach more machines but at least a packet 
wouldn't be sent when it isn't needed. Sending every 30 seconds is a 
precaution, in case something is wrong. If two hosts are configured to 
respond differently to LLMNR requests, there is no problem until 
another host actually queries for the conflicting record. If no host 
ever queries for that record, what do we gain by spewing traffic every 
30 seconds?

The multicast response could be used to build a cache on hosts 
implementing LLMNR resolvers. This cache could be hit before a query 
packet is generated on the wire, potentially eliminating additional 
traffic.

---

From: Mika Liljeberg <[email-masked]>
Date: 13 May 2003 09:30:46 +0300

> ever queries for that record, what do we gain by spewing traffic every 

I agree. There is no need to detect conflicts proactively.

If people are worried about the CPU usage (and that is certainly a valid
point), we can just leave the unicast responses as they are, but using
multicast would simplify the code.

> packet is generated on the wire, potentially eliminating additional 

I'm not sure I'm comfortable with this one. This might make cache
poisoning a bit too easy.

Note that, for UDP unicast responses, comparing received responses to
pending queries is currently our only defence against spoofed UDP
unicast responses from off-link, since we no longer test TTL=255 for
responses.

	MikaL

---

From: Joshua Graessley <[email-masked]>
Date: Tue, 13 May 2003 10:59:32 -0700

> unicast responses from off-link, since we no longer test TTL=255 for

Using multicast can help with this. If only multicast responses to 
multicast queries are accepted then cache poisoning becomes difficult. 
Any attempt to poison the cache using multicast would result in the 
detection of a conflict. The host with the "real" information would see 
the "spoofed" multicast response and likely handle it as a conflict.

-josh