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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf