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: <20101006012509.GA3540@gondor.apana.org.au>
Date:	Wed, 6 Oct 2010 09:25:09 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Arnaud Ebalard <arno@...isbad.org>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	netdev@...r.kernel.org
Subject: Re: [PATCHv4 net-next-2.6 4/5] XFRM,IPv6: Add IRO remapping hook
	in xfrm_input()

On Wed, Oct 06, 2010 at 01:28:42AM +0200, Arnaud Ebalard wrote:
>
>  1) First, current net-next-2.6 (no patches applied)
>  2) then, with my patches applied and CONFIG_XFRM_SUB_POLICY enabled
>  3) then, with my patches applied and CONFIG_XFRM_SUB_POLICY disabled

To measure the effect of this properly you should use null
encryption/hashing and look at the CPU utilisation with minimum
packet sizes.
 
> > With your remapping, would it be possible to add dummy xfrm_state
> > objects with the remapped destination address that could then call
> > xfrm6_input_addr?
> >
> > That way normal IPsec users would not be affected at all while
> > preserving your new functionality.
> 
> I don't think I can do that easily (at all?) with what XFRM provides,
> can I? Or at least I don't see how it is possible because I would need
> some kind of policy for the state to be applied and the only trigger I
> see is the src/dst address mismatch when processing the IPsec packet.

So do you know the remapped destination addresses a priori?

If not then then other possibility would be to add the code hook
in case of xfrm_state_lookup failure.

But more importantly you need to solve the hash collission issue
that I mentioned earlier.  Without that it won't work at all.

Cheers,
-- 
Email: Herbert Xu <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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