Wang Xi <[email protected]> wrote: > Thanks for the insights. Glad to hear we are aligned on keeping this > purely within the application layer
> If we strictly wait for the response to arrive as per RFC 7296, the
> responder (the loser) is still forced to execute the heavy PQC signing
> just to generate that doomed response. This completely defeats the
> purpose of mitigating PQC overhead.
Yes, this is a problem for a responder that sees that the SA in question will
not be the winning SA. If the initiator doesn't implement the sensible
heuristic I am proposing, the responders only real choice here is to discard
the packet, and risk retransmission.
(If the SA *would* be the winning SA, then the responder should stop/delay the
SA
it is initiating, and it should do the signature...)
> To solve this without breaking the state machine or risking a spoofing
> DoS, I am NOT suggesting a standard DELETE payload. Instead, once the
> responder verifies the collision via local identity checks, it should
> reply with an encrypted, lightweight COLLISION_ABORT Notify Payload
> using the IKE_SA_INIT keys, and instantly tear down the state.
How can it do that when it hasn't got an encrypted SA?
To get encrypted, you have to do the KEM too.
> To be precise, this mechanism does not eliminate 100% of the PQC
> overhead, as the initiator has already computed and sent its initial
> IKE_AUTH request. However, it completely saves the responder from
> running the heavy asymmetric PQC signing for the response. Since the
> reply comes from the responder, it perfectly honors the standard
> Request-Response flow, while successfully shielding the responder's
> CPU.
I think, responsder can just unilaterally protect its CPU by dropping traffic.
Maybe it's time for the puzzles to return.
A long time ago, that's how FreeS/WAN protected itself against IKEv1
aggressive mode.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
** My working hours and your working hours may be different. **
** Please do not feel obligated to reply outside your normal working hours **
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
