Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1

From: Stuart Cheshire <[email-masked]>
Date: Tue, 4 Mar 2003 14:15:11 -0800

Robert Elz wrote:

>There is evidence out there (apparently) that everything works OK
>using 128

>I can't think of a reason that 64, or 32, or 16, or 192 would be any
>different

Precisely. TTL values from 1 to 254 all work pretty much about the same.

The one exception is TTL=255, which allows the receiver to be pretty sure 
that the packet did in fact originate on-link.

Given that we have 254 possible values that work about the same, and one 
other value that is just as good and also gives marginal additional 
functionality, I go with the additional functionality.

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

---

From: John Schnizlein <[email-masked]>
Date: Tue, 04 Mar 2003 17:34:15 -0500

>Precisely. TTL values from 1 to 254 all work pretty much about the same.

The same in principle, but only one of these causes an ordinary Internet router to drop packets that attempt to get beyond the link of origin.

>functionality, I go with the additional functionality.

Your claim that the particular value of TTL=1 that would actually enforce the goal of keeping link-local traffic from being forwarded beyond the link is "about the same" as all the values from 2 through 254 is disingenuous. Your previous fair treatment of opinions that differ from your own leads me to expect a more direct argument from you.

John

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 04 Mar 2003 17:57:18 -0500

On 03/04/2003 17:34, "John Schnizlein" <[email-masked]> wrote:

> Your claim that the particular value of TTL=1 that would actually enforce the
> goal of keeping link-local traffic from being forwarded beyond the link is
> "about the same" as all the values from 2 through 254 is disingenuous. Your
> previous fair treatment of opinions that differ from your own leads me to
> expect a more direct argument from you.

How can you ensure that a packet with a TTL of one originated on the local
link?

john

-- 
John C. Welch
Consultant III
Office Computing Practice (IS)
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Mar 2003 01:13:37 +0200

> How can you ensure that a packet with a TTL of one originated on the local

A LL destination address in a packet is already a pretty good indication
of local origin. TTL=255 check gives us nothing new.

	MikaL

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 04 Mar 2003 18:46:05 -0500

> of local origin. TTL=255 check gives us nothing new.

No, it's an indication that it originated in a subnet with that address.
Nothing more. A TTL of 255 indicates that the packed hasn't been through a
router yet. Nothing more.

Both together give you a VERY high probability of local origin.

john

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Mar 2003 01:55:44 +0200

> No, it's an indication that it originated in a subnet with that address.

No it doesn't. It just indicates that someone tried to use LL as a
destination address.

My point is that you won't have much luck trying to get a packet like
that routed where you want it. We *are* talking about attacks, right? 

[If we were only talking about leakage, TTL=1 would clearly be more
effective.]

	MikaL

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 04 Mar 2003 19:04:56 -0500

> that routed where you want it. We *are* talking about attacks, right?

If I'm running an attack, then I'm not going to be able to *guarantee* the
ending TTL. But I'll have *far* better luck with 1 than with 255.

john

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Mar 2003 02:09:47 +0200

> ending TTL. But I'll have *far* better luck with 1 than with 255.

So here's a challenge for you: whip out your hacker toolbox and send me
a packet that has a LL destination address. I guarantee you I'll never
see it, much less get to check its TTL.

	MikaL

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 04 Mar 2003 19:13:48 -0500

> see it, much less get to check its TTL.

Um...so there's this thing called "nat"....

john

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Mar 2003 02:21:07 +0200

> Um...so there's this thing called "nat"....

I'm all ears. How would that work exactly?

	MikaL

---

From: John Schnizlein <[email-masked]>
Date: Tue, 04 Mar 2003 19:20:38 -0500

>ending TTL. But I'll have *far* better luck with 1 than with 255.

There was a long thread about supposed security benefits of checking
TTL=255, with the conclusion that no security claims were valid enough
to continue that thread. Since this WG has accepted the position that 
there is no particular security value to link-local traffic, and there
are so many different attacks available on an un-configured subnet,
assuming that an attack would employ TTL tricks is dubious.

John

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Mar 2003 19:18:19 -0600

> Um...so there's this thing called "nat"....

I've seen you complain when others responded like this.   Mika has a 
point.   How can an attacker get a packet with an IP destination 
address that's an IPv4ll address arrange for a series of routers to 
convey that packet to your network?   Is it even *remotely* possible 
that this could be done?   Can you describe a network configuration 
where this would be possible?

I think we are arguing about how many needles can dance on the head of 
a pin - I don't see any way for an actual packet addressed to an IPv4ll 
destination to stray significantly from where it belongs, and I 
definitely don't see a way to direct such a packet to a particular 
destination.

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 04 Mar 2003 22:56:48 -0500

