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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
