netdev - Re: [PATCH 7/12] [IPSEC]: Remove xfrmX_tunnel_check

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-next>] [day] [month] [year] [list]

Message-ID: <4714CCCC.2040504@trash.net>
Date:	Tue, 16 Oct 2007 16:38:04 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Herbert Xu <herbert@...dor.apana.org.au>
CC:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH 7/12] [IPSEC]: Remove xfrmX_tunnel_check_size

Herbert Xu wrote:
> [IPSEC]: Remove xfrmX_tunnel_check_size
> 
> These functions have always been causing trouble by sending ICMP errors
> back to the local host which was totally confused about how to deal with
> it and most often ended up causing a downward spiral which only finishes
> when the MTU is so small that you can't send packets out anymore.
> 
> They're also wrong now that we have inter-family transforms.  They'll
> end up trying to shove an IPv4 packet into the IPv6 ICMP stack and vice
> versa.
> 
> In fact, I've just realised that they are totally unnecessary.  The reason
> is that whoever calls us should have already checked the MTU.  In particular,
> there are two cases:
> 
> 1) The packet is forwarded in which case the forwarding function would've
> performed the check.
> 
> 2) The packet is local in which case whoever generated it should've checked.
> If they didn't check then us sending back an ICMP error wouldn't do any good
> anyway since the next time they transmit they'll still get it wrong.
> 
> So the only time this function has an effect is when the MTU happens to
> change between the caller checking it and us checking it.  This is useless
> because if we did catch such a change there's nothing stopping a further
> MTU change between us checking it and the packet actually getting to the
> device.

Thats true, but for the first case we actually have something in the
stack doing that, which is NAT and routing by fwmark. Maybe netfilter
should just send an ICMP error back, that would also solve the problem
of silently dropped packets when rerouting to an unreachable
destination.
-
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