ICMP Redirect on Resolvers

Sat Apr 6 07:12:01 UTC 2013

On 4/6/13, Keith Medcalf <kmedcalf at dessus.com> wrote:
>

Although spoofed ICMP redirects mightalso  be abused to
intercept/quietly sniff traffic
on a switched LAN;
The default gateway responding with a redirect in that situation
 is the normal case where you expect to receive an ICMP redirect. ; in
that particular case ICMP redirect improves matters,  by  directing
clients to send their packets directly to that other router on that
LAN,  thus eliminating one router hop for future packets to that
destination IP address  (until the destination IP address' redirect
entry gets aged out in the sending host's route cache),
which is the whole point of ICMP redirects.

However...  routes  are better than redirects.

An ICMP redirect applies to only one IP address that is redirected, so
if you made heavy use of that functionality (eg Large LANs, with this)
-- many table entries could be spent on the redirects;  an actual
route on the host is much better than relying on ICMP redirects for
providing more deterministic behavior while still avoiding suboptimal
routing,   because only a small number of table entries are required
on the hosts (entry per network).

It's not an ideal situation, to have a large number of hosts reached
through an ICMP redirect;  in the ideal situation, you  design
networks so that you don't  route traffic across a LAN network to a
next hop IP address that also contains end hosts,  instead, give
routers dedicated 'links' or 'LANs', where the other endpoints are
routers only  (and route to next hops on those networks, instead of
end-host LANs), or else: at least populate the routing tables of end
hosts on  any LAN you route through (using static routes, or a routing
protocol on the servers),  so that you aren't carrying around ICMP
redirects.

Failing all that, if the LANs are large, and a large number of ICMP
redirects would occur,  it may be preferrable to turn ICMP redirects
off for those LANs on their routers

>> icmp redirect from 192.168.140.36: 192.168.179.80 => 192.168.140.254
>
> The host attempted to send a packet to 192.168.179.80 via 192.168.140.36.
> 192.168.140.36 forwarded the packet to 192.168.140.254 according to its
> routing table, but is advising you (and the kernel has added to the routing
> table) that in the future you reach 192.148.179.80 via 192.168.140.254, not
> via 192.168.140.36.

--
-JH