Subject: LLMNR and Rendezvous TTL disagreement, a modest proposal

From: David Brower <[email-masked]>
Date: Thu, 12 Feb 2004 13:10:16 -0800

[ Moderators note: Post by non-subscriber.  With the massive amount of
   spam, it is easy to miss and therefore delete relevant posts 
   by non-subsrcibers. Please fix your subscription addresses. ]

Not being religious, and only being a party that wishes to use things
in this space to reduce configuration, interoperability between LLMNL
and Rendezvous is important in reaching stability and critical mass.

The first contentious issue seems to be the TTL field.  There seem to
be perfectly good arguments for each position, and I am not wise
enough to say either is correct.  Is it plausible to say "both are
right" on this point?  Have the standard say senders may set the field
to either 1 or 255, and recipients should accept either value?   Both
seem just as good at detecting leaked packets.

You may stone me now.

thanks,

David Brower
Oracle Cluster Architecture

--
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: Paul Vixie <[email-masked]>
Date: Mon, 16 Feb 2004 17:03:51 +0000

> [...] The reason we can't just do this is that the standard that was
> agreed upon requires that if you get a packet with a TTL that's not
> 255, you have to drop it.  This is the standard Rendezvous adopted,
> because the WG consensus at the time was that this was the right thing
> to do.  Subsequently the consensus of the WG changed, and the current
> consensus is incompatible with the old consensus.  [...]

I think there are two topics on which consensus would be valuable and
useful but which for the moment are impossible to gauge.  Above, Ted
makes reference to the old "1 vs 255" thing.  Others here have shown
that one choice assures correct behaviour by initiators, the other by
responders, and that either choice is useful, perhaps equally so.  At
this point we could flip a coin to decide, and the consensus would
surely be, "wow we sure are glad that some kind of decision got made."

The second point on which consensus is unclear is actually much more
important, and that's "should we allow Apple to legislate standards
using the force of their installed base?"  Apparently there's some
concern that Apple is acting like a bully here.  I've also heard of
suspicions that Microsoft's big reason for pushing LLMNR is to wipe
out Apple's early lead in this market.  What we (as IETF "members")
have to decide isn't "who should win this fight?" but rather "what's
the best engineering solution?"  In other words no arguments based on
the existence of an installed base, whether for or against, should be
taken into account.  If the best solution happens to be what Apple did
then we should write it that way.  If the best solution happens to be
what Apple didn't do then we should write it THAT way.

But wait, I have a proposal.  Given the following three facts...

    (1) 1 and 255 have about equal usefulness but protect different endpoints
    (2) apple only chose as they did because of apparent consensus "back then"
    (3) consensus since then seems to have drifted back into vagueness

...that we give Apple's solution the nod based simply on operational
experience with a solution that has already been randomly chosen.

--------

But there's still the larger question of "why LLMNR?"  If the WG isn't
going to advance LLMNR while it remains incompatible with Rendezvous,
then why doesn't the WG just advance Rendezvous?  Clearly, being early
isn't always an advantage.  But does it always have to be a disadvantage?

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 19 Feb 2004 18:24:56 -0800

> I support "MUST send with TTL=255, MAY reject if TTL<>255 on receipt",
> possibly with a paragraph emphasizing that routers SHOULD discard such
> packets if TTL<>255 (though this is perhaps broadening the ambit of
the
> document too far).

Which packets? Routers have no idea what application a packet belongs to
-- or in any case they are not supposed to care what application a
packet belongs to. LLMNR packets are indistinguishable from other
packets. Why should a router apply a different TTL treatment to them?

There is certainly a very strong case that multicast packets should be
sent with the shortest possible TTL, in order to minimize the risk of
flooding entire networks. Even for unicast packets, one can make the
point that using long TTL values allows for interesting hacks, e.g.
reflection DOS attacks against third parties.

The reflection DOS attack can only be prevented if the LLMNR nodes can
ensure that the addresses used in the communication are local in scope:
local scope multicast addresses, destination addresses that are on-link.
But if the LLMNR nodes can do that, then checking a TTL value of 255
does not bring any particular advantage.

