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

From: Robert Elz <[email-masked]>
Date: Wed, 25 Feb 2004 00:28:36 +0700

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

  | If you check for TTL>1 then the interloper could only come from 1 hop
  | away,

This is nonsense.   If one wants to check whether the sender is local,
at the receiver, the only thing that works is to set TTL=255, and check
that the TTL is still 255 when the packet arrives.   Checking that the
arriving TTL is 1 is an absolute waste of time.

If you don't understand this, you most likely shouldn't be participating
in this debate, as you're just confusing the issue.

  | Neither setting will protect the host since it could be bombarded by a
  | DDOS.

Anyone can bombard the host with any packets at all.   Neither LLMNR 
nor Rendezvous has anything whatever to do with that.   Worrying about
that happening is absurd (by which I mean, only worry about things that
you can control, the uncontrollable will either happen, or not, whatever
we do - or worry about).

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.

Using TTL of 1 (for multicast packets) is to avoid the legitimate traffic,
packets that are supposed to be there, from possibly escaping and
being sent further than they should (a quite remote possibility, but
one which would be bad if it happened).

For unicast packets, being able to verify that the host is on link just
may have some (small) benefit, stopping packets accidentally escaping has
essentially none, so TTL of 255 there makes (some) sense.

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.   Eg: if instead of TCP, it
is T/TCP (which avoids the 3 way handshake, often) does the argument
still hold?   What would we do if SCTP or HIP was ever being used?   This
is all just too much to worry about - the unicast vs multicast is a
simple distinction, leave it at that.

kre

--
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: "Eric A. Hall" <[email-masked]>
Date: Tue, 24 Feb 2004 12:18:36 -0600

> simple distinction, leave it at that.

Is such a distinction even necessary, really? Is the actual threat harmful
enough to impose even this cost on the nodes? I mean, if we think the
threat is so small that we don't feel compelled to make the TTL check
mandatory, then why are we even worrying about it? All messages MUST have
TTL=1 gets the same 99.9999% protection at less cost.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Andras Salamon <[email-masked]>
Date: Wed, 25 Feb 2004 13:42:00 +0200

> one which would be bad if it happened).

There is nothing inherently special about LLMNR as a multicast protocol,
so if we are going to worry about LLMNR we also have to worry about each
multicast protocol.  Using this argument, _any_ multicast protocol will
have to worry about the TTL to ensure multicast packets do not propagate
further than "expected".  This level of layer interdependency is clearly
not appropriate, and I don't think this working group can mandate changes
to every multicast protocol, past, present or future.

The real issue here is that LLMNR is meant to have local scope, and we
are trying to implement a "local scope" constraint using a TTL hack.
As Masataka Ohta and others have pointed out, on a network that is
connected to another potentially hostile network (ie. the Internet),
TTLs can be made to take on any values that suit a remote attacker,
and therefore cannot reliably be linked with the packet being local.
The TTL hack simply doesn't work to 100% guarantee "local scope", no
matter how much we try to make it so.  It usually works fine, but not
in the presence of hostile intent.

Personally, I don't see a way to 100% reliably implement a "local scope"
constraint in a higher layer protocol, without mucking around in the
lower layer protocols.  I think we need to pick an approach, document
the failure scenarios, possibly make some recommendations for filtering
packets at border routers, and move on.

Summarising the previous discussion:

First consider the case of hostile intent.  If all routers are configured
to drop LLMNR packets, then the protocol is only vulnerable to local
injection by an attacker, and the TTL value is then irrelevant.  However,
if routers are not configured to drop LLMNR packets, then the TTL=255
case is more robust since it only fails in the case of local injection
(in other cases the local server will not respond to the bogus request).
In the TTL=1 case a hostile remote attacker could still elicit a response
by the local server, by just setting the TTL to successive values of 1, 2,
..., n, where n is the diameter of the Internet (currently around 35-40).

Now consider the case of non-hostile packets slipping out by mistake,
due to broken routers mishandling the multicast address.  If all routers
are configured to block LLMNR packets, then the TTL value used is again
irrelevant.  If routers do not block LLMNR packets, then the TTL=1 case
is more robust.

Personally, I would rather see resistance to remote attack inherent in
the protocol, than trying to ensure broken routers do not cause havoc.
If we want to protect against routers incorrectly treating local
multicast addresses then we may as well start campaigning for every
multicast protocol to include TTL "protection" against such a "threat".
Why single out LLMNR?

There is already operational experience with the TTL=255 approach,
and it reduces the security threat to the case where an attacker can
actually inject packets onto the local network.  We should just adopt
this approach and move on.

-- Andras Salamon                   [email-masked]

---

From: John Schnizlein <[email-masked]>
Date: Wed, 25 Feb 2004 16:11:29 -0500

At 06:42 AM 2/25/2004, Andras Salamon wrote:
>...

This is an important point that sometimes gets lost in the deeper analysis.

