Subject: Re: DNSEXT Document Review: LLMNR-45

From: Edward Lewis <[email-masked]>
Date: Thu, 12 Jan 2006 11:49:16 -0500

I don't understand this question...

>We would like to specifically ask the working group:
>    b) that it supports the thought that issue 1 and 2 are indeed out
>       of scope;

Not having read the draft, so I can't comment on that above, but -

What difference does it make if the document 
considers, in particular issue 1, to be out of 
scope?  Having read the arguments on issue 1, I 
can't see the reasoning behind the IETF marking 
as a standard a protocol that has a significant, 
non-compatible, non-interoperable alternative in 
the same solution space.  From that aspect alone, 
I would place this document as an Informational 
document, not a standards track document, no 
matter how solid it is.

Whether I am applying the right metric is 
debatable.  The IETF has standardized protocols 
while competing approaches abounded - TCP vs. 
OSI's and DECnet's protocols.  OSI never became 
widely deployed, DECnet never really materialized 
on other platforms.  (Maybe it did, but I recall 
putting TCP on DEC machines and  not DECnet on 
Unix machines.)  But given the degree of 
deployment of the alternative in this case, I am 
not convinced the document has a shot at gaining 
standards track.  (If someone knows of precedents 
to the contrary, they might change my mind.)

Note that I started with "haven't read"...this is 
not a judgement of the document but a positioning 
of it.  Further, my question is about the chair's 
question - I am remarking that it seems not to 
make sense to me and for guidance of what a "yes" 
or "no" answer to it means.

At 11:08 -0500 1/12/06, Ólafur Guðmundsson /DNSEXT
  co-chair wrote:
>Dear Colleagues
>
>In http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01251.html
>our AD, Margaret Wasserman summarized the IETF Last Call
>and provided the reasons why LLMNR should not be forwarded to the
>IESG. She asked the DNSEXT working group to resolve the issues and
>suggested a new IETF last call when the issues where addressed.
>Note that after posting of the above mail there was significant
>discussion on the IETF list.
>
>Below are the issues brought up by Margaret:
>
>(1) Concerns that publication of this protocol will be confusing
>or actively harmful given the existing wide deployment of Apple's
>mDNS protocol.
>
>(2) Security concerns have been raised about the fact that
>applications on hosts that implement LLMNR will not be able to
>tell if a response has come from the DNS or from a local lookup.
>
>(3) Separate, but perhaps underlying both of the previous issues,
>there seems be a fundamental disagreement about what technical
>approach we should take to link-local name lookup. LLMNR takes the
>approach that local lookups should use the same names as global
>lookups and that upper layers should not care whether a name was
>resolved in the global DNS or locally, essentially making the
>local lookup mechanism an extension of the DNS. mDNS takes the
>approach that local lookups should be distinguishable from global
>lookups and accomplishes this through the use of a special local
>domain (.local).
>
>
>Bernard argued in 
>http://www1.ietf.org/mail-archive/web/ietf/current/msg37767.html
>that points 1 and 2 are resolver and API issues respectively.
>
>Since the start of the IETF last call 
>(LLMNR-42), Bernard has updated the document  3 
>times,
>The current version is available at
>    http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-45.txt
>the diff´s are available at:
> 
>http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-mdns/draft-ietf-dnsext-mdns-43-from-42.diff.html
> 
>http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-mdns/draft-ietf-dnsext-mdns-44-from-43.diff.html
> 
>http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-mdns/draft-ietf-dnsext-mdns-45-from-44.diff.html
>
>These edits have been vetted through several ISSUES on the
>mailing-list. The issue tracker for LLMNR is at
>   http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
>
>We are asking the working group to thoroughly review version 45.
>
>We would like to specifically ask the working group:
>
>    a) that it agrees that all protocol issues have been properly
>       addressed;
>    b) that it supports the thought that issue 1 and 2 are indeed out
>       of scope;
>    c) and that Issue 3 is indeed clarified in version 0.45 of the
>       document.
>
>If there is consensus on the fact that the answer to the 3
>questions above is yes then we will forward the document to the
>IESG once more. If there is no consensus on one of the 3 questions
>(based on technical arguments) then more work needs to be done or,
>alternatively, we drop the work and ask Margaret to support
>publication as an informational RFC (please provide arguments).
>
>If we do not get sufficient feedback on this i.e. fewer than 5
>people indicate they have thoroughly reviewed the document  then we
>will inform our AD that the DNSEXT working group failed in
>delivering a review of chartered work and request removal of the
>work item.
>In that case we plan to suggest to the AD, that as this document has
>seen detailed technical review this working group will not
>object if this document being published as informational (unless
>the working group instructs us not to do so).
>
>We plan review the discussion on this item during the second week
>of February, please send your comments no later than on February 5'th.
>
>	The DNSEXT chairs
>	Olaf & Ólafur
>
>
>--
>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/>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Inactionable unintelligence is bliss.

