Subject: llmnr issue 39 Name conflict detection algorithm

From: Erik Guttman <[email-masked]>
Date: Wed, 14 May 2003 11:12:02 +0200 (CEST)

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Bernard,

I agree that multicasting the name with the conflict would be easier
to implement (and specify correctly).

If this multicast occurs to a link local multicast group destination, it
would be hard for an attacker send it to another link.  This mitigates
the security risk of caching. 

I assume the host (llmnr responder) receiving these multicast
unsolicited replies can distinguish the difference between a message
sent to multicast and unicast destinations.  Either a separate listener
(socket, or whatever) should be used to listen for unicast requests, to
differentiate them from multicast requests - or the 'destination
address' of the received datagram should be examined. 

Erik

--
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: "Christian Huitema" <[email-masked]>
Date: Wed, 14 May 2003 08:32:15 -0700

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.

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.

My real issue with name conflict detection is whether it is actually
needed. Take the IETF network. Suppose that two attendees come in with
the laptops "zeus.example1.com" and "zeus.example2.net". There will be a
conflict for the unqualified name "zeus", but is that a bug that needs
be fixed? None of the two laptops is going to change its name, as that
would probably invalidate various security credentials and other
certificates. I guess we will just have to live with it.

If names are picked at random, then we can just as well pick them from a
space large enough to avoid the birthday paradox, and periodic checks
will not be particularly useful. If we assume that names are configured,
then periodic checks are not needed either. The administrator may
perform the check during the configuration procedure, or compare to a
master file kept somewhere, on a computer or a notebook. The
administrator may also at a later stage perform inventories of the
network, e.g. by listening to traffic, collecting IP addresses and
performing reverse look-ups.

In summary, I would rather rely on occasional checks triggered by an
administrative action, rather than increase the amount of broadcast on
the network.

-- Christian Huitema