netdev - Re: Re-adding support for nested IPsec tunnels

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: <ZHc6Bdt4NfI7nclq@gauss3.secunet.de>
Date: Wed, 31 May 2023 14:13:57 +0200
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Benedict Wong <benedictwong@...gle.com>
CC: <netdev@...r.kernel.org>, <martin@...ongswan.org>, <nharold@...gle.com>,
	<evitayan@...gle.com>
Subject: Re: Re-adding support for nested IPsec tunnels

On Wed, May 10, 2023 at 01:30:20AM +0000, Benedict Wong wrote:
> This patch set adds support for inbound nested IPsec tunnels within the 
> same network namespace by incrementally marking verified secpath entries 
> once policy checks are complete. This allows verification that each layer 
> of nested tunnels can be verified, even where the outermost headers 
> change (src/dst/proto/etc). 
> 
> The previous iteration b0355dbbf13c ("Fix XFRM-I support for nested ESP 
> tunnels") attempted to clear secpath entries once verified, but that 
> caused issues with netfilter policy matching (lack of secpath entries to 
> match against), and transport-in-tunnel mode (where the tunnel policies 
> are still resolvable, and thus expected). 
> 
> Notably, all secpath entries (except where optional) must still have the 
> secpath entries validated, but they may now happen in multiple steps.
> 

Series now applied, thanks Ben!