[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
- [IPsec] Charles Eckel's Discuss on draft-ietf-ips… Charles Eckel via Datatracker
- [IPsec] Re: Charles Eckel's Discuss on draft-ietf… Kampanakis, Panos
- [IPsec] Re: Charles Eckel's Discuss on draft-ietf… Charles Eckel (eckelcu)