Should routers send redirects by default?

Tue Aug 24 20:02:49 UTC 2010

On Fri, Aug 20, 2010 at 07:49:43PM -0400, Ricky Beam wrote:
> I think it's almost universally disabled (by default) everywhere in IPv4 
> purely for security (traffic interception.)  In a perfectly run network, 
> redirects should never be necessary, so I'd think IPv6 should avoid going 
> down that road again. (support OPTIONAL, never enabled by default.) [It's 
> another insecure mistake IPv6 doesn't need to repeat.]

I am not sure that is so much of an issue in IPv6.  I know that in
IPv4 3rd party ICMP redirects were quite common among the kiddies to
knock each other off IRC, but ICMPv6 redirect reception in hosts has
a number of saves and limitations that mean it should be far less,
perhaps not an issue, provided your local network is secure and BCP
38 is in use.

For example, an ICMPv6 implementation will not process a redirect from
a router that is not the host's current next-hop for the target
destination.  Because this is a Link-Local Address, an off-link
attacker has quite a problem guessing (and on-link attackers are a
problem anyway).

But I have a different memory of why we first started disabling
redirects, back in the day.

My memory is that hosts typically implement redirects with /32 routes,
with no aggregation, installed upon receiving a redirect message.

The ICMP message does not contain any TTL, and none was specified in
RFC, so consequently over the lifetime of a device receiving redirects
the routing table grows until every redirected destination is
enumerated, or the system restarts.

The ultimate size of the table reached can be quite large, beyond the
scale typically engineered for in a host.

Of course, that was back in the day when hosts were typically slower
than the LANs they were connected to.  So every additional host route
installed increased per-packet forwarding overhead and decreased
throughput considerably.

Although ICMPv6 Redirect messages also lack a (router-advertised) TTL,
an examination of [1] leads me to believe they will time out because
they are implemented as part of the ND llinfo cache.  A stale cache
entry (the equivalent of a /128 route with link layer information)
will ultimately be cleaned.  If the destination is reused later,

So it may be that the same conclusion does not hold, except in the
unusual condition where a large number of redirects are required over
a relatively short period of time (such as devices that have a large
number of active sessions with hosts that its routers redirect; web
servers, smtp systems...).

[1] Li, Q., Jinmei, T., Shima, K., "IPv6 Core Protocols
    Implementation", October 2006.
    ISBN 13: 978-0-12-447751-3
    ISBN 10: 0-12-447751-8

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20100824/e3c1c5a2/attachment.sig>