What else could we recommend to do in this situation?
If responder deletes IKE SA in case it receives IKE_AUTH
message that doesn't pass ICV check, then it would give
an attacker an easy way to prevent legitimate initiator
to connect - just monitor the network and once IKE_SA_INIT
from the legitimate client is finished, inject IKE_AUTH message
containing garbage.
I suggest we do similar thing we do for IKEv2 in general. I.e. if you
get IKE_AUTH message which does not pass ICV, you simply drop it. I
would expect most of the implementations do that already. Also before
you can verify the ICV you need to know the SK_a and to be able to get
that you need to calculate SKEYSEED, which requires g^ir, i.e 2nd half
of Diffie-Hellman.
Agree.
So at that point you have already calculated the Diffie-Hellman. Also
implementation would be completley stupid if it would not store the
SKEYSEED and SK_* keys once it has calculated them, so I would expect
every implementation do that already, i.e. they will already keep
them, and there is no need to say anything about this in here.
I think there is no harm if the draft recommends such behaviour explicitely.
After all, it is about DDoS protection, so every thing that
concerns the desense, even evident, should be spelled out.
If responder keeps half-open IKE SA for a while waiting
for more IKE_AUTH messages, then I see no reason to repeat
calculating D-H shared secret with every received message -
the result will be exacly the same.
Why would anybody ever repeat the D-H secret calculation, when they
have already calculated SKEYSEED (and SK_*) earlier?
Do we also need to say that for future notificaitons it would be nice
for implementations to keep the "cached" SK_* values stored in IKE SA,
and not to calculate the SK_* from the KE payloads for every single
packet?
That's what the draft recommends.
I do not think we need to say such thing, and I do not think
we need to say that once you have calculated the SK_* you keep them
until you delete the IKE SA.
It's better to spell this out, then to let implementers to do it wrong.
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
