Subject: Re: Proposed Resolution to LLMNR Issue 33: PTR via Unicast

From: [email-masked]
Date: Fri, 25 Apr 2003 11:05:29 +0900

>The goal is to prevent off link attacks, and also DOS amplification
>attacks.
(snip)
>Second, DoS amplification. The attack is to send a short UDP request to
>an intermediary, using a spoofed source address, and to have the
>intermediary respond to that target address with a long packet. This
>achieves two interesting goals: hiding the actual source of the attack,
>and amplifying the attack. This can be trivially mounted with a UDP PTR
>request.

	when i hear the word "DoS amplification", i assume that there
	are more than N packet produced in response to N malicious packets.
	is it common to call the above scenario (N larger packet generated by
	N malicious packet) "amplification"?  i don't think so.

itojun

--
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: Thu, 24 Apr 2003 20:11:44 -0700 (PDT)

> I agree. Connection hijacking on the local link is easy, so using TCP
> doesn't provide any additional protection. Besides, certain restricted
> devices equipped with a minimal protocol stack might only support UDP.

-17 essentially requires that either TCP or EDNS0 be implemented anyway,
so as to be to handle extended replies. The issue is whether *both*
mechanisms are required, or only one.

---

From: Mika Liljeberg <[email-masked]>
Date: 25 Apr 2003 08:47:08 +0300

On Fri, 2003-04-25 at 04:39, Christian Huitema wrote:
> First, off-link attacks. Off link attacks to a link-local multicast
> destination are very hard. Off link attack to a TCP destination are also
> very hard: if the SYN-ACK is sent with TTL 1, the attacker has to
> successfully guess the TCP sequence number, and that is not easy. Off
> link attack to an UDP unicast port with a spoofed IP source address are
> on the contrary much easier.

Even with UDP there is still the timing problem, which makes off-link
attacks very hard. However, I conceed they are possible.

> Sure, you get some protection via TTL
> checks, but TTL checks can be bypassed with various tunneling
> technologies, not to mention faulty routers. (The recent slammer worm
> propagated through an off link attack to a UDP listener.)

If you get access to the link, whether physically or via a tunnel or a
misconfigured router, all bets are off anyway.

Suppose we just require that the responder must always send the
responses to the link-local multicast address and that the resolver must
not accept unicast responses? That should take care of any off-link
LLMNR cache poisoning attacks using a spoofed source address.

> and amplifying the attack. This can be trivially mounted with a UDP PTR

As Itojun pointed out, one-for-one isn't really amplification. A TCP
server would send multiple SYN-ACKs for one SYN before giving up
(although with exponential backoff).

Also, the scope of the DoS attack is limited to other nodes on the same
link, since responses would have TTL=1. It doesn't look like a massive
DDoS is in the cards.

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 26 Apr 2003 14:56:43 +0300

Hi all,

> mechanisms are required, or only one.

The requirement in the draft is MAY and I think that is the correct
thing to say. There are implementations that only support address
queries and for those implementatons it is quite acceptable to only
support UDP, since they will practically never encounter responses that
don't fit into a UDP response packet.

I share the concern about the security issues so I did a little threat
analysis to make sense of the problem. The analysis is appended below,
in case anyone is interested. It's probably far from complete but feel
free to expand on it (I hope you can make sense of the notation). The
upshot of the analysis, however, is that using TCP for unicast would
indeed address some problems. However, as I would not like to mandate
TCP for PTR queries, I propose an alternative solution.

The critical thing is that a sender can easily verify that a particular
response is not spoofed by an off-link sender. If we have a simple way
to do that, we can use link-local addressing and TTL to make sure we
don't leak anything off-link. So, I propose the following simple rules
for ALL queries:

     1. Concatenate a random cookie to the canonical name. The cookie
        should be changed for every new query (but not retransmission).
        The sender must verify that the cookie is correctly echoed by
        the responder or discard the response (this is already done as
        part of normal response processing). Naturally, the responder
        must to disregard the cookie element while looking up the name
        database.
     2. Send all queries and responses with TTL=1 to prevent leakage.
     3. Don't amplify: respond to unicast queries with unicast
        responses.

Note that we could use the above rules only for unicast and the current
TTL=255 checks with multicast, but the proposed rules would work equally
well for both unicast and multicast queries.

The "when to use unicast" rules are fine as proposed in resolution 34.

What do you think, did I overlook something?

	MikaL

Threats and alternative solutions to each threat
================================================

THREAT A: sender should not accept any responses from off-link.
Alternative solutions:
        [1] check that the destination address of the response is
        link-local (multicast)
        [2] check that TTL=255 in response packets
        [8] use TCP unicast, send queries with TTL=1 to avoid asking
        off-link
        [9] concatenate a random cookie to the canonical name, send
        queries with TTL=1, verify cookie on receipt

THREAT B: A responder should not leak information to off-link attackers.
Alternative solutions:
        [3] check that the destination address of the query packet is
        link-local (multicast)
        [4] check that TTL=255 in query packets
        [5] send responses with TTL=1
        [6] send responses to link-local (multicast) address

THREAT C: Both sender and responder should guard against
reflection/amplification attacks. Solution:
        [7] don't amplify: don't respond to a single packet with many
        packets and don't respond to a unicast with multicast

Threat coverage analysis
========================

Link-local multicast query
  A: 1,2 (alternative with 5),!8,9
  B: 3,4,5 (alternative with 2),6
  C: 7
Outcome: All three threats countered, alternative solutions

UDP unicast query with TTL=1
  A: !1 (conflicts with 7),!2 (conflicts with 5),!8,9
  B: !3,!4,5,!6 (conflicts with 7)
  C: 7 => respond with unicast
Outcome: All three threats countered, solution=9,5,7

TCP unicast query with TTL=1
  A: 1,!2 (conflicts with 5),8,9
  B: !3,!4,5,!6
  C: 7
Outcome: All three threats countered, solution=8,5,7 or 9,5,7

NOTE: solution=9,5,7 works for all of the above