Hi Panos, > On Jul 5, 2026, at 12:33 PM, Kampanakis, Panos <[email protected]> wrote: > > Thanks Charles. I fixed the nits in the -09 version.
Thanks. > > 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. Thank you for this more detailed explanation. Personally, I find it very helpful and believe others reading this document would as well, but perhaps the WG already debated this point and the current text was viewed as being sufficiently clear without being unnecessarily prescriptive. The draft already provides justification for the SHOULD NOT. I will clear my DISCUSS and leave it to you to decide whether or not adding the more detailed justification is helpful. Thanks again, Charles > > > > -----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]
