Subject: RE: IPv4 linklocal security

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 2 Apr 2001 10:13:57 -0700

There are two issues here. One is what a well-behaved
system should do. The other is how to protect yourself
against someone who is ill-intentioned.

Setting TTL=1 on well-intentioned systems does not
prevent an ill-intentioned person from setting a
higher TTL in order to take advantage of routers who
do not treat 169.254/16 as a linklocal prefix. As I've
noted, such attacks are occurring today.

There are a number of things that could be done in
order to improve resilience to such attacks, aside
from setting TTL=255 (which would cause backwards
compatibility problems). For example, Dave Thaler
has suggested:

1. Dropping packets on the host that are destined to
   the linklocal prefix, but don't originate from the
   linklocal prefix.

2. Dropping packets on the host that originate from
   the linklocal prefix that are destined for
   non-linklocal prefixes.

Implementing these two things would require the attacker
to use both linklocal source and destination addresses.
Ideally, a home gateway should have address spoofing protection
enabled so that it will not accept any packets originating
from the internal prefix on its external interface. That
would kill all spoofs, not just linklocal ones.

-----Original Message-----
From: McDonald, Ira [mailto:[email-masked]]
Sent: Friday, March 30, 2001 4:11 PM
To: 'Daniel Senie'; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: RE: IPv4 linklocal security

Hi Bernard and Daniel,

I agree with Daniel.  Let's make a SHOULD of setting TTL=1
(a MUST is impractical because it will invalidate too many
existing implementations), so that routers will ALWAYS
discard link-local traffic.

Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
  High North Inc

-----Original Message-----
From: Daniel Senie [mailto:[email-masked]]
Sent: Friday, March 30, 2001 9:46 AM
To: Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: Re: IPv4 linklocal security

Bernard Aboba wrote:
>
> 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.

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.

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

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.

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

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

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

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.

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

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