Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt

[Paul Wouters <[e-mail]>]

On Mon, 28 Mar 2016, Valery Smyslov wrote:

>>  If we assume cookies take care of spoofed IPs, then an attacker trying
>>  to waste the responders resources would exchange an IKE_INIT round,
>>  and then just send a bunch of IKE_AUTH packets (with proper SPIs) that
>>  all will fail to decrypt. The responder has to try all of them because
>>  it could be a legitimate client. So I'm not sure if you actually buy
>>  anything by postponing the SKEYSEED and SK_* calculation?
>
> Postponing SKEYSEED and SK_* calculation saves your resources
> if IKE_AUTH request never come.

But if the attacker wants to exhaust your cpu, they _will_ come back
with a /dev/random filled IKE_AUTH request.

> It can be if there are some network
> problems (for example, the IKE_AUTH message is too long, get fragmented
> by IP and dropped by NAT, and the initiator doesn't support IKE 
> fragmentation)
> or if the initiator never mind to send IKE_AUTH (i.e. it is an attack on 
> half-open SAs, that could be even with cookies - in case of botnets).

That's not really a ddos protection. It's more of a common sense thing.

> Mostly yes. However in some cases it is not so stupid. If you do all crypto 
> in hardware
> and this hardware may handle limited number of key handles, then
> you'd probably discard the keys in this case not to exhaust crypto HW memory.
> In this case you'll recalculate them once new IKE_AUTH arrives.
> This a tradeoff and the draft recommends (with SHOULD) to keep the keys.

Ok, I guess I feel it is a bit of a stretch away from "ddos defense" and
more of a "core implementation sanity", but I guess that line is a
little subjective, and I guess a paragraph extra won't hurt the
document.

Paul