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
