Subject: IPv4 linklocal security

From: Bernard Aboba <[email-masked]>
Date: Fri, 30 Mar 2001 08:40:57 -0800 (PST)

Even though packets to or from the linklocal prefix (169.254/16) are not
supposed to be forwarded, it is likely that it will take some time before
this is implemented by ISPs and vendors. 

Today, more than a year after IANA first allocated the linklocal prefix,
it appears that virtually no ISPs or router vendors prohibit forwarding of
packets to or from the linklocal prefix. 

Hackers are apparently taking advantage of this; I have noted quite a few
breakin attempts coming from hosts within the linklocal prefix within the
last few days. 

As a thought exercise, I urge each of you to do a traceroute to an address
within the linklocal prefix, say 169.254.101.152. When I last did a
traceroute, I discovered that routers up to 4 hops away were forwarding
packets destined to this prefix. When the packets reached the core routers
running BGP, a host unreachable message was returned. 

The implication is that an attacker sending packets to a linklocal source
address could reach hosts up to 4 hops away, and possibly more if the path
did not traverse a backbone router. Since most routers route only 
on the destination address and not the source, packets sourced
with a linklocal prefix can go much further, probably all the way 
to the destination. Declaring 169.254/16 a linklocal prefix
is unlikely to have much effect on this particular attack in the short and
possibly even medium term. 

So what do we do about this? Given that routers are likely to continue
forwarding packets with linklocal source addresses for the forseeable
future, and packets with linklocal destinations for the short term, the
reality is that we cannot depend on ISPs and router vendors to make sure
that linklocal really means link local. 

Given this reality, I feel that it is necessary for hosts to
incorporate their own protection mechanisms, rather than relying on
routers to do the right thing. One way to accomplish this is to
require that packets sent to or from the linklocal scope contain 
TTL=255. Since even the most dysfunctional router will decrement
TTL, a host receiving a packet to or from the linklocal prefix with a TTL
< 255 can know that the packet was forwarded off-segment, and thus can
silently discard it.   

I believe that adding this protection is the right thing to do, since
otherwise, devices using only linklocal addresses will not have a
reasonable way to protect themselves. Implementing this kind of protection
in the TCP/IP stack will also make it easier for application developers,
who will not have to try to implement this in individual applications
using linklocal addressing (such as mDNS), thereby requiring the use of
raw sockets.

---

From: Daniel Senie <[email-masked]>
Date: Fri, 30 Mar 2001 12:46:15 -0500

> packets to or from the linklocal prefix.

I've had filters in my firewalls for this particular prefix for some
time. To date I've seen very few attempts using the prefix.

I see lots of Netbios/IP traffic to/from these addresses floating
around, but generally discount that as misconfigured clients nearby
(e.g. on the cable modem system, or on the DMZ at the colo I use).
However, I have started seeing lots of traffic attempting to reach
services (e.g. HTTP) coming from link local addresses.

> possibly even medium term.

RFC 1918, a BCP, does two things: it specifies a block of addresses to
use, and recommends those addresses not be routed across the Internet.
It doesn't mention all blocks which have special use, though.

Perhaps draft-manning-dsua-06.txt, should be targetted as a BCP
indicating which blocks should not be routed?

The linklocal document should specify whatever action we'd like routers
to take, and that should be noted for the RFC editor so they can mark
the RFC Index to indicate the linklocal RFC updates router requirements.

> that linklocal really means link local.

Recommend filtering for source addresses. Recommend black-holing
169.254/16 in routers (route to null interface).

> < 255 can know that the packet was forwarded off-segment, and thus can

Why not require hosts to set TTL=1? That way, if a router does get hold
of such a packet, it'll discard it due to TTL expiry.

> using linklocal addressing (such as mDNS), thereby requiring the use of

I think we should approach this on multiple levels:

- recommend filtering (source or dest) at routers (Access lists or route
to null for destination case). This covers us from an operational
perspective. This could be a small, stand-alone BCP.

- either incorporate into linklocal or write another short document that
updates router requirements with the desired action. This will help in
th long term, as router vendors release new code.

- decide on a plan for setting TTL or other such mechanism on the hosts
to effect somewhat shorter-term issues. Perhaps this should be an update
to the host requirements document?

I'm willing to take care of a few short documents if we decide they
should exist and should be stand-alone items (or help write sections if
they're going to be in other documents).

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com