[radext] Rate limiting of EAP for supplicants
Alan DeKok <alan.dekok@inkbridge.io> Fri, 24 July 2026 12:23 UTC
Return-Path: <alan.dekok@inkbridge.io>
X-Original-To: radext@mail2.ietf.org
Delivered-To: radext@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id B5A5811E26D35; Fri, 24 Jul 2026 05:23:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784895788; bh=QSgUdccCpV9S8TVBGK1CNkf3t8WhXbUt83q+L6z6Bqw=; h=From:Subject:Date:Cc:To; b=Ef5WD15nh9QJfphKysGKU0lJcHS3TMHDvE4K+hKQjWjiS3qgy0Y3j0JzwJ2leipwb /MOi6ERnnjF/lg+idOb2FmVS0kF7Pe5qWtuvrjGN8pVZWCTmqAANvk9sm28iTqbtAz +BtegKARZ1kG8Oh+oblj376ogMXD1OCsYX273rf8=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=inkbridge.io
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3TnEPJ_ZwQQ; Fri, 24 Jul 2026 05:23:08 -0700 (PDT)
Received: from mail.networkradius.com (mx1-ca.networkradius.com [199.66.222.134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 15B4811E26D2D; Fri, 24 Jul 2026 05:23:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inkbridge.io; s=sep2024; t=1784895787; bh=X8Km4LA4CJnET1RPFc/0I+YxoFKEftmt3OOVKlyCnCE=; h=From:Subject:Date:Cc:To:From; b=FJXQgGTc+0X5WqcEDp9RM9EctaPWQ5/1w60LQFfkhz1XdxGsVvLDkMjvBaz+QhHmC Ntu62boSAQZXNNRN8zgfITqlRz3Aq/cGPpjX2Z7nbK8qIcWxJwVX2+hlVXOwW26ti3 MgWBTft9mB4PoZl6sACuvFK9sBSrINBXSbbVz2JbQUbGhWNGy7UL/dw3QB/HuC525S 6HarMcHTFBqMwTgP5t1cGLy5TrXKx0H+RZZyhIpZ64hWIaM28X23gIaPMwLJYWtEuc o7SFEiVtHTeZJqv4M+IN7ktOVWb2cELHrQCWINctFpr44O1aMv8//ruAKcKY1IYNPk QRQYTVbbrjDRQ==
Received: from smtpclient.apple (rtr-guestwired.meeting.ietf.org [31.133.144.1]) by mail.networkradius.com (Postfix) with ESMTPSA id F0A41134008F; Fri, 24 Jul 2026 12:23:06 +0000 (UTC)
From: Alan DeKok <alan.dekok@inkbridge.io>
Content-Type: multipart/signed; boundary="Apple-Mail=_7B7B736E-901A-496A-8290-A21B4EC77910"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.4\))
Message-Id: <0F6AAB9F-E156-49D6-9A59-C7FCE173334E@inkbridge.io>
Date: Fri, 24 Jul 2026 14:22:55 +0200
To: EMU WG <emu@ietf.org>
X-Mailer: Apple Mail (2.3826.700.81.1.4)
Message-ID-Hash: HO7M7DQV73HYJAX4MYPK2ZZZDFIT6HLK
X-Message-ID-Hash: HO7M7DQV73HYJAX4MYPK2ZZZDFIT6HLK
X-MailFrom: alan.dekok@inkbridge.io
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-radext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: radext@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [radext] Rate limiting of EAP for supplicants
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/hZgKSH-ILxh4rtJTSfNcjKwavbc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Owner: <mailto:radext-owner@ietf.org>
List-Post: <mailto:radext@ietf.org>
List-Subscribe: <mailto:radext-join@ietf.org>
List-Unsubscribe: <mailto:radext-leave@ietf.org>
There are no documents right now which require that supplicants rate limit their messages. As eduroam US found out, some supplicants will happily send thousands of requests a second. This is bad. It would be good to require supplicants to rate-limit their traffic. The one question is where do we do this? The "updating RADIUS security" document has a discussion on rate limiting: https://www.ietf.org/archive/id/draft-ietf-radext-deprecating-radius-09.html#section-5.4 Would it be useful / acceptable to add a subsection there, which mandates rate limiting for supplicants, too? It could update EAP (3748) I don't think there is enough text to issue a new EAP document. So putting the update into a RADEXT document seems to be at least somewhat reasonable. Is this a good idea? Is it the best place to do it? Alan DeKok.