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

From: Derek Atkins <[email-masked]>
Date: Tue, 02 Mar 2004 00:24:45 -0500

Andras Salamon <[email-masked]> writes:

> On Thu, Feb 26, 2004 at 12:56:46AM -0800, Bernard Aboba wrote:
>> If there is to be a "compromise" I believe that it should be
>> to set TTL=255 on responses and (optionally) check on the sender, while
>> *always* setting TTL=1 on queries.
>
> Sounds reasonable to me.

But now you're open to smurf attacks, where I send a LLMNR request to
a responder, setting YOUR ip address as the source, and setting the
TTL to make sure the packet arrives "properly".  Or do we just not
care about this?

I can make sure you send the packet, and with TTL=255 the response
will always make it back to the "sender" (which is YOUR ip address in
this case).

So, what is the threat(s) we're trying to solve?  In particular, what
threat does TTL=255 on responses actually solve?

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

--
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: "Christian Huitema" <[email-masked]>
Date: Tue, 16 Mar 2004 21:54:41 -0800

> > Ok, although I would rather suggest:
> 
> > 1) Nodes should very that the source address of queries belong to an
> > authorized range;
> 
> I'm not sure how to define an "authorized range".  A host may not know
all
> the prefixes present on a given link.

In IPv6 at least, the host is suppose to learn the list of on-link
prefixes from the RA. But you are right, there are many ways to get this
test half-right and cause major operation pain. 

> > 2) Use TTL=1 with TCP.
> 
> This makes sense.
> 
> > 3) No TTL requirements for UDP requests and responses, but recommend
> > setting to 255 for compatibility with Rendezvous.
> 
> This only works if UDP unicast requests are prohibited. Otherwise,
LLMNR
> would send unicast PTR RR queries off the local link, which is not
> acceptable.
> 
> An alternative would be to have no TTL requirements for multicast UDP
> request and unicast UDP responses, but setting to 255 for
compatibility
> with Rendezvous.  But requiring either TTL=1 for UDP unicast queries
or
> get rid of unicast UDP queries entirely.

Getting rid of unicast UDP query would be by far the most robust
solution. Multicast routing pretty much guaranties that a multicast
request only travels one single hop; the TCP 3-ways handshake combined
with TTL=1 also guarantees an on-link peering. 

The residual risk is address spoofing by an on-link source, to enroll
the LLMNR responder in a reflection attack. But as long as we devise the
protocol so that only one node respond to a query, we have not created
an extra vulnerability. Regular DNS servers are just as easy to enroll
in a reflection attack...

-- Christian Huitema