If I understand correctly, rendezvous made the hypothesis that only
"link local" addresses would be used. LLMNR does not enforce that
restriction. Using TTL=1 is a logical consequence of allowing use with
regular IP addresses. 

-- Christian Huitema

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 20 Feb 2004 00:59:45 -0800

Christian Huitema wrote:

>flooding entire networks.

Exactly what is the "risk of flooding entire networks" here?

Just about every network printer bought by Microsoft or anyone else in 
the last year has Rendezvous in it, and sends multicast packets with TTL 
255 to the link-local address 224.0.0.251. If there were any actual case 
of a defective router incorrectly forwarding these link-local multicast 
packets and "flooding entire networks", don't you think someone would 
have noticed by now?

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 20 Feb 2004 10:12:23 -0800

>what's the point of the TTL==255 stuff (for multicast
>packets anyway) ?

The immediate value is primarily for unicast packets, and less so for 
multicast packets.

When Rendezvous sends a multicast query, and the peers on the local link 
respond with unicast responses back to the querier, then checking TTL=255 
on reception verifies that no off-net interloper has managed to slip a 
few remote unicast responses in with the legitimate local unicast 
responses.

The value for multicast packets is an indirect code hygiene benefit: 
suppose a router vendor were to make a future multicast router that 
incorrectly forwards 224.0.0/24 packets. This could expose hosts to 
off-net attack. By setting and checking TTL=255, hosts are protected from 
this vulnerability, and because of the resultant traffic forwarding, the 
problem is detected and the router is fixed before it even gets through 
QA testing. Suppose we used TTL=1 instead: Now the router bug might go 
unnoticed for months or years, until the product is deployed in millions 
of homes around the world, and then some hacker finds it and exploits it.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 21 Feb 2004 07:54:19 +0900

Stuart Cheshire;

> few remote unicast responses in with the legitimate local unicast 

It is unwise to use not DNS but Rendesvous, when LAN is connected
to the Internet.

> of homes around the world, and then some hacker finds it and exploits it.

Any protocol which relies LAN, which is connected to the Internet,
is secure is insecure.

Note that the LAN may be connected to other LAN with Ethernet
over IP.

Never bother to improve quality of illusion of security.

							Masataka Ohta

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 20 Feb 2004 09:04:09 -0800

Robert Elz has made a convincing argument why TTL=1 should be set on 
multicast packets.   It also makes sense to set TTL=1 on LLMNR packets sent 
via unicast TCP, since if this is done the TCP three way handshake will 
ensure that a connection will only be set up to a host on the same link.  If 
TTL=255 were set on the TCP SYN, then an LLMNR connection could be set up to 
any host on the Internet.  This doesn't make sense for linklocal name 
resolution.

Then there is the issue of what the TTL should be on UDP unicast packets.  
There are two cases here:  UDP unicast queries and UDP unicast responses.  
Unicast UDP queries will presumably be sent largely to resolve PTR RRs;  
this is not the recommended transport, but it can be used.  Therefore I 
would make the same argument as for TCP queries, namely that TTL=1.  There 
is no reason for a linklocal name resolution protocol to send queries all 
over the Internet.

So we are left with the question of the TTL for UDP unicast response 
packets. Here we could set TTL=255 and (optionally) check on reception as 
Robert proposes, or we could set TTL=1.  In thinking about the 
risks/benefits of this, it's important to keep in mind the risks of DoS 
attack.  In the existing LLMNR specification, there is no support for 
"wildcard" queries.  However, the DISCOVER Opcode specification, if run on 
top of LLMNR, would add this capability.

Once "wildcard" queries are supported, we now have the possibility of an 
attacker sending a wildcard query from a spoofed address, and causing the 
victim to be deluged with responses.  Even with TTL=1 on responses this 
attack exists, but can only be used to attack someone on the local network.  
With TTL=255 set on responses, it can be used to attack anyone on the 
Internet.

To my mind, this was the argument that tipped the balance in favor of 
setting TTL=1 on UDP responses.

