Subject: Summary of the LLMNR Last Call

From: Margaret Wasserman <[email-masked]>
Date: Sun, 18 Sep 2005 10:09:07 -0400

Hi All,

As I am sure many of you have noticed, there was extensive discussion 
during the IETF Last Call for "Link Local Multicast Name Resolution 
(LLMNR)" specification that is currently available as 
draft-ietf-dnsext-mdns-43.txt.  Thanks to all who participated!  The 
discussion appears to have quieted down at this point, so I will 
attempt to summarize the discussion and see if we can reach some 
conclusions.

First, I'll give a brief summary of the responses received:

By my count 38 separate individuals responded to the Last Call.  Some 
of these people responded on the IETF list, some on the IESG list, 
and some privately to me.  People who responded privately to others 
were not counted  :-).

Of the 38 respondents, only 18 of them stated an explicit opinion on 
the publication of LLMNR as a Proposed Standard RFC.  Others provided 
useful facts to inform the discussion and/or discussed other topics, 
such as the structure of the DNS root.  I was quite conservative 
about how I determined people's opinions, and I tried not to infer 
peoples' opinions from factual statements about only one of the 
protocols, etc.

Of the 18 people who expressed an explicit opinion, 14 people argued 
against the publication of LLMNR as a Proposed Standard.  I realize 
that we don't vote on specifications in the IETF.  I also realize 
that the IETF LC is worded to encourage the statements of objection 
and not to encourage statements of support.  However, the fact that 
14 separate individuals felt strongly enough that this document 
should not be published to say so explicitly in response to an IETF 
LC must be taken quite seriously.

In addition to a few minor nits or comments, all of which have been 
captured in the issue tracker, there seem to be three major concerns 
with the publication of this protocol:

(1) Concerns that publication of this protocol will be confusing or 
actively harmful given the existing wide deployment of Apple's mDNS 
protocol.

Concerns here seem to hinge on whether end-users will use .local 
extensions because they _think_ that they have mDNS available when 
they actually do not, which, when combined with LLMNR's default 
behavior of querying the DNS first, will result in a larger number of 
.local lookups in the global DNS.  There are several possible ways to 
alleviate this issue, including suppression of global queries for 
.local domains as part of an LLMNR implementation, or suppressing 
recursive lookups for names in the .local domain on the local DNS 
server, but none of these solutions is currently specified in the 
LLMNR specification or elsewhere.

