Subject: RE: comments on mnds-00

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 29 Mar 2001 13:18:23 -0800

To provide some perspective on this, recently I noticed multiple
attempted breakins to a system coming from the 169.254/16 prefix. I then
did a traceroute, and 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.=20

The implication is that an attacker using this (bogus) source address
could reach hosts up to 4 hops away, and possibly more if the path did
not traverse a backbone router. Declaring=20
169.254/16 a linklocal prefix is unlikely to have much effect in the
short term; after all, IANA has listed this as a linklocal prefix for
more than a year now, apparently with minimal effect. It is likely that
it will take several years for the necessary router upgrades to be
widely deployed.=20

Given this reality, we feel that it is necessary for hosts to
incorporate their own protection mechanisms, rather than relying on
routers to do the right thing. Requiring TTL=3D255 provides a mechanism
for hosts to protect themselves against off-segment attackers, since
routers that do not recognize 169.254/16 as a linklocal prefix will
still decrement TTL.=20

This issue exists not only for mDNS but also for all use of IPv4
linklocal addresses.=20

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Wednesday, March 28, 2001 8:58 AM
To: Erik Guttman
Cc: [email-masked]; [email-masked]; Dave Thaler; Bernard
Aboba; Levon Esibov; [email-masked]
Subject: Re: comments on mnds-00

> Shouldn't IPv6 hop count / IPv4 TTL be 1 for link-local multicast dns?
> If this is a 'clever trick' which will cause listeners to drop
messages
> after they've traversed a single router (they will always be less
than=3D20
> 255 in this case), I claim this is not a good idea.  A link-local=3D20
> protocol shouldn't be routed at all:  We choose an address we
specify=3D20
> routers must not forward, and we send with hop count/ttl =3D3D 1 to
further=3D
> =3D20
> reduce this possibility.

You seem to be touching on two issues:
1. should be able to span more than one link
2. even on one link the ttl 255 trick is undesired or broken.

Did I get that right?

The issue the 255 trick is addressing is attacks from far away by
injecting
bogus unicast responses. Using ttl=3D1 doesn't address that.
Requiring that both source and destination be link local
unicast/multicast
would accomplish close to the same thing as the ttl 255 trick,
but RFC 2461 uses non-link local addresses in some cases which is why
it mandates ttl 255.

  Erik

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Bill Manning <[email-masked]>
Date: Fri, 30 Mar 2001 04:26:48 -0800 (PST)

% To provide some perspective on this, recently I noticed multiple
% attempted breakins to a system coming from the 169.254/16 prefix. I then
% did a traceroute, and 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.=20

From the current DSUA draft, draft-manning-dsua-06.txt:

169.254.0.0/16 has been ear-marked as the IP range to use for end node 
auto-configuration when a DHCP server may not be found. As such, network
operations and administrators should be VERY aggressive in ensuring that
neither route advertisements nor packet forwarding should occur across
any media boundaries. This is true for the Internet as well as any
private networks that use the IP protocols. End node administrators
should be aware that some vendors will auto-configure and add this
prefix to the nodes forwarding table. This will cause problems with
sites that run router discovery or deprecated routing protocols such as
RIP.

-- 
--bill

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Mar 2001 09:48:41 -0800

> auto-configuration when a DHCP server may not be found.

could we have a document reference for this?

randy

---

From: Bill Manning <[email-masked]>
Date: Fri, 30 Mar 2001 09:58:41 -0800 (PST)

% 
% > 169.254.0.0/16 has been ear-marked as the IP range to use for end node 
% > auto-configuration when a DHCP server may not be found.
% 
% could we have a document reference for this?
% 
% randy
% 

Sure.
62% whois [email-masked]
[whois.arin.net]
Internet Assigned Numbers Authority (IANA) (NETBLK-LINKLOCAL)
   For use with Link Local Networks
   Information Sciences Institute
   University of Southern California
   4676 Admiralty Way, Suite 330
   Marina del Rey, CA 90292-6695
   US

   Netname: LINKLOCAL
   Netblock: 169.254.0.0 - 169.254.255.255

   Coordinator:
      Internet Corporation for Assigned Names and Numbers  (IANA-ARIN)  [email-masked]
      (310) 823-9358

....
Based on the now expired draft:
draft-ietf-dhc-ipv4-autoconfig-04.txt, October 1998
See: RFC 2563 for documentation on how to disable this feature.
(Note to self. Its odd that the prefix for Autoconfig & associated documentation
never made RFC status but how to disable it did...)

...

-- 
--bill