[radext] Re: Review of draft-janfred-radext-radius-congestion-control-01

Alan DeKok <alan.dekok@inkbridge.io> Sun, 26 April 2026 13:48 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 20079E36DACE for <radext@mail2.ietf.org>; Sun, 26 Apr 2026 06:48:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777211299; bh=QwrFZOf8+Vch6+vNlqzcZJTKshNbhE0UDsLTITQ+i8Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=xzos5EDj7PGDjMYJdr9jS6HCFrrs3hTb6yxR4XOHETY/bZvERUEzpsovm1fE98CM+ EvS92hTMwQ/mJnVUE/FogSsOEbuw6ZH9rnDflawPVFz53rxe3XE/UVv5NlYxKwzy9F MkTk0x1kDhbkWeGFivwss2dN0CmfZJq8mrIgrFMo=
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 header.b="G+ttqhuB"; dkim=pass (2048-bit key) header.d=inkbridge.io header.b="hu5JHH2Y"
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 ryKdz4T2MOUW for <radext@mail2.ietf.org>; Sun, 26 Apr 2026 06:48:18 -0700 (PDT)
Received: from mail2.networkradius.com (mail2.networkradius.com [184.95.211.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 73C3AE36DAC3 for <radext@ietf.org>; Sun, 26 Apr 2026 06:48:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=inkbridge.io; s=sep2024; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0A0b8xR93XMwdUDVvwQQc4BAEYiATbXEe2qC38QqB0Q=; b=G+ttqhuBP7CZVJheuIV6F2FPb6 rCTbjxw6acfST9XfkfLavg9y9xrc0xQLBTzTqhq3svVD9QuYCcNVKVi78r0iy8uBUtLszIFN/+WTs tWzmJ6mTzPHtV3XOGSu8mIIqDwMEU2t/BFWKeJnnJUmiwwXaxoF6SD/XhEV+IbUwo6KTT/08u6iLy WDlB3C5EhfVjY5K3MzRu5sZwcjqkSl9bJx42rMVKyx7+iIfV5iF/7j0vKPA6BcWuwbwp3awkWtZuD sRcAb9SxiVugBHYozGL/mPqMtGoX7tmDyU6yNtpg9QKdGLW6CCcqtsGS8m1U8CNSA5wS1ovYWh406 NC6Vs0Ww==;
Received: from mail.servers.fr.internal.networkradius.com ([192.168.42.56]:43422 helo=mail.networkradius.com) by mail2.networkradius.com with esmtp (Exim 4.97) (envelope-from <alan.dekok@inkbridge.io>) id 1wGzqD-00000000QHA-2iIx; Sun, 26 Apr 2026 13:48:09 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inkbridge.io; s=sep2024; t=1777211288; bh=0A0b8xR93XMwdUDVvwQQc4BAEYiATbXEe2qC38QqB0Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=hu5JHH2YcUcQNNm6rBXlkO93wFuaKdH467tYqB7mxAIyCf/vCEiFsu8fG/vFuxHUr jscLar2m+kWMHzetNgm7jTSj6Cy9Q4olTurLIMp4xF3Z1KGB+hyf0jwX4Twyfltjm5 8BdPrwcd21djvksbocR8zcv08ITdLM4L7eabVtkYsMILCrWwgls7UTc9U3gT5ojasr RwkZ1wJcyNncDEzFWvDGjDgP2SHIj51lSka9qu1AAMGnhGbWcc3i696orXrO9R9PXO JceoahT6S1AeC9jpX700lNeSGMNJSpzIF2n2Ci0uylZIPc5Jmqt1nvbmDIdTSAW6K5 ABs6sK04Vexqg==
Received: from smtpclient.apple (24-246-4-149.cable.teksavvy.com [24.246.4.149]) by mail.networkradius.com (Postfix) with ESMTPSA id 74C326C; Sun, 26 Apr 2026 13:48:08 +0000 (UTC)
Content-Type: multipart/signed; boundary="Apple-Mail=_B12DD9A5-07E9-4EA8-A355-A8CD0D419CAD"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.4\))
From: Alan DeKok <alan.dekok@inkbridge.io>
In-Reply-To: <26881.1776953534@obiwan.sandelman.ca>
Date: Sun, 26 Apr 2026 09:47:56 -0400
Message-Id: <A4B94C08-C92D-4FB4-A736-2EF2AF0DB86D@inkbridge.io>
References: <BYAPR11MB37689872340FFF3C092140E0CC2C2@BYAPR11MB3768.namprd11.prod.outlook.com> <D2814CEE-D70F-4AED-B3FB-7DC747F780D9@inkbridge.io> <BYAPR11MB37683B78B0748256A547A960CC2D2@BYAPR11MB3768.namprd11.prod.outlook.com> <9A8C93DD-2B42-4229-B055-94F5B57ADCE7@inkbridge.io> <26881.1776953534@obiwan.sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3826.700.81.1.4)
Message-ID-Hash: CKPFQGJY46WT75GZSY3KKP3PUPSVPSLH
X-Message-ID-Hash: CKPFQGJY46WT75GZSY3KKP3PUPSVPSLH
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" <radext@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [radext] Re: Review of draft-janfred-radext-radius-congestion-control-01
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/xGMSLM2NNVXEExUHMim61zxpZaM>
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>

On Apr 23, 2026, at 10:12 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> But, AFAIK, federations like eduroam leaves it up to the supplicant and
> backend authenticator to do whatever inner EAP method they want.  So the
> authenticator does not get to see that part, so can't do any kind of per-user
> rate limiting.  All that is visible is the outer EAP's NAI.

  Yes.

> This seems like a big deal, and something worth fixing, even if it takes a
> long time to deploy.

  There as similar issues with EAP-PPT.

  When a user has complete anonymity in a roaming environment, there is substantial potential for abuse.

  It's likely impossible to satisfy both the user desire for anonymity, and the local administrations desire to prevent abuse.

  So the question then becomes, what can we do about it?

  I suspect that administrators will err on the side of safety.  i.e. If someone @example.com is abusing the local network. the safest and simplest thing to do is to ban all users @example.com.

  Those users can then complain to their administrator, who will (presumably) deal with the issue out of band.

  Alan DeKok.