Subject: RE: llmnr issue 39 Name conflict detection algorithm

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

--
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: "Eric A. Hall" <[email-masked]>
Date: Thu, 15 May 2003 11:08:09 -0500

Another option is to stick the client name into the request message,
perhaps using a special RR in the authority or additional-data sections.
Other clients which are monitoring the multicast channel can watch for
collisions and take whatever recovery steps are needed.

That would only increase the request size by a small percentage, and
wouldn't generate any additional messages.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 15 May 2003 14:58:10 -0700

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

> broadcast by all hosts on a network, as it has obvious potential for

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.

> 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

---

From: Erik Guttman <[email-masked]>
Date: Fri, 16 May 2003 16:54:26 +0200

[ 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. ]

Christian,

Christian Huitema wrote:
> I am afraid that there is no good solution to this problem. 

The real question is - what is the problem?  Early on in the work on
this protocol it was asserted that it would be unacceptable to allow
multiple hosts to respond to the same name.  (I do not remember who
asserted this.)

If we accept it is necessary to detect and correct the situation where
more than one llmnr responder responds authoritatively to the same
name we need either a proactive or reactive approach.  But do we really
need to accept this requirement?  There are for example cases where we
*want* multiple responders to answer to the same name (if the hosts
support redundant identical services, for example.)

It could be inconvenient and confusing for a user to get inconsistent
results to a request.  But in this case, can't the user intervene?
The host had to have *gotten* its name somehow.  If this was a manual
administrative assignment, only a similar assignment should be done
to change the name.  The name may have been assigned automatically ,
by a program which attempted to assign a unique name.  This same program
could periodically test to see if the name is still unique.

I argue that duplicate name detection and suppresion does not need to be
part of the base LLMNR protocol.

 > I don't like

I agree both are undesirable and with your argument.

> administrative action, rather than increase the amount of broadcast on

That is basicly what I am suggesting above.

Best regards,

Erik