On Mon, 22 Jun 2026, Songbo Bu wrote:
Subject: [IPsec] Re: New I-D: draft-li-ipsecme-extensions-for-robust-negotiation
I am late reading this draft, my apologies.
I find the examples in Section 4 odd. To me, those are both valid cases
to fail the IKE SA as initiator and responder do not have matching
requirements.
Scenario 1: The initiator sends a proposal where ADDKE1, ADDKE2, and
ADDKE3 each contain the identical list of algorithms: PQ_KEM_1 and
PQ_KEM_2.
Clearly this proposal should fail to load on the initiator, as it can
never be satisfied, unless ADDKE3 is always just NONE. And having an
empty "must be NONE" proposal makes no sense.
Scenario 2: The initiator sends a proposal where ADDKE1 contains
PQ_KEM_1 and PQ_KEM_2, while ADDKE2 contains only PQ_KEM_2.
Again, this proposal should fail to load on the initiator, as it can
never be satisfied. Or it should remove PQ_KEM_2 from ADDKE1 while
loading and log a warning. But this requires more complicated code.
Not seeing an actual problem with RFC 9370, I am not convinced we need
this robustness draft. I am also not convinced that we need to allow
things like duplicate algorithms to allow for misconfigurations.
Perhaps there is a use for a document on how and when to reject ADDKE
proposals, but this document does not do that.
Paul
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
