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

[Paul Wouters <[e-mail]>]

On Mon, 28 Mar 2016, Valery Smyslov wrote:

[ cutting a bunch of text since we seem to just disagree about whether
  puzzles are harmful or helpful ]

>>  It is an (obvious) attack but not a DDOS attack. eg:
>>
>>  client    IKE_INIT Request          --->
>>                                      <--- IKE_INIT Response  server
>>  attaker   IKE_AUTH Request (bogus)  --->  [fails]
>>  client    IKE_AUTH Request          --->
>>
>>  I think any implementor should really already handle this case in
>>  general. Any failures of unauthenticated packets must be dropped
>>  and the timeout timer continued to wait for the legitimate response.
>>  That's a core part of the IKEv2 spec, so I don't think that needs
>>  to be repeated in this document.
>
> 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?

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

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

> However, I think that if implementations cannot tolerate
> 2-3 sec delay to requests, then they cannot operate reliably.

I've had long frustrating discussions with Large Clients that run things
that need to failover/restart within seconds, using very flaky third
world networking, and insisting on liveness timers of 1s. It happens :/
Apparently, it is more reliable for them to restart than to wait 30 seconds.

>>  So you are saying basically that this text should have appeared in the
>>  AUTH NULL RFC, but didn't. 
>
> The more general text was included there (Section 3.2), and you were the 
> author :-)

Oh, I am very fallible :)

>>  Perhaps then a separate section for AUTH NULL
>>  clients could be put in this document, and then also let it update that
>>  RFC?
>
> I don't think the update is needed. RFC 7619 has already referenced
> this document (as a draft) and has warnings that NULL auth
> clients are unauthenticated and thus can mount various attacks.

Ohh, you are right. it does reference it already. Still, putting the
"updates" in might work because it will cause an "updated by" clause
to appear at the top of 7619, so people are more convinced they need
to also read this document. But I'll let the chairs weight in on this.

Paul