Subject: Re: LLMNR Issue 3

From: Bernard Aboba <[email-masked]>
Date: Thu, 10 Apr 2003 10:40:08 -0700 (PDT)

Joshua Graessley writes:

"I would not want to always
use LLMNR first or even simultaneously with DNS. I don't want to make
it easier for someone to spoof my mail server, or the AIM server, or
any of the other number of services that are totally insecure that I
make use of on a daily basis."

This is certainly a concern. While both unicast and multicast name
resolution is vulnerable to spoofing without DNS security, the thinking is
that LLMNR is even easier because you don't even have to write any
software to do it, just misconfigure your machine. Also, DNS security
seems difficult to deploy with protocols such as LLMNR. So the argument is
that even though both usages are vulnerable today, LLMNR is likely to
remain vulnerable, no matter how DNS security were to advance.

"The solution to this problem lies in LLMNR issue 22 (Bring back
"local.arpa")."

I guess I'm missing how "local.arpa" addresses the spoofing issue. Is this
because instead of spoofing ietf.org, the attacker now has to spoof
ietf.org.local.arpa? Or is the "security" provided by this due to only
using linklocal name resolution to resolve unqualified names
(foo.local.arpa)? In that case, why wouldn't the same scope restriction
in LLMNR provide equivalent security?

"You can make it very clear when LLMNR should be used (LLMNR issue 3),
if the fully qualified name ends in "local.arpa.", use LLMNR."

Actually, this just adds another "knob to configure" -- the search list.

"You also give people a domain they can use a name in."

Since this is a flat name space, that doesn't address the issue of name
conflicts. There will be as many "bob.local.arpa" hosts as "bob" hosts.

"When I'm at work, my laptop is graejo5.apple.com.
When I'm at home, my laptop is
adsl-64-171-18-123.dsl.sntc01.pacbell.net."

Depends on whether your host allows DHCP to assign the name or not. If
not, your laptop might remain graejo5.apple.com while a PTR RR query for
your IP address might return adsl-64-171-18-123.dsl.sntc01.pacbell.net
from the DNS server, and graejo5.apple.com if handled via LLMNR.

In any case, I'm not sure how "local.arpa" helps this situation. Does
someone at the airport connect to your machine as
"graejo5.apple.com.local.arpa"? "graejo5.local.arpa"? Or some other name?

"If I meet someone else at an airport or at someone's house where I'm
assigned a NAT address, I would like an easy way to connect to their
machine by name. In both of these cases, I have a configured DNS
server. I have no idea what name the other machine has."

This doesn't sound like a problem that requires a name resolution solution
to me. It has been pointed out by Erik Guttman that if what is actually
needed to solve this is to discover the hosts and corresponding services
on the local link, as well as their attributes, which could include a
"friendly name". That way you don't have to know what the name is -- which
is a problem whether you're using "local.arpa" or not.

"there is a possibility that one
interface will be attached to a configured network and one interface
will be attached to an ad-hoc network. In such a scenario, the device
connected to both networks will be unable to use LLMNR to resolve names
on the ad-hoc network."

I don't think this is true. It might attempt to do a DNS query first, but
presumably this will fail and an LLMNR query will go out, potentially on
both interfaces.

--
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: Thu, 10 Apr 2003 13:10:27 -0700

> in LLMNR provide equivalent security?

Unless I'm mistaken, domains in the search list are appended to 
unqualified names only if an attempt to resolve the unqualified name 
fails. A resolver attempting to resolve "ietf.org" would try to resolve 
"ietf.org." first. Since "ietf.org." doesn't end in "local.arpa." LLMNR 
would not be used if there is a DNS server configured. Even if someone 
were respoding to "ietf.org.local.arpa." using LLMNR, it is unlikely 
they would receive any queries for that name.

> Actually, this just adds another "knob to configure" -- the search 

It is an optional knob. The default behavior could work well enough 
that you don't have to add local.arpa to the search list unless you 
really wanted to. You could resolve LLMNR names by appending local.arpa 
yourself. You can resolve any name without editing or even having a 
search list. Search lists are just a convenience for people who type a 
lot of names in a few domains often.

> conflicts. There will be as many "bob.local.arpa" hosts as "bob" hosts.

Detecting and handling conflicts is not an impossible task. Creating an 
appropriate user experience to properly handle and notify someone of a 
conflict can be tricky.

> "graejo5.apple.com.local.arpa"? "graejo5.local.arpa"? Or some other 

I don't own the domain apple.com. I can't just pick any name in that 
domain. That domain is handled by an administrator at Apple. I don't 
own the dsl.sntc01.pacbell.net domain either. Come to think of it, I 
don't really own any domain. What name should I pick? How do I go about 
picking one? How do I make sure that it won't conflict with a name 
somewhere in the DNS namespace? If the name does exist in the DNS 
namespace, someone with access to a DNS server may be unable to use 
LLMNR to find me. If there is a specific domain for LLMNR names, the 
domain can be used to specify that the name should be resolved using 
LLMNR. People who don't have authority over any domain will still have 
a way to use LLMNR. Names in that domain will have certain properties. 
They won't be globally unique, they will be unique only on the local 
link. This would give me the freedom to pick any LLMNR name. The 
protocol can detect a conflict and notify me, at which time I can pick 
a new unique name or maybe my LLMNR responder could automatically 
generate a unique name.

> is a problem whether you're using "local.arpa" or not.

Service discovery is ideal but there are many tools that exist today 
that could make use of LLMNR. For example, my ssh client doesn't know 
about any service discovery mechanisms. The ability to use a name 
instead of addresses with an ssh client is very desirable. The same is 
true of a web browser. Few web browsers support any service discovery 
mechanisms. The ability to use a name instead of an address when typing 
in a URL for my buddies machine is very useful. Such a name would 
continue to work even if the network topology changes, as long as my 
buddy and I are still on the same local network and our names don't 
conflict with other names on that network.

-josh