[IPsec] Charles Eckel's Discuss on draft-ietf-ipsecme-ikev2-mlkem-08: (with DISCUSS and COMMENT)

Charles Eckel via Datatracker <noreply@ietf.org> Wed, 01 July 2026 22:44 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@mail2.ietf.org
Received: from [10.244.22.182] (gaia.k8s.ietf.org [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id BFFB310C03B4B; Wed, 1 Jul 2026 15:44:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782945846; bh=HOG2oLLEMyZWTvTd25DgYkyVVasQt3DclpMdFqUUx/A=; h=From:To:Cc:Subject:Reply-To:Date; b=qVfINVqgwWaTdWNd/6AOszyh0NRtNhllvY2J8dgb4w6PbBZrv50Z9SjAdY93s73cg pwvvpnKF3JV11Tl4SNdgtYIh2QFR2Una0WnbtWJOvRrvk0jxPlbtvN0w14F98gzT3Q VtIoJfThPVEU/+ntD9cAJ4ZOKHUr1dM/YrtPnOfo=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Charles Eckel via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.67.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <178294584671.2289293.4363484353568077077@dt-datatracker-f9b87776f-xzl65>
Date: Wed, 01 Jul 2026 15:44:06 -0700
Message-ID-Hash: L4HDKAWJE73X237KJTWSSNUY45HYNVOH
X-Message-ID-Hash: L4HDKAWJE73X237KJTWSSNUY45HYNVOH
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipsec.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-ipsecme-ikev2-mlkem@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, sfluhrer@cisco.com
X-Mailman-Version: 3.3.9rc6
Reply-To: Charles Eckel <eckelcu@cisco.com>
Subject: [IPsec] Charles Eckel's Discuss on draft-ietf-ipsecme-ikev2-mlkem-08: (with DISCUSS and COMMENT)
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/t6c54Het03vZ7NjQ2M4OqP-RoTk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Owner: <mailto:ipsec-owner@ietf.org>
List-Post: <mailto:ipsec@ietf.org>
List-Subscribe: <mailto:ipsec-join@ietf.org>
List-Unsubscribe: <mailto:ipsec-leave@ietf.org>

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