Re: Summary of the LLMNR Last Call

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> I would be very interested in understanding what technical errors I made and I
> would appreciate if you would share the details with me, perhaps off-line.

The message sent to the IETF list contains several major technical errors, 
including:

a. Confusing DNS resolver behavior with the behavior of LLMNR 
implementations.  The sending of .local queries to the global DNS, while 
potentially a serious problem, results from the behavior of existing DNS 
resolver implementations.  This problem exists today on the vast 
majority of Internet hosts, which do not implement either mDNS or 
LLMNR.  Given this, putting language into the LLMNR specification 
to "fix" an orthogonal issue makes no sense. 

Even fixing the issue in another IETF specification could prove sticky, 
because it can be argued that the IANA has authority over the allocation of 
new TLDs such as ".local" not the IETF, which is why the DNSEXT WG 
recommended early on that the ".local.arpa" domain be used instead of 
".local". 

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.

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.  For example, *NIX systems have utilized 
/etc/host files, NIS and DNS;  Windows systems utilize LMHOSTS, DNS and 
NetBIOS.  The issue of integration of multiple name services is dealt 
within multiple RFCs, including RFC 1001 which defines NetBIOS and 
describes how it coexists with DNS and RFC 2937, which describes the Name 
Service Search Option for DHCP.  In practice, hundreds of millions of 
Internet hosts use these mechanisms every day.  If you type "http://foo/"; 
in the browser of a Windows host, a DNS query for "foo" is not sent over 
the wire; only a NetBIOS query is sent.  This is not rocket science. 

> Please remember, though, that most of my note was not meant to express my own
> technical opinion, it was an attempt to summarize the issues that were raised
> by others in this discussion.

The job of an IESG member is not to repeat mistatements, it is to use their 
judgement.  In this and other instances, the IESG appears to have lost sight 
of its mission.  The best interest of the Internet community lies not in 
blocking the publication of documents that fall outside today's orthodoxy, 
but rather in providing information to the Internet community.  In this case, 
that interest would be best served by publishing *all* documents 
relating to mDNS and LLMNR, especially the ones that the DNSEXT WG has found 
most objectionable (such as DNS-SD, and Bill Manning's DISCOVER OPCODE draft). 

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.  

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]