> On 10 Nov 2021, at 16:41, Michael Richardson <[email protected]> wrote:
>
>
> Yoav Nir <[email protected]> wrote:
>>>> Tero Kivinen <[email protected]> wrote:
>>>>>> Even without surpassing the 64KB limit, this must be a concern.
>>>>>> IKEv2's cookie mechanism and puzzles try to increase the cost of the
>>>>>> attacker per each connection. Now, an attacker must still accept
>>>>>> these costs but can use one connection to trigger several key
>>>>>> exchanges, all significantly larger than what we had with DH, making
>>>>>> the trade-off way better for them compared to non-pqc IKEv2.
>>>>
>>>>> No it cannot. Attacker can use cookie only once, and will only get one
>>>>> exchange created by each cookie exchange, thus it needs to do puzzles
>>>>> and cookies again for every single attack packet it wants to send.
>>>>
>>>> I wonder if anyone has any stats on how often cookie challenge is used, how
>>>> often puzzles are invoked.
>>>
>>> I've implemented puzzles, but I'm not aware of any other implementation.
>>>
>>> What about cookies - in stress tests they are used very intensively.
>>> But I don't have any real life stats for them.
>>>
>>> Regards,
>>> Valery.
>
>> I also implemented puzzles. So that makes two of us.
>
> Did you ever interop?
No. Never got to it.
> What is your criteria for enabling them? Do you do this automatically, or is
> it an operator configuation to demand them?
GUI had three settings: off, cookies, puzzles. In case of cookies or puzzles,
they would activate with a certain number of simultaneous IKE negotiations in
progress.
Because of GUI constraints, that setting had to apply to both IKEv1 and IKEv2
(that was s separate set of radio buttons)
Yoav
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