> assuming that an attack would employ TTL tricks is dubious.

So is saying that TTL =  1 prevents leakage any more than 255...one prevents
leakage out, the other prevents leakage in. zeroes out nicely to me.

john

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 04 Mar 2003 23:02:38 -0500

> where this would be possible?

Um..I work in an environment that is very well defined and well known, down
to the number of routers. And I never complain about NAT, that's someone
else. The point was, there is a way to hide your true IP address from
external routers. If you know your network well enough, you can spoof
anything. My point is, I don't see any more real advantage to TTL =1 over
255. I can see a *disadvantage* in that out of the two leading users of LL
*now*, neither uses 255. Since we all agree that a properly configured
router will never pass a LL address *anyway*, leakage isn't a problem. It's
a double check really, more because what you *could* have is a router that
happens to be talking to two separate LL networks. That's the case where
weirdness may happen.

And I really don't think that the Internet needs 'protecting' nearly as much
as some. It's a pretty flexible thing. Some specific points may be more
fragile than others, but let's not get into the mental image of 'saving the
Internet'. It constrains your thinking.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Mar 2003 00:21:55 -0600

>> I've seen you complain when others responded like this.
> else.

Sorry, I mean complain about hypothetical failure scenarios with no 
actual documented scenario to back up the complaint.

> If you know your network well enough, you can spoof
> anything.

No, you can't spoof anything.   If you know your network well, you may 
be able to do some significant subset of all spoofs that are possible 
on your network, but that's a much more restricted set of spoofs than 
"anything."

> I can see a *disadvantage* in that out of the two leading users of LL
> *now*, neither uses 255.

I think Stuart was saying that Apple does use 255.   But Microsoft does 
not.   The debate here is over whether to codify Apple's change to the 
protocol.

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 5 Mar 2003 11:14:31 -0000

> From: "Mika Liljeberg" <[email-masked]>

So here is a scenario:

  Link A             Link B
+--------+Gateway-A+--------+Gateway-B+--> to the Internet

Gateway-A is the default gateway (for global traffic) on link A
Gateway-B ditto for Link B

If these gateways are not LL aware they will simply forward LL packets which
reach them on towards the Internet.

This scenario must be quite common.

Now suppose that Link A and Link B have LL hosts on them.

The only additional requirement for a malicious host on Link A to send a
packet to a LL destination on Link B is that either Gateway-A or Gateway-B
has been configured with a route which directs the LL prefix onto Link B.

While this might be regarded as a misconfiguration, it is not a huge one and
would likely go unnoticed. For example one or other gateway might be a
general purpose machine which a user has added a route to precicely so that
they can participate in LL exchanges on Link B.

Furthermore additional Gateways and networks can be interposed between Link
A and Link B without changing the basic principle but making the attack more
remote.

Philip

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Mar 2003 13:42:33 +0200

> This scenario must be quite common.

Granted. I could use that same scenario to argue for TTL=1. :)

> they can participate in LL exchanges on Link B.

Well, it *is* misconfiguration. I don't deny that this could happen but
I don't think it very likely.

Nodes on Link B should not rely on LL addresses having any security
properties any more than they rely on routable addresses. LL addresses
don't have, and don't need, any special magic.

> A and Link B without changing the basic principle but making the attack more

And also more unlikely. I sincerily doubt my ISP or their carriers would
be using LL addresses on their backbone networks, much less misconfigure
their routers the way you suggest.

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 Mar 2003 18:58:42 +0700

Date:        Wed, 5 Mar 2003 11:14:31 -0000
    From:        "Philip Nye" <[email-masked]>
    Message-ID:  <01fb01c2e308$653b3de0$131010ac@aldebaran>

  | The only additional requirement for a malicious host on Link A to send a
  | packet to a LL destination on Link B is that either Gateway-A or Gateway-B
  | has been configured with a route which directs the LL prefix onto Link B.

Yes, in appropriate circumstances, a malicious host would be able to
send a packet like that.   Requiring TTL=1 won't help in the slightest,
the malicious host will just ignore that requirement (even send with TTL=2
perhaps, so the recipient loots to have received a packet with TTL=1).

Requiring TTL=255 allows it to be detected.   That's fine.   It also means
that the target won't be able to interoperate at LL level with the majority
of (current) LL hosts that exist.

  | Furthermore additional Gateways and networks can be interposed between Link
  | A and Link B without changing the basic principle but making the attack more
  | remote.

What attack?   All you have so far is packets from a bogus source
address arriving at a host.   That the source address, or the address
of the target host, might be LL is irrelevant surely?

