| 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
| ||
|
Date: Tue, 1 Jul 2014 09:42:14 +0100 (BST) From: Edward Allcutt <edward.allcutt@...nmarket.com> To: David Miller <davem@...emloft.net> cc: kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] ipv4: icmp: Fix pMTU handling for rare case On Tue, 1 Jul 2014, David Miller wrote: > From: Edward Allcutt <edward.allcutt@...nmarket.com> > Date: Mon, 30 Jun 2014 16:16:02 +0100 > >> This is explicitly described as an eventuality that hosts must deal >> with by the standard (RFC 1191) since older standards specified that >> those bits must be zero. > ... >> One example I have seen is an OpenBSD router terminating IPSec >> tunnels. > > Why doesn't OpenBSD implement RFC 1191? Why do you think I know? :) However the standard says that you should interoperate with older implementations, and I can't see any downside to doing so. > I really don't want to allow for zero values. Why? I have had a look through all the higher level protocols and they seem to handle this fine, if they are allowed to see the signal at all. Most of them fall back to the minimum packet size, which isn't ideal but it's much better than just stalling indefinitely. If it helps any, I've been running several production machines with this patch for just about a year now (mostly running 3.10 stable series). -- Edward Allcutt -- 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
Powered by blists - more mailing lists