Subject: Fwd: Summary of the LLMNR Last Call

From: Margaret Wasserman <[email-masked]>
Date: Mon, 19 Sep 2005 08:19:49 -0400

Sorry, I mistyped "namedroppers" on this message the first time...

Margaret

>Date: Sun, 18 Sep 2005 10:09:07 -0400
>To: [email-masked]
>From: Margaret Wasserman <[email-masked]>
>Subject: Summary of the LLMNR Last Call
>Cc: [email-masked], [email-masked]
>Bcc:
>X-Attachments:
>
>
>Hi All,
>
>As I am sure many of you have noticed, there was extensive 
>discussion during the IETF Last Call for the "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
>
>
>

--
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: Edward Lewis <[email-masked]>
Date: Wed, 21 Sep 2005 11:26:47 -0400

Speaking as a working group participant and ...

At 8:19 -0400 9/19/05, Margaret Wasserman wrote:

...taking Margaret's message out of order...

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

Will this be fruitful?  I am directing the question to other WG participants.
(To Bernard - this is in no way to slight your work or your efforts. 
I am asking to judge whether I want to tune into the discussion on 
this.)

No insult is intended towards Bernard's efforts, but has there been 
significant interest by others (i.e., non-Bernard) in the WG?  I am 
asking because until now I have ignored the issue completely as I 
have no real driving interest in this topic.  But if the WG is being 
asked to take on what would be major work to solve the problems, I'll 
start to take notice.

If the goal of the IETF is interoperability, it seems unwise to 
standardize one approach to a problem when there is a incompatible 
approach in use.  I don't want to make this about Microsoft vs. Apple 
(I am saying that openly because it seems to be a smoldering concern 
in the LC comments), but rather the granting of the title of 
"standard" when there is clearly a choice of approaches.

LLMNR vs. mDNS isn't an isolated case of this, but it's the one case 
being put before the WG.

It seems to me that concerns 1 and 3 could be erased by removing 
LLMNR from standards track and publishing it as informational or even 
experimental.  Security concerns I understand and would become a work 
item, although my senses are that "security concerns" can become a 
work item that fills all space and time allotted for it.

I'm curious if the WG wants to take this back.  It's (I mean the 
problem, not the proposed solution) lingered so long, is there energy 
to solve the concerns raise in the last call?  Is there any, *any*, 
chance we can merge LLMNR and mDNS?  If not, I really don't think 
it'll be worth an interoperable standardization effort.

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

>>CONCLUSION 1:  There are at least two blocking technical issues with the
>>LLMNR specification (raised in items #1 and #2 above)...

>>CONCLUSION 2: The IETF community does not currently have consensus to
>>standardize a local name resolution mechanism...

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

If you knew what I was thinking, you'd understand what I was saying.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Sep 2005 17:12:59 +0000

# It seems to me that concerns 1 and 3 could be erased by removing LLMNR from
# standards track and publishing it as informational or even experimental.

that's what happened to the SRV RR, and it hasn't hurt apple's or microsoft's
business at all to have the dreaded "experimental" tag on that RFC.

# I'm curious if the WG wants to take this back.  It's (I mean the problem,
# not the proposed solution) lingered so long, is there energy to solve the
# concerns raise in the last call?  Is there any, *any*, chance we can merge
# LLMNR and mDNS?  If not, I really don't think it'll be worth an
# interoperable standardization effort.

while i agree with this in general, i have three specific concerns.

1. the right way to do multicast DNS is draft-manning-opcode-discover-01,
   and while apple and microsoft both call their approaches "multicast dns"
   they are really "overloading dns to carry service discovery in multicast".

2. any attempt to merge mdns and llmnr MUST be backward compatible with mdns,
   since apple has created an important new economy of mdns services/devices
   and ietf should only ignore this economy if mdns is the provably wrong
   approach, rather than merely suboptimal in some way (that i'm unaware of).

3. if this is really about PnP, i sure wish that everybody would just say so
   and re-frame the debate in PnP terms and stop treating it as a dns issue
   that's somehow relevant to the skills of the core namedroppers community.