Subject: Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 30 Aug 2005 23:48:07 +0200

On 10-aug-2005, at 20:47, The IESG wrote:

> The IESG has received a request from the DNS Extensions WG to  
> consider the
> following document:

> - 'Linklocal Multicast Name Resolution (LLMNR) '
>    <draft-ietf-dnsext-mdns-42.txt> as a Proposed Standard

> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2005-08-24.

Sorry for the delay.

After the discussion on the IETF list I thought it prudent to do a  
more thorough review of the draft.

This statement:

[a]  Responders MUST listen on UDP port 5355 on the link-scope multicast
      address(es) defined in Section 2, and on UDP and TCP port 5355 on
      the unicast address(es) that could be set as the source address 
(es)
      when the responder responds to the LLMNR query.

Seems to be in conflict with:

    Unicast LLMNR queries MUST be done using TCP and the responses MUST
    be sent using the same TCP connection as the query.  Senders MUST
    support sending TCP queries, and responders MUST support listening
    for TCP queries. If the sender of a TCP query receives a response to
    that query not using TCP, the response MUST be silently discarded.

    Unicast UDP queries MUST be silently discarded.

Why would a responder be required to listen on unicast UDP and then  
have to silently discard anything that comes in?

    Section 2.4 discusses use of TCP for LLMNR queries and  
responses.  In
    composing an LLMNR query using TCP, the sender MUST set the Hop  
Limit
    field in the IPv6 header and the TTL field in the IPv4 header of the
    response to one (1).  The responder SHOULD set the TTL or Hop Limit
    settings on the TCP listen socket to one (1) so that SYN-ACK packets
    will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
    prevents an incoming connection from off-link since the sender will
    not receive a SYN-ACK from the responder.

    For UDP queries and responses, the Hop Limit field in the IPv6  
header
    and the TTL field in the IPV4 header MAY be set to any value.
    However, it is RECOMMENDED that the value 255 be used for
    compatibility with Apple Bonjour [Bonjour].

Why not REQUIRE that UDP queries/responses have a TTL of 255. Then  
the receiver of a packet can determine with almost complete certainty  
that the packet didn't traverse any routers by checking if the  
received packet has a TTL of 255. (See (amongst others) ICMPv6 for  
how this works.)

    Since LLMNR queries can be sent when DNS server(s) do not  
respond, an
    attacker can execute a denial of service attack on the DNS server(s)
    and then poison the LLMNR cache by responding to an LLMNR query with
    incorrect information.

Couldn't have said it better myself.

LLMNR takes the approach of intermingling the locally resolved  
namespace with the globally resolved namespace. This will lead to  
security problems such as the one mentioned above (the security  
considerations section is way too cavalier), but also unduly puts  
strain on both the local and the global mechanisms in the expected  
common case where a host will first try to resolve a name globally  
and failing that, try to resolve the name locally.

For instance, when a user configures a name that doesn't exist in the  
global namespace on a locally reachable device, and then references  
that device by name, this will involve the global DNS unnecessarily.  
Since the intended result does materialize, the user doesn't see a  
failure condition and the situation persists.

Alternatively, whenever there is a failure in the global DNS, for  
instance because of lack of reachability, unavailability of a DNS  
server or the user typing an incorrect name, this will result in a  
local multicast query. On some links this is very undesirable. Low- 
bandwidth links such as cell phone data services are an obvious  
example. Another one is IEEE 802.11x. Due to its one-to-many nature  
broadcasts and multicasts must be sent at an artificial low bitrate  
on these links, using up an inordinate amount of link bandwidth  
relative to the packet size.

I suggest that the IESG either send back the draft to the wg to fix  
these problems or at most approves publication as an experimental RFC  
and NOT a standards track RFC.

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

---

From: Ned Freed <[email-masked]>
Date: Tue, 30 Aug 2005 15:55:56 -0700 (PDT)

> more thorough review of the draft.

Agreed. Although this is not gernally my area, the discussion led me to
review the document.

> have to silently discard anything that comes in?

Indeed. It certainly seems unnecessary to me.

