Thanks Charles. I fixed the nits in the -09 version. To answer your question
> Thus, implementation transporting IKE over UDP and not performing Path MTU > (PMTU) discovery SHOULD NOT use ML-KEM-768 or ML-KEM-1024 in the IKE_SA_INIT > exchange on networks where the PMTU is unknown or restricted. It has a "SHOULD NOT" because ML-KEM-768 could fit in the IKE_SA_INIT depending on the rest of the content in the proposal. So strictly speaking, it is not certain we would need fragmentation. Additionally, there are networks where IP fragmentation is not a problem (reassembly of the fragments succeeds as you mention. or where Jumbo Frames are used which could fit all sizes of ML-KEM. So, the WG agreed to keep "SHOULD NOT" there as a way to caution implementers but not make it completely mandatory. -----Original Message----- From: Charles Eckel via Datatracker <[email protected]> Sent: Wednesday, July 1, 2026 6:44 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [EXTERNAL] Charles Eckel's Discuss on draft-ietf-ipsecme-ikev2-mlkem-08: (with DISCUSS and COMMENT) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Charles Eckel has entered the following ballot position for draft-ietf-ipsecme-ikev2-mlkem-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would like to DISCUSS a couple concerns I have with respect to normative language. Section 1.2, reads, "ML-KEM-768 and ML-KEM-1024 public key and ciphertext sizes can exceed the path MTU; these key exchanges could require more than one IP packet from both the initiator and the responder." Section 2.1 says, "Thus, implementation transporting IKE over UDP and not performing Path MTU (PMTU) discovery SHOULD NOT use ML-KEM-768 or ML-KEM-1024 in the IKE_SA_INIT exchange on networks where the PMTU is unknown or restricted." Why is this not a MUST? How does receiver handle if sender ignores the SHOULD? I suppose the latter depends on whether reassembly of the fragments succeeds or not. Is it worth saying something about this? I also support the DISCUSS by Mahesh on section 2.2. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Scott Fluhrer, the document shepherd, for his very helpful write-up, particularly the insights on IPR claims. Nits - Abstract, expand "SA" in "Child SA". - Section 2.1, s/fields inside it has meaning/fields inside it have meanings _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
