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

From: "Christian Huitema" <[email-masked]>
Date: Tue, 4 Mar 2003 17:21:47 -0800

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

Wrong. Source routes and tunnels come to mind easily.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Mar 2003 20:48:00 -0600

> Wrong. Source routes and tunnels come to mind easily.

Of course, but I mean in practice, not in theory.   Source routing is 
dangerous.   In practice, it's not available, even though it's 
described in a standard and very widely implemented in various IP 
stacks.

> dra-chi% sysctl -a |fgrep source
> net.inet.ip.sourceroute: 0
> net.inet.ip.accept_sourceroute: 0

This is the default configuration for a MacOS X machine.   Do Windows 
machines, Cisco routers, or the like, come with source routing enabled? 
   Unless I am mistaken, in practice there is no way to use source 
routing to get a packet somewhere it doesn't belong across the Internet.

As for tunnels, I didn't say it wasn't possible for an IPv4ll packet to 
leak *out*.   I imagine it could follow default routes quite a ways out 
from a leaf network before it was stopped by a BGP router with no route 
for the IPv4ll class B.   It's hard to imagine how this could be used 
to *direct* an IPv4ll packet somewhere it didn't belong.

As for tunnels, if you have your laptop configured to do routing, and 
it has a VPN tunnel into your corporate network, then it's possible 
that an attacker on your local network could forward a packet through 
your machine and use it to attack some resource on your corporate 
network.   I would hope that there aren't any VPN clients out there 
that can easily be configured to work this way.   If there are, this is 
only one of many attacks that is possible.   Once again, it's difficult 
to see how this attack would be useful, since it's unlikely that 
there'd be a way to get a reply back out through the tunnel, nor out 
through the corporate firewall, from an IPv4ll node that's not 
cooperating in the attack.

The point is that while this is theoretically a problem, it's not a 
problem over which we need get our knickers in a twist.

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Mar 2003 10:04:18 +0200

> Wrong. Source routes and tunnels come to mind easily. 

Easy to think of and easy to counter. The TTL=255 check doesn't protect
against tunnel attacks and everybody who is concerned about security
drops source routed packets anyway.

	MikaL

---

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

> Wrong. Source routes and tunnels come to mind easily. 

What new vulnerabilities occur here that aren't already present with
non-LL addresses? If there are specific new vulnerabilities related to
LL, we need to at least document them and possibly also try to
mitigate them.

For tunnels, it seems to be that this document might just want to
point out that when LL traffic pops out of a tunnel, normal forwarding
rules apply, and they should not be forwarded.

We might also want to say that by default, LL traffic should not be
tunneled and should be discared on receipt.

Thomas