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

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

Christian Huitema wrote:

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

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

--
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: Robert Elz <[email-masked]>
Date: Fri, 20 Feb 2004 19:49:08 +0700

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

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

One of two things is being observed there - first, that the vast majority of
routers installed don't forward multicast packets at all, currently anyway,
so noticing that they're not forwarding particular multicast packets isn't
providing much in the way of useful information.

Second, assuming that none of the routers that do have multicast turned on
is forwarding those packets (and that "not noticed by now" isn't just
that there isn't yet enough of it for anyone to care), is telling us
that routers handle link local multicast correctly, and don't forward
link local multicast off the origin link.

In fact, using TTL==255 is relying on routers doing that correctly, if
there are routers with bugs that allow link local multicast to be forwarded,
then Christian's "flooding the entire network" would be exactly what would
happen, wouldn't it?

So, let's assume that routers are correctly not forwarding link local
multicast.

In that case, what's the point of the TTL==255 stuff (for multicast
packets anyway) ?

The only rationale for using TTL 255, is to allow hosts to validate that
the packets haven't been forwarded by a router.   If the TTL arrives with
a value of 255 we assume no router touched it (because TTL decrementing is
something that experience has taught us that routers actually do correctly).

But this is obviously unnecessary - we've already assumed that routers
block link local multicast packets - if the routers are blocking (not
forwarding) link local multicast packets, and we can assume that is
correctly functioning, then there's no point at all in the host doing any
kind of TTL==255 check, that is just a waste of time - and if the hosts
aren't going to check it, there's also no point in sending TTL==255.

Of course, there was that assumption, that routers are in fact going to
block link local multicast.   What happens if that proves to be incorrect?

Well, in that case not doing the TTL==255 check at the recipient allows off
net sourced packets to be received and processed, but now we have packets
flooding the net.

Which is those is the greater harm if not prevented?

IMNSHO, the packet flooding is the greater harm, and it is that which
needs to be prevented (at almost any cost).   I'm not sure I see any
enormous harm in LLMR packets being received from off link (certainly
nothing worse than lots of other spoofed packets that might be received).

So, once again, I'd require that all intended-to-be-link-local multicast
packets be sent with a TTL of 1 - it just means that if there do happen
to be any defective routers, which don't know what is special about
224.0.0.*/24 and forward the packets, then the TTL->0 when it is
decremented will prevent forwarding.  If there are no such defective routers
the TTL==255 thing is a waste of time anyway.

On the other hand, for unicast packets, wherever they are used in LLMR,
the "flooding" argument is meaingless, and (aside from when they happen
to be to or from an LL address) won't be being blocked by routers.   They
also do no real harm to the net when forwarded (even if they end up nowhere).
There if there's any gain to be had from detecting off link sourced
packets, I see no reason to lose it.   So, sending any unicast packets
with a TTL of 255 (and validating that they arrive with the TTL still
being 255, if the host cares) seems reasonable to me.

kre

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Feb 2004 12:41:55 -0500

Personally, I find it amazing when people build huge pyramids of logic 
on top of premises like "we can't depend on the routers to be correct."

It's true that we can't depend on routers to be correct - don't get me 
wrong.   But when routers are not correct, the solution is to fix the 
router, or throw it out, not to demand that all network protocols 
account for every possible way that a router can be broken.

So what's the scenario where the router would do the wrong thing in 
this case?   How likely is it that an implementation mistake would 
result in the wrong thing happening?   Because I've thought about this, 
and to me it looks like you'd have to do a proactively bad 
implementation to get the behavior you're talking about - it wouldn't 
be enough to just forget to check something.   Furthermore, in order 
for the doomsday scenario Christian described to come to pass, *every 
router on the internet* would have to be broken *in the same way*.

Am I wrong here?   Can you or Christian explain why it's so likely that 
this scenario could come to pass?

Thanks!

---

From: Robert Elz <[email-masked]>
Date: Sat, 21 Feb 2004 03:06:21 +0700

Date:        Fri, 20 Feb 2004 12:41:55 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | Personally, I find it amazing when people build huge pyramids of logic 
  | on top of premises like "we can't depend on the routers to be correct."

No, you missed the point - which was (and Stuart's reply that just
followed yours confirms it) that for multicast, the TTL==255 check
is meaningful only if you assume that the router bug exists.   If
there would be no such bug, the test is totally meaningless.

  | It's true that we can't depend on routers to be correct - don't get me 
  | wrong.   But when routers are not correct, the solution is to fix the 
  | router, or throw it out, not to demand that all network protocols 
  | account for every possible way that a router can be broken.

