[nycbug-talk] Fwd: icmp redirects from host A to host A

[Miles Nordin]

>>>>> "jc" == Jesse Callaway <bonsaime at gmail.com> writes:

    jc> Even then... accepting routes over ICMP is probably not SOP
    jc> for most router maintainers I would venture to
    jc> guess.

they're either accepted or ignored really quietly.  There's nothing to
configure except two sysctl knobs:  send or not?  and obey or not?

They're sent if, for example:

 .1
    0.0.0.0/0   via <some other interface>
    1.2.3.0/24  via .2

 .2
    0.0.0.0/0   via .1
    1.2.3.0/24  via <some other interface>

 .3
    0.0.0.0/0 via .1

In this case, when .3 sends a packet to 1.2.3.4 via .1, then .1 will
forward the packet out the same interface it was received albeit with
the new destination MAC address, and will also send an ICMP redirect
to .3 asking that further packets for 1.2.3.4 go directly to .2.  .3
will install a route via .2 for a little while.  The route times out,
though, like ARP.  And this is very old and is actually implemented on
BSD gateways and end-systems, though I don't know if it defaults to on
or off.

You can argue about whether this is really a security problem or not.
If the redirects were sanity-checked before accepting them such that
they can never change a destination's outbound interface, I could see
its being implemented with no added danger over arp spoofing.  I'm not
sure they are sanity-checked, though.  I usually turn off accepting
redirects with sysctl.

Max's redirect, though, seemed to have the same address in the
destination and next-hop fields, so I don't know why it was generated,
and that's why i didn't reply before.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20081110/f76c4c3e/attachment.bin>