On 4/6/13, Keith Medcalf <kmedcalf@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