> received packet has a TTL of 255. (See (amongst others) ICMPv6 for

This seems like a reasonable suggestion.

>     Since LLMNR queries can be sent when DNS server(s) do not respond, an

> and failing that, try to resolve the name locally.

Quite correct. In addition, the approach of trying the global DNS then falling
back to LLMNR seems likely to create fertile ground for screwy and hard
to trace errors.

Suppose, for example, the LLMNR resolver is configured (intentionally or
otherwise) to respond to some names that are also defined in the DNS. Perhaps
this was done to provide a fallback service, perhaps it was done in error,
whatever. But since normal DNS provides the information under normal
circumstances this information ends up not being used. Soon it is forgotten,
updates aren't done, and the information goes stale. Then the DNS service
experiences a transient failure. LLNMR now provides the information, but oops,
it's way out of date. And of course by the time someone attempts to track down
the problem the DNS will no doubt be back up and nobody will be able to figure
out what happened.

Debugging name service problems is already difficult enough, thank you very
much, without this added wrinkle.

> failure condition and the situation persists.

It has been claimed elsewhere that this is not so much of an issue because DNS
servers can be configured to reject such queries. I'm afraid I don't buy this
claim, for two reasons. First and most important, implementing such a setup
requires that sites understand and implement consistent naming policies. This
rarely happens in practice. Second, while such setups aren't difficult to
implement with most nameservers, they aren't exactly trivial either. And many
admins are very reluctant to mess around with name server configurations for
fear of breaking something.

> relative to the packet size.

A few additional comments on the draft:

(1) Section 2.3 talks about using LLMNR and MX records to "find a local
    mail server". Trouble is, MX records are used for mail routing on the
    Internet. They are not designed for or used to locate local mail
    servers. And even if this usage made sense, IMO it is inappropriate for
    this document to talk about ways to locate a mail service, if for no
    other reason than service location is supposed to be out of scope.

(2) The abstract and to some extent the introduction talk about the goals of the
    protocol and what the protocol isn't supposed to be. They really should
    focus on what the protocol is.

(3) The entire document seems hugely convoluted and full of warnings,
    caveats, and restrictions. Perhaps this is unavoidable, but the general
    feel is that of a specification grudgingly agreed to as part of some
    sort of compromise, rather than work done to meet a real need.
    Reading the document, I cannot imagine actually wanting to implement it.

(4) Section 2.5 talks about using a TTL value of 255 "for compatibility with
    Bonjour". Given that this work is claimed to be orthogonal to mDNS
    I don't understand why this was included.

> and NOT a standards track RFC.

IMO this needs major work even before being approved as experimental. The
overlapped namespace approach in particular seems hugely problematic and IMO
needs to be replaced.

				Ned

P.S. Please note that I have taken no position on the LLMNR vs mDNS debate. I
haaven't even looked at the mDNS specifications. My comments here are solely on
having reviewed LLMNR.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 31 Aug 2005 02:01:25 +0200

One more thing:

On 31-aug-2005, at 0:55, Ned Freed wrote:

>>     composing an LLMNR query using TCP, the sender MUST set the  
>> Hop Limit

I've heard reports in the past that attackers were able to spoof  
their end of a TCP session without being able to see return traffic.  
Obviously this is very hard to do if the TCP implementation uses  
enough randomness in its initial sequence numbers, but nonetheless it  
seems prudent to make it possible for the RECEIVER to check whether  
an incoming packet was forged (with the TTL=255 trick) rather than  
depend on the quality of the initial sequence number generation  
algorithm.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 30 Aug 2005 23:40:19 -0400

On Tuesday, August 30, 2005 15:55:56 -0700 Ned Freed 
<[email-masked]> wrote:

> overlapped namespace approach in particular seems hugely problematic and
> IMO needs to be replaced.

I've only read this document briefly, but based on what I've seen and on 
the descriptions and explanations in the current discussion, I have to 
agree.  The overlapped namespace approach has significant problems, which 
have been mentioned here.  It generates load in the form of additional 
queries on caching servers and on the global DNS roots for names those 
servers are never expected to be able to resolve, and in the form of 
multicast traffic on the local link for potentially every failed query 
against the global DNS.

It also creates massive ambiguities in the namespace, by allowing any host 
on the local link to claim any global DNS name which happens not to resolve 
at the moment (even if due to a temporary failure).  This means that names 
which are intended to be part of the global DNS namespace may resolve 
differently depending on one's location, or what hosts might be responding 
to LLMNR requests on the local network.

This is a problem so egregious that the IAB wrote a document about it 
(RFC2826).  While the majority of that document pertains specifically to 
recurring "alternate root" proposals, much of it applies equally well here 
-- "alternate roots" are a bad idea because they split what needs to be a 
single global namespace into several alternate namespaces.  The use of the 
overlapped-namespace approach with LLMNR does the same thing, only instead 
of creating a few alternate roots, it creates millions.

> P.S. Please note that I have taken no position on the LLMNR vs mDNS
> debate.  I haaven't even looked at the mDNS specifications.

Me either.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 31 Aug 2005 09:54:49 +0200

> of creating a few alternate roots, it creates millions.

Good summaries, good points.

I do not believe the LLMNR specification should be published in
its current form; the namespace confluence is extremely bothersome,
and should not be accepted even for publication as an experimental
RFC.

Even if the namespace confluence problem is corrected, it seems
more appropriate - given the deployment of mDNS - to publish both
mDNS and LLMNR as experimental RFCs.

	Henrik.