netdev - Re: IPsec PMTUD problem

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 PHC
Open Source and information security mailing list archives

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

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

Date:	Tue, 3 Apr 2007 19:55:10 +1000
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: IPsec PMTUD problem

Hi Patrick:

On Mon, Apr 02, 2007 at 04:10:25PM +0200, Patrick McHardy wrote:
> I noticed a problem with PMTUD between two IPsec tunnel endpoints.
> When sending a packet larger than the PMTU with IP_DF from one
> tunnel endpoint to the other, xfrm4_output sends an ICMP frag.
> required with the IPsec MTU. Since the addresses match the tunnel
> endpoints, this updates the MTU for the XFRM route with the value
> that was calculated for the entire bundle, which in turn causes
> a decrease for the bundle, resulting in further ICMP frag. required
> messages until the minimum is reached.

I presume you're using the same pair of addresses inside and
outside the tunnel? If so the problem is that the kernel doesn't
distinguish between internal ICMP errors and external ones.
So when an MTU update occurs for the internal pair the external
pair is also affected.

We'd need some field in the routing cache to distinguish the
two pairs.

Of course the easy work-around is to use distinct addresses
within IPsec tunnels.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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