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

From: Bernard Aboba <[email-masked]>
Date: Wed, 23 Apr 2003 11:23:08 -0700 (PDT)

Issue 33 is given below. The proposed resolution is as follows:

In Section 3, change:

"[4] A sender SHOULD only send LLMNR queries for PTR RRs
that represent addresses reachable on the link
over which LLMNR is used."

To:

"[4] A sender SHOULD send LLMNR queries for PTR RRs
via unicast over TCP, as specified in Section 2.3."
Note: Acceptance of the proposed resolution to Issue 33 is dependent on
acceptance of the proposed resolution to Issue 34 (to follow).

---------------------------------------------------------------------
Issue 33: PTR via Unicast
Submitter: Mika Liljeberg
Submitter email address: [email-masked]
Date first submitted: April 17, 2003
Reference:
<[email-masked]>
Document: LLMNR-16
Comment type: T
Priority: S
Section: 3
Rationale/Explanation of issue:

It occurs to me that it would be a whole lot simpler to do PTR
queries using unicast. The LLMNR resolver could use a TTL=1 when
sending the query. This way it would either get an immediate no-route
response from the local TCPIP stack, a direct response from the holder
of the address, or an ICMP time exceeded reply from the default router.
Either way, the resolver wouldn't have to do any checking on the
address. This approach has several benefits:

1) Immediate error response if there is no route for the address
2) Error response from default router if the address is off-link
3) LLMNR resolver does not need to do any checking on the address
4) Unicast is easier on the network

Note that conflict resolution for addresses is taken care by DAD, so
using unicast for PTR shouldn't make any difference there. Another
assumption is that the PTR query is already vulnerable to spoofing on
the local link, so, as long as we use TTL=1 for the query there should
be no perceivable additional risk.

--
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: [email-masked]
Date: Thu, 24 Apr 2003 11:28:18 +0900

>acceptance of the proposed resolution to Issue 34 (to follow).

	i don't think it necesary to require TCP here.

itojun

---

From: Mika Liljeberg <[email-masked]>
Date: 24 Apr 2003 19:54:17 +0300

> 	i don't think it necesary to require TCP here.

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.

	MikaL

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 24 Apr 2003 18:39:17 -0700

> devices equipped with a minimal protocol stack might only support UDP.

The goal is not to protect from connection hijacking on the local link.
Indeed, an attacker on a local link can use ARP poisoning, and all bets
are pretty much off.

The goal is to prevent off link attacks, and also DOS amplification
attacks.

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. 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.)

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.

Clearly, using TCP for direct queries has some cost. However, these
costs will mostly appear when a service insists on resolving PTR
records, which is clearly an "opt-in" function. And the cost does not
appear un-surmountable...

-- Christian Huitema