(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.

This opens applications to attack from nodes that can block global 
DNS access and substitute local resolution.  Some ways to eliminate 
or alleviate this issue might include:  using different domains (such 
as .local) to distinguish global and local lookups, explicitly using 
different global and local lookup mechanisms at the application 
level, only falling back to local resolution when a "no such name" 
response is received from the global DNS, placing further limits on 
what answers are acceptable from local lookups (only for certain 
domains configured as local, only within certain IP subnets...).

This security concern does not seem to be adequately explored and 
addressed in the LLMNR specification.  At the very minimum, it should 
be carefully explored in the security considerations section so that 
implementers and users can be aware of these concerns.

(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).

This is an issue that has been discussed extensively in the DNSEXT WG 
at various times, and consensus was found to proceed with the LLMNR 
approach.  However, it is not clear whether that consensus is held by 
the wider IETF community, as there are at least 14 people in the IETF 
who have explicitly disagreed with that decision during IETF LC.

So, based on the IETF LC discussion of this document, I have come to 
two conclusions:

CONCLUSION 1:  There are at least two blocking technical issues with 
the LLMNR specification (raised in items #1 and #2 above) that would 
need to be resolved before this document is technically ready for 
publication as an Proposed Standard RFC.  We should resolve these 
issues and determine that the IETF community is satisfied with their 
resolution before sending the document to IESG review.

CONCLUSION 2: The IETF community does not currently have consensus to 
standardize a local name resolution mechanism that takes the approach 
described in LLMNR.  Further work would be needed to establish the 
IETF consensus required to publish this document as a Proposed 
Standard.

Based on these conclusions, I do not intend to forward the LLMNR 
specification to the IESG for review and approval.  I am planning to 
send the document back to the WG for resolution of these issues and 
would issue another IETF LC if/when the WG believes that they have a 
document that will address these issues and reach IETF consensus.

We have a number of choices about how to proceed in this situation, 
but before we talk about next steps, I would like to hear any 
feedback that people might have regarding my summary of the 
discussion so far and the conclusions that I have reached from it.

Margaret

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: grenville armitage <[email-masked]>
Date: Mon, 19 Sep 2005 10:06:20 +1000

Margaret Wasserman wrote:
	[..]
> We have a number of choices about how to proceed in this situation, but 
> before we talk about next steps, I would like to hear any feedback that 
> people might have regarding my summary of the discussion so far and the 
> conclusions that I have reached from it.

As a (so far) silent observer of the LLMNR Last CAll thread on [email-masked]
I believe you've pretty much summarised the thread's key points correctly
(modulo Stuart's clarification a few hours ago), and your conclusions seem
justifiable.

cheers,
gja

---

From: Robert Elz <[email-masked]>
Date: Wed, 21 Sep 2005 21:32:00 +0700

Date:        Sun, 18 Sep 2005 10:09:07 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <p0620071dbf52f99dab4c@[192.168.2.2]>

I am not going to comment on the substance of the issues, or the
doc in question, as I haven't been following what is happening with
it, nor have a read a recent version.

But ...

  | Based on these conclusions, I do not intend to forward the LLMNR 
  | specification to the IESG for review and approval.

What kind of process is going on here?    As I recall it, from rfc2026,
it is the IESG that issues last calls, when it has a doc for review, and
the IESG that decides if a last call has passed or not (that is, the IESG
takes input from the comments received during the last call to help it make
its decision on what to do with the doc that has been presented to it).

How did we ever get an IETF last call on a doc that hasn't even gone to
the IESG (apparently) but is still (apparently) under AD review ?

And how does one AD (alone, apparently) get to draw conclusions based upon
the results of the last call ?

What is happening here?   Can't the IETF manage to either follow its
own documented processes, or change them in the approved way?

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 21 Sep 2005 11:06:52 -0400

Hi Robert,

Our process, as currently instantiated, has three stages after a 
document is submitted to the IESG for review/approval:

1. AD Review -- the responsible AD reviews the document and 
determines if is ready for IETF LC.  Sometimes other things happen at 
this stage, like review by certain specialist groups (such as the MIB 
doctors) and/or resolution of AD Review comments.
2. IETF LC -- the document goes to IETF LC, after which the 
responsible AD determines whether the community has consensus to 
publish the document.  Any issues raised in IETF LC need to be 
addressed before he document is approved by the IESG.
3. IETF Evaluation -- the full IESG reviews the document on a 
telechat, stating positions (yes, no objection, discuss, abstain or 
recuse) on the document.  Any discuss positions have to be resolved 
before the document is forwarded to the RFC editor for publication. 
For a standards track document, there must also be at least one 'yes' 
position and at least 9 'yes/no-ob' positions for a document to be 
approved for publication.

It was my job (as responsible AD for DNSEXT) to perform the AD 
review, send the document to IETF LC, determine whether or not we 
have IETF consensus to publish the documen and make sure that any 
substantive issues raised during IETF LC are addressed before sending 
the document to the IESG for review.

In my opinion, based on the results of the IETF LC, the IETF LC 
raised two substantive technical issues with this specification, and 
the IETF community does not currently have consensus to publish this 
document as a Proposed Standard.  If the WG continues to believe that 
this document should be published as a Proposed Standard, they will 
address these technical issues (through changes to the document, 
informing the community why changes are not needed, or other means) 
and produce a document that will achieve IETF community consensus.

Like all decisions made by ADs, my decision is, of course, subject to appeal.

Margaret