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: "Christian Huitema" <[email-masked]>
Date: Sat, 13 Mar 2004 12:02:40 -0800

Could we agree in any case that the TTL discussion does not apply when we use TCP? 

As far as I can tell, I would split the problem as follow:

1) Source address is an IPv6 local-link address: must use TTL=255, as per IPv6. No need for special code, this is done by the stack.

2) Operation over TCP: three-ways handshake prevents spoofing. Test of address ranges is sufficient to guarantee on-link status. Setting TTL=1 provides additional benefit.

3) Multicast query: multicast routing normally limits propagation of packet to the local link. On-link attackers can spoof the source address; off-link attackers generally cannot send multicast packets to the destination. Checking the TTL provides no protection against on-link attackers (they can set whatever TTL value is expected). Checking that the source address belongs to an "on-link" prefix prevents the "smurf attack to an off-link target". Setting the TTL=1 in multicast queries prevent the side effects of a rare bug in routers, but this bug may not be very frequent anyhow.

4) UDP unicast query: spoofing of the source address is very easy, including for off-link attackers. Checking TTL=255 protects against spoofing by off-link sources. Checking that the source address belongs to a local range also affords some protection.

5) UDP unicast response: spoofing of the response requires guessing the transaction identifier, which in practice requires an "on-link" attacker; TTL games do not protect against on-link attackers. Setting the TTL to 1 protects against unwitting participation in a DOS-attack to an off-link target, if the source address of the query was spoofed.

6) Setting the TTL to either 1 or 255 will create failures in some network topologies that support multicast but require packets to go through a router -- some wireless networks and some ad hoc networks can have that property.

In practice, checking TTL=255 is only useful in UDP unicast queries, where it provides a slight incremental benefit over a simple check of the source address prefix. Setting the TTL to 1 provides a limited benefit in TCP operation, multicast queries and unicast responses, but contradicts the requirement of TTL=255 for IPv6 link-local addresses. Setting to either value will create operational problems in some future scenarios.

The simplest solution is probably to remove all mentions of TTL checks from the LLMNR document, and simply state that:
1) Nodes should verify that the source address of queries belong to an authorized range;
2) The TTL field should be set by the stack to whatever default value is adequate for the interface and the source address (e.g., TTL=255 for IPv6 link-local addresses.)

-- Christian Huitema

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Mar 2004 17:17:11 -0800 (PST)

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

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

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 16 Mar 2004 21:54:41 -0800

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

> 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

---

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

Olafur & Olaf

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 13 Mar 2004 12:02:40 -0800

-- Christian Huitema

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Mar 2004 17:17:11 -0800 (PST)

This makes sense.

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 16 Mar 2004 21:54:41 -0800

-- Christian Huitema