Re: ICMP redirect issue

[Simon Horman <horms@verge.net.au>]

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)
> 
> > From: Flavio Leitner <fbl@redhat.com>
> > Date: Wed, 28 Sep 2011 17:19:52 -0300
> > 
> >> 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?