On Wed, Sep 28, 2011 at 07:12:55PM -0400, David Miller wrote:

From: David Miller <davem@davemloft.net>
Date: Wed, 28 Sep 2011 18:56:54 -0400 (EDT)

quoted

From: Flavio Leitner <redacted>
Date: Wed, 28 Sep 2011 17:19:52 -0300

quoted

What about something like below? It will change a bit the
secure_redirects documentation.

The previous check was stronger, and served other purposes.

Firstly, it required that the spoofer know the exact gateway
IP address we used previously, whereas your test requires only
knowing the subnet which is easier to figure out.

But more importantly, the old test allowed us to ignore outdated
or erroneous redirects.

We really have to restore the original behavior before my inetpeer
changes (enforce that the old gateway matches), and find another way
to accomodate IPVS.

BTW, I just double-checked RFC1122 and it explicitly specifies the
old_gw check:

[ RFC1122, section 3.2.2.2 ]

 ...

	A Redirect message SHOULD be silently discarded if the new
        gateway address it specifies is not on the same connected
        (sub-) net through which the Redirect arrived [INTRO:2,
        Appendix A], or if the source of the Redirect is not the
        current first-hop gateway for the specified destination (see
        Section 3.3.1).

In fact, it's saying that we should also validate that saddr == old_gw
too.

So really, we need to put the check back and find a way to accomodate IPVS.

Hi Dave,

I'm have to admit that this issues is new to me.
But doesn't it affect any setup where a secondary
address is being used as the gateway and the gateway
send an ICMP redirect?

Perhaps an option to weaken the check for these cases
would provide a work-around for those who need it.
Or does that break your inetpeer changes horribly?