There are very many installed routers that know nothing about LLMNR, or
link-local IPv4 addresses for that matter. While these routers can be
assumed to decrement TTL and drop to prevent looping traffic, it is not
reasonable to demand that the introduction of new protocol features on
hosts cause all the installed routers to be re-configured.

John

---

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

Date:        Wed, 25 Feb 2004 13:42:00 +0200
    From:        Andras Salamon <[email-masked]>
    Message-ID:  <[email-masked]>

  | There is nothing inherently special about LLMNR as a multicast protocol,

No, there isn't.   They're all different, and each has to make sure it
has the proper mechanisms to sale properly.

  | so if we are going to worry about LLMNR we also have to worry about each
  | multicast protocol.

That doesn't follow at all - each multicast protocol has to worry about
itself.   Including LLMR.

  | Using this argument, _any_ multicast protocol will
  | have to worry about the TTL to ensure multicast packets do not propagate
  | further than "expected".

No, each multicast protocol has to make sure that it's properties allow
it to be rationally deployed on the internet.   How they do that is up
to each protocol to determine.

  | As Masataka Ohta and others have pointed out, on a network that is
  | connected to another potentially hostile network (ie. the Internet),
  | TTLs can be made to take on any values that suit a remote attacker,

We cannot depend upon any unverifiable TTL setting for security
purposed (using the TTL for any kind of security is very weak), but
we can specify what conforming applications should set it to.

When we're concerned about scaling, rather than security, we can
assume that the vast majority of the nodes  that matter are obeying
the specification, we don't need to imagine a million compromised
nodes all trying to defeat us.

  | and therefore cannot reliably be linked with the packet being local.

The 225 case can, as if the packet has been through a router, the TTL
won't be 255 any longer, regardless of what the sender set it to.

  | The TTL hack simply doesn't work to 100% guarantee "local scope", no
  | matter how much we try to make it so.  It usually works fine, but not
  | in the presence of hostile intent.

This depends upon what we're trying to achieve.   The intent of the TTL=1
isn't to prevent anyone else from doing something to us, it is to prevent
our own packets from doing harm to others - and there we can rely upon
the TTL being set correctly, as we're doing it ourselves.

  | Personally, I don't see a way to 100% reliably implement a "local scope"
  | constraint in a higher layer protocol, without mucking around in the
  | lower layer protocols.

Of course, the scope needs to actually be implemented at the network
layer, which is why it is done using network addresses, or the TTL,
both of which are network layer concepts.

  | Summarising the previous discussion:

You're only considering the security implications, which are important,
but which are only a part of what needs to be considered.  That seems
to be a lot of the problem we have here - most participants are looking
at just one issue, and seeing how they can handle that one, and ignoring
everything else.

  | First consider the case of hostile intent.  If all routers are configured
  | to drop LLMNR packets,

That's never going to happen in general.   Multicast packets perhaps,
but not unicast.   They're just random UDP (or perhaps TCP) packets.

  | In the TTL=1 case a hostile remote attacker could still elicit a response
  | by the local server, by just setting the TTL to successive values of 1, 2,
  | ..., n, where n is the diameter of the Internet (currently around 35-40).

Yes, absolutely, though there's no need to do that expanding search, as
no-one is going to check that the arriving TTL is 1, that's an utter waste
of time - so simply sending a packet with a "bit enough" TTL would do.
However, all this happens is cause the server to send a response, if all
the TTLs were 1, then the response wouldn't get very far, would it?

  | Personally, I would rather see resistance to remote attack inherent in
  | the protocol,

Which particular remote attack?   The one you're concerned about isn't
the same one Stuart is concerned with (he's concerned with bogus replies
being injected - ie: one assumes (infers) that a query is being sent, and
generates a reply to the assumed query).

And you also need to look and see what the overall damage might be,
and what other ways there are to mount a similar attach (no point doing
anything to prevent an attack that it is trivial to succeed at using
a different mechanism).

  | There is already operational experience with the TTL=255 approach,
  | and it reduces the security threat to the case where an attacker can
  | actually inject packets onto the local network.

Actually, no, it doesn't - if the attacker can inject packets into the
local net, then TTL=1 is better, as there at least replies (and queries)
go nowhere.   TTL=255 provides some protection from attackers who cannot
inject packets into the local net, but who are able to determine enough
about local activities to know when and how to generate a plausible fake
reply.   This is actually a very hard thing to do (knowing when a query
might be made isn't too hard in some cases - the attacker can cause that,
knowing enough about the query (its source port, ID, ...) to generate
a reply that will be accepted, without being able to observe the query
isn't nearly so easy.

kre

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Feb 2004 18:34:43 -0500

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

> hosts cause all the installed routers to be re-configured.

AFAIK the whole reason for this discussion is that we are trying to 
come up with a protocol that will work and not create packet storms in 
the absence of any modified routers.   :')