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

From: "Christian Huitema" <[email-masked]>
Date: Tue, 24 Feb 2004 15:24:16 -0800

> > I beg to differ.   This is not a cogent argument, because the
bombing
> > scenario can't happen unless all the routers on the internet are
very
> > carefully broken.   Furthermore, it's an irrelevant argument,
because
> > we've (at least, some of us have) agreed that we don't need the
TTL=255
> > check for multicast anyway, and it's sufficient to have it just for
> > unicast.
> 
> Reflection attack is a possibility if the attacker sends a spoofed
query
> to a multicast group of higher than link-local scope or to a broadcast
> address.

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

-- 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: Ted Lemon <[email-masked]>
Date: Tue, 24 Feb 2004 19:09:31 -0500

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

Right, which argues for making sure that the recipient of an LLMNR 
packet that originated off-link never replies to it.   Of course, you 
can argue that the right fix is to make sure that the packet sent by 
the recipient never makes it off the link (this is the require TTL==1 
fix), but what if the attack is on a node that's *on* the link?   In 
either scenario, brokenness is bad; it's just differently bad.

The bottom line is that we have to trust that *somebody* is going to 
get their implementation right.   You can get a smurf attack with 
either kind of bad implementation.   So I think that arguing about 
smurf attacks and how they might happen, while important, is not 
relevant to the question of whether to use TTL=1 or TTL=255.

Just as a reminder here, the smurf attack uses nodes that are compliant 
with the relevant ICMP and IP RFCs.   Here, in order for the attack to 
work, nodes have to fail to comply with the RFC (assuming we ever get 
an RFC out of this process!).

---

From: Derek Atkins <[email-masked]>
Date: Tue, 24 Feb 2004 22:14:43 -0500

It sounds like you want two things here, but it also sounds like all
of them need to happen in the responder.  The attacker could
theoretically send packets of any type, with any TTL.  So you can't
trust anything you receive from the network.  To this affect, I think:

1) We want the responder to try to determine that a request came from
   the local network.  The best way to do this is for the responder to
   check that TTL=255 to make sure.  If a TTL is less than 255 then it
   originiated off-net and can be dropped.

2) We want the responder to make sure response packets don't go
   off-net.  In other words, we want the responder to respond with
   TTL=1, to make sure it can't smurf.

So, to this affect:

a) an LLMNR requestor should send requests with TTL=255
b) an LLMNR responder should verify requests have TTL=255 -- if it is not
   255 then it should drop the packet.
c) an LLMNR responder should respond with TTL=1
d) I dont' think an LLMNR requestor needs to check the response TTL.

The only issue this doesn't directly solve is a requester being
spoofed by an off-net attacker, but said attacker would need
to guess the transaction id of the request in order to send a
valid response, which is just as likely in LLMNR as it is in
standard DNS, so it can probably be ignored.

So, other than this issue, does this solve the issue?

-derek

Ted Lemon <[email-masked]> writes:

> Just as a reminder here, the smurf attack uses nodes that are
> compliant with the relevant ICMP and IP RFCs.   Here, in order for the
> attack to work, nodes have to fail to comply with the RFC (assuming we
> ever get an RFC out of this process!).
>
>
> --

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

---

From: Mika Liljeberg <[email-masked]>
Date: Wed, 25 Feb 2004 07:38:01 +0200

On Wed, 2004-02-25 at 02:09, Ted Lemon wrote:
> packet that originated off-link never replies to it. 

That would be ok but there's a practical problem. Many incarnations of
the socket API do not allow for checking the destination address of an
incoming packet, and you can't bind a socket to a multicast address.
OTOH, setting the TTL is simple and works on most systems.

	MikaL