Re: Summary of the LLMNR Last Call

Russ Allbery <> Tue, 20 September 2005 05:01 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1EHaGT-0005cT-1J; Tue, 20 Sep 2005 01:01:57 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1EHaGR-0005c2-3l for; Tue, 20 Sep 2005 01:01:55 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id BAA21949 for <>; Tue, 20 Sep 2005 01:01:54 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1EHaMB-0000CS-7T for; Tue, 20 Sep 2005 01:07:52 -0400
Received: from (windlord.Stanford.EDU []) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j8K51eYU002448; Mon, 19 Sep 2005 22:01:40 -0700
Received: by (Postfix, from userid 1000) id 0573CE7CA7; Mon, 19 Sep 2005 22:01:40 -0700 (PDT)
From: Russ Allbery <>
To: Bernard Aboba <>
In-Reply-To: <> (Bernard Aboba's message of "Mon, 19 Sep 2005 21:31:05 -0700 (PDT)")
Organization: The Eyrie
References: <> <p0620074fbf5509dd070a@[]> <>
Date: Mon, 19 Sep 2005 22:01:39 -0700
Message-ID: <>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: Margaret Wasserman <>,
Subject: Re: Summary of the LLMNR Last Call
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Bernard Aboba <> writes:

> b. Confusion between security issues and namespace separation.  In
> peer-to-peer name resolution protocols, it is possible for a responder
> to demonstrate ownership of a name, via mechanisms such as DNSSEC.  It
> is also possible for a responder to demonstrate membership in a trusted
> group, such as via TSIG or IPsec.  If DNSSEC is available, spoofing
> attacks are not possible, and querying for FQDNs does not expose the
> sender to additional vulnerabilities.  Both the mDNS and LLMNR
> specifications agree on this point.

We agree that home burglary is a serious problem.  This is why we
recommend that everyone hire an armed guard for their house.  If your
house is monitored by armed guards, burglary is very unlikely.  Given that
there is an effective security mechanism available, there's really no need
to consider simple deterrants that won't provide true security.

> c. Lack of consideration of existing practice.  Internet hosts have used
> multiple name resolution mechanisms based on a single API for more than
> two decades, with no ill effects.

"No ill effects" is a horribly inaccurate description of the effects of
that design.  A much more accurate description would be that Internet
hosts have used multiple name resolution mechanisms through a single API
out of necessity for more than two decades, have suffered frequent ill
effects up to and including major outages because of it, but have
struggled along with that design because there are some features provided
by it that are too useful to completely dismiss in general.  That being
said, most systems attempt to avoid using those features when feasible and
attempt to make all sources of information match exactly to avoid the
serious and often hard-to-diagnose problems of conflicting information.

If you think that using /etc/hosts, NIS, and DNS at the same time on
systems to provide name resolution is a *success* story, your perceptions
of the practical problems of name resolution in Internet hosts is
drastically different than mine.  You've also had to maintain far less
code to try to work around bizarre inconsistencies in gethostbyname
responses than I have.

> I must admit that at one point, I did not see value in funding the RFC
> Editor to publish documents outside of the IETF process, via the RFC
> Editor Individual Submission route, described in RFC 3932.  However, now
> it has become abundantly evident that this represents an important
> safety mechanism that needs to be preserved going forward.

I suppose that's one reaction to a general IETF mailing list consensus
that a protocol raises serious concerns.  I don't think it's a
particularly useful one, though.

Russ Allbery (             <>

Ietf mailing list