Note that this deicision is not mandated by the IPv4 Linklocal TTL 
specification.  In Section 2.7 of that specification, it is stated:

   A sensible default for applications which are sending from a Link-
   Local IPv4 address is to explicitly set the IPv4 TTL to 1.  This is
   not appropriate in all cases as some applications may require that
   the IPv4 TTL be set to other values.

LLMNR responses can be sent from any source address, so this text does not 
apply in many situations.  Also,  the above text leaves the decision to the 
application.  So I think that this is purely an LLMNR decision.

_________________________________________________________________
Take off on a romantic weekend or a family adventure to these great U.S. 
locations. http://special.msn.com/local/hotdestinations.armx

---

From: "Burns, Mike" <[email-masked]>
Date: Tue, 24 Feb 2004 08:36:35 -0500

On Fri, 20 Feb 2004, Stuart Cheshire wrote:
>then checking TTL=255

If you check for TTL>1 then the interloper could only come from 1 hop
away, which in most cases is a router core network(ISP,Corp) with a limited
number
of hosts.

>This could expose hosts to
>this vulnerability

Neither setting will protect the host since it could be bombarded by a
DDOS.  Regardless of the TTL, the packet will still have to be processed
by the host.

>Suppose we used TTL=1 instead: Now the router bug might go
>of homes around the world

Check for TTL>1 if you insist. 

It seems much more likely that a large deployment of a virus could infect
a number of hosts then send LLMNR packets to flood a victim when the
TTL=255, than if the TTL=1.  If the TTL=1, then the packet would have to
be crafted, which is easily enough to do on a distributed basis, but is
not common (crafting of packets with a  virus).  Most virus creators are
lazy and use the existing OS functionalities.

Mike

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 24 Feb 2004 10:38:29 -0800

> The TTL=1 argument provides nothing at all that helps avoid DoS
> attacks - what the specification says should be done is irrelevant
> to an attacker, if they want to bombard you, and they're 10 hops
> away, they'll set the TTL to 11 (or more) regardless of what the
> spec says it should be set to.

The difference is with reflection attacks. A worm sends an LLMNR request
to the local network, spoofing the source address of a target. With
TTL=255, the response to the request can bomb any site on the Internet;
with TTL=1, the response will only travel one hop.

-- Christian Huitema

---

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Feb 2004 18:50:20 +0000

> with TTL=1, the response will only travel one hop.

once again we see that there are cogent arguments to be made for both
ttl settings, but that consensus proves elusive.  we can flipflop on
this for many years to come, or we can find a compromise (which means
"a solution which displeases everyone equally".)

---

From: Robert Elz <[email-masked]>
Date: Wed, 25 Feb 2004 04:07:26 +0700

Date:        Tue, 24 Feb 2004 10:38:29 -0800
    From:        "Christian Huitema" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The difference is with reflection attacks. A worm sends an LLMNR request
  | to the local network, spoofing the source address of a target. With
  | TTL=255, the response to the request can bomb any site on the Internet;
  | with TTL=1, the response will only travel one hop.

This works only if the request is one that many nodes on the local link
will answer.  If only one (or a small number) reply, then the bomb is
just 2 or 3 packets, which isn't much to be concerned about.

If there is some request that lots of nodes will answer, which would make
that an affective attack, then really what ought to be done is to fix things
so that there aren't lots of answers - that's useful just for local genuine
queries, which don't want a hundred answers either.   Even with TTL=1,
if there was an avenue for attack here, it would be a good way to neutralise
a system on a link - just get everyone else on the link to bomb it.   That
we don't want - so preventing the mass replies is the better solution.

kre

ps: Ted, Christian's scenario here involves unicast replies aimed at a victim,
this one isn't multicast.

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 24 Feb 2004 15:24:16 -0800

> > I beg to differ.   This is not a cogent argument, because the
bombing
> > scenario can't happen unless all the routers on the internet are
very
> > carefully broken.   Furthermore, it's an irrelevant argument,
because
> > we've (at least, some of us have) agreed that we don't need the
TTL=255
> > check for multicast anyway, and it's sufficient to have it just for
> > unicast.
> 
> Reflection attack is a possibility if the attacker sends a spoofed
query
> to a multicast group of higher than link-local scope or to a broadcast
> address.

