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