[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: llmnr issue 39 Name conflict detection algorithm


On Wednesday, May 14, 2003, at 08:32 US/Pacific, Christian Huitema wrote:

I am afraid that there is no good solution to this problem. I don't like
the idea of multicasting all replies, as it is either wasteful or
dangerous; and I also really don't like anything that relies on periodic
broadcast by all hosts on a network, as it has obvious potential for
melt-down.
We have operational experience with a wide deployment of an implementation of something similar to LLMNR that uses multicasts for responses to quickly detect conflicts and to implement caching. We have received no reports of melt-downs nor have we experienced any such problems here at Apple.

Let's expand on why multicast replies are wasteful or dangerous. There
is a proposed design in which hosts listen to all replies, even those to
queries they did not issue, and cache the response. The idea is that
multicast may be costly, but this cost would be compensated by more
extensive caching. The problem is that such design is a powerful tool
for an on-link attacker: the attacker can issue a spoofed query and then
broadcast spoofed responses, effectively polluting the caches of all
on-link hosts. In practice, a responsible host will only accept
responses to its own queries. It will ignore the other broadcast
responses. The multicast will just be wasteful.
A node can do the wrong thing and wreck havoc on the local network. In the case you note, the multicast would be detected by anyone advertising conflict data and the conflict detection would kick in. Someone could use a unicast hardware address with a multicast IP address to spoof a response to just one node. The network is a shared resource, unless encryption and authentication is used, it can not be made secure.

-josh


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>