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

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

--
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: Mika Liljeberg <[email-masked]>
Date: Sun, 14 Mar 2004 00:29:16 +0200

Christian,

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

This is untrue. IPv6 does not require nor enforce hop limit 255 for
link-local addresses. Only ICMPv6 neighbor discovery packets use hop
limit 255. This is not a constraint for LLMNR.

> The simplest solution is probably to remove all mentions of TTL checks
> from the LLMNR document, and simply state that:

This seems useful.

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

Ok, although I would rather suggest:

2) Use TTL=1 with TCP.

3) No TTL requirements for UDP requests and responses, but recommend
setting to 255 for compatibility with Rendezvous.

	MikaL

---

From: Paul Vixie <[email-masked]>
Date: Sun, 14 Mar 2004 00:22:10 +0000

> setting to 255 for compatibility with Rendezvous.

"i'll by THAT for a dollar."

---

From: Joshua Graessley <[email-masked]>
Date: Mon, 15 Mar 2004 10:30:45 -0800

Works for me.

-josh