Re: [PATCH] Fix xfrm hash collisions by changing __xfrm4_daddr_saddr_hash to hash addresses with addition

[Herbert Xu <herbert@gondor.apana.org.au>]

On Wed, Aug 12, 2009 at 08:56:35PM -0700, David Miller wrote:
> 
> 1) The client is on your private network, much more serious
>    mischief is possible.

Not necessarily as having an IPsec connection does not entail
full access to the network on the other side.

> 2) Whoever creates such a hash collision explosion can be
>    precisely identified.
> 
> The ikev1 failure case is an interesting situation I hadn't
> considered.
> 
> Maybe that can matter, but again the guilty party is easy to identify
> and easy to block via whatever means appropriate.

For corporate networks perhaps.  However, in other cases the
peer may be trusted even less.  For instance, if IPsec were
used for mobility purposes then you essentially don't know
the client at all.

It's like Facebook.  If one user mounts a DoS attack you can
block their account.  However, if they can simply come back
with a new account then you need to make sure that the attack
can be mitigated in other ways so that it doesn't bring the
whole thing down.

BTW, this isn't just exposed to IPsec peers.  It can also be
exposed to those behind the gateway not using IPsec.

Some IPsec applications use a policy that spawns one SA per
src/dst address pair.  In that case, even an entity that is
not on the IPsec side would be able to spawn SAs with the intent
of causing collisions.  It simply needs to send packets through
the IPsec gateway with the appropriate destination addresses.

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