netdev - Re: [PATCH net] ipv4: add support for "gratuitous" redirect

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1443617718.6398.25.camel@dhcp-176-88.mxp.redhat.com>
Date:	Wed, 30 Sep 2015 14:55:18 +0200
From:	Paolo Abeni <pabeni@...hat.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, kuznet@....inr.ac.ru, jmorris@...ei.org,
	yoshfuji@...ux-ipv6.org, corbet@....net, kaber@...sh.net
Subject: Re: [PATCH net] ipv4: add support for "gratuitous" redirect

On Tue, 2015-09-29 at 11:49 -0700, David Miller wrote:
> I don't know if it's a question of terminology but RFC1122 does
> seem to ask us to make this check, from 3.2.2.2:
> 
>         A Redirect message SHOULD be silently discarded if ... the
>         source of the Redirect is not the current first-hop gateway
>         for the specified destination (see Section 3.3.1).

According to the same RFC:

*    "SHOULD"

              This word or the adjective "RECOMMENDED" means that there
              may exist valid reasons in particular circumstances to
              ignore this item, but the full implications should be
              understood and the case carefully weighed before choosing
              a different course. 

So, if we agree that there are valid reasons we can make this check
optional.

> Whereas if we changed the routers to send ICMP redirects that these
> hosts would actually accept, you'd only have to make the change on
> the routers.  This is several orders of magnitude easier to deploy.

Actually fixing this behavior on the VRRP router requires somewhat
'NATing' ICMP redirect packets, which AFAIK is not possible on a Linux
box, since ICMP reply packets do not traverse the nat table.

To cope with the original issue on the router, it would be needed an
'icmp_errors_use_inbound_daddr' sysctl, that, when enabled, forces the
kernel to send icmp error messages using the destination address of the
incoming packet as source. 

Eventually we can restrict the above option to icmp redirect only.

Do you think that adding such configuration would be more acceptable?

Some time ago, there was already some discussion on this topic:

http://comments.gmane.org/gmane.linux.kernel/1128505

Thank you,

Paolo

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html