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

["Valery Smyslov" <[e-mail]>]

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