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

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Thu, 11 Mar 2004 10:34:09 -0500

The chairs are looking for closure and rough consensus on this only
remaining issue for LLMNR.
The solution below seems like a good solid compromise.
Is there any technical reason why this should not be adopted, please
state so before March 24'th.

         Olafur & Olaf

>Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal
>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?

--
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: Joshua Graessley <[email-masked]>
Date: Thu, 11 Mar 2004 10:52:56 -0800

I have an issue with this.

Using a TTL of 255 to verify that requests originate from the local 
link is not very important. It may be useful to use a unicast query to 
specific address from off of the local link to ask for records such as 
HINFO. In the case of multicast, unless something is seriously broken a 
link-local multicast packet is not going to be forwarded.

Setting the TTL to 1 also unnecessarily prohibits unicast 
request/responses from off of the local link. I would consider it more 
useful to verify that a response to a link-local multicast came from 
the local link.

To those who are concerned that setting the TTL to 255 on a response 
would enable another smurf attack, I would encourage them to try 
pinging the all hosts multicast address. Most hosts will respond to 
such a ping. This has not lead to any serious problems. The solution to 
the smurf attack was to drop the subnet broadcast packets in routers 
(don't forward them). A link local multicast packet will not be 
forwarded. The defense against the smurf style attack is already 
implemented. Hosts still respond to pings with subnet broadcasts but 
routers never forward such packets, so this is only a local 
vulnerability. If someone is local they could just as easily spoof the 
source address of their packets as any of the other devices on the 
local network.

If the whole point of changing the TTL is to achieve interoperability 
with Rendezvous, then the proposal below fails.

-josh

---

From: Derek Atkins <[email-masked]>
Date: Fri, 12 Mar 2004 16:56:27 -0500

Hi,

Joshua Graessley <[email-masked]> writes:

> HINFO. In the case of multicast, unless something is seriously broken
> a link-local multicast packet is not going to be forwarded.

It's exactly the fact that it's useful in a unicast query that we
should do it.  You are correct, multicast doesn't care, so we should
use the TTL value that gives us the most bang for the buck.  What does
it hurt us to use TTL=255 and verifying it?  In neither case does it
hurt us.  Yes, requests could leave the network, but the responder
would drop them (as it should -- it's not link-local!)

> useful to verify that a response to a link-local multicast came from

Indeed, this prohibition is EXACTLY WHAT WE WANT!  It's not
unnecessary.  It's a requirement!

> such a ping.

Just because a problem exists in another protocol and isn't majorly
exploited now does not mean that we should make the same mistake.
People HAVE used DNS as a smurf/explosion attack.

Pings aren't interesting -- the response is no larger than the
request.  DNS is VERY interesting, because I could potentially get a
LARGE response for a small request.

Therefore, we should protect against it.

>  This has not lead to any serious problems. The solution
> to the smurf attack was to drop the subnet broadcast packets in
> routers (don't forward them). A link local multicast packet will not
> be forwarded. The defense against the smurf style attack is already

This type of defence does not protect against unicast LLMNR requests.
Sure, a properly configured multicast router can stop the multicase
requests, but it wont stop the unicast packets.  That's yet another
reason we should use TTL=1 on responses, to make sure unicast messages
can't smurf.

> with Rendezvous, then the proposal below fails.

No, the whole point of this proposal is to get us out of the deadlock
that we've been in by showing how we can use TTLs to get the most bang
for the buck.  I've listed all the threats that I think we're worried
about and I've shown how the largest set of threats can be mitigated
by the combined 255/1 TTL.

If we can get Apple to move along with us and interoperate, great.
But this proposal is not "let's make this look like Rendevous".

> -josh

So, Olaf and Olafur, I obviously have no technical reason why this
should not be adopted ;)

-derek

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

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Mar 2004 09:35:59 +0900

>>    the local network.

No, we don't.

						Masataka Ohta