--
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: Paul Vixie <[email-masked]>
Date: Thu, 12 Jan 2006 17:42:17 +0000

much as it pains me for it to be ed lewis (of all people) that i agree with, i
agree with ed lewis here.  bernie, can you offer us some guideance as to your
interest or your employer's interest in seeing LLMNR standardized?  why aren't
you able to use apple's existing similar technology to achieve your aims here?

re:

# >We would like to specifically ask the working group:
# >    b) that it supports the thought that issue 1 and 2 are indeed out
# >       of scope;
# 
# Not having read the draft, so I can't comment on that above, but -
# 
# What difference does it make if the document considers, in particular issue
# 1, to be out of scope?  Having read the arguments on issue 1, I can't see
# the reasoning behind the IETF marking as a standard a protocol that has a
# significant, non-compatible, non-interoperable alternative in the same
# solution space.  From that aspect alone, I would place this document as an
# Informational document, not a standards track document, no matter how solid
# it is.
# 
# Whether I am applying the right metric is debatable.  The IETF has
# standardized protocols while competing approaches abounded - TCP vs. OSI's
# and DECnet's protocols.  OSI never became widely deployed, DECnet never
# really materialized on other platforms.  (Maybe it did, but I recall putting
# TCP on DEC machines and not DECnet on Unix machines.)  But given the degree
# of deployment of the alternative in this case, I am not convinced the
# document has a shot at gaining standards track.  (If someone knows of
# precedents to the contrary, they might change my mind.)
# 
# Note that I started with "haven't read"...this is not a judgement of the
# document but a positioning of it.  Further, my question is about the chair's
# question - I am remarking that it seems not to make sense to me and for
# guidance of what a "yes" or "no" answer to it means.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Jan 2006 15:02:24 -0500

Hello all,

I have read the current draft, and I am preparing some remarks; but I
first have some questions about the issues the A-D brought up.

On Thu, Jan 12, 2006 at 11:08:44AM -0500, Ólafur Guðmundsson /DNSEXT

> or actively harmful given the existing wide deployment of Apple's

That is the way she introduced it in her email; but I noticed that
her subsequent discussion of the question boiled down to two, in my
view distinct questions:

1.a.	That users will be confused, and potentially use .local.
1.b.	That large numbers of lookups for undelegated labels may end
up going to the global DNS.

It seems to me that these are different issues, and that it makes no
difference whether it is the label ".local" or something else for
which the query asks, unless the query is for something that is
already properly configured in the global DNS.  Perhaps I am
overlooking some way in which 1.b. depends strongly on 1.a.?  Because
it sort of looks to me like 1.b. might be true under this draft even
if users understand perfectly well that they shouldn't use .local. 

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Paul Vixie <[email-masked]>
Date: 15 Jan 2006 03:34:15 +0000

Paul Vixie <[email-masked]> writes:

> much as it pains me for it to be ed lewis (of all people) that i agree with

several of you took exception to this, on the assumption that ed and i aren't
friends (we are) or that my regard for ed and his work is low (it's very high)
or he will take it either seriously or personally (which he never has).

nevertheless, i have agreed with our esteemed WG chairs to set a better example
and keep my personal "ed joshing" off-list in the future.
-- 
Paul Vixie

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Jan 2006 17:02:26 -0500

Hello,

I have carefully read the document,
<http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-45.txt>. 
I do not object to it proceeding.  (I'd be a "don't care" in a show
of hands.)  I think the authors have worked hard to address the
concerns that were raised during IETF last call (I was one of the
people complaining, since I wasn't following this WG prior to that
LC).
  
Below are my comments.

On Thu, Jan 12, 2006 at 11:08:44AM -0500, Ólafur Guðmundsson

>    a) that it agrees that all protocol issues have been properly

I believe so.

>    b) that it supports the thought that issue 1 and 2 are indeed out

No.  I do not see how a potential significant increase in load to the
global DNS (which is entailed by the discussion of issue 1) can be
out of scope for a mechanism whose behaviour is indistinguishable to
users from the behaviour of the global DNS, and that is specified
such that it relies on some behaviour of the global DNS.  That said,
the addition of the remarks in section 1, point [2] and following,
plus the recommendation in the IANA Considerations section about the
right to use a FQDN, address the issue to some extent.  

