[PATCH 1/1] Security: Reduce impact of bogus key setup packet DoS

[Ian Jackson]

Richard Kettlewell writes ("Re: [PATCH 1/1] Security: Reduce impact of bogus key setup packet DoS"):
> I had to modify the test program slightly to get it to work properly 
> (diff attached).

Thanks.  I don't know why my kernel tolerated that mistake!

>  The DoS and the enter_wait_state() patch behave as 
> described.

:-/

> Thoughts:
> 
> 1) There's a comment in the code suggesting maintaining a blacklist of 
> bad setup sources.  I'm not really convinced by this suggestion: slow, 
> overloaded or poorly connected systems might fail to complete setup for 
> an extended period, making them difficult to distinguish from a 
> malicious source.

Quite so.

> 2) The setup state is broken out into a separate chunk in 'struct site'. 
>   Assuming that reflects reality (which I've not checked!) it doesn't 
> seem like it would be especially onerous to have multiple parallel key 
> exchanges selected by source IP address, and to accept whichever 
> completed first and junk the rest.

Well, except that key exchange packets can consume computational
resources doing public key crypto.  Since without
--enable-hacky-parallel secnet is single threaded that would also be a
possible DoS for data transfer, and with that option it's an
opportunity to DoS the host by getting secnet to fork lots.

> Neither of these help if the attacker has many IP addresses available 
> (in both cases there would have to be some kind of size limit to prevent 
> resource exhaustion).

I'm afraid think the right answer is a protocol change.  The initiator
should be required to prove that they can receive packets sent to
their address, and then the first thing after that should be signed by
the initiator (and there should be a global ratelimit for verification
attempts).  But I don't propose to do anything like that soon.

> 3) Often the legitimate setup source for a site will be reasonably easy 
> to discover out of band - for instance there may be a DNS name that 
> reliably points at it.  secnet could limit what addresses it would 
> accept MSG1 from for such sites.  This doesn't introduce a new 
> dependency as it already uses DNS to discover the target address (in 
> fact it would usually be the same name).

The DNS, while harder to attack, is of course not really secure in
that sense.  This would be a useful feature I think.  It would have to
be a site option because some users are currently relying on the fact
that secnet does not insist on its peer having the right address, even
if a DNS name is specified in the config.

I think we should revisit this after my "mobile" option is in thhe tree.

> This does not help if the legitimate peer does not have a stable name.

Yes.  I don't have a solution for that...

Ian.