Partly true - but we must also make the protocols resilient to plausible
failure modes.   After all, that's why we have the TTL in packets in the
first place - if we could rely upon either correct routers, or the "fix
whatever is broken" approach, we wouldn't need the TTL, as packets would
always go to their destination, or be dropped, they'd never loop.
But we simply aren't prepared to make either of those assumptions, the
net has to keep working, even when parts of it are malfunctioning.

  | So what's the scenario where the router would do the wrong thing in 
  | this case?   How likely is it that an implementation mistake would 
  | result in the wrong thing happening?   Because I've thought about this, 
  | and to me it looks like you'd have to do a proactively bad 
  | implementation to get the behavior you're talking about - it wouldn't 
  | be enough to just forget to check something.

All that's needed is for the definition of what is a LL multicast to
be entered incorrectly (say 224.0.0/25 instead of /24 - most simple
tests wouldn't notice the problem, but the 224.0.0.251 addr would sure
fall through it)

  | Furthermore, in order 
  | for the doomsday scenario Christian described to come to pass, *every 
  | router on the internet* would have to be broken *in the same way*.

Is that really so hard to imagine?   Can't you imagine a scenario where
almost all of the internet is run using one vendor's routers, built out
of one vendor's common code base?

It isn't everything that has to be broken, just enough to cause lots
of trouble.

  | Am I wrong here?   Can you or Christian explain why it's so likely that 
  | this scenario could come to pass?

I don't think it is likely at all.   But if the routers aren't going to
be broken this way, and I don't think they are likely to be, then there's
no point at all doing the TTL==255 check for multicast, as any packet that
would fail it, will have already been dropped by the router.

Stuart Cheshire <[email-masked]> said:

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

This is looking promising, as I think just about all of the arguments for
TTL=1 rather than TTL=255 come from the multicast arguments.   If we can
get the "less so" down to "irrelevant for", then perhaps we have a compromise
in the offing.

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

Fine, I have no problem with this (though the problem that is being solved
still exists in the DNS without DNSSEC - once DNSSEC is done, a DNSSEC type
approach to LLMR is likely to be a better, and much safer, way to solve this
problem).

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

Yes, but it would also cause the multicast queries (with TTL==255,
and any other multicast replies) to get sent to places where they're
not supposed to go.   That would be a much more serious problem.  And
even if the TTL checks happen to protect LLMR (or Rendezvous) they're
not going to protect other users of LL multicast addresses.

That is, this would be a serious problem, and as Ted said, one that
warrants getting the router fixed (we still need the network working while
that is happening - but we can tolerate some security risk, after all,
we can always filter out the packets that we don't want to receive).

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

If someone is doing QA testing of this kind of thing in the router at all,
I don't think they're going to be relying on LLMR/Rendezvous reporting
that it is dropping packets because their TTL isn't 255....

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

If there is a vulnerability here that is so important, that we need this
kind of mechanism to protect against this unlikely scenario, then the whole
thing badly needs a re-think.

If getting a packet through a router is all it takes to wreak havoc on
a host or net (which this is suggesting), then there are lots of other
methods, rather than imagining a broken router that happens to allow
forwarding of LL multicast (and as Ted indicated, you'd actually need a
whole chain of such things, between the hacker and the victim) and yet
correctly decrements the TTL.

Much more likely would be for the hacker to get a virus onto some system
on the local net (we all know how easy that is to accomplish), where the
virus sets up a tunnel end point which simply decapsulates packets and
forwards them (any and all packets, with no TTL adjustments).

This is far more likely to happen than the broken router scenario, and
in this setup, the TTL==255 check is of no benefit whatever - the packets
can have a 255 TTL if that is what is needed to get them accepted.

If we now have a problem that makes LLMR too insecure to use, then
we need to abandon LLMR (as it is now anyway), and think of something
different - or at least some other fix that isn't depending upon anything
so crude as the value of a field in the IP header.

If this doesn't make LLMR unacceptable to one and all, then clearly the
TTL test isn't achieving anything, and may as well be dropped (for
multicast packets) - it is irrelevant.

Once the check is dropped, then the multicast packets can be sent with
TTL=1 and everyone will feel just that little bit happier about that
very unlikely (but horrible should it occur) possibility of broken routers
incorrectly forwarding the packets.

kre

---

From: Ted Lemon <[email-masked]>
Date: Sat, 21 Feb 2004 00:30:02 -0500

> get the "less so" down to "irrelevant for", then perhaps we have a 

Okay, I'm happy.   I don't really care about the multicast argument as 
long as it doesn't prevent forward progress.