netdev - Re: [PATCH][IPSEC] inter address family IPsec tunnel on the fly

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

Message-Id: <20080305.134020.05696990.davem@davemloft.net>
Date:	Wed, 05 Mar 2008 13:40:20 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	kazunori@...azawa.org
Cc:	netdev@...r.kernel.org, usagi-core@...ux-ipv6.org
Subject: Re: [PATCH][IPSEC] inter address family IPsec tunnel on the fly

From: Kazunori MIYAZAWA <kazunori@...azawa.org>
Date: Wed, 5 Mar 2008 21:37:27 +0900

> Hello David,

Hello,

> This patch fix inter address family ipsec tunneling
> when we install IPsec SA via PF_KEY interface
> because there are no interface to set the selector.
> 
> This patch is for net-2.6
> 
> Signed-off-by: Kazunori MIYAZAWA <miyazawa@...ux-ipv6.org>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>

It seems quite excessive to grab and release the module reference
count during every packet input/output which happens through IPSEC
tunnels.

The whole reason we store the mode information in the state is so that
we only have to grab the reference during IPSEC rule addition, instead
of during packet processing.

Having to export xfrm_mode_{get,put} from xfrm_state.c is a sure
sign of trouble :-)

Is there some way we can simply propagate the correct setting to
x->inner_mode?

I also wonder if the PF_KEY limitation really exists.  For example we
will set x->sel.family etc. from the SADB_EXT_ADDRESS_PROXY attribute
if present.

Finally, if the determination can be made in the data path, it
by definition could be made during rule insertion which is much
more efficient and appropriate.
--
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