If sending packets to a host is to start to be considered as an attack,
then we're all doomed.   Even if the source address is something to
which no reply can successfully be sent.

If you're one of the (very few) people (I hope) who believes that a
host ought to be able to be "protected" by having only a LL address,
then please forget it - that kind of protection is useless.  If a
host cannot protect itself (or will not) the only hope it has is to
have a (string enough) firewall between it and all possible attack
sources (including hosts on its own link - which can mean putting it
on a link of its own sometimes).   Relying upon some mystical properties
of addresses to protect a host is folly, and we should not be doing
anything that even hints this can possibly work.

kre

---

From: Thomas Narten <[email-masked]>
Date: Wed, 05 Mar 2003 07:24:15 -0500

> If these gateways are not LL aware they will simply forward LL
> packets which reach them on towards the Internet.

Agreed. Packets sent to a LL destination could get sucked up by the
default route (of such packets were sent to the router).

> This scenario must be quite common.

Sure.

> has been configured with a route which directs the LL prefix onto

This is clearly a broken configuration and will result in LL in
general not working. I.e., two nodes, both on Link A, both using LL
addresses, won't be able to communicate. The Router will grab their
traffic and forward it to the wrong place.  Right?

> would likely go unnoticed.

Even though normal LL communication also doesn't work?

Or are you assuming nodes A & B will send directly to each other
because they understand LL? Well, if so, how is the router
intercepting traffic between them and forwarding it to the wrongb
place?

> For example one or other gateway might be a general purpose machine
> which a user has added a route to precicely so that they can
> participate in LL exchanges on Link B.

> A and Link B without changing the basic principle but making the attack more

I don't doubt there are pathalogical cases where one can arrange to
have packets destined to a LL address forwarded across the internet to
a target network. Christian mentions tunneling, for example. Well,
tunneling breaks ingress filtering too. Maybe what this document
should do is add a section that talks about tunneling and how tunneled
packets that contain LL addresses should be not forwarded (ever)
and/or even discarded as a bad idea and/or potential security
vulnerability.

But I think in general, arranging to have packets for LL destinations
improperly delivered to links multiple hops away will be hard to do
and thus does not open up a significant vulnerability.  Or where it
does, the vulnerability isn't due to LL, it's with the mechanism that
is being exploited, which probably also allows attacks from normal
addresses. E.g., source routing can allow packets to be delivered in
circumvention of policy for non LL addresses too.

So, if folk really think that the TTL=255 check on reciept prevents
off-link attacks, please  be very specific about how  they work, and
how these are _new_ vulnerabilities that are somehow different or
worse than when non-LL addresses are used.

Up to now, I haven't seen a clear example of an attack from off-link
senders to a LL address for which the best defense is the TTL=255
check.

Thomas

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 5 Mar 2003 13:39:22 -0000

> From: "Mika Liljeberg" <[email-masked]>
...
> > +--------+Gateway-A+--------+Gateway-B+--> to the Internet
...
> Granted. I could use that same scenario to argue for TTL=1. :)

I am not (yet) arguing any side of the TTL debate. I was simply pointing out
that your assertion that it is hard to get a LL-destination packet onto the
link from outside doesn't hold in some quite plausible circumstances.

> I don't think it very likely.

I disagree - this configuration seems quite likely.

> their routers the way you suggest.

I certainly didn't envisage ISPs doing this but it is just the sort of
configuration which could very easily occur in a small organisation which
does not have the resources to have a fully qualified geek administering
their network.

> From: "Robert Elz" <[email-masked]>
> What attack?

Attack was a loose term based on the fact that the packet was deliberately
("maliciously") sent in from off-link - I should obviously have used some
other term.

> From: "Thomas Narten" <[email-masked]>

Wrong. The routers do not in general grab the traffic because it is not sent
to them by properly behaved LL hosts. The issue will arise either if the
source is not LL aware and just sends to the default route or if the source
maliciously exploits the configuration.

I daresay there are other scanarios too where it is very easy to get a
packet with a LL destination, in from outside - especially from a nearby
network. My point was just that this might not be the rarity that Mika was
suggesting.

Philip

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 Mar 2003 21:20:31 +0700

Date:        Wed, 5 Mar 2003 13:39:22 -0000
    From:        "Philip Nye" <[email-masked]>
    Message-ID:  <001101c2e31c$a1b9e820$131010ac@aldebaran>

  | Attack was a loose term based [...]

please be careful with use of terms like this - if something is an
attack, then clearly we should be taking reasonable steps to avoid it.

If it isn't an attack, but that was just a convenient word, then perhaps
it is just a harmless side effect, that we can ignore.

kre