Think of the ICMP "smurf" attack, only use LLMNR instead of ping.

-- Christian Huitema

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Feb 2004 11:37:00 -0800 (PST)

Robert Elz noted:

"While Bernard is right, that for TCP, a TTL of 1 would also work, I don't
think I really want that level of detail being checked, and would prefer
if simply all unicast was treated the same."

I'd argue that the distinction to make is between queries and responses,
not between unicast and multicast.  I believe that queries of any type
need to have TTL=1 (no check implied);  for responses, TTL=255 can be
considered, along with an (optional) check.

TTL=1 on queries is really about scaling and "fast fail", not
security.  Since LLMNR can be used to resolve *any* name where
the DNS  server does not respond or responds with RCODE=0 and no RRs
or RCODE=3, it was important to scaling to ensure that
LLMNR queries do not escape the local link. Otherwise,
LLMNR could add signficantly to DNS traffic on bottleneck links.

The primary use of unicast requests is for resolution
of PTR RRs.  For these queries we already know the IP address.
Setting TTL=1 ensures not only that these queries don't escape the local
link but also that queries for off-link addresses will fail more
quickly than setting TTL=255 and then waiting for a response from
anywhere on the Internet.  In practice, PTR RR queries will comprise
a signficant fraction of all LLMNR queries, so containing these
queries and "fast fail" is important.

This is distinct from what TTL is used in the response or whether the
sender checks TTL on the response.

For a TCP query, TTL=1 is set by the sender on the SYN.  The three
way handshake takes care of the rest, regardless of what TTL the
receiver sets on his response.  This works on SCTP as well.

Christian Huitema noted:

"Think of the ICMP "smurf" attack, only use LLMNR instead of ping."

LLMNR does not support wildcard queries, so that I don't believe that this
attack is possible against a properly functioning implementation.
A host should only respond to queries for names for which it is
authoritative.

In the case of a cluster, you might have quite a few hosts responding to a
query for the same name, but otherwise an LLMNR query will receive 0-1
responses.

However, if DNS DISCOVER opcode were to be implemented on top of LLMNR
such an attack would become possible, since that draft supports wildcard
queries. So setting TTL=255 on a unicast UDP response and then checking has
implications for the security of DNS DISCOVER opcode.

Ted Lemon noted:

"I think we're very close to a compromise here, if the authors are willing
to consider the proposed changes."

If you want to propose a change for this or any other purpose, please
submit an issue in the format described here:

http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

However, before doing that it might be helpful to be clear what the change
is trying to accomplish.  If the goal is to fix an issue with the LLMNR
protocol, that's one thing; if the goal is to converge with Rendezvous,
that is a much larger task that cannot be accomplished by a single change,
particularly since it isn't even clear that the  "compromise" being
discussed meets Apple's requirements.

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 26 Feb 2004 13:59:38 -0800

> On Thu, Feb 26, 2004 at 12:56:46AM -0800, Bernard Aboba wrote:
> > If there is to be a "compromise" I believe that it should be
> > to set TTL=255 on responses and (optionally) check on the sender,
while
> > *always* setting TTL=1 on queries.
> 
> Sounds reasonable to me.

I would qualify that by setting the TTL=255 only when the response is
sent to a link local address, either IPv6 link local or IPv4 169.254/16.

-- Christian Huitema

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 27 Feb 2004 08:04:59 +0900

Christian;

> sent to a link local address, either IPv6 link local or IPv4 169.254/16.

To stop packets flooding out, it should also be required
that a site administrator is sure that all the local routers
recognize link local addresses, which involves site dependent
configuration.

However, when all the local routers regognize link local
addresses, there are no reason (even invalid reasons as there
are no valid reasons from the beginning) to set TTL 255.

With TTL of 1, the configuration becomes unnecessary.

						Masataka Ohta