The discussion of the extent to which spoofing threats are already
present in the DNS (plus the recommendations around use of a FQDN)
seem to me to give enough guidance to implementors.

>    c) and that Issue 3 is indeed clarified in version 0.45 of the

Sort of.  What I am slightly puzzled about is that, given the
suggestions about how to handle single-label names and the suggestion
that users reserve a FQDN if they want to use it with LLMNR, I'm not
sure what is so different about this proposal from Apple's mDNS; and
mDNS, as far as I can tell, has the additional benefit that a mistake
in configuration doesn't automatically leak to the global DNS.

Anyway, I think the document draws enough attention to what I
believed were very serious problems.  I now regard them as merely
potential problems (coming mostly from poor though maybe conformant
implementations), so I don't object to the document proceeding.

A

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Mon, 23 Jan 2006 23:59:33 -0500

>Not having read the draft, so I can't comment on that above, but -

Bernard argued that issue 1 and 2 are issues that will not have to be
fixed in the llmnr specification but that they are resolver and API
issues.

The question is if the working group agrees with that argument and
support the thought that issue 1 and 2 are indeed out of scope for
the llmnr specification.

If the working group agrees with this view we do not have to address
these issues in the specs and we can report the WG opinion to the AD.
That is more or less what a 'yes' would mean. A 'no' would mean more
work for this group. If that is the outcome we will return to the
group to ask if there is consensus to continue spend more iterations,
but first things first. Lets answer the question at hand.

         Olafur & Olaf

---

From: [email-masked]
Date: Tue, 24 Jan 2006 10:43:09 +0000

> support the thought that issue 1 and 2 are indeed out of scope for

	this raises the (perhaps) interesting question about the
	remit of the WG.  Is the resolver and its associated API(s)
	part of the DNS or not?

>         Olafur & Olaf

--bill

---

From: Tony Finch <[email-masked]>
Date: Tue, 24 Jan 2006 13:29:09 +0000

> fixed in the llmnr specification but that they are resolver and API

What changes should be made to RFC 3493 as a consequence of LLMNR?

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 24 Jan 2006 11:16:37 -0500

> 	remit of the WG.  Is the resolver and its associated API(s)

It seems to me that, if the answer is no, then LLMNR doesn't belong
here anyway (since it is an alternative to DNS); and if the answer is
yes, then the original questions 1 and 2 have to be considered
in-scope.

A

-- 
Andrew Sullivan  | [email-masked]
It is above all style through which power defers to reason.
		--J. Robert Oppenheimer

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 27 Jan 2006 09:29:35 +0100

On Thu, Jan 12, 2006 at 11:08:44AM -0500,
 Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]> wrote 
 a message of 89 lines which said:

> applications on hosts that implement LLMNR will not be able to tell
> if a response has come from the DNS or from a local lookup.

I've read the -45 document and I did not find flaws. 

I regard issue 2, above, as a non-issue: other name resolution
techniques like /etc/hosts or LDAP have the same behavior and nobody
complained that getnameinfo() cannot tell you from which service you
got the IP address.

May be just a small addition in Security Considerations:

Implementations should [lowercase, not RFC 2119] allow the system
administrator to disable completely the use of LLMNR [like what you
can do with a typical /etc/host.conf or equivalent].

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 27 Jan 2006 10:53:53 -0500

> or actively harmful given the existing wide deployment of Apple's

Not an in-scope (ie, techical) factor.

> tell if a response has come from the DNS or from a local lookup.

This is a feature not a bug. [That is, if multiple ~standardized naming
services are going to be ~supported, then application interoperability
between them would be a feature. I mean, NIS and NetBIOS names (and
/etc/hosts too) can be used by applications without needing to understand
the actual resolution service and providing similar functionality here
would be a competitive feature.]

These probably aren't the right questions however. The fact that LLMNR and
DNS are layered in the resolution path is indeed a problem, separate from
the above questions. For one thing, LLMNR names are absolutely not DNS
names and they should not be treated as such (they may look like DNS
names, and they may have even started out as DNS names, but once the
authoritative delegation path is removed from the query path those names
are absolutely not DNS names anymore [TTLs are not respected, and some
other host may have been given the official delegation], and so they
should not be treated as such). For another, using the DNS root as a
fallback for local (non-DNS) name resolution is bad manners at the least
(usurping a TLD is not exactly polite either but that's a different
protocol's problem). This seems to be part of your #3 issue, but which is
not presented as a consideration beyond a point of discussion. I think
it's the core issue myself.

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