Hi Paul and Guilin, Perhaps adding the following description can eliminate the ambiguity: In the initial IKE_SA_INIT exchange, all the basic capabilities (one of which is: supporting IKE fragmentation) were already negotiated. That is, during the exchange, two key notification payloads, NOTIFY(IKEV2_FRAGMENTATION_SUPPORTED) and NOTIFY(MULTIPLE_KEY_EXCHANGES_SUPPORTED)[RFC 9370], were included.
This way, both parties would clearly know whether the other party supports fragmentation. Best, Meiling [email protected] From: Paul Wouters Date: 2026-01-02 22:35 To: Wang Guilin CC: [email protected]; ipsec Subject: RE: [IPsec] Re: FW: New Version Notification for draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03.txt On Thu, 1 Jan 2026, Wang Guilin wrote: > Dear Meiling and Paul, > > Thanks the input text. Yes, absolutely, the support of IKE_INTERMEDIATE and > IKEV2_FRAG should be indicated by the both peers before exchange the public > key and ciphertext of FrodoKEM. > > We will update our draft soon to make this clear. That does not answer the question I raised though. In IKE_SA_INIT there is no fragmentation support. You first need to send and receive IKE_SA_INIT to get to know the peer supports fragmentation. But in IKE_SA_INIT you already need to send a KE payload, and this KE payload can thus not be fragmented. The simple way out is to use a classic KE payload for IKE_SA_INIT and then negotiate a hybrid with classic and frodokem, eg 25519-frodokem. If you want a "pure frodokem" that would need some kind of protocol change to allow this to happen. But I now see that you are only defining the hybrid, so this is not an issue for you then :) Paul
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
