[strongSwan-dev] DoS protection questions

[Emeric POUPON]

>> I know these settings and they look promising.
> 
> Why not use them then?

We do, but we still suffer from DoS attacks that seem trivial to setup.

>> Unfortunately as I said before they seem to be useless since the counter is
>> increased too late in the IKE_SA manager.
> 
> Yeah, I noticed that it's quite late.  Since strongSwan calculates the
> IKE keys while processing the IKE_SA_INIT request (and not e.g. when
> processing the IKE_AUTH request) it might be better to increase this
> counter when the IKE_SA is checked out.  But even so I guess there could
> be lots of packets queued initially until a number of them have been
> processed to increase the half-open SA count.  I suppose you could
> counter that by some rate limiting in the firewall (e.g. only allow a
> few UDP packet/s per source IP).  We currently also don't recheck the
> limits when processing queued packets (they are only checked early in
> the receiver before they get queued).

Furthermore, I am afraid we actually queue a lot of jobs (more than one) when the counter is decreased by one.
I think it may be the root problem?

>> We simulated a DoS attack and charon did not handle it well (see the logs in the
>> initial question).
> 
> How exactly?  And what settings did you use on the responder?  (I saw
> that there are e.g. only 16 threads and I guess you didn't set a job limit.)

Here is the initiator configuration :

 charon {
    reuse_ikesa = no
    threads = 32

    plugins {
        load-tester {
            enable = yes
            initiators = 32
            iterations = 1000000
            delay = 100
            responder = 172.21.21.33
            proposal = aes128-sha1-modp1024
            initiator_auth = psk
            responder_auth = psk
            request_virtual_ip = yes
            ike_rekey = 0
            child_rekey = 60
            delete_after_established = no
            shutdown_when_complete = no
        }
    }
}

On the responder, cookie threshold is set to 10 and block_threshold is set to 5, and there is neither job limit nor half open limit set.
There is no visible effect if we set both cookie and block thresholds to 1. Same for init_limit_half_open set to 5.
The only visible effect is to set a job limit, but since it is global we could prevent high priority jobs to run properly.

Regards,