Hi Yaron,
We are almost in agreement. My understanding is that both the
IKE_SA_INIT and IKE_AUTH puzzles are needed, and each one has a
different goal:
- IKE_SA_INIT puzzle: should counteract the responder's memory cost of
keeping the half-open SA, and its CPU cost in computing DH.
- IKE_AUTH puzzle: should counteract the responder's CPU cost of
validating the AUTH payload.
Thank you, now I better understand your position. Let me rephrase it.
You propose that IKE_AUTH puzzle resides inside SK payload
and its verifications takes place after computing DH
and verifying authenticity of IKE_AUTH messag, but before
any actionts dealing with peer authentication take place.
Am I right?
This will allow attacker to perform an attack on responder's CPU power
by sending single garbage message in IKE_AUTH,
which will be partially counteracted by IKE_SA_INIT
puzzle. But this will definitely ease legitimate client's burden
in case of IKE fragmentation.
I still prefer IKE_AUTH puzzle to reside outside SK payload
and to be verified before performing DH and computing SKEYSEED.
However, after some thoughts, I think that in case of IKE
fragmentation, puzzle must only present in the very first
fragment (outside SKF payload), not in the every fragment,
as I proposed before. The responder in this case will pay no attention
on the other fragments untill it receives the first one and verifies the
puzzle.
Fragments that were received before this event
could be dropped (in a hope that they will be eventually
retransmitted) or just collected with no action. In the latter case
after the puzzle is vefified and DH is computed all the
collected fragments must be verified for theit authenticity.
This approach would still require legitimate client to re-solve
puzzle in case it first sends unfragmented message and then
switches IP fragmentation on (or in case it refragments
the message with smaller MTU), but it would provide better
defense against attacks on CPU exhausting in IKE_AUTH.
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
