>> What your draft does, is force the initiator to protect each
>> fragment. To protect a fragment in a way that will cause the
>> responder to store it, requires running the MAC function, and that
>> in turn requires generating the keys (running the PRF), which in
>> turn requires completing the D-H calculation. If the initiator fails
>> to do any of these things, the fragment will be immediately rejected
>> at the responder. Of course, the D-H calculation is not
>> per-fragment, and I did not claim that this was the case.
>
> Initiator must do Diffie-Hellman anyways before it can send IKE_AUTH.
True for a legitimate Initiator. At attacker can send fake fragments, and
the responder has the option of expanding
CPU resources for verifying the ICV, or expanding the memory resources for
storing them for a while.
There is no difference comparing with usual, non-fragmented IKE_AUTH
message -
responder still can be forced by attacker to complete DH, calculate keys and
try to verify forged message. And fragmentation doesn't make it worse.
And even with unprotected fragments it is not a big deal for attacker to
send
you a set of fragments that you will successfully reassemble to a
good-looking
message and then you again will have to complete DH, calculate keys and
try to verify that garbage. No difference.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
