The text is not exactly about this. Once the responder sent IKE_SA_INIT response it is able to calculate SKEYSEED and SK_* keys. However, it is a good idea not to do it immeditely, but instead wait for the IKE_AUTH request to come. The reason is that in case IKE_AUTH request never came (attack, network problem etc.), the responder would not spent quite a lot of CPU resources calculating D-H shared secret.

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. 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).

However, in this case careless implementations could
discard the just computed SK_* keys if the IKE_AUTH request failes to decrypt.

Like I said, that would be _really_ stupid. So stupid that I don't think
it needs to go into an RFC. As you have to protect against the attack
I list above anyway.

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.

 See other discussions. We sadly have a strong demand by operational
 people to have really short liveness timers. While as implementor, we
 have refused < 1s, people often do use 1s timers as a way to do High
 Availability. So I think the advise of limiting the number of allowed
 responses for an IKE SA in general is dangerous. There are many
 unexpected use cases.

No, there is no advises to limit the number of responses.
There is an advice to delay responce in case of there are too
many requests in order to limit the rate of requests. If your implementation relies on an immediate reply and no packets loss, then don't follow this advice.

Can you at least put in a small note on the issue of liveness probes and
the risk of delaying these? Eg a 3 probe, 1s each liveness would die in
3 seconds, which seems to be well within the range in which you say
implementations could delay things.

OK.

Regards,
Valery.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to