Re: Summary of the LLMNR Last Call

Bernard Aboba <aboba@internaut.com> Mon, 19 September 2005 23:52 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHVRM-0007vL-CN; Mon, 19 Sep 2005 19:52:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHVRK-0007uh-9m for ietf@megatron.ietf.org; Mon, 19 Sep 2005 19:52:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08907 for <ietf@ietf.org>; Mon, 19 Sep 2005 19:52:48 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHVX1-0001sY-QO for ietf@ietf.org; Mon, 19 Sep 2005 19:58:45 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1EHVRB-000JBA-Lg for ietf@ietf.org; Mon, 19 Sep 2005 19:52:41 -0400
Received: by internaut.com (Postfix, from userid 1000) id A05D435015; Mon, 19 Sep 2005 16:52:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 9165035000 for <ietf@ietf.org>; Mon, 19 Sep 2005 16:52:41 -0700 (PDT)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information)
X-MHO-User: aboba
Date: Mon, 19 Sep 2005 16:52:41 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: ietf@ietf.org
Message-ID: <Pine.LNX.4.61.0509191647510.23762@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Subject: Re: Summary of the LLMNR Last Call
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stuart Cheshire said:

"This claim is one of the bits of misinformation that seems to be spread
about mDNS for some reason. It's repeated so often that people who
haven't read the draft assume it's true."

[BA] Right.  Margaret's message was technically wrong on a large number
of points, mischaracterizing mDNS, LLMNR and even DNS.  

Stuart continues:

"Even on Mac OS 9, five years ago, if you looked up "www.ietf.org" and had
no unicast DNS servers configured, it would look it up via mDNS instead.
The difference is that we were profoundly nervous about the implications
of doing this without adequate security, which is why
draft-cheshire-dnsext-multicastdns.txt allows multicast lookups for
non-local names, but says:"

[BA] Completely agree.  Sending unsecured queries for FQDNs via a 
link-scope multicast protocol is potentially dangerous.  This should only 
be done in situations where the security concerns can be addressed.  This is why 
the LLMNR specification describes usage restrictions (Section 2) as well as 
authentication mechanisms (Section 5.3).

   (14. Enabling and Disabling Multicast DNS)

   The option to fail-over to Multicast DNS for names not ending
   in ".local." SHOULD be a user-configured option, and SHOULD
   be disabled by default because of the possible security issues
   related to unintended local resolution of apparently global names.

[BA] The LLMNR specification contains similar language, except using a MAY 
instead of a SHOULD:

"  While these conditions are necessary for sending an LLMNR query, they
   are not sufficient.  While an LLMNR sender MAY send a query for any
   name, it also MAY impose additional conditions on sending LLMNR
   queries.  For example, a sender configured with a DNS server MAY send
   LLMNR queries only for unqualified names and for fully qualified
   domain names within configured zones."

The reason that this is only a MAY is because if security mechanisms 
are in place (DNSSEC, TSIG, IPsec) then queries for FQDNs may be sent 
securely.

[Stuart]

   (24. Security Considerations)

   When DNS queries for *global* DNS names are sent to the mDNS
   multicast address (during network outages which disrupt communication
   with the greater Internet) it is *especially* important to use
   DNSSEC, because the user may have the impression that he or she is
   communicating with some authentic host, when in fact he or she is
   really communicating with some local host that is merely masquerading
   as that name.

[BA] Agreed. Section 5.3 of the LLMNR specification describes the use 
of DNSSEC as well as other security mechanisms such as TSIG and IPsec.  
Use of LLMNR with TSIG has been demonstrated in running code.

[Stuart]

The difference between mDNS and LLMNR is not in their lookup of global
names, but that mDNS *also* designates a special sub-tree of the
namespace where users explicitly have different security expectations.

[BA] Actually, LLMNR and mDNS don't differ in this respect.  LLMNR also 
enables use of special sub-trees.  As an example, Windows implementations 
today treat single-label names specially; queries for these names are 
never sent to the DNS, only over NetBIOS.

However, LLMNR, while describing the use of special sub-trees, does not 
prescribe the special sub-tree that implementations should use.  Some
implementations might designate the single-label space as special;
others might use ".local".  


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf