Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal

From: "Christian Huitema" <[email-masked]>
Date: Thu, 19 Feb 2004 18:24:56 -0800

> I support "MUST send with TTL=255, MAY reject if TTL<>255 on receipt",
> possibly with a paragraph emphasizing that routers SHOULD discard such
> packets if TTL<>255 (though this is perhaps broadening the ambit of
the
> document too far).

Which packets? Routers have no idea what application a packet belongs to
-- or in any case they are not supposed to care what application a
packet belongs to. LLMNR packets are indistinguishable from other
packets. Why should a router apply a different TTL treatment to them?

There is certainly a very strong case that multicast packets should be
sent with the shortest possible TTL, in order to minimize the risk of
flooding entire networks. Even for unicast packets, one can make the
point that using long TTL values allows for interesting hacks, e.g.
reflection DOS attacks against third parties.

The reflection DOS attack can only be prevented if the LLMNR nodes can
ensure that the addresses used in the communication are local in scope:
local scope multicast addresses, destination addresses that are on-link.
But if the LLMNR nodes can do that, then checking a TTL value of 255
does not bring any particular advantage.

If I understand correctly, rendezvous made the hypothesis that only
"link local" addresses would be used. LLMNR does not enforce that
restriction. Using TTL=1 is a logical consequence of allowing use with
regular IP addresses. 

-- Christian Huitema

--
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: "Bernard Aboba" <[email-masked]>
Date: Fri, 20 Feb 2004 09:04:09 -0800

[ Moderators note: Post by non-subscriber.  With the massive amount of
   spam, it is easy to miss and therefore delete relevant posts 
   by non-subsrcibers. Please fix your subscription addresses. ]

Robert Elz has made a convincing argument why TTL=1 should be set on 
multicast packets.   It also makes sense to set TTL=1 on LLMNR packets sent 
via unicast TCP, since if this is done the TCP three way handshake will 
ensure that a connection will only be set up to a host on the same link.  If 
TTL=255 were set on the TCP SYN, then an LLMNR connection could be set up to 
any host on the Internet.  This doesn't make sense for linklocal name 
resolution.

Then there is the issue of what the TTL should be on UDP unicast packets.  
There are two cases here:  UDP unicast queries and UDP unicast responses.  
Unicast UDP queries will presumably be sent largely to resolve PTR RRs;  
this is not the recommended transport, but it can be used.  Therefore I 
would make the same argument as for TCP queries, namely that TTL=1.  There 
is no reason for a linklocal name resolution protocol to send queries all 
over the Internet.

So we are left with the question of the TTL for UDP unicast response 
packets. Here we could set TTL=255 and (optionally) check on reception as 
Robert proposes, or we could set TTL=1.  In thinking about the 
risks/benefits of this, it's important to keep in mind the risks of DoS 
attack.  In the existing LLMNR specification, there is no support for 
"wildcard" queries.  However, the DISCOVER Opcode specification, if run on 
top of LLMNR, would add this capability.

Once "wildcard" queries are supported, we now have the possibility of an 
attacker sending a wildcard query from a spoofed address, and causing the 
victim to be deluged with responses.  Even with TTL=1 on responses this 
attack exists, but can only be used to attack someone on the local network.  
With TTL=255 set on responses, it can be used to attack anyone on the 
Internet.

To my mind, this was the argument that tipped the balance in favor of 
setting TTL=1 on UDP responses.

Note that this deicision is not mandated by the IPv4 Linklocal TTL 
specification.  In Section 2.7 of that specification, it is stated:

   A sensible default for applications which are sending from a Link-
   Local IPv4 address is to explicitly set the IPv4 TTL to 1.  This is
   not appropriate in all cases as some applications may require that
   the IPv4 TTL be set to other values.

LLMNR responses can be sent from any source address, so this text does not 
apply in many situations.  Also,  the above text leaves the decision to the 
application.  So I think that this is purely an LLMNR decision.

_________________________________________________________________
Take off on a romantic weekend or a family adventure to these great U.S. 
locations. http://special.msn.com/local/hotdestinations.armx

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Feb 2004 11:37:00 -0800 (PST)

Robert Elz noted:

"While Bernard is right, that for TCP, a TTL of 1 would also work, I don't
think I really want that level of detail being checked, and would prefer
if simply all unicast was treated the same."

I'd argue that the distinction to make is between queries and responses,
not between unicast and multicast.  I believe that queries of any type
need to have TTL=1 (no check implied);  for responses, TTL=255 can be
considered, along with an (optional) check.

TTL=1 on queries is really about scaling and "fast fail", not
security.  Since LLMNR can be used to resolve *any* name where
the DNS  server does not respond or responds with RCODE=0 and no RRs
or RCODE=3, it was important to scaling to ensure that
LLMNR queries do not escape the local link. Otherwise,
LLMNR could add signficantly to DNS traffic on bottleneck links.

The primary use of unicast requests is for resolution
of PTR RRs.  For these queries we already know the IP address.
Setting TTL=1 ensures not only that these queries don't escape the local
link but also that queries for off-link addresses will fail more
quickly than setting TTL=255 and then waiting for a response from
anywhere on the Internet.  In practice, PTR RR queries will comprise
a signficant fraction of all LLMNR queries, so containing these
queries and "fast fail" is important.

This is distinct from what TTL is used in the response or whether the
sender checks TTL on the response.

For a TCP query, TTL=1 is set by the sender on the SYN.  The three
way handshake takes care of the rest, regardless of what TTL the
receiver sets on his response.  This works on SCTP as well.

Christian Huitema noted:

"Think of the ICMP "smurf" attack, only use LLMNR instead of ping."

LLMNR does not support wildcard queries, so that I don't believe that this
attack is possible against a properly functioning implementation.
A host should only respond to queries for names for which it is
authoritative.

In the case of a cluster, you might have quite a few hosts responding to a
query for the same name, but otherwise an LLMNR query will receive 0-1
responses.

However, if DNS DISCOVER opcode were to be implemented on top of LLMNR
such an attack would become possible, since that draft supports wildcard
queries. So setting TTL=255 on a unicast UDP response and then checking has
implications for the security of DNS DISCOVER opcode.

Ted Lemon noted:

"I think we're very close to a compromise here, if the authors are willing
to consider the proposed changes."

If you want to propose a change for this or any other purpose, please
submit an issue in the format described here:

http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

However, before doing that it might be helpful to be clear what the change
is trying to accomplish.  If the goal is to fix an issue with the LLMNR
protocol, that's one thing; if the goal is to converge with Rendezvous,
that is a much larger task that cannot be accomplished by a single change,
particularly since it isn't even clear that the  "compromise" being
discussed meets Apple's requirements.