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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 24 Sep 2020 19:54:19 -0700 (PDT) From: David Miller <davem@...emloft.net> To: zenczykowski@...il.com Cc: maze@...gle.com, netdev@...r.kernel.org, edumazet@...gle.com, willemb@...gle.com, lorenzo@...gle.com, sgill@...cinc.com, vparadka@....qualcomm.com, twear@...cinc.com, dsahern@...nel.org Subject: Re: [PATCH v3] net/ipv4: always honour route mtu during forwarding From: Maciej Żenczykowski <zenczykowski@...il.com> Date: Wed, 23 Sep 2020 13:18:15 -0700 > From: Maciej Żenczykowski <maze@...gle.com> > > Documentation/networking/ip-sysctl.txt:46 says: > ip_forward_use_pmtu - BOOLEAN > By default we don't trust protocol path MTUs while forwarding > because they could be easily forged and can lead to unwanted > fragmentation by the router. > You only need to enable this if you have user-space software > which tries to discover path mtus by itself and depends on the > kernel honoring this information. This is normally not the case. > Default: 0 (disabled) > Possible values: > 0 - disabled > 1 - enabled > > Which makes it pretty clear that setting it to 1 is a potential > security/safety/DoS issue, and yet it is entirely reasonable to want > forwarded traffic to honour explicitly administrator configured > route mtus (instead of defaulting to device mtu). > > Indeed, I can't think of a single reason why you wouldn't want to. > Since you configured a route mtu you probably know better... > > It is pretty common to have a higher device mtu to allow receiving > large (jumbo) frames, while having some routes via that interface > (potentially including the default route to the internet) specify > a lower mtu. > > Note that ipv6 forwarding uses device mtu unless the route is locked > (in which case it will use the route mtu). > > This approach is not usable for IPv4 where an 'mtu lock' on a route > also has the side effect of disabling TCP path mtu discovery via > disabling the IPv4 DF (don't frag) bit on all outgoing frames. > > I'm not aware of a way to lock a route from an IPv6 RA, so that also > potentially seems wrong. > > Signed-off-by: Maciej Żenczykowski <maze@...gle.com> Applied and queued up for -stable, thank you.
Powered by